오픈토푸와 테라폼을 라이선스, 상태 파일, 레지스트리, 이전 순서로 비교한다. 2023년 8월 BSL 전환과 2025년 2월 아이비엠 인수 이후에도 같은 HCL을 어디에 둘지, tofu plan이 비는지를 오픈소스, 클라우드, 데브옵스, AWS, API, 깃허브, 개발자, 백엔드 기준으로 나눈다. 1.5 상태 호환과 HCP 유지 조건도 표로 둔다.
테라폼 1.6부터는 비즈니스 소스 라이선스라서, 같은 HCL을 써도 바이너리와 라이선스가 갈립니다. 2023년 8월 10일 하시코프가 모질라 공중 라이선스에서 BSL 1.1로 바꿨고, 커뮤니티는 마지막 오픈소스 줄에서 오픈토푸를 갈라 리눅스 재단에 뒀습니다. 공식 FAQ는 테라폼 1.5로 만든 상태 파일까지 오픈토푸가 읽는다고 적습니다. 그보다 새 버전에서 만든 상태는 버전별 이전 문서를 먼저 엽니다.
언어를 바꾸는 비교는 풀루미 글에 있습니다. 입문 명령은 테라폼 입문을, 컨테이너를 어디에 둘지는 컴포즈와 쿠버네티스를 같이 보면 자리가 겹치지 않습니다.
명령은 같은데 라이선스가 갈린다
고르는 기준은 로고가 아니라 다음 분기에도 같은 라이선스로 쓸 수 있는지입니다. 테라폼(Terraform)과 오픈토푸(OpenTofu)는 둘 다 HCL로 인프라를 적고, plan 다음에 apply를 합니다. 2023년 8월 10일 이후 줄은 갈립니다. 하시코프(HashiCorp) 공식 안내는 앞으로 나오는 제품 출시를 BSL 1.1로 둔다고 적었습니다. API와 SDK, 대부분의 라이브러리는 모질라 공중 라이선스(MPL 2.0)를 유지한다고 같이 적혀 있습니다.
빠른 갈래 | 사내에서만 돌리고 라이선스를 오픈소스로 고정하고 싶으면 오픈토푸부터 봅니다. 이미 HCP 테라폼이나 엔터프라이즈 계약을 쓰고 볼트와 한 줄로 묶여 있으면 테라폼을 유지하는 달이 많습니다. 둘 다 쓰기 전에 상태 백업과 plan이 비는지가 먼저입니다.
레지스트리를 바꾸면 프로바이더는 그대로인가
오픈토푸 FAQ는 자기 프로바이더를 따로 만들지 않는다고 적습니다. 테라폼 프로바이더 라이선스는 코어와 달리 그대로인 경우가 많고, 오픈토푸는 그 바이너리를 자기 레지스트리로 받아 씁니다. 주소만 바뀝니다. 하시코프 레지스트리 대신 registry.opentofu.org와 search.opentofu.org를 봅니다.
AWS, 구글 클라우드, 애저, 쿠버네티스, 깃허브처럼 많이 쓰는 줄은 양쪽에서 찾을 수 있습니다. 공식 소개도 수천 개 프로바이더를 공개 레지스트리에 둔다고 적습니다. 그래도 init이 한 번에 끝나지 않으면, 미러나 잠금 파일이 옛 호스트를 가리키고 있는지부터 봅니다.
볼트, 콘설, 노마드처럼 하시코프 제품 프로바이더는 테라폼 쪽이 먼저 갱신되는 경우가 있습니다. 그 제품을 인프라의 한가운데에 두고 있으면, 레지스트리만 바꿔서는 안 됩니다. 프로바이더 버전 제약과 잠금 해시가 어느 호스트에서 왔는지 같이 적습니다.
로고와 문법은 익숙해도 1.6 이후 코어 라이선스는 BSL이다. 받는 레지스트리 주소를 먼저 본다
상태 파일을 그대로 넘기다 깨지는 지점
공식 FAQ 문장은 짧습니다. 오픈토푸는 테라폼 1.5.x까지 만든 상태 파일을 읽는다고 적혀 있습니다. 1.6 이후에서 만든 상태는 “바이너리만 갈아끼우면 된다”고 단정하지 않습니다. 사이트에도 1.6, 1.7, 1.8, 1.9처럼 출발 버전을 나눈 이전 안내가 있습니다. 1.5 이하에서 오면 오픈토푸 1.6.2를 거쳐 최신으로 올리라고 적힌 페이지도 있습니다.
원격 상태로 여러 스택이 서로를 읽는 구성은 한 저장소만 바꾸면 안 됩니다. 오픈토푸 이전 안내는 terraform_remote_state로 연결된 여러 설정을 한꺼번에 옮길 때 순서를 따로 보라고 적습니다. S3 버킷에 버전 관리가 꺼져 있으면, 잘못 apply한 뒤 되돌릴 자리가 없습니다.
오픈토푸 1.7부터는 상태와 플랜을 디스크에 둘 때 암호화를 켤 수 있습니다. 키 없이 읽히지 않게 막는 기능입니다. 한 번 켜면 키를 잃어버린 상태 파일은 복구가 어렵습니다. 공식 문서는 재해 복구 연습을 하고 암호화되지 않은 백업을 잠시 둔 뒤에 켜라고 적습니다. 테라폼으로 다시 돌아가려면 그 암호화 줄을 먼저 풀어야 합니다.
테라폼을 상품에 넣으면 BSL이 먼저 걸린다
사내 스테이징에 가상 머신을 올리는 팀과, 고객 계정에 인프라를 대신 만들어 주는 팀은 라이선스 질문이 다릅니다. 하시코프 FAQ는 내부 사용과 일부 통합은 허용 범위로 안내합니다. 오픈토푸 쪽은 BSL의 “경쟁”과 “임베딩” 해석이 나중에 바뀔 수 있다고 보고 포크를 만들었습니다. 법률 판단은 이 글이 대신하지 않습니다. 법무와 계약서가 최종입니다.
쓰는 자리
먼저 볼 것
자주 가는 갈래
개인 랩, 사이드
BSL도 비상업 사용은 넓게 안내
둘 다 가능. 나중에 팔 계획이면 오픈토푸가 단순
사내 플랫폼만
내부 사용 조항, 벤더 약관
라이선스 고정이 필요하면 오픈토푸
고객에게 매니지드 인프라
경쟁 상품 해당 여부
법무 검토 전제. 오픈토푸를 기본 후보로 두는 팀이 많음
이미 HCP 계약
원격 실행, 정책, 감사 로그
테라폼 유지가 비용보다 쌀 수 있음
2025년 2월 27일 아이비엠은 하시코프 인수를 마쳤다고 발표했습니다. 기업 가치는 64억 달러로 적혀 있습니다. 제품이 아이비엠 자동화 포트폴리오로 옮겨 가는 안내는 하시코프 고객 공지에 있습니다. 인수가 라이선스를 MPL로 되돌렸다는 공식 문구는 없습니다. 계약과 BSL 조항은 따로 읽습니다.
상태 파일은 실제 자원의 지도다. 상품에 테라폼을 넣기 전에 내부 사용 조항과 경쟁 조항을 같이 읽는다
옮길 때 plan이 비어야 한다
오픈토푸 이전 가이드는 순서를 짧게 적습니다. 상태와 설정을 백업하고, 바이너리를 깔고, init과 plan으로 읽히는지 확인한 뒤, apply로 상태 표기를 맞추고, 작은 변경으로 한 번 더 확인합니다. plan에 예기치 않은 생성이나 삭제가 보이면 apply를 누르지 않습니다.
오픈토푸 공식 이전 순서 (백업 이후)
tofu --version
tofu init
tofu plan
# plan이 비거나, 테라폼과 같은 결과일 때만
tofu apply
설치 확인은 tofu --version입니다. 공식 설치 안내와 깃허브 릴리스, 패키지 관리자, 도커 이미지가 있습니다. 2026년 5월 14일 오픈토푸 1.12.0이 나왔습니다. 같은 모듈 안에서 prevent_destroy를 변수로 켤 수 있고, init이 잠금 파일에 여러 플랫폼 해시를 더 채웁니다. 윈도 원격(WinRM) 프로비저너는 이 버전에서 폐기 예고가 붙었습니다. 1.13에서 빼겠다고 적혀 있습니다.
되돌리는 길도 문서에 있습니다. 오픈토푸를 당장 멈추고, 백업 상태를 되돌린 뒤 terraform init과 terraform plan으로 읽히는지 봅니다. 암호화된 상태를 테라폼이 읽지 못하면, 오픈토푸 쪽에서 암호화를 푼 뒤에야 돌아갑니다. CI 워크플로 이름만 바꿔 두고 상태 백업을 안 한 채 옮기면, 그다음 주 온콜이 상태를 고칩니다. 재사용 워크플로 칸은 깃허브 액션 재사용에 있습니다.
apply 전 한 줄 | 원격 상태 버킷에 버전 관리를 켜 두고, 로컬이든 원격이든 상태 사본을 따로 둡니다. plan이 리소스를 갈아엎으면 원인은 거의 항상 프로바이더 호스트, 버전 제약, 암호화 키, 원격 상태 주소 중 하나입니다.
테라폼을 유지하는 편이 맞는 팀
오픈토푸가 항상 이기는 비교가 아닙니다. HCP 테라폼에서 원격 실행, 정책, 감사 로그, 프라이빗 레지스트리를 이미 사고 있다면 바이너리만 바꾸는 이득이 작습니다. 볼트와 테라폼을 한 지원 창구로 쓰는 계약도 마찬가지입니다. 아이비엠 인수 뒤 이름과 청구 화면이 바뀌는 안내는 고객 공지를 따릅니다. 국내 발행 카드로 클라우드 콘솔을 결제하면 부가세와 환율이 붙는 달이 있습니다. 청구서 한 줄이 최종입니다.
테라폼만의 새 문법이나 클라우드 전용 기능을 이미 쓰고 있으면, 오픈토푸 FAQ도 미래 버전 호환을 커뮤니티가 고른다고 적습니다. 빠진 기능은 이슈로 올리라고 되어 있습니다. “앞으로 모든 출시가 초 단위로 같다”는 약속이 아닙니다. 그래서 옮기기 전에 쓰는 기능 목록을 한 장 적습니다. 모듈 소스, 프로바이더 제약, 원격 상태 주소, HCP 전용 블록이 그 장에 들어갑니다.
1인 사이드라면 라이선스 리스크보다 운영 단순함이 먼저입니다. 저는 사이트를 코드로 잠글 때 다음 분기에도 같은 라이선스로 포크할 수 있는지를 먼저 봅니다. 고객에게 인프라를 대신 올리는 상품이 아니면, 이미 익숙한 테라폼을 유지하고 상태 백업만 단단히 해도 됩니다.
여기서 가장 많이 실수하는 전환 설정
바이너리 별칭만 바꾸고 잠금 파일을 그대로 두면, init이 옛 레지스트리를 두드립니다. CI 이미지에 terraform만 있고 tofu가 없으면 머지 파이프라인이 밤사이에 깨집니다. 로컬은 오픈토푸인데 배포 잡은 테라폼인 상태도 같습니다. 도구 버전을 한 파일에 고정하고, 그 파일을 로컬과 CI가 같이 읽게 합니다.
상태 암호화를 켠 뒤 키를 채팅에 붙여 넣는 실수도 있습니다. 공식 문서는 사람이 많이 만져야 하면 프로덕션 plan과 apply를 CI에서만 돌리라고 적습니다. 키 순환이 필요한 알고리즘이면 키 관리 서비스를 쓰라고도 적혀 있습니다. 암호화는 유출을 줄이지, 오래된 플랜을 다시 실행하는 공격까지 막지는 않습니다.
한글 주석과 변수 이름은 호환과 무관합니다. 깨지는 쪽은 거의 항상 백엔드 주소, 워크스페이스 이름, 프로바이더 소스 호스트입니다. 리버스 프록시 뒤에 자기 레지스트리 미러를 둘 때는 엔진엑스 HTTPS 설정과 인증서 만료를 같이 봅니다.
프로바이더 소스와 리전은 설정에 남는다. 백업 없이 바이너리만 바꾸지 않는다
풀루미와 자리는 겹치지 않는다
풀루미는 타입스크립트나 파이썬으로 인프라를 적습니다. 테라폼과 오픈토푸는 HCL을 유지한 채 라이선스와 거버넌스가 갈린 비교입니다. “테라폼이 싫어서 다른 도구”를 고르는 자리와, “같은 모듈을 오픈소스로 고정”하는 자리는 다릅니다. 언어를 바꾸고 싶으면 풀루미 비교를 열고, 모듈과 상태 형식을 유지하고 싶으면 이 표만 봅니다.
쿠버네티스 위에 앱을 올리는 문제와 클라우드 계정의 네트워크, 디비, 아이엠을 잠그는 문제도 다릅니다. 컴포즈로 충분한 서비스를 클러스터로 옮기는 결정은 오케스트레이션 글에 맡깁니다. 여기서 고르는 것은 plan을 누가 실행하고, 상태 파일을 어떤 라이선스의 바이너리가 읽느냐입니다.
참고 자료
하시코프 BSL 채택 발표 - 2023년 8월 10일, 이후 출시를 BSL 1.1로 둔다는 공식 안내
라이선스와 호환 범위는 수시로 바뀝니다. 위 표는 2026년 8월 공개 페이지 기준 점검용이며, 계약과 적용의 최종 근거는 공식 화면과 법률 검토입니다.
자주 묻는 질문
테라폼 설정을 오픈토푸가 그대로 읽나?
대부분은 읽습니다. 공식 안내는 호환을 목표로 한다고 적습니다. 그래도 백업 뒤에 tofu init과 tofu plan을 먼저 돌립니다. plan이 리소스를 새로 만들거나 지우면 apply를 누르지 않습니다. 테라폼 전용 클라우드 블록이나 새 문법이 있으면 그 줄부터 걷습니다.
상태 파일은 그냥 복사하면 되나?
테라폼 1.5까지 만든 상태는 공식 FAQ가 읽는다고 적습니다. 1.6 이후에서 만든 상태는 출발 버전에 맞는 이전 페이지를 엽니다. 원격 상태로 스택이 서로 물려 있으면 한 저장소만 바꾸지 않습니다. S3 버전 관리와 상태 사본을 먼저 둡니다.
사내 배포만 하면 BSL이 문제 없나?
하시코프 FAQ는 내부 사용을 넓게 안내합니다. 고객 계정에 인프라를 대신 올리는 상품, 경쟁 콘솔에 테라폼을 넣는 상품은 조항이 다릅니다. 이 글이 법률 판단을 대신하지 않습니다. 약관과 법무 메모가 최종입니다.
아이비엠 인수 뒤에 라이선스가 다시 열렸나?
2025년 2월 27일 인수는 완료됐습니다. 라이선스를 MPL로 되돌린다는 공식 문구는 인수 발표에 없습니다. 제품 이름과 청구 창구가 아이비엠 쪽으로 옮겨 가는 안내는 고객 공지를 따릅니다. 라이선스 조항은 별도로 읽습니다.
HCP 테라폼을 쓰면 오픈토푸로 못 가나?
원격 실행과 정책, 감사 로그를 HCP에 맡겨 두었다면 바이너리만 바꿔서는 그 화면이 따라오지 않습니다. 상태만 가져올 수 있는지는 백엔드 종류와 계약에 달립니다. 이미 그 화면을 팀 절차의 한가운데에 두었다면 테라폼을 유지하는 달이 많습니다.
풀루미로 가는 편이 더 빠르지 않나?
언어를 타입스크립트나 파이썬으로 바꾸고 싶을 때의 비교입니다. 같은 HCL 모듈과 상태 형식을 유지한 채 라이선스만 고정하고 싶으면 오픈토푸 쪽입니다. 두 결정을 한 표에 섞으면 마이그레이션 범위가 커집니다.
