Bicep vs ARM 템플릿 vs Terraform: Azure IaC 도구 선택

인프라를 코드로 관리하기로 했는데 도구가 셋입니다. Bicep, ARM 템플릿, Terraform을 문법·상태 관리·멀티 클라우드·학습 곡선 기준으로 비교하고, 우리 팀엔 무엇이 맞는지 정리했습니다.

세 도구 모두 “원하는 최종 상태를 선언하면 알아서 맞춰준다”는 선언형 IaC라는 점은 같습니다. 갈림길은 Azure만 쓰는지, 다른 클라우드도 함께 다루는지, 그리고 팀이 이미 어떤 도구에 익숙한지입니다.

세 도구 한눈에 비교

핵심 차이 두 가지입니다. 첫째, Bicep·ARM은 Azure가 상태를 직접 관리해 상태 파일이 없고, Terraform은 상태 파일을 팀이 관리해야 합니다. 둘째, Terraform만 멀티 클라우드를 하나의 문법으로 다룹니다.

같은 리소스, 다른 코드

스토리지 계정 하나를 만드는 코드로 문법 차이를 비교해 봅니다.

// Bicep — 간결
resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mydata${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

# Terraform — HCL
resource "azurerm_storage_account" "sa" {
  name                     = "mydata12345"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

ARM JSON은 같은 리소스를 표현하는 데 훨씬 많은 줄이 필요합니다. 그래서 Azure 전용이라면 Bicep이 사실상 ARM의 상위 호환입니다.

각 도구가 맞는 팀

ARM 템플릿 — 이미 방대한 ARM 자산이 있고 당장 바꿀 이유가 없을 때 유지합니다. 다만 신규 작성은 대부분 Bicep으로 옮겨가는 추세입니다.

Bicep — Azure만 쓰고, 학습 부담을 줄이며, 새 Azure 기능을 가장 빨리 코드로 쓰고 싶은 팀에 적합합니다. Azure CLI·포털과 통합이 매끄럽고 상태 파일 관리 부담이 없습니다.

Terraform — AWS·GCP 등 여러 클라우드를 한 워크플로로 다루거나, 이미 조직 표준이 Terraform인 경우 자연스러운 선택입니다. 모듈 생태계가 넓어 재사용이 강력합니다.

선택 기준 체크리스트

1. Azure만 쓰나? → 그렇다면 Bicep이 기본. 여러 클라우드면 Terraform.
2. 기존 ARM 자산이 많은가? → 점진적으로 Bicep으로 디컴파일해 이전 가능.
3. 상태 파일을 관리할 여력이 있나? → 부담되면 상태가 없는 Bicep.
4. 조직 표준 IaC가 이미 있나? → 있으면 그 표준을 따르는 편이 협업에 유리.
5. 최신 Azure 기능을 즉시 써야 하나? → Bicep이 반영이 가장 빠릅니다.

배포 명령 비교

# Bicep
az deployment group create \
  --resource-group rg-demo --template-file main.bicep

# ARM
az deployment group create \
  --resource-group rg-demo --template-file azuredeploy.json

# Terraform
terraform init
terraform plan -out tfplan
terraform apply tfplan

Terraform은 plan으로 변경 사항을 미리 보고 적용하는 흐름이 명확합니다. Bicep도 what-if 옵션으로 유사한 미리 보기를 제공합니다.

흔한 실수

• Terraform 상태 파일을 로컬에만 둔다 — 팀 협업 시 상태가 어긋나 리소스가 중복 생성됩니다. Azure Storage 같은 원격 백엔드 + 잠금을 반드시 씁니다.
• 상태 파일을 Git에 커밋한다 — 상태에는 민감 정보가 담길 수 있습니다. 절대 버전 관리에 넣지 마세요.
• ARM을 새로 손으로 작성한다 — 장황해 오류가 잦습니다. 신규는 Bicep으로 쓰고 필요 시 ARM으로 빌드됩니다.
• 도구를 섞어 같은 리소스를 관리한다 — Bicep과 Terraform이 같은 리소스를 각자 관리하면 서로 덮어써 충돌합니다. 리소스별로 소유 도구를 하나로 정하세요.
• 포털에서 수동 변경 후 방치한다 — 코드와 실제가 어긋나는 드리프트가 쌓입니다. 변경은 항상 코드로 하고, 드리프트는 주기적으로 점검합니다.

전환은 어렵지 않다

ARM에서 Bicep으로는 az bicep decompile로 기존 JSON을 Bicep으로 변환해 점진적으로 옮길 수 있습니다. Terraform으로 옮길 때는 terraform import로 기존 리소스를 상태에 편입해 코드화합니다. 어느 쪽이든 한 번에 전면 교체보다 리소스 그룹 단위로 나눠 이전하는 편이 안전합니다.

자주 묻는 질문

• Q. Bicep과 ARM 템플릿은 무엇이 다른가요?
  Bicep은 ARM을 더 읽기 쉬운 문법으로 감싼 언어입니다. 배포 시 ARM JSON으로 변환돼 실행되므로 기능은 동등하지만 코드가 훨씬 간결하고 모듈·타입 지원이 좋아 새 Azure 프로젝트에서는 Bicep이 권장됩니다.
• Q. Terraform은 왜 상태 파일을 쓰나요?
  실제 리소스와 코드의 매핑을 상태 파일에 기록해 변경 계획을 계산하기 때문입니다. 손상·동시 수정 위험이 있어 원격 백엔드에 저장하고 잠금을 걸어 공유합니다.
• Q. 멀티 클라우드라면 무엇을 써야 하나요?
  Azure 외에 AWS·GCP까지 한 도구로 관리하려면 Terraform이 적합합니다. Bicep·ARM은 Azure 전용이므로 여러 클라우드를 같은 워크플로로 다루는 조직엔 Terraform의 이점이 큽니다.
• Q. 새로 시작하는 Azure 팀이라면?
  상태 파일 부담이 없고 학습이 쉬우며 최신 기능 반영이 빠른 Bicep으로 출발하길 권합니다. 이후 멀티 클라우드 요건이 생기면 Terraform을 검토하면 됩니다.

정리하면, Azure만 다루면 Bicep이 사실상 표준, 여러 클라우드를 아우르면 Terraform이 강점입니다. ARM은 이제 대개 Bicep의 빌드 결과물로 남습니다. “우리가 다루는 클라우드 범위”가 첫 질문이면 답은 대부분 자연스럽게 정해집니다.