6. FaaS (Function as a Service) 및 서버리스 아키텍처

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

1. 본질: 서버 인프라의 존재를 완벽히 추상화하고, 개발자가 작성한 비즈니스 로직(함수)을 이벤트 기반으로 실행하며 밀리초(ms) 단위로 자원을 동적 할당하는 클라우드 컴퓨팅 모델.
2. 가치: 유휴 자원 낭비 제로(Scale-to-Zero)와 무한한 자동 확장성(Auto Scaling)을 제공하여, 예측 불가능한 트래픽 스파이크 대응과 TCO(총소유비용) 절감에 극적인 효과를 발휘.
3. 융합: 마이크로서비스 아키텍처(MSA)의 극한 형태로, API Gateway, NoSQL, 비동기 메시지 큐 등 클라우드 네이티브 생태계와의 결합을 통해 진정한 이벤트 기반 아키텍처(EDA)를 완성.

Ⅰ. 개요 및 필요성 (Context & Necessity)

서버리스(Serverless)와 FaaS의 도래 FaaS (Function as a Service)는 클라우드 컴퓨팅의 진화 과정에서 IaaS와 PaaS가 가진 물리적/논리적 인프라 관리의 부담을 최종적으로 제거한 패러다임이다. 전통적인 서버 기반 아키텍처에서는 트래픽 피크를 대비해 항상 자원을 '과잉 프로비저닝(Over-provisioning)'해야만 했으며, 이는 평상시 막대한 유휴 자원 낭비로 이어졌다. 서버리스는 "서버가 없다"는 뜻이 아니라, "사용자가 직접 관리할 서버가 없다"는 의미로, 인프라 운영 책임을 클라우드 서비스 제공자(CSP)에게 100% 위임한다. 이로 인해 개발자는 운영체제 패치, 용량 계획, 로드 밸런싱에서 해방되어 핵심 비즈니스 로직에만 집중할 수 있게 되었다.

💡 비유: 마치 수도꼭지를 틀 때만 물이 나오고 쓴 양(밀리초)만큼만 요금을 내는 상수도 시스템과 같다. 물탱크(서버)를 직접 사서 옥상에 관리할 필요가 전혀 없다.

이 도식은 고정 자원을 할당하는 IaaS 환경과 요청에 따라 동적으로 자원이 매핑되는 FaaS 환경의 리소스 사용 패턴 한계를 대조하여 보여준다.

[자원 사용량 및 트래픽 타이밍 비교도]

트래픽    :    ___/\___        ___/\/\/\___     (실제 사용자 API 요청)

[IaaS / VM 배포 모델]
Provision : ----------------------------------- (VM 항상 켜져 있음)
낭비 구간 : ▒▒▒    ▒▒▒▒▒▒▒▒▒▒▒▒           ▒▒▒▒▒ (유휴 자원 비용 발생)

[FaaS / 서버리스 배포 모델]
Function  :    ___/\___        ___/\/\/\___     (요청 즉시 실행 및 소멸)
낭비 구간 : (없음 - Scale to Zero 메커니즘 동작)

이 도식의 핵심은 IaaS 기반 구조에서는 트래픽의 고점을 기준으로 인프라를 상시 구동해야 하므로 빈 공간(유휴 자원)만큼의 비용 누수가 지속해서 발생한다는 점이다. 반면 FaaS 모델에서는 요청이 들어오는 순간(Trigger)에만 런타임이 기동되고 즉시 소멸(Scale to Zero)하므로 자원 낭비가 완벽하게 차단된다. 실무에서는 간헐적이거나 예측 불가능한 스파이크가 발생하는 워크로드에 FaaS를 도입할 때 가장 극적인 재무적 이점을 거둘 수 있다.

📢 섹션 요약 비유: 빈 택시가 계속 시동을 켜고 대기하며 기름을 낭비하는 것이 기존 서버라면, 서버리스는 승객이 부를 때만 마법처럼 차가 나타나 이동 후 바로 사라지는 순간 이동 서비스와 같다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

FaaS 내부 동작 및 분산 아키텍처 구성 FaaS 환경은 함수 코드가 저장소에 대기하다가 특정 이벤트가 발생하면, 동적으로 격리된 실행 환경(마이크로VM 또는 샌드박스)을 할당받아 코드를 실행한 후 즉시 반환하는 고도의 오케스트레이션 라이프사이클을 갖는다.

이 도식은 사용자의 API 요청부터 FaaS 백엔드 엔진이 어떻게 마이크로VM을 할당하고 반환하는지를 보여주는 계층 구조도이다.

┌─────────────────────────────────────────────────────────────┐
│ 1. 클라이언트 요청 (HTTP / S3 이벤트 / Cron)                │
└───────┬──────────────────────────────────────────────┬──────┘
        │ (페이로드)                                   │ (응답)
┌───────▼──────────────────────────────────────────────┴──────┐
│ 2. API 게이트웨이 / 이벤트 라우터 (인증, 속도 제한)         │
└───────┬──────────────────────────────────────────────┬──────┘
        │ (함수 호출 이벤트)                           │
