Serverless Computing & FaaS Dynamics

1. Overview

서버리스 컴퓨팅과 FaaS 역학(Serverless Computing & FaaS Dynamics)은 "서버를 관리하는 가장 좋은 방법은 서버 자체를 아예 안 가지는 것이다"라는 극단적 클라우드 철학을 바탕으로, OS 패치와 오토스케일링의 지옥에서 백엔드 개발자를 완전히 해방시키는 궁극의 인프라 추상화를 해부합니다.

학습자는 AWS EC2처럼 24시간 내내 켜두고 월세를 내는 고정 비용 모델을 버리고, 유저의 요청(Event)이 들어올 때만 0.1초 만에 코드를 띄우고(Execute) 밀리초 단위로 돈을 내는 **FaaS (Function as a Service - AWS Lambda)**의 짠돌이 경제학을 뜯어봅니다. 나아가 FaaS의 가장 뼈아픈 약점인, 너무 오랫동안 안 쓰면 컨테이너가 굳어버려 첫 요청에 3초 넘게 걸리는 **콜드 스타트(Cold Start)**의 끔찍한 딜레마를 장악합니다. 마지막으로, 단순한 함수 쪼가리(Lambda)들을 이벤트 브릿지(EventBridge)와 상태 머신(Step Functions)으로 정교하게 엮어 거대한 트랜잭션을 꿰매는 마이크로 빌딩 블록 설계 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Serverless Paradigm: No Ops (서버 관리 제로), Pay-as-you-go (밀리초 단위 과금), Event-driven (이벤트 트리거).
• FaaS (Function as a Service): AWS Lambda, Google Cloud Functions 구조 및 제약사항.
• The Cold Start Problem: JIT 컴파일과 OS 프로비저닝 지연, Provisioned Concurrency (대기 풀) 타협.
• State & Orchestration: Stateless 함수의 한계, AWS Step Functions을 이용한 상태 기반 오케스트레이션.

Out-of-Scope

• BaaS (Backend as a Service) 딥 다이브: Firebase Realtime DB, Cognito 등 서드파티 통합 $\rightarrow$ 벤더 종속적 튜토리얼 영역으로 위임.
• AWS 특정 서비스 매뉴얼: IAM 권한 설정, API Gateway 연동 클릭법 $\rightarrow$ 클라우드 인증(Certification) 영역.

Boundaries

• Serverless vs PaaS (Heroku/Elastic Beanstalk): PaaS는 인프라 관리를 대신해 주지만, 새벽 3시에 아무 트래픽이 없어도 "1대의 웹 서버"는 켜져 있어야 하고 그 1대분 월세는 지불해야 합니다. 반면 진정한 서버리스(FaaS)는 트래픽이 0이면 인프라도 0으로 소멸(Scale to Zero)하여 비용이 0원이 되는 극단적 스케일링(Scale-to-Zero)을 경계선으로 삼습니다.

3. Counterexample

• FaaS 안의 모놀리스 (Lambdalith): 람다(Lambda) 하나에 스프링 부트(Spring Boot)로 짠 거대한 게시판, 결제, 회원 모듈을 통째로 밀어 넣었습니다. 유저가 API를 찌를 때마다 람다가 이 거대한 자바 런타임을 메모리에 올리느라 콜드 스타트(Cold Start) 지연만 10초가 걸려 앱이 뻗어버립니다. 서버리스는 작고 가벼운 단일 목적의 함수(Micro-function)들이 이벤트에 반응해야 한다는 원칙을 무시한 최악의 하이브리드 참사입니다.
• 긴 실행 시간의 폭사: 데이터베이스에 있는 100만 건의 유저 테이블을 조회해서 CSV로 뽑아내는 배치(Batch) 잡을 AWS 람다에 태웠습니다. 람다의 하드 리밋(Max Timeout)인 15분이 땡 치자마자, 작업이 99% 완료되었음에도 불구하고 AWS가 자비 없이 람다의 목을 날려버립니다(Killed). FaaS는 철저히 '짧은 생명주기(Short-lived)'를 갖는 Stateless 트랜잭션에 써야 하며, 장기 실행(Long-running) 배치 작업은 EC2나 Batch 서비스로 돌려야 하는 한계를 인지하지 못한 도구 오용입니다.

