IaC & Deployment Physics

1. Overview

IaC 및 배포 물리학(IaC & Deployment Physics, IDP)은 구부러진 전선과 뜨거운 서버 장비를 차가운 논리의 줄글(Code)로 가상화하고, 수만 대의 하드웨어에 수 밀리초 만에 새로운 영혼(Software)을 불어넣는 '인프라 형상 및 전달 공학'입니다.

학습자는 하드웨어 구성을 수리적으로 명세하는 **IaC (Infrastructure as Code)**의 선언적 물리 모델과, 배포 시 한 대씩 순서대로 갈아끼우는 **롤링 배포(Rolling)**의 수치적 안정성을 배웁니다. 특히, 작업 전후의 인프라 상태를 동일하게 유지하는 멱등성(Idempotency) 수리 원칙과, 트래픽을 한순간에 물리적으로 옮기는 블루-그린(Blue-Green) 배포의 물리학을 익힙니다. 이를 통해 '손으로 한 작업'이 없는 100% 재현 가능한 클라우드 인프라와 무충돌 배포 거버넌스 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Provisioning Mechanics: 테라폼(Terraform) 등을 통한 하드웨어 자원의 수리적 할당 수순
• Configuration Management: 앤서블(Ansible)을 활용한 하드웨어 내부 OS 상태의 물리적 동기화
• Deployment Strategies: Blue-Green, Rolling, Canary 배포의 물리적 트래픽 전환 모델
• State Management: 인프라의 현재 수치를 기록하는 상태 파일($State File$)의 무결성 보호
• Rollback Dynamics: 배포 실패 시 이전 물리 상태로 즉각 회귀하는 수리적 가용성 확보

Out-of-Scope

• 퍼블릭 클라우드(AWS, Azure)의 특정 서비스 UI 대시보드 사용법 (클라우드 노드에서 분담)
• 어플리케이션 소스 코드 자체의 빌드 및 패키징 (09-03-02 BAE 영역에서 분담)

Boundaries

• IDP vs. BAE: BAE(09-03-02)가 '파일 덩어리'를 만드는 데 집중한다면, IDP는 그 덩어리가 '안착할 하드웨어 땅'을 다지고 '안전하게 이사시키는 과정'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "스크립트로 서버 띄우기"라 설명하는 것은 IDP 학습이 아닙니다. 왜 IaC에서 'Immutable Infrastructure' 모델을 택해야 하드웨어마다 미세하게 설정이 달라지는 '구성 드리프트($Drift$)'를 물리적으로 근절할 수 있는지 증명할 수 있어야 하며, 블루-그린 배포 시 DB 스키마 변경이 왜 '하위 호환성' 수리 정책 없이는 물리적 데이터 파괴를 일으키는지 논증하지 못한다면 IDP의 본질을 이해하지 못한 것입니다.

4. Prerequisites

• Build Systems & Artifact Engineering (Basic): 09-03-02의 실행 파일 및 이미지 이미지 이해가 필수입니다.
• Operating Systems & System Mechanics (Recommended): 03-03-XX 가상화 및 컨테이너 물리 기초 이해가 권장됩니다.

5. Learning Map

1. Hardware as Logic: 서버를 물리적 장비가 아닌 '수리적 변수'로 취급하는 인식의 전환을 시작합니다.
2. Infrastructure Assembly: 코드를 실행하여 허공에 가상의 하드웨어 성벽(Network, Server)을 쌓습니다.
3. The Deployment Dance: 구버전과 신버전이 하드웨어 위에서 서로 충돌하지 않고 교대하는 우아한 수순을 배웁니다.
4. Resilient Empire: 코드 한 줄로 대륙 전체의 인프라를 순식간에 복제하고 복구하는 하이엔드 전술을 완성합니다.

6. Learning Topics

Basic

Core: 인프라의 코드화와 선언적 명세 (IaC Foundations)

• Why to Learn: 매번 서버를 클릭해서 만들면 실수할 확률이 100%이므로, 물리적인 재현성을 확보하기 위함입니다.
• What to Learn:
  • Declarative vs Imperative: '어떤 모양이어야 한다'와 '어떻게 만들어라'의 수리적 차이
  • Idempotency in IaC: 몇 번을 실행해도 동일한 물리 형상에 도달하는 성질
  • Provider & Resource: 클라우드 하드웨어를 수리적으로 정의하는 추상화 계층
• How to Learn:
  • 테라폼으로 가상 서버 1대를 띄우고, 코드를 수정하지 않고 다시 실행했을 때 "순수 변화 없음(No changes)"을 확인하는 멱등성 실험 실습
  • GUI로 만든 서버와 코드로 만든 서버의 '차이(Drift)'를 수치적으로 발견하는 훈련
• Implement: 특정 하드웨어 스펙을 입력하면 테라폼 코드를 생성해주는 기초 InfraScaffold

Recommended

Core: 배포 전략과 트래픽 제어 (Deployment Mechanics)

