Cloud-Native & Serverless Evolution

1. Overview

클라우드 네이티브 및 서버리스 진화(Cloud-Native & Serverless Evolution, CNSE)는 인프라 관리라는 귀찮고 복잡한 작업을 클라우드 사업자에게 완전히 위임(Offloading)하고, 엔지니어는 오직 비즈니스 가치를 창출하는 핵심 로직(Code)에만 집중하게 만드는 인프라 패러다임의 궁극적 진화 형태를 다룹니다.

과거에는 서버 한 대를 띄우려면 견적서를 올리고 하드웨어를 조립해야 했지만, 이제는 테라폼(Terraform) 코드 몇 줄로 전 세계 수만 대의 네트워크 인프라를 1분 만에 띄우고 지우는 인프라 애즈 코드(IaC)의 시대입니다. 학습자는 어떠한 클라우드에서도 무중단으로 동작하는 12-Factor App 설계부터, 서버조차 없애버리고 함수 단위로 요금을 내는 서버리스(Serverless/FaaS) 아키텍처, 그리고 런던의 접속자와 서울의 접속자에게 빛의 속도로 응답을 보장하는 글로벌 엣지 컴퓨팅(Edge Computing)의 거대한 파도에 올라탑니다.

2. Scope & Boundaries

In-Scope

• 클라우드 네이티브 설계 (Cloud-Native Patterns): 12-Factor App, 불변 인프라(Immutable Infrastructure), 멀티/하이브리드 클라우드 아키텍처, 펫(Pets) vs 가축(Cattle) 메타포.
• 서버리스 및 FaaS (Serverless & FaaS): AWS Lambda 등 이벤트 구동형 함수(Event-driven Functions), 콜드 스타트(Cold Start) 물리, 무상태(Stateless) 고립 한계.
• 엣지 컴퓨팅과 CDN (Edge & CDN): Cloudflare Workers 등 엣지 노드에서의 로직 처리, 캐싱 무효화(Invalidation), 데이터 로컬리티(Data Locality).
• 코드형 인프라 (IaC & GitOps): Terraform, Pulumi를 활용한 선언적 인프라 구성, Git을 진실의 원천(Single Source of Truth)으로 삼는 ArgoCD 배포 모델.

Out-of-Scope

• AWS, GCP의 콘솔 클릭 사용법 가이드: 특정 벤더의 자격증을 따기 위한 마우스 클릭 튜토리얼 (클라우드 환경에 종속되지 않는 벤더 중립적 아키텍처를 지향).
• 컨테이너 내부 프로세스 격리 원리: 리눅스 커널 Cgroups나 네임스페이스의 C 언어 수준 원리 $\rightarrow$ 07-06. Microservices & Containers 영역으로 위임.

Boundaries

• CNSE vs. MCM (07-06): MCM(07-06)이 '내 코드를 어떻게 컨테이너(Docker)라는 규격화된 박스에 담고 쿠버네티스로 지휘할 것인가'에 대한 애플리케이션 포장법이라면, CNSE는 **'그 박스를 실행할 거대한 데이터센터 인프라 자체를 어떻게 코드로 찍어내고, 더 나아가 박스(컨테이너)조차 의식하지 않는 서버리스의 세계로 갈 것인가'**를 다루는 거시적 패러다임입니다.

3. Counterexample

• 콘솔 클릭 프로비저닝 (Ops Fallacy): AWS 웹 콘솔에 들어가 마우스 클릭으로 EC2 서버 10대와 RDS를 정성스럽게 세팅하는 행위. 한 달 뒤 서버 하나가 죽거나, 똑같은 환경의 '개발(Dev) 서버'를 띄워야 할 때 내가 체크박스를 어떻게 찍었는지 아무도 기억하지 못해 재난이 발생합니다. 인프라는 마우스가 아닌 **테라폼(Terraform) 코드(IaC)**로만 작성되어 Git으로 리뷰받아야 한다는 현대 운영의 대원칙을 부정한 안티패턴입니다.
• 상태 보존형 서버리스 함수 (Serverless Fallacy): AWS Lambda 코드 안에서 전역 변수 배열을 선언해 두고, 여러 유저가 들어올 때마다 배열에 데이터를 쌓아 조회하게 만든 구조. 서버리스 함수는 호출이 끝나면 언제든지 클라우드 벤더에 의해 메모리가 폭파(Destroy)되며, 여러 호출이 동시에 오면 함수가 여러 개 복제되어 각자 다른 메모리(상태 불일치)를 갖게 됩니다. 서버리스는 철저한 무상태(Stateless) 연산 모터일 뿐, 상태(State)는 반드시 DynamoDB 같은 외부 저장소로 빼야 한다는 물리 법칙을 위반한 설계입니다.

4. Prerequisites

• 기초 및 아키텍처 패턴 (Basic): 의존성을 외부로 밀어내는 클린 아키텍처 원리가 12-Factor 앱의 '설정(Config) 분리'와 맥을 같이합니다. (07-01. FAP)
• 확장성 및 고가용성 설계 (Recommended): AWS나 GCP가 밑단에서 로드 밸런싱을 어떻게 물리적으로 수행하는지 알아야 클라우드를 신뢰할 수 있습니다. (07-03. SHA)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 클라우드 네이티브와 12-Factor App (Cloud-Native Patterns)

