127. 서버리스·FaaS 아키텍처 (Serverless / FaaS Architecture)

핵심 인사이트 (3줄 요약)

본질: 서버리스 아키텍처 (Serverless Architecture) / FaaS (Function as a Service, 서비스형 함수)는 인프라 프로비저닝·관리 없이 함수 코드만 배포하면, 트리거 이벤트(HTTP 요청, 메시지, 스케줄) 발생 시 클라우드 플랫폼이 동적으로 컨테이너를 스핀업하여 코드를 실행하고, 완료 후 자동 스케일-투-제로(Scale-to-Zero)하는 실행 모델이다.

가치: 서버 관리·용량 계획이 불필요하고 실제 실행 시간·호출 수에 비례한 과금으로 유휴 자원 비용이 사라지며, 이벤트 기반 자동 확장으로 트래픽 급증에도 수동 개입 없이 대응한다.

판단 포인트: 콜드 스타트(cold start) 지연, 최대 실행 시간 제한(AWS Lambda 15분), 스테이트리스(stateless) 강제가 서버리스의 핵심 한계이므로, 빠른 응답이 필수인 실시간 API나 장기 실행 작업에는 적합하지 않다.

Ⅰ. 개요 및 필요성

서버리스라는 용어는 '서버가 없는 것'이 아니라 '개발자가 서버를 관리하지 않는 것'을 의미한다. 클라우드 제공자(AWS Lambda, Google Cloud Functions, Azure Functions)가 서버 프로비저닝, 패치, 확장을 모두 처리한다.

전통적 서버 기반 아키텍처에서는 항상 서버가 실행 중이어야 하므로 유휴 시간에도 비용이 발생한다. 서버리스는 코드가 실행될 때만 과금하는 이벤트 기반 실행 모델로, 비용 구조를 근본적으로 바꿔놓는다.

┌─────────────────────────────────────────────────────────────┐
│         서버리스 실행 흐름                                    │
├─────────────────────────────────────────────────────────────┤
│  트리거 이벤트 발생                                          │
│  (HTTP 요청, S3 업로드, Kafka 메시지, 스케줄)               │
│       │                                                     │
│       ▼                                                     │
│  클라우드 플랫폼: 컨테이너 스핀업 (콜드 스타트: 수백ms~수초) │
│       │                                                     │
│       ▼                                                     │
│  함수 코드 실행 (최대 15분, AWS Lambda 기준)                 │
│       │                                                     │
│       ▼                                                     │
│  실행 완료 → 컨테이너 종료 (Scale-to-Zero)                  │
│                                                             │
│  과금: 실행 시간(ms) × 메모리 크기 × 호출 횟수              │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 택시 대신 우버(Uber)를 사용하는 것과 같다. 택시를 항상 대기시키면(서버 상시 운영) 유휴 시간에도 비용이 발생하지만, 필요할 때만 호출하면(서버리스) 탑승 시간만 비용을 낸다.

Ⅱ. 아키텍처 및 핵심 원리

서버리스의 핵심 설계 원칙은 스테이트리스 함수, 단일 책임, 이벤트 기반 구성이다. 각 함수는 상태를 보유하지 않으며, 상태는 외부 스토리지(DynamoDB, S3, Redis)에 저장한다. 함수 간 직접 호출 대신 이벤트 버스(EventBridge, SNS/SQS)를 통한 비동기 연결을 권장한다.

항목	설명	포인트
인프라 관리	불필요 (클라우드 관리)	필요 (클러스터 운영)
확장	자동 (요청별)	반자동 (HPA 설정)
콜드 스타트	있음 (수백ms~수초)	없음 (항상 실행)
비용	실행 시간 비례	예약 자원 비례
상태 관리	외부 스토리지 필수	내부·외부 모두 가능

┌─────────────────────────────────────────────────────────────┐
│       서버리스 아키텍처 구성 예시 (AWS)                       │
├─────────────────────────────────────────────────────────────┤
│  API Gateway → Lambda (비즈니스 로직)                        │
│                    │                                        │
│              DynamoDB (상태 저장)                           │
│                    │                                        │
│              SNS/SQS → Lambda (비동기 처리)                 │
│                    │                                        │
│              S3 (파일 저장) → Lambda (이벤트 트리거)         │
└─────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 전기 콘센트처럼 필요할 때만 플러그를 꽂으면 전기(컴퓨팅 자원)가 공급된다. 플러그를 빼면 전기 소비가 즉시 멈춘다. 발전소(클라우드)는 항상 준비되어 있지만 요금은 사용한 만큼만 낸다.