4. Prerequisites

• 이벤트 주도 아키텍처 (Basic): 이벤트(Event)에 반응하는 비동기 흐름. (07-04-02 Event-driven Flows)
• 컨테이너 부팅 역학 (Basic): VM과 달리 격리된 환경이 뜨는 속도. (07-06-02 Containerization)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 서버리스 경제학, Scale-to-Zero (The Serverless Illusion)

• Why to Learn: 한 달 내내 켜두지만 실제 트래픽은 하루 10분만 들어오는 비효율적인 서버 구조를 박살 내고, 내가 코드를 실행한 밀리초 단위로만 돈을 내는 클라우드 극한 효율을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Serverless Computing, Scale-to-Zero (0으로 축소), NoOps (운영 제로), TCO (총 소유 비용), Pay-as-you-go.
  • Skills: 전통적 EC2(고정 비용)와 Lambda(변동 비용) 간의 손익 분기점(Break-even Point) 계산.
• How to Learn:
  • 1단계: 고정 비용의 낭비 (EC2): 하루 100명 들어오는 사내 어드민 페이지를 위해 AWS EC2 한 대를 켭니다. 밤 12시부터 아침 8시까지 접속자가 0명이어도, AWS 요금 미터기는 24시간 내내 돌아가며 한 달 20달러를 빨아갑니다.
  • 2단계: 초극단적 종량제 (FaaS): 서버리스(Lambda)로 바꿨습니다. 접속자가 없으면 서버는 '0대(소멸)'가 됩니다. 누군가 버튼을 누를 때마다(Event), 컨테이너가 0.1초 만에 떠서 처리하고 다시 소멸합니다. 100명이 100번 눌렀으면, 함수가 실행된 총합 2초 치 요금(약 0.0001달러)만 청구되는 미친 TCO(Total Cost of Ownership) 매직을 해부합니다.
• Implement: Serverless 요금 시뮬레이터 파이썬 스크립트. 변수: Traffic_Per_Day(호출 수), Avg_Exec_Time(실행 시간 ms). 월간 고정 서버비(예: $20)와 Lambda 방식 비용(GB-s당 요금 * 호출 수)을 비교하여, 어느 정도의 트래픽을 넘어서면 역으로 서버리스가 더 비싸지는지(교차점) 그래프 렌더링.

Recommended

Core Topic 02: 찰나의 생명, FaaS (Function as a Service)

• Why to Learn: 거대한 스프링 부트(Monolith) 프레임워크를 버리고, 오직 "이벤트(Event)가 들어왔을 때 -> 연산하고 -> 죽는다"는 단일 목적 함수 단위로 시스템을 조각내기 위함입니다.
• What to Learn:
  • Concepts: FaaS, Event-driven Triggers (HTTP, S3, SQS), Short-lived Process, Statelessness, Execution Environment.
  • Skills: 특정 이벤트(예: S3 버킷에 이미지 업로드)에만 발동하는 마이크로 함수(이미지 썸네일 리사이징) 아키텍처 매핑.
• How to Learn:
  • 1단계: 전통적 데몬(Daemon): 유저가 프로필 사진을 올리면 썸네일로 압축해야 합니다. EC2 서버 안에 while(true)를 도는 워커(Worker) 프로세스를 띄워두고 24시간 큐를 감시하게 만듭니다. 메모리 낭비입니다.
  • 2단계: 이벤트 트리거 (Event Driven): 서버리스 환경에서는 아무 프로세스도 안 띄워놓습니다. 단지 AWS 설정에 "S3 버킷에 파일 들어오면 이 파이썬 코드(Lambda) 1번 실행해"라고 룰만 걸어둡니다. 파일이 1만 개가 동시에 올라오면? AWS가 알아서 파이썬 컨테이너를 1만 개 띄워(무한 스케일아웃) 순식간에 다 압축하고 전부 죽여버리는 찰나의 폭발력을 뜯어봅니다.
