Infrastructure as Code (IaC) & GitOps

1. Overview

인프라 애즈 코드와 깃옵스(Infrastructure as Code & GitOps)는 AWS 콘솔 창을 마우스로 클릭하며 서버를 만들던 "수제 인프라(ClickOps)"의 원시 시대를 종식시키고, 수백 대의 클라우드 서버와 네트워크 망을 코드로 작성(Terraform)하여 Git으로 버전 관리하는 현대 인프라의 자동화 혁명을 해부합니다.

학습자는 누가 언제 AWS 콘솔에서 보안 그룹(방화벽)을 몰래 바꿨는지 추적할 수 없는 재앙을 끝내고, 인프라의 희망 상태(Desired State)를 선언적(Declarative)으로 정의하는 **IaC(Terraform, Pulumi)**의 멱등성(Idempotency) 철학을 뜯어봅니다. 나아가 코드와 실제 인프라 간의 상태 차이(Drift)를 저장하는 **상태 파일(State File)**의 동기화 원리를 장악합니다. 마지막으로, 인프라 코드를 푸시(Push)하는 것을 넘어 쿠버네티스 클러스터 안의 에이전트(ArgoCD)가 Git 저장소를 쳐다보며 현실을 강제로 동기화(Pull)시켜 버리는 GitOps의 무자비한 인프라 통제 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• IaC (Infrastructure as Code): Declarative(선언형) vs Imperative(명령형), Terraform, Immutable Infrastructure.
• State Management: Terraform State File (.tfstate), State Lock (원격 상태 잠금), Drift(형상 불일치).
• GitOps: Push vs Pull 배포 모델, Git as a Single Source of Truth (SSOT), ArgoCD, Flux.
• Drift Detection & Reconciliation: 수동 변경(ClickOps)에 대한 자동 복구 루프.

Out-of-Scope

• Terraform 벤더 특정 문법(HCL): AWS VPC를 띄우는 복잡한 모듈 짜기 $\rightarrow$ 인프라 엔지니어링 실습 영역.
• CI/CD 파이프라인(Jenkins, GitHub Actions): CI 빌드와 테스트 중심의 통합 $\rightarrow$ 09-02 CI/CD & DevOps 영역으로 위임 (본 문서는 CD 중에서도 인프라 쪽에 집중).

Boundaries

• IaC vs Configuration Management: Terraform(IaC)은 서버 자원(EC2, RDS) 자체를 "새로 띄우고 지우는(Provisioning)" 데 특화되어 불변 인프라(Immutable)를 추구합니다. 반면 Ansible, Chef 같은 도구는 이미 떠 있는 서버 안에 접속해서 "패키지를 설치하고 설정을 바꾸는(Configuration)" 가변 인프라(Mutable)에 특화되어 있습니다. 컨테이너 시대에는 설정이 변경되면 컨테이너를 새로 띄우므로, Ansible의 역할이 줄어들고 Terraform과 Kubernetes의 결합이 표준이 되었음을 명확히 경계 짓습니다.

3. Counterexample

• 클릭옵스(ClickOps)의 비극: 개발 서버와 운영 서버를 AWS 콘솔에서 마우스 클릭으로 만들었습니다. 1년 뒤, 두 서버 간에 알 수 없는 설정 차이(Configuration Drift)가 50개가 넘습니다. 운영 서버에 장애가 터졌을 때 "어떤 포트를 열어뒀었지?" 아무도 기억하지 못해 인프라를 복원하는 데 3일이 걸립니다. 인프라를 코드(IaC)로 기록하지 않아 재현성(Reproducibility)과 재해 복구(DR) 능력을 완벽히 상실한 안티 패턴입니다.
• 상태 파일(State File) 충돌의 호러쇼: 테라폼(Terraform) 코드를 짜서 팀원 3명이 각자의 로컬 노트북에서 terraform apply를 때립니다. A가 AWS에 만든 DB를 테라폼 상태 파일(State)로 자기 컴퓨터에만 저장했습니다. B는 그 상태를 모르고 다시 apply를 쳤다가 기존 DB를 날려 먹습니다. IaC의 핵심인 상태 파일(.tfstate)을 S3나 원격 저장소에 올리고 Lock(잠금) 장치를 걸지 않아 인프라 동기화가 완전히 파괴된 대참사입니다.

