Terraform v1.x 호환성 약속

Terraform v1.x 호환성 약속

Terraform v1.0의 출시는 Terraform 언어와 워크플로의 발전에서 중요한 이정표예요. Terraform v1.0은 인프라를 설명하고 관리하기 위한 안정적인 플랫폼이에요.

출처: 문서

본문

이번 릴리스에서 우리는 1.x 릴리스 전반에 걸쳐 호환성을 유지하려는 여러 Terraform 동작을 정의해요:

  • Terraform 언어 기능의 큰 부분집합.
  • Terraform CLI 워크플로 명령의 더 보수적인 부분집합.
  • Terraform Core와 Terraform 프로바이더 사이의 통신을 위한 와이어 프로토콜(wire protocol).
  • Terraform 프로바이더와 외부 Terraform 모듈 설치를 위한 와이어 프로토콜.

우리의 의도는 Terraform v1.0용으로 작성된 Terraform 모듈이 v1.x 릴리스 전반에 걸쳐 별도의 변경 없이 계획(plan)과 적용(apply)을 성공적으로 수행할 수 있게 하는 거예요. 또한 이 문서에서 설명하는 워크플로 부분집합을 기반으로 구축된 자동화가 모든 미래 v1.x 릴리스에서 변경 없이 작동하도록 하는 것도 의도하고 있어요. 마지막으로, 현재 문서화된 프로바이더 와이어 프로토콜에 맞춰 빌드된 프로바이더가 소스 코드 수정이나 바이너리 재컴파일 없이도 같은 운영체제와 아키텍처를 대상으로 하는 모든 미래 Terraform v1.x 릴리스와 호환될 수 있도록 하는 것도 목표예요.

간단히 말해, 우리는 v1.x 릴리스 간 업그레이드를 여러분의 구성 변경 없이, 업그레이드 단계를 실행할 추가 명령 없이, 그리고 Terraform 주변에 설정한 자동화 변경 없이 수행할 수 있게 만드는 것을 목표로 해요. Terraform v1.x 시리즈는 v1.0 이후 최소 18개월 동안 적극적으로 유지 관리될 거예요.

다음 섹션에서는 자세한 내용을 원하는 분들을 위해 v1.x 시리즈 전반에 걸쳐 약속할 것들에 대한 구체적인 지침을 포함해요. 하지만 더 높은 수준에서 보면, 우리는 기존 모듈이나 자동화가 새 v1.x 릴리스로 업그레이드할 때 변경을 요구하게 만드는 어떤 변경도 하지 않으려 해요. 일반적으로 새 Terraform CLI 릴리스의 호환성 문제는, 중요한 보안 문제를 해결하거나 우리가 직접 통제하지 않는 원격 의존성의 호환성을 깨는 변경과 일치시키는 것 같은 매우 중요한 정당성이 없는 한 고쳐야 할 버그로 취급할 거예요.

Terraform 언어

주요 Terraform 언어에는 언어 구문, resource, module, provider 블록 같은 최상위 구조, 그 블록들의 "메타 인자(meta-argument)", 그리고 표현식에서 사용할 수 있는 연산자와 내장 함수의 문서화된 의미와 동작이 포함돼요. Terraform 언어에는 단일 공식 명세가 없지만, Terraform 웹사이트 문서의 Configuration 섹션이 언어 기능과 의도된 동작에 대한 설명 역할을 해요.

다음 최상위 블록과 정의된 "메타 인자" (즉, 프로바이더 같은 외부 플러그인이 아니라 Terraform Core가 정의한 인자)는 현재 기능을 유지할 거예요:

  • 리소스를 선언하는 resource와 data 블록. 여기에는 중첩 블록 타입인 lifecycle, connection, provisioner와 메타 인자 provider가 포함돼요.
  • 다른 모듈을 호출하는 module 블록과 그 메타 인자 providers.
  • resource, data, module 블록의 count, for_each, depends_on 메타 인자.
  • 프로바이더를 구성하는 provider 블록과 alias 메타 인자.
  • 모듈에서 다양한 종류의 명명된 값을 선언하는 variable, output, locals 블록.
  • 중첩된 required_version과 required_providers 인자, 그리고 백엔드 구성을 위한 중첩 backend 블록을 포함한 terraform 블록.