Ⅲ. 비교 및 연결

서버리스는 모든 상황에 최적이 아니므로, 적합한 워크로드와 부적합한 워크로드를 명확히 구분하는 것이 핵심 판단이다.

비교 축	A	B
실행 패턴	간헐적, 이벤트 기반	상시 실행, 지속적 스트리밍
실행 시간	수초~수분 이내	장시간 실행(>15분)
응답 요구	비동기, 배치 처리	실시간 초저지연
비용 특성	간헐적 트래픽	항상 높은 트래픽
예시	이미지 처리, 웹훅, 데이터 변환	실시간 게임 서버, HPC

📢 섹션 요약 비유: 배달 음식(서버리스)은 주문할 때만 비용이 발생하지만, 대가족이 매일 세 끼를 먹는다면 요리사를 상주(항상 실행 서버)시키는 것이 더 효율적이다.

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

콜드 스타트 최소화는 서버리스 성능 최적화의 핵심 과제다. 함수 실행 빈도를 높여 웜(warm) 상태를 유지하거나, AWS Lambda Provisioned Concurrency로 미리 워밍업된 인스턴스를 예약하는 방식을 사용한다. 함수 크기 최소화와 의존성 최적화도 콜드 스타트 단축에 효과적이다.

판단 체크리스트

워크로드가 간헐적이고 이벤트 기반인가? (서버리스 최적 조건)
최대 실행 시간이 플랫폼 한계(15분) 이내인가?
콜드 스타트 지연이 사용자 경험에 허용 가능한 수준인가?
함수가 스테이트리스하게 설계되었으며 상태는 외부 스토리지에 저장하는가?
벤더 종속(vendor lock-in) 위험을 완화하기 위한 이식 계층이 있는가?

📢 섹션 요약 비유: 도서관에서 사서(서버)를 항상 배치하는 대신, 셀프 대출 키오스크(서버리스)를 설치하면 이용자가 있을 때만 기계가 작동한다.

Ⅴ. 기대효과 및 결론

서버리스는 인프라 관리 부담 제거, 자동 확장, 사용량 기반 비용으로 스타트업과 간헐적 워크로드에서 탁월한 경제성을 제공한다. 배포 단순성 덕분에 개발자가 비즈니스 로직에만 집중할 수 있어 개발 속도가 향상된다.

한계는 콜드 스타트, 실행 시간 제한, 상태 관리 복잡성, 벤더 종속, 디버깅 어려움이다. 서버리스 함수가 너무 많아지면 관리와 모니터링이 복잡해지는 '함수 스프롤(function sprawl)' 문제도 있다.

미래 방향으로는 ① WebAssembly 기반 서버리스로 콜드 스타트 밀리초 수준 감소, ② WASI (WebAssembly System Interface)를 통한 벤더 독립 서버리스, ③ AI 추론 서버리스 함수 최적화가 주목받고 있다.

📢 섹션 요약 비유: 공용 세탁기(서버리스)는 필요할 때만 사용하고 사용한 만큼만 비용을 내지만, 세탁량이 매우 많은 가정은 개인 세탁기(전용 서버)를 갖추는 것이 더 효율적이다.

📌 관련 개념 맵

[클라우드 컴퓨팅 진화] → [FaaS·서버리스] → [이벤트 기반 실행] → [자동 확장] → [Wasm 기반 초경량 서버리스]

개념	연결 포인트
FaaS (Function as a Service)	서버리스 아키텍처의 핵심 실행 모델
이벤트 주도 아키텍처(EDA)	서버리스 함수를 트리거하는 이벤트 기반 구조
API 게이트웨이	HTTP 트리거로 서버리스 함수를 호출하는 진입점
WebAssembly (Wasm)	콜드 스타트 감소를 위한 차세대 서버리스 런타임

📈 관련 키워드 및 발전 흐름도

[서버 상시 운영 비용 문제] → [PaaS] → [컨테이너·Kubernetes] → [FaaS·서버리스] → [Wasm 초경량] → [AI 추론 서버리스]

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

서버리스는 불을 켤 때만 전기 요금을 내는 것처럼, 함수가 실행될 때만 비용이 발생해요.
서버를 직접 관리하지 않아도 되니까 개발자는 코드 작성에만 집중할 수 있어요.
하지만 처음 불을 켤 때 약간의 준비 시간(콜드 스타트)이 필요해요!