IT/IaC

OpenTofu vs Terraform, 2026년 지금 우리 팀은 뭘 쓰고 있나

gfrog 2026. 7. 19. 12:20

작년 이맘때만 해도 사내에서 "OpenTofu 쓸까요?" 얘기가 나오면 반응은 두 종류였다. "일찍 넘어가는 건 위험하다" 아니면 "어차피 언젠간 넘어갈 텐데". 그 사이에서 결정을 못 하고 시간이 흘렀다.

포크된 지 만 3년, BSL 전환 이슈가 터진 지도 그만큼 지났다. 이제는 어느 쪽이든 "지켜본다"라는 답이 힘을 잃었다. Fidelity가 상태 파일 5만 개, 리소스 400만 개를 OpenTofu로 옮겼다는 발표가 올해 초에 나왔고, 우리 팀 슬랙에도 그 링크가 다시 돌았다. 결국 지난달 두 주짜리 스파이크를 잡고 실제로 병행 운영을 해봤다. 그 기록을 정리한다.

두 도구가 실제로 얼마나 벌어졌나

핵심 CLI 동작만 놓고 보면 plan, apply, import, state mv 같은 워크플로우는 99% 그대로다. 이건 두 도구 다 인정하고 있고, 우리도 확인했다. 리소스 400여 개짜리 프로덕션 스테이트 하나를 골라서 OpenTofu 1.9로 그대로 plan 돌려봤는데 diff가 안 났다. 프로바이더 락 파일 형식도 호환됐다.

차이는 그 위에 얹힌 기능들에서 벌어진다.

OpenTofu만 있는 것

  • state 네이티브 암호화 (v1.7): AES-GCM으로 로컬/원격 상태 파일을 그대로 암호화한다. S3 서버사이드 암호화 위에 한 겹 더 올리는 셈인데, 감사팀 요구사항이 있으면 이게 편하다.
  • provider for_each (v1.9): 리전 여러 개를 동적으로 도는 모듈을 짤 때 그동안은 정말 손이 아팠는데, 이게 되면서 리전별 리소스 관리가 훨씬 깔끔해졌다.
  • -exclude 플래그 (v1.9): -target의 반대. 특정 리소스만 빼고 plan/apply. 데이터베이스 같은 위험 리소스를 잠깐 제외하고 배포할 때 유용하다.
  • backend config에서의 조기 변수 평가 (v1.8): 이게 은근히 크다. 워크스페이스별로 백엔드 키를 변수로 넣을 수 있게 됐다.

Terraform만 있는 것

  • Terraform Stacks: HCP 안에서만 돈다. 오픈 바이너리에는 없다. 우리는 안 쓰지만, 여러 스테이트를 하나의 라이프사이클로 묶어서 관리하는 게 필요한 팀이라면 이거 하나로 Terraform에 남는 이유가 된다.
  • Sentinel: 정책 프레임워크. plan 시점에 태그 강제, 리소스 타입 제한, 비용 정책 강제 같은 걸 엔진 레벨에서 붙일 수 있다. OpenTofu 진영은 OPA/Rego로 대체하는 흐름인데, 이미 Sentinel로 폴리시가 수백 개 쌓여있는 대기업은 옮기기가 쉽지 않다.
  • HCP Terraform의 UI/RBAC/워크스페이스 관리: 이게 가장 크다. 관리자 콘솔이 편하다는 얘기를 부인할 수는 없다.

그래서 뭐가 더 좋은가

이 질문은 잘못 던진 질문이다. 우리 팀 논의에서도 그랬다. "뭐가 더 좋은가"로 시작하면 결론이 안 난다. 대신 세 가지를 봤다.

첫째, 락인의 방향이다. Terraform은 오픈소스 코어를 유지하되 실제 가치는 HCP에 얹는 방향으로 확실히 이동했다. Stacks가 HCP에만 있는 게 그 신호다. 즉 CLI만 쓰는 팀이라면 상관없지만, 운영 편의성을 위해 HCP를 조금이라도 쓰기 시작하면 그 쪽으로 계속 끌려가게 된다. OpenTofu는 반대로 CLI에 기능을 계속 붙이는 방향이다. 위에 어떤 플랫폼을 얹을지는 사용자 선택이다 (Scalr, env0, Spacelift 등).

둘째, 팀 규모와 협업 방식이다. 3~10명이 CLI + S3 백엔드 + 간단한 CI로 돌아가는 팀이면 OpenTofu가 별로 흠잡을 게 없다. 오히려 state 암호화 같은 기능이 편하다. 반대로 스무 명 이상이 워크스페이스 수백 개를 UI로 관리하고, 감사 로그와 RBAC이 필수인 조직이라면 HCP Terraform의 완성도가 아직 앞선다. env0나 Scalr가 그 자리를 노리고는 있지만, 성숙도의 격차는 있다.

