Terraform vs OpenTofu, 2026년 중반에 뭘 쓸까

작년까지만 해도 "OpenTofu는 아직 지켜봐야지" 하는 분위기가 있었다. 그런데 올해 들어 상황이 좀 달라졌다. 우리 팀에서 최근 IaC 도구 재검토를 하면서 정리했던 내용을 공유하려고 한다. 결론부터 말하면 케이스 바이 케이스인데, 그 "케이스"를 어떻게 나눠서 봐야 하는지가 핵심이었다.

시장 점유율만 놓고 보면 Terraform이 여전히 우세하다. 2026년 4월 기준으로 OpenTofu 채택률이 12% 정도, Terraform은 여전히 30%대 후반이다. 근데 이 숫자만 보면 안 되는 게, 신규 프로젝트에서 OpenTofu를 선택하는 비율이 훨씬 높다. 기존 Terraform 자산이 없는 팀 기준으로만 보면 이야기가 완전히 달라진다.

라이선스 문제, 실제로 회사에 영향을 주나

이게 우리 팀에서 가장 오래 논의됐던 부분이다. HashiCorp가 2023년에 BSL로 바꾼 뒤로, "우리는 HashiCorp 제품과 경쟁하지 않으니까 문제없다"고 넘어가는 팀이 많았다. 나도 처음엔 그렇게 생각했다.

근데 법무팀에 문의해봤더니 답이 애매했다. BSL의 "경쟁 제품" 정의가 명확하지 않다는 거다. 우리가 사내 플랫폼 팀이라 IaC 도구를 다른 개발팀에게 셀프서비스로 제공하는데, 이게 "경쟁 제품 제공"으로 해석될 여지가 있냐는 질문에 법무팀이 확답을 못 줬다. Elastic이나 MongoDB 같은 다른 BSL 사례를 봐도 해석의 여지가 넓더라.

물론 실제로 HashiCorp가 사내 플랫폼 팀에 소송 걸 가능성은 낮다. 그런데 "가능성이 낮다"와 "리스크가 없다"는 다르다. 규제가 빡빡한 금융권이나 대기업에서 OpenTofu로 넘어간 이유가 이거였다. Fidelity가 5만 개가 넘는 state 파일을 마이그레이션 한 게 대표적이다.

기능 격차, 어느 쪽이 앞서 있나

작년까지는 Terraform이 기능적으로 앞서 있다는 인식이 있었는데, 올해는 반대다. OpenTofu가 오히려 커뮤니티 요청 기능을 더 빨리 넣고 있다.

몇 가지 눈에 띄는 것만 보면:

• 상태 암호화가 OpenTofu 1.7에 네이티브로 들어갔다. Terraform은 여전히 없어서 외부 도구(예: SOPS)를 붙여야 한다. 컴플라이언스 요건 있는 팀에서는 이게 진짜 크다.
• provider for_each가 1.9에 나왔다. 멀티 리전, 멀티 계정 구성할 때 예전엔 provider 블록을 하드코딩해서 반복해야 했는데, 이제 반복문으로 쓸 수 있다.
• -exclude 플래그. 특정 리소스만 빼고 apply 할 때 정말 편하다. Terraform은 -target은 있지만 반대는 없다.
• Early variable evaluation. backend 설정에서 변수를 쓸 수 있게 됐다. 이거 없으면 워크스페이스별로 backend 파일 따로 관리해야 했는데, 이제 하나로 통합 가능하다.

솔직히 이 목록을 처음 봤을 때 "어? 이건 뭐지" 싶었다. 특히 상태 암호화. 우리 팀도 KMS 붙이는 파이프라인 따로 만들어서 관리하고 있었는데, 이걸 도구 레벨에서 지원한다는 게 상당한 차이다.

Terraform 쪽도 놀고 있진 않다. Terraform Stacks 같은 새 기능이 있는데, 다만 이건 HCP(HashiCorp Cloud Platform) 기반이라 오픈소스 CLI만 쓰는 팀에게는 의미가 크지 않다. 이 부분이 사실 Terraform의 방향성을 잘 보여준다. 유료/클라우드 쪽에 리소스를 몰빵하는 느낌이다.

