IaC & Deployment Physics

1. Overview

IaC와 배포의 물리학(IaC & Deployment Physics)은 마우스 클릭 노가다로 서버를 세팅하다가 관리자가 퇴사하면 시스템이 블랙박스가 되어버리는 원시 시대를 끝내고, 인프라 전체를 텍스트(Code)로 선언하여 무한 복제와 롤백이 가능한 마법의 세계를 해부합니다.

학습자는 AWS 콘솔 화면의 복잡한 버튼들을 외우는 대신, "DB 1대, 웹서버 2대를 띄워라"라고 코드로 명령하는 **코드로서의 인프라(Infrastructure as Code, IaC)**의 불변성을 뜯어봅니다. 나아가 코드를 배포할 때 유저가 502 에러(Bad Gateway)를 보게 만드는 멍청한 재시작을 버리고, 무중단으로 트래픽을 부드럽게 넘기는 블루-그린(Blue-Green)과 롤링(Rolling) 배포 아키텍처를 장악합니다. 마지막으로, 서버에 문제가 생겼을 때 들어가서 고치는(Mutable) 좀비 사육을 멈추고, 미련 없이 서버를 쏴 죽이고 새 서버를 띄우는 **불변 인프라(Immutable Infrastructure)**의 철학을 확보합니다.

2. Scope & Boundaries

In-Scope

• Infrastructure as Code (IaC): Terraform, CloudFormation 등의 선언형(Declarative) 인프라 구축 철학. 멱등성(Idempotency).
• Mutable vs Immutable Infrastructure: 애완동물(Pet)처럼 고쳐 쓰는 서버와, 가축(Cattle)처럼 갈아 치우는 서버의 패러다임 전환.
• Zero-Downtime Deployment: 사용자의 요청이 끊기지 않는 무중단 배포 전략.
• Deployment Strategies: Rolling Update (순차 배포), Blue-Green Deployment (통째 교체), Canary Release (일부 유저 선반영).

Out-of-Scope

• Terraform/Ansible 문법 튜토리얼: HCL 언어 문법이나 AWS 콘솔 클릭 튜토리얼 $\rightarrow$ 도구 종속적 지식이므로 본 문서에서는 '배포와 인프라의 역학(Physics)'에 집중함.
• GitOps 동기화 파이프라인: ArgoCD를 통한 K8s 매니페스트 렌더링 및 자동 동기화 $\rightarrow$ 09-05-04 GitOps & Progressive Delivery 영역으로 분리.

Boundaries

• 명령형(Imperative) vs 선언형(Declarative): 스크립트(sh)로 "EC2를 1대 띄워라"를 3번 실행하면 서버가 3대가 됩니다(명령형). 반면 Terraform(IaC)으로 "EC2 개수는 1대다"라고 선언하면, 이 코드를 100번 실행해도 서버는 1대만 유지됩니다(선언형, 멱등성). IaC의 본질은 자동화 스크립트가 아니라, 인프라의 최종 '상태(State)'를 정의하고 기계가 그 상태를 강제로 맞추게 하는 권력의 이동임을 명확히 긋습니다.

3. Counterexample

• 클릭옵스(ClickOps)의 저주: 스타트업 개발자가 AWS 웹 콘솔에 들어가서 마우스를 수백 번 클릭하여 로드밸런서, 보안 그룹, EC2를 세팅했습니다. 사업이 대박이 나서 런던에 똑같은 시스템(Region)을 띄워야 합니다. 개발자는 "어... 그때 내가 뭘 클릭했더라?" 하며 당황합니다. 3주 동안 온갖 설정을 빼먹어 해킹을 당하고 서버가 뻗습니다. 인프라를 코드(IaC)로 '선언(Declare)'해 두지 않고, 인간의 뇌와 손가락(클릭)에 의존한 인프라 휘발성의 재앙입니다.
• 눈물의 새벽 배포 (Downtime Deployment): "사용자 여러분, 02시부터 04시까지 점검입니다." 개발자들이 서버를 끄고, 톰캣에 war 파일을 올리고, 톰캣을 켭니다. 켜지는 도중에 에러가 납니다. 다시 끄고 어제 코드로 롤백합니다. 06시가 되어도 점검이 안 끝납니다. 새 서버(Green)를 미리 띄워놓고 100% 정상 가동되는 걸 확인한 뒤 공유기(Load Balancer)의 스위치만 0.1초 만에 딸깍 바꿔치기하는 블루-그린(Blue-Green) 무중단 배포를 몰라, 개발자와 고객 모두가 밤을 새우는 야만 시대의 풍경입니다.

4. Prerequisites

