오늘 Terraform 모듈을 열어보면 3년 전에는 존재하지 않았던 질문에 부딪힙니다. 이 코드를 실행하는 바이너리는 terraform인가요, 아니면 tofu여야 할까요? IBM은 HashiCorp 인수를 2025년 2월 27일 64억 달러에 완료했고, OpenTofu는 CNCF Sandbox 프로젝트가 되었습니다 2025년 4월 23일에 그렇게 되었으며, 두 도구 간의 마이그레이션 경로는 이제 공식적으로 문서화되어 있습니다. 이 결정은 더 이상 가정이 아닙니다.
이 글은 관리형 Terraform 플랫폼의 관점이 아니라 인프라 운영 관점에서 작성되었습니다. 목표는 실제 마이그레이션 비용을 라이선스 및 거버넌스 관련 잡음과 분리하는 것입니다. 즉, 마이그레이션 중 무엇이 깨지는지, 정당한 거버넌스 질문은 무엇인지, 그리고 Terraform에 남는 것이 옳은 선택인 경우에 대해 솔직하게 말할 수 있다는 뜻입니다.
이 글은 네 가지를 다룹니다. 2026년 현재 OpenTofu가 무엇인지, Terraform에 없는 기능들, 실제 마이그레이션이 어떤 모습인지, 그리고 흔한 의사결정 상황에 대한 명확한 권장 사항입니다.
요약
- OpenTofu는 Terraform의 오픈소스 포크로, MPL 2.0 라이선스를 사용하며 Linux Foundation이 호스팅하고 2025년 4월 23일부터 CNCF Sandbox 프로젝트입니다. HashiCorp가 2023년 8월 Terraform을 Business Source License로 전환한 이후 Terraform 1.5.x에서 포크되었습니다.
- 2026년 7월 26일 기준 현재 유지관리 릴리스는 v1.12.5이며, GitHub 저장소는 29,000개 이상의 스타를 보유하고 있고, OpenTofu 프로젝트 사이트는 3,900개 이상의 provider와 23,600개 이상의 모듈을 등록하고 있습니다.
- Terraform이 현재 같은 방식으로 따라오지 못하는 OpenTofu 전용 또는 OpenTofu가 앞서가는 기능들을 제공합니다. 클라이언트 측 state 및 plan 암호화, provider
for_each, 조기 변수 평가,enabled메타 인수, 그리고 동적prevent_destroy. 임시(ephemeral) 리소스는 OpenTofu 전용이 아닙니다. Terraform은 1.10 버전부터 이를 지원해 왔습니다. - 로컬이나 S3 state를 사용하는 작은 Terraform 1.5.x 프로젝트라면 순조로운 경로는 짧고 되돌릴 수 있는 마이그레이션일 수 있습니다. 작업이 늘어나는 지점은 CI/CD 참조, HCP 전용 워크플로, 그리고 의존성 락 변경입니다.
- 2026년에 새로운 IaC 프로젝트를 시작한다면 OpenTofu로 시작하세요. 기존 Terraform 배포의 경우, BSL이 발목을 잡을 때, OpenTofu에는 있지만 Terraform에는 없는 기능이 필요할 때, 혹은 IBM이 통제하는 로드맵이 실제 우려 사항일 때 전환하세요. 그렇지 않다면 비용 대비 이득은 미미합니다.
2026년 OpenTofu란 무엇인가
OpenTofu는 Linux Foundation이 호스팅하고, 2025년 4월 23일 CNCF에 Sandbox 프로젝트로 승인되었으며, Mozilla Public License 2.0으로 라이선스가 부여된 Terraform의 오픈소스 포크입니다. 바이너리 이름은 tofu입니다. 설정 언어는 HCL이며, Terraform이 사용하는 것과 동일한 HCL입니다. 대부분의 단순~중간 규모 프로젝트에서는 기존 Terraform 코드베이스가 변경 없이 OpenTofu에서 그대로 실행됩니다.
이 포크는 HashiCorp가 2023년 8월 Terraform을 MPL 2.0에서 Business Source License 1.1로 옮긴 2023년 8월에 시작되었습니다. BSL은 OSI 승인 라이선스가 아니라 소스 공개(source-available) 라이선스이며, "HashiCorp의 상업적 제품과 경쟁하는" 프로덕션 사용을 제한합니다. 5일 만에 OpenTF 선언문이 발표되고 포크가 발표되었습니다. Linux Foundation의 발표는 2023년 9월 20일 OpenTofu를 공식적으로 소개했습니다.
Linux Foundation 발표 Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver, Terramate를 창립 후원사로 이름 올렸으며, 최소 18명의 엔지니어가 최소 5년간 전임으로 참여하기로 약속했습니다. OpenTofu는 마지막 MPL 2.0 버전인 Terraform 1.5.x에서 포크되었습니다.
프로젝트의 현재 상황: v1.12.5가 현재 유지관리 릴리스이며, 공식 사이트는 3,900개 이상의 provider와 23,600개 이상의 모듈을 등록하고 있습니다. 채택 신호는 더 이상 항의성 포크의 초기 추진력에만 국한되지 않습니다. Fidelity 마이그레이션 사례 연구 5만 개 이상의 state 파일과 400만 개의 리소스를 아우르는 프로그램을 설명합니다.
관련 비즈니스 맥락: IBM은 2025년 2월 27일 64억 달러에 HashiCorp 인수를 완료했습니다. Terraform의 로드맵은 이제 훨씬 더 큰 엔터프라이즈 벤더 내부에서 결정됩니다. 이것이 사용자에게 자동으로 좋거나 나쁜 것은 아니지만, 2026년 팀들이 하는 계산의 일부입니다.
OpenTofu가 Terraform과 다른 점
포크 이후 두 프로젝트는 서로 다른 기능 경로를 걸어왔습니다. 아래 표는 요약 버전이며, 이어지는 설명은 각 차이가 실무자에게 어떤 의미인지 설명합니다.
| 기능 | OpenTofu | Terraform | 버전부터 |
|---|---|---|---|
| 클라이언트 측 state 암호화 | 네이티브 (PBKDF2, AWS KMS, GCP KMS, OpenBao) | 저장 시 백엔드가 관리 | v1.7 (2024년 4월) |
| 조기 변수 평가 | 예 | 지원되지 않음 | v1.8 |
제공업체 for_each | 예 | 네이티브 대응 기능 없음 | v1.9 |
| 임시(ephemeral) 리소스 | 예 | 예, Terraform 1.10부터 | OpenTofu v1.11 / Terraform v1.10 |
enabled 메타 인수 | 예 | 지원되지 않음 | v1.11 (2025년 12월) |
동적 prevent_destroy | 예 | 정적 값만 | v1.12 (2026년 5월) |
| 라이선스 | MPL 2.0 (OSI 승인) | BSL 1.1 (OSI 미승인) | 해당 없음 |
클라이언트 측 state 암호화 (v1.7.0, 2024년 4월 30일). OpenTofu는 PBKDF2, AWS KMS, GCP KMS 또는 OpenBao로 도구 내부에서 state와 plan 파일을 암호화할 수 있습니다. Terraform은 일반적으로 저장 시 암호화를 선택된 백엔드에 위임하며, 로컬 state는 평문으로 남습니다. OpenTofu의 클라이언트 측 암호화는 복호화 키가 함께 노출되지 않는 한 도난당한 state 객체나 캐시된 plan을 보호할 수 있습니다. 이는 TLS, 백엔드 접근 제어, 비밀 관리 규율을 대체하지 않습니다.
설정은 대략 다음과 같습니다:
terraform {
encryption {
key_provider "pbkdf2" "passphrase" {
passphrase = var.tofu_state_passphrase
}
method "aes_gcm" "default" {
keys = key_provider.pbkdf2.passphrase
}
state {
method = method.aes_gcm.default
}
}
}제공업체 for_each (v1.9). 리소스를 반복하는 것과 같은 방식으로 provider 설정을 반복할 수 있습니다. 다중 리전이나 다중 계정 구성에서는 오랫동안 이어진 우회 방법 전체를 제거합니다. 더 이상 리전마다 별칭이 붙은 provider를 손수 만들 필요 없이, map 하나로 단일 블록을 구동할 수 있습니다.
조기 변수 평가 (v1.8). 이제 backend와 모듈 source 인수를 포함해 이전에는 제한되었던 위치에서도 변수를 참조할 수 있습니다. 이는 하나의 루트 모듈이 소수의 변수 집합만 다른 여러 환경을 관리할 때 유용합니다.
임시 리소스와 enabled 메타 인수 (v1.11.0, 2025년 12월 9일). OpenTofu 1.11은 임시 리소스와 enabled me타 인수를 추가했습니다. 임시 리소스는 단 하나의 plan/apply 주기 안에서만 존재하며 state에 저장되지 않아 수명이 짧은 자격 증명에 유용합니다. 이들은 OpenTofu 전용이 아닙니다. Terraform은 1.10에서 이를 도입했고 1.11에서 write-only 인수를 추가했습니다. 여기서 OpenTofu만의 기능은 enabled이며, 이는 조건부 count count 곡예 없이 표현식으로 리소스 블록을 켜고 끄는 enabled입니다.
동적 prevent_destroy (v1.12). Terraform의 prevent_destroy 설정은 리터럴 값만 허용합니다. OpenTofu 1.12는 이를 계산식으로 만들 수 있게 해줘서, 하나의 모듈이 staging은 삭제 가능하게 두면서 production은 보호할 수 있습니다.
라이선스 행은 기능으로 드러나지 않는 구조적 차이입니다. MPL 2.0은 OSI 승인을 받았으며 파일 단위 copyleft입니다. Terraform의 BSL 1.1 라이선스는 소스 공개형이며, 추가 사용 제한이 있고, 각 라이선스 대상 저작물이 공개된 지 4년 후 MPL 2.0으로 전환됩니다. 대부분의 팀에게 실질적 영향은 작지만, HashiCorp의 상업 제품과 가까운 무언가를 만드는 벤더에게는 바로 이것이 포크가 존재하는 이유입니다.
마이그레이션: 실제로 무엇이 깨지는가
공식 마이그레이션 가이드 는 의도적으로 짧고 되돌릴 수 있게 설계되어 있습니다. state와 코드를 백업하고, OpenTofu를 설치한 뒤 tofu init를 실행하고, tofu plan 비교한 뒤 작은 변경 사항을 테스트하세요. 어려운 부분은 명령어가 아닙니다. 주변의 CI/CD 참조, HCP 전용 워크플로, 의존성 락 변경, 그리고 포크를 채택하는 데 따르는 조직적 검토가 어려운 부분입니다.
순조로운 경로
HCP Terraform을 사용하지 않고, 파이프라인 참조가 수천 개나 terraform 있지 않은 프로젝트라면 마이그레이션은 간단합니다.
# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak
# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone
# Re-initialize against the OpenTofu registry.
tofu init -upgrade
# Verify parity with what Terraform was doing.
tofu plantofu plan 은 Terraform이 만든 plan과 일치해야 합니다. 예상치 못한 차이가 있다면, 적용하기 전에 provider 버전, 백엔드 설정, 그리고 1.5.x 이후의 Terraform 기능을 확인하세요.
무언가를 실행하기 전에 두 가지 뉘앙스가 중요합니다. 첫째, OpenTofu는 이 가이드가 설명하는 경우에 대해 Terraform 스타일 HCL과 대체로 설정 호환됩니다. 다만 Terraform 1.5.x 이후에 추가된 기능은 여전히 호환성 확인이 필요합니다. 둘째, tofu init -upgrade 가 업데이트될 수 있습니다, .terraform.lock.hcl provider 소스 주소와 checksum 항목을 포함해서요. 이 메타데이터는 인프라 드리프트와 별개로 검토하세요.
진짜 걸림돌
세 가지 요소가 빠른 CLI 마이그레이션을 더 큰 규모의 플랫폼 프로젝트로 바꿔놓을 수 있습니다. 그중 어느 것도 버그가 아닙니다.
HCP Terraform 워크스페이스. OpenTofu는 호환되는 remote 서비스를 위한 cloud 및 remote 통합을 포함하는데 HCP Terraform이 로컬 실행과 state 저장 시나리오에서 포함되는 호환되는 remote 서비스를 위한 것입니다. 더 어려운 부분은 HCP 전용 원격 실행과 플랫폼 기능입니다. Sentinel, run trigger, 동적 자격 증명, Stacks, 그리고 OpenTofu가 완전히 테스트하거나 지원할 수 없는 모든 서비스 동작이죠. 이런 것들이 핵심이라면 먼저 워크스페이스 하나로 시범 운영하세요. HCP를 떠나는 경우라면 state를 마이그레이션하고 그런 플랫폼 제어 기능을 다시 만드세요.
프로 팁: HCP Terraform을 떠나는 것은 인프라가 HCP 전용 워크플로에 의존할 때 가장 큰 숨겨진 비용이 될 수 있습니다. 결정하기 전에 terraform state pull > state.json 실행해서 크기와 리소스 개수를 살펴보세요. 리소스 200개짜리 워크스페이스 하나는 run trigger와 policy set이 있는 50개 워크스페이스 규모와는 전혀 다른 프로젝트입니다. 후자는 도구 교체가 아니라 플랫폼 엔지니어링 마이그레이션입니다.
다음을 위해 하드코딩된 CI/CD 파이프라인 terraform. 모든 terraform plan, terraform apply에 대한 참조, 바이너리 경로, Docker 이미지, GitHub Actions 또는 GitLab CI 단계는 모두 검토가 필요합니다. GitHub Actions의 경우 교체는 대략 이렇습니다:
# Before
- name: Setup Terraform
uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.5.7
- run: terraform init
- run: terraform plan
# After
- name: Setup OpenTofu
uses: opentofu/setup-opentofu@v2
with:
tofu_version: 1.12.5
- run: tofu init
- run: tofu plan이건 사소한 경우입니다. workflow 하나, 저장소 하나. 공유된 composite action, 여러 파이프라인, 재사용 가능한 workflow 라이브러리가 있는 모노레포에서는 검토 범위가 더 넓습니다. 작업은 기계적이지만 CLI 교체보다 시간이 더 걸릴 수 있습니다.
의존성 락 파일 검토. tofu init 가 업데이트될 수 있습니다, .terraform.lock.hcl가 provider 소스 주소와 checksum 항목을 포함해 업데이트될 수 있습니다. OpenTofu 1.12는 완전한 h1: h1: checksum 세트를 추가할 수도 있습니다. 이 diff는 인프라 드리프트가 아니라 별도로 검토하고 커밋할 의존성 메타데이터로 다루세요.
프로 팁: 락 파일 diff는 첫 커밋에서 지저분해 보일 수 있습니다. tofu init -upgrade 깨끗한 브랜치에서 락 파일만 "review OpenTofu lock-file changes"처럼 명확한 메시지로 커밋한 다음, 그 위에 기능 작업을 리베이스하세요. 의존성 메타데이터를 기능 PR에 섞으면 두 변경 사항 모두 검토하기 어려워집니다.
이해관계자의 저항. "이제 우리는 포크를 쓰고 있습니다"라는 말은 조직마다 다르게 받아들여집니다. 솔직한 반박은 OpenTofu가 이 가이드가 설명하는 경우에 대해 Terraform 스타일 HCL과 대체로 설정 호환성을 유지한다는 것이며, 그래서 전환은 대체로 되돌릴 수 있습니다. 만약 OpenTofu가 내일 사라진다 해도 많은 팀이 Terraform을 재설치하고, 락 파일을 검토한 뒤, 동일한 .tf .tf 파일을 계속 사용할 수 있을 것입니다. 포크 이후 기능은 먼저 검증하세요. 이 단서가 완벽한 상호 교환성을 약속하는 것보다 더 신뢰할 만합니다.
마이그레이션이 정말로 어려울 때
이 순조로운 경로가 모든 Terraform 환경에 적용되는 것은 아닙니다.
다음과 같은 경우 마이그레이션은 눈에 띄게 어려워집니다:
- state가 크고(수천 개의 리소스, 수십 개의 워크스페이스) HCP Terraform에 존재할 때.
- 코드베이스가 HCP 전용 기능을 깊이 사용할 때. 워크스페이스에 연결된 Sentinel 정책, run trigger, HCP가 관리하는 동적 provider 자격 증명 등입니다. Terraform Stacks는 HCP 전용이며 OpenTofu에는 대응 기능이 없어 이 글의 범위 밖입니다.
- 기업 감사나 컴플라이언스 프레임워크가 "Terraform"을 공식 IaC 도구로 명시할 때, 이는 기술적 문제 위에 조달과 문서화 문제까지 더해집니다.
- 대규모 모듈 라이브러리가 Terraform 전용 registry 동작에 맞춰 해석되던 내부 버전 제약을 가지고 있을 때.
모든 팀이 마이그레이션해야 하는 것은 아닙니다. 비용 대비 이득은 BSL 제약이 실제로 사용 사례에 영향을 미칠 때, 특정 OpenTofu 기능이 구체적인 무언가를 풀어줄 때, 또는 IBM이 통제하는 로드맵이 조직에 실제 우려 사항일 때만 의미가 있습니다. 이 중 어느 것도 해당하지 않는다면 Terraform에 남는 것은 충분히 타당한 결정입니다.
전환해야 할까요?
여기에는 단 하나의 정답이 없습니다. 팀을 위해 의사결정 트리를 그려보면 네 가지 흔한 형태가 나타나며, 올바른 선택은 여러분이 어떤 형태에 속하는지에 달려 있습니다.
새로운 IaC 도입(그린필드). OpenTofu로 시작하세요. 라이선스는 MPL 2.0이고, 거버넌스는 Linux Foundation과 CNCF 아래에 있으며, 프로젝트는 활발한 릴리스 주기를 가지고 있습니다. 차별점으로는 클라이언트 측 state 암호화, provider for_each, enabled, 그리고 동적 prevent_destroy. BSL로 인한 마찰을 신경 쓸 필요가 없습니다. 이것이 이 글에서 가장 강력한 권장 사항입니다.
기존 Terraform 사용자, 소규모~중간 규모 프로젝트. 세 가지 트리거 중 하나라도 발생하면 전환하세요. 첫째, BSL의 "HashiCorp와 경쟁" 예외 조항에 걸릴 수 있는 제품을 판매하거나 판매할 가능성이 있는 경우입니다. 법적 계산은 MPL 2.0 쪽이 더 명확합니다. 둘째, 클라이언트 측 state 암호화, provider for_each, enabled, 또는 동적 prevent_destroy 필요가 있는데 Terraform의 우회 방법을 더 이상 유지할 가치가 없는 경우입니다. 셋째, 단일 벤더 로드맵보다 다자간 거버넌스를 선호하는 경우입니다. 어느 것도 해당하지 않고 Terraform이 문제없이 돌아간다면 그대로 두세요. 마이그레이션은 많은 환경에서 되돌릴 수 있지만 공짜는 아닙니다.
HCP Terraform 헤비 유저. 이것을 자동으로 백엔드 마이그레이션이 아니라 플랫폼 결정으로 다루세요. OpenTofu는 호환되는 remote 백엔드를 사용할 수 있지만, HCP 전용 원격 실행, Sentinel, run trigger, 동적 자격 증명, Stacks는 여전히 기능별 평가가 필요합니다. 이런 제어가 핵심이라면 먼저 시범 운영하세요. 라이선스, 비용, 거버넌스 이유로 HCP를 떠난다면 이 작업을 플랫폼 마이그레이션으로 계획하세요.
Pulumi나 다른 비 HCL 대안을 고려 중이라면. HCL과 기존 워크플로 대부분을 유지하고 싶다면 OpenTofu가 가장 가까운 경로입니다. Pulumi는 더 폭넓은 플랫폼과 언어 선택지입니다. TypeScript, Python, Go, .NET으로 클라우드 API를 제어하죠. 그쪽으로 옮기려면 변환이나 재작성이 필요할 수 있으니, Terraform에서 OpenTofu로의 단순한 바이너리 교체와는 별도로 평가하세요.
직접 다룰 가치가 있는 것이 하나 더 있습니다. OpenTofu가 부분적으로 SaaS 벤더의 헤지라는 정당한 비판입니다. BSL 변경에 관한 Hacker News 스레드에서는 프로젝트의 창립 멤버들이 자체적인 라이선스 유연성 동기를 가진 상업용 Terraform 플랫폼이라는 우려가 제기되었습니다. 저는 이 우려를 진지하게 받아들입니다. 이를 완화하는 것은 거버넌스 구조, Linux Foundation의 호스팅, CNCF Sandbox 지위, 모든 파일에 적용된 MPL 2.0으로, 이는 향후 재라이선싱을 단일 벤더의 경우보다 훨씬 어렵게 만듭니다. 불가능하게 만들지는 않습니다. 하지만 충분히 비용이 들게 만들어 실질적인 견제 장치가 됩니다.
빠른 결론. 2026년 새로운 IaC 작업이라면 OpenTofu로 시작하세요. 라이선스, 거버넌스, 활발한 개발, 기능 세트가 강력한 기본값을 만듭니다. 기존 Terraform 배포의 경우 위의 세 가지 트리거 중 하나가 해당될 때 전환하세요. 그렇지 않다면 비용 대비 이득은 미미하며 그대로 두는 것도 괜찮습니다.
도구 선택이 명확해지면 다음 실질적인 질문은 OpenTofu를 어디서 실행할 것인가입니다. 이 결정은 비밀 정보 처리, 비용, 재현성, 그리고 팀이 실행 환경에 대해 얼마나 통제력을 갖는지에 영향을 미칩니다.
직접 OpenTofu 실행하기
OpenTofu는 CLI 바이너리입니다. 어디서 실행하느냐가 비용, 보안, 그리고 무엇을 할 수 있는지에 많은 영향을 미칩니다. 배치하기에 대략 세 곳의 합리적인 장소가 있습니다.
노트북 또는 개발 머신. 일회성 계획, 프로토타이핑, 소규모 개인 프로젝트에는 적합합니다. remote state, 잠금, 검토 규율이 이미 강제되어 있지 않다면 공유된 프로덕션 워크플로에는 좋지 않은 기본값입니다. 팀은 대개 마지막으로 tofu apply.
관리형 CI 러너(GitHub Actions, GitLab CI 등). 일반적인 경로입니다. opentofu/setup-opentofu action은 hashicorp/setup-terraform 대체품으로 그대로 쓸 수 있습니다. 이는 대부분의 팀과 프로젝트에서 잘 작동합니다. 트레이드오프: 비밀 정보가 서드파티 CI 서비스를 거치고, 대규모 state 작업에서는 무료 플랜의 분이 소진될 수 있으며, 러너 환경이 임시적이라는 점은 대개 장점이지만 때로는 제약이 됩니다. 참조: GitHub vs GitLab 아직 호스팅형 CI 옵션 중에서 고민 중이라면, 그리고 Best CI/CD Tools 더 넓은 그림을 참고하세요.
VPS에 자체 호스팅한 러너. 관리형 CI의 트레이드오프가 더 이상 통하지 않을 때 유용합니다. 비밀 정보를 서드파티 서비스 밖에 둬야 하거나, CI 분 사용료가 비싸지거나, 지속적인 provider 캐시를 원할 때입니다. 설정은 간단합니다. Linux VPS, OpenTofu 바이너리, GitHub Actions 또는 GitLab Runner 에이전트, 그리고 작업 격리를 위한 Docker입니다. 참조: Install Docker on VPS 가 있다면요. 소규모 팀 러너의 경우 4GB RAM, 2 vCPU, 60GB NVMe면 합리적인 출발점입니다. 더 큰 plan과 더 높은 동시성을 위해서는 CPU, 메모리, 스토리지를 확장하세요.
러너 비밀 정보에 대한 더 엄격한 통제, 지속적인 provider 캐시, 또는 예측 가능한 CI 비용이 필요한 팀이라면 VPS의 자체 호스팅 러너가 합리적일 수 있습니다. 이런 구성에서는 root 접근, 빠른 NVMe 스토리지, 손쉬운 크기 조정, 그리고 더 큰 plan 작업을 위한 충분한 CPU/RAM을 우선시하세요.
Cloudzy Linux VPS 인스턴스는 root 접근, NVMe 스토리지, 유연한 크기 조정을 갖춰 이런 자체 호스팅 러너 패턴에 잘 맞아, 작게 시작해서 OpenTofu 워크로드가 커짐에 따라 러너를 확장할 수 있습니다.
자주 묻는 질문
OpenTofu는 Terraform과 같은가요?
정확히는 아닙니다. OpenTofu는 Terraform 1.5.x의 포크로 시작했으며 Terraform 스타일 HCL과 대체로 설정 호환성을 유지합니다. 동일한 .tf .tf 파일, provider, 그리고 plan/apply plan/apply 워크플로가 많은 프로젝트에서 동일합니다. 라이선스와 포크 이후 추가된 기능에서는 차이가 있습니다. OpenTofu에는 클라이언트 측 state 암호화, provider for_each, enabled, 그리고 동적 prevent_destroy가 있습니다. Terraform도 임시 리소스를 포함해 포크 이후 자체 기능을 가지고 있습니다.
OpenTofu가 제 모든 Terraform Provider를 지원할까요?
AWS, GCP, Azure, Kubernetes, Helm 같은 주요 provider라면 일반적으로 그렇습니다. OpenTofu Registry 는 2026년 7월 기준 3,900개 이상의 provider를 등록하고 있습니다. tofu init 가 업데이트될 수 있습니다, .terraform.lock.hcl tofu init이 메타데이터를 업데이트할 수 있습니다. 틈새, 특정 벤더 전용, 또는 새로 출시된 provider의 경우 전환 전에 가용성과 버전 지원을 직접 확인하세요.
OpenTofu 자체가 언젠가 재라이선싱될 수 있을까요?
미래의 재라이선싱은 Terraform 때보다 어렵지만 불가능하지는 않습니다. OpenTofu는 MPL 2.0이며, Linux Foundation이 호스팅하고, 2025년 4월 23일부터 CNCF Sandbox 프로젝트입니다. 거버넌스는 다자간이며 라이선스는 OSI 승인을 받았습니다. 단일 창립자에 의한 일방적인 재라이선싱은 재단의 헌장 및 제거하거나 다시 작성해야 할 기존 MPL 2.0 기여물 모두와 충돌할 것입니다. 이 우려는 정당하며, 구조적 장벽은 실재합니다.
IBM의 HashiCorp 인수가 Terraform의 미래에 어떤 의미인가요?
IBM은 2025년 2월 27일 64억 달러에 HashiCorp 인수를 완료했습니다. Terraform의 로드맵은 이제 더 큰 엔터프라이즈 벤더 안에 놓여 있습니다. 인수 자체만으로는 향후 라이선스나 제품 방향을 증명하지 않습니다. 소유권을 예측으로 취급하기보다는 현재 릴리스 노트, 라이선스 지침, HCP 제품 변경 사항을 평가하세요.
OpenTofu는 2026년에 프로덕션에 사용할 준비가 되었나요?
네. v1.12.5가 현재 유지관리 릴리스이며, 이 프로젝트는 CNCF Sandbox에 있고, Fidelity는 5만 개 이상의 state 파일과 400만 개의 리소스를 아우르는 IaC 환경 전반에 걸친 프로덕션 도입을 설명했습니다. 프로덕션에 준비되었다는 것이 기능적으로 동일하다는 의미는 아닙니다. Terraform Stacks 같은 HCP 전용 기능에 의존하는 팀은 여전히 별도의 호환성 판단이 필요합니다.