또한 모든 표현식 연산자와 내장 함수에 대해 호환성을 유지하려고 해요. 예외는 워크스페이스 모델의 향후 변경의 일부로 동작이 바뀔 수 있는 terraform.workspace 참조예요.

Terraform 언어 기능과의 광범위한 호환성을 유지하려고 하며, 몇 가지 특정 주의 사항이 있어요:

  • 우리는 Terraform이 오류를 보고하지 않고 계획을 만들고 적용할 수 있다면 구성을 유효하다고 간주해요. 현재 오류를 만드는 구성은 향후 Terraform 버전에서 다른 오류를 만들거나 다른 비오류 동작을 보일 수 있어요. 적용 단계에서 오류를 생성하는 구성은 향후 더 이른 단계에서 비슷한 오류를 만들 수도 있는데, 일반적으로 오류를 최대한 이른 단계에서 감지하는 것이 더 낫다고 생각하기 때문이에요.

일반적으로 이 문서에서 설명하는 호환성 약속은 유효한 구성에만 적용돼요. 유효하지 않은 구성의 처리는 항상 향후 Terraform 릴리스에서 변경될 수 있어요.

  • 실제 기능 동작이 우리가 명시적으로 문서화한 동작과 다르다면, 일반적으로 그것을 버그로 취급하고 기능을 문서와 일치하도록 변경할 거예요. 다만 그러한 변경이 광범위한 호환성 문제를 일으킬 것 같으면 피할 거예요. 우리가 항상 이전 릴리스와 "버그 호환(bug-compatible)" 상태를 유지한다고 약속할 수는 없지만, 그 영향을 최소화하도록 그러한 수정을 신중히 고려할 거예요.

  • 어떤 실험적(experimental) 기능은 미래 릴리스에서 변경되거나 완전히 제거될 수 있어요. Terraform은 실험적 언어 기능이 활성화될 때 항상 경고를 만들어서 그 위험을 알려줘요. 프로덕션 모듈에서는 실험적 기능을 사용하지 않는 걸 권장해요.

  • 우리는 새 언어 기능을 도입할 거예요. 그것을 사용하기 시작하면 여러분의 구성은 아직 그 기능을 지원하지 않는 이전 Terraform 버전에서는 작동하지 않을 거예요.

  • Terraform 프로바이더는 Terraform Core와 독립적으로 변경될 수 있는 별도의 플러그인이므로 이 호환성 약속의 적용을 받지 않아요. 사용 중인 프로바이더를 업그레이드하면 그 프로바이더와 관련된 프로바이더나 리소스 구성을 변경해야 할 수도 있어요.

  • Terraform v1.0에서 명시적 경고와 함께 더 이상 사용되지 않는(deprecated) 소수의 기능이 남아 있어요. 그 지원 중단 주기는 미래 v1.x 릴리스에서 끝나고, 그 시점에 해당하는 기능을 제거할 거예요.

워크플로

보호된 워크플로(protected workflows)라고 부르는 자주 사용되는 Terraform 워크플로 집합이 있어요. 우리는 이러한 명령, 하위 명령, 플래그를 제거하지 않고 보호된 워크플로 기능에 대해 하위 호환성을 깨는 변경도 하지 않을 거예요. 실수로 이것을 변경한다면, 핵심 워크플로에 대한 하위 호환성을 깨는 변경은 고쳐야 할 버그로 간주할 거예요. 보호된 워크플로의 일부인 명령과 옵션 조합 목록은 보호된 워크플로 명령을 참고하세요.

또한 기능이 v1.x 릴리스에서 변경될 것으로 예상되기 때문에 호환성 약속을 명시적으로 하지 않는 명령 집합도 있어요: 변경될 수 있는 명령을 참고하세요.

