90DaysOfDevOps (Day 40)

고태규·2025년 11월 17일

devops

DevOps

목록 보기

39/50

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 40 - Infrastructure as Code - A look at Azure Bicep and Terraform

1. Infrastructure as Code (IaC)

IaC의 공식적인 정의는 기계가 읽을 수 있는 정의 파일(machine-readable defined files)을 통해 컴퓨터 데이터 센터를 관리하고 프로비저닝하는 프로세스이다.

간단히 말해, 인프라 구성을 수동으로 클릭하는 대신 코드로 정의하는 것이다.

이는 우리가 겪는 많은 문제를 해결한다. 더 이상 복잡한 문서를 뒤지거나 명명 규칙을 고민할 필요 없이, 코드가 모든 작업을 일관되게 처리해 준다.

IaC의 또 다른 핵심 이점은 '위임'이다. 전통적으로 개발팀은 인프라팀이 서버나 데이터베이스를 배포해 줄 때까지 기다려야 했다.

하지만 IaC를 사용하면, 잘 정의된 템플릿 파일이나 배포 시스템 접근 권한을 개발팀에 제공할 수 있다. 개발자들은 인프라팀의 개입 없이도 필요한 리소스를 일관되고 반복 가능한 방식으로 직접 배포할 수 있게 되어, 기다리는 시간이 사라진다.

Terraform, Ansible, AWS CloudFormation, Pulumi, Puppet, Azure Bicep 등 다양한 IaC 도구가 존재하며, 해당 세션에서는 그중에서도 최근 주목받는 Azure Bicep과 Terraform에 대해 집중적으로 다루고자 한다.

2. Azure Bicep: Microsoft IaC 솔루션

Azure Bicep은 Microsoft가 직접 만든 오픈소스 IaC 언어이다.

이는 Azure Resource Manager (ARM) 템플릿의 새로운 버전으로, 기존 ARM 템플릿의 복잡성을 개선하기 위해 개발되었다.

Bicep은 DSL(도메인 특화 언어)이며, 선언적 구문(declarative syntax)을 사용하여 Azure 리소스를 배포한다.

Microsoft가 직접 만든 First-Party 도구이므로 Azure Policy, 가상 머신, 앱 서비스 플랜 등 모든 Azure 리소스와 완벽하게 통합된다.

Bicep의 가장 큰 장점은 'Day-1 Support'이다.

Microsoft는 새로운 Azure 제품이나 기능 출시를 미리 알고 있으므로, Bicep이 해당 기능을 출시 첫날부터 (혹은 매우 빠르게) 지원하도록 준비할 수 있다.

이는 서드파티 도구와의 명확한 차별점으로, 다른 도구들은 신규 기능이 출시된 후에야 해당 기능을 지원하기 위한 개발을 시작할 수 있다.

이 때문에 많은 고객이 Terraform을 메인 도구로 사용하면서도, Terraform이 아직 지원하지 않는 최신 Azure 기능을 배포하기 위해 Bicep을 함께 사용하는 전략을 취하기도 한다.

# Azure Bicep을 사용하여 스토리지 계정을 생성하는 예시 코드
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'toylaunchstorage'
  location: 'westus3'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

resource storageAccount: 'storageAccount' 라는 심볼릭 이름으로 리소스를 선언
'Microsoft.Storage/storageAccounts@2022-09-01': 배포할 리소스의 타입과 사용할 API 버전을 정의
name, location, sku, kind, properties: 스토리지 계정의 이름, 배포 위치, SKU(Standard_LRS), 종류(StorageV2), 속성(Hot) 등 필요한 최소한의 정보를 정의

3. Terraform: Multi-Cloud 지원 IaC

Terraform은 HashiCorp에서 개발한 오픈소스 IaC 도구이다. Terraform 역시 선언적 언어를 사용하여 인프라를 코드로 정의하고 관리한다.

Terraform의 가장 강력한 차별점은 여러 플랫폼과 프로바이더를 지원한다는 것이다.

Terraform 코드를 작성하여 AWS, Azure, Google Cloud (GCP) 리소스는 물론, VMware 같은 온프레미스 인프라까지 배포할 수 있다.

이는 조직이 여러 클라우드를 동시에 사용하거나 온프레미스에서 클라우드로 마이그레이션하는 과정에서 매우 유용하다.

