2026년 IaC 파노라마

2023년 HashiCorp는 Terraform의 라이선스를 MPL 2.0(오픈소스)에서 세계에서 가장 뜨거운 논쟁을 불러일으키는 비즈니스 소스 라이선스(BSL 1.1) DevOps. BSL은 OSI 정의에 따라 오픈 소스가 아닙니다. 상업적 사용은 금지됩니다. HashiCorp의 직접적인 경쟁자에 의해. 커뮤니티의 반응은 이랬습니다. 즉시: 오픈 소스 포크 오픈두부, Linux Foundation에 기부했습니다.

2026년에 시장은 세 가지 명확한 위치로 자리 잡았습니다. Terraform이 시장점유율 32.8% 거대한 설치 기반 덕분에 IaC 도구 중 하나 공급자와 모듈의 생태계; OpenTofu가 정복했습니다. ~8% 주로 인증된 오픈 소스 라이센스가 필요한 환경에서; 풀루미 그리고 자랐다 ~15% 개발자 경험과 기본 테스트에 중점을 둡니다. CloudFormation, CDK, Bicep 및 Ansible이 파노라마를 완성합니다.

무엇을 배울 것인가

  • HashiCorp BSL 라이센스 변경의 역사와 의미
  • OpenTofu: Terraform 호환성, 현재 상태 및 로드맵
  • Pulumi: "실제 코드로서의 인프라" 패러다임, 장단점
  • 기술 비교표: 기능, 라이선스, 생태계, 테스트
  • 결정 매트릭스: 각 도구를 선택하는 시기
  • Terraform에서 OpenTofu로 마이그레이션: 단계별 절차

HashiCorp 라이선스 변경: 의미

HashiCorp가 2023년에 채택한 Business Source License(BSL 1.1)에는 다음과 같은 조항이 있습니다. 핵심: 귀하는 경쟁 제품을 제공하기 위해 소프트웨어를 사용할 수 없습니다. HashiCorp와 함께 실제로 이는 다음을 의미합니다. 

# Cosa e CONSENTITO con la BSL HashiCorp:
# - Uso interno in azienda per gestire infrastruttura propria
# - Contribuire al codebase Terraform
# - Creare moduli e provider Terraform
# - Usare Terraform in CI/CD per i tuoi progetti
# - Formazione e certificazioni

# Cosa NON e CONSENTITO senza licenza commerciale:
# - Offrire Terraform as a Service (competitor di Terraform Cloud/Enterprise)
# - Costruire un prodotto SaaS che "wrappa" Terraform come core feature
#   e compete con HCP Terraform
# - Le piattaforme come Spacelift, Env0, Scalr devono gestire questa zona grigia

# Data conversione a Apache 2.0: non annunciata (BSL diventa Apache 2.0 dopo 4 anni
# dalla release di ogni versione, quindi Terraform 1.5 -> Apache 2.0 nel 2027)

# Chi ha BIFORCATO:
# - OpenTofu (Linux Foundation, ex OpenTF) — replica di Terraform pre-BSL
# - OpenTofu segue Terraform con ~2-4 version lag
# - Attuale: OpenTofu 1.8.x vs Terraform 1.9.x

OpenTofu: 오픈 소스 포크

오픈두부 (이전 OpenTF) 및 유지된 Terraform 포크 Linux Foundation에서 Gruntwork, Spacelift, Env0, Scalr 및 수십 명의 기여를 받았습니다. 다른 사람들의. 명시된 목표: Terraform이 추가됨에 따라 호환성을 유지하는 것 비즈니스 모델을 보호하기 위해 HCP가 구현하지 않을 수 있는 기능.

호환성 및 차이점

# OpenTofu e un drop-in replacement per Terraform
# I file .tf sono identici: nessuna modifica richiesta per la maggior parte dei casi

# Installazione OpenTofu
# Via brew (macOS/Linux):
brew install opentofu

# Via script ufficiale:
curl --proto '=https' --tlsv1.2 -fsSL https://get.opentofu.org/install-opentofu.sh | \
  sh -s -- --install-method standalone

# Verifica versione
tofu version
# OpenTofu v1.8.3
# on linux_amd64

# Comandi identici a Terraform (solo "tofu" invece di "terraform"):
tofu init
tofu plan
tofu apply
tofu destroy

# Stessa sintassi HCL, stessi provider, stesso state file format

OpenTofu의 고유한 기능(Terraform에는 없음)

