Terraform이냐 OpenTofu냐…속도보다 상태 파일 암호화가 선택을 가른다

기존 Terraform 프로젝트를 OpenTofu로 옮길지는 공개 속도표보다 상태 파일의 보호 방식으로 먼저 판단하는 편이 정확하다. 두 도구는 HCL 구성, plan·apply 흐름과 공급자 생태계를 상당 부분 공유하지만, OpenTofu는 상태 파일을 저장 전에 암호화할 수 있다. Terraform을 유지할 근거는 현재 백엔드의 보안과 HCP Terraform의 운영 기능이 이미 요구를 충족하는지에 달려 있다.

라이선스도 사용 방식에 따라 결론을 바꾼다. Terraform을 사내 인프라 관리에 쓰는 팀과 실행 기능을 외부 고객에게 제공하는 사업자는 서로 다른 조건을 검토해야 한다. 이전을 결정했다면 같은 구성의 변경 계획을 대조하고, 상태 백업과 복구 경로를 확보한 뒤 암호화 도입을 별도 변경으로 다루는 것이 안전하다.

호환되는 코드와 속도표의 측정 조건

OpenTofu는 Terraform의 HCL 구성과 공급자 기반 실행 방식을 이어받았다. 기존 프로젝트에서 익숙한 초기화, 변경 계획, 적용 순서를 사용할 수 있고 다수의 공개 공급자도 양쪽에서 작동한다. 그러나 구성을 읽을 수 있다는 사실이 이후의 모든 상태 파일과 도구별 기능까지 양방향으로 호환된다는 보장은 아니다. 사용 중인 Terraform 버전, 모듈, 공급자와 백엔드를 하나의 묶음으로 살펴야 한다.

공개 성능 수치에서는 리소스 수보다 시험 환경이 중요하다. TechPlained의 400개 리소스 비교에는 AWS 공급자를 사용한 이전 측정과 random·local·null 공급자만 사용한 갱신 측정이 제시돼 있다. 갱신 측정은 Terraform 1.16.1과 OpenTofu 1.12.6의 로컬 작업을 비교하며, 실제 AWS 리소스를 생성하는 시험은 아니다. 같은 400개 구성이라는 이유로 서로 다른 측정값을 하나의 결과처럼 읽을 수 없다.

로컬 공급자 시험에서는 OpenTofu의 일부 작업이 더 빠르게 나타나므로 두 도구의 속도가 언제나 같다고 단정할 수도 없다. 다만 AWS 배포에서는 공급자 API 응답과 리소스 준비 시간이 전체 적용 시간에 들어간다. 로컬 작업에서 나타난 차이가 운영 배포의 지연을 얼마나 줄일지는 그 결과만으로 알 수 없다. 특히 초기화 시간은 공급자 다운로드와 캐시 조건의 영향을 받으므로, 잦은 CI 실행이 문제인 팀이라면 자기 환경에서 따로 측정해야 한다.

성능표가 답하는 질문과 이전 결정이 답해야 하는 질문도 다르다. 앞의 것은 특정 구성에서 명령이 끝나는 시간이고, 뒤의 것은 상태를 누가 읽을 수 있는지, 기존 실행 승인과 복구 체계를 유지할 수 있는지에 관한 문제다. 몇 초의 차이가 중요한 배포 환경도 있지만, 그 판단에는 현재 저장소와 실행 경로에서 반복 측정한 결과가 필요하다.

BUSL과 MPL은 사용 방식에 따라 의미가 달라진다

Terraform의 BUSL은 사내 사용 자체를 막는 조건이 아니다. HashiCorp의 라이선스 FAQ 설명은 내부 인프라를 위한 Terraform 실행과 사내 CI/CD 사용을 허용하고, 제삼자에게 판매하는 경쟁 상품에 Terraform을 호스팅하거나 포함하는 경우를 제한 대상으로 구분한다. 회사의 한 부서가 다른 내부 부서에 실행 환경을 제공하는 경우도 외부 고객 대상 상품과 같게 취급하지 않는다.

OpenTofu는 MPL로 배포된다. 따라서 기존 Terraform 프로젝트를 내부 운영에만 쓰는 조직이라면 라이선스 변경만으로 즉시 이전할 이유는 약하다. 반면 고객에게 인프라 실행 기능을 유료로 제공하려는 사업자는 Terraform 바이너리를 어디에 포함하고 누가 서비스를 이용하는지 검토해야 한다. 단순히 Terraform으로 고객 인프라 작업을 돕는 경우와 경쟁하는 호스팅 상품을 파는 경우를 한데 묶으면 판단이 흐려진다.

국내 플랫폼 팀에도 구분은 실무적이다. 직원이 사용하는 사내 개발 플랫폼이라면 현재 허용 범위를 먼저 확인하고, 외부 고객이 접속하는 상품이라면 제공 방식과 계약 구조를 따져야 한다. OpenTofu의 MPL은 이 선택에서 경쟁 상품 관련 BUSL 조건을 제거하지만, 기존 CI와 공급자 검증에 드는 이전 비용까지 없애지는 않는다. 라이선스의 장점은 실제 사업 모델에 적용될 때 비로소 전환 근거가 된다.

상태 암호화는 저장소뿐 아니라 키 운영을 바꾼다

상태 파일은 리소스 속성뿐 아니라 구성에 따라 비밀번호나 토큰 같은 민감한 값도 담을 수 있다. Terraform CLI가 로컬에 저장하는 상태는 평문이며, 원격 백엔드를 사용하면 저장 시 암호화 방식은 그 백엔드에 좌우된다. 따라서 화면에 민감한 출력을 숨기는 설정과 상태 객체 자체를 보호하는 설정은 별개다. 백업, 복제본, 아티팩트 저장소까지 상태가 이동한다면 각 경로에서 누가 객체를 읽을 수 있는지도 중요해진다.