외부 소프트웨어가 Terraform과 상호작용하는 지원 방식은 일부 명령이 제공하는 JSON 출력 모드와 종료 상태 코드(exit status code)를 통해서예요. 우리는 특정 JSON 형식을 새 객체 속성으로 확장할 수 있지만, 기존 속성의 정의를 제거하거나 깨는 변경은 하지 않을 거예요. 자연어 명령 출력이나 로그 출력은 안정적인 인터페이스가 아니며 어떤 새 버전에서도 변경될 수 있어요. 이 출력을 파싱하는 소프트웨어를 작성했다면 Terraform을 업그레이드할 때 업데이트해야 할 수도 있어요. 현재 머신이 읽을 수 있는 JSON 인터페이스 중 하나로는 사용할 수 없는 데이터에 접근해야 한다면, 기능 요청을 열어 사용 사례를 논의할 것을 제안해요.

업그레이드와 다운그레이드

v1.x 릴리스 시리즈 전반에 걸쳐 우리는 새 Terraform 버전으로 전환해서 특별한 업그레이드 단계 없이 이전처럼 바로 사용할 수 있도록 하려고 해요. 어떤 v1.x 릴리스에서든 그 이후의 어떤 v1.x 릴리스로도 업그레이드할 수 있어야 해요. 이전 v1.x 릴리스로 다운그레이드할 수도 있지만 그것은 보장되지 않아요: 이후 릴리스는 이전 버전이 이해할 수 없는 새 기능(새 Terraform 상태 스냅샷 저장 형식 포함)을 도입할 수 있기 때문이에요.

이후 v1.x 릴리스에서 도입된 기능을 사용한다면, 여러분의 구성은 그 기능 이전의 릴리스와는 호환되지 않아요. 예를 들어 v1.3에서 언어 기능이 추가되고 그것을 사용하기 시작하면, 여러분의 Terraform 구성은 더 이상 Terraform v1.2와 호환되지 않아요.

프로바이더

Terraform 프로바이더는 문서화된 프로토콜로 Terraform과 통신하는 별도의 플러그인이에요. 따라서 이 호환성 약속은 Terraform Core가 구현한 이 프로토콜의 "클라이언트" 측만 다룰 수 있어요. 개별 프로바이더의 동작(어떤 리소스 타입을 지원하고 어떤 인자를 기대하는지 포함)은 프로바이더 개발 팀이 결정하며 Terraform Core 릴리스와 독립적으로 바뀔 수 있어요. 프로바이더의 새 버전으로 업그레이드하면 여전히 Terraform v1.x 릴리스를 사용하더라도, 그 프로바이더가 해석하는 구성 부분을 변경해야 할 수도 있어요.

프로바이더 설치 방법

Terraform은 일반적으로 프로바이더 레지스트리 프로토콜 버전 1을 구현하는 프로바이더 레지스트리에서 프로바이더를 설치해요. 모든 Terraform v1.x 릴리스는 그 프로토콜과 호환되므로, 올바르게 구현된 프로바이더 레지스트리는 호환 상태를 유지할 거예요. Terraform은 또한 로컬 파일시스템 디렉터리(파일시스템 미러)와 네트워크 미러(프로바이더 미러 프로토콜 구현)에서도 프로바이더 설치를 지원해요. 모든 Terraform v1.x 릴리스는 암시적 로컬 미러 디렉터리를 포함한 이러한 설치 방법과 호환될 거예요. 특정 프로바이더 레지스트리나 네트워크 미러는 Terraform 자체와 독립적으로 운영되므로 그 자체 동작은 이 호환성 약속의 적용을 받지 않아요.

프로바이더 프로토콜 버전

