IaC 오리엔테이션

학습 목표

Infrastructure as Code(IaC) 가 풀려는 문제를 설명할 수 있다.

Terraform·CDK·Serverless·GitOps·CD가 각각 어떤 계층·변경 주기를 담당하는지 구분할 수 있다.

desired state → plan → apply/sync → drift 루프를 설명할 수 있다.

플랫폼 시리즈에서 본 IaC·GitOps 개요와 본 시리즈의 심화 범위 차이를 설명할 수 있다.

22편 로드맵을 보고 학습 순서를 잡을 수 있다.

문제 상황

• VPC·RDS·IAM을 콘솔로 만들고, 6개월 뒤 누가 security group을 열었는지 모른다
  • 변경 이력이 클릭 로그에만 있고 코드·PR에 없다
• staging은 Terraform, prod는 수동 — 같은 모듈인데 변수·버전이 어긋난다
• terraform apply를 두 명이 동시에 실행해 state 충돌·리소스 이중 생성
• K8s는 GitOps인데 클라우드 네트워크는 여전히 스프레드시트와 콘솔
• Lambda·API Gateway를 콘솔 위저드로 배포 — 로컬과 prod SAM template 불일치
• CI는 이미지 빌드까지만 하고, 프로덕션 승격·canary·롤백은 Slack·수동 kubectl
• Argo CD OutOfSync — 런타임에서 kubectl edit 한 흔적을 코드로 되돌릴 규칙이 없다

앞서 플랫폼 · DevOps · Cloud 시리즈에서 컨테이너·K8s·CI/CD·IaC와 GitOps 개요까지 봤다. 본 시리즈는 인프라·서버리스·배포 파이프라인을 코드와 거버넌스 관점에서 전편 다룬다.

1. IaC란?

• Infrastructure as Code
  • 인프라·설정을 파일로 선언하고, 도구가 실제 상태와 맞춘다
  • 변경은 PR·리뷰·plan을 거친다 — 콘솔 즉시 클릭이 기본이 아니다

	수동 운영	IaC
진실의 원천	콘솔·머릿속	Git·코드
변경	즉시 적용	plan으로 diff 확인 후 apply
재현	환경마다 다름	동일 코드 → 동일 결과(멱등)
감사	산재한 로그	commit·PR history

desired state (HCL · CDK · YAML · SAM in Git)
        ↓ plan / diff
actual state (cloud API · K8s API · Lambda)
        ↓ apply / sync
actual ← desired  (drift면 Git으로 되돌림)

• 선언적(declarative)
  • "어떻게 클릭할지"가 아니라 최종 상태를 적는다
  • K8s manifest·Terraform resource·CDK construct가 같은 철학
• 멱등성(idempotent)
  • 같은 plan을 다시 apply해도 이미 맞으면 변경 없음
• 버전 관리
  • 인프라 변경이 앱 코드와 같은 리뷰·롤백 흐름을 탄다

2. 시리즈가 다루는 다섯 축

도구 이름은 바뀌어도 역할 분리는 유지된다.

축	담는 문제	대표 도구(본 시리즈)
Terraform	VPC·RDS·IAM 등 클라우드 프로비저닝	HCL, provider, state, module
AWS CDK	타입·로직이 있는 인프라 코드	Construct, synthesis → CloudFormation
Serverless	이벤트·FaaS 워크로드 배포	Lambda, API Gateway, SAM
GitOps	클러스터·manifest reconcile	Argo CD, Flux, desired in Git
CD	빌드 이후 승격·배포·거버넌스	progressive delivery, 승인 게이트

• Terraform vs CDK
  • 둘 다 클라우드 IaC — 언어·상태·추상화가 다름
• GitOps vs Terraform
  • Terraform은 주로 클라우드 리소스 생성
  • GitOps는 이미 있는 클러스터 안 desired state 지속 동기화
  • 실무에서는 Terraform으로 클러스터·네트워크, GitOps로 워크로드 조합이 흔하다
• Serverless
  • 컨테이너/K8s와 다른 배포 단위 — cold start·이벤트·IAM boundary
• CD
  • CI(빌드·테스트)와 구분 — 언제·어떻게 프로덕션에 올릴지

3. Platform 시리즈와의 관계

Platform에서 본 것	본 시리즈에서 심화
CI/CD·GitHub Actions	ML·인프라 plan in CI, CD 승격·canary
배포 전략(canary, blue-green)	Argo Rollouts·에러 버짓 연계
IaC·GitOps 개요(plan, Argo sync)	Terraform module·workspace, CDK 테스트, Flux PR flow
Lambda 개요	SAM·이벤트 fan-out·프로덕션 패턴
VPC·관리형 서비스	Terraform으로 동일 스택 코드화

• 선행 권장
  • Platform 5~14편 수준 — K8s manifest, CI/CD, IaC·GitOps 입문
  • Git·PR, YAML/HCL 읽기, AWS/GCP 리소스 이름 정도는 알고 시작
• 연계 시리즈
  • Security — 시크릿·IAM·Policy as Code
  • Observability — 배포·SLO·알람과 CD 거버넌스
  • Architecture — 이벤트 기반·MSA와 Serverless 경계

4. 다룰 스택 미리보기

영역	핵심 질문	본 시리즈에서
클라우드 IaC	네트워크·DB·IAM을 어떻게 코드로?	Terraform 25편, CDK 69편
함수·API	컨테이너 없이 어떻게 배포?	Serverless 10~13편
클러스터 상태	manifest drift를 어떻게 막나?	GitOps 14~16편
프로덕션 배포	누가·언제 prod에 올리나?	CD 17~19편
운영	drift·정책·멀티 계정은?	IaC 운영 20~22편

• 코드 → 파이프라인 우선 — 콘솔 스크린샷은 보조
• 한 편 한 메커니즘 — state locking, synthesis, cold start 등 하나씩
• 예제는 재현 가능한 .tf, CDK snippet, template.yaml 위주

5. 시리즈 로드맵

• Part 1. Terraform (2~5편) — IaC 원칙, HCL, state·module, 환경 분리
• Part 2. AWS CDK (6~9편) — Construct, 인프라 정의, Terraform 비교, 테스트·배포
• Part 3. Serverless (10~13편) — FaaS, Lambda·API GW, SAM, 이벤트 기반
• Part 4. GitOps (14~16편) — 원칙, Argo CD·Flux, PR 기반 변경
• Part 5. CD (17~19편) — CI vs CD, progressive delivery, 배포 거버넌스
• Part 6. IaC 운영 (20~22편) — drift·import, policy as code, 멀티 계정·시크릿

다음에 다룰 것

• Infrastructure as Code란
• 선언적 인프라, 멱등성, imperative vs declarative

---

해당 내용은 HashiCorp Terraform Documentation, AWS CDK Developer Guide, OpenGitOps principles 를 기반으로 합니다.