마이그레이션 난이도

여기가 의외였다. 이게 진짜 이래도 되나 싶을 정도로 쉽다.

HCL 파일, 모듈 구조, state 파일 포맷이 다 호환된다. terraform 바이너리를 tofu로 바꾸고 명령어 그대로 쓰면 대부분 그냥 돌아간다. state도 별도 변환 없이 읽는다. 우리도 테스트용 환경 하나 잡아서 옮겨봤는데, tofu init && tofu plan 돌리니까 diff 없이 클린하게 나왔다.

물론 완전히 무통증은 아니다. 몇 가지 걸리는 지점이 있다:

• HCP Terraform(구 Terraform Cloud) 백엔드 쓰던 팀은 옮길 자리를 찾아야 한다. Scalr, Spacelift, env0 같은 대안들이 OpenTofu 지원을 하고 있어서 옵션은 있다.
• 사내 표준 모듈이 HCP 레지스트리에 올라가 있으면 그것도 옮겨야 한다. 우린 자체 Git 레지스트리로 관리하고 있어서 이 문제는 없었다.
• provider 중 일부가 라이선스 이슈로 fork 됐는데(대부분 커뮤니티가 이어받았다), 특수 provider 쓰는 팀은 미리 확인해야 한다.

그래서 우리 팀은 어떻게 결정했나

우선 신규 프로젝트는 전부 OpenTofu로 시작하기로 했다. 이유는 명확하다. 라이선스 리스크 없고, 기능이 오히려 앞서고, 마이그레이션 부담도 없다. 굳이 Terraform을 고를 이유를 못 찾겠다.

기존 프로젝트는 아직 옮기지 않았다. 이유가 두 개인데, 하나는 지금 당장 옮겨서 얻을 이득이 크지 않고(우린 이미 SOPS로 상태 암호화 하고 있고), 다른 하나는 HCP Terraform을 일부 팀이 쓰고 있어서 그 팀들과 조율이 필요하다. 아마 올해 하반기쯤 대대적으로 옮길 것 같다.

한 가지 팁이라면, 옮길 계획이 있든 없든 CI 파이프라인에서 tofu 바이너리로도 동일한 결과 나오는지 정기적으로 테스트해두면 좋다. 우리는 nightly job으로 돌리고 있는데, 이런 준비를 해두면 실제 마이그레이션할 때 심리적 부담이 훨씬 적다.

다른 팀들은 어떻게 쓰는지

주변 팀들 얘기 들어보면 크게 세 가지 패턴이다:

첫 번째는 전면 OpenTofu 이관. 컴플라이언스 이슈나 라이선스 리스크 명확한 곳들. 금융권이나 규제 산업 쪽.

두 번째는 하이브리드. 신규만 OpenTofu, 기존은 Terraform. 우리 팀 케이스가 여기 해당한다.

세 번째는 계속 Terraform. HCP 유료 기능 깊게 쓰고 있는 팀들. Stacks, no-code provisioning, drift detection 등. 이건 진짜 유료 기능 없으면 힘든 경우가 아니라면 굳이 여기 남을 이유가 있나 싶긴 하다.

마치며

작년 이맘때만 해도 "OpenTofu 지켜보자"였는데, 지금은 "안 갈 이유가 뭐냐"에 가까워졌다. 특히 신규 프로젝트라면 정말 고민할 게 없다.

혹시 아직 검토 안 해봤다면, 로컬에서 브랜치 하나 파서 tofu로 apply 해보는 정도만 해봐도 감이 온다. 리스크 대비 시간 투자가 매우 적다.

혹시 다른 관점이나 우리가 놓친 포인트 있으면 댓글로 남겨주시면 감사하겠다. 특히 Terraform에 남기로 결정한 팀들의 이유가 궁금하다.

---

태그: Terraform, OpenTofu, IaC, DevOps, 인프라, 오픈소스