서버리스 아키텍처란?

서버리스 아키텍처는 클라우드 제공업체가 요청이 있을 때 코드를 실행해 주므로 서버를 직접 프로비저닝하거나 관리할 필요가 없는 클라우드 실행 모델입니다. 서버는 여전히 존재합니다. 다만 서버를 빌리고, 패치하고, 확장하는 일을 그만두는 것입니다. 여러분은 함수를 배포하고, 플랫폼은 이벤트가 도착하면 컴퓨팅을 할당하고 실제로 실행된 만큼만 과금합니다.

핵심 요약

해결하는 문제

전통적인 배포에서는 수요보다 앞서 용량을 빌립니다. 인스턴스 크기를 정하고, 오토스케일링을 설정하고, 유휴 시간에 비용을 내고, OS를 패치합니다. 너무 크게 잡으면 돈을 낭비하고, 너무 작게 잡으면 트래픽이 정점일 때 요청을 처리하지 못하고 놓칩니다.

서버리스 모델에서는 이 순환 전체가 사라집니다. 함수를 작성하면, 0에서 수천 개의 동시 실행으로 확장하는 일은 제공업체의 몫입니다. 영화의 평균 평점을 서버 측에서 계산하는 데 필요한 백엔드 코드는 다음이 전부입니다.

// cloud/main.js — Back4app Cloud Code 함수
Parse.Cloud.define('averageStars', async (request) => {
  const query = new Parse.Query('Review');
  query.equalTo('movie', request.params.movie);
  const reviews = await query.find();
  const sum = reviews.reduce((acc, r) => acc + r.get('stars'), 0);
  return sum / reviews.length;
});

이를 감싸는 Express 앱도, Dockerfile도, 로드 밸런서도 없습니다. 함수가 곧 배포 단위입니다.

모든 클라이언트에서 호출하기

모든 클라이언트 SDK는 같은 함수를 이름으로 호출합니다. 전송, 인증, 확장은 플랫폼이 처리합니다.

