OpenTofu 1.13 assume 함수 활용과 업그레이드 점검

unknown을 줄이는 일과 업그레이드 검증을 함께 잡는다

OpenTofu 1.13으로 실행 파일을 바꾸면 구성의 입력이 같아도 리소스 업데이트나 교체가 제안될 수 있다. base64gzip의 결과가 이전 버전과 달라지기 때문이다. 모듈 작성자가 plan 단계의 unknown을 줄이는 기능을 도입할 때, 기존 구성에서 달라지는 계획도 함께 확인해야 한다.

이 글의 기준 버전은 **OpenTofu v1.13.0 (2026-09-30), v1.13.1 (2026-10-01)**이다. v1.13.0 릴리스노트는 unknown 감소 기능과 주요 호환성 변경을 제시한다. 구체적인 영향과 패치 수정은 v1.13 브랜치 CHANGELOG를 기준으로 확인한다.

모듈에서 먼저 찾을 대상은 OpenTofu가 자동으로 추론하지 못하지만 작성자는 최종 결과에 관해 알고 있는 값이다. assume 접두사의 함수는 그 정보를 힌트로 전달하기 위해 추가됐다. 힌트를 제공하면 계획 단계에서 더 많은 정보를 알 수 있지만, 모든 unknown이 확정된다는 뜻은 아니다.

다음 그림은 unknown에 대한 작성자의 지식이 plan에 추가 정보를 제공하는 경로를 보여 준다.

⤢✕

적용 후보를 검토할 때는 “unknown이 보인다”에서 멈추지 말고, 그 값의 최종 결과에 관해 모듈 작성자가 무엇을 알고 있는지 적어 둔다. 자료가 설명하는 도입 지점은 바로 그 정보다.

convert와 assume의 역할을 구분해 모듈에 반영한다

convert는 주어진 값을 지정한 타입 제약으로 변환한다. assume 접두사의 함수는 unknown의 최종 결과에 관한 기대를 OpenTofu에 알려 준다. 따라서 타입 변환이 필요한 자리와 예상 결과에 관한 힌트가 필요한 자리를 구분해서 검토해야 한다.

CHANGELOG는 각 함수의 목적을 설명하지만 개별 assume 함수의 이름, 인자, 호출 예시는 제공하지 않는다. 이 자료만으로 작성한 글에서 실행 가능한 HCL 예시를 만들거나 특정 함수가 어떤 unknown을 확정한다고 단정할 수는 없다.

모듈 검토에서는 다음 기준으로 적용 범위를 좁힐 수 있다.

검토 대상	자료가 설명하는 기능	모듈 작성자가 확인할 것
지정한 타입 제약으로 변환할 값	convert가 값을 해당 타입 제약으로 변환	변환하려는 값과 목표 타입 제약
최종 결과에 관해 작성자가 아는 unknown	assume 함수가 예상 결과의 힌트를 제공	힌트로 표현하려는 정보의 근거
OpenTofu가 자동으로 추론하지 못하는 값	추가 힌트로 plan에서 더 많은 정보를 알 수 있음	도입 후 계획에서 실제로 더 알려진 정보

변경 전후의 plan을 검토할 때도 성공 기준을 구체적으로 잡는다. 함수 호출을 추가했다는 사실보다, 목표로 삼은 unknown에서 계획 단계의 정보가 실제로 늘었는지가 판단 기준이다. 릴리스 설명의 표현도 “잠재적으로 더 많은 정보를 알 수 있다”이므로, 함수 도입 자체를 unknown 해소의 보장으로 취급하지 않는다.

base64gzip은 압축 해제 내용과 계획 차이를 따로 확인한다

base64gzip은 새로 최적화된 DEFLATE 압축 구현의 영향으로 이전 릴리스와 다른 결과를 생성한다. 새 압축 결과를 풀면 같은 바이트열이 나오지만, 함수가 반환하는 데이터는 이전 결과와 동일하지 않다.

