Terraform 의존성 관리 실용 가이드

Source: Dev.to

TL;DR

• Terraform 의존성 관리를 두 개의 서로 다른 시스템으로 생각하세요: 제공자는 .terraform.lock.hcl 로 선택하고 고정(pinned)됩니다(기본적으로 재현 가능). 반면 모듈은 lock 파일에 고정되지 않으며 정확한 버전이나 git ref 를 지정하지 않으면 시간이 지나면서 변동될 수 있습니다.
• Terraform CLI(required_version)에 대해서는 제한된 범위(bounded ranges)를 사용하고, 루트 모듈에서는 제공자에 대해 비관적 제약(~>)을 사용하세요.
• 재사용 가능한 서브‑모듈에서는 가능한 넓은 최소값을 선호하고(필요한 경우에만 선택적인 상한을 추가), 최종 해석은 루트 모듈이 담당하도록 합니다.
• 모듈에 대해서는 최대 재현성을 위해 정확한 고정(pin)을 선택하거나, 더 쉬운 업그레이드를 위해 ~> 범위를 선택하고(terraform init -upgrade 워크플로를 체계적으로 운영) 명시적으로 선택하세요.

버전 제약을 지정하고 terraform init 을 실행하면 끝—하지만 제공자와 모듈은 서로 다른 해석 및 지속성 규칙을 따릅니다. 제공자는 잠금이 되지만 모듈은 그렇지 않습니다. 이 비대칭 때문에 팀에서는 “변경된 것이 없음” 구성이라도 머신이나 CI 실행마다 다른 결과가 나오는 상황에 놀라게 됩니다.

이 글에서 루트 모듈은 여러분이 실행하는 최상위 Terraform 구성(디렉터리 init/plan/apply 하는 곳)을 의미합니다. 재사용 가능한 모듈은 다른 구성에서 사용되는 라이브러리 형태의 모듈을 뜻합니다. 메커니즘부터 시작해 실용적이고 검증 가능한 정책까지 단계별로 살펴보겠습니다.

---

실제 문제: “제약”은 “고정”을 의미하지 않는다

버전 제약은 허용 가능한 버전들의 필터일 뿐입니다(예: >= 5.0). 같은 연산자라도 Terraform 이 선택된 결과를 기록하느냐에 따라 안정성이 크게 달라질 수 있습니다.

지속성 차이:

핵심 인사이트: 같은 연산자라도 Terraform 이 선택된 결과를 기록하느냐에 따라 안정성이 크게 달라집니다.

---

생각할 수 있는 정신 모델

graph TD
    A[사용자가 제약을 정의] --> B[Terraform 이 버전을 해석]
    B --> C{제공자?}
    C -->|예| D[.terraform.lock.hcl 에 기록]
    C -->|아니오| E[lock 파일 항목 없음]
    D --> F[다음 실행에서 잠긴 버전 재사용]
    E --> G[다음 실행에서 최신 모듈 버전 선택 가능]

이 동작은 문서화되어 있습니다: lock 파일은 제공자에만 적용되고 모듈에는 적용되지 않습니다.

---

연산자: 실제로 무엇을 보장해 주는가

Terraform 은 표준 비교 연산자와 비관적 제약 ~>(“가장 오른쪽에 지정된 구성 요소만 변경 허용”, 즉 편리한 제한 범위)를 지원합니다.

각 연산자를 생각하는 방법

예시 해석 (Terraform 의미론)

제공자 버전 제약

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

• ~> 5.0 은 >= 5.0.0, < 6.0.0 로 변환됩니다.
• lock 파일에 선택된 정확한 제공자 버전이 기록되어, terraform init -upgrade 를 실행하지 않는 한 이후 실행은 동일한 버전을 사용합니다.

모듈 버전 제약

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"
}

• 동일한 ~> 5.0 범위가 적용되지만 모듈에 대한 lock 파일 항목은 생성되지 않습니다.
• 이후 실행에서는 -upgrade 로 명시적으로 업그레이드하거나 더 엄격한 제약을 추가하지 않는 한, 최신 5.x 릴리스를 자동으로 선택할 수 있습니다.