Terraform vs OpenTofu, 2년 써보고 내리는 조심스러운 결론

OpenTofu 1.0이 나온 게 2024년 초였다. 당시 팀에서 "일단 지켜보자"고 결정한 뒤로 약 2년이 지났고, 그 사이에 우리 팀은 한쪽 서비스 군을 OpenTofu로 옮겨봤다. 나머지는 여전히 Terraform이다. 의도한 건 아니고 어쩌다 보니 그렇게 됐는데, 결과적으로는 같은 조직 안에서 둘을 병행 운영하는 꽤 좋은 비교 실험이 됐다.

요즘 들어 "이제 OpenTofu로 갈아타야 하는 거 아니냐"는 질문을 사내외에서 자주 받는다. 특히 작년 12월에 IBM이 HashiCorp 인수 마무리하면서 분위기가 또 한 번 바뀌었다. 이 글은 그 질문에 대한 내 나름의 답이다. 결론부터 말하면 "상황에 따라 다르다"는 재미없는 답이 맞는데, 적어도 어떤 상황에서 뭘 고려해야 하는지는 좀 정리가 됐다.

2년 전과 뭐가 달라졌나

2024년 초에 OpenTofu를 봤을 때 솔직한 느낌은 "Terraform 복사본"이었다. HCL 문법 그대로, 프로바이더 그대로, state 파일 그대로. 굳이 옮길 이유가 없었다.

지금은 좀 다르다. OpenTofu 쪽에서 Terraform에는 없는 기능을 몇 개 넣기 시작했다. 제일 눈에 띄는 건 이 세 가지다.

첫째, state 파일 native 암호화. 이전에는 S3 backend 쓰면서 KMS 붙이거나 SOPS로 따로 처리해야 했는데, OpenTofu 1.7부터는 backend 설정에 encryption 블록 하나 넣으면 끝난다. 이게 꽤 크다. 우리 팀에서 OpenTofu 쓰는 클러스터들은 이 기능 때문에 파일럿이 길어지지 않았다.

둘째, provider-level for_each. Terraform에서는 provider를 여러 개 선언하려면 alias를 일일이 만들어야 했다. 멀티 리전 배포할 때 리전 5개면 alias 5개 + 리소스마다 provider = aws.region_name 수동 지정. OpenTofu에서는 provider 블록에 for_each 먹는다. 코드가 눈에 띄게 짧아진다.

셋째, 독립 프로바이더 레지스트리. HashiCorp가 2023년 8월에 BSL로 라이선스 바꾸면서 생긴 프로바이더 공급 이슈를 해결하려고 만들었는데, 지금은 2000개 이상 프로바이더가 미러링돼 있다. 실무에서 이게 문제가 된 적은 없지만, 공급망 관점에서 의존처가 분산됐다는 건 장점이다.

반면 Terraform도 가만히 있진 않았다. HCP Terraform(구 Terraform Cloud)의 기능 확장, Stacks 정식 출시, 그리고 Sentinel 정책 엔진의 성숙도. 엔터프라이즈 기능 관점에서는 여전히 Terraform 쪽이 두텁다.

우리가 어느 쪽에 뭘 썼나

지금 우리 팀 상태를 대략 그리면 이렇다. 플랫폼 코어(VPC, 네트워크, 공통 IAM, 데이터 저장소 기본 리소스)는 Terraform + HCP Terraform. 서비스 워크로드용 클러스터 부속물(Karpenter NodePool, External DNS, cert-manager 관련 리소스 등)은 OpenTofu.

나누게 된 이유가 기술적인 판단이었다고 하면 좀 포장이다. 사실은 작년에 새로 세팅한 신규 서비스 팀 한 곳이 "우리는 OpenTofu로 시작할게요"라고 했고, 코어 쪽은 이미 HCP Terraform 위에서 돌고 있어서 옮길 동기가 약했다. 그러다 보니 자연스레 나뉜 거다.

근데 막상 병행해보니 배운 게 꽤 많다.

OpenTofu 좋았던 점