이 차이는 함수 결과를 관리 리소스의 인자로 사용할 때 문제가 된다. OpenTofu는 달라진 base64 데이터에 대한 프로바이더의 반응에 따라 해당 리소스 인스턴스의 업데이트나 교체를 제안할 수 있다. 압축 해제 내용이 같다는 사실만으로 인프라 계획에도 차이가 없을 것이라고 판단하면 안 된다.

아래 그림은 같은 원문 바이트열을 복원하는 압축 결과라도, 리소스 인자로 전달되는 데이터 차이는 별도의 변경 판단으로 이어질 수 있음을 보여 준다.

⤢✕

업그레이드 검토에서는 구성에서 base64gzip 사용 위치를 찾고, 결과가 관리 리소스 인자까지 전달되는지 추적한다. 해당 리소스가 있다면 새 버전의 plan에서 업데이트나 교체가 제안되는지 확인한다.

계획에 변화가 생겼을 때는 변경 원인과 변경 동작을 함께 기록한다. 압축 데이터의 표현이 달라졌다는 원인만으로 교체를 무시할 수는 없다. 실제 동작은 프로바이더가 달라진 데이터를 어떻게 처리하는지에 달려 있다.

실행 환경과 프로비저너의 지원 경계를 확인한다

WinRM 연결을 사용하는 프로비저너는 1.13에서 더 이상 지원되지 않는다. 이 연결 타입은 v1.12에서 사용 중단 예정으로 표시됐고 v1.13에서 제거됐다. CHANGELOG는 구현에 사용하던 일부 상위 라이브러리가 더 이상 유지보수되지 않는다고 설명하며, WinRM 사용자에게 SSH로의 이전을 권고한다.

WinRM 사용 여부를 확인하는 작업은 assume 함수 도입과 별개로 진행할 수 있다. 기존 연결이 제거된 기능에 의존한다면 모듈의 계획 정보를 개선하기 전에 실행 경로부터 바꿔야 한다.

플랫폼 변경도 실행 파일의 설치 가능 여부와 관련 구성요소의 지원 여부를 나눠 확인한다.

대상	1.13의 변경	업그레이드 전에 확인할 것
WinRM 프로비저너 연결	winrm 연결 타입 제거	기존 사용 위치와 SSH 이전 계획
SSH 원격 프로비저너	파일 형식·통신 형식 파서의 견고성 변경	이전에 허용되던 잘못된 입력이 거부되는지
macOS 실행 환경	macOS 13 Ventura 이상 필요	OpenTofu를 실행하는 macOS 버전
32비트 공식 빌드	v1.13이 마지막 공식 릴리스 시리즈	*_386·*_arm 사용 여부와 64비트 이전 계획
Windows ARM64	OpenTofu 공식 패키지 지원 추가	사용하는 프로바이더 플러그인의 해당 플랫폼 지원

SSH로 이전하는 구성은 파서 변경도 함께 검증해야 한다. CHANGELOG에 따르면 이전에 받아들이던 일부 잘못된 입력이 이제 거부될 수 있다. 기존 입력이 새 버전에서도 허용되는지 실제 사용 경로에서 확인한다.

32비트 환경에서는 지원 종료 시점을 이전 계획에 반영한다. v1.13.x의 지원 기간은 2027년 8월 1일까지다. 공식 *_386·*_arm 빌드에 의존한다면 그 전에 *_amd64·*_arm64 환경으로 옮길 계획을 세운다. v1.13의 공식 32비트 릴리스에서 tofu init을 실행하면 v1.14부터 해당 공식 빌드를 중단한다는 경고도 표시된다.

이 변경의 범위는 OpenTofu 프로젝트가 직접 배포하는 공식 패키지다. 제삼자가 비공식 플랫폼용 빌드를 계속 제공할 수 있다는 설명을 공식 배포 지속의 근거로 사용해서는 안 된다.

Windows ARM64는 반대로 공식 지원이 추가된 플랫폼이다. 다만 OpenTofu 실행 파일이 지원된다고 해서 모든 프로바이더 플러그인도 지원되는 것은 아니다. 실행 파일과 사용하는 플러그인을 각각 확인해야 한다.