• Implement: S3 기반 FaaS 이벤트 처리 시뮬레이터. Event_Queue에 파일 업로드 이벤트 생성. FaaS 프레임워크 로직이 이벤트를 잡자마자 Thread를 즉시 스폰(Spawn)하여 2초짜리 리사이징을 실행하고 스레드를 자결(Kill)시킴. 100개의 이벤트가 동시에 들어와도 100개의 스레드가 일제히 떠서 2초 만에 완벽히 처리하고 사라지는(Scale to Zero) 콘솔 애니메이션.

Practical

Core Topic 03: 얼어붙은 엔진, 콜드 스타트 (The Cold Start Dilemma)

• Why to Learn: 람다를 맹신하다가, "첫 화면 로딩이 5초나 걸려요"라는 유저의 분노에 직면했을 때, 그 밑바닥에 숨겨진 컨테이너 부팅 딜레이의 물리학을 깨닫고 방어하기 위함입니다.
• What to Learn:
  • Concepts: Cold Start (초기 구동 지연), Warm Start (캐시된 구동), JIT Compiler 딜레이 (Java/C#), Provisioned Concurrency (미리 켜두기).
  • Skills: FaaS 환경에 적합한 가벼운 런타임(Go, Node.js) 선택 및 콜드 스타트 방어(웜 풀) 설정.
• How to Learn:
  • 1단계: 콜드 스타트의 지옥: 10분 동안 아무도 앱에 안 들어왔습니다. AWS는 돈을 아끼기 위해 띄워뒀던 람다 컨테이너를 다 지워버립니다. 11분째에 유저가 접속합니다. AWS가 뒤늦게 컨테이너를 부팅하고, 자바(Java) 가상 머신(JVM)을 띄우고, 코드를 다운받느라 4초(Cold Start)가 걸립니다. 유저는 4초 동안 흰 화면만 보게 되는 재앙을 해부합니다.
  • 2단계: 웜 스타트와 타협: 한 번 부팅된 컨테이너는 5~10분 정도는 안 죽고 대기(Warm)합니다. 두 번째 요청부터는 0.01초 만에 응답(Warm Start)합니다. 무거운 자바 대신 가벼운 Go나 Node.js를 써서 부팅을 0.5초로 줄이거나, 돈을 좀 더 내고 "무조건 10개는 끄지 말고 켜둬(Provisioned Concurrency)"라고 타협하는 FaaS 튜닝을 뜯어봅니다.
• Implement: Cold/Warm Start 딜레이 시뮬레이터. Function_Container의 상태(ASLEEP, AWAKE). request() 호출 시 ASLEEP이면 [COLD START] 3000ms delay 출력 후 AWAKE로 전환. 이후 request() 호출은 [WARM START] 50ms delay 출력. 단, request()가 10초 이상 안 들어오면 백그라운드 타이머가 컨테이너를 다시 ASLEEP으로 강등시키는 로직 렌더링.

Advanced

Core Topic 04: 기억을 잃은 개미 군단 조종하기 (Orchestrating Stateless)

• Why to Learn: 실행 후 1초 만에 완벽히 기억상실증에 걸리는(Stateless) 람다 함수들을 10개 이어 붙여서, "결제 $\rightarrow$ 실패 시 롤백 $\rightarrow$ 성공 시 배송"이라는 거대한 비즈니스 트랜잭션을 꿰매기 위함입니다.
• What to Learn:
  • Concepts: Orchestration vs Choreography, State Machine (상태 머신), AWS Step Functions, Saga Pattern with Serverless.
  • Skills: 외부 상태(DB, Step Functions)를 활용하여 Stateless 함수 간의 데이터(State)를 넘겨주는(Pass) 오케스트레이션 설계.
• How to Learn:
  • 1단계: 기억 상실의 한계: 람다 A가 결제를 끝냈습니다. 이제 배송을 해야 합니다. 그런데 람다 A는 실행 1초 만에 죽어버려 메모리가 다 날아갑니다. "방금 결제한 유저가 누구지?" 람다 B에게 알려줄 방법이 없습니다. 상태(State)가 없다는 FaaS의 최대 약점을 해부합니다.
  • 2단계: 지휘자(Orchestrator): 함수 안에 로직을 억지로 욱여넣는(Lambdalith) 대신, AWS Step Functions 같은 '상태 머신(State Machine)'을 도입합니다. 중앙 지휘자가 람다 A를 부르고 그 결과값(JSON)을 자기가 쥐고 있다가, 람다 B를 띄우면서 그 값을 넘겨줍니다(Pass State). 에러가 나면 람다 C(취소 함수)를 부르는 끈질긴 분산 트랜잭션 지배력을 뜯어봅니다.
• Implement: State Machine 파이썬 시뮬레이션. StepFunction 클래스가 steps = [FuncA, FuncB, FuncC] 정의. FuncA(input) 실행 결과를 JSON으로 받아 FuncB(result_of_A)의 인자로 토스함. FuncB에서 50% 확률로 에러가 발생 시, 즉각 CompensationFunc(Rollback)을 실행하여 상태(State)를 완벽히 통제하는 오케스트레이션 데모.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Cloud Computing (Serverless and FaaS)
• [P5] SFIA - Software Design (DESN) - Serverless Architectures

Secondary

• [Serverless Architectures on AWS] Peter Sbarski - Serverless patterns and Lambda
• [Building Microservices] Sam Newman - Serverless and Function as a Service

Industry

• [MartinFowler.com] - Serverless Architectures
• [AWS Serverless Architecture Center] - Best practices for organizing larger serverless applications

9. Final Checklist

Primary

• 24시간 고정 비용이 나가는 EC2 인스턴스(혹은 PaaS) 모델과 비교하여, 트래픽이 0일 때는 과금도 0원이 되는 서버리스(FaaS)의 Scale-to-Zero 경제학이 중소규모 프로젝트에 미치는 이점을 증명할 수 있는가?
• AWS Lambda와 같은 FaaS는 태생적으로 "상태 없음(Stateless)"과 "짧은 실행 시간(Short-lived)" 제약을 가지므로, 30분짜리 대용량 비디오 인코딩 작업에는 절대로 쓰면 안 되는 이유를 설명할 수 있는가?

Secondary

• 드문드문 들어오는 트래픽 환경에서 자바(Java)로 작성된 FaaS 함수가 최초 실행될 때 수 초가 지연되는 콜드 스타트(Cold Start) 메커니즘을 분석하고, 이를 웜 스타트(Warm Start)로 유지하거나 런타임을 Go/Node.js로 교체하는 튜닝을 논증할 수 있는가?
• 웹 서버가 API 요청을 받아 동기적으로 연산하는 방식(Request-Response)을 버리고, 파일 업로드(S3)나 큐 삽입(SQS) 같은 사건(Event)에 반응하여 람다 함수가 비동기적으로 트리거되는 이벤트 주도(Event-driven) 아키텍처를 설계할 수 있는가?

Industry

• A 람다 함수 내부의 소스 코드에서 B 람다 함수를 HTTP로 호출하고 기다리게(Wait) 짜면, A와 B 모두에게 초당 과금이 중복 청구되는 끔찍한 안티 패턴임을 식별할 수 있는가?
• 순식간에 기억 상실증에 걸리는 무상태(Stateless) 함수들을 엮어서 "결제 $\rightarrow$ 재고 차감 $\rightarrow$ 이메일 전송"이라는 거대한 트랜잭션을 만들기 위해, AWS Step Functions와 같은 중앙 상태 머신(Orchestrator)으로 상태(State)를 토스(Pass)하는 설계를 평가할 수 있는가?