• state 암호화가 진짜 편하다. "비밀은 state에 들어가면 안 된다"는 원칙을 지키기 어려운 상황(예: 외부 서비스 프로비저닝)에서 마음이 편하다.
• provider for_each로 리전 7개 배포 코드가 깔끔하게 줄었다. 기존 Terraform 모듈에서 alias 관리하던 보일러플레이트가 절반 이하.
• 릴리즈 주기가 빠르다. 커뮤니티 이슈 대응이 체감상 2~3주 빠르다.
• 바이너리가 오픈소스(MPL 2.0)라서 보안 리뷰 통과가 쉬웠다. BSL 대응하느라 사내 법무 검토 기다리던 기억이 다른 팀에선 아직 트라우마다.

Terraform(+HCP) 좋았던 점

• Sentinel 정책 엔진이 실전에서 잘 먹는다. "태그 없으면 plan 거절", "특정 인스턴스 타입 금지" 같은 걸 코드로 강제해두면 실수로 운영에 큰 리소스 올라가는 사고가 대부분 차단된다.
• HCP Terraform의 팀/워크스페이스 RBAC이 성숙하다. 자체 구축하면 꽤 큰 일이다.
• 드리프트 감지, 정책 위반 알림, cost 추정 같은 부가 기능이 박스 안에서 다 돌아간다.
• 업스트림 프로바이더 릴리즈와 완전 동기. 신규 AWS 서비스 기능이 나오면 보통 가장 먼저 사용 가능하다.

그래서 마이그레이션, 지금 할 만한가

조건부로 "예"다. 다만 몇 가지는 직접 테스트해봐야 한다.

먼저, state 파일 호환성 이슈는 실제로 있다. OpenTofu 1.7 이상에서 apply를 한 번이라도 돌리면 state 메타데이터에 OpenTofu 고유 정보가 들어갈 수 있고, 그 이후에 Terraform으로 되돌리면 못 읽는 경우가 있다. 편도 티켓에 가깝다는 뜻이다. 돌아올 수 있는 플랜을 미리 짜두거나, state 파일 버전 고정 전략을 세워두는 걸 추천한다.

둘째, 사내 표준과 교육 비용을 과소평가하지 말자. HCL 자체는 같지만 tofu 바이너리 설치, CI 러너 세팅, 레지스트리 미러 정책, 팀원 에디터 플러그인까지 바꿀 게 생각보다 많다. 우리 팀은 이걸 2주 스프린트 하나로 처리했다.

셋째, 엔터프라이즈 기능이 중요하면 Terraform 쪽이 여전히 두텁다. HCP Terraform + Sentinel 조합을 대체하려면 OpenTofu에 Spacelift나 env0 같은 서드파티 플랫폼을 붙여야 한다. 기능적으로는 대체되지만 조달/계약/보안심사 과정이 또 한 번 필요하다.

넷째, "그냥 유행 타서 옮기는" 건 말리고 싶다. OpenTofu 어댑션은 12% 수준이라는 최근 리포트도 있는데(Terraform이 여전히 시장 점유 지배적), 이건 OSS 대 상용의 자연스러운 구도다. 남들이 옮긴다고 옮기는 게 아니라, 우리가 해결하려는 문제가 OpenTofu 쪽에서 풀리는지를 봐야 한다. 우리 팀의 경우 state 암호화와 provider for_each가 충분한 당위였다.

개인적인 결론

나는 신규 프로젝트라면 OpenTofu부터 본다. 라이선스 부담 없고, 주요 기능 차이는 오히려 OpenTofu 쪽이 살짝 앞서 있고, CNCF 거버넌스로 들어간 이상 장기 운영 리스크도 낮다.

기존에 HCP Terraform/Sentinel 위에 두텁게 올라가 있는 레거시라면 무리하지 않겠다. 마이그레이션 비용과 대체 플랫폼 조달 비용을 합치면 얻는 이득보다 클 수 있다. 이건 정말 조직 상황에 달렸다.

그리고 지금 우리 팀처럼 병행 운영도 하나의 선택지다. "모든 팀이 하나의 도구만 써야 한다"는 원칙이 꼭 맞는 건 아니다. 오히려 둘 다 쓰면서 각각의 한계를 몸으로 아는 게 장기적으로 더 나은 의사결정을 돕는 것 같다.

다음에는 OpenTofu state 암호화를 KMS + 자동 키 로테이션과 엮어서 운영하는 법도 한 번 정리해볼까 한다. 혹시 실전에서 OpenTofu 쓰고 계신 분이 계시면, 어떤 부분에서 Terraform보다 편한지/불편한지 댓글로 남겨주시면 저도 공부가 될 것 같다.