• Why to Learn: 코드를 내 로컬 윈도우(Windows) 컴퓨터에서 짜든, AWS 리눅스(Linux) 환경에서 돌리든 단 1줄의 코드 수정 없이 이식성을 100% 보장하기 위함입니다.
• What to Learn:
  • Concepts: 클라우드 네이티브 아키텍처, 펫(Pets) vs 가축(Cattle) 메타포, 불변 인프라(Immutable Infrastructure).
  • Skills: 12-Factor App 규칙 적용(환경 변수로 설정 분리, 상태 없는 프로세스, 포트 바인딩).
  • Tools: .env 관리, 컨테이너 빌드 파이프라인.
  • Trade-offs: OS에 종속된 라이브러리(C++ 등)를 쓸 수 없고 모든 것을 환경 변수로 주입해야 하는 답답함 vs 코드가 돌아가는 서버가 통째로 박살 나도 다른 서버에 소스만 올리면 즉시 복구되는 궁극의 회복력.
• How to Learn:
  • 1단계: 하드코딩된 DB 비밀번호와 로컬 파일 시스템(/usr/images)에 사진을 저장하는 끔찍한 레거시 코드를, DATABASE_URL 환경 변수와 S3 외부 저장소(Backing Service)로 분리하는 12-Factor 리팩토링을 수행합니다.
  • 2단계: 이렇게 리팩토링된 앱은 서버가 꺼졌다가 다른 IP로 다시 켜져도(가축) 이전 상태를 완벽히 유지하며 서비스가 가능함을 증명합니다.
• Implement: 특정 레거시 시스템 코드를 분석하여, 12-Factor App의 12가지 항목 중 위반된 사항을 찾아내고 클라우드에 올리기 위한 리팩토링 가이드 문서 작성.

Recommended

Core Topic 02: 서버리스 컴퓨팅과 콜드 스타트 물리 (Serverless & FaaS)

• Why to Learn: 24시간 켜놔야 해서 월 10만 원씩 나가던 서버를, 사용자가 클릭할 때만 0.05초 실행되게 만들어 요금을 100원 단위로 극단적으로 깎아버리기 위해서입니다.
• What to Learn:
  • Concepts: IaaS $\rightarrow$ PaaS $\rightarrow$ Serverless의 진화, FaaS(Function as a Service)의 구조, 이벤트 트리거(Event Trigger).
  • Skills: 짧고 독립적인 무상태(Stateless) 함수 분리, 동시성 한계 제어, 콜드 스타트(Cold Start) 지연 해결.
  • Tools: AWS Lambda, Google Cloud Functions, Serverless Framework.
  • Trade-offs: 인프라 관리 제로(Zero) 및 미친듯한 자동 수평 확장 vs 언어 런타임이 처음 로딩될 때 발생하는 2~3초의 콜드 스타트 딜레이와 디버깅/모니터링의 극악한 난이도.
• How to Learn:
  • 1단계: 유저가 S3(스토리지)에 10MB짜리 프로필 사진을 올리는 이벤트를 트리거로 삼아, 즉시 Lambda 함수가 깨어나 썸네일로 리사이징하고 종료되는 파이프라인 흐름을 추적합니다.
  • 2단계: 아무도 접속 안 하다가 첫 번째 유저가 들어왔을 때 코드가 컨테이너에 적재되느라 발생하는 콜드 스타트(Cold Start) 3초를 확인하고, 이를 막기 위해 Provisioned Concurrency(미리 웜업해 두기)를 적용하는 벤더 로직을 뜯어봅니다.
• Implement: Serverless Framework를 이용해 "슬랙(Slack)에서 메시지를 치면 날씨 API를 조회해 리턴하는" 단순 봇을 만들고, 인프라 비용 없이 배포하는 실습 프로비저닝 코드.

Practical

Core Topic 03: 엣지 컴퓨팅과 분산 라우팅 (Edge Computing & CDN)

• Why to Learn: 글로벌 서비스에서 빛의 속도(광케이블 물리 한계)조차 답답할 때, 미국에 있는 메인 서버가 아니라 한국 사용자 동네에 있는 엣지 서버에서 미리 연산을 끝내버리기 위함입니다.
• What to Learn:
  • Concepts: CDN(Content Delivery Network), 데이터 로컬리티(Data Locality), 엣지 로직(Edge Computing).
  • Skills: 정적 자원 캐싱 무효화(Cache Invalidation) 전략, 지리적 기반 라우팅(Geo-Routing), 엣지 워커(Edge Worker)를 통한 JWT 인증 분리.
  • Tools: Cloudflare Workers, AWS Lambda@Edge.
  • Trade-offs: 사용자는 화면을 0.01초 만에 띄우는 황홀한 경험을 하지만 vs 메인 DB와 전 세계 엣지 캐시 간의 데이터가 불일치하여, 방금 바꾼 내 프로필 사진이 안 바뀐 것처럼 보이는 캐시 정합성(Consistency) 붕괴 리스크.
