Infrastructure as Code (IaC) & GitOps

1. Overview

인프라 코드화 및 GitOps(Infrastructure as Code & GitOps, IAG)는 수작업으로 이루어지던 하드웨어 구성을 소프트웨어 개발의 정밀한 공정으로 끌어들여, 인프라의 생성, 수정, 삭제를 '실행 가능한 도면'으로 제어하는 아키텍처의 자동화 혁명입니다.

학습자는 인프라의 현재 상태를 코드로 선언하고 이를 실제 하드웨어와 일치시키는 IaC의 선언적 수리 모델을 배웁니다. 특히, Git 저장소를 시스템의 '유일한 진실 저장소(SSOT)'로 삼아 코드가 바뀌는 즉시 인프라를 동기화하는 GitOps의 물리적 루프를 익힙니다. 이를 통해 '사람의 실수'가 개입할 틈을 물리적으로 차단하고, 수천 개의 서버를 버튼 하나로 똑같이 복제하고 관리하는 하이엔드 인프라 자율 주행 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• IaC Principles: 선언적(Declarative) vs 명령적(Imperative) 인프라 구성 물리학
• State Management: 인프라의 현재 기록을 담는 상태 파일($State File$)의 관리와 잠금 기제
• GitOps Methodology: Pull-based vs Push-based 배포 모델의 수리적 차이
• Idempotency: 코드를 여러 번 실행해도 하드웨어 상태가 동일하게 유지되는 수리적 불변성
• Drift Detection: 실제 인프라와 코드 도면 사이의 물리적 간극 감지 및 교정

Out-of-Scope

• 구체적인 Terraform이나 Ansible의 고급 문법 상세 (하부 도구 영역으로 위임)
• CI/CD 파이프라인의 일반적인 애플리케이션 빌드 상세 (09-03-XX 영역에서 분담)

Boundaries

• IAG vs. Container Orchestration: 쿠버네티스(07-06-03)가 '컨테이너들의 생사'를 관리한다면, IAG는 '전체 클라우드 인프라(VPC, DB, K8s 자체)의 도면'을 관리하는 더 상위의 물리 통제권으로서 구분합니다.

3. Counterexample

• 단순히 "스크립트로 인프라 만들기"라 설명하는 것은 IAG 학습이 아닙니다. 왜 **상태 관리(State Management)**가 없는 IaC가 실제 하드웨어와의 동기화 실패를 초래하는 물리적 위험 요소가 되는지 수리적으로 증명할 수 있어야 하며, GitOps 도입 시 '변경 이력'이 없는 수동 조작(Click-ops)이 전체 시스템의 '신뢰의 사슬'을 어떻게 물리적으로 끊어버리는지 논증하지 못한다면 IAG의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Reliability Engineering & SRE Fundamentals (Basic): 자동화와 가용성 지표 이해가 필수입니다. (07-05-01 SSE)
• Containerization & Docker Mechanics (Recommended): 불변 인프라(Immutable Infra) 개념 이해가 권장됩니다. (07-06-02 CDM)

5. Learning Map

1. Blueprint over Manual: 손으로 서버를 만지는 물리적 비효율을 버리고, '도면(Code)'을 정의합니다.
2. State Synchronization: 도면과 실제 하드웨어 사이의 상태를 수리적으로 일치시키는 법을 배웁니다.
3. Git as the Governor: Git의 Commit이 곧 인프라의 '법(Law)'이 되는 자동화 루프를 가공합니다.
4. Autonomous Infrastructure: 코드가 바뀌면 하드웨어가 스스로 반응하여 변신하는 자율 운영의 극치를 완성합니다.

6. Learning Topics

Basic

Core: IaC의 선언적 수리 모델 (Declarative IaC)

• Why to Learn: 수천 대의 서버 설정을 눈으로 확인하지 않고도 코드로 확신하기 위해서입니다.
• What to Learn:
  • Declarative Approach: 최종 결과물(Desired State)만 수리적으로 기술하는 방식
  • IaC Lifecycle: Plan(계획) -> Apply(적용) -> Destroy(삭제)의 물리적 수순
  • Provisioning vs Configuration: 장비를 만드는 것과 장비 안을 채우는 것의 하드웨어적 구분
• How to Learn:
  • Terraform을 이용해 VPC 전용 네트워크를 5분 만에 구축하고, 코드를 수정하여 서브넷을 물리적으로 늘리는 실습
  • 명령형 스크립트와 비교했을 때 '멱등성(Idempotency)'이 보장되는 수리적 안정성 확인
• Implement: 특정 클라우드 리소스를 정의하는 기초 main.tf 명세서

Recommended

Core: 상태 관리와 드리프트 감지 (State Management)