• Why to Learn: 배포 중에 사용자가 에러 페이지를 한 번도 보지 않게 물리적으로 설계하기 위해서입니다.
• What to Learn:
  • Rolling Update: 서버를 순차적으로 끄고 켜는 물리적 교체 수순
  • Blue-Green: 두 개의 하드웨어 팜 사이에서 트래픽을 단번에 스위칭하는 법
  • Health Check Gates: 신규 하드웨어가 정상일 때만 트래픽을 열어주는 수리적 안전장치
• How to Learn:
  • 로드밸런서 배후의 서버 2대를 대상으로, Blue-Green 배포 시의 '0% 다운타임'을 가용성 수치($Uptime$)로 증명하는 실습
  • 배포 중에 특정 노드에서 발생하는 에러율($Error Rate$)을 감시하여 자동 롤백되는 물리 루프 시뮬레이션
• Implement: 현재 하위 노드들의 버전과 건강 상태를 합산하여 배포 성공 여부를 판별하는 DeploymentJudge

Practical

Core: 구성 관리와 상태 유지보수 (Configuration & State)

• Why to Learn: 서버 대수가 늘어날 때마다 기하급수적으로 증가하는 설정 관리의 물리적 한계를 극복하기 위함입니다.
• What to Learn:
  • State File Integrity: 인프라의 '기억'을 담은 파일이 오염되었을 때의 물리적 후폭풍
  • Push vs Pull Config: 앤서블(Agentless)과 셰프(Agent-based)의 하드웨어 전송 기제 비교
  • Secret Management: 인프라 코드에 암호를 쓰지 않고 물리적으로 주입받는 보안 수순
• How to Learn:
  • 상태 파일($State$)을 수동으로 조작한 후, 실제 하드웨어 자원이 무차별적으로 삭제되는 '재앙 상황' 복구 실험 실습
  • 앤서블 플레이북을 통해 10대의 가상 장비에 동시에 특정 소프트웨어를 설치하는 시간($T$) 효율 측정
• Implement: 인프라 코드를 스캔하여 평문으로 노출된 암호 패턴을 찾아내는 IdentiScan

Advanced

Core: 불변 인프라와 하이엔드 가용성 (Immutable Governance)

• Why to Learn: 운영 중인 서버에 접속해서 고치는 행위를 물리적으로 금지해, 인프라의 엔트로피 증가를 차단하기 위함입니다.
• What to Learn:
  • Immutable Architecture: 고치는 것이 아니라 '부수고 새로 띄우기'의 수리적 안정성
  • Multi-region DR: 대륙 규모의 하드웨어 장애 시 다른 거점으로 인프라를 즉시 전이하는 물리학
  • Automated Drift Detection: 코드와 실제 하드웨어의 수치적 괴리를 24시간 감시하는 법
• How to Learn:
  • 고장 난 서버의 SSH 접속을 끊고, 신규 서버로 즉시 교체($Replacement$)했을 때 가용 영역($AZ$) 내 부하 분산 변화 분석 실습
  • 'Chaos Monkey'를 활용해 무작위로 하드웨어를 파괴하고, IaC에 의해 시스템이 수리적으로 자기복구되는 과정 연구
• Implement: 전체 인프라의 '코드 일치율(Consitency Score)'을 산출하여 거버넌스 등급을 매기는 InfraAuditor

7. Terminology

8. References

Primary

• [P1] CS2023 - NC/Networking and Communication (Network management and monitoring) — Resource management.
• [P5] SFIA v9 - Software Engineering / Methods and tools (Systems installation/decommissioning) — Deployment skills.

Secondary

• [Infrastructure as Code] Kief Morris — The standard book for IaC.
• [Terraform: Up & Running] Yevgeniy Brikman — Practical application.

Industry

• [HashiCorp: The Tao of HashiCorp] — Philosophy of IaC.
• [Google SRE: Canary Analysis and Rollouts] — High-scale deployment patterns.

9. Final Checklist

Primary

• 'IaC'에서 '선언적 방식'이 '명령적 방식'보다 하드웨어 형상 불일치를 물리적으로 왜 더 잘 방지하는지 설명 가능한가? (P1)
• '무중단 배포' 성공을 위해 서비스의 'Liveness/Readiness' 프로브 수치가 어떻게 배포 물리와 결합되는지 기술할 수 있는 가? (P1)

Secondary

• '테라폼'의 상태 파일($State$)이 분실되었을 때, 실제 클라우드 하드웨어 자원이 '고아($Orphan$)' 상태가 되는 과정을 소통 가능한가?
• 블루-그린 배포 시 이전 버전으로의 물리적 복귀(Rollback)가 1초 안에 가능하도록 만드는 하드웨어 수리 수순을 논증할 수 있는 가?

Industry

• 복잡한 마이크로서비스 환경에서 'Canary' 배포의 노출 비중($5\% \rightarrow 10\% \dots$)을 결정하는 수리적 근거를 제안할 수 있는 가? (SFIA)
• 앤서블 플레이북의 멱등성 파괴를 유발하는 shell 모듈 사용을 지양해야 하는 물리적 필연성을 분석할 수 있는 가?