206. 서버리스 및 콜드 스타트 (Serverless & Cold Start)

핵심 인사이트

본질: 서버리스(Serverless)는 개발자가 서버 인프라를 관리하지 않고 비즈니스 로직 코드만 작성하면 되는 아키텍처 패러다임이며, FaaS (Function as a Service, 서비스로서의 함수)가 그 핵심 구현 방식이다. "서버가 없는 것"이 아니라 "서버 관리가 없는 것"이 본질이다.

가치: 이벤트 발생 시에만 과금하는 완전한 종량제(Pay-per-Use) 모델로 유휴 비용을 제거하고, 자동 스케일링이 0에서 수천 동시 실행까지 즉시 대응하여 운영 부담을 최소화한다.

판단 포인트: 기술사 시험에서는 콜드 스타트(Cold Start) 문제의 원인·영향·극복 전략, 서버리스 아키텍처의 적합/부적합 워크로드 구분, 그리고 상태 관리(Stateless) 제약을 어떻게 극복하는지 논리적으로 서술해야 한다.

Ⅰ. 개요 및 필요성

전통적인 클라우드 아키텍처에서도 서버(VM이나 컨테이너)를 항상 실행 상태로 유지해야 했다. 트래픽이 없는 새벽에도 EC2 인스턴스가 돌아가고, 비용이 지속 발생한다. 서버리스 아키텍처는 이 비효율을 근본적으로 해결한다. 이벤트(HTTP 요청, 파일 업로드, 데이터베이스 변경 등)가 발생할 때만 함수를 실행하고, 실행이 끝나면 즉시 자원을 반납하여 비용이 제로가 된다.

AWS Lambda가 2014년 서버리스 패러다임을 대중화한 이후, Azure Functions·GCP Cloud Functions·Cloudflare Workers 등의 경쟁 서비스가 등장하였다. 서버리스는 단순한 API 핸들러를 넘어서, 이벤트 드리븐 데이터 처리·스케줄 작업·IoT 데이터 수집·AI 추론 API 등 다양한 패턴으로 활용된다.

그러나 서버리스에는 고유한 제약이 있다. 가장 대표적인 것이 콜드 스타트(Cold Start) 문제다. 함수가 오랫동안 호출되지 않으면 인스턴스가 종료되고, 다음 요청 시 새 인스턴스를 초기화하는 시간(수백 ms~수 초)이 소요된다. 지연 시간에 민감한 서비스에서는 이것이 심각한 UX 저하 요인이 된다.

📢 섹션 요약 비유: 서버리스는 택시 대신 앱 호출 서비스다. 필요할 때만 호출하면 와서(함수 실행) 비용을 내고, 탑승 안 할 때는 돈이 안 나간다. 단, 오랜만에 호출하면 차가 잠깐 준비하는 시간(콜드 스타트)이 걸린다.

Ⅱ. 아키텍처 및 핵심 원리

2-1. 서버리스 실행 모델 및 콜드 스타트

┌──────────────────────────────────────────────────────────────────────┐
│                  서버리스 함수 수명 주기 (Life Cycle)                  │
├──────────────────────────────────────────────────────────────────────┤
│  이벤트 발생                                                          │
│       │                                                               │
│       ▼                                                               │
│  ┌────────────────────────────────────┐                              │
│  │    콜드 스타트 (Cold Start) 단계    │ ← 오랫동안 미호출 시 발생    │
│  │  1. 컨테이너 초기화    (~50ms)     │                              │
│  │  2. 런타임 로드        (~100ms)    │                              │
│  │  3. 핸들러 초기화      (~200ms)    │                              │
│  │  합계: 수백ms ~ 수 초 지연         │                              │
│  └────────────────────────────────────┘                              │
│       │                                                               │
│       ▼                                                               │
│  ┌────────────────────────────────────┐                              │
│  │    웜 스타트 (Warm Start) 단계      │ ← 인스턴스 재사용 시         │
│  │  기존 컨테이너 즉시 재사용 (~1ms)  │                              │
│  └────────────────────────────────────┘                              │
│       │                                                               │
│       ▼                                                               │
│  ┌────────────────────────────────────┐                              │
│  │         함수 실행 (Execution)       │                              │
│  │  비즈니스 로직 처리                 │                              │
│  └────────────────────────────────────┘                              │
│       │                                                               │
│       ▼                                                               │
│  일정 시간(~15분) 미호출 → 인스턴스 소멸 → 다음 호출 시 콜드 스타트   │
└──────────────────────────────────────────────────────────────────────┘

