OpenTofu vs Terraform, 2026년 지금 뭘 쓸까
라이선스 이슈로 시끄러웠던 게 벌써 2년 전이다. 그때는 "일단 지켜보자"로 넘어간 팀이 많았는데, 요즘 다시 이 얘기가 올라온다. 나도 최근에 팀 내부에서 마이그레이션 검토를 했고, 결과적으로는 OpenTofu 쪽으로 기울었다. 이유를 정리해본다.
지금 어디까지 왔나
Terraform은 1.15 라인이 stable, 1.16이 alpha다. OpenTofu는 1.12.2가 stable. 버전 넘버만 보면 Terraform이 앞서가는 것 같지만 실제 CLI 오픈소스 기능은 그 반대다.
HashiCorp가 BSL로 넘어간 뒤 IBM에 인수됐고, 오픈소스 CLI에는 신규 기능이 거의 안 들어간다. 대신 HCP Terraform(관리형)과 AI 어시스트 쪽으로 투자가 몰려 있다. 반면 OpenTofu는 Linux Foundation 산하로 옮겨간 뒤로 기능 릴리스가 꾸준하다. state 암호화(1.7), provider for_each(1.9), backend 설정을 포함한 변수 조기 평가(1.8), -exclude 플래그(1.9) — 이 중 Terraform 오픈소스 CLI에 있는 건 하나도 없다.
실무에서 갈리는 지점
우리 팀은 노드 40대 규모 EKS 클러스터 2개, RDS, VPC 몇 개, 그리고 여러 SaaS provider(Datadog, PagerDuty, GitHub)를 IaC로 관리한다. 두 도구를 비교할 때 정말 체감되는 차이는 세 가지였다.
state 암호화. S3 백엔드에 SSE-KMS를 걸어놓긴 했지만 그건 서버사이드 암호화라 IAM 실수 한번이면 그대로 열린다. OpenTofu는 클라이언트 사이드에서 KMS/Vault/패스프레이즈로 state와 plan 파일을 암호화한다. 백엔드가 잠깐 노출돼도 키가 없으면 읽을 수 없다. 이걸 Terraform에서 하려면 별도 wrapper를 쓰거나 자체 스크립트를 태워야 하는데, OpenTofu는 그냥 백엔드 블록에 몇 줄 추가하면 끝난다.
terraform {
encryption {
key_provider "aws_kms" "state_key" {
kms_key_id = "arn:aws:kms:ap-northeast-2:xxx:key/xxx"
region = "ap-northeast-2"
key_spec = "AES_256"
}
method "aes_gcm" "state" {
keys = key_provider.aws_kms.state_key
}
state {
method = method.aes_gcm.state
}
}
}provider for_each. 이게 진짜 편하다. 계정 20개 넘는 멀티 AWS 환경에서 provider alias 20개 선언하고 있으면 그것만으로 파일이 스크롤 압박이 심하다. OpenTofu에서는 map으로 provider를 iterate 할 수 있다. 처음에는 안 그리워했는데 한번 써보고 나니 왜 진작 안 만들었나 싶은 기능이다.
-exclude 플래그. 반대로 이건 소소하지만 삽질할 때 큰 차이가 난다. -target은 오래 전부터 있었는데, 특정 리소스만 빼고 apply 하고 싶을 때는 나머지 리소스를 다 나열해야 했다. -exclude로 그냥 문제 있는 리소스만 제외하고 돌릴 수 있다.
Terraform이 앞서는 것들
그래도 무조건 OpenTofu가 낫다는 얘기는 아니다. HCP Terraform을 쓰고 있다면 이건 별개의 얘기가 된다. RUN task, policy set, cost estimation, no-code module 같은 관리형 기능은 OpenTofu 진영에는 아직 그 수준으로 구현된 게 없다. Spacelift나 Scalr, env0 같은 서드파티가 OpenTofu를 밀고 있긴 하지만, 각자 결이 조금씩 다르다.
또 하나. Terraform Registry는 여전히 provider와 모듈의 사실상 표준이다. OpenTofu Registry가 별도로 있지만 실제 사용은 대부분 Terraform Registry를 프록시로 가리키는 방식이다. 이론상 문제 없는데, 언젠가 HashiCorp가 정책을 바꾸면 어떻게 될지는 아무도 모른다.
마이그레이션은 얼마나 부담인가
이게 걱정이었는데 생각보다 별거 없었다. 대부분의 팀에게 .terraform 디렉터리 지우고 tofu init 하면 끝이다. state 파일 포맷은 동일하고, HCL 문법도 그대로다. CI에서 terraform 바이너리를 tofu로 바꾸는 게 실제 작업의 90%다.
문제가 될 수 있는 부분은 두 가지 정도.
첫째, 최신 Terraform provider의 일부가 BSL 조건에 걸려서 OpenTofu에서 못 쓰는 경우가 이론적으로 가능한데, 실무에서 부딪힌 적은 아직 없다. AWS/GCP/Azure/Kubernetes provider는 다 그대로 쓴다.
둘째, Terraform Cloud/HCP Terraform과 얽혀 있는 워크플로우가 있다면 그건 통째로 걷어내야 한다. 우리는 원래 Atlantis + S3 백엔드였어서 이 문제가 없었지만, HCP를 쓰던 팀은 이 부분이 진짜 마이그레이션의 본체다.
그래서 뭘 쓸까
내 결론은 이렇다.
- HCP Terraform을 이미 잘 쓰고 있고 관리형 워크플로우가 팀에 녹아 있다 → Terraform 유지. 굳이 옮길 이유 없다.
- 오픈소스 CLI + 자체 CI(Atlantis, GitHub Actions 등)만 쓴다 → OpenTofu로 옮겨도 무방하다. 오히려 state 암호화 하나만 봐도 옮길 이유가 충분하다.
- 신규 프로젝트다 → OpenTofu로 시작하는 게 낫다. 어차피 문법 호환되니 나중에 돌아갈 수도 있고, 반대로 새 기능은 여기서 먼저 나온다.
우리 팀은 두 번째에 해당해서 지난달부터 스테이징 환경을 OpenTofu로 옮겼고 이번 스프린트에 프로덕션도 넘어간다. 옮긴 뒤에 후회한 사람은 아직 없다.
혹시 반대로 Terraform 그대로 쓰기로 결정한 팀 있으면 어떤 이유에서 그랬는지 궁금하다. HCP 종속성 말고 다른 이유가 있는지.