콘솔에서 클릭으로 만든 인프라는 누가 무엇을 바꿨는지 기록이 없고, 같은 환경을 다시 만들 수도 없습니다. IaC(Infrastructure as Code)는 인프라를 선언적 코드로 정의해 버전 관리, 리뷰, 재현을 가능하게 만듭니다. 이 글은 테라폼류 도구로 운영할 때의 실전 패턴을 다룹니다.
운영 문제: 드리프트와 눈송이 서버
코드로 만든 인프라도 누군가 콘솔에서 손대면 코드와 실제 상태가 어긋나는 ‘드리프트’가 생깁니다. 또 환경마다 미묘하게 다른 ‘눈송이 서버’가 쌓이면 재현성이 무너집니다. IaC의 운영은 결국 이 드리프트를 어떻게 통제하느냐의 문제입니다.
아키텍처: 상태 파일이 진실의 원천
테라폼은 상태 파일(state)에 현재 인프라의 모습을 기록하고, 코드와 비교해 차이만 적용합니다. 따라서 상태 파일을 원격 백엔드에 두고 잠금(locking)을 거는 것이 협업의 출발점입니다. 잠금이 없으면 두 사람이 동시에 apply해 상태가 깨집니다.
terraform {
backend "s3" {
bucket = "infra-state-prod"
key = "network/terraform.tfstate"
dynamodb_table = "tf-lock" # 동시 실행 잠금
encrypt = true
}
}구성: 모듈과 환경 분리
- 재사용 단위는 모듈로: VPC, 데이터베이스, 클러스터를 모듈화
- 환경은 변수로 분리: dev/staging/prod가 같은 모듈에 다른 값
- plan을 PR에서 리뷰: 무엇이 생성·변경·삭제되는지 먼저 확인
- apply는 파이프라인에서만: 사람의 로컬 apply 금지
특히 plan 결과를 코드 리뷰 단계에서 검토하는 습관이 중요합니다. ‘삭제 5개’가 보이는데 누군가 무심코 승인하면 데이터베이스가 통째로 사라질 수 있기 때문입니다.
모니터링과 비용
드리프트는 주기적으로 plan을 돌려 코드와 실제의 차이를 감지하는 방식으로 모니터링합니다. 차이가 발견되면 알림을 보내 즉시 원인을 추적합니다. 비용 면에서는 plan 단계에 비용 추정 도구를 붙여, 이 변경이 월 비용을 얼마나 늘리는지 PR에서 미리 보여주면 무심한 고비용 자원 생성을 사전에 막을 수 있습니다.
정리
IaC의 핵심 가치는 인프라를 소프트웨어처럼 다루는 규율입니다. 원격 상태와 잠금, 모듈화, PR 기반 plan 리뷰라는 삼각 편대를 갖추면, 인프라 변경은 두려운 클릭이 아니라 추적 가능하고 되돌릴 수 있는 코드 변경이 됩니다.