2-2. AWS Lambda 주요 제약 사항

항목	제약	영향
최대 실행 시간	15분	장시간 배치 처리 부적합
메모리	128MB ~ 10GB	대용량 메모리 작업 한계
임시 스토리지 (/tmp)	최대 10GB	로컬 파일 처리 제한
동시 실행 한도	계정별 기본 1,000	대규모 동시 처리 시 스로틀링
패키지 크기	50MB(직접), 250MB(S3)	대용량 라이브러리 제한

📢 섹션 요약 비유: 콜드 스타트는 오랫동안 안 쓰던 차의 시동 거는 시간이다. 매일 타는 차(웜 스타트)는 바로 출발하지만, 주차장에 오래 세워둔 차는 시동이 걸리는 데 잠깐 시간이 걸린다.

Ⅲ. 비교 및 연결

3-1. 서버리스 vs. 컨테이너(K8s) vs. VM 비교

구분	서버리스 (FaaS)	컨테이너 (K8s)	VM (IaaS)
관리 단위	함수 (코드)	컨테이너 이미지	가상 머신
스케일링	즉시 자동 (0→∞)	자동 (HPA)	수동/자동
콜드 스타트	있음 (수백ms~초)	적음 (수 초)	없음 (항상 실행)
비용 모델	실행 시간 × 메모리	노드 실행 시간	VM 실행 시간
유휴 비용	없음	있음 (최소 노드)	있음
최대 실행 시간	15분 (Lambda)	무제한	무제한
상태 관리	무상태(Stateless) 필수	선택적	선택적

3-2. 콜드 스타트 극복 전략

전략	설명	효과
Provisioned Concurrency (사전 프로비저닝)	지정된 수의 인스턴스를 항상 웜 상태로 유지	콜드 스타트 완전 제거 (추가 비용 발생)
런타임 최적화	경량 런타임 선택 (Python > Java/JVM)	초기화 시간 단축
패키지 경량화	불필요한 의존성 제거, Lambda Layers 활용	패키지 로드 시간 단축
정기 워밍업	CloudWatch Events로 주기적 함수 호출	인스턴스 소멸 방지
SnapStart (AWS)	JVM 스냅샷으로 초기화 시간 최소화	Java 콜드 스타트 90% 감소

3-3. 서버리스 적합/부적합 워크로드

적합 워크로드	부적합 워크로드
이벤트 드리븐 API (간헐적 트래픽)	지연 시간 < 50ms 실시간 서비스
파일 처리 (S3 업로드 트리거)	15분 초과 장시간 배치 작업
스케줄 작업 (주기적 데이터 수집)	지속적 WebSocket·TCP 연결
데이터 변환·ETL 파이프라인	상태 유지(Stateful) 워크로드
챗봇·AI 추론 API	예측 불가한 메모리 집약적 처리

📢 섹션 요약 비유: Provisioned Concurrency는 택시를 미리 대기시켜 두는 것이다. 손님이 올 때 바로 탈 수 있어 기다림(콜드 스타트)이 없지만, 대기 시간 동안에도 약간의 비용이 발생한다.

Ⅳ. 실무 적용 및 기술사 판단

4-1. 서버리스 아키텍처 패턴

이벤트 드리븐 파이프라인: S3 파일 업로드 → Lambda 트리거 → 이미지 리사이징 → DynamoDB 저장 → SNS 알림 발송. 각 단계가 독립된 함수로 분리되어 장애가 격리되고 개별 확장이 가능하다.

API Gateway + Lambda: REST API 엔드포인트를 서버 없이 구현. API Gateway가 HTTP 요청을 받아 Lambda를 호출하고, 결과를 클라이언트에 반환한다. 간헐적 트래픽의 백엔드 API에 이상적이다.

