클라우드 비용 청구서를 열어본 순간, 예상보다 훨씬 높은 금액에 당황한 경험이 있을 것이다. 서버리스로 전환하면 비용이 줄어든다는 말을 믿고 마이그레이션했는데, 오히려 기존 컨테이너 환경보다 비용이 늘어난 사례도 적지 않다. 문제는 과금 구조를 제대로 이해하지 못한 채 아키텍처를 선택했기 때문이다.
이 글에서는 AWS Lambda, Azure Functions, Google Cloud Run 세 가지 서버리스 플랫폼의 과금 체계를 워크로드 패턴별로 비교하고, 컨테이너 기반 인프라 대비 손익분기점을 구체적인 수치로 산출한다. 끝까지 읽으면 자신의 워크로드에 맞는 플랫폼을 비용 근거를 갖추고 선택할 수 있게 된다.
서버리스 비용 폭탄은 왜 발생하는가
종량제의 함정
서버리스의 핵심 매력은 ‘쓴 만큼만 낸다’는 종량제 모델이다. 그런데 이 단순한 원칙이 실제로는 꽤 복잡하게 작동한다. 요청 수, 실행 시간, 할당 메모리, 네트워크 전송량이 각각 별도 과금 단위로 잡히기 때문이다.
실제 적용 사례를 살펴보면, 한 스타트업이 이미지 리사이징 함수를 Lambda에 올렸다가 월 50만 원이 넘는 청구서를 받았다. 함수 자체 비용은 미미했지만, S3 전송 비용과 API Gateway 요금이 전체의 70%를 차지했다. 함수 실행 비용만 계산하면 전체 그림을 놓친다.
트래픽 패턴이 비용을 결정한다
균일한 트래픽과 스파이크성 트래픽은 완전히 다른 비용 구조를 만든다. 하루 종일 초당 100건씩 꾸준히 들어오는 API라면, 서버리스보다 컨테이너가 거의 항상 저렴하다. 반대로 새벽에는 0건, 점심시간에 초당 5,000건이 몰리는 패턴이라면 서버리스가 압도적으로 유리하다. 트래픽 편차가 클수록 서버리스의 경제성이 올라간다는 원리다.
AWS Lambda·Azure Functions·Cloud Run 과금 구조의 근본적 차이
과금 단위부터 다르다
세 플랫폼 모두 종량제지만, 측정 방식이 제각각이다. Lambda는 1ms 단위로 실행 시간을 측정하고 요청당 $0.20/백만 건을 부과한다. Azure Functions 소비 플랜도 비슷한 구조이나, GB-초 단가가 Lambda보다 약 10% 저렴한 $0.000016/GB-초 수준이다. Cloud Run은 접근이 근본적으로 다르다. 컨테이너 인스턴스 단위로 CPU와 메모리를 초 단위 과금하며, 동시 요청을 하나의 인스턴스가 처리할 수 있어 요청당 비용 개념이 희석된다.
쉽게 비유하면 이렇다. Lambda와 Azure Functions는 택시 미터기처럼 탈 때마다 기본요금이 붙는 구조고, Cloud Run은 렌터카처럼 빌리는 시간 동안 얼마나 많이 굴려도 추가 요금이 없는 셈이다.
프리티어 비교
AWS Lambda 공식 요금 페이지에 따르면 월 100만 건 요청과 40만 GB-초가 무료다. Azure Functions는 월 100만 건과 40만 GB-초로 거의 동일하다. Cloud Run은 월 200만 건 요청, 36만 vCPU-초, 18만 GiB-초를 제공한다. 소규모 프로젝트라면 세 플랫폼 모두 무료 범위 안에서 운영할 수 있지만, 트래픽이 조금만 늘어도 과금 구조 차이가 극명해진다.
워크로드 패턴별 비용 시뮬레이션, 어떤 플랫폼이 유리한가
경량 API 호출 패턴
평균 실행 시간 100ms, 메모리 256MB, 월 500만 건 호출이라는 전형적인 REST API 시나리오를 가정해보자. Lambda 예상 비용은 약 $12.5(요청비 $1 + 컴퓨팅 $11.5)이다. Azure Functions 소비 플랜에서는 약 $11.2로 소폭 저렴하다. Cloud Run은 동시성 설정에 따라 크게 달라지는데, 동시 요청 80으로 설정하면 인스턴스 수가 줄어 약 $8~10 수준까지 내려간다.
반면 무거운 배치 작업은 양상이 달라진다. 실행 시간 30초, 메모리 1GB, 일 1만 건이면 Lambda 월 비용이 약 $75까지 올라간다. 이 구간에서는 Cloud Run의 최소 인스턴스 유지 방식이 오히려 비효율적이다.
고빈도 vs 저빈도, 갈림길
많은 사람이 처음에는 서버리스가 무조건 저렴하다고 생각한다. 하지만 월 1,000만 건을 넘기는 순간 이야기가 달라진다. Lambda 기준으로 월 5,000만 건(128MB, 200ms) 호출 시 약 $220이 발생하는데, 같은 워크로드를 ECS Fargate 0.25vCPU/0.5GB 인스턴스 2대로 처리하면 월 $15 내외에 해결된다. 열 배가 넘는 차이다. 핵심은 가동률이다. 서버가 80% 이상 가동되는 워크로드라면 컨테이너가 거의 항상 이긴다.
컨테이너 대비 서버리스 손익분기점, 정확히 어디인가
산출 공식
손익분기점 계산은 의외로 단순하다. 컨테이너 월 고정비용을 서버리스 건당 비용으로 나누면 된다. Fargate 최소 사양(0.25vCPU, 0.5GB) 기준 월 약 $7.5가 고정 비용이다. Lambda에서 128MB·200ms 함수의 건당 비용은 약 $0.0000042다.
$7.5 ÷ $0.0000042 ≈ 약 178만 건
월 호출이 178만 건 미만이면 Lambda가 저렴하고, 이를 초과하면 Fargate가 유리하다는 뜻이다. 물론 이건 단순 컴퓨팅 비용만 놓고 본 것이고, 운영 인건비나 CI/CD 복잡도, 모니터링 비용을 포함하면 분기점이 위로 올라간다. 손익분기점 개념을 정확히 이해하고 자사 워크로드에 맞는 변수를 대입하는 것이 중요하다.
운영 비용까지 포함한 총소유비용(TCO)
서버리스는 인프라 관리가 거의 없어 DevOps 인력 부담이 줄어든다. 컨테이너는 오토스케일링 설정, 헬스체크, 패치 관리 등 운영 오버헤드가 존재한다. 엔지니어 시급을 시간당 5만 원으로 잡으면, 주 5시간의 인프라 관리 시간만으로도 월 100만 원 이상의 암묵적 비용이 발생한다. 순수 인프라 비용만으로 판단하면 잘못된 결론에 도달할 수 있다.
서버리스 비용 최적화에서 반드시 주의할 점
과도한 메모리 할당의 역설
Lambda에서 메모리를 늘리면 CPU도 비례해서 올라간다. 256MB에서 15초 걸리던 함수가 512MB에서 7초로 줄어든다면, 총 GB-초가 오히려 감소해서 비용이 내려갈 수 있다. 그렇다고 무작정 메모리를 올리면 실행 시간 감소 효과가 체감되지 않는 구간에서 비용만 증가한다. AWS Lambda 메모리 설정 가이드를 참고해 Power Tuning 도구로 최적 메모리를 찾아야 한다.
예측 불가능한 비용 변수
콜드스타트가 잦으면 실행 시간이 늘어나 비용에 영향을 준다. 프로비저닝된 동시성을 설정하면 콜드스타트는 해결되지만, 유휴 시간에도 과금이 발생한다. 이건 마치 에어컨을 꺼놨다 켜면 전기를 많이 쓰니까 24시간 틀어놓자는 것과 비슷한 딜레마다. 워크로드 예측이 가능한 구간에서만 프로비저닝을 사용하고, 나머지는 콜드스타트를 허용하는 하이브리드 전략이 현실적이다.
모든 워크로드에 단일 플랫폼을 적용하는 것은 비효율적이다. API 게이트웨이 뒤의 경량 함수는 Lambda로, 장시간 실행되는 배치 작업은 Cloud Run이나 Fargate로 분리하는 혼합 아키텍처가 비용 최적화의 핵심이다.
최종 정리: 워크로드에 맞는 선택 기준
의사결정 프레임워크
결론부터 말하면 정답은 없다. 다만 판단 기준은 명확하다. 월 호출 200만 건 미만, 실행 시간 1초 이내, 트래픽 변동이 큰 워크로드라면 서버리스가 확실히 유리하다. 월 호출 1,000만 건 이상, 서버 가동률 70% 이상이라면 컨테이너로 전환하는 것이 비용을 줄인다.
- 스파이크 트래픽 + 경량 함수 → Lambda 또는 Azure Functions
- 동시성이 높은 웹 서비스 → Cloud Run (멀티 요청 처리로 인스턴스 효율 극대화)
- 균일 트래픽 + 장시간 실행 → ECS Fargate 또는 GKE
- 초기 스타트업, 트래픽 예측 불가 → 서버리스로 시작 후 성장에 따라 전환
플랫폼 선택보다 중요한 것
어떤 플랫폼을 고르든, 비용 모니터링 체계를 먼저 갖추는 게 순서다. AWS Cost Explorer, Azure Cost Management, GCP Billing Reports를 설정해 일 단위로 비용 추이를 확인하고, 임계값 알람을 걸어두어야 한다. 플랫폼 선택은 언제든 바꿀 수 있지만, 모니터링 없이 흘러간 비용은 돌아오지 않는다.
핵심 요약
서버리스 3사 플랫폼은 과금 단위와 동시성 모델이 다르므로 단순 단가 비교는 무의미하다. 컨테이너 대비 손익분기점은 워크로드에 따라 월 180만~500만 건 구간에서 형성되며, 운영 비용까지 포함하면 이 수치는 더 올라간다. 지금 당장 할 일은 현재 워크로드의 월간 호출 수와 평균 실행 시간을 측정하는 것이다. 이 두 숫자만 알면 위 공식으로 자사 환경의 손익분기점을 바로 산출할 수 있다.