서버리스 컴퓨팅(Serverless Computing)은 서버를 직접 운영하지 않고도 코드를 실행하는 클라우드 실행 모델입니다. 함수형 서비스인 FaaS(Function as a Service)와 백엔드 서비스인 BaaS(Backend as a Service)를 묶어, 요청이 들어올 때만 자동으로 자원이 할당되고 사용한 만큼만 과금됩니다. AWS Lambda·Azure Functions·Cloudflare Workers가 대표 플랫폼인데요. 2026년 서버리스 시장은 약 263억 달러 규모로 추정되며, 콜드스타트와 숨은 비용이라는 한계를 어떻게 다루느냐가 기업 도입 성패를 가릅니다. 이 글은 정의·아키텍처·과금·벤더 비교·실전 도입 단계를 한 번에 정리한 가이드입니다.
목차
- 서버를 안 쓴 첫 프로젝트에서 배운 것
- 서버리스 컴퓨팅이란 무엇인가
- FaaS와 BaaS, 그리고 이벤트 기반 아키텍처
- 콜드스타트라는 오래된 숙제
- 사용한 만큼 낸다는 과금 모델의 진실
- AWS Lambda·Azure Functions·Cloudflare Workers 비교
- 2026 서버리스 도입 실전 가이드
- FAQ
- 같이 읽으면 좋은 것들
서버를 안 쓴 첫 프로젝트에서 배운 것
처음 서버리스로 작은 이미지 변환 API를 만들었을 때 일입니다. 사용자가 사진을 올리면 썸네일 세 종류를 만들어 저장하는, 흔한 기능이었는데요. 예전 방식이라면 EC2 인스턴스를 한 대 띄우고, 트래픽이 없는 새벽에도 그 인스턴스는 계속 돌면서 비용을 먹었을 겁니다. 그런데 AWS Lambda로 옮기고 나니 호출이 없는 시간에는 청구서에 0원이 찍혔습니다. 한 달 트래픽이 몰리는 며칠만 비용이 올랐고요.
처음엔 마법 같았습니다. 그러다 운영 한 달째, 사용자 한 명이 "가끔 첫 업로드가 2초 넘게 걸린다"고 제보를 했는데요. 로그를 뒤져보니 한동안 호출이 없다가 들어온 첫 요청에서만 지연이 생겼습니다. 이게 바로 콜드스타트(cold start)였습니다. 그때 깨달은 게 있습니다. 서버리스는 서버를 없앤 게 아니라, 서버 관리 책임을 클라우드로 옮기고 그 대신 다른 종류의 고민을 떠안는 모델이라는 점입니다.
또 하나 충격이었던 건 청구서 구조였습니다. Lambda 자체 비용은 정말 몇 달러밖에 안 나왔는데요. API Gateway, CloudWatch 로그, 데이터 전송 요금이 붙으니 총액이 함수 비용의 대여섯 배가 되어 있었습니다. 서버리스를 제대로 쓰려면 함수 코드보다 그 주변 구조를 먼저 이해해야 한다는 걸, 그 청구서가 가르쳐 줬습니다.
서버리스 컴퓨팅이란 무엇인가
먼저 시장 구조부터 짚어보겠습니다. 전통적인 인프라 운영은 비효율이 많았습니다. 트래픽이 어느 정도일지 미리 예측해 서버를 사두고, 피크에 대비해 여유분을 더 띄워둡니다. 그 결과 평균적으로 서버 자원의 상당 부분이 놀고 있는데도 비용은 24시간 나갑니다. 사용량이 들쭉날쭉한 서비스일수록 이 낭비가 커집니다.
서버리스 컴퓨팅(Serverless Computing)은 이 비효율을 정면으로 겨냥한 클라우드 실행 모델입니다. 이름은 "서버가 없다"는 뜻이지만, 실제로 서버가 사라진 건 아닙니다. 개발자가 서버의 존재를 의식하지 않아도 된다는 의미에 가깝습니다. 자원의 프로비저닝·스케일링·패치·장애 복구를 클라우드 사업자가 모두 맡고, 개발자는 비즈니스 로직 코드만 올립니다.
핵심 특징은 세 가지입니다. 첫째, 요청이 들어올 때만 코드가 실행되는 이벤트 기반(event-driven) 동작입니다. 둘째, 트래픽에 맞춰 0에서 수천 개 인스턴스까지 자동으로 늘었다 줄어드는 오토스케일링입니다. 셋째, 실행한 시간과 횟수만큼만 내는 종량 과금입니다. 호출이 없으면 비용도 0에 수렴하는데요, 이게 전통적인 상시 가동 서버와 가장 크게 다른 지점입니다.
Middleware의 2026 서버리스 정리에 따르면, 서버리스는 API·데이터 파이프라인·IoT 워크로드·머신러닝 트리거처럼 부하가 불규칙한 작업에 특히 잘 맞습니다. 반대로 24시간 일정하게 높은 부하가 걸리는 작업은 오히려 전통적 서버가 저렴할 수 있습니다.
FaaS와 BaaS, 그리고 이벤트 기반 아키텍처
서버리스를 이야기할 때 가장 자주 등장하는 두 약어가 FaaS와 BaaS입니다. 둘은 역할이 다릅니다.
FaaS(Function as a Service)는 서버리스의 핵심입니다. 개발자가 작성한 함수 단위 코드를 클라우드가 실행해 주는 방식인데요. AWS Lambda, Azure Functions, Google Cloud Functions가 여기에 속합니다. 함수는 평소엔 잠들어 있다가 특정 이벤트가 발생하면 깨어나 실행되고, 일이 끝나면 다시 사라집니다. 상태를 기억하지 않는 무상태(stateless) 실행이 기본입니다.
BaaS(Backend as a Service)는 인증·데이터베이스·파일 저장·푸시 알림 같은 백엔드 기능을 통째로 가져다 쓰는 방식입니다. Firebase, Supabase, AWS Amplify가 대표적인데요. 직접 백엔드를 짜는 대신 완성된 서비스에 연결만 하면 됩니다. 프런트엔드 개발자가 백엔드 인력 없이 앱을 출시할 수 있게 해주는 게 BaaS의 매력입니다.
이 둘을 묶는 접착제가 바로 이벤트 기반 아키텍처입니다. 동작 흐름을 표로 정리하면 이렇습니다.
| 이벤트 소스 | 트리거 예시 | 실행되는 함수 |
|---|---|---|
| 객체 스토리지(S3) | 파일 업로드 | 썸네일 생성·바이러스 검사 |
| 메시지 큐(SQS·SNS) | 메시지 도착 | 주문 처리·알림 발송 |
| API 게이트웨이 | HTTP 요청 | 사용자 로그인·데이터 조회 |
| 데이터베이스 스트림 | 레코드 변경 | 집계 갱신·감사 로그 |
| 스케줄러(EventBridge) | 정해진 시각 | 배치 정산·리포트 생성 |
이런 구조에서는 각 함수가 자기 일만 처리하고 결과를 다음 이벤트로 넘깁니다. AWS의 경우 S3, DynamoDB Streams, EventBridge, SNS, SQS가 Lambda와 직접 연결됩니다. 서비스끼리 느슨하게 묶이다 보니 한 부분을 고쳐도 다른 곳에 영향이 적고, 부분별로 따로 확장할 수 있다는 게 장점입니다. 대신 흐름이 여러 함수로 쪼개지면 전체 동작을 추적하기가 까다로워지는데요, 그래서 옵저버빌리티 도구가 더욱 중요해집니다.
콜드스타트라는 오래된 숙제
서버리스의 가장 유명한 약점이 콜드스타트입니다. 한동안 호출되지 않던 함수가 처음 깨어날 때, 실행 환경을 새로 띄우고 런타임을 초기화하느라 생기는 지연인데요. 짧게는 수백 밀리초, 무겁게는 1~2초까지 걸립니다.
왜 문제냐면, 사용자가 직접 마주하는 API에서 이 지연이 그대로 체감되기 때문입니다. 업계 분석에 따르면 2026년 Lambda 트래픽은 API Gateway·AppSync 뒤에 붙은 동기 API와 AI 에이전트 도구 호출이 큰 비중을 차지합니다. 둘 다 사용자 앞단에 있어 꼬리 지연(tail latency)에 민감합니다. 새벽처럼 호출이 뜸한 시간대에 들어온 첫 요청 한 건이 유독 느리면, 그 한 명에게는 서비스 전체가 느린 것처럼 보입니다.
다행히 완화 수단이 여럿 마련됐습니다.
- 프로비저닝된 동시성(Provisioned Concurrency): 미리 N개의 인스턴스를 항상 따뜻하게 켜둬 콜드스타트를 없애는 방식입니다. 대신 켜둔 만큼 추가 비용이 듭니다.
- SnapStart: 초기화를 마친 실행 환경의 스냅샷을 저장해 두고 그걸 복원하는 기술입니다. Java에서 콜드스타트를 약 200밀리초 수준으로 줄여주는데요, 2026년 기준 Java·Python·.NET에서 일반 사용이 가능합니다.
- 경량 런타임 선택: 무거운 의존성을 줄이고 초기화 코드를 가볍게 짜면 콜드스타트 자체가 짧아집니다.
한 정리 자료는 프로비저닝된 동시성과 상시 가동 풀을 함께 쓰면 지연에 민감한 앱에서 콜드스타트를 60~80% 낮출 수 있다고 봅니다. 콜드스타트는 이제 "감수해야 할 단점"이라기보다 "관리 가능한 변수"에 가까워졌습니다.
사용한 만큼 낸다는 과금 모델의 진실
서버리스의 매력은 종량 과금에서 나옵니다. 그런데 이 "쓴 만큼만 낸다"는 말을 액면 그대로 믿으면 청구서에서 당황하게 됩니다. 앞서 제 첫 프로젝트 이야기에서 짚었던 그 함정인데요.
Lambda 과금은 크게 호출 횟수와 실행 시간(GB-초)으로 구성됩니다. Wiz의 2026 비용 분석과 LeanOps 자료를 종합하면, 100만 건당 요청 비용은 리전에 따라 대략 0.20~0.28달러 선입니다. 여기까지만 보면 정말 저렴합니다. 문제는 함수 혼자 동작하지 않는다는 점입니다.
예를 들어 256MB·200밀리초로 1천만 건을 처리하는 API가 있다고 합시다. Lambda 컴퓨팅 비용 자체는 약 10달러인데요. 여기에 API Gateway, CloudWatch 로그, NAT Gateway가 붙으면 실제 청구액은 약 57달러로 뜁니다. 이 "지원 서비스"들이 전체 서버리스 비용의 약 80%를 차지하는 셈입니다. 2025년 8월부터는 콜드스타트의 초기화(INIT) 구간까지 과금 대상에 포함됐습니다.
여기서 얻을 교훈은 분명합니다. 서버리스 비용을 관리하려면 함수 단가가 아니라 전체 구조의 총소유비용(TCO)을 봐야 합니다. 로그 보존 기간을 줄이고, 불필요한 NAT Gateway 경유를 없애고, 메모리 설정을 실측해 최적화하는 작업이 실제 절감으로 이어집니다. 이런 클라우드 비용 가시화와 최적화는 FinOps 영역과 그대로 겹칩니다. 이 부분은 아래 같이 읽으면 좋은 글에서 더 깊이 다룹니다.
AWS Lambda·Azure Functions·Cloudflare Workers 비교
대표 플랫폼 세 곳은 철학이 조금씩 다릅니다. 기존 방식대로 한 벤더만 쓰던 기업이 워크로드별로 플랫폼을 골라 쓰기 시작한 게 최근 흐름인데요.
| 항목 | AWS Lambda | Azure Functions | Cloudflare Workers |
|---|---|---|---|
| 실행 모델 | 컨테이너 기반 | 컨테이너 기반 | V8 아이솔레이트 |
| 과금 기준 | 벽시계 시간(duration) | 벽시계 시간 | CPU 시간 |
| 콜드스타트 | 수백 ms~수초 | 소비 플랜에서 다소 느림 | 1ms 미만 |
| 강점 | 가장 넓은 생태계·서비스 연동 | .NET·MS 생태계 통합 | 엣지 분산·초저지연 |
| 적합한 곳 | 범용 백엔드·데이터 파이프라인 | MS 중심 기업·기존 Azure 계약 | 전 세계 사용자 대상 경량 처리 |
InventiveHQ의 플랫폼 비교를 보면, Cloudflare Workers는 브라우저와 같은 V8 엔진의 아이솔레이트 모델을 써서 1밀리초 미만으로 시작합니다. 사용자와 가장 가까운 위치에서 자동으로 실행돼 콜드스타트 고민이 사실상 없습니다. 다만 무거운 연산이나 복잡한 백엔드 통합에는 한계가 있습니다.
Azure Functions는 .NET 팀이나 이미 Azure 엔터프라이즈 계약을 쓰는 조직에 강점이 있습니다. 반대로 마이크로소프트 생태계 바깥에서는 선택할 이유를 찾기 어렵고, 소비 플랜의 콜드스타트는 대체로 Lambda보다 느린 편입니다.
그래서 2026년 들어 자리 잡은 패턴이 하이브리드 서버리스입니다. 엣지의 Cloudflare Workers에서 요청 검증과 캐싱을 빠르게 처리하고, 무거운 작업은 EventBridge를 거쳐 AWS Lambda로 넘기는 식인데요. 각 플랫폼의 장점만 골라 쓰는 구성입니다. 이런 엣지 분산 구조는 엣지 컴퓨팅과 맞닿아 있어, 함께 설계하면 효과가 큽니다.
2026 서버리스 도입 실전 가이드
처음 도입한다면 한 번에 전부 옮기지 말고 단계적으로 접근하는 편이 안전합니다. 초보 조직도 따라 할 수 있게 네 단계로 정리했습니다.
1단계, 후보 워크로드 고르기. 트래픽이 불규칙하거나, 이벤트로 깔끔하게 쪼갤 수 있는 작업부터 시작합니다. 이미지·파일 처리, 알림 발송, 정기 배치, 웹훅 수신 같은 게 좋은 출발점인데요. 24시간 일정하게 높은 부하가 걸리는 핵심 서비스는 후순위로 미룹니다.
2단계, 작은 파일럿으로 검증하기. 하나의 기능을 FaaS로 옮겨 콜드스타트 지연과 실제 비용을 측정합니다. 이때 함수 단가만 보지 말고 게이트웨이·로그·데이터 전송까지 합친 총비용을 꼭 확인해야 합니다. 첫 청구서에서 놀라지 않으려면 이 단계가 중요합니다.
3단계, 지연과 비용 다듬기. 사용자 앞단 API라면 프로비저닝된 동시성이나 SnapStart로 콜드스타트를 잡습니다. 로그 보존 기간 조정, 메모리 실측 최적화로 비용을 깎습니다. 모니터링 도구를 붙여 어느 함수가 느린지, 어디서 돈이 새는지 눈으로 봐야합니다.
4단계, 거버넌스와 확장. 함수가 수십 수백 개로 늘면 권한·비밀키 관리, 배포 자동화, 비용 책임 분배가 과제가 됩니다. 이 시점에 FinOps와 플랫폼 엔지니어링 관점을 결합하면 운영이 한결 수월해집니다.
기존 방식에서는 인프라 팀이 서버 증설을 승인하고 며칠을 기다렸습니다. 새 방식에서는 개발자가 함수를 올리는 즉시 트래픽에 맞춰 알아서 확장됩니다. 변화된 결과는 명확합니다. 출시 속도가 빨라지고, 안 쓰는 시간의 비용이 사라지며, 운영 부담이 클라우드로 넘어갑니다. 다만 그 대가로 벤더 종속과 디버깅 복잡성이라는 새 숙제를 안게 되는데요, 도입 전 이 트레이드오프를 분명히 인식하는 게 좋습니다.