• 빌드 시스템과 도커 (Basic): 불변하는 아티팩트(Image)의 개념. (09-05-02 Artifact Engineering)
• 네트워크와 로드밸런서 (Basic): 트래픽을 서버로 분배하는 원리. (07-02-01 TCP/IP & Load Balancing)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 선언형 인프라와 멱등성 (Declarative IaC & Idempotency)

• Why to Learn: 서버 세팅 과정을 퇴사한 서버 관리자의 뇌에서 끄집어내어 git 저장소에 박제함으로써, 서버가 통째로 불타버려도 단 5분 만에 지구 반대편에 100% 똑같은 인프라를 복제하기 위함입니다.
• What to Learn:
  • Concepts: IaC (Infrastructure as Code), Declarative (선언형) vs Imperative (명령형), Idempotency (멱등성), State Drift (상태 드리프트).
  • Skills: "서버를 하나 더 만들어라(명령)"가 아니라 "서버의 총개수는 3대다(선언)"라고 Terraform 코드를 짜서, 현재 서버가 2대면 1대를 띄우고 4대면 1대를 스스로 부수는 기계의 지능 통제하기.
• How to Learn:
  • 1단계: 명령형의 공포 (Imperative): 쉘 스크립트에 aws ec2 create라고 씁니다. 파이프라인이 꼬여서 이 스크립트가 3번 실행됐습니다. EC2 서버가 3대가 생성되어 요금 폭탄을 맞습니다.
  • 2단계: 선언형의 멱등성 (Declarative): Terraform에 count = 1이라고 씁니다. 코드를 1번 실행하든 100번 실행하든 서버는 무조건 1대만 유지됩니다. 연산(f(x))을 여러 번 해도 결과가 변하지 않는 멱등성(Idempotency)입니다.
  • 3단계: 드리프트 방어 (State Drift): 누군가 몰래 AWS 콘솔에 접속해 서버 1대를 맘대로 수동으로 지웠습니다(상태가 빗나감, Drift). 다음번 IaC 코드가 돌 때 기계가 "어? 선언은 1대인데 실제론 0대네?" 하고 묻지도 따지지도 않고 1대를 다시 살려냅니다. 코드가 인프라의 '법(Law)'이 되는 웅장한 아키텍처를 해부합니다.
• Implement: IaC 상태 동기화(State Reconciliation) 시뮬레이션. IaC Code: AWS_S3_BUCKET: { ACL: Private }. Drift Action: 주니어가 몰래 콘솔에서 ACL을 Public으로 열어버림 (보안 대형 사고). IaC Apply: 파이프라인이 즉각 Drift를 감지하고, 콘솔에서 조작한 설정을 뭉개버린 뒤 다시 Private으로 원상복구. 휴먼 에러를 코드가 무력화시키는 시각화.

Recommended

Core Topic 02: 애완동물과 가축 (Pets vs Cattle & Immutable Infrastructure)

• Why to Learn: 서버에 렉이 걸렸다고 SSH로 접속해 로그를 지우고 아파치(Apache)를 재시작하는 '노가다 운영'을 끝내고, 서버를 쓰다 버리는 소모품(가축)으로 다루는 클라우드 네이티브 철학을 깨닫기 위함입니다.
• What to Learn:
  • Concepts: Mutable vs Immutable Infrastructure, Pets vs Cattle analogy, Snowflake Server, Configuration Drift.
  • Skills: 버그가 났을 때 서버에 들어가 파일 1줄을 수정(Mutable)하는 짓을 멈추고, 소스코드를 고친 뒤 새로운 도커 이미지를 구워서 기존 서버를 부수고 새 서버로 통째 교체(Immutable)하는 파이프라인 태도 장착하기.
• How to Learn:
  • 1단계: 애완동물 (Pets): 과거의 서버는 '애완동물'이었습니다. 서버 이름도 Zeus, Apollo처럼 예쁘게 지어줍니다. 서버가 아프면(에러) 밤새 로그를 보며 간호합니다. 수백 번 수동 패치를 거친 이 서버는 지구상에 똑같은 세팅을 가진 놈이 단 1대도 없는 고유한 눈송이(Snowflake Server)가 되어, 서버가 죽으면 회사가 망합니다.
  • 2단계: 가축 (Cattle): 도커 시대의 서버는 '가축'입니다. 이름은 web-pod-7x2bq 따위의 바코드입니다. 얘가 아프면? 간호하지 않습니다. 그냥 총으로 쏴 죽입니다(Kill). 그리고 1초 만에 옆에 건강한 복제양 돌리(새 컨테이너)를 찍어냅니다.
  • 3단계: 불변 인프라 (Immutable): 한 번 띄운 서버 안의 파일은 단 1바이트도 수정하지 않습니다. 수정이 필요하면 '수정된 새 서버'를 띄우고 옛날 것을 버립니다. 배포의 롤백이 단순히 '옛날 이미지로 서버 띄우기'로 치환되는 완벽한 불변성의 마법을 뜯어봅니다.