셋째, 리스크 톤이다. 이게 실제로 결정타였다. 우리 팀은 대규모 조직이 아니라서 Terraform Stacks나 Sentinel이 없어도 되는 상황이다. 그렇다면 남는 질문은 "BSL 라이선스가 3년 뒤에 또 조여지지 않을 거라고 확신하는가"였다. 아무도 답을 못 했다. 반대로 "OpenTofu 프로젝트가 3년 뒤에 유지될까"에는 다들 "Fidelity, Capital One이 뒤에 있는데 안 유지되면 그게 더 이상하다"고 답했다.

실제로 옮겨보니

파일럿은 사내 sandbox 계정용 리포 하나로 잡았다. 리소스 100여 개, 모듈 8개 규모. 다음 순서로 진행했다.

# 1. 백업
cp terraform.tfstate terraform.tfstate.bak
cp .terraform.lock.hcl .terraform.lock.hcl.bak

# 2. OpenTofu 설치 (asdf 씀)
asdf plugin add opentofu
asdf install opentofu 1.9.1
asdf local opentofu 1.9.1

# 3. plan 비교 (diff가 0이어야 함)
terraform plan -out=tf.plan
tofu plan -out=tofu.plan

terraform show -json tf.plan > tf.json
tofu show -json tofu.plan > tofu.json
diff <(jq -S . tf.json) <(jq -S . tofu.json)

이 diff가 정확히 0이 나오면 통과다. 우리는 프로바이더 락 파일 hash에서 한 줄 걸렸는데, 이건 프로바이더 미러 설정 때문이었고 재초기화 후 사라졌다.

주의할 점 몇 가지:

  • 상태 파일 서명 필드: OpenTofu는 "terraform_version" 필드를 그대로 두지만, 일부 서드파티 툴(Atlantis 예전 버전, terragrunt 특정 버전)이 이 문자열을 파싱해서 문제 삼을 수 있다. 우리는 Atlantis를 안 써서 겪지 않았지만, 슬랙에서 이 얘기가 종종 나온다.
  • 워크플로우 파일: GitHub Actions에서 hashicorp/setup-terraform이 아니라 opentofu/setup-opentofu를 써야 하고, 명령어도 terraform → tofu로 바꿔야 한다. sed 한 줄로 대부분 커버되지만 스크립트가 여러 개면 하나씩 확인해야 한다.
  • 프로바이더 레지스트리: OpenTofu는 자체 registry.opentofu.org를 쓴다. 대부분의 공식 프로바이더는 미러링돼 있지만, 사내 프라이빗 프로바이더를 쓰면 미러 설정을 새로 넣어야 한다.

그리고 개인적으로 놀란 것 하나. tofu CLI가 체감상 조금 빠르다. 정확히 벤치마크한 건 아니지만, plan 반복 실행에서 약간 더 매끄럽게 돌았다. 커뮤니티에도 비슷한 얘기가 몇 번 올라왔는데, 이건 릴리즈에 따라 편차가 있으니 각자 확인하는 게 좋다.

그래서 나는

지금 결론적으로 우리 팀은 신규 리포는 OpenTofu로 뽑고, 기존 리포는 그대로 두는 쪽으로 갔다. 급하게 전환해서 얻을 게 없다는 판단이었다. HCP를 안 쓰기 때문에 락인 이슈에서 자유롭고, 파일럿에서 문제가 안 나온 이상 새로 만드는 것부터 자연스럽게 넘어가는 게 리스크가 가장 낮다.

만약 조직이 HCP Terraform이나 Sentinel을 이미 깊게 쓰고 있다면 얘기가 완전히 달라진다. 그 경우엔 아직 Terraform이 답이다. Sentinel을 대체할 정책 스택을 새로 짜는 비용이 어마어마하기 때문이다.

한 가지 확실한 건, 이제 "지켜본다"라는 답이 유효하지 않다는 것이다. 두 도구 모두 진지하게 굴러가는 프로덕트고, 어느 쪽이든 선택하고 넘어가야 한다. 결정을 미루는 게 가장 비싼 선택이다.

혹시 이미 옮기신 분들이나, 반대로 남기로 결정하신 분들 얘기가 궁금하다. 특히 Atlantis + OpenTofu 조합 쓰시는 분 있으면 어떻게 셋업하셨는지 댓글로 남겨주시면 정말 도움 될 것 같다.

저작자표시 비영리 동일조건 (새창열림)