┌───────▼──────────────────────────────────────────────┴──────┐
│ 3. FaaS 컨트롤러 (스케일아웃 매니저)                        │
│   [ 유휴 워커 풀 ]       ==>   [ 콜드 워커 초기화 ]         │
└───────┬──────────────────────────────────────────────┬──────┘
        │ (디스패치)                                   │
┌───────▼──────────────────────────────────────────────┴──────┐
│ 4. 워커 노드 (물리 서버)                                    │
│ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐    │
│ │ MicroVM (Warm) │ │ MicroVM (Cold) │ │ MicroVM (Term) │    │
│ │ - 노드 런타임  │ │ - OS/코드 부팅 │ │ - GC / 정리    │    │
│ │ - 실행()       │ │ - 패키지 다운  │ │                │    │
│ └────────────────┘ └────────────────┘ └────────────────┘    │
└───────┬──────────────────────────────────────────────┬──────┘
        │ (상태 읽기/쓰기 - 필수!)                     │
┌───────▼──────────────────────────────────────────────┴──────┐
│ 5. 외부 백엔드 서비스 (DynamoDB, S3, RDS)                   │
└─────────────────────────────────────────────────────────────┘

이 구조도의 핵심은 FaaS 컨트롤러가 요청 인입 시 '유휴 워커(Warm)'가 있는지, '새로운 워커(Cold)'를 띄워야 하는지 판단하는 동적 스케줄링 계층에 있다. Worker Node 내부에서는 컨테이너보다 격리 수준이 높으면서도 부팅이 빠른 MicroVM(예: AWS Firecracker)이 사용된다. 또한 실행 환경 자체가 무상태(Stateless)이므로, 모든 영구 데이터는 반드시 5번 계층(DB)에 의존해야 한다는 점이 아키텍처의 최대 제약이자 트레이드오프다.

콜드 스타트 (Cold Start) 메커니즘 FaaS의 가장 치명적인 단점은 콜드 스타트다. 함수가 오랫동안 호출되지 않으면 클라우드는 비용 절감을 위해 해당 인스턴스를 회수(Kill)한다. 이 타이밍 그래프는 웜 스타트와 콜드 스타트 시 발생하는 지연(Latency) 구간의 차이를 명확히 대조한다.

[요청 시작] ──────────────────── 시간(ms) ─────────────────────► [응답 완료]

[Warm Start (최적)]
REQ ──►│ 실행(Execute) 10ms │──► ACK
       (이미 준비된 컨테이너/메모리 재사용)

[Cold Start (초기 지연 병목 발생)]
REQ ──►│ 1. 인스턴스/VM 부팅 (50ms) │
       │ 2. 런타임 초기화 (100ms)    │
       │ 3. 코드/패키지 로드 (200ms) │
       │ 4. DB 커넥션 맺기 (150ms)   │
       │ 5. 실행(Execute) (10ms)     │──► ACK (총 510ms 소요)

이 타이밍 도식의 핵심은 콜드 스타트 시 순수 비즈니스 로직(5번)의 실행 시간보다 인프라와 런타임이 준비되는 시간(1~4번)이 몇십 배 길게 소요된다는 점이다. 머신러닝 패키지처럼 크기가 크거나 JVM처럼 무거운 환경일수록 3번 구간의 지연이 치명적이다. 따라서 실시간 응답성이 극도로 중요한 경우, 서버리스 채택을 보류하거나 '프로비저닝된 동시성(Provisioned Concurrency)' 기능을 통해 강제로 웜 상태를 유지(비용 지불)하는 설계가 필요하다.

📢 섹션 요약 비유: 요리사가 주방에 요리 레시피(코드)만 던져놓으면, 주문이 들어올 때마다 클라우드가 0.1초 만에 도마와 가스레인지를 세팅하고 조리 후 바로 치워버리는 첨단 팝업 주방이다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

서버리스, 컨테이너, 가상머신 아키텍처 심층 비교 FaaS는 만능이 아니며 워크로드의 특성에 따라 IaaS, CaaS 간의 명확한 판단이 필요하다.

이 매트릭스는 "어느 기술이 우월한가"가 아니라 "통제권(Control)과 자동화(Automation) 사이의 저울질"을 나타낸다. FaaS는 운영 자동화의 정점에 있지만, 개발자의 통제권(인프라 디버깅, 네트워크 세밀 조정)을 앗아간다. IaaS는 통제권이 완벽하지만 인프라 운영 노동(Toil)이 극심하다. 실무에서는 상시 트래픽은 CaaS로 처리하고 비동기 배치/알람은 FaaS로 분리하는 '하이브리드 MSA' 전략이 보편적이다.

📢 섹션 요약 비유: 자가용(IaaS)은 내 마음대로 튜닝할 수 있고, 시내버스(CaaS)는 안정적인 노선을 달리며, 택시(FaaS)는 편하지만 매일 장거리를 타면 요금 폭탄을 맞게 된다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

FaaS 실무 운영 시나리오 및 트러블슈팅 서버리스 아키텍처는 도입 초기에는 훌륭하지만, 트래픽이 거대해지면 기존 환경과는 전혀 다른 성격의 장애 병목을 유발한다.

