서버리스 아키텍처 2026: AWS Lambda vs Vercel vs Cloudflare Workers

서버를 관리하지 않는다. 코드를 올리면 알아서 실행되고, 트래픽이 몰리면 알아서 스케일링되고, 안 쓰면 비용이 0원이다. 서버리스(Serverless)의 기본 아이디어는 이거다.

물론 서버가 정말로 없는 건 아니다. 서버는 있다. 내가 관리하지 않을 뿐. 클라우드 제공자가 서버 프로비저닝, 운영체제 패치, 스케일링, 가용성을 전부 처리해준다. 개발자는 코드에만 집중하면 된다.

FaaS와 BaaS

서버리스는 크게 두 가지로 나뉜다.

FaaS(Function as a Service) — 함수 단위로 코드를 실행하는 서비스. AWS Lambda, Cloudflare Workers, Vercel Functions 같은 것들. HTTP 요청이 들어오면 해당 함수가 실행되고, 결과를 반환하면 끝. 함수가 호출되지 않는 동안에는 아무 리소스도 소비하지 않는다.

BaaS(Backend as a Service) — 백엔드 기능을 API로 제공하는 서비스. Firebase(인증, DB, 스토리지), Supabase, Auth0 같은 것들. 직접 백엔드를 구축하지 않고 이미 만들어진 서비스를 갖다 쓰는 방식이다.

이 글에서는 주로 FaaS 쪽을 다룬다.

AWS Lambda

서버리스 FaaS의 원조. 2014년에 나왔고, 가장 성숙하고 기능이 풍부하다.

특징:

• 지원 언어가 많다. Node.js, Python, Java, Go, .NET, Ruby. 커스텀 런타임을 쓰면 거의 모든 언어로 가능
• 다른 AWS 서비스와의 연동이 강력하다. S3에 파일이 올라오면 Lambda 실행, DynamoDB에 데이터가 바뀌면 Lambda 실행, SQS 메시지가 오면 Lambda 실행 — 이런 이벤트 기반 아키텍처를 쉽게 만들 수 있다
• 최대 실행 시간 15분. 짧은 작업에 적합하고, 오래 걸리는 배치 작업은 Step Functions와 조합해서 처리
• 메모리 128MB ~ 10GB 선택 가능. CPU는 메모리에 비례해서 할당

과금 방식: 요청 수 + 실행 시간 기준. 월 100만 요청과 40만 GB-초가 무료 티어에 포함되어 있어서, 소규모 서비스는 사실상 무료로 운영 가능하다.

비용 = (요청 수 × $0.0000002) + (실행시간(GB-초) × $0.0000166667)

월 100만 요청이면 요청 비용만 $0.20. 정말 싸다.

단점은 콜드 스타트. Lambda 함수가 일정 시간 호출되지 않으면 인스턴스가 내려간다. 다음 요청이 들어올 때 인스턴스를 새로 만들어야 해서 지연이 발생한다. Node.js 기준 보통 100500ms, Java는 15초까지 걸릴 수 있다. Provisioned Concurrency를 설정하면 인스턴스를 미리 띄워둘 수 있는데, 이러면 상시 비용이 발생한다.

Vercel Functions

Next.js를 만든 Vercel이 제공하는 서버리스 함수. 웹 프런트엔드 개발자에게 가장 친숙한 서버리스 환경일 거다.

특징:

• Next.js의 API Routes, Server Actions이 자동으로 서버리스 함수로 배포된다. 별도 설정 없이 app/api/ 아래에 파일을 만들면 끝
• Git push만 하면 자동 배포. CI/CD를 따로 구성할 필요 없다
• 프리뷰 배포가 PR마다 자동으로 생성되어서 리뷰가 편하다
• Edge Functions도 지원해서 CDN 엣지에서 함수를 실행할 수 있다

과금 방식: 무료 플랜에서 월 10만 요청, 100GB-시간의 함수 실행 포함. 취미 프로젝트에는 충분하다. Pro 플랜($20/월)부터 실제 서비스 운영에 적합한 제한이 걸린다.