• How to Learn:
  • 1단계: 미국 서버에 떠 있는 정적 이미지와 JS 파일을 한국에서 직접 다운로드할 때 500ms가 걸리지만, CDN을 태워 캐싱하면 한국 엣지 노드에서 20ms 만에 응답하는 빛의 물리를 벤치마킹합니다.
  • 2단계: 단순히 이미지 캐싱을 넘어, 유저가 미국 서버로 가기 전 한국 엣지 서버(Cloudflare Worker)에서 즉시 악성 봇(Bot) 여부를 판단하거나 JWT 토큰을 검사해 차단해 버리는 연산의 전방 배치를 설계합니다.
• Implement: 특정 API(예: 오늘의 환율) 결과를 엣지(CDN) 레벨에 10분간 캐싱(TTL) 설정하고, 환율이 급변했을 때 수동으로 캐시를 강제 무효화(Invalidation)하는 흐름을 도식화한 인프라 맵.

Advanced

Core Topic 04: 코드형 인프라와 GitOps 배포 모델 (IaC & GitOps)

• Why to Learn: 구두로 전해지거나 위키(Wiki)에 적힌 서버 셋업 매뉴얼을 완전히 불태우고, 오직 Git에 저장된 main 브랜치의 코드가 시스템의 유일한 진실(Single Source of Truth)이 되게 만들기 위해서입니다.
• What to Learn:
  • Concepts: IaC(Infrastructure as Code), 선언적 인프라(Declarative) vs 절차적 스크립트(Imperative), GitOps 철학.
  • Skills: Terraform 상태(State) 파일의 동시성 제어 락(Lock), ArgoCD의 Pull 기반 배포 모델, 드리프트(Drift) 감지 및 교정.
  • Tools: Terraform, Pulumi, ArgoCD, Flux.
  • Trade-offs: 누가 언제 왜 DB 포트를 열었는지 Git 로그에 완벽한 히스토리가 남는 궁극의 보안성 vs 누군가 콘솔에서 마우스로 급하게 포트를 열었을 때, 테라폼 코드가 "코드가 진실이다!"라며 그 포트를 다시 닫아버려(Drift) 대참사가 나는 융통성 없음.
• How to Learn:
  • 1단계: VPC, Subnet, EC2 서버 2대를 생성하는 절차를 AWS 콘솔 클릭이 아닌 .tf 테라폼 코드로 작성합니다. 이 코드를 terraform apply 하면 클라우드 API가 호출되어 실제 장비가 프로비저닝되는 과정을 확인합니다.
  • 2단계: 쿠버네티스 클러스터 안에 ArgoCD를 띄웁니다. 개발자가 소스 코드를 Git에 push만 하면, ArgoCD가 스스로 Git을 감시(Pull)하다가 변경사항을 발견하고 자동으로 클러스터 상태를 업데이트하는 마법 같은 CI/CD 흐름을 분석합니다.
• Implement: 테라폼(Terraform)을 이용해 로드 밸런서 1대와 백엔드 서버 2대로 구성된 고가용성 인프라 아키텍처를 단 1개의 명령어(terraform apply)로 구축하고 파괴(terraform destroy)할 수 있는 IaC 모듈 작성.

7. Terminology

8. References

Primary References

• [P2] SWEBOK v4: Software Construction - Cloud Computing — Construction patterns.
• [P1] CS2023: SE - SaaS and Cloud Computing — Design principles.

Secondary References

• [Cloud Native Patterns] Cornelia Davis — 클라우드 네이티브의 기본 원리와 패턴 상세.
• [Infrastructure as Code] Kief Morris — 선언적 인프라 관리의 바이블.

Industry References

• [CNCF Cloud Native Definition] — 클라우드 네이티브 기술의 공식 정의 및 생태계 로드맵.
• [The 12-Factor App] — 현대적인 앱 구축을 위한 12가지 가이드라인.

9. Final Checklist

Primary Checklist

• 특정 애플리케이션이 클라우드 네이티브 기준(12-Factor)을 얼마나 충족하는지 정량적으로 평가할 수 있는가? (P1)
• 서버리스 환경에서 콜드 스타트(Cold Start) 지연을 줄이기 위한 물리적 해결책(메모리 할당, Warm-up)을 제안 가능한가? (Industry)

Secondary Checklist

• 엣지 컴퓨팅을 도입했을 때 중앙 집중형 구조 대비 사용자 시점 Latency 감소분을 공학적으로 산출했는가?
• 인프라 변경 시 수동 조작 대신 IaC와 GitOps를 통해 물리적 형상 관리를 100% 보장하고 있는가?

Industry Checklist

• 특정 클라우드 벤더의 장애 상황(Region Outage)에 대응하기 위한 멀티 리전(Multi-region) 설계 역량을 입증했는가?
• 서버리스 함수 간의 상태 공유 난제를 해결하기 위한 외부 저장소(Redis, S3) 결합 설계를 논리적으로 기술 가능한가?