Lambda 콜드 스타트 대책: 프로비저닝드 동시성의 비용 판단

Lambda의 콜드 스타트는 서버리스를 선택할 때 가장 자주 나오는 걱정거리입니다. 결론을 먼저 적으면, 대부분의 워크로드는 무료 대책(패키지 축소, 경량 런타임, SnapStart)으로 충분하고, 프로비저닝드 동시성은 p99 지연 요구가 명확한 사용자 대면 경로에만 계산해 보고 겁니다. 프로비저닝드 동시성은 흔히 비싼 보험으로 알려져 있지만, 실행 단가가 온디맨드보다 낮게 설계되어 있어 사용률이 높으면 오히려 총액이 싸지는 역전 구간이 있습니다. Lambda 자체의 선택 기준은 Lambda vs Fargate에서 다뤘습니다. 요금은 us-east-1 기준입니다.

한눈에 보는 대책 비교 #

콜드 스타트의 구조: 어디서 시간이 가는가 #

Lambda는 요청이 왔는데 놀고 있는 실행 환경이 없으면 새 환경을 만듭니다. 이때 코드 다운로드, 런타임 기동, 핸들러 밖 초기화 코드 실행이 순서대로 일어나고, 이 초기화 단계가 콜드 스타트 지연의 본체입니다. 짧으면 100ms 안쪽, 무거운 프레임워크를 얹은 Java나 .NET이면 수 초까지 늘어납니다.

중요한 것은 발생 빈도입니다. 콜드 스타트는 첫 요청, 트래픽이 늘어 동시 실행이 확장될 때, 배포 직후에 발생합니다. 상시 트래픽이 있는 함수라면 전체 호출의 1% 미만이 콜드 스타트인 경우가 많으므로, 평균 지연이 아니라 p99가 문제인지부터 확인해야 합니다. 내부 배치 처리나 비동기 이벤트 소비라면 수 초의 콜드 스타트는 문제조차 아닙니다.

돈을 쓰기 전의 기본기는 세 가지입니다. 배포 패키지와 의존성을 줄여 다운로드·초기화를 짧게 만들고, 핸들러 밖 초기화 코드(SDK 클라이언트 생성, 설정 로드)를 꼭 필요한 것만 남기고, 초기화가 CPU 병목이면 메모리를 올려 비례 배정되는 CPU를 늘립니다. SnapStart는 초기화가 끝난 스냅샷을 미리 떠 두고 복원하는 방식으로, Java는 추가 요금 없이 켤 수 있어 Java 함수라면 첫 번째로 시도할 대책입니다. Python과 .NET도 지원하지만 스냅샷 캐시 보관과 복원에 과금되므로 호출량이 많은 함수에서는 요금을 확인하고 켭니다.

프로비저닝드 동시성의 요금 구조: 이중 단가 #

프로비저닝드 동시성(Provisioned Concurrency)은 지정한 수만큼 실행 환경을 초기화 완료 상태로 상시 유지하는 기능입니다. 요금은 두 축입니다.

• 유지 요금: 프로비저닝한 용량에 대해 GB-초당 $0.0000041667이 실행 여부와 무관하게 나갑니다. 메모리 1GB 함수 1개 동시성을 한 달 내내 유지하면 약 $11입니다.
• 실행 요금: 프로비저닝된 환경에서 실행된 시간은 GB-초당 $0.0000097222로, 온디맨드 단가($0.0000166667)의 약 58%입니다.

실행 단가가 낮다는 점이 핵심입니다. 프로비저닝한 용량이 놀고 있으면 유지 요금이 순손해지만, 사용률이 올라가면 실행 요금 할인이 유지 요금을 상쇄합니다. 유지+실행 합계와 온디맨드 요금이 같아지는 지점은 사용률 약 60%입니다. 상시 트래픽이 프로비저닝 용량의 60%를 넘겨 돌고 있다면, 콜드 스타트 제거는 공짜가 아니라 절감과 함께 옵니다. 반대로 사용률 10%라면 콜드 스타트 제거에 유지 요금 대부분을 그대로 내는 셈입니다.

계산 예를 하나 적으면, 1GB 함수에 동시성 10을 한 달 유지하면 유지 요금 약 $110입니다. 이 용량이 평균 70%로 돌면 실행 요금은 온디맨드 대비 약 $89 절감되어 순비용이 약 $21로 줄고, 평균 20%로 돌면 절감이 약 $25뿐이라 순비용 약 $85를 콜드 스타트 제거 비용으로 내는 구조입니다.

두 가지 운영 잔가지가 있습니다. 프로비저닝 용량을 넘는 트래픽은 온디맨드로 넘쳐 흐르며 그 부분은 콜드 스타트가 다시 생깁니다. 그리고 Application Auto Scaling으로 시간대 스케줄을 걸 수 있으므로, 업무 시간에만 유지하면 유지 요금을 3분의 1로 줄일 수 있습니다. 야간 트래픽이 없는 사내 API라면 스케줄링이 기본입니다.

참고로 EventBridge로 몇 분마다 함수를 찔러 두는 웜업 방식은 환경 1개만 데워 둘 뿐 동시 요청이 오면 바로 콜드 스타트가 나므로, 프로비저닝드 동시성의 대체가 되지 않습니다.

판단 순서 #

1. p99가 문제인지부터 확인합니다: CloudWatch에서 초기화 시간과 발생 비율을 봅니다. 비동기·배치 경로라면 콜드 스타트는 대책 없이 수용하는 것이 정답입니다.
2. 무료 대책을 먼저 소진합니다: 패키지 축소, 초기화 코드 정리, Java면 SnapStart까지. 여기서 p99가 요구 안으로 들어오면 끝입니다.
3. 프로비저닝드 동시성은 용량과 사용률을 계산하고 겁니다: 필요한 동시성은 피크 동시 실행 수에서 잡고, 예상 사용률 60%를 기준으로 온디맨드와 총액을 비교합니다.
4. 스케줄로 유지 시간을 줄입니다: 트래픽 패턴이 명확하면 Auto Scaling 스케줄로 야간·주말 유지 요금을 지웁니다.
5. 상시 고트래픽이면 아키텍처 재검토와 병행합니다: 사용률이 항상 높다면 프로비저닝드 동시성이 절감이 되지만, 그 규모라면 Fargate 상시 컨테이너와의 비교도 다시 성립합니다.

정리 #

• 콜드 스타트의 본체는 초기화 단계입니다. 발생 비율은 보통 전체 호출의 1% 미만이므로, 평균이 아니라 p99 요구가 있는지부터 확인합니다.
• 무료 대책(패키지 축소, 초기화 정리, Java SnapStart)이 1순위입니다. Python·.NET의 SnapStart는 캐시·복원 과금을 확인하고 켭니다.
• 프로비저닝드 동시성은 유지 GB-초당 $0.0000041667에 실행 단가는 온디맨드의 약 58%인 이중 구조입니다. 사용률 약 60%가 손익 분기입니다.
• 사용률이 낮으면 유지 요금이 콜드 스타트 제거 비용이 되고, 스케줄링으로 그 비용을 줄입니다. 웜업 호출은 동시 요청에 무력해 대체가 되지 않습니다.
• API 앞단 구성(요금 구조가 다른 API Gateway와 ALB)은 다음 글에서 이어집니다.