Infrastructure as Code
서론
온라인 서버가 다운되었는데, 당초 어떻게 설정했는지 아무도 기억하지 못하는 악몽을 겪어본 적이 있나요? 서버에 수동으로 로그인하고, 기억에 의존해 명령을 치고, 틀리지 않기를 기도하는 것 — 이것이 전통적 운영의 일상입니다. Infrastructure as Code(IaC)는 이 모든 것을 근본적으로 바꿨습니다: 코드로 인프라를 정의하고 관리하여, 서버 설정이 소프트웨어처럼 버전 관리되고, 재현 가능하고, 감사 가능하게 만듭니다.
이 글에서 무엇을 배우게 될까요?
이 장을 마치면 다음을 얻게 됩니다:
- 핵심 개념: IaC가 무엇이며, 왜 현대 운영의 초석인지 이해
- 워크플로 인식: Terraform의 Write → Plan → Apply → Destroy 4단계 프로세스 파악
- 도구 선택: Terraform, Pulumi, CloudFormation 등 주류 도구의 장단점 이해
- 위험 인식: 구성 드리프트의 위험성과 감지 방법 이해
- 모범 사례: IaC 프로젝트의 엔지니어링 관리 방법 파악
| 장 | 내용 | 핵심 개념 |
|---|---|---|
| 제1장 | IaC 개념 | 수동 운영 vs 코드화 관리 |
| 제2장 | Terraform 워크플로 | Write → Plan → Apply |
| 제3장 | 도구 비교 | Terraform, Pulumi, CDK |
| 제4장 | 구성 드리프트 | 감지, 예방, 수정 |
| 제5장 | 모범 사례 | 모듈화, 상태 관리, CI/CD |
0. 전체 그림: 왜 인프라에도 "소스 코드"가 필요한가?
요리사라고 상상해 보세요. 매번 감에 의존해 요리한다면, 오늘 소금 한 숟가락, 내일 두 숟가락이 되어 맛이 항상 일정하지 않을 것입니다. 하지만 레시피를 적어둔다면 — 각 양념의 정확한 그램 수까지 — 누구나 같은 맛을 재현할 수 있습니다.
인프라 관리도 같은 문제에 직면합니다. 서버 한 대의 설정에 운영체제, 네트워크 규칙, 보안 그룹, 스토리지 볼륨, 환경 변수 등 수십 개의 매개변수가 관련될 수 있습니다. 수동 설정은 오류가 발생하기 쉬울 뿐만 아니라 재현 불가능, 감사 불가, 롤백 불가합니다.
IaC의 핵심 가치
- 재현 가능: 같은 코드를 몇 번 실행하든 결과가 동일함(멱등성)
- 버전 관리 가능: 인프라 변경이 Git을 통해 관리되어 누가 무엇을, 왜 변경했는지 한눈에 파악
- 감사 가능: 모든 변경에 기록이 있어 컴플라이언스 요구 충족
- 자동화 가능: CI/CD 파이프라인을 통해 자동 배포하여 인적 조작 위험 제거
- 협업 가능: 팀원들이 Pull Request로 인프라 변경을 리뷰 — 코드 리뷰와 마찬가지
1. IaC 개념: "수동 클릭"에서 "코드 선언"으로
전통적 운영의 방식은 클라우드 플랫폼 콘솔에 로그인하여 수동으로 서버를 만들고, 네트워크를 설정하고, 보안 그룹을 지정하는 것입니다. 이 방식은 서버 몇 대를 관리할 때는 괜찮지만, 수십, 수백 대로 확장되면 악몽이 됩니다.
IaC의 핵심 사상은: 선언형 코드로 원하는 인프라 상태를 설명하고, 도구가 자동으로 구현하는 것입니다. 도구에게 "먼저 VPC를 만들고, 그 다음 서브넷을 만들고, 그 다음 보안 그룹을 만들어"(명령형)라고 말할 필요 없이, "이런 네트워크 환경이 필요해"(선언형)라고만 말하면, 도구가 자동으로 실행해야 할 단계를 계산합니다.
| 对比维度 | 手动运维 | 基础设施即代码 |
|---|---|---|
| 可重复性 | 每次操作可能不同 | 代码保证完全一致 |
| 速度 | 分钟到小时级 | 秒到分钟级 |
| 审计追踪 | 依赖人工记录 | Git 历史自动记录 |
| 协作 | 口头传达、截图 | Code Review、PR 流程 |
| 回滚 | 几乎不可能 | git revert 一键回滚 |
선언형 vs 명령형
- 선언형(Declarative): "무엇을 원하는지"를 설명하고, 도구가 "어떻게 할 것인지"를 자동으로 계산. Terraform, CloudFormation이 이 방식을 채택. 장점은 멱등성이 좋고, 단점은 유연성이 제한적.
- 명령형(Imperative): "어떻게 할 것인지"를 설명하고, 단계별로 실행. Ansible, Shell 스크립트가 이 방식을 채택. 장점은 유연하고, 단점은 멱등성 보장이 어려움.
- 혼합형: Pulumi, AWS CDK는 범용 프로그래밍 언어로 작성하며, 선언형의 상태 관리와 명령형의 유연성을 겸비.
2. Terraform 워크플로: Write → Plan → Apply
Terraform은 현재 가장 인기 있는 IaC 도구로, HashiCorp에서 개발했습니다. 작업 흐름이 명확하고 직관적이며, 소프트웨어 개발의 "코딩→리뷰→배포→정리"와 같이 네 단계로 나뉩니다.
用声明式语言（HCL）描述你期望的基础设施状态。代码就是文档，可以提交到 Git 进行版本管理和 Code Review。
4단계 워크플로
- Write(작성): HCL(HashiCorp Configuration Language)로 인프라 정의 파일(.tf)을 작성. 필요한 리소스를 선언: 서버, 데이터베이스, 네트워크 등.
- Plan(계획):
terraform plan을 실행하면, Terraform이 현재 상태와 목표 상태를 비교하여 "실행 계획"을 생성 — 어떤 리소스를 생성, 수정, 삭제할지 알려줍니다. 이것은 안전망으로, 실제 실행 전에 변경 사항을 확인. - Apply(실행): 계획에 이상이 없음을 확인한 후
terraform apply를 실행하면, Terraform이 계획에 따라 리소스를 생성하거나 수정. 실행이 완료되면 현재 상태가 상태 파일(terraform.tfstate)에 저장됩니다. - Destroy(삭제): 더 이상 필요 없을 때
terraform destroy를 실행하여 모든 리소스를 정리하고 불필요한 비용 발생 방지.
3. 도구 비교: 적합한 IaC 도구 선택
IaC 분야에는 여러 도구가 있으며, 각각 장단점이 있습니다. 도구 선택 시 팀의 기술 스택, 클라우드 플랫폼, 프로젝트 규모 등을 고려해야 합니다. "최고의" 도구는 없고, 오직 "가장 적합한" 도구만 있습니다.
| 特性 | Terraform | CloudFormation |
|---|---|---|
| 厂商 | HashiCorp | AWS |
| 配置语言 | HCL | YAML / JSON |
| 声明式/命令式 | 声明式 | 声明式 |
| 多云支持 | 原生多云 | 仅 AWS |
| 状态管理 | State 文件 | AWS 托管 |
| 学习曲线 | 中等 | 中等偏高 |
| 社区生态 | 非常活跃 | AWS 生态 |
| 最佳场景 | 多云/混合云 | 纯 AWS 环境 |
어떻게 선택할까?
- 스타트업 / 단일 클라우드: CloudFormation(AWS) 또는 해당 클라우드 플랫폼의 네이티브 도구. 생태계 통합이 가장 좋음
- 멀티 클라우드 / 중대형 팀: Terraform. 커뮤니티가 가장 크고, Provider가 가장 풍부하며, 채용이 가장 쉬움
- 개발자 주도 팀: Pulumi 또는 CDK. 익숙한 프로그래밍 언어로 인프라를 작성하고 IDE 지원이 좋음
- 구성 관리 필요: Ansible. 서버 내부 설정(소프트웨어 설치, 설정 파일 수정)에 특화
4. 구성 드리프트: 소리 없는 시한폭탄
구성 드리프트(Configuration Drift)는 IaC 실무에서 가장 은밀한 적입니다. 이것은 실제 인프라 상태와 코드로 정의된 상태 사이에 점진적으로 편차가 발생하는 것을 말합니다.
이러한 편차는 보통 어떻게 발생할까요? 누군가 온라인 문제를 "빠르게 수정"하기 위해 콘솔에 직접 로그인하여 보안 그룹 규칙을 수동으로 변경했거나, 디버깅을 위해 특정 서버의 설정을 임시로 높였지만 원래대로 되돌리는 것을 잊은 경우입니다. 이러한 "작은 변경"이 누적되어 결국 코드와 실제 환경이 심각하게 괴리됩니다.
团队使用 Terraform 部署了 3 台 Web 服务器，配置完全一致：Nginx 1.24、端口 443、2GB 内存。代码和实际状态完美匹配。
구성 드리프트의 위험
- 재현 불가: 코드가 설명하는 환경과 실제 환경이 불일치하여 새 환경 생성 시 문제 발생
- 롤백 실패: 이전 버전으로 롤백하면 복구될 것이라 생각했지만, 실제 환경은 이미 수동으로 수정됨
- 보안 위험: 수동으로 열어둔 포트, 완화된 권한이 잊혀져 공격 경로가 될 수 있음
- 감사 무효화: 컴플라이언스 감사는 코드를 기반으로 하지만, 코드가 실제 상태를 반영하지 않음
5. 모범 사례: IaC 프로젝트를 지속적으로 발전시키기
IaC 코드도 애플리케이션 코드와 같이 좋은 엔지니어링 실무가 필요하여 유지보수성을 보장합니다. 인프라 규모가 커질수록 체계적이지 않은 IaC 코드는 또 다른 형태의 "기술 부채"가 됩니다.
# 忽略本地状态文件
*.tfstate
*.tfstate.backup
.terraform/
# 忽略敏感变量文件
*.tfvars
!example.tfvars6가지 핵심 모범 사례
- 모듈화: 재사용 가능한 인프라를 모듈(예: VPC 모듈, 데이터베이스 모듈)로 추상화하여 복사-붙여넣기 방지. 함수를 작성하는 것과 같이 한 곳에서 정의하고 여러 곳에서 호출.
- 환경 격리: 개발, 테스트, 프로덕션은 독립적인 상태 파일과 변수 파일을 사용하여 workspace나 디렉토리 구조로 격리.
- 원격 상태 관리: 상태 파일(tfstate)은 원격 백엔드(S3 + DynamoDB)에 저장하여 팀 협업과 상태 잠금을 지원하고 동시성 충돌 방지.
- 민감 정보 관리: 비밀번호, 키 등 민감 정보는 코드에 작성하지 말고 Vault, AWS Secrets Manager 등의 도구로 관리.
- CI/CD 통합: terraform plan을 PR 프로세스에 통합하고, apply는 파이프라인을 통해 자동 실행하여 로컬 수동 조작 근절.
- 코드 리뷰: 인프라 변경도 애플리케이션 코드와 같이 Code Review가 필요하며, 특히 보안 그룹, IAM 정책과 관련된 변경.
요약
Infrastructure as Code는 현대 클라우드 네이티브 운영의 초석입니다. "설명할 수 없는 수동 작업"을 "버전 관리 가능한 코드"로 바꾸어 인프라 관리를 "예술"에서 "엔지니어링"으로 만들었습니다.
핵심 포인트 복습:
- IaC의 본질: 코드로 인프라의 원하는 상태를 선언하고, 도구가 자동으로 구현
- Terraform 워크플로: Write → Plan → Apply 3단계, Plan이 안전망
- 도구 선택: 멀티 클라우드는 Terraform, 단일 클라우드는 네이티브 도구, 개발자 팀은 Pulumi
- 구성 드리프트: 가장 은밀한 위험으로 프로세스와 도구의 이중 방어 필요
- 엔지니어링 관리: 모듈화, 환경 격리, 원격 상태, CI/CD 통합이 모두 필수
더 읽어보기
- Terraform 공식 튜토리얼 - 처음부터 Terraform 배우기
- Pulumi 문서 - 프로그래밍 언어로 인프라 작성
- AWS CDK Workshop - AWS CDK 실전 튜토리얼
- Infrastructure as Code (O'Reilly) - IaC 분야의 고전 서적
- Spacelift Blog - IaC 모범 사례와 업계 동향