테라폼 운영 강좌 #7 OpenTofu와 라이선스: BSL 전환, IBM 인수, 선택 기준
트랙의 마지막 편은 코드가 아니라 도구 자체의 이야기입니다. 기초 #1에서 “OpenTofu라는 포크가 있고 선택 기준은 마지막에 다룬다"라고 미뤄 둔 약속이기도 합니다. 지금 테라폼을 배우는 사람은 사실상 두 갈래 앞에 서 있습니다. 그 갈림길이 왜 생겼는지, 실제로 무엇이 갈라졌는지, 그리고 어떻게 고를 것인지를 정리하고 트랙을 마무리하겠습니다.
무슨 일이 있었나: 2023년부터의 연표 #
- 2023-08: HashiCorp가 테라폼의 라이선스를 오픈 소스(MPL 2.0)에서 BSL(Business Source License)로 전환했습니다. 갑작스러운 전환에 커뮤니티가 반발했고, 몇 주 만에 마지막 오픈 소스 버전(1.5)에서 포크한 OpenTofu가 출범했습니다.
- 2024: OpenTofu가 리눅스 재단 산하에서 1.6을 시작으로 독자 릴리스를 이어가고, 테라폼과의 기능 분기가 시작됐습니다.
- 2025-02: IBM의 HashiCorp 인수가 완료됐습니다(64억 달러). 테라폼은 IBM 제품군의 일부가 됐습니다.
- 2025-04: OpenTofu가 CNCF(Cloud Native Computing Foundation)에 채택되어 쿠버네티스와 같은 재단의 프로젝트가 됐습니다.
- 2026 현재: 조사에 따라 다르지만 OpenTofu 채택률은 10%대 초반, 테라폼이 여전히 다수파입니다. 다만 신규 평가 대상으로 OpenTofu를 올리는 팀의 비율은 그보다 훨씬 높게 잡힙니다.
BSL이 실제로 금지하는 것 #
라이선스 논쟁은 과열되기 쉬우니 사실관계를 좁혀 둡니다. BSL 하의 테라폼은 소스가 공개되어 있고, 무료로 쓸 수 있고, 상용 서비스의 인프라 관리에 쓰는 것도 자유입니다. 금지되는 것은 테라폼과 경쟁하는 상품에 테라폼을 임베드해 제공하는 것입니다. 즉 #6에서 본 실행 플랫폼 같은 사업을 하는 회사들이 직접 영향권이고, 인프라를 관리하는 최종 사용자 대부분에게 법적 실질 변화는 없습니다. 그런데도 포크가 일어난 이유는 라이선스 조문보다 신뢰의 문제였습니다. 한 번 바뀐 라이선스는 또 바뀔 수 있고, 생태계를 이루던 도구 회사들의 기반이 흔들렸으며, IBM 인수는 “단일 기업의 결정에 걸린 도구"라는 우려를 재확인시켰습니다. OpenTofu가 재단(리눅스 재단, 이후 CNCF) 소속이라는 점을 전면에 내세우는 이유가 여기 있습니다.
무엇이 갈라졌나 #
포크 초기에는 두 도구가 사실상 같았지만, 릴리스가 거듭되며 분기가 실체화됐습니다.
- 문법과 코어: 여전히 대부분 호환입니다. 이 트랙에서 배운 HCL, state, 모듈, 워크플로 개념은 양쪽에 그대로 통합니다. provider·모듈 생태계도 대부분 공유합니다(OpenTofu는 자체 레지스트리를 운영합니다).
- OpenTofu 고유: 대표적으로 state 암호화(state 파일 자체를 암호화해 저장)처럼 커뮤니티 요구가 컸던 기능을 먼저 넣는 행보를 보입니다.
- 테라폼 고유: 실전 #6에서 쓴 ephemeral·write-only 계열처럼 최신 언어 기능이 테라폼에 먼저 실리는 경우가 있고, HCP Terraform·Sentinel 같은 상용 생태계는 테라폼 전용입니다.
실무적 함의는 분명합니다. 개념 학습은 공통 자산이고, 특정 신기능에 의존하는 코드부터 이식성이 깨집니다. 이 트랙의 내용 중에서는 write-only 인수가 대표적인 확인 포인트입니다.
선택 기준 #
- 이미 테라폼을 쓰는 팀: 강제 이주 사유는 없습니다. BSL은 최종 사용자에게 실질 제약이 없고, 전환 비용은 실재합니다. 다만 신기능 의존을 늘릴수록 되돌아올 수 없는 다리가 늘어난다는 것은 인지하고 결정합니다.
- 새로 시작하는 팀: 재단 거버넌스와 라이선스 안정성을 중시하면 OpenTofu, HCP Terraform 생태계나 Sentinel, 최신 언어 기능을 쓰려면 테라폼입니다. 채용 시장의 표기는 아직 Terraform이 다수지만, 개념이 공통이라 이력서 관점의 차이는 크지 않습니다.
- 실행 플랫폼·도구를 만드는 조직: BSL의 직접 영향권이므로 법무 검토 없이 테라폼을 임베드하면 안 됩니다. 이 경우 OpenTofu가 기본값입니다.
마이그레이션 자체는 분기점(1.5/1.6) 부근 버전이라면 state를 그대로 읽어 순조로운 편이고, 멀어질수록 기능 사용 여부의 감사가 먼저입니다. 공식 마이그레이션 가이드가 버전 경로별 확인 항목을 제공하므로, 실행 전 최신 가이드 확인을 전제로 삼으면 됩니다.
트랙을 마치며 #
기초 9편에서 문법과 원리를, 실전 10편에서 myapp 인프라 전체를, 운영 7편에서 팀의 워크플로와 거버넌스를 다뤘습니다. 26편을 관통한 주제를 하나만 꼽으면 인프라에 관한 판단을 리뷰 가능한 기록으로 만드는 것입니다. plan을 읽는 습관(기초 #2)에서 시작해, 안전장치(기초 #7), 시크릿(실전 #6), CI 관문(#1), 정책(#4)까지 전부 그 변주였습니다. 학습을 자격증으로 정리하고 싶다면 HashiCorp의 Terraform Associate가 표준이며, 2026년 1월부터 시험이 003에서 004로 개정되었으니 응시 시점의 현행 코드를 확인하고 준비하면 됩니다. 이 트랙의 기초·실전 내용이 시험 범위의 대부분을 덮습니다.
정리 #
이번 글에서 다룬 내용입니다.
- 2023 BSL 전환 → OpenTofu 포크 → 2025 IBM 인수 완료·CNCF 채택이 현재 지형의 연표입니다
- BSL이 금지하는 것은 경쟁 상품 임베드이며, 인프라를 관리하는 최종 사용자 대부분에게 실질 제약이 없습니다. 포크의 동력은 조문보다 거버넌스 신뢰였습니다
- 문법·개념은 여전히 대부분 공통이고, state 암호화(OpenTofu), ephemeral·write-only(테라폼)처럼 신기능부터 갈라집니다
- 기존 팀은 유지가 기본값, 신규 팀은 거버넌스 대 생태계로 선택, 도구를 만드는 조직은 OpenTofu가 기본값입니다
- Associate 자격증은 2026-01부터 004가 현행입니다. 트랙의 기초·실전이 시험 범위 대부분을 덮습니다
테라폼 트랙 26편이 여기서 완결됩니다. 인프라 코드의 다음 단계로는 이 트랙의 CI 부분을 확장하는 GitHub Actions 자동화, 그리고 쿠버네티스 트랙과의 결합이 자연스러운 이웃입니다. 어느 쪽이든 이 트랙의 코드가 그대로 출발점이 될 것입니다.