Terraform v1.0 기준 프로바이더 플러그인 프로토콜의 현재 메이저 버전은 버전 5이며, 물리적 와이어 형식을 설명하는 Protocol Buffers 스키마와 예상되는 프로바이더 동작을 설명하는 추가 산문 문서의 결합으로 정의돼요. 우리는 Terraform v1.x 릴리스 전반에 걸쳐 프로토콜 버전 5를 지원할 거예요. 이후 릴리스에서 프로토콜 버전 5에 새로운 마이너 수정을 만든다면, 올바르게 구현된 기존 플러그인이 계속 작동하도록 설계할 거예요. v1.x 시리즈 동안 프로토콜의 새 메이저 버전을 도입할 수도 있어요. 그렇다면 새 버전과 함께 프로토콜 버전 5를 계속 지원할 거예요. 개별 프로바이더 팀은 이후 릴리스에서 프로토콜 버전 5 지원을 제거하기로 결정할 수 있으며, 그 경우 그 새 프로바이더 릴리스는 모든 Terraform v1.x 릴리스와 호환되지 않을 거예요.

외부 모듈

Terraform 모듈은 Terraform 언어로 작성된 재사용 가능한 인프라 구성 요소예요. 일부 모듈은 Terraform이 현재 구성 디렉터리가 아닌 다른 위치에서 자동으로 설치한다는 의미에서 "외부" 모듈이에요. 그 경우 내용이 로컬 모듈, 사용하는 프로바이더, Terraform 자체의 변경과 독립적으로 바뀔 수 있어요.

모듈 설치 방법

Terraform은 다양한 모듈 소스 타입에서 하위 모듈 설치를 지원해요. 우리는 v1.x 릴리스 전반에 걸쳐 기존 소스 타입을 모두 계속 지원할 거예요. 지원되는 소스 타입 중 하나는 모듈 레지스트리 프로토콜 버전 1을 구현하는 모듈 레지스트리예요. 모든 Terraform v1.x 릴리스는 그 프로토콜의 올바른 구현과 호환될 거예요. 일부 모듈 소스 타입은 제3자가 정의하고 실행하는 서비스나 프로토콜과 직접 작동해요. 우리가 Terraform 자체의 클라이언트 측 지원을 제거하지는 않겠지만, 그 소유자가 해당 서비스를 계속 운영하거나 Terraform의 클라이언트 구현과 계속 호환되게 유지할 것이라고는 보장할 수 없어요.

외부 모듈 호환성

구성이 외부 모듈에 의존한다면, 그 모듈의 새 버전에 호환성을 깨는 변경이 포함될 수 있어요. 외부 모듈은 Terraform의 일부가 아니므로 이 호환성 약속의 적용을 받지 않아요.

프로비저너(Provisioners)

우리는 모든 v1.x 릴리스에서 file, local-exec, remote-exec 프로비저너 타입에 대한 호환성을 유지할 거예요. 일부 추가적인 벤더별 프로비저너는 이전 Terraform 버전에서 사용할 수 있었지만 Terraform v0.13에서 지원 중단되고 Terraform v0.15에서 제거됐어요.

Terraform은 특정 로컬 파일시스템 디렉터리에서 추가 프로비저너를 플러그인으로 로드하는 것을 지원해요. v1.x 릴리스 전반에 걸쳐 이를 계속 지원할 거예요. 하지만 그러한 플러그인은 Terraform Core 자체와 분리되어 있으므로 그 자체 동작은 이 호환성 약속의 적용을 받을 수 없어요. 그래도 우리는 v1.x 릴리스 전반에 걸쳐 Terraform v1.0에서 정의한 플러그인 와이어 프로토콜을 계속 지원할 것이므로, 올바르게 구현된 프로비저너 플러그인은 미래 Terraform 릴리스와도 호환 상태를 유지해야 해요.

상태 저장 백엔드

원격 상태를 사용할 때 Terraform은 Terraform 상태를 저장하고 잠금을 관리하기 위해 네트워크를 통해 원격 서비스와 상호작용해요. 역사적인 이유로 지원되는 모든 상태 저장 백엔드는 Terraform CLI의 일부로 포함되지만 모두 Terraform 팀이 직접 지원하는 것은 아니에요. Terraform 팀이 유지 관리하는 다음 백엔드만 호환성 약속의 적용을 받아요:

  • local (원격 상태를 사용하지 않을 때의 기본값)
  • http