4. Prerequisites

• 클라우드 컴퓨팅 (Basic): AWS 리소스(VPC, EC2) 개념. (03-02 Networking Basics)
• 버전 관리 (Basic): Git의 커밋과 롤백. (09-01 Source Control)
• 쿠버네티스 선언형 철학 (Basic): Desired State. (07-06-03 Kubernetes)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 수제 인프라의 종말, IaC (Infrastructure as Code)

• Why to Learn: 휴먼 에러 투성이인 마우스 클릭(AWS 콘솔)을 금지하고, 인프라의 모든 스펙을 코드로 박제하여 언제든 100% 동일한 환경을 0.1초 만에 복제해 내기 위함입니다.
• What to Learn:
  • Concepts: IaC, Terraform(HCL), Declarative vs Imperative, Idempotency (멱등성), Reproducibility (재현성), Immutable Infrastructure.
  • Skills: 인프라 배포 코드화를 통한 개발 환경(Dev)과 운영 환경(Prod)의 완벽한 동일성(Parity) 유지.
• How to Learn:
  • 1단계: 명령형 스크립트의 공포: create_server.sh를 2번 실행했습니다. 서버가 2대 생깁니다. 3번 누르면 3대가 생깁니다. 여러 번 실행하면 시스템 상태가 꼬여버리는 멱등성 결여의 한계를 해부합니다.
  • 2단계: 선언형(Declarative) IaC: 테라폼 코드에 "나는 서버 3대를 원한다"고 선언합니다. terraform apply를 1번 치면 서버 3대가 뜹니다. 10번을 더 쳐도 "이미 3대 있습니다" 하고 아무 짓도 안 합니다(멱등성). 코드가 곧 인프라의 최종 형태를 강제하는 기적을 뜯어봅니다.
• Implement: 멱등성 보장 인프라 프로비저닝 봇(파이썬). Target_State = {'Web': 3, 'DB': 1}. 현재 클라우드의 상태를 딕셔너리로 읽어옴. Apply() 호출 시, 부족한 서버는 띄우고(Create), 초과된 서버는 날려버려(Destroy) 반드시 Target_State와 일치시키는 Reconciliation 로직 시뮬레이션.

Recommended

Core Topic 02: 인프라의 뇌, 상태와 드리프트 (The State & The Drift)

• Why to Learn: 테라폼이 수만 개의 클라우드 리소스를 꼬이지 않고 추적(Tracking)하는 뇌(State)의 작동 방식을 이해하여, 인프라 동기화 붕괴 대참사를 막기 위함입니다.
• What to Learn:
  • Concepts: Terraform State File (.tfstate), Remote State (원격 저장소 - S3 백엔드), State Lock (DynamoDB), Configuration Drift (형상 드리프트).
  • Skills: 여러 명의 SRE 팀원이 동시 작업할 때 tfstate 충돌을 막는 State Lock 아키텍처 세팅.
• How to Learn:
  • 1단계: 상태 파일(State)의 본질: 테라폼은 방금 자기가 만든 AWS EC2의 고유 ID(i-1234abcd)를 terraform.tfstate라는 로컬 파일에 몰래 적어둡니다(기억력). 다음에 실행할 때 이 파일을 보고 "아, 이 코드는 저 EC2를 가리키는 거구나"라고 매핑하는 핵심 두뇌를 해부합니다.
  • 2단계: 드리프트(Drift)와 무자비한 복원: 누군가 급하다고 AWS 콘솔에 들어가서 DB 포트를 열었습니다. 테라폼 코드에는 닫혀 있습니다. terraform plan을 치면 테라폼이 "어라? 내 기억(State)이랑 실제 AWS 현실이 다르네?(Drift 발생)"라고 경고합니다. apply를 치면 테라폼이 수동 변경 사항을 무자비하게 덮어써서 다시 코드 상태로 강제 복원시키는 철권통치를 뜯어봅니다.
