‘서버가 없는 컴퓨팅’이라는 이름은 오해를 부르기 쉽다. 서버리스(Serverless)는 서버가 사라진다는 뜻이 아니라, 개발자가 서버를 직접 프로비저닝하거나 관리하지 않아도 된다는 운영 모델을 가리킨다. 코드를 함수 단위로 올려두면 클라우드 사업자가 실행 환경을 자동으로 준비하고, 요청이 들어온 만큼만 과금한다. 이 글은 서버리스의 정의와 FaaS·BaaS 구조, 주요 플랫폼 비교, 콜드 스타트와 과금 모델, 그리고 도입 전에 알아야 할 한계까지 실무 관점에서 정리한다.
서버리스란 무엇인가 — ‘서버가 없다’는 오해
서버리스에서도 물리 서버는 당연히 존재한다. 달라지는 것은 책임의 경계다. 전통적인 방식에서는 개발자가 EC2 인스턴스 같은 서버를 띄우고, 용량을 산정하고, OS 패치와 스케일링까지 떠맡는다. 이 모델에서는 그런 하부 구조 관리를 클라우드 사업자에게 위임한다. Cloudflare의 설명에 따르면 서버리스는 “서버 관리 없이 애플리케이션을 빌드하고 실행하는” 모델이며, 개발자는 코드에만 집중하면 된다.
비유하자면 발전소를 직접 짓는 대신 콘센트에 플러그를 꽂고 쓴 전기만큼만 요금을 내는 것과 같다. 서버를 24시간 켜두고 고정 비용을 내는 대신, 요청이 실제로 처리된 시간만큼만 비용이 발생한다. 트래픽이 0이면 비용도 0에 수렴한다. IBM은 이 사용량 기반 과금과 자동 확장을 해당 모델의 핵심 특징으로 꼽는다.
FaaS와 BaaS — 서버리스를 떠받치는 두 축
서버리스는 흔히 두 갈래로 나뉜다. 어느 쪽이든 인프라 운영을 사업자에게 맡긴다는 공통점이 있다.
- FaaS(Function-as-a-Service): 애플리케이션 로직을 함수 단위로 배포하고, 이벤트가 발생할 때만 실행한다. AWS Lambda, Google Cloud Functions, Cloudflare Workers가 대표적이다. 서버리스를 이야기할 때 대부분 FaaS를 지칭한다.
- BaaS(Backend-as-a-Service): 인증·데이터베이스·파일 저장 같은 백엔드 기능을 완성형 서비스로 제공한다. 개발자는 프런트엔드만 작성하고 백엔드는 API로 호출한다. Firebase, Supabase 등이 여기에 속한다.
두 모델은 함께 쓰이는 경우가 많다. 예컨대 모바일 앱이 인증과 저장은 BaaS에 맡기고, 결제 검증이나 이미지 리사이징 같은 커스텀 로직만 FaaS 함수로 처리하는 식이다.
서버리스는 어떻게 동작하나 — 이벤트와 콜드 스타트
서버리스 함수는 상시 대기하지 않는다. HTTP 요청, 파일 업로드, 메시지 큐 이벤트 같은 트리거가 발생하면 그제야 실행 환경이 깨어난다. 이 지점에서 가장 유명한 약점인 콜드 스타트(Cold Start)가 등장한다.
콜드 스타트는 함수가 오랫동안 호출되지 않아 실행 환경이 종료된 뒤, 새 요청이 들어왔을 때 환경을 처음부터 다시 준비하는 지연을 말한다. 런타임 종류, 패키지 크기, VPC 설정에 따라 수십 밀리초에서 2초까지 벌어진다. 반대로 최근에 실행돼 환경이 아직 살아 있으면 지연 없이 응답하는데, 이를 웜 스타트(Warm Start)라 부른다.
플랫폼마다 콜드 스타트에 대응하는 방식이 다르다. AWS Lambda는 프로비저닝된 동시성(Provisioned Concurrency)이나 SnapStart로 환경을 미리 데워둘 수 있다. Cloudflare Workers는 컨테이너 대신 V8 아이솔레이트(isolate)를 사용해 시작 시간을 극단적으로 줄였고, 공식적으로 콜드 스타트가 사실상 없다고 소개한다. Vercel Functions는 공식 문서에서 일정 기간 호출이 없으면 함수가 아카이브되며, 재호출 시 콜드 스타트가 1초가량 더 길어질 수 있다고 명시한다.
주요 서버리스 플랫폼 비교
가장 널리 쓰이는 세 플랫폼을 정리하면 다음과 같다. AWS Lambda는 2014년 출시된 FaaS의 사실상 표준이고, Cloudflare Workers는 엣지 실행, Vercel Functions는 프런트엔드 프레임워크와의 통합에 강점이 있다.
| 항목 | AWS Lambda | Cloudflare Workers | Vercel Functions |
|---|---|---|---|
| 실행 방식 | 리전 기반 컨테이너 | 엣지 V8 아이솔레이트 | microVM(Node.js 등) |
| 콜드 스타트 | 수십ms~2초 | 사실상 없음 | 아카이브 시 +1초 |
| 무료 한도 | 월 100만 요청 + 40만 GB-초 | 일 10만 요청 | 플랜별 상이 |
| 유료 과금 | $0.20 / 100만 요청 | 최소 $5/월, $0.30 / 100만 요청 | 사용량 기반 |
| 강점 | 방대한 AWS 생태계 통합 | 글로벌 저지연 엣지 | Next.js·프런트 통합 |
숫자는 각 사업자 공식 가격 페이지 기준이며, 리전과 플랜에 따라 달라질 수 있다. 세 플랫폼 모두 ‘쓴 만큼 과금’과 ‘자동 확장’이라는 핵심 가치를 공유하되, 실행 위치와 격리 방식에서 갈린다.
과금 모델과 숨은 비용
서버리스의 과금은 요청 수 × 실행 시간 × 할당 메모리의 조합이다. AWS Lambda 공식 가격은 100만 요청당 $0.20, 실행 시간은 GB-초당 $0.0000166667이며, 매월 100만 요청과 40만 GB-초를 무료로 제공한다. Cloudflare Workers는 무료 플랜에서 하루 10만 요청, 유료 플랜은 계정당 월 최소 $5에 1,000만 요청을 포함하고 초과분은 100만 요청당 $0.30이다.
다만 실제 청구서는 함수 실행비만으로 끝나지 않는다는 점을 짚어야 한다. API Gateway, 로그 저장(CloudWatch), NAT Gateway 같은 부수 서비스가 전체 청구 비용의 상당 부분을 차지하는 경우가 흔하다. 게다가 AWS는 2025년 8월 1일부터 초기화(INIT) 단계 과금을 표준화했다. 그동안 관리형 런타임의 ZIP 패키지 함수는 콜드 스타트 초기화 시간이 청구에서 빠져 있었는데, 이제 모든 구성에서 동일하게 계산된다. AWS는 대부분의 사용자에게 미치는 영향은 미미하다고 밝혔지만, 콜드 스타트가 잦은 워크로드라면 과금 구조 변화를 점검해 볼 만하다.
서버리스가 맞는 경우와 한계
서버리스가 만능은 아니다. 다음과 같은 워크로드에서 특히 빛을 본다.
- 트래픽이 불규칙하거나 예측하기 어려운 API
- 이미지 처리, 웹훅 수신, 예약 배치 같은 이벤트 기반 작업
- 빠르게 프로토타이핑하고 초기 인프라 비용을 최소화하려는 스타트업
반대로 한계도 분명하다. 콜드 스타트로 인한 지연은 실시간성이 중요한 서비스에서 부담이 되고, 함수당 실행 시간과 메모리에 상한이 있어 장시간 배치나 대용량 연산에는 부적합하다. 트래픽이 꾸준히 높은 서비스라면 상시 실행 서버가 오히려 저렴할 수 있으며, 특정 사업자에 대한 종속(vendor lock-in)과 분산된 함수의 디버깅 난이도도 무시할 수 없다. 그렇다면 실무에서는 어떤 기준으로 판단해야 할까? 트래픽 패턴이 들쭉날쭉하고 운영 인력을 줄이고 싶다면 서버리스가, 부하가 일정하고 세밀한 제어가 필요하다면 컨테이너 기반이 더 나은 선택인 경우가 많다.
자주 비교되는 것이 컨테이너 오케스트레이션이다. 도커 같은 컨테이너가 애플리케이션 패키징의 기본이라면, 쿠버네티스 입문은 컨테이너를 대규모로 운영하는 방식이다. 서버리스는 이 스택에서 한 단계 더 추상화를 밀어붙여, 인프라 운영 자체를 사업자에게 넘긴 모델로 이해하면 위치가 분명해진다.
정리
서버리스는 서버가 없어지는 기술이 아니라, 서버 관리 책임을 클라우드 사업자에게 넘기고 사용한 만큼만 비용을 내는 운영 모델이다. FaaS와 BaaS라는 두 축으로 나뉘며, AWS Lambda·Cloudflare Workers·Vercel Functions 같은 플랫폼이 각자의 실행 방식으로 이를 구현한다. 콜드 스타트와 숨은 비용, 실행 상한이라는 한계를 인지한 채 워크로드 성격에 맞게 선택한다면, 서버리스는 인프라 운영 부담을 크게 덜어주는 강력한 도구가 된다. 다음 인프라 글에서는 이 위에서 인프라를 코드로 관리하는 IaC와 Terraform을 다룬다.