다른 상태 저장 백엔드는 Terraform CLI 코드베이스에 대한 기여를 통해 외부 팀이 유지 관리하므로, 예상되는 구성 인자나 동작이 v1.x 릴리스에서도 바뀔 수 있어요. 다만 그러한 경우 가능하면 좋은 마이그레이션 경로를 보장하려고 노력할 거예요. 우리는 프로바이더 플러그인과 유사한 플러그인을 통한 외부 상태 저장 백엔드 구현을 허용하는 것을 고려하고 있어요. v1.x 릴리스 동안 그러한 메커니즘을 도입한다면 그 플러그인을 사용하려면 구성 변경이 필요할 수 있고, 위에 나열된 것 외의 상태 저장 백엔드는 동등한 플러그인이 제공되면 이후 Terraform CLI 버전에서 제거될 수 있어요.

remote 백엔드와 HCP Terraform

remote 백엔드는 HCP Terraform 팀이 유지 관리하므로 그 동작이 HCP Terraform의 지속적인 변경과 함께 바뀔 수 있어요. v1.x 릴리스 전반에 걸쳐 Terraform CLI를 HCP Terraform과 함께 사용하는 지원 메커니즘이 있을 거지만, 정확한 세부 사항은 바뀔 수 있어요. HCP Terraform은 Terraform CLI와 독립적으로 진화하므로 이 호환성 약속의 적용을 받지 않아요.

커뮤니티 유지 관리 상태 저장 백엔드

azurerm, consul, s3, kubernetes 백엔드는 HashiCorp의 다른 팀이 유지 관리해요. 그 팀은 백엔드용 플러그인 프로토콜을 구현하지 않는 한 v1.x 릴리스 동안 버그 수정 수준의 기본 유지 관리를 계속하려고 해요. 그 지점에서 이 백엔드의 개발은 외부 플러그인에서만 계속될 가능성이 높으며, 플러그인 등가물로 전환하려면 구성 변경이 필요할 수 있어요. cos, oss, pg, gcs, etcdv3 백엔드는 외부 기여자가 유지 관리하며 이 호환성 약속의 적용을 받지 않아요.

지원 중단된(Unmaintained) 상태 저장 백엔드

artifactory, etcdv2, manta, swift 상태 저장 백엔드는 현재 유지 관리자가 없으므로 최선의 노력(best-effort) 기준으로 Terraform CLI 릴리스에 남아 있어요. 이것들은 이후 v1.x 릴리스에서 제거될 수 있으며, 통합되는 서비스에 호환성을 깨는 변경이 발생할 경우 업데이트되지 않을 거예요.

지원 플랫폼

v1.x 시리즈 전반에 걸쳐 다음 플랫폼에 대한 공식 릴리스를 계속 만들고, 이 운영체제의 새 릴리스를 지원하는 데 필요한 변경을 할 거예요:

  • x64 CPU의 macOS (darwin_amd64)
  • x64 CPU의 Windows (windows_amd64)
  • x64, 32비트 ARMv6, 64비트 ARMv8의 Linux (각각 linux_amd64, linux_arm, linux_arm64)

시간이 지나면서 더 새 버전의 운영체제가 필요할 수도 있어요. 예를 들어 v1.x 시리즈의 이후 Terraform 릴리스는 더 이른 버전의 macOS나 Windows, 또는 더 이른 Linux 커널 릴리스 지원을 종료할 수도 있어요. 우리는 역사적으로 그 플랫폼 사용자를 위한 편의를 위해 여러 다른 플랫폼에 대한 공식 릴리스를 만들어 왔지만, 그 발행을 중단할 현재 계획은 없어요. 다만 v1.x 시리즈 전반에 걸쳐 다른 플랫폼에 대한 지속적인 릴리스나 버그 수정은 약속할 수 없어요. Terraform을 위에 나열된 것 외의 플랫폼에서는 일상적으로 테스트하지 않아요.

