Terraform vs OpenTofu 실무 선택: BSL 이후 뭘 쓰고 언제 옮길까

"새 프로젝트인데 Terraform 써도 되나요?"라는 질문의 정체

2023년 HashiCorp가 Terraform을 MPL 2.0(오픈소스)에서 BSL(Business Source License) 1.1로 전환한 이후, 인프라 팀 회의에서 빠지지 않는 질문이 생겼습니다. "이거 라이선스 걸리는 거 아니야?" 그리고 2024년 IBM의 HashiCorp 인수가 확정되면서 이 불안은 "벤더 락인을 감수할 것인가"라는 더 큰 의사결정으로 번졌습니다.

동시에 Terraform의 커뮤니티 포크인 OpenTofu가 Linux Foundation 산하에서 안정적으로 성장하며, state encryption 같은 독자 기능까지 붙기 시작했습니다. 이제는 "무엇이 더 좋은가"가 아니라 **"우리 상황에서 무엇을 써야 하는가"**를 판정해야 하는 단계입니다.

이 글은 소개가 아니라 판정입니다. 각 섹션은 결정 근거로 끝나고, 마지막엔 상황별 의사결정표와 복붙 가능한 마이그레이션 명령까지 제공합니다. 참고로 아래 라이선스 해석은 실무 판단 참고용이며, 최종 결론은 반드시 사내 법무 검토를 거쳐야 합니다.

라이선스 판정: 우리 회사가 BSL에 걸리는가

BSL의 핵심 조항은 흔히 오해되는 것처럼 "상업적 사용 금지"가 아닙니다. 정확히는 **"HashiCorp의 상용 제품과 경쟁하는 제품(competitive offering)을 만드는 데 사용 금지"**입니다. 즉 대부분의 사내 인프라 관리 목적 사용은 저촉되지 않습니다.

아래 Yes/No 플로우로 5분 안에 자가 판정할 수 있습니다.

[시작]
  │
  ▼
① 우리는 Terraform으로 만든 결과물을
   외부에 재판매하거나 SaaS/관리형 서비스로 제공하는가?
  │
  ├── No ──▶ [BSL 저촉 가능성 낮음]
  │           (사내 인프라, 자사 서비스 배포 등 → 대부분 안전)
  │
  └── Yes
        │
        ▼
② 그 제품이 HashiCorp의 상용 제품
   (Terraform Cloud/Enterprise 등)과 경쟁하는가?
        │
        ├── No ──▶ [BSL 저촉 가능성 낮음 — 단, 법무 확인 권장]
        │
        └── Yes ──▶ [⚠ BSL 리스크 — 법무 검토 필수 / OpenTofu 검토]

정리하면:

핵심 결정 근거: 당신이 인프라를 "쓰는" 쪽이면 걱정 없이 Terraform을 써도 됩니다. 인프라 자동화 자체를 "파는" 쪽이면 OpenTofu가 안전지대입니다.

기능·호환성 정면 비교

OpenTofu는 Terraform 1.5.x 시점의 포크에서 출발했기 때문에 초기 호환성이 매우 높습니다. 다만 두 프로젝트가 독립적으로 발전하면서 격차가 생기는 지점이 있습니다.

⚠️ 버전별 기능 격차(예: Terraform 1.6/1.7/1.8의 신기능이 OpenTofu 대응 버전에 반영됐는지)는 빠르게 변합니다. 확정 서술 대신 각 프로젝트의 공식 릴리스 노트를 반드시 직접 확인하세요. 특히 최신 stacks·특정 함수·provider-defined functions 지원 여부가 자주 바뀝니다.

결정 근거: state 호환성이 유지되므로 마이그레이션 자체는 기술적으로 저부담입니다. state encryption이 필요하면 OpenTofu가 유일한 내장 옵션입니다.

마이그레이션 실전: terraform → tofu 전환 절차

기술적으로는 놀랄 만큼 간단합니다. 아래는 복붙 가능한 전체 흐름입니다.

1) 바이너리 설치

# macOS (Homebrew)
brew install opentofu

# Linux (스크립트 설치)
curl -fsSL https://get.opentofu.org/install-opentofu.sh -o install.sh
chmod +x install.sh
./install.sh --install-method standalone
rm install.sh

# 설치 확인
tofu version

예상 정상 결과:

OpenTofu v1.x.x
on darwin_arm64

2) 명령 매핑 — 그냥 terraform을 tofu로 바꾸면 됩니다

3) 전환 전 반드시 state와 lock 백업

# 로컬 state인 경우
cp terraform.tfstate terraform.tfstate.bak
cp .terraform.lock.hcl .terraform.lock.hcl.bak

# 원격 backend면 콘솔/버전관리로 state 스냅샷 확보

4) 초기화 및 plan으로 no-op 확인

tofu init -upgrade
tofu plan

예상 정상 결과: No changes. Your infrastructure matches the configuration.

이 no-op이 뜨면 state가 정상 해석된 것입니다. 만약 리소스 재생성(destroy/create)이 계획에 잡히면 절대 apply하지 말고 provider 버전·lock 파일 차이를 먼저 조사하세요.