• Implement: Configuration Drift 누적의 파국 모델링. Mutable 패턴: 1년 동안 50번의 수동 패치 적용. 결과 $\rightarrow$ 1번 서버와 2번 서버의 패키지 버전이 미세하게 달라짐(Drift). 알 수 없는 간헐적 버그 발생. Immutable 패턴: 패치할 때마다 낡은 컨테이너 파괴 & 동일한 새 컨테이너 2대 띄움. 결과 $\rightarrow$ 1번과 2번 서버가 수학적으로 100% 동일함을 영구 보장(No Drift).

Practical

Core Topic 03: 배포의 스위칭, 무중단 배포 물리학 (Zero-Downtime Deployment)

• Why to Learn: 사용자가 물건을 결제하고 있는데 서버가 재시작되어 "결제 실패"가 뜨는 치명적 매출 손실을 막고, 서버 교체 작업을 0.1초 만에 그림자처럼 해치우기 위함입니다.
• What to Learn:
  • Concepts: Zero-Downtime Deployment, Load Balancer (LB), Reverse Proxy, Connection Draining (Graceful Shutdown).
  • Skills: Nginx나 AWS ALB를 앞단에 세우고, 새 서버(v2)를 뒤에서 조용히 다 띄운 다음 헬스 체크(Health Check)가 200 OK로 떨어지는 순간, 로드밸런서의 화살표(트래픽) 방향만 휙 돌려버리는 구조 설계하기.
• How to Learn:
  • 1단계: 야만적 배포: 서버 종료(kill) $\rightarrow$ (이때부터 유저는 접속 불가) $\rightarrow$ 신규 파일 다운로드 $\rightarrow$ 서버 시작(start). 서버가 켜지는 30초 동안 사용자들은 화를 내며 앱을 지웁니다.
  • 2단계: 블루-그린 (Blue-Green): 현재 유저를 받고 있는 구형 서버(Blue) 100대가 있습니다. 뒤쪽 보이지 않는 곳에 신형 서버(Green) 100대를 완전히 세팅합니다. 테스트도 몰래 해봅니다. 완벽합니다. 로드밸런서에 명령을 내립니다. "지금부터 모든 요청은 Green으로 쏴라." 0.1초 만에 스위칭됩니다. 유저는 아무것도 모릅니다.
  • 3단계: 커넥션 드레이닝 (Connection Draining): 스위칭했다고 Blue를 당장 죽이면 안 됩니다. 스위칭 직전에 Blue에 들어와서 결제 중이던 유저가 억울해집니다. Blue로 들어오는 신규 유저만 막고, 기존 유저의 결제가 끝날 때(Graceful Shutdown)까지 기다려준 뒤 조용히 Blue를 죽이는 세심한 외과 수술을 해부합니다.
• Implement: 무중단 배포(Zero-Downtime) 스위칭 아키텍처 렌더링. T=0s: 유저 트래픽 100% $\rightarrow$ LB $\rightarrow$ Blue(v1.0) T=10s: (뒤에서) Green(v2.0) 기동 및 Health Check(OK) 통과. T=11s: LB 타겟 그룹 전환 $\rightarrow$ 신규 트래픽 100% $\rightarrow$ Green(v2.0) T=30s: Blue에 잔존하던 기존 트랜잭션 종료(Draining 완료) $\rightarrow$ Blue 파괴. 다운타임 0초 달성 증명.

Advanced

Core Topic 04: 전략의 트레이드오프, 롤링 vs 카나리아 (Rolling vs Canary vs Blue-Green)

• Why to Learn: 돈이 넘쳐나서 서버를 2배로 띄우는 Blue-Green을 무작정 썼다가 인프라 비용 폭탄을 맞지 않고, 회사의 예산과 리스크 허용도에 맞춰 배포 전략을 조율하기 위함입니다.
• What to Learn:
  • Concepts: Rolling Update (롤링), Canary Release (카나리아), Blue-Green (블루그린), Blast Radius (영향 반경).
  • Skills: "서버 비용이 부족하다"면 Rolling으로 1대씩 야금야금 교체하고, "버그가 나면 회사가 망하는 기능"이라면 트래픽의 5%만 새 서버로 보내는 Canary 배포로 리스크(Blast Radius)를 쪼개어 검증하기.