이후 v1.x 릴리스에서 새 플랫폼 지원을 추가할 수도 있어요. 그렇다면 그 지원 이전의 Terraform 릴리스는 그 플랫폼에서 사용할 수 없어요. 프로바이더 플러그인을 포함한 모든 Terraform 플러그인은 지원 플랫폼에 대한 자체 정책을 가진 별도의 프로그램이에요. Terraform CLI 자체가 위 플랫폼을 지원하더라도 모든 프로바이더가 현재 지원하거나 계속 지원할 것이라고는 보장할 수 없어요.

이 약속에 대한 향후 수정

우리는 새 기능과 관련된 약속을 설명하거나, 피드백을 통해 이전 진술이 불명확했다는 것을 발견하면 기존 약속을 명확히 하기 위해 v1.x 시리즈 전반에 걸쳐 이 약속을 확장하거나 다듬을 수 있어요. 새 기능에 대한 약속은 기존 약속을 철회하지 않고 추가하는 방식으로 가산적(additive)이 될 거예요. 후기 v1.x 릴리스에만 적용되는 약속에 대해서는 그 약속이 적용되는 가장 이른 버전을 언급할 거예요.

이 문서에 명시적 진술을 추가하지 않더라도, 후기 v1.x 릴리스에서 추가된 비실험적 기능은 달리 명시되지 않는 한 최소한 v1.x 시리즈의 나머지 기간 동안 호환 상태를 유지하려고 해요.

부록

보호된 워크플로 명령 (Protected Workflow Commands)

다음은 이 호환성 약속의 적용을 받는 Terraform CLI 하위 명령과 옵션 목록이에요. 이러한 명령 주변에 자동화를 구축한다면 모든 이후 v1.x 릴리스와 호환되어야 해요. 위에서 언급했듯이 외부 소프트웨어와의 호환성은 명시적으로 머신이 읽을 수 있는 출력(-json, -raw 모드)과 종료 코드로 제한돼요. 이러한 명령의 자연어 출력은 이후 릴리스에서 변경될 수 있어요.

위 목록에 없는 명령이나 옵션에 대해서도 가능하면 호환성을 깨는 변경을 피할 거예요. 다만 v1.x 시리즈 전반에 걸친 완전한 호환성은 약속할 수 없어요. Terraform 주변에 자동화를 구축한다면 위 명령만 사용해서 업그레이드할 때 변경할 필요가 없게 하세요.

참고로 Terraform의 내부 로그(TF_LOG 환경 변수 사용)는 JSON 형식으로 제공되지만, 그 로그 줄의 특정 구문이나 구조는 지원되는 통합 인터페이스가 아니에요. 로그는 Terraform 개발자가 임시 필터링과 처리를 돕기 위해서만 JSON으로 제공돼요.

변경될 수 있는 명령 (Commands That Might Change)

다음 명령과 그 하위 명령/옵션은 모두 호환성 약속의 적용을 받지 않아요. 그 이유는 v1.x 시리즈 동안 개선할 기존 계획이 있거나, 지속적인 유지 관리를 위해 호환성을 깨는 변경이 필요할 수 있는 설계상의 단점을 알고 있기 때문이에요. 이 명령들은 지원되는 한 Terraform을 대화형으로 실행할 때 자유롭게 사용할 수 있지만, 나중에 v1.x 릴리스로 업그레이드할 때 해당 자동화를 업데이트할 의향이 없다면 자동화의 일부로 사용하는 건 권장하지 않아요.

향후 릴리스에서 이 명령들과 관련된 주요 사용 사례에 대한 지원을 유지하려고 하긴 하지만, 그러한 사용 사례를 충족하기 위한 정확한 명령 이름이나 옵션을 유지한다고 약속할 수는 없어요.

우리가 이 약속을 어떻게 지킬 것인가

자동 회귀 테스트

