IaC 튜토리얼 (1)

IaC란?

어떻게 만들지(절차)가 아니라 무엇을 원하는지(상태)를 적는 선언형 방식이 IaC의 주류다.

요약 정리

IaC는 인프라의 “원하는 상태(desired state)” 를 텍스트 파일로 기술하고, 도구가 그 정의대로 실제 클라우드/온프레미스 자원을 만들고 변경·삭제하도록 하는 운영 패러다임입니다.

콘솔에서 수동으로 만든 자원은 누가/언제/무엇을 바꿨는지 추적이 어렵고, 재현이 불가능합니다. IaC는 이 과정을 코드로 옮겨 Git으로 이력을 남기고, 코드 리뷰를 거치고, 동일한 정의로 몇 번이든 같은 환경을 재생산할 수 있습니다.

결과적으로 인프라가 소프트웨어 개발의 모범 사례(버전 관리·테스트·CI/CD· 리뷰)를 그대로 누리게 됩니다.

코드로 정의하면 따라오는 것들

• Single Source of Truth : 실제 인프라의 구조는 코드 저장소가 말해줍니다.
• 리뷰 가능성: 인프라 변경이 PR로 들어와, 동료의 검토를 받습니다. (이제 AI의 작성과 리뷰도 받을 수 있습니다.)
• 자동화: apply 한번으로 수십 개의 자원을 일관되게 생성합니다.

IaC의 이점

이점	무엇을 해결하는가?	구체적인 효과
재현성 / 멱등성	환경 간 불일치, 재해 복구	동일 코드로 dev-alpha-production 등의 환경에 동일하게 생성 가능. 여러 번 apply해도 결과가 동일함
버전 관리	”누가 이걸 지웠는가?”	Git Diff로 변경 추적이 가능함
협업 / 리뷰	사일로화된 인프라 지식	인프라 변경이 코드 리뷰 대상이 되어 지식이 팀에 공유된다.
속도 / 자동화	느린 수동 프로피저닝	CI/CD 파이프라인에서 plan / apply를 자동 실행
일관성	휴먼 에러, Contribution Drift	클릭 실수 제거, 정책을 코드로 강제할 수 있음
문서화	오래된 위키	코드 자체가 항상 최신 인프라를 명세하는 명세서 역할을 함
비용 / 보안 가시성	유령 자원, 미흡한 점검	정적 분석 (tfsec, Checkov) 으로 배포 전에 위험, 낭비를 탐지할 수 있음

IaC에서 멱등성은 매우 중요합니다. 명령형 스크립트를 통해 인프라 생성시, 단순하게 두 번 실행하면 자원을 2개 만들어낼 수 있습니다. 선언형 IaC는 “이미 원하는 상태” 라면 아무 일도 하지 않습니다. 이 성질로 “안전하고 다시 돌릴 수 있는” 자동화를 가능하게 만들어줍니다.

명령형 vs 선언형 그리고 state에 대해

명령형(imperative)

“EC2 인스턴스를 생성하라 → 보안그룹을 붙여라 → 태그를 달아라”처럼 수행할 단계를 순서대로 기술합니다. (예: 셸 스크립트, AWS CLI 나열) 다시 실행하면 중복 생성·오류가 날 수 있어 멱등하지 않습니다.

선언형(declarative)

“t3.micro EC2가 1대, 이 보안그룹과 함께, 이 태그로 존재해야 한다”처럼 결과만 기술합니다. 도구가 현재와 비교해 필요한 동작을 스스로 도출합니다. (ex. Terraform, CloudFormation, Kubernetes manifest)

선언형 IaC 도구가 동작하는 방식

선언형 도구는 세 가지를 비교합니다.

1. 코드에 적힌 목표 상태(desired)
2. 도구가 기억하는 마지막 상태(state file)
3. 클라우드의 실제 상태(real)

plan 단계에서 이 셋을 대조하여 “무엇을 만들고/바꾸고/지울지”를 실행 계획으로 보여줍니다. apply 단계에서 그 계획만큼만 실제 API를 호출합니다. 코드와 실제가 어긋나는 현상을 드리프트(drift)라 하며, 도구는 이를 감지해 다시 코드 기준으로 맞춰 줍니다. 이 “목표-현재 차이 계산” 모델이 IaC가 멱등하고 안전한 이유입니다.