팀이 Terraform이라는 하나의 도구와 기술 스택을 학습하면, 여러 환경에 걸쳐 일관된 방식으로 인프라를 관리할 수 있다. (물론, 각 프로바이더마다 사용되는 코드 구문과 리소스 정의는 다르다.)

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_storage_account" "toystorageaccount" {
  name                     = "toylaunchstorage"
  resource_group_name      = "automation-inventory"
  location                 = "westus3"
  account_tier             = "Standard"
  account_replication_type = "LRS"
  access_tier              = "Hot"
}

terraform { ... } : Terraform 설정을 정의
required_providers { ... } : 이 코드가 'azurerm' (Azure) 프로바이더를 필요로 함을 선언 (프로바이더는 API와 상호작용하는 플러그인)
provider "azurerm" { ... } : Azure 프로바이더의 세부 설정을 정의
resource "azurerm_storage_account" "toystorageaccount" { ... } : 실제 리소스를 정의 ('azurerm_storage_account'라는 리소스 타입을 'toystorageaccount'라는 이름으로 선언)
name, resource_group_name, location, account_tier, account_replication_type, access_tier : 리소스에 필요한 속성값 (이름, 리소스 그룹, 위치, 등급, 복제 타입 등)을 할당
(Bicep 예시와 달리 resource_group_name이 포함)

4. IaC 모범사례

어떤 IaC 언어를 사용하든, 성공적인 인프라 관리를 위해 따라야 할 몇 가지 모범 사례가 존재한다.

버전 관리 (Version Control):
- 모든 IaC 코드는 Git (GitHub, Azure DevOps 등)을 통해 버전 관리되어야 한다.
- 이는 변경 이력을 추적하고, 팀원 간 협업 및 동료 검토를 가능하게 한다.
정적 분석 (Static Analysis):
- IaC도 코드이므로 잘못된 구성이 가능하다.
- 정적 분석 스캐닝 도구를 사용하여 코드를 배포하기 전에 비즈니스 요구사항이나 보안 정책에 맞지 않는 구성을 미리 탐지해야 한다.
비밀 관리 (Secrets Management):
- 코드에 절대 사용자 이름, 암호, API 키 등 민감한 정보를 하드코딩해서는 안 된다.
- Azure Key Vault, HashiCorp Vault 같은 전문 시크릿 매니저를 사용하여 민감한 정보를 안전하게 저장하고 코드에서 참조해야 한다.
문서화 (Documentation):
- 코드 자체의 가독성도 중요하지만, 주석이나 별도의 문서를 통해 지식을 공유하고 투명성을 확보해야 한다.
- 이는 팀의 주니어 멤버나 몇 달 뒤 코드를 다시 보게 될 미래의 자신에게 큰 도움이 된다.
CI/CD 파이프라인:
- IaC 배포 과정을 자동화해야 한다.
- Azure DevOps나 GitHub Actions 같은 CI/CD 도구를 사용하여 코드 변경 시 자동으로 테스트하고 배포하는 파이프라인을 구축하는 것이 좋다.

5. Bicep vs Terraform 비교

두 도구는 경쟁 관계라기보다 상황에 따라 함께 사용될 수 있지만, 명확한 차이점이 존재한다.

프로그래밍 패러다임: 둘 다 선언적(Declarative)이다. (원하는 '상태'를 정의)
지원 범위:
- Bicep: Azure Only. 오직 Azure 리소스 배포만 지원
- Terraform: Multi-Cloud & On-prem. Azure, AWS, GCP 및 온프레미스 등 다양한 환경을 지원
커뮤니티: 둘 다 크고 활발하지만, 역사가 더 긴 Terraform의 커뮤니티가 더 크다고 간주된다.
상태 관리 :
- Terraform:
  - State 파일을 사용한다.
  - Terraform은 배포된 리소스의 상태를 별도의 tfstate 파일에 저장하여 단일 진실 공급원으로 삼는다.
  - 팀 협업을 위해서는 tfstate 상태 파일을 Azure Blob Storage나 Amazon S3 같은 공유 백엔드에 저장하고 관리해야 한다.
- Bicep:
  - State 파일을 사용하지 않는다.
  - Bicep은 Azure 자체를 단일 진실 공급원으로 삼고, 배포 시 Azure에서 직접 현재 상태를 읽어온다.
  - 즉, 별도의 상태 파일을 관리할 필요가 없다.

결론적으로, 조직이 오직 Azure만 사용하고 최신 기능을 즉시 도입해야 한다면 Bicep이 훌륭한 선택이다.

반면, 여러 클라우드를 동시에 관리하거나 온프레미스 환경까지 아우르는 일관된 도구가 필요하다면 Terraform이 더 적합할 것이다.

고태규

이전 포스트

90DaysOfDevOps (Day 39)

다음 포스트