• Implement: 드리프트 감지(Drift Detection) 툴 시뮬레이터. Code_State = {port: 80}, Cloud_State = {port: 8080}. 두 딕셔너리를 diff 비교하여 [DRIFT DETECTED] Port changed outside of IaC 경고를 뿜어냄. 이후 Sync 액션 발동 시 Cloud_State를 무조건 Code_State의 값으로 오버라이트(Overwrite)해 버리는 콘솔 데모.

Practical

Core Topic 03: 배달부와 스파이, Push vs Pull (GitOps)

• Why to Learn: CI/CD 서버(Jenkins)가 털리면 쿠버네티스 클러스터까지 통째로 털리는 보안 구멍을 막고, K8s 내부에서만 돌아가는 안전한 자동 배포 패러다임을 장악하기 위함입니다.
• What to Learn:
  • Concepts: GitOps, Push Model (CI/CD 중심), Pull Model (Agent 중심), ArgoCD, Flux, Continuous Deployment (CD).
  • Skills: ArgoCD를 K8s 내부에 설치하여 Git 저장소의 변동 사항을 자동으로 감지하고 Pull(당겨오는) 파이프라인 설계.
• How to Learn:
  • 1단계: Push 모델의 불안함: 기존에는 Jenkins(외부)가 빌드를 끝내고 kubectl apply를 날려 K8s(내부)로 코드를 밀어 넣습니다(Push). 이를 위해 Jenkins에게 K8s 최고 관리자 권한(Admin)을 줘야 합니다. Jenkins가 해킹당하면 클러스터 전체가 장악당하는 보안 위험을 해부합니다.
  • 2단계: Pull 모델 (스파이 에이전트): GitOps는 다릅니다. 외부에서 아무도 못 들어옵니다. 대신 K8s 클러스터 '안'에 ArgoCD라는 요원(Agent)을 심어둡니다. 이 요원이 1분마다 Git(GitHub)을 쳐다보다가 "어? YAML 파일 버전 올랐네?" 하고 자기가 코드를 안으로 당겨옵니다(Pull). 클러스터 외부로 권한을 줄 필요가 없는 궁극의 인프라 격리 통제를 뜯어봅니다.
• Implement: Push vs Pull 배포 아키텍처 비교 콘솔 로그.
  • Push: [Jenkins(External)] -> [AUTH: Root Token] -> [K8s(Internal)] (보안 위험 경고)
  • Pull: [ArgoCD(Internal)] -> [Poll Git Repo every 60s] -> [YAML Changed] -> [Self-Apply] (내부 방화벽 차단 상태에서의 배포 성공 렌더링).

Advanced

Core Topic 04: 절대 진리, 단일 진실 공급원 (The Ultimate SSOT)

• Why to Learn: "서버 장애 났어! 어제 상태로 당장 롤백해!"라는 다급한 외침에, 콘솔을 뒤지는 대신 git revert 명령어 단 한 방으로 인프라 전체를 과거로 되돌리는 데브옵스의 끝판왕을 맛보기 위함입니다.
• What to Learn:
  • Concepts: Single Source of Truth (SSOT), Git as SSOT, Infrastructure Rollback, Disaster Recovery (DR), Audit Trail (감사 추적).
  • Skills: Git 커밋 히스토리를 통한 인프라 변경 이력(누가/언제/왜) 강제 추적 및 장애 시 Git 롤백을 통한 초고속 인프라 DR(재해 복구) 실행.