5) CI 파이프라인 교체 (GitHub Actions)

# Before
- uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: "1.5.7"

# After
- uses: opentofu/setup-opentofu@v1
  with:
    tofu_version: "1.8.0"

Atlantis를 쓴다면 atlantis.yaml 또는 서버 설정에서 실행 바이너리를 지정합니다:

# atlantis.yaml (프로젝트 단위)
projects:
  - dir: .
    workflow: tofu
# server-side: workflows.tofu.plan.steps 에서 tofu 바이너리 호출

6) 롤백 절차

문제가 생기면 되돌리기도 간단합니다.

# 1. 백업한 state/lock 복원
cp terraform.tfstate.bak terraform.tfstate
cp .terraform.lock.hcl.bak .terraform.lock.hcl

# 2. 다시 terraform으로 초기화
terraform init -upgrade
terraform plan   # No changes 확인

state 포맷이 호환되므로 양방향 전환이 가능하다는 점이 심리적 안전판입니다.

실패 분기 체크리스트: 이관이 막히는 진짜 이유

명령은 쉽지만, 실제 이관을 막는 것은 아래 의존성입니다. 전환 전에 체크하세요.

• provider가 OpenTofu Registry에 있는가? 마이너/사내 provider가 미등록이면 소스 주소를 명시(source = "registry.opentofu.org/...")하거나 미러링이 필요합니다.
• TFC/TFE 종속 기능을 쓰는가?
  • remote backend의 워크스페이스 관리 → 부분 호환, 재구성 필요할 수 있음
  • Sentinel 정책 → OpenTofu 미지원 (OPA/Conftest로 대체 검토)
  • Run Tasks / Drift Detection 등 TFC 고유 기능 → 그대로 이관 불가
• 래퍼/도구 체인 호환?
  • Terragrunt: OpenTofu 지원 (terraform_binary = "tofu" 지정)
  • TFLint / tfsec / Checkov: 대부분 HCL 파싱 기반이라 호환되나 버전 확인 필요
• 모듈 소스가 특정 registry에 하드코딩됐는가?

결정 근거: TFC/TFE의 Sentinel·Run Tasks에 깊게 물려 있으면 마이그레이션 비용이 급증합니다. 이 경우 OSS 이관보다 "TFC 유지 vs 셀프호스팅 전환"의 더 큰 결정이 됩니다.

상황별 의사결정표

비용 비교: 오픈소스는 공짜, 진짜 비용은 관리 계층에서

두 CLI 도구 자체는 둘 다 무료입니다. 비용은 협업·정책·상태 관리를 담당하는 "관리 계층"에서 발생합니다.

구체적 단가는 벤더 정책에 따라 수시로 바뀌므로 각 벤더 공식 가격 페이지 확인이 필요합니다.

국내 현황 한 문단: 국내에서도 클라우드 MSP와 플랫폼 팀을 중심으로 OpenTofu 도입 사례가 늘고 있으며, 한글 자료와 커뮤니티 발표도 꾸준히 축적되는 추세입니다. 다만 상용 지원 계약이 필요한 대기업이라면 Terraform Cloud/Enterprise의 공식 지원 채널이나 Spacelift·Env0 같은 상용 벤더의 국내 파트너십 유무를 별도로 확인하는 편이 안전합니다.

결론: 한 줄 판정

• 인프라를 쓰는 쪽 + 신규 프로젝트 → OpenTofu를 기본값으로.
• TFC 고유 기능에 깊게 물린 조직 → 대체 설계 전까지 현행 유지.
• IaC를 파는 벤더 → OpenTofu + 법무 검토.

기술적 마이그레이션은 terraform을 tofu로 바꾸고 tofu plan에서 no-op을 확인하는 수준으로 가볍습니다. 진짜 의사결정은 라이선스와 TFC 종속성에 있습니다.

자주 묻는 질문 (FAQ)

Q. 사내 인프라만 관리하는데 Terraform BSL에 걸리나요? A. 일반적으로 저촉되지 않습니다. BSL은 "HashiCorp 상용 제품과 경쟁하는 제품"에 사용하는 것을 제한하며, 자사 인프라 프로비저닝은 여기에 해당하지 않습니다. 다만 최종 판단은 사내 법무 검토가 필요합니다.

Q. OpenTofu로 옮기면 기존 state를 다시 만들어야 하나요? A. 아니요. state 포맷이 호환되어 동일한 state 파일을 그대로 읽습니다. 백업 후 tofu init, tofu plan으로 no-op(No changes)이 나오는지만 확인하면 됩니다. 문제 시 terraform으로 롤백도 가능합니다.

Q. Terraform Cloud의 Sentinel 정책을 쓰고 있는데 OpenTofu로 갈 수 있나요? A. Sentinel은 OpenTofu에서 지원되지 않습니다. OPA(Open Policy Agent)/Conftest 같은 오픈소스 정책 엔진으로 대체 설계를 먼저 마친 뒤 이관하는 것을 권장합니다.