주요 용도: Vercel Functions는 범용 서버리스라기보다, Next.js(또는 프런트엔드 프레임워크) 프로젝트의 백엔드 로직을 처리하는 데 최적화되어 있다. API 라우트, 서버 사이드 렌더링, ISR(Incremental Static Regeneration) 같은 Next.js 기능이 서버리스 함수로 자연스럽게 구현된다.

AWS Lambda처럼 S3 이벤트를 트리거하거나 SQS와 연동하는 건 Vercel의 영역이 아니다. 웹 앱의 API 엔드포인트를 서버리스로 처리하는 게 주 목적이다.

Cloudflare Workers

Cloudflare의 엣지 서버리스 플랫폼. 이 중에서 가장 독특한 모델이다.

특징:

• V8 Isolate 기반이다. Node.js가 아니라 Chrome V8 엔진의 격리된 인스턴스에서 코드가 실행된다. 이 때문에 컨테이너나 VM보다 훨씬 가볍고 빠르다
• 콜드 스타트가 사실상 없다. 인스턴스 시작 시간이 5ms 미만. Lambda의 콜드 스타트 문제가 여기서는 거의 해소된다
• 전 세계 300개 이상의 엣지 로케이션에서 실행된다. 사용자와 가장 가까운 서버에서 함수가 돌아가니까 레이턴시가 매우 낮다
• Workers KV(키-값 저장소), Durable Objects(상태 관리), R2(S3 호환 스토리지), D1(SQLite 기반 DB) 같은 자체 스토리지 서비스를 제공

과금 방식: 무료 플랜에서 일 10만 요청, 실행 시간 10ms 제한. 유료 플랜($5/월)부터 월 1,000만 요청 포함, 초과분 100만 요청당 $0.50.

제한 사항: V8 Isolate 환경이라 Node.js의 모든 API를 쓸 수 있는 건 아니다. fs, net 같은 네이티브 모듈은 사용 불가. npm 패키지 중 Node.js 네이티브 기능에 의존하는 것들은 안 돌아간다. Workers 환경에 맞게 작성된 코드나 호환되는 라이브러리를 써야 한다.

CPU 실행 시간에도 제한이 있다. 무료 플랜 10ms, 유료 플랜 30초. I/O 대기 시간은 제한에 포함되지 않으니 API 호출이 많은 함수는 괜찮지만, CPU 집약적인 작업에는 적합하지 않다.

Deno Deploy

Deno 런타임 기반의 서버리스 플랫폼이다. Cloudflare Workers와 비슷하게 엣지에서 실행된다.

특징:

• Deno 런타임을 그대로 사용. TypeScript 네이티브 지원, 표준 Web API(fetch, Request, Response) 기반
• 글로벌 엣지에서 실행되어 레이턴시가 낮다
• Fresh(Deno의 웹 프레임워크)와 자연스럽게 통합
• Deno KV — 글로벌 분산 키-값 저장소 내장

아직 시장 점유율은 작지만, Web Standard API 기반이라는 점에서 이식성이 좋고, Deno 생태계가 성장하면서 관심이 늘고 있다.

플랫폼 비교 요약

항목	AWS Lambda	Vercel Functions	Cloudflare Workers	Deno Deploy
실행 환경	컨테이너	Node.js/Edge	V8 Isolate	Deno
콜드 스타트	100ms~수초	보통	거의 없음 (~5ms)	거의 없음
최대 실행 시간	15분	60초(Hobby)	30초(유료)	50ms CPU
엣지 실행	Lambda@Edge	Edge Functions	기본	기본
언어 지원	다양	JS/TS	JS/TS/Wasm	JS/TS
무료 티어	100만 요청/월	10만 요청/월	10만 요청/일	100만 요청/월
AWS 통합	최고	없음	일부 (R2=S3 호환)	없음

콜드 스타트 — 서버리스의 고질병

서버리스의 가장 큰 불만 중 하나다. 함수가 한동안 호출되지 않으면 인스턴스가 제거되고, 다음 요청 시 새로 시작해야 하니까 첫 응답이 느려진다.

콜드 스타트에 영향을 주는 요소:

