🍀 HashiCorp가 배신했다? — Terraform의 역사와 OpenTofu가 탄생한 진짜 이유

오픈소스는 공짜가 아니다. 다만 자유롭다.
그 자유를 누군가 빼앗으려 할 때, 커뮤니티는 포크(fork)로 답한다.

🎯 이 글에서 다루는 것

• Terraform이 어떻게 IaC(Infrastructure as Code)의 표준이 됐는지
• HashiCorp가 라이선스를 바꾼 이유와 커뮤니티의 반응
• OpenTofu가 탄생한 배경과 CNCF에 합류한 이유
• OpenTofu vs Terraform, 지금 어떤 차이가 있는가
• OpenTofu의 미래와 우리가 어떤 선택을 해야 하는가

---

📌 도입 — "우리가 믿던 그 도구가 갑자기 달라졌다"

인프라를 코드로 관리한다는 개념, IaC(Infrastructure as Code). 이 분야에서 오랫동안 사실상의 표준(de facto standard)이었던 도구가 바로 Terraform입니다.

 

AWS, Azure, GCP를 막론하고 클라우드 인프라를 .tf 파일 몇 줄로 선언하면 뚝딱 만들어주는 그 Terraform. 수백만 명의 엔지니어가 매일 쓰는 이 도구가 2023년 8월, 갑작스럽게 라이선스를 바꿨습니다.

 

반응은 즉각적이었습니다. 커뮤니티는 분노했고, 기업들은 당황했으며, 결국 OpenTofu라는 새 프로젝트가 태어났습니다. 단 몇 달 만에 CNCF(Cloud Native Computing Foundation)의 공식 프로젝트가 되었죠.

 

이 글은 그 전말을 처음부터 끝까지 정리합니다. Terraform의 역사부터, 왜 OpenTofu가 탄생해야만 했는지, 그리고 앞으로 어떻게 될지까지.

---

🔍 Terraform의 역사 — 어떻게 IaC의 왕좌에 올랐나

탄생 (2014년)

Terraform은 HashiCorp가 2014년에 만든 오픈소스 IaC 도구입니다. HashiCorp는 Vagrant, Consul, Vault, Nomad 등 인프라 관련 도구들로 유명한 회사죠.

 

당시의 문제는 이랬습니다. 클라우드가 폭발적으로 성장하면서 인프라 자원을 콘솔(GUI)로 클릭클릭 만드는 방식이 한계에 부딪혔습니다. 수백 대의 서버, 수십 개의 네트워크 설정을 손으로 관리한다? 불가능합니다. 실수도 많고, 재현도 안 되고, 협업도 힘듭니다.

Terraform의 해답은 간단하면서도 강력했습니다.

# main.tf — AWS EC2 인스턴스 하나를 선언하는 예시
provider "aws" {
  region = "ap-northeast-2"  # 서울 리전
}

resource "aws_instance" "web" {
  ami           = "ami-0c9c942bd7bf113a2"
  instance_type = "t3.micro"

  tags = {
    Name = "my-web-server"
  }
}

 

이 파일 하나면 terraform apply 한 방에 EC2 인스턴스가 생깁니다. terraform destroy하면 깔끔하게 지워집니다. 코드니까 Git으로 버전 관리도 되고, 팀원과 공유도 됩니다.

성장 (2015~2020년)

Terraform의 핵심 설계 철학은 선언형(Declarative) 방식입니다. "이렇게 만들어줘"가 아니라 "최종 상태는 이거야" 라고 선언하면, Terraform이 현재 상태와 비교해서 필요한 작업만 알아서 합니다.

 

또한 Provider 생태계가 폭발적으로 성장했습니다. AWS, Azure, GCP는 물론이고 GitHub, Datadog, Cloudflare, Kubernetes까지 — 수천 개의 Provider가 Registry에 올라왔습니다. 사실상 "클라우드 세계의 모든 것"을 Terraform으로 관리할 수 있게 된 거죠.

# 여러 클라우드를 동시에 관리하는 예시
provider "aws" {
  region = "ap-northeast-2"
}

provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
}

# AWS에 S3 버킷
resource "aws_s3_bucket" "backup" {
  bucket = "my-backup-bucket-2024"
}

# Azure에 Storage Account
resource "azurerm_storage_account" "backup" {
  name                     = "mybackupstorage2024"
  resource_group_name      = var.resource_group
  location                 = "koreacentral"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

 

멀티클라우드 전략을 쓰는 기업에게 Terraform은 선택이 아니라 필수가 됐습니다.

전성기 (2020~2023년)

2021년 HashiCorp는 나스닥에 상장합니다. 기업 가치 수십억 달러. Terraform은 DevOps/클라우드 엔지니어라면 반드시 알아야 하는 도구가 됐고, 관련 자격증(HashiCorp Certified: Terraform Associate)도 등장했습니다.

 

하지만 상장 기업이 된다는 것은 커뮤니티보다 주주와 투자자에게 답해야 한다는 의미이기도 합니다. 그리고 2023년, 그 균열이 드러납니다.

---

💥 라이선스 변경 — 그날의 충격

2023년 8월 10일

HashiCorp는 Terraform을 포함한 자사 주요 제품들의 라이선스를 기존 MPL 2.0(Mozilla Public License 2.0)에서 BSL 1.1(Business Source License 1.1)로 변경한다고 발표했습니다.

 

이게 왜 문제냐고요? 차이를 비교해보겠습니다.

항목	MPL 2.0 (기존)	BSL 1.1 (변경 후)
개인 사용	✅ 자유	✅ 자유
기업 내부 사용	✅ 자유	✅ 자유
오픈소스 프로젝트	✅ 자유	✅ 자유
HashiCorp와 경쟁하는 제품/서비스 구축	✅ 가능	❌ 불가
OSI 공식 오픈소스 인증	✅ 인증됨	❌ 인증 안 됨

 

핵심은 하나입니다. "HashiCorp의 경쟁자가 Terraform을 이용해 상업적 서비스를 만들 수 없다."

 

HashiCorp의 논리는 이랬습니다. "일부 기업들이 우리 오픈소스로 돈 벌면서 기여는 안 한다. 우리도 지속 가능한 비즈니스를 해야 한다." 틀린 말은 아닙니다.

하지만 커뮤니티의 반응은 달랐습니다.

우리가 10년 동안 기여하고 생태계를 키운 건 오픈소스라서였다.
이제 와서 규칙을 바꾸면, 그게 배신 아닌가?

 

Spacelift, Env0, Scalr 같이 Terraform 기반으로 서비스를 만들던 기업들은 직격탄을 맞았습니다. HashiCorp의 Terraform Cloud와 경쟁하는 구조였으니까요.

---

🍀 OpenTofu의 탄생 — 커뮤니티의 포크(Fork)

OpenTF Manifesto (2023년 8월)

라이선스 변경 발표 직후, 커뮤니티는 빠르게 움직였습니다. 수십 개의 기업과 수천 명의 개발자들이 OpenTF Manifesto에 서명했습니다. 요지는 간단했습니다.

1. HashiCorp에게 MPL 2.0으로 돌아올 것을 요청한다
2. 돌아오지 않으면 우리가 직접 진정한 오픈소스 Terraform 포크를 만들겠다

서명에 참여한 기업만 해도 Gruntwork, Spacelift, Env0, Terragrunt 개발사 등 굵직굵직한 곳들이었습니다. HashiCorp는 응하지 않았습니다.

OpenTofu 탄생 (2023년 9월)

그렇게 OpenTofu가 태어났습니다. Terraform의 마지막 MPL 2.0 버전(1.5.x)을 베이스로 한 공식 포크입니다.

이름의 유래가 재밌습니다. 🍀 토끼풀 모양 클로버 이모지를 활용한 마스코트, 그리고 Tofu(두부). 두부는 어떤 요리에도 어울리고, 형태를 자유롭게 바꿀 수 있으며, 오픈소스처럼 누구나 만들 수 있습니다. 오픈소스 철학을 음식으로 표현한 센스 있는 네이밍이죠.

OpenTofu 초기 참여 기업/프로젝트:
- Gruntwork (Terragrunt 개발사)
- Spacelift
- Env0
- Scalr
- Digger
- Terramate
- ... 수십 개 기업

CNCF 합류 (2023년 9월)

OpenTofu는 놀라운 속도로 CNCF(Cloud Native Computing Foundation) Sandbox 프로젝트로 합류했습니다. 발표 후 불과 몇 주 만의 일입니다.

---

☁️ CNCF란 무엇이고, 왜 OpenTofu가 거기 들어갔나

CNCF 소개

CNCF는 Linux Foundation 산하의 비영리 단체입니다. Kubernetes, Prometheus, Envoy, Argo CD, Helm 등 클라우드 네이티브 생태계의 핵심 프로젝트들을 품고 있는 곳이죠. 쉽게 말해 "클라우드 네이티브 세계의 공식 홈" 입니다.

CNCF 프로젝트가 된다는 것의 의미:

• 🔒 중립성 보장: 특정 기업의 이해관계에서 독립
• 💰 재정 지원: 인프라, 마케팅, 법률 지원
• 🏛️ 거버넌스: 투명한 의사결정 구조
• 🌍 커뮤니티: 글로벌 기여자 네트워크

OpenTofu가 CNCF를 선택한 이유

OpenTofu의 가장 큰 위험은 "또 다른 HashiCorp"가 되는 것이었습니다. 처음엔 오픈소스로 시작했다가 나중에 상업적 이해관계로 라이선스를 바꾸는 일이 반복될 수 있으니까요.

CNCF 합류는 이 위험을 구조적으로 차단합니다.

• 어떤 단일 기업도 OpenTofu를 "소유"할 수 없습니다
• 라이선스 변경은 커뮤니티 전체의 합의 없이 불가능합니다
• MPL 2.0 라이선스는 영구적으로 유지됩니다

Kubernetes가 Google에서 CNCF로 이관된 것처럼, OpenTofu도 같은 길을 걷는 것입니다.

---

🔄 OpenTofu vs Terraform — 지금 얼마나 다른가

초기에는 거의 동일했습니다. Terraform 코드를 그대로 OpenTofu에서 쓸 수 있었죠. 하지만 시간이 지나면서 차이가 생기고 있습니다.

현재(2024~2025년) 주요 차이점

기능 Terraform OpenTofu

라이선스	BSL 1.1 (비오픈소스)	MPL 2.0 (오픈소스)
State 암호화	❌ 미지원	✅ 네이티브 지원
Provider 함수	제한적	확장 지원
개발 투명성	HashiCorp 주도	커뮤니티 주도
GitHub Stars 증가세	둔화	가파른 상승

 

특히 State 파일 암호화는 OpenTofu의 킬러 피처입니다. Terraform의 State 파일은 민감한 정보(패스워드, API 키 등)가 평문으로 저장되는 경우가 있어 보안 우려가 컸는데, OpenTofu는 이를 네이티브로 지원합니다.

# OpenTofu — State 암호화 설정 예시
terraform {
  # OpenTofu에서는 'terraform' 블록을 그대로 사용
  encryption {
    key_provider "pbkdf2" "my_passphrase" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "my_method" {
      keys = key_provider.pbkdf2.my_passphrase
    }

    state {
      method = method.aes_gcm.my_method
    }
  }
}

마이그레이션은 얼마나 쉬운가?

기존 Terraform 사용자라면 대부분의 경우 이렇게만 하면 됩니다.

# macOS (Homebrew)
brew install opentofu

# 기존 Terraform 명령어를 tofu로 교체
terraform init    →  tofu init
terraform plan    →  tofu plan
terraform apply   →  tofu apply
terraform destroy →  tofu destroy

# .tf 파일은 수정 없이 그대로 사용 가능 (대부분의 경우)

.tf 파일 내부의 코드는 거의 수정할 필요가 없습니다. HCL 문법 자체가 동일하기 때문입니다.

---

⚠️ 주의사항 — OpenTofu 도입 시 체크리스트

1. Provider 호환성 확인 대부분의 Provider는 호환되지만, 일부 엔터프라이즈 전용 Provider는 HashiCorp Terraform에만 최적화되어 있을 수 있습니다. 도입 전 반드시 확인하세요.

2. Terraform Cloud/Enterprise 사용 중이라면 HashiCorp의 관리형 서비스(Terraform Cloud, Terraform Enterprise)와의 연동은 당연히 Terraform 전용입니다. OpenTofu로 전환 시 Spacelift, Env0, Scalr, Atlantis 같은 대안을 고려해야 합니다.

3. State 파일 관리 기존 Terraform State 파일은 OpenTofu에서 그대로 읽을 수 있습니다. 하지만 OpenTofu의 State 암호화 기능을 활성화하면 다시 Terraform으로 돌아가기 어려울 수 있습니다.

4. 팀 내 버전 통일 Terraform과 OpenTofu를 팀 내에서 혼용하면 혼란이 생깁니다. 전환 시 팀 전체가 동시에 전환하는 것을 권장합니다.

---

🔭 OpenTofu의 미래 — 낙관적일 수 있는 이유

HashiCorp의 IBM 인수 (2024년)

2024년, IBM이 HashiCorp를 약 64억 달러에 인수했습니다. 이 소식은 OpenTofu 커뮤니티에 오히려 호재로 작용했습니다. 대기업의 인수 후 오픈소스 정책이 더 제한적으로 바뀌는 사례를 수없이 봐왔기 때문입니다. OpenTofu로의 전환을 고민하던 기업들이 결단을 내리는 계기가 됐죠.

빠른 성장세

• GitHub Star 수: 수만 개 돌파 (빠른 속도로 증가 중)
• 기여자 수: 수백 명의 글로벌 개발자
• 기업 후원: 수십 개의 주요 기술 기업
• CNCF Incubating 단계로 격상

커뮤니티 드리븐의 강점

OpenTofu는 Terraform이 해결하지 않았던 기능들을 빠르게 추가하고 있습니다. 커뮤니티에서 수년간 요청했지만 HashiCorp가 우선순위를 두지 않았던 기능들이죠. State 암호화가 그 대표적인 예입니다.

그래도 Terraform을 써야 하는 경우

OpenTofu가 훌륭하지만, 아직 Terraform을 선택해야 하는 상황도 있습니다.

• HashiCorp의 공식 엔터프라이즈 지원이 필요한 경우
• Terraform Cloud와 깊게 연동된 워크플로우를 사용 중인 경우
• 조직의 규정상 CNCF 프로젝트 외 특정 벤더 공식 지원 필요 시

---

✅ 정리 — 오픈소스의 자유는 포크로 지킨다

시점	사건
2014년	HashiCorp, Terraform MPL 2.0으로 오픈소스 출시
2021년	HashiCorp 나스닥 상장
2023년 8월	Terraform BSL 1.1로 라이선스 변경 발표
2023년 8월	OpenTF Manifesto 발표, 수천 명 서명
2023년 9월	OpenTofu 공식 출범, CNCF Sandbox 합류
2024년	IBM, HashiCorp 인수 완료
2024~2025년	OpenTofu, CNCF Incubating 격상 및 독자 기능 추가

 

Terraform은 분명 위대한 도구였고, 지금도 그렇습니다. 하지만 오픈소스의 힘은 특정 기업이 아니라 커뮤니티에 있다는 것을 OpenTofu는 다시 한번 증명했습니다.

 

다음 단계로 추천하는 학습 방향:

• OpenTofu 공식 문서: opentofu.org
• CNCF 프로젝트 생태계 이해
• Terragrunt, Atlantis 등 OpenTofu 기반 워크플로우 도구
• State 암호화 실습

IaC를 처음 시작하는 분이라면, 지금은 OpenTofu로 시작하는 것을 권장합니다. 📦