# 1. Encrypted State (OpenTofu 1.7+)
# Terraform richiede un backend esterno per la cifratura dello state
# OpenTofu supporta encryption nativa nel backend

terraform {
  encryption {
    key_provider "pbkdf2" "my_key" {
      passphrase = var.state_encryption_key
    }

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

    state {
      method = method.aes_gcm.my_method
    }

    plan {
      method = method.aes_gcm.my_method
    }
  }
}

# 2. Provider Functions (OpenTofu 1.7+, porting in Terraform 1.8)
# Funzioni custom definite nei provider (entrambi supportano ora)

# 3. Variable validation con references ad altre variabili
variable "max_instances" {
  type = number
}

variable "min_instances" {
  type = number
  validation {
    # OpenTofu: puoi referenziare altre variabili nella validation
    condition     = var.min_instances <= var.max_instances
    error_message = "min_instances deve essere <= max_instances."
  }
}

Terraform에서 OpenTofu로 마이그레이션

# Migrazione in 5 passi (praticamente indolore)

# 1. Backup dello state attuale
terraform state pull > backup_$(date +%Y%m%d).tfstate

# 2. Installa OpenTofu
brew install opentofu

# 3. Testa in un ambiente non-prod
cd environments/dev
tofu init   # Legge lo stesso .terraform.lock.hcl (OpenTofu e compatibile)
tofu plan   # Verifica che il plan sia identico a terraform plan

# 4. Se tutto ok, migra il .terraform.lock.hcl
# OpenTofu usa un formato leggermente diverso per il lock file
tofu providers lock \
  -platform=linux_amd64 \
  -platform=darwin_amd64 \
  -platform=darwin_arm64

# 5. Aggiorna le pipeline CI/CD
# Sostituisci "terraform" con "tofu" negli script
# Aggiorna le action GitHub se usi hashicorp/setup-terraform:
# usa opentofu/setup-opentofu invece

# Nel CI/CD (GitHub Actions):
# - name: Setup OpenTofu
#   uses: opentofu/setup-opentofu@v1
#   with:
#     tofu_version: "1.8.x"

Pulumi: 실제 코드로서의 인프라

Pulumi는 선언적 DSL(HCL) 대신 근본적으로 다른 접근 방식을 취합니다. 사용하다 실제 프로그래밍 언어 — TypeScript, Python, Go, C#, Java. 이는 심오한 의미를 갖습니다. 루프, 조건부, 함수, npm/pip 모듈에 액세스할 수 있습니다. Jest/pytest 및 전체 언어 툴체인을 사용한 기본 테스트.

TypeScript의 풀루미

// Pulumi - infrastruttura come TypeScript
import * as aws from "@pulumi/aws";
import * as pulumi from "@pulumi/pulumi";

const config = new pulumi.Config();
const environment = config.require("environment");
const instanceCount = config.requireNumber("instanceCount");

// VPC con subnet - stessa logica di Terraform ma con TypeScript
const vpc = new aws.ec2.Vpc("main", {
  cidrBlock: "10.0.0.0/16",
  enableDnsHostnames: true,
  enableDnsSupport: true,
  tags: {
    Name: `${environment}-vpc`,
    Environment: environment,
    ManagedBy: "Pulumi",
  },
});

// Crea subnet dinamicamente con un loop TypeScript nativo
// In Terraform useresti count o for_each
const publicSubnets = Array.from({ length: instanceCount }, (_, i) =>
  new aws.ec2.Subnet(`public-${i}`, {
    vpcId: vpc.id,
    cidrBlock: `10.0.${i}.0/24`,
    mapPublicIpOnLaunch: true,
    tags: { Name: `${environment}-public-${i + 1}` },
  })
);

// Output esportati
export const vpcId = vpc.id;
export const subnetIds = publicSubnets.map(s => s.id);

Pulumi를 사용한 기본 테스트

Terraform에 비해 Pulumi의 가장 구체적인 장점은 테스트입니다. Terratest 또는 외부 프레임워크 없이 표준 Jest/pytest/Go 테스트를 사용하여 테스트합니다. 

// test/infra.test.ts — Unit test Pulumi con Jest
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// Mock del provider AWS per i test (non fa chiamate reali)
pulumi.runtime.setMocks({
  newResource: (args) => {
    return {
      id: `${args.name}-id`,
      state: { ...args.inputs, id: `${args.name}-id` },
    };
  },
  call: (args) => ({ outputs: {} }),
});