시나리오: RDBMS 커넥션 풀 고갈 현상 (치명적 안티패턴) 가장 흔한 실패 사례는 FaaS에서 기존 온프레미스형 RDBMS(MySQL, Oracle)를 직접 호출하는 것이다. 이 도식은 오토 스케일링되는 FaaS 환경이 백엔드 DB 연결 병목을 어떻게 유발하는지 시각화한다.

[Client / 클라이언트]        [API Gateway / API 게이트웨이]             [FaaS (AWS Lambda)]            [RDBMS]
                            ____(Scale-out)___
Requests =>    1,000 req => │ Func 1 (Conn 1) │ --- (TCP Handshake) ---> [DB Max Conn = 200]
                            │ Func 2 (Conn 1) │ --- (TCP Handshake) --->  │
                            │ ...             │                           │ (200개 초과 시 즉각 연결 거부!)
                            │ Func 1000 (Conn)│ --- (Conn Refused) ----X (전체 시스템 장애 발생)
                            -------------------

이 흐름의 핵심은 FaaS의 무한한 스케일 아웃이 역설적으로 백엔드 데이터베이스를 공격하는 자체 DDoS 형태가 된다는 점이다. 기존 WAS 서버는 한정된 스레드 내에서 DB 커넥션 풀을 공유하지만, FaaS는 각각 독립된 마이크로VM이므로 풀을 공유하지 못하고 수천 개의 새로운 연결을 맺으려다 DB를 터뜨린다.

• 실무 판단: 이를 방지하기 위해 FaaS 전용 DB 프록시(예: AWS RDS Proxy)를 중간에 두어 커넥션을 캐싱하거나, 아예 연결 오버헤드가 없는 HTTP API 기반의 분산 NoSQL(DynamoDB)로 전환해야 한다.

서버리스 도입 체크리스트

1. 장기 실행 제약: FaaS는 최대 실행 시간 제한(예: 15분)이 존재한다. 동영상 인코딩 같은 작업은 서버리스 대신 배치 전용 컨테이너로 넘겨야 한다.
2. 분산 추적 필수: 로그 파일에 직접 접근할 수 없으므로, OpenTelemetry 기반의 Trace ID를 코드에 심어 전체 호출 흐름을 엮는 중앙 집중형 로깅이 필수다.

📢 섹션 요약 비유: 수만 명의 아르바이트생(FaaS)을 한 번에 고용해 일을 시킬 수는 있지만, 이들이 동시에 좁은 창고(DB) 문으로 뛰어들면 병목 사고가 발생하므로 반드시 효율적인 안내 요원(DB 프록시)을 배치해야 한다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

도입 기대 효과 (정량 / 정성)

미래 전망과 아키텍처 진화 FaaS는 단순히 함수 조각을 넘어서, 진정한 클라우드 네이티브의 종착지로 나아가고 있다. 과거 CSP 벤더 종속이 한계로 지적되었으나, 최근에는 쿠버네티스 위에서 구동되는 오픈소스 서버리스 플랫폼(Knative, OpenFaaS)이 표준으로 자리 잡으며 하이브리드 서버리스 환경이 열리고 있다. 또한, 콜드 스타트를 근본적으로 제거하기 위해 무거운 컨테이너 대신 WebAssembly(Wasm) 기술이 엣지 컴퓨팅 기반의 초경량 런타임(Cloudflare Workers)으로 통합 발전하는 추세다.

📢 섹션 요약 비유: FaaS는 레고 블록만 조립하면 알아서 거대한 건물이 지어지고 사라지는 마법이다. 미래에는 이 블록마저 사용자 바로 옆(엣지)에서 0.001초 만에 조립될 것이다.

📌 관련 개념 맵 (Knowledge Graph)

• 이벤트 기반 아키텍처 (EDA) | FaaS의 비동기 실행을 촉발하는 근본적인 아키텍처 철학이자 설계 패턴
• AWS Firecracker | 서버리스 함수의 고속 부팅과 커널 격리를 동시에 보장하는 마이크로VM 엔진
• API Gateway | 외부 트래픽을 정제하고 FaaS로 안전하게 라우팅하는 단일 진입점 프록시 방화벽
• 프로비저닝된 동시성 (Provisioned Concurrency) | 콜드 스타트 지연을 방지하기 위해 컨테이너를 강제로 웜 상태로 유지하는 기법
• Bounded Context | 도메인 주도 설계(DDD)에서 하나의 FaaS 함수 또는 서비스가 책임지는 논리적 경계

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

1. 예전 컴퓨터는 우리가 사용하지 않을 때도 전기를 켜두고 요금을 내야 하는 비싼 장난감이었어요.
2. 서버리스(FaaS)는 똑똑한 로봇 수도꼭지 같아서, 우리가 손을 댈 때만 딱 켜져서 일하고 그 1초만큼만 동전을 낸답니다.
3. 그래서 평소에 안 쓰는 기능들을 이걸로 만들면 컴퓨터 요금을 엄청나게 아낄 수 있고 고장도 안 나요!