• How to Learn:
  • 1단계: Blue-Green (한 방 교체): 최고로 빠르고 롤백(스위치 원복)도 1초 컷입니다. 단점? 서버가 100대라면 교체 순간에 총 200대의 서버 비용을 지불해야 합니다. 돈이 최고인 자본주의의 정점입니다.
  • 2단계: Rolling (순차 교체): 서버가 100대일 때, 10대 죽이고 새 거 10대 띄우기를 10번 반복(Rolling)합니다. 서버는 100~110대 선에서 유지되어 돈을 아낍니다. 단점은 교체 중인 10분 동안 구버전 유저와 신버전 유저가 혼재(Inconsistency)하여 DB 스키마 꼬임 대참사가 일어날 수 있습니다.
  • 3단계: Canary (리스크 분산): 광부들이 탄광에 들어갈 때 가스 중독을 미리 알려고 카나리아 새를 들고 갔습니다. 전체 100대의 서버 중 딱 1대만 새 버전으로 띄웁니다. 트래픽의 1%만 찔끔 보냅니다. 버그가 터지면 그 1%의 유저만 희생(Blast Radius 최소화)됩니다. 로그를 지켜보다가 안전하면 10%, 50%, 100%로 점진적 확장하는 데이터 주도 배포의 극치를 뜯어봅니다.
• Implement: 배포 전략별 트레이드오프 매트릭스 도출. Blue-Green: 배포 속도(빠름), 롤백 속도(1초), 인프라 비용(200%), 두 버전 혼재(없음). Rolling: 배포 속도(느림), 롤백 속도(매우 느림), 인프라 비용(100%), 두 버전 혼재(발생! DB 하위호환성 필수). Canary: 버그 파급력(최소), 에러 모니터링 의존도(극상), 롤백 속도(빠름). 조직의 예산과 아키텍처 성숙도에 맞는 배포 전략 선택 가이드 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Cloud Computing and Infrastructure (IaC)
• [P5] SFIA - IT Operations (ITOP) - Deployment and infrastructure provisioning

Secondary

• [Infrastructure as Code] Kief Morris - Dynamic Systems for the Cloud Age
• [Site Reliability Engineering (Google)] - Release Engineering (Canary, Blue-Green)

Industry

• [AWS Architecture Blog] - Blue/Green Deployments, Canary Deployments, and Rolling Deployments
• [MartinFowler.com] - ImmutableServer, BlueGreenDeployment

9. Final Checklist

Primary

• AWS 콘솔에서 마우스로 생성한 서버 설정이 문서화되지 않아 퇴사자 발생 시 시스템이 '블랙박스'가 되는 재앙을, IaC(Terraform)의 코드화와 Git 버전 관리(History)가 어떻게 근본적으로 해결하는지 설명할 수 있는가?
• 사용자 접속이 폭주하는 오후 2시에 신규 버전을 배포해야 할 때, 서버를 내리고 올리는 10분의 다운타임을 없애기 위해 로드밸런서(LB) 타겟 전환을 이용하는 블루-그린(Blue-Green) 무중단 배포를 설계할 수 있는가?

Secondary

• 쉘 스크립트로 create_server() 명령을 3번 실행하면 서버가 3대가 되는 명령형(Imperative) 방식의 한계를 지적하고, 선언형(Declarative) IaC를 통해 코드를 100번 실행해도 시스템이 정확히 '지정된 상태(State)'를 유지하는 멱등성(Idempotency)을 논증할 수 있는가?
• 서버에 접속해(SSH) hotfix.sh를 실행하여 장애를 해결하는 '가변 인프라(Mutable/Pets)' 문화가 1년 뒤 수백 대의 서버 환경을 각기 다르게 오염(Configuration Drift)시키는 현상을, '불변 인프라(Immutable/Cattle)' 원칙으로 어떻게 박살 내는지 설명할 수 있는가?

Industry

• 인프라 리소스가 한정되어 있어 100대의 서버를 추가로 띄울 수 없는(Blue-Green 불가) 환경에서, 10대씩 순차적으로 교체하는 롤링(Rolling Update) 배포를 채택할 때 "구버전과 신버전이 혼재하는 10분" 동안 DB 스키마 충돌이 나지 않도록 하위 호환성을 설계할 수 있는가?
• 치명적일 수 있는 추천 알고리즘 변경사항을 배포할 때, 카나리아(Canary) 전략을 사용하여 트래픽의 1%만 신규 서버로 라우팅하고, HTTP 500 에러 비율이 평소보다 높게 감지되면 즉각 트래픽을 0%로 롤백하는 메트릭 기반의 자동화 파이프라인을 구축할 수 있는가?