// JavaScript / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('averageStars');
final params = <String, dynamic>{'movie': 'Inception'};
final response = await function.execute(parameters: params);
if (response.success) {
  print('Average rating: ${response.result}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("averageStars",
                        parameters: ["movie": "Inception"]) { result in
  switch result {
  case .success(let rating):
    print("Average rating: \(rating)")
  case .failure(let error):
    print(error.localizedDescription)
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("movie" to "Inception")
ParseCloud.callFunctionInBackground<Float>("averageStars", params) { rating, e ->
  if (e == null) {
    Log.d("Cloud", "Average rating: $rating")
  }
}

서버리스 요청의 흐름

주시해야 할 분기는 콜드 스타트입니다. 웜 인스턴스가 없으면 플랫폼은 코드를 실행하기 전에 런타임을 프로비저닝해야 하며, 여기에는 언어, 코드 크기, 의존성에 따라 몇 밀리초에서 몇 초까지 걸립니다. 프로덕션에서는 꾸준히 호출되는 함수가 웜 인스턴스를 계속 재사용하므로 전체 요청 중 극히 일부에만 영향을 줍니다. 대부분의 API에는 무시할 수 있는 수준이지만 지연 시간이 중요한 경로에서는 실재하는 문제이며, 엣지 함수와 워밍업 전략이 존재하는 이유이기도 합니다.

서버리스 vs. 컨테이너 vs. 전통적인 서버

FaaS와 BaaS: 서버리스의 두 반쪽

“서버리스”는 상호 보완적인 두 모델을 아우르며, 이 구분은 martinfowler.com에 실린 Mike Roberts의 대표 글이 정립했습니다. 이 구분이 생겨난 시점도 분명합니다. 상용 이벤트 트리거 컴퓨팅은 2014년에 출시되었고, 2년 안에 서버리스는 연구 아이디어에서 이벤트 기반 작업의 프로덕션 기본값이 되었습니다. 용어가 그 밑에 있는 아이디어보다 여전히 새롭게 느껴지는 이유입니다. FaaS(Functions as a Service)는 서버 측 로직을 여전히 직접 작성하되, 그 로직이 무상태의 이벤트 트리거 방식으로 완전 관리형 컴퓨팅에서 실행된다는 뜻입니다. 이른바 “클라우드 함수” 모델입니다. BaaS(Backend as a Service)는 한 걸음 더 나아갑니다. 데이터베이스, 인증, 파일 스토리지, API 자체를 관리형 서비스로 사용하므로, 직접 작성했을 백엔드 코드 대부분이 아예 사라집니다.

실제 애플리케이션 대부분은 둘 다 필요합니다. 커스텀 로직에는 함수를, 나머지 모든 것에는 관리형 서비스를 씁니다. 그 조합이 바로 BaaS 플랫폼이 패키징하는 것입니다. 모델의 이 반쪽을 깊이 알아보려면 Backend as a Service 완전 가이드를 읽어 보기를 권합니다.

서버리스의 일반적인 사용 사례

• API와 모바일 백엔드. 가장 대표적인 사례입니다. 밤에는 한산하다가 출시 때 급증하는 요청 기반 트래픽은 실행당 과금이 가장 유리하게 작동하는 바로 그 형태입니다.
• 이벤트 및 데이터 처리. 업로드 시 이미지 크기 조정, 저장 시 레코드 검증, 변경 사항을 서드파티 시스템에 동기화하는 것처럼 이벤트에 짧게 반응하는 작업입니다.
• 예약 작업. 야간 리포트, 정리 작업, 반복 동기화는 cron으로 트리거되는 함수로 실행되며, 실행 사이에 대기하는 서버가 없습니다.
• 실시간 기능. 채팅, 알림, 실시간 대시보드는 직접 만든 웹소켓 서버 대신 서버리스 함수와 관리형 실시간 인프라를 결합합니다.
• MVP와 프로토타입. 아이디어를 검증할 때는 인프라에 시간을 전혀 쓰지 않는 것이 핵심입니다. 함수를 배포하고, URL을 받고, 출시합니다.
• AI 에이전트와 웹훅. LLM, 결제 제공업체, SaaS API 사이의 연결 코드는 본질적으로 이벤트 기반이고 수명이 짧아 서버리스에 완벽하게 맞습니다.

서버리스를 선택해야 할까? 결정 매트릭스

비용에 관해서는 구체적인 기준점이 도움이 됩니다. 서버리스 플랫폼은 선불 약정 없이 요청당 요금에 소비한 컴퓨팅 시간(GB-초)을 더해 과금합니다. Back4app의 무료 요금제에는 월 25,000건의 API 요청이 포함되어 있어, 확장 결정이 필요해지기 전까지 실제 MVP를 $0으로 운영하기에 충분합니다.

한계와 트레이드오프

• 콜드 스타트. 유휴 함수의 첫 호출은 프로비저닝 비용을 치릅니다(100ms 미만부터 1초 이상까지). 완화책: 웜 동시성, 더 작은 번들, 엣지 런타임.
• 실행 시간 제한. 함수는 짧은 작업을 위해 만들어졌습니다. 비디오 인코딩이나 한 시간짜리 배치 작업은 컨테이너나 백그라운드 작업 시스템에서 처리해야 합니다.
• 더 어려운 디버깅과 관측 가능성. SSH로 접속할 서버가 없습니다. 플랫폼의 로그, 메트릭, 트레이싱에 의존하게 되므로 도입 전에 이를 평가해야 합니다.
• 벤더 종속(vendor lock-in). 독점 API에 맞춰 작성한 함수는 옮기는 비용이 큽니다. 오픈소스 위에 구축된 플랫폼을 선호하는 것이 좋습니다. Back4app의 Cloud Code는 언제든 셀프 호스팅할 수 있는 오픈소스 기반 위에서 실행됩니다.
• 지속적 대규모 운영 시 비용. 실행당 과금은 낮거나 급증하는 볼륨에서는 다른 방식이 따라올 수 없을 만큼 유리하지만, 일정한 고부하에서는 고정 서버 요금을 넘어설 수 있습니다. 트래픽이 안정되면 계산을 다시 해야 합니다.
• 무상태성. 함수는 호출 사이에 메모리를 유지하지 않습니다. 세션과 애플리케이션 상태는 데이터베이스나 캐시에 두어야 하며, 상태를 가진 코드를 포팅한다면 이는 설계상의 제약입니다.

Back4app에서의 서버리스 아키텍처

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 두 반쪽을 하나의 플랫폼에서 제공합니다. FaaS 반쪽은 Cloud Code입니다. 위의 averageStars 같은 JavaScript 함수를 대시보드나 CLI에서 배포하고, 데이터베이스 트리거와 예약 작업도 함께 쓸 수 있으며, 설정할 게이트웨이, IAM 정책, 인프라가 없습니다. BaaS 반쪽은 모든 Back4app 앱에 프로비저닝되어 있습니다. 데이터베이스, 사용자 인증, 파일 스토리지, 자동 생성되는 REST 및 GraphQL API입니다. 그리고 Back4app은 오픈소스 기반 위에 구축되어 있으므로 여러분이 작성한 함수는 이식 가능합니다. 나중에 같은 스택을 셀프 호스팅할 수 있으므로, 제공업체 전용 서버리스 플랫폼에 따라붙는 종속 우려가 사라집니다.