• How to Learn:
  • 1단계: 재해 복구(DR)의 지옥: 해커가 침입해 K8s 클러스터를 싹 다 지웠습니다. 수동으로 복구하려면 수백 개의 설정(YAML)을 기억해 내어 다시 타이핑해야 합니다. 회사가 망할 수도 있습니다.
  • 2단계: Git은 모든 것을 기억한다: 인프라의 모든 정보(네트워크, DB 셋업, 앱 배포)가 오직 Git(YAML/Terraform)에만 저장되어 있습니다(SSOT). 클러스터가 날아가면? 텅 빈 새 클러스터를 만들고 요원(ArgoCD)을 켠 뒤 "저 Git 주소 쳐다봐"라고 한 줄만 치면 끝입니다. 요원이 Git 코드를 쫙 빨아들여 3분 만에 모든 인프라와 앱을 파괴되기 직전과 100% 똑같이 재건(Rebuild)해 내는 소름 돋는 복원력을 뜯어봅니다.
• Implement: Git 기반 롤백 시뮬레이터. Commit_v1(안정), Commit_v2(장애 유발) 상태. 인프라가 v2로 동기화되어 [CRASH] 상태. 유저가 터미널에 git revert HEAD를 침. Git 상태가 Commit_v1으로 돌아감. 인프라 요원 봇이 이를 즉각 감지하고 인프라 설정을 v1으로 덮어써서 [RECOVERY SUCCESS]를 출력하는 무자비한 Git 주도(Git-driven) 오퍼레이션.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Cloud Computing and Infrastructure as Code
• [P5] SFIA - Systems Installation and Removal (ITOP) - Infrastructure Provisioning

Secondary

• [Infrastructure as Code] Kief Morris - Dynamic Systems for the Cloud Age
• [GitOps and Kubernetes] Billy Yuen et al. - Continuous Deployment with Argo CD, Jenkins X, and Flux

Industry

• [HashiCorp Terraform Documentation] - State and Workspaces
• [Weaveworks Blog] - Guide To GitOps

9. Final Checklist

Primary

• AWS 콘솔에서 마우스로 인프라를 생성하는 수작업(ClickOps)이 재현성(Reproducibility)과 추적성을 어떻게 박살내는지 지적하고, 이를 코드로 선언하는 IaC(Terraform)의 멱등성(Idempotency) 우위를 증명할 수 있는가?
• 테라폼(Terraform)을 사용할 때, 로컬과 클라우드의 형상 차이를 기록하는 뇌 역할인 상태 파일(State File, .tfstate)의 위험성을 식별하고, S3 백엔드와 DynamoDB Lock을 통해 동시성 붕괴(State Corruption)를 막는 설계를 해부할 수 있는가?

Secondary

• Jenkins와 같은 전통적인 외부 CI/CD 도구가 kubectl apply를 강제로 밀어 넣는 푸시(Push) 배포 모델의 보안 리스크를 설명하고, ArgoCD와 같은 요원이 K8s 내부에서 Git을 쳐다보며 가져오는 풀(Pull) 배포 모델의 아키텍처적 승리를 논증할 수 있는가?
• 팀원이 급하다고 AWS 콘솔에 접속해 수동으로 방화벽(Security Group)을 열었을 때, 테라폼의 terraform plan이나 GitOps 에이전트가 이 설정 불일치(Drift)를 어떻게 탐지하고 무자비하게 원상 복구(Reconciliation)시키는지 평가할 수 있는가?

Industry

• "모든 인프라의 상태는 Git에 존재한다(SSOT)"는 GitOps의 원칙하에, 장애(Incident) 발생 시 SSH로 서버에 들어가 핫픽스(Hotfix)를 치는 대신 git revert 명령어 단 한 방으로 전체 인프라를 이전 상태로 완벽히 롤백하는 재해 복구(DR) 파이프라인을 설계할 수 있는가?
• 여러 개의 클라우드(AWS, GCP, 온프레미스 K8s)를 넘나드는 멀티 클라우드(Multi-Cloud) 환경에서, 테라폼 리소스(Provider) 추상화와 K8s 매니페스트(YAML)를 결합하여 인프라 종속성(Vendor Lock-in)을 분리해 내는 클라우드 네이티브 아키텍처를 세울 수 있는가?