<aside>
☁️ 클라우드웨이브 · W07 · 2/5 · 예상 읽기 7분
</aside>
오늘은 비슷한 인프라를 여러 환경에 복사하면서 생기는 드리프트를 줄이는 방법을 정리했다. 모듈은 단순한 폴더 묶음이 아니라 인터페이스를 가진 재사용 단위다. 반복문은 자원 수를 줄이는 문법이지만, 상태 주소와 변경 이력을 어떻게 유지할지까지 생각해야 안전하다.
루트 모듈은 실행의 시작점이며 환경별 provider와 공통 입력, 백엔드 경계를 소유한다. 자식 모듈은 웹 계층이나 보안 그룹처럼 명확한 책임을 받아 자원과 출력을 정의한다. 자식 모듈이 provider를 몰래 구성하면 호출 환경의 인증·리전·별칭 정책과 충돌하기 쉬우므로, 일반적으로 provider 설정은 루트에서 주입하는 편이 협업에 유리하다.
flowchart TD
R[루트 모듈] --> P[provider와 환경 입력]
R --> W[웹 모듈]
R --> N[네트워크 모듈]
R --> O[출력과 의존성 연결]
W --> WR[웹 자원]
N --> NR[네트워크 자원]
재사용 모듈은 입력을 작게 유지하고, 출력 이름과 의미를 안정적으로 문서화한다. 버전은 태그나 레지스트리 버전으로 고정해 갑작스러운 호환성 변화를 막는다. 변경이 필요하면 새 버전을 발행하고 호출 측에서 검토 후 올리는 흐름이 좋다.
count는 동일한 자원을 개수로 만들 때 직관적이다. 그러나 중간 항목이 삭제되면 인덱스가 밀려 다른 자원까지 교체 대상으로 보일 수 있다. for_each는 키가 안정적인 맵이나 집합을 사용해 자원 정체성을 더 분명하게 표현한다. for 표현식은 입력을 변환해 모듈이나 자원에 전달하고, 조건식은 환경에 따라 선택적인 구성을 만든다.
module "web" {
source = "<MODULE_SOURCE_PLACEHOLDER>"
version = "<VERSION_PLACEHOLDER>"
for_each = var.web_groups
name = each.key
size = each.value.size
}
반복 기준은 사람이 읽고 리뷰할 수 있어야 한다. 키를 무작위 값으로 만들면 계획 결과가 불안정해지고, 목록 순서에 기대면 자원 이동이 예상보다 커진다. 반복문을 도입하기 전에는 기존 상태 주소와 새 주소의 대응을 확인하고, 필요한 경우 상태 마이그레이션을 계획한다.
리소스를 모듈 아래로 옮기거나 count를 for_each로 바꾸면 실제 클라우드 자원을 새로 만들지 않고 상태 주소만 이동해야 하는 경우가 있다. 이때는 마이그레이션 명령과 계획 결과를 검토하고 백업을 확보한다. 주소를 잘못 매핑하면 Terraform이 기존 자원을 새 자원으로 오인할 수 있다.
create_before_destroy는 새 자원을 먼저 만들도록 요청하는 lifecycle 설정이다. 이름 충돌, 용량 한도, 연결 전환, 데이터 마이그레이션이 해결되어야 효과가 있다. 따라서 이 옵션은 교체 중 서비스 중단 가능성을 줄이는 도구이지, 모든 시스템에서 무중단을 보장하는 만능 스위치가 아니다.
모듈 변경은 예제 환경에서 plan을 실행하고, 기존 호출자의 출력과 상태 주소를 비교한다. 파괴적 변경은 별도 승인으로 분리하고, 새 리소스가 정상 헬스 체크를 통과한 뒤 트래픽을 전환하는 단계까지 파이프라인에 표현한다. 모듈의 입력을 늘리기보다 책임을 재검토하면 장기 유지 비용이 줄어든다.