OpenTofu의 상태·계획 파일 암호화 문서는 로컬 저장과 원격 백엔드 모두에서 클라이언트 측 암호화를 지원하고, 적절한 키가 없으면 암호화된 파일을 복구할 수 없다고 명시한다. 저장소에 도착한 상태 사본을 별도의 키 없이 읽지 못하게 하려는 요구가 있다면 분명한 차이다. 반대로 명령을 실행하며 키와 복호화된 상태에 접근할 권한을 가진 사람의 열람까지 막는 기능은 아니다.

키의 가용성이 상태의 가용성이 된다는 점도 결정에 포함해야 한다. 정상적인 상태 백업이 남아 있어도 키를 잃거나 키 관리 서비스에 접근하지 못하면 복구할 수 없다. 암호화는 파일 손상이나 오래된 상태를 다시 사용하는 문제도 해결하지 않는다. 상태 백업과 키 백업을 각각 보관하고, 두 가지를 함께 사용해 복구할 수 있는지 확인해야 한다.

기존 평문 상태에 암호화 설정만 추가하면 OpenTofu는 기본적으로 그 파일을 읽지 않는다. 이전 과정에는 평문을 명시적으로 허용하는 임시 설정과 상태 재기록이 필요하다. 이후 Terraform으로 돌아가려면 암호화된 상태를 읽을 수 있는 동안 평문으로 되돌리는 절차와 상태 호환성을 확인해야 한다. 바이너리 교체와 암호화 적용을 한꺼번에 진행하면 계획 차이와 키 설정 문제의 원인을 구별하기 어려워진다.

HCP Terraform 의존성은 CLI 교체 범위를 넓힌다

HCP Terraform을 쓰는 팀은 실행 파일 외에도 원격 실행, 워크스페이스 권한, 상태 버전과 정책 판정에 의존할 수 있다. HCP Terraform 보안 모델은 워크스페이스별 상태 보관과 접근 권한, 격리된 실행 환경, 저장 상태 암호화를 설명한다. HCL 파일이 OpenTofu에서 읽힌다고 해서 이 운영 환경이 함께 이전되는 것은 아니다.

현재 배포가 HCP의 실행 승인이나 정책 평가를 거친다면, 다른 환경에서도 누가 계획을 보고 적용을 승인하는지 정해야 한다. 비공개 모듈과 공급자를 내려받는 경로, 실행 주체의 인증 정보, 상태 버전 접근 권한도 옮겨야 할 대상이다. 공급자 호환성만 확인한 뒤 CI 명령어를 바꾸면 실제 배포에 필요한 접근 경로가 빠질 수 있다.

이미 자체 CI와 원격 백엔드로 운영하며 HCP 기능을 거의 사용하지 않는 팀은 이전 범위가 상대적으로 작다. 반대로 HCP에서 실행과 상태 관리, 정책 통제를 함께 맡고 있다면 도구 선택은 대체 운영 환경을 마련하는 일과 연결된다. 이 경우 저장 전 암호화의 이점을 평가할 때도 새 키 관리뿐 아니라 기존 권한 체계와 승인 절차를 옮기는 비용을 함께 봐야 한다.

이전 판단표: 상태를 되돌릴 수 있는가

이전 시험은 현재 인프라에 예상하지 못한 변경을 만들지 않는 계획에서 시작한다. OpenTofu의 공식 이전 절차는 구성과 상태를 백업하고 tofu init과 tofu plan으로 확인한 뒤, 작은 변경을 적용하고 문제가 생기면 백업을 복원하도록 안내한다. 기존 Terraform 계획과 OpenTofu 계획이 다른 이유를 설명하지 못한다면 적용을 멈추는 것이 맞다.

• 상태 백업: 로컬 상태는 별도 위치에 복사하고, 원격 백엔드는 이전 버전이나 스냅샷을 실제로 복원할 수 있는지 확인한다. 백업 파일의 존재와 복구 성공은 다른 조건이다.
• 공급자 잠금: 현재 공급자 버전과 잠금 파일을 기록한다. tofu init 뒤 선택된 공급자가 바뀌었다면 CLI 교체의 영향과 공급자 업데이트의 영향을 따로 판별해야 한다.
• 드라이런: 같은 구성과 상태를 기준으로 두 도구의 계획을 대조한다. 예상하지 못한 생성·삭제·교체가 보이면 먼저 공급자 버전, 모듈과 백엔드 설정의 차이를 찾는다.
• 롤백: OpenTofu가 상태를 다시 기록하기 전과 후의 복원 경로를 구분한다. 암호화까지 켰다면 Terraform 명령어로 되돌아가기 전에 상태를 복호화할 수 있는 키와 절차도 필요하다.

이 표에서 가장 큰 차이는 단순한 코드 호환성이 아니라 상태의 복구 가능성이다. 내부 사용에 BUSL 문제가 없고 현재 백엔드의 암호화와 HCP 운영 기능이 요구를 충족한다면 Terraform 유지에 근거가 있다. 저장 전에 상태 사본을 암호화해야 하고 키 복구를 운영할 수 있거나, 외부 고객 대상 상품의 라이선스 조건이 전환을 요구한다면 OpenTofu 이전을 검토할 근거가 강해진다.

함께 읽기:

• Copilot과 Gemini, 가격보다 기존 업무 생태계가 선택을 가른다
• 한국에서 Stripe와 PayPal을 고르면, 수수료보다 먼저 볼 차이
• 프롬프트 캐싱, 켜기만 하면 느려질 수 있다…경계가 비용을 가른다