Terraform 코드베이스에는 안정 버전으로 배포되기 전에 우발적인 동작 회귀를 발견하는 데 도움이 되는 다양한 단위 및 통합 테스트가 포함돼 있어요. 하지만 Terraform은 흥미로운 방식으로 상호작용할 수 있는 많은 기능을 가진 비교적 복잡한 시스템이에요. 과거에 우리는 이전에 예상하지 못했거나 자동 테스트를 작성하지 않은 방식으로 두 개 이상의 기능을 결합할 때만 나타나는 동작 차이 보고를 본 적이 있어요. 각 경우에 우리는 호환성 문제를 해결하는 변경을 구현하고 그 기능 조합의 동작을 나타내는 하나 이상의 통합 테스트를 추가했어요. 시간이 지남에 따라 Terraform의 테스트 적용 범위를 개선할 수 있도록 이 접근 방식을 계속할 예정이에요.

사전 릴리스(pre-release) 버전

이 약속으로 다루는 대부분의 우발적 동작 변경은 기존 테스트로 잡힐 것으로 기대해요. 하지만 테스트 스위트가 가능한 모든 기능 상호작용이나 기타 엣지 케이스를 완벽하게 다룰 수는 없다는 점도 인정해요. 그래서 각 중요 변경이 최종 릴리스에 포함되기 전에 알파와 베타 릴리스 모두에 포함되도록 하는 것을 목표로 해요. 마이너 릴리스의 경우 일반적으로 최종 릴리스 전에 릴리스 후보(release candidate)를 최소 하나 이상 발행할 거예요. 릴리스 후보는 계획된 개발이 종료됐고 알파와 베타 릴리스를 기준으로 보고된 회귀를 수정했음을 나타내며, 따라서 뒤따르는 최종 릴리스는 일반적으로 가장 최근 릴리스 후보와 정확히 또는 거의 정확히 일치해야 해요.

최종 릴리스의 회귀

더 모호한 기능 조합의 경우 사전 릴리스 기간 동안 회귀가 감지되지 않아 최종 릴리스에 포함될 수 있어요. 누군가 그러한 회귀를 발견해 릴리스 직후 보고하면, 보안 자문(advisory) 같은 매우 중요한 정당성이 없는 한 그것을 버그로 취급하고 향후 릴리스에서 이전 동작을 복원하도록 수정할 거예요. 이런 경우 일반적으로 회귀 영향을 받는 사람에게 문제가 수정될 때까지 이전 버전에 머무르고, 그 후 수정이 포함된 새 릴리스로 바로 건너뛰도록 권장할 거예요.

알파, 베타, 릴리스 후보 패키지에 대해 모듈을 사전에 테스트하면 최종 릴리스에서 놓친 회귀의 영향을 받을 위험을 최소화할 수 있어요. 프로덕션 인프라가 아닌 격리된 개발 또는 스테이징 환경에서만 이렇게 하길 권장해요. 사전 릴리스 빌드에서 이 문서의 약속과 반대되는 것처럼 보이는 동작 변화를 발견하면 Terraform의 GitHub 저장소에 이슈를 열어 논의해 주세요.

늦게 보고된 회귀

가장 극단적인 경우, 매우 드물어 오랫동안 감지되지 않는 기능 조합의 회귀가 있을 수 있어요. 변경이 더 많은 릴리스에 포함된 후에는 다른 사용자가 새 동작에 의존하게 될 가능성이 점점 높아지므로, 동작을 복원하는 것이 새 동작을 유지하는 것보다 더 큰 부정적 영향을 미칠지 여부를 결정하는 균형을 맞춰야 해요. 우리는 항상 각 고유 상황의 영향을 충분히 고려해 이 결정을 내릴 거예요.

새 마이너 및 패치 릴리스로 신속하게 업그레이드하고 Terraform의 GitHub 저장소에서 발생한 호환성 문제를 보고함으로써 늦게 보고된 회귀에 모듈이 영향을 받을 위험을 최소화할 수 있어요.

실용적 예외 (Pragmatic Exceptions)