describe("VPC Infrastructure", () => {
  let infra: typeof import("../index");

  beforeAll(async () => {
    infra = await import("../index");
  });

  test("VPC deve avere DNS abilitato", async () => {
    const vpc = await infra.vpc;
    const props = await vpc.enableDnsHostnames.apply(v => v);
    expect(props).toBe(true);
  });

  test("Numero subnet deve corrispondere alla configurazione", async () => {
    const subnets = await pulumi.all(infra.subnetIds).apply(ids => ids.length);
    const expectedCount = Number(process.env.INSTANCE_COUNT || 2);
    expect(subnets).toBe(expectedCount);
  });

  test("Subnet devono appartenere alla VPC", async () => {
    const vpcId = await infra.vpcId;
    // Verifica che ogni subnet abbia il VPC ID corretto
    expect(vpcId).toBeDefined();
    expect(vpcId).toMatch(/^vpc-/);
  });
});

비교표: Terraform vs OpenTofu vs Pulumi

기능별 비교(2026)

특징 테라폼 오픈두부 풀루미
특허 BSL 1.1 MPL 2.0 아파치 2.0
언어 HCL HCL TS/파이썬/Go/C#
AWS 공급자 1200개 이상의 리소스 TF와 동일 ~900개 리소스
네이티브 테스트 테라폼 테스트(1.6+) 두부 테스트 농담/pytest/Go
상태 암호화 백엔드 전용 네이티브(1.7+) 풀루미 클라우드
학습 곡선 낮은 낮은 평균
커뮤니티 및 문서 훌륭한 좋은 좋은

결정 매트릭스: 언제 무엇을 선택할 것인가

# Scegli TERRAFORM se:
# - Hai gia un team con esperienza HCL e non vuoi riformare
# - Lavori in un contesto enterprise con vendor support HashiCorp
# - Hai bisogno del massimo ecosistema di provider e moduli
# - Non hai requisiti di licenza open-source certificata
# - Usi Terraform Cloud o HCP per il backend di stato

# Scegli OPENTOFU se:
# - La licenza BSL e un problema (healthcare, govtech, open-source aziende)
# - Vuoi drop-in replacement con garanzia open-source a lungo termine
# - Usi gia Terraform e vuoi minimizzare il costo di migrazione
# - Hai bisogno di state encryption nativa (feature non in Terraform)
# - Il tuo company legal ha approvato MPL 2.0 ma non BSL

# Scegli PULUMI se:
# - Il tuo team e composto da developer (non solo DevOps) abituati a TypeScript/Python
# - Hai logica di configurazione complessa: loop, condizionali, validazioni rich
# - Vuoi testing nativo con framework di test standard senza Terratest
# - Stai costruendo un Internal Developer Platform e vuoi API programmatiche
# - Hai bisogno di astrazioni di alto livello (Pulumi Component Resources)

상호 운용성: Pulumi에서 Terraform 공급자 사용

// Pulumi supporta tutti i provider Terraform via bridge
// Utile per provider non ancora disponibili nativamente in Pulumi

import * as pulumitf from "@pulumi/terraform";

// Usa qualsiasi provider Terraform (anche non ufficiale)
const provider = new pulumitf.Provider("custom-provider", {
  version: "1.2.3",
  // Equivalente di required_providers in Terraform
});

// Questa interoperabilita permette una migrazione graduale
// da Terraform a Pulumi senza dover aspettare che tutti i provider
// siano portati nativamente

결론

이 경쟁에서 절대적인 승자는 없습니다. 각 도구는 상황에 따라 탁월합니다. 다르다. Terraform은 가장 풍부한 생태계를 갖춘 시장 선두주자로 남아 있습니다. 오픈두부e 오픈 소스 라이선스와 Terraform 호환성을 원하는 사람들을 위한 합리적인 선택입니다. 인프라 통합을 원하는 개발자 중심 팀을 위한 Pulumi와 미래 단일 코드 패러다임으로 적용합니다.

전체 시리즈: Terraform 및 IaC

  • 제01조 — 처음부터 Terraform
  • 제02조 — 재사용 가능한 Terraform 모듈
  • 제03조 — Terraform 상태 및 원격 백엔드
  • 제04조 — CI/CD의 Terraform
  • 제05조 — IaC 테스트
  • 제06조 — IaC 보안
  • 제07조 — Terraform 다중 클라우드
  • 제08조 — Terraform용 GitOps
  • 제09조(본) — Terraform vs Pulumi vs OpenTofu: 비교 2026
  • 제10조 — Terraform 엔터프라이즈 패턴