GCP 고객이 Terraform과 OpenTofu 비교에 관심을 보여 관련 자료를 정리한 적이 있다. 두 도구는 구성 문법과 명령어가 비슷하지만, 도입을 검토할 때는 라이선스와 기존 운영 환경의 호환성까지 확인해야 한다.
Terraform을 이미 사용하는 조직이라면 기존 자동화와 지원 체계를 유지할 이유가 있고, 신규 도입이라면 OpenTofu의 오픈소스 라이선스와 운영 방식을 검토할 수 있다. GCP 리소스를 예로 들어 두 도구의 차이와 선택 기준을 살펴본다.
비교 기준은 2026년 10월 공식 문서다. CLI 기능과 호환 범위는 버전별로 달라질 수 있으므로 실제 도입 시 사용할 버전을 기준으로 확인한다.
1. Terraform과 OpenTofu 개요#
두 도구 모두 IaC(Infrastructure as Code) 방식으로 인프라를 관리한다. HCL 기반 구성 파일에 리소스를 정의하고, provider를 통해 클라우드 API를 호출한다. plan으로 변경 계획을 검토하고 apply로 적용하는 흐름도 유사하다.
OpenTofu는 Terraform의 MPL 라이선스 코드에서 분기한 프로젝트다. Terraform의 라이선스 변경을 배경으로 출범했으며 Linux Foundation 산하에서 개발된다. 현재 두 프로젝트는 각각 기능을 개발하고 릴리스한다. OpenTofu 프로젝트 배경
| 비교 항목 | Terraform | OpenTofu |
|---|---|---|
| 개발·관리 | HashiCorp 제품 체계 | Linux Foundation 산하 프로젝트 |
| CLI 명령 | terraform | tofu |
| 구성 파일 | .tf, HCL 기반 | 기존 .tf 구성의 호환을 목표로 지원 |
| 현행 CLI 소스 라이선스 | BSL 1.1 (Business Source License) | MPL 2.0 (Mozilla Public License) |
| provider 설치 | 기본적으로 Terraform Registry 사용 | 기본적으로 OpenTofu Registry 사용 |
| 기존 운영 환경 검토 | 현재 사용 버전과 자동화·지원 체계 확인 | 구성·provider·backend·state의 전환 호환성 확인 |
라이선스는 Terraform LICENSE와 OpenTofu LICENSE를 기준으로 확인했다. 과거 Terraform 릴리스는 해당 버전의 라이선스를 따르므로 모든 버전을 동일하게 취급하지 않는다.
2. 라이선스와 비용 비교#
소스 코드를 열람할 수 있다는 것과 오픈소스 라이선스로 배포된다는 것은 구분해야 한다. Terraform의 BSL 1.1은 사용 목적에 제한을 두는 소스 공개형(source-available) 라이선스다. OpenTofu의 MPL 2.0은 오픈소스 라이선스이며, 수정·배포 시 고지와 소스 제공 등의 조건을 따른다. 소스를 볼 수 있는지뿐 아니라 어떤 용도로 사용하고 배포할 수 있는지가 차이다. Terraform 라이선스, OpenTofu 라이선스
회사 내부 사용과 서비스 제공의 차이#
회사에서 사용한다는 이유만으로 Terraform CLI 사용이 곧바로 유료가 되지는 않는다. Terraform의 BSL 추가 사용 허가는 조직 내부의 사용을 경쟁 서비스 제공으로 보지 않는다고 명시한다.
예를 들어 사내 GCP 프로젝트의 VPC·VM·GKE 등을 Terraform으로 관리하는 경우와, Terraform을 내장하거나 호스팅해 경쟁하는 유료 인프라 관리 제품을 제공하는 경우는 구분해야 한다. 후자는 제공하는 기능과 사업 형태에 따라 라이선스 검토가 필요하다. Terraform 라이선스 원문
OpenTofu는 MPL 2.0 오픈소스 라이선스를 사용한다. 상용 이용이 가능하며, OpenTofu 자체를 수정·배포할 때는 MPL의 고지와 소스 제공 조건을 확인해야 한다. OpenTofu로 인프라를 관리한다는 이유만으로 사내 애플리케이션 전체를 공개해야 하는 것은 아니다. OpenTofu 라이선스
Terraform CLI와 provider의 라이선스도 구분해야 한다. 이 글에서 사용하는 hashicorp/google provider는 MPL 2.0으로 배포된다. Terraform CLI의 라이선스가 Google provider에도 그대로 적용되는 것은 아니다. 모듈과 외부 플랫폼 역시 각각의 라이선스·이용 조건을 확인한다. Google provider LICENSE
협업 플랫폼 요금과 GCP 리소스 비용#
CLI 라이선스와 협업 서비스 이용료는 별개다. HCP Terraform은 원격 실행, state 관리, VCS 연동 등을 제공하는 서비스로 플랜과 기능 조건을 따로 확인해야 한다. OpenTofu도 실행·승인·권한 관리 플랫폼을 함께 사용한다면 그 플랫폼의 요금과 지원 조건이 별도로 적용된다. HCP Terraform 개요
OpenTofu로 전환하는 것만으로 GCP의 VM 단가가 낮아지지는 않는다. 같은 리전·사양·사용 시간·할인 조건이라면 Compute Engine 요금 기준은 동일하다. 도구를 비교할 때는 클라우드 리소스 비용과 함께 협업 플랫폼 이용료, 지원 계약, 전환 작업 비용을 따로 계산한다. Compute Engine 요금 기준
3. 구성 파일과 provider 호환성#
OpenTofu는 기존 Terraform 구성과의 호환성을 목표로 하며, 공식 문서는 대부분의 Terraform 코드가 수정 없이 동작할 수 있다고 설명한다. 다만 모든 버전과 확장 기능의 호환성을 일괄 보장하는 의미는 아니다. OpenTofu 마이그레이션 개요
예를 들어 Google provider를 사용하는 기본 VPC 구성은 다음과 같다.
terraform {
required_providers {
google = {
source = "hashicorp/google"
version = "~> 7.0"
}
}
}
provider "google" {
project = var.project_id
}
variable "project_id" {
type = string
}
resource "google_compute_network" "example" {
name = "iac-example-vpc"
auto_create_subnetworks = false
}이런 기본 구성에서는 resource 유형과 속성을 Google provider가 해석한다. 도구를 바꾼다고 google_compute_network를 OpenTofu 전용 리소스 이름으로 변경하는 방식은 아니다. 코드의 terraform 블록도 기존 이름을 사용한다.
주요 CLI 명령은 다음과 같이 대응한다. 기존 인프라의 관리 정보인 state를 공유하는 환경에서는 담당 실행 도구를 정하고, 전환 절차에 따라 검증한다.
| 작업 | Terraform | OpenTofu |
|---|---|---|
| 초기화 | terraform init | tofu init |
| 코드 포맷 | terraform fmt | tofu fmt |
| 구성 검증 | terraform validate | tofu validate |
| 변경 계획 | terraform plan | tofu plan |
| 변경 적용 | terraform apply | tofu apply |
| 리소스 삭제 | terraform destroy | tofu destroy |
실제 재사용 여부는 CLI 문법 지원, provider 버전, 모듈, backend 설정을 함께 확인해야 한다. provider의 기본 다운로드 레지스트리도 달라지므로 사내 프록시나 네트워크 허용 목록을 사용하는 환경은 설치 경로를 점검한다. OpenTofu 초기화와 provider 설치 동작은 공식 전환 가이드에서 확인할 수 있다.
4. 기존 state를 유지하며 OpenTofu로 전환하기#
구성 파일을 읽는 것과 기존 state를 안전하게 이어 사용하는 것은 별개의 확인 항목이다. state에는 Terraform 리소스 주소와 실제 클라우드 리소스의 연결 정보가 들어 있다. 이를 잘못 처리하면 기존 VM을 관리하지 못하거나 예상하지 않은 생성·교체 계획이 나올 수 있다. backend는 이 state의 저장 위치와 접근 방식을 설정하는 구성으로, 로컬 파일이나 GCS 같은 원격 저장소를 사용할 수 있다.
OpenTofu로 전환한다고 state 저장소까지 반드시 이전해야 하는 것은 아니다. 기존 GCS backend를 유지하는 경우에도 대상 버전에서 해당 backend의 인증과 state 읽기·쓰기가 정상적으로 동작하는지 확인한다.
운영 환경에서는 다음 순서로 전환을 검토한다.
- 현재 CLI·provider 버전, backend, CI/CD 실행 경로를 기록한다.
- 코드·의존성 잠금 파일·state를 백업하고 자동 배포 작업을 중지한다.
- provider와 모듈 버전을 유지한 상태에서 대상 CLI 버전의 전환 가이드에 따라 초기화하고 변경 계획을 비교한다.
- 예상하지 않은 생성·삭제·교체가 없을 때 제한된 범위에서 적용을 검증한다.
CLI 교체와 provider·모듈 업그레이드를 동시에 진행하면 변경 원인을 구분하기 어렵다. 먼저 도구 전환을 검증하고, 버전 업그레이드는 별도 변경으로 진행한다.
여러 구성 사이에서 terraform_remote_state로 데이터를 참조한다면 state를 작성하는 구성과 읽는 구성을 함께 점검한다. 한쪽만 전환하거나 암호화 방식을 바꾸면 참조하는 쪽에서 state를 읽지 못할 수 있다. OpenTofu 전환 가이드
새 도구로 state를 갱신한 이후에는 이전 CLI로 되돌릴 수 있는지까지 확인해야 한다. 전환 이후 실제 인프라가 바뀌었다면 이전 state만 복원하는 것으로 현재 상태가 일치한다고 볼 수 없다. 복구 시점의 리소스 상태를 기준으로 계획을 다시 확인한다.
OpenTofu의 state·plan 암호화#
OpenTofu는 로컬 및 backend에 저장하는 state와 plan에 자체 암호화를 설정할 수 있다. GCS 버킷의 저장 암호화와는 별도로, OpenTofu가 파일 내용을 암호화하는 기능이다.
암호화된 파일을 읽으려면 해당 설정과 키가 필요하다. 이를 사용하면 다른 도구나 원격 state 참조 구성도 그 형식을 처리할 수 있는지 확인해야 한다. 키를 잃으면 복구할 수 없으므로 기능 도입과 함께 키 보관·복구 방안도 정한다. OpenTofu state·plan 암호화
5. 환경별 선택 기준#
| 사용 환경·요구사항 | 우선 검토할 선택 | 판단 이유 |
|---|---|---|
| Terraform 자동화가 안정적으로 운영 중 | Terraform 유지 | 전환 이점과 검증·교육·자동화 변경 비용 비교 |
| HCP Terraform이나 Terraform Enterprise 기능·지원 계약 사용 | 기존 Terraform 체계 검토 | 승인·정책·원격 실행·지원 계약까지 포함해 판단 |
| 신규 IaC 도입, MPL 2.0 기반 도구 요구 | OpenTofu | 오픈소스 라이선스를 도입 조건으로 충족 |
| 도구를 내장한 인프라 관리 제품·서비스 개발 | OpenTofu 및 Terraform의 적용 조건 비교 | 재배포 조건과 경쟁 서비스 해당 여부 검토 |
| OpenTofu 자체 state·plan 암호화 필요 | OpenTofu | 파일 암호화와 키 관리 요구에 맞는지 확인 |
| 특정 모듈·provider·운영 플랫폼 사용이 필수 | 해당 제품의 지원 조합 확인 | 도구 이름보다 지원 버전과 연동 검증 결과가 우선 |
이미 Terraform을 잘 운영하고 있다면, 라이선스 변경 소식만으로 전환을 결정하기보다 실제 사용 형태와 필요한 기능을 확인하는 편이 합리적이다. 반대로 신규 도입에서 오픈소스 라이선스가 필수 조건이라면 OpenTofu를 처음부터 평가할 이유가 충분하다.
GCP VPC와 VM 같은 기본 리소스를 관리하는 목적이라면 두 도구의 코드 작성 방식은 유사하다. 선택할 때 차이가 커지는 부분은 기존 자동화·협업 플랫폼·지원 계약·라이선스 조건·state 호환성이다. 조직에서 필요한 조건을 먼저 정하고, 후보 도구의 지원 버전으로 계획과 적용 결과를 검증한 뒤 도입한다.