우리는 위의 약속을 선의로 하고 있으며, Terraform 모듈이나 자동화 작성에 대한 여러분의 투자가 미래의 Terraform 변경으로 무효화되지 않도록 하는 것이 의도예요. 하지만 위와 같은 광범위한 약속은 Terraform을 계속 개발하면서 발생할 수 있는 실제 문제의 모든 뉘앙스를 다룰 수는 없어요. 그 때문에 기존 모듈이나 자동화에 영향을 줄 수 있는 변경을 여전히 해야 하는 상황이 있을 수 있어요:

  • 보안 문제: 중요한 보안 영향을 가진 설계 문제를 알게 될 수 있어요. 관련 위험에 대한 판단에 따라 더 안전한 시스템을 위해 호환성을 깨는 것을 선택할 수 있어요.
  • 외부 의존성: Terraform의 동작은 선택한 운영체제와 모듈·프로바이더 설치 같은 상황에서의 일부 원격 네트워크 서비스를 포함한 외부 코드베이스가 제공하는 인터페이스에 의존해요. 이러한 외부 시스템은 우리 통제 밖에서 변경될 수 있으며, Terraform 자체 기능이 의존하는 기능을 제거하거나 변경할 수도 있어요. 그 경우 적절한 대체 메커니즘이 없다면 새 제약 안에서 작동하도록 Terraform 설계를 변경해야 할 수도 있어요.
  • 선택적 호환성 파괴(Opt-in Compatibility Breaks): 새 언어 기능의 설계는 기존 기능의 동작이나 구성 표현을 변경해야 할 수 있어요. 그렇다면 일반적으로 기존 모듈을 깨지 않도록 새 기능을 선택적(opt-in)으로만 만들겠지만, 새 기능에 선택하지(opt in) 않도록 모듈을 변경한다면 새 언어 설계와 함께 작동하도록 구성의 다른 부분도 변경해야 할 수 있어요.
  • 새 기능의 버그: Terraform에 새 기능을 도입하고 초기 구현에 릴리스 시 문서화된 설계 의도와 일치하지 않는 문제가 있으면, 초기 구현과 비교해 사소한 호환성 회귀를 나타내더라도 문서화된 설계와 일치하도록 구현을 수정하는 후속 릴리스를 만들 수 있어요. 하지만 기능이 잘 확립되고 널리 사용되면 일반적으로 구현된 동작을 우선하고 이를 반영하도록 문서를 변경할 거예요.
  • 기존 기능의 회귀: 새 Terraform 릴리스에 개발 및 사전 릴리스 기간 동안 감지되지 않은 기존 기능에 대한 회귀가 포함됐고, 그 사실을 새 릴리스 직후 promptly 알게 되면, 회귀로 영향을 받는 사용자가 새로 도입된 동작에 의존하는 시스템을 가진 사용자보다 많을 것이라는 가정 하에 일반적으로 기술적으로 새 릴리스의 동작과의 호환성을 깨는 대가를 치르면서 이전 동작을 복원할 거예요.
  • 늦게 보고된 회귀: 이전 섹션에서 설명했듯이 훨씬 이전 릴리스에서 드물게 사용되는 기능이나 기능 조합의 의도하지 않은 회귀가 있었다는 것을 알게 되면, 이전 동작을 복원하는 것이 이후 채택자에게는 회귀로 보일 수 있어요. 회귀를 수정하는 것이 회귀 자체가 영향을 주는 것보다 더 많은 사용자에게 영향을 미칠 것이라고 믿는다면 그 회귀를 새로운 약속된 동작으로 받아들일 수도 있어요.
  • 예상할 수 없는 상황: 여기서 다양한 특정 예외 상황을 고려하려고 노력했지만, Terraform과 그 개발 과정은 더 넓은 맥락에서 격리되어 있지 않아요. 그래서 Terraform의 미래에 영향을 줄 수 있는, 우리가 전혀 예상할 수 없는 상황이 있을 수 있음을 고려해야 해요. 그러한 상황에서는 기존 모듈과 자동화에 대한 영향을 최대한 최소화하는 행동 방침을 찾기 위해 항상 최선을 다할 거예요.

이 실용적 예외들의 의도는 일반적인 호환성 약속이 다룰 수 없는 상황이 항상 존재한다는 것을 인정하는 것뿐이에요. 우리는 이러한 예외를 충분히 고려하고 마지막 수단으로만 사용할 거예요.

더 알아보기 (Learn more)