4-2. 상태 관리 전략

서버리스 함수는 본질적으로 무상태(Stateless)여야 한다. 상태가 필요한 경우:

짧은 세션 상태: Redis (ElastiCache) 활용
영구 데이터: DynamoDB, RDS (Relational Database Service)
대규모 분산 상태: Step Functions (워크플로우 상태 관리)

4-3. 비용 최적화

Lambda 비용 = 요청 수 × 실행 시간 × 메모리 크기. ARM 아키텍처(Graviton2)를 선택하면 동일 성능에서 x86 대비 20% 비용 절감이 가능하다. 함수별 메모리를 최적화(너무 작으면 실행 시간 증가, 너무 크면 비용 낭비)하는 Power Tuning 도구 활용이 권장된다.

📢 섹션 요약 비유: 서버리스 상태 관리는 무인 편의점과 같다. 편의점(함수)은 손님이 오면 즉시 열리고 가면 닫히지만, 손님의 포인트 정보(상태)는 별도 서버(DB)에 저장된다. 편의점 자체는 항상 비어있다.

Ⅴ. 기대효과 및 결론

서버리스 아키텍처는 운영 복잡성을 최소화하고 비용 효율성을 극대화하는 강력한 패러다임이다. 특히 이벤트 드리븐 워크로드·마이크로서비스 배포·빠른 프로토타이핑에서 두드러진 가치를 발휘한다. 콜드 스타트 문제는 Provisioned Concurrency·런타임 최적화·패키지 경량화 등으로 충분히 제어 가능하며, 적절한 워크로드 선택이 성공적인 서버리스 도입의 핵심이다.

기술사 시험에서는 ① 서버리스의 본질(서버 관리 없음 ≠ 서버 없음), ② 콜드 스타트 원인·영향·극복 전략, ③ FaaS 제약 사항(실행 시간·상태·메모리), ④ 컨테이너·VM과의 비교를 체계적으로 서술하고, 실제 사용 사례와 연결해야 완성도 높은 답안이 된다.

📢 섹션 요약 비유: 서버리스는 "사용한 만큼만 내는 전기 요금제"다. 전등이 켜진 시간만큼만 내고, 꺼지면 0원이다. 단, 오랫동안 꺼져 있다가 켜면 스위치가 잠깐 반응이 느린 것(콜드 스타트)이 단점이다.

📌 관련 개념 맵

개념	설명	연관 키워드
서버리스	서버 관리 없이 코드 실행 패러다임	FaaS, 이벤트 드리븐
FaaS	Function as a Service, 함수 단위 실행	AWS Lambda, Azure Functions
Cold Start	함수 인스턴스 신규 초기화 지연	런타임 로드, 수백ms
Warm Start	기존 인스턴스 재사용 즉시 실행	성능 최적화
Provisioned Concurrency	사전 웜 인스턴스 유지 설정	콜드 스타트 제거
Event-Driven	이벤트 발생 시 함수 트리거	S3·API Gateway·SQS
Step Functions	서버리스 워크플로우 상태 관리 서비스	오케스트레이션
Stateless	함수 간 상태 미보유 원칙	Redis, DynamoDB 보완
Power Tuning	Lambda 메모리 최적화 도구	비용·성능 균형

👶 어린이를 위한 3줄 비유 설명

서버리스는 필요할 때만 켜지는 자판기야. 아무도 안 쓸 때는 꺼져 있어서 전기세(비용)가 안 나오고, 누군가 버튼을 누르면(이벤트) 바로 켜져서 음료를 줘.
콜드 스타트는 오랫동안 안 썼던 자판기를 다시 켤 때 잠깐 준비 시간이 걸리는 거야. 매일 쓰는 자판기(웜 스타트)는 바로 나오는데, 창고에 있던 자판기는 잠깐 기다려야 해.
Provisioned Concurrency는 "항상 준비된 자판기"를 유지하는 거야. 기다림은 없어지지만, 안 쓸 때도 약간의 전기세(비용)가 나온다는 게 트레이드오프야.