• 런타임 — Python, Node.js는 빠르고(100300ms), Java, .NET은 느리다(15초)
• 패키지 크기 — 의존성이 많을수록 느려진다. Lambda에서는 zip 크기를 줄이는 게 중요
• 메모리 할당 — Lambda에서 메모리를 높이면 CPU도 비례해서 할당되어 콜드 스타트가 짧아진다
• VPC 연결 — Lambda를 VPC 안에 넣으면 ENI 생성 때문에 추가 지연 발생 (최근에는 많이 개선됨)

해결 방법:

• Provisioned Concurrency (Lambda) — 인스턴스를 미리 워밍해두지만, 비용 발생
• 주기적 핑 — 일정 간격으로 함수를 호출해서 인스턴스를 유지하는 꼼수. 근본적 해결은 아님
• Cloudflare Workers / Deno Deploy로 전환 — V8 Isolate 기반이라 콜드 스타트 문제 자체가 거의 없다

서버리스가 적합한 경우

API 백엔드 — CRUD API, 웹훅 처리, 인증 등. 요청이 들어올 때만 실행되면 되니까 서버리스와 잘 맞는다.

이벤트 처리 — 파일 업로드 시 이미지 리사이징, 결제 완료 후 이메일 발송, 로그 수집 같은 이벤트 기반 작업.

트래픽 변동이 큰 서비스 — 평소에는 트래픽이 거의 없다가 특정 시간에만 몰리는 서비스. 서버리스는 자동으로 스케일링되니까 인스턴스 수를 미리 걱정할 필요가 없다.

프로토타입/MVP — 빠르게 만들고 싶을 때. 인프라 구성 없이 코드만 작성하면 되니까 속도가 빠르다.

서버리스가 적합하지 않은 경우

장시간 실행 작업 — 동영상 인코딩, ML 모델 학습, 대규모 배치 처리. 실행 시간 제한에 걸리고, 비용도 EC2나 컨테이너보다 비싸진다.

상태 유지가 필요한 작업 — WebSocket 연결, 게임 서버 같은 것. 서버리스 함수는 기본적으로 상태가 없다(stateless). Durable Objects(Cloudflare)같은 걸로 해결할 수는 있지만 복잡해진다.

높은 처리량 + 일정한 트래픽 — 초당 수천 건의 요청이 꾸준히 들어오는 서비스. 이 경우 서버리스보다 상시 실행되는 컨테이너가 비용 효율적이다. 서버리스는 호출당 과금이라 트래픽이 지속적으로 높으면 전통적 서버보다 비싸질 수 있다.

디버깅이 어렵다 — 이건 모든 서버리스의 공통 약점이다. 로컬에서 재현하기 어려운 문제가 생기고, 분산 시스템의 디버깅 복잡성이 추가된다. 로그 추적이 번거롭고, 콜드 스타트로 인한 타임아웃 같은 서버리스 특유의 문제도 있다.

엣지 컴퓨팅 트렌드

서버리스의 다음 진화가 엣지 컴퓨팅이다. 기존 서버리스가 특정 리전의 데이터센터에서 함수를 실행했다면, 엣지 서버리스는 사용자와 가장 가까운 CDN 엣지 노드에서 실행한다.

Cloudflare Workers가 이 모델의 선두주자이고, Vercel Edge Functions, Deno Deploy도 같은 방향이다. AWS도 Lambda@Edge와 CloudFront Functions로 엣지 컴퓨팅을 제공하지만, Cloudflare Workers만큼 전면적이지는 않다.

엣지에서 할 수 있는 것들:

• A/B 테스팅 — 사용자 요청을 엣지에서 분기
• 인증 토큰 검증 — 오리진 서버까지 가기 전에 엣지에서 처리
• 지역별 콘텐츠 커스터마이징
• API 응답 캐싱과 변환

다만 엣지에서는 실행 시간과 메모리에 더 엄격한 제한이 있고, 데이터베이스 접근이 제한될 수 있다. 모든 로직을 엣지로 옮기는 게 아니라, 엣지에서 처리하기 적합한 작업을 선별해서 배치하는 게 맞다.

서버리스는 만능이 아니다. 하지만 적합한 곳에 쓰면 인프라 관리 부담을 크게 줄일 수 있다. 특히 사이드 프로젝트나 소규모 서비스에서는 서버 한 대 관리하는 것보다 서버리스가 훨씬 편하고 저렴하다. 프로젝트 규모와 특성에 맞춰서 선택하면 된다.