서버리스 콜드 스타트란?

콜드 스타트는 서버리스 플랫폼이 코드를 실행하기 전에 새 환경을 생성하고 초기화해야 할 때 치르는 지연 시간 비용입니다. 버그가 아니라 과금 구조의 대가입니다. 0으로 축소란 유휴 환경이 회수되어 유휴 상태에서는 비용이 들지 않는다는 뜻이고, 회수 이후의 첫 요청이 그 설정 비용을 치릅니다. 단계, 실제 수치, 완화 사다리를 이해하면 콜드 스타트는 막연한 두려움이 아니라 비용을 따져 내리는 엔지니어링 결정이 됩니다.

핵심 요약

다섯 단계와 단계별 소요 시간

콜드 스타트                                             일반적인 비용
1  샌드박스 할당 (마이크로 VM / 컨테이너)               ~50–100 ms
2  배포 패키지 다운로드                                 50–500 ms     ← 번들 크기에 비례
3  언어 런타임 부팅                                     50–1,000 ms   ← 인터프리터는 빠르고 VM은 느림
4  사용자 초기화 코드 (import, SDK 클라이언트, DB 연결) 0 ms–수 초    ← 직접 쥐고 있는 가장 큰 레버
5  핸들러 호출                                          실제 작업

웜 스타트 = 5단계만 (+ ~1–10 ms 해동). 환경은 파괴된 것이 아니라
동결된 것이므로 핸들러 밖의 연결과 캐시는 살아남으며,
초기화 규율이 이후의 모든 요청에서 보답하는 이유가 바로 이것입니다.

직접 측정해 볼 만한 비교 대상은 상시 실행되는 백엔드 위의 함수입니다. 이 경우 초기화를 기다리는 경쟁 자체가 일어나지 않습니다.

// JavaScript / Node.js — Back4app JS SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
const t0 = Date.now();
const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' });
console.log(`Round trip: ${Date.now() - t0} ms`); // consistent p50 ≈ p99
// The FaaS mitigations (warmers, provisioned capacity, bundle diets)
// don't apply here: the process serving this call was already running.

// Flutter / Dart — Back4app Flutter SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
final t0 = DateTime.now();
final response = await ParseCloudFunction('averageStars')
    .execute(parameters: {'movie': 'Arrival'});
print('Round trip: ${DateTime.now().difference(t0).inMilliseconds} ms');
// Consistent p50 ≈ p99: the process serving this call was already running.

// iOS / Swift — Back4app Swift SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
let t0 = Date()
let avg: Double = try await Cloud.run(name: "averageStars",
                                      parameters: ["movie": "Arrival"])
print("Round trip: \(Int(Date().timeIntervalSince(t0) * 1000)) ms")
// Consistent p50 ≈ p99: the process serving this call was already running.

// Android / Kotlin — Back4app Android SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
val t0 = System.currentTimeMillis()
val avg = ParseCloud.callFunction<Double>(
    "averageStars", mapOf("movie" to "Arrival"))
println("Round trip: ${System.currentTimeMillis() - t0} ms")
// Consistent p50 ≈ p99: the process serving this call was already running.

콜드 vs. 웜 스타트

얼마나 오래, 얼마나 자주 – 솔직하게

지속 시간은 대부분 런타임과 번들에 좌우됩니다. 인터프리터 런타임(JavaScript, Python)은 보통 200–400ms, 컴파일 런타임(Go, Rust)은 약 100–300ms 미만, VM 기반(JVM, .NET)은 500ms에서 수 초이며 스냅샷 복원 기능이 JVM 수치를 극적으로 줄입니다. p99는 중앙값의 2–3배이고, 비대한 의존성 트리는 언어와 무관하게 시작 시간을 몇 배로 늘리며, hello-world 벤치마크가 각 런타임의 기준선을 보여 줍니다. 빈도는 대부분의 설명이 절반만 말하는 지점입니다. 꾸준한 프로덕션 트래픽에서는 호출의 1% 미만에서 콜드 스타트가 발생합니다. 안심되는 수치이고 사실입니다. 그러나 드문 트래픽에서는 계산이 뒤집힙니다. Mike Roberts의 산술에 따르면 한 시간에 한 번 호출되는 함수는 사실상 매번 콜드 스타트를 겪고, 개발 환경의 콜드 비율은 30–90%에 이릅니다. 그리고 모두가 잊는 트리거가 동시성 스케일 아웃입니다. 요청 열 개가 도착했는데 웜 환경이 세 개뿐이면 일곱 개가 동시에 콜드 스타트를 겪습니다. 트래픽 급증의 한가운데, 정확히 가장 아픈 순간에 말입니다.

가격이 매겨진 완화 사다리