• Why to Learn: 코드만 믿다가 실제 인프라와 꼬여서 하드웨어가 삭제되는 대참사를 물리적으로 막기 위함입니다.
• What to Learn:
  • state File Mechanics: 코드가 만든 결과물을 기억하는 하드웨어 장부
  • Remote State & Locking: 협업 시 동시에 인프라를 건드리지 못하게 막는 수리적 잠금
  • Drift Detection: 도면과 실물 사이의 수치적 오차를 찾아내는 물리 기작
• How to Learn:
  • 콘솔에서 수동으로 리소스 이름을 바꾼 뒤, terraform plan이 이 '오차(Drift)'를 어떻게 짚어내는지 관찰 실습
  • 상태 파일이 유실되었을 때 인프라 복구가 왜 수리적으로 불가능해지는지 시나리오 분석
• Implement: 상태 파일을 S3 등 원격 저장소에 안전하게 보관하는 Backend 설정

Practical

Core: GitOps와 자동화 루프 (GitOps Mechanics)

• Why to Learn: "누가 배포했나?" 대신 "어떤 커밋이 반영됐나?"로 인프라의 투명성을 물리적으로 확보하기 위함입니다.
• What to Learn:
  • Single Source of Truth: 인프라의 모든 진실은 Git에 있다는 수리 철학
  • Continuous Reconciliation: Git과 하드웨어를 무한히 비교하고 맞추는 물리 루프 (ArgoCD 등)
  • Pull-based vs Push-based: 보안과 확장성에 따른 배포 통신 물리학
• How to Learn:
  • Git 리포지토리의 레플리카 개수를 3에서 5로 바꿨을 때, 오퍼레이터가 이를 감지하고 하드웨어에 반영하는 과정 추적 실습
  • 잘못된 코드가 머지되었을 때 git revert 만으로 인프라가 이전 물리 상태로 복구되는지 검증
• Implement: ArgoCD 등을 활용해 특정 Git 경로의 소스를 클러스터에 동기화하는 설정

Advanced

Core: 정책 기반 코드와 가드레일 (Policy as Code)

• Why to Learn: 실수로 '전 세계에 열린 보안 그룹' 같은 위험한 도면을 인프라에 반영하는 것을 물리적으로 전수 차단하기 위함입니다.
• What to Learn:
  • PaC (Policy as Code): 인프라 코드가 준수해야 할 규칙을 또 다른 코드로 검증 (OPA 등)
  • Infrastructure Testing: 도면이 하드웨어에 적용되기 전 수행하는 수리적 시뮬레이션
  • Automated Cleanup: 사용하지 않는 하드웨어 자원을 코드로 감지하여 자동 삭제하는 물리 루틴
• How to Learn:
  • "Public IP가 부여된 인스턴스 생성 금지" 규약을 수치로 정의하고, 위반된 IaC 코드가 '배포 전'에 차단되는 실습
  • 거대 클러스터의 '인프라 회계($FinOps$)' 지표를 코드로 산출하여 낭비되는 예산 파악
• Implement: 생성될 리소스의 태그(Tag) 존재 여부를 자동으로 감사하는 Linting 규칙 정의

7. Terminology

8. References

Primary

• [P5] SFIA v9 - IT Infrastructure (Application support / Infrastructure build and configuration) — Management context.
• [P2] SWEBOK v4.0 - Software Configuration Management / Management of the SCM Process (Automated configuration) — Structural context.

Secondary

• [Infrastructure as Code] Kief Morris — The standard text on the subject.
• [GitOps: Cloud-native Continuous Deployment] Florian Beutler — Practical GitOps implementation.

Industry

• [Terraform by HashiCorp: Official Documentation] — Leading IaC tool guide.
• [Open Policy Agent (OPA): Documentation] — Standard for Policy as Code.

9. Final Checklist

Primary

• '선언적(Declarative) 인프라 코드'가 왜 '명령적 스크립트'보다 물리적 변경 관리에 수리적으로 유리한지 설명 가능한가? (P5)
• 'IaC'를 통해 동일한 하드웨어 환경을 전 세계 여러 리전에 '동시에 복제'할 때 발생하는 수리적 병목을 기술할 수 있는 가? (P5)

Secondary

• '상태 파일(State File)'이 오염되거나 유실되었을 때, 기존 리소스의 물리적 통제권을 어떻게 수리 복구($Import$)하는지 소통 가능한가?
• GitOps 모델에서 '수동 조작'이 금지되어야 하는 보안적/운영적 필연성을 논증할 수 있는 가?

Industry

• 서비스 운영 중 '인프라 비용'이 예산을 초과할 때, IaC 코드를 분석하여 하드웨어 리소스를 물리적으로 최적화($Rightsizing$)하는 방안을 제안할 수 있는 가? (SFIA)
• '정책 기반 코드(PaC)'를 도입하여 특정 보안 취약점이 포함된 인프라 배포를 물리적으로 자동 거부($Reject$)하는 절차를 분석할 수 있는 가?