ephemeral 구성은 v1.13.1의 수정 경로를 검증한다

v1.13.1에는 ephemeral 사용 구성과 관련된 수정이 있다. ephemeral 리소스가 구성에 있을 때 저장된 plan을 JSON으로 표시하는 기능이 다시 동작하며, ephemeral 출력 값은 apply 단계에서 항상 재평가된다. 이전에는 계획 단계의 오래된 값을 사용하는 경우가 있었다.

저장된 plan의 JSON을 읽는 경로가 있다면 해당 구성을 대상으로 CHANGELOG에 명시된 명령을 확인한다.

tofu show -json <planfile>

<planfile>에는 검증할 저장된 plan 파일 경로를 넣는다. 이 확인의 대상은 ephemeral 리소스를 포함한 구성에서 plan JSON을 표시하는 경로다.

ephemeral 출력은 검증 지점이 다르다. plan의 값을 apply에서 그대로 사용하는 경우가 수정됐으므로, apply 단계에서 값이 재평가되는 동작을 확인한다. 리소스가 포함된 plan의 표시 문제와 출력 값의 재평가 문제를 하나의 확인 항목으로 합치지 않는다.

다음 비교 그림은 v1.13.1이 수정한 표면과 각 표면에서 확인할 동작을 나란히 보여 준다.

⤢✕

저장된 plan을 표시하는 방식에도 1.13.0의 변경이 있다. plan 파일에는 렌더링에 필요한 프로바이더 스키마가 포함되며, 가능한 경우 tofu show는 프로바이더를 실행하지 않고 plan을 표시한다. “가능한 경우”라는 조건이 있으므로 모든 표시 경로에서 프로바이더 실행이 사라진다고 일반화하지 않는다.

실험 기능은 모듈 개선과 별도로 평가한다

1.13에는 기본 linting과 Symbol Libraries도 포함되지만, 둘 다 실험 기능이다. assume 함수로 계획 정보를 개선하는 작업과 실험 기능 채택 여부는 별도로 판단할 수 있다.

linting은 지원되는 명령에서 -lint 플래그로 활성화한다. 선택된 lint 규칙을 구성에 실행하고 문제가 발견되면 경고 진단을 표시한다. 초기 구현이며 사용 방식과 유용성에 관한 피드백을 얻기 위해 실험 상태로 제공된다.

따라서 기존 검증에 추가할 때는 실제 구성에서 어떤 경고가 나오는지 평가한다. 릴리스 자료가 설명하는 결과는 경고 진단이므로, 이를 곧바로 배포 차단이나 정책 강제 기능으로 간주하지 않는다. 정책 집행까지 포괄하는 기능은 릴리스노트가 제시한 향후 방향이다.

Symbol Libraries는 재사용 가능한 값, 함수, 타입 별칭의 모음이며, 모듈이 지원하는 소스 유형에서 가져올 수 있다. CHANGELOG는 language 블록의 실험 목록에 적절한 실험을 추가해 활성화한다고 설명하지만 구체적인 설정 예시는 제시하지 않는다.

모듈 간 함수와 타입을 공유하려는 요구가 있다면 별도의 평가 대상으로 삼을 수 있다. 다만 안정화 전에 변경될 수 있으며, CHANGELOG는 프로덕션에서 의존하지 말라고 명시한다.

업그레이드의 완료 기준은 새 실행 파일이 동작하는 데서 끝나지 않는다. base64gzip에 따른 계획 차이, 제거된 연결 방식, 실행 플랫폼의 지원 경계를 확인하고, ephemeral을 쓰는 구성은 패치의 수정 경로까지 검증해야 한다. 그 위에서 모듈 작성자가 근거를 가진 unknown에 힌트를 추가하고, plan에서 실제로 늘어난 정보를 확인하면 1.13의 기능을 검증 가능한 모듈 개선으로 연결할 수 있다.