비용 순서로, 가장 저렴한 것부터입니다. 무료, 코드 수준: 배포 번들을 줄이고 의존성을 정리합니다. 대부분의 팀이 아직 손대지 않은 가장 효과적인 수단입니다. 사용하는 SDK 하위 모듈만 import하고, 드문 코드 경로에서만 쓰는 무거운 모듈은 지연 로딩하며, 데이터베이스 연결은 웜 스타트가 재사용하도록 초기화 범위에서 엽니다. 저렴, 설정: 메모리를 늘립니다(CPU가 함께 늘어나며, VM 런타임에서는 체감할 만큼 늘어납니다). 플랫폼이 제공한다면 스냅샷 복원을 켭니다. 불안정, 민간요법: 킵 워밍 핑입니다. 몇 분마다 보내는 예약 요청은 환경 하나를 웜 상태로 유지할 뿐 스케일 아웃에는 아무 소용이 없습니다. 솔직히 말해 레거시 편법입니다. 유료, 결정적: 사전 프로비저닝된 용량(“프로비저닝된 동시성”, “최소 인스턴스”)입니다. N개의 환경이 항상 초기화되어 있어 N까지는 콜드 스타트가 사라지지만, 사용량 기반 과금을 부분적으로 상쇄하는 상시 가동 가격이 붙습니다. 이 아이러니는 짚고 넘어갈 만합니다. 서버리스의 대표적인 문제에 대한 해법이, 없다고 약속받았던 바로 그 서버를 되사는 것입니다.

아이솔레이트: 엣지 런타임이 콜드 스타트를 우회하는 방법

엣지 플랫폼은 환경을 워밍하는 대신 아키텍처를 바꿔 0에 가까운 콜드 스타트를 보고합니다. 테넌트마다 컨테이너나 마이크로 VM을 부팅하는 대신, 오래 실행되는 프로세스 하나 안에서 브라우저 탭과 비슷한 샌드박스인 V8 아이솔레이트 수천 개를 실행합니다. 아이솔레이트 컨텍스트를 생성하는 비용은 수백 밀리초와 런타임 부팅이 아니라 한 자릿수 밀리초와 메가바이트 단위입니다. 대신 실행 환경에 제약이 따릅니다. 웹 표준 API의 부분집합만 쓸 수 있고, CPU 상한이 엄격하며, 파일시스템이 없습니다. 공짜 업그레이드가 아니라 다른 도구이며, 엣지 항목에서 솔직하게 다룹니다.

콜드 스타트가 중요한 일반적인 사용 사례

• 대화형 API – 사람이 스피너를 보고 있으며, p99에는 콜드 꼬리가 포함됩니다.
• 결제와 체크아웃 – 지연 시간에 민감하며, 지연이 곧 전환율 손실로 이어집니다.
• 로그인과 세션 발급 – 첫인상 경로이며, 유휴 기간 뒤에 오는 경우가 많습니다.
• 드문 트래픽의 엔드포인트 – 거의 모든 호출이 콜드인 관리자 도구와 내부 API.
• 중요하지 않은 곳: 큐에 쌓이는 작업, 웹훅, 예약 작업. 비동기는 꼬리를 보이지 않게 흡수합니다.

콜드 스타트를 최적화해야 할까? 결정 매트릭스

한계와 트레이드오프

• 완화책은 돈과 지연 시간을 맞바꿉니다. 사전 워밍된 용량은 고정 청구서입니다. 플랫폼 전체가 아니라 엔드포인트 단위로 결정해야 합니다.
• 워머는 대시보드를 속입니다. 핑을 받는 함수는 건강해 보이지만, 실제 트래픽 급증마다 스케일 아웃은 여전히 콜드 스타트를 겪습니다.
• 초기화 절약에는 한계가 있습니다. 공격적인 지연 로딩은 지연 시간을 콜드 스타트에서 첫 사용 경로로 옮길 뿐입니다. 어디로 옮겼는지 측정해야 합니다.
• 벤치마크는 빨리 낡습니다. 런타임 순위와 플랫폼 수치는 해마다 바뀌고, 오래된 수치(와 고쳐진 지 오래된 네트워킹 페널티)가 여전히 떠돕니다. 데이터에 날짜를 달아야 합니다.
• 중요한 것은 우리 서비스의 지표입니다. 콜드 비율 통계는 다른 누군가의 트래픽을 설명할 뿐입니다. 프로덕션과 유사한 부하에서 직접 측정한 p99만이 지출을 정당화합니다.

Back4app에서의 콜드 스타트

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Back4app에는 아키텍처상 콜드 스타트가 아예 존재하지 않습니다. Cloud Code는 상시 실행되는 백엔드 안에서 동작하므로 0에서 확장하는 순간 자체가 없습니다. 초기화 경쟁도, 관리할 웜 풀도, 프로비저닝 용량 청구 항목도 없으며, 코드 탭의 측정 결과가 그 덕분에 얻는 이점을 보여 줍니다. 하루의 첫 요청에서도 백만 번째 요청에서도 p50과 p99가 서로 가까이 붙어 있습니다. 그 트레이드오프는 BaaS vs. 서버리스에서 이름 붙인 바로 그것입니다. 호출 단위 과금의 세밀함을 포기하는 대신 일정한 지연 시간과 연결된 데이터베이스를 얻으며, 사용자를 마주하는 앱 백엔드에서는 보통 그쪽이 사용자가 체감할 수 있는 쪽입니다.