🥊 AWS Image Builder vs Packer — 실무 DevOps 엔지니어라면 뭘 써야 할까?

"둘 다 AMI 만든다는 건 아는데, 실무에서 어느 걸 골라야 하죠?"
이 글이 그 질문에 답합니다.

 

---

🎯 이 글에서 다루는 것

• AWS Image Builder와 Packer의 핵심 개념 및 작동 방식 비교
• 사용 난이도와 학습 곡선 — 어느 쪽이 더 빨리 손에 익는가
• 실무 시나리오별 선택 기준 (CI/CD 파이프라인 통합, 멀티 클라우드, 컴플라이언스 환경)
• 보안·컴플라이언스 관점 차이
• 빌드 비용과 속도 비교
• 결론: 어떤 팀에 무엇이 맞는가

---

📌 도입 / 배경

AMI(Amazon Machine Image)는 EC2 인스턴스의 골든 이미지입니다. 어떤 설정이 들어간 인스턴스를 찍어두고, 이후 배포할 때마다 이 이미지를 기반으로 인스턴스를 찍어냅니다. Auto Scaling, Blue/Green 배포, 불변 인프라(Immutable Infrastructure) 전략 모두 골든 AMI 빌드 자동화가 전제입니다.

 

문제는 이 골든 이미지를 어떻게 만드느냐입니다.

AWS가 2019년 Image Builder를 출시하기 전까지, 대부분의 DevOps 팀은 HashiCorp의 Packer를 사용했습니다. 이제는 두 도구가 공존하고, 신규 프로젝트를 시작하는 팀마다 선택의 기로에 섭니다.

 

이 글은 두 도구를 단순히 나열하는 게 아니라, 실무 CI/CD 경험이 있는 엔지니어가 어느 쪽을 선택해야 하는지 명확한 기준을 제시하는 것을 목표로 합니다.

---

🔍 두 도구 개념 먼저 잡기

AWS Image Builder

AWS가 직접 만든 관리형 서비스입니다. 콘솔, CloudFormation, Terraform 등으로 파이프라인을 선언하면, AWS가 임시 EC2 인스턴스를 띄우고 → 컴포넌트(설치 스크립트)를 실행하고 → AMI를 생성하고 → 인스턴스를 종료하는 전 과정을 알아서 처리합니다.

 

핵심 구성 요소:

구성 요소	역할
Recipe	베이스 이미지 + 컴포넌트 조합 정의
Component	설치·설정 스크립트 단위 (YAML)
Pipeline	빌드 스케줄 및 배포 대상 설정
Distribution	완성된 AMI를 어느 리전/계정에 배포할지

Packer

HashiCorp가 만든 오픈소스 CLI 도구입니다. JSON 또는 HCL2 파일로 빌드 구성을 정의하고, packer build 명령 하나로 실행합니다. AWS뿐 아니라 Azure, GCP, VMware, Docker 이미지까지 동일한 방식으로 만들 수 있습니다.

 

핵심 구성 요소:

구성 요소	역할
Builder	어떤 플랫폼에 이미지를 만들지 정의 (amazon-ebs 등)
Provisioner	Shell, Ansible, Chef 등으로 내부 설정 수행
Post-processor	빌드 후 처리 (Manifest 파일 생성, 태깅 등)
Variable	빌드 파라미터화 (리전, AMI 이름, 버전 등)

---

🔍 사용 난이도 / 학습 곡선

AWS Image Builder

초기 진입은 콘솔 기반이라 쉽게 느껴집니다. 하지만 이 편의함이 오래가지 않습니다.

컴포넌트 YAML 문법이 독자적이고, 빌드 실패 시 로그를 찾아 S3나 CloudWatch Logs로 들어가야 합니다. 로컬에서 미리 테스트할 방법이 없고, 컴포넌트 하나 수정해도 전체 파이프라인을 재실행해야 결과를 확인할 수 있습니다. 이는 반복 개발 주기(iteration)가 느리다는 의미입니다.

학습 난이도: 처음 3일은 쉽고, 이후 디버깅과 세밀한 제어에서 막힙니다.

 

Packer

CLI 기반이라 진입 장벽이 있지만, Terraform을 써본 DevOps 엔지니어라면 HCL2 문법이 익숙하게 느껴집니다. packer validate로 구문 검증, packer build -debug로 인터랙티브 디버깅이 가능합니다. 로컬에서 Docker builder로 프로비저너 스크립트를 먼저 검증한 뒤 AWS 빌드에 적용하는 패턴도 널리 쓰입니다.

# packer build 기본 구조 (HCL2)
packer {
  required_plugins {
    amazon = {
      version = ">= 1.2.0"
      source  = "github.com/hashicorp/amazon"
    }
  }
}

variable "aws_region" {
  type    = string
  default = "ap-northeast-2"
}

variable "app_version" {
  type = string
}

source "amazon-ebs" "golden_ami" {
  region        = var.aws_region
  instance_type = "t3.micro"
  
  # 베이스 이미지: 최신 Amazon Linux 2023 자동 탐색
  source_ami_filter {
    filters = {
      name                = "al2023-ami-*-x86_64"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    owners      = ["amazon"]
    most_recent = true
  }
  
  ssh_username = "ec2-user"
  
  ami_name        = "my-app-golden-${var.app_version}-{{timestamp}}"
  ami_description = "Golden AMI for my-app v${var.app_version}"
  
  tags = {
    Name        = "my-app-golden"
    Version     = var.app_version
    BuildDate   = "{{timestamp}}"
    ManagedBy   = "Packer"
  }
}

build {
  sources = ["source.amazon-ebs.golden_ami"]
  
  # 1단계: 시스템 업데이트
  provisioner "shell" {
    inline = [
      "sudo dnf update -y",
      "sudo dnf install -y amazon-cloudwatch-agent"
    ]
  }
  
  # 2단계: Ansible로 앱 설정
  provisioner "ansible" {
    playbook_file = "./ansible/app-setup.yml"
    extra_arguments = [
      "--extra-vars", "app_version=${var.app_version}"
    ]
  }
  
  # 3단계: 빌드 결과 매니페스트 저장 (다음 배포 단계에서 AMI ID 참조용)
  post-processor "manifest" {
    output     = "manifest.json"
    strip_path = true
  }
}

 

학습 난이도: 첫 설정에 1~2일, 이후 Ansible·Shell 조합만 익히면 빠르게 확장됩니다.

---

🔍 실무 CI/CD 파이프라인 통합

이것이 가장 중요한 비교 지점입니다.

Packer + GitHub Actions

Packer는 CLI 도구이므로 파이프라인에서 단순히 명령 하나를 실행하면 됩니다. AMI ID는 manifest.json에 기록되어 후속 Terraform 배포 단계로 바로 넘길 수 있습니다.

# .github/workflows/build-ami.yml
name: Build Golden AMI

on:
  push:
    branches: [main]
    paths:
      - 'packer/**'
      - 'ansible/**'

jobs:
  build-ami:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # OIDC 기반 AWS 인증
      contents: read
    
    steps:
      - uses: actions/checkout@v4
      
      # OIDC로 AWS 인증 (장기 자격증명 불필요)
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsPackerRole
          aws-region: ap-northeast-2
      
      # Packer 설치
      - name: Setup Packer
        uses: hashicorp/setup-packer@main
        with:
          version: "1.10.0"
      
      # 플러그인 초기화
      - name: Packer Init
        run: packer init ./packer/
      
      # 유효성 검사
      - name: Packer Validate
        run: packer validate -var "app_version=${{ github.sha }}" ./packer/
      
      # AMI 빌드
      - name: Packer Build
        run: |
          packer build \
            -var "app_version=${{ github.sha }}" \
            ./packer/
      
      # 빌드된 AMI ID를 다음 job으로 전달
      - name: Extract AMI ID
        id: ami
        run: |
          AMI_ID=$(jq -r '.builds[-1].artifact_id' manifest.json | cut -d: -f2)
          echo "ami_id=$AMI_ID" >> $GITHUB_OUTPUT
      
      # Terraform으로 즉시 배포 트리거
      - name: Trigger Deployment
        run: |
          echo "Built AMI: ${{ steps.ami.outputs.ami_id }}"
          # 후속 Terraform apply 또는 Auto Scaling Group 업데이트

AWS Image Builder + EventBridge

Image Builder는 콘솔이나 CLI로 파이프라인 실행을 트리거하고, 완료 이벤트를 EventBridge로 수신해 Lambda → Terraform을 연결하는 패턴을 씁니다. 동작은 하지만 파이프라인 구성이 여러 AWS 서비스에 분산되어 가시성이 낮아집니다.

 

결론: CI/CD 통합의 단순함과 가시성은 Packer가 압도적으로 유리합니다.

---

🔍 보안 · 컴플라이언스 관점

AWS Image Builder의 강점

Image Builder에는 Inspector 통합이 내장되어 있습니다. 빌드 파이프라인 안에서 CVE 스캔을 실행하고, 취약점이 발견되면 AMI 배포를 자동으로 차단합니다. AWS Organizations 환경에서 SCPs(Service Control Policies)와 결합하면, 승인되지 않은 이미지의 사용 자체를 막을 수 있습니다.

 

또한 STIG(보안 기술 구현 가이드) 컴포넌트를 AWS가 직접 제공합니다. 금융·공공 환경의 컴플라이언스 요건을 빠르게 충족해야 할 때 유용합니다.

Packer의 보안 접근

Packer 자체에는 스캔 기능이 없습니다. 대신 프로비저너 단계에서 Trivy, Lynis, OpenSCAP 같은 도구를 직접 호출하는 방식입니다. 더 유연하지만, 직접 구성해야 합니다.

# Packer에서 Trivy로 취약점 스캔하는 예시
provisioner "shell" {
  inline = [
    # Trivy 설치
    "curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin",
    
    # OS 패키지 취약점 스캔
    "trivy rootfs --exit-code 1 --severity HIGH,CRITICAL /",
    
    # 결과를 S3에 저장 (감사 로그용)
    "trivy rootfs --format json / > /tmp/trivy-report.json",
    "aws s3 cp /tmp/trivy-report.json s3://my-compliance-bucket/trivy-reports/$(date +%Y%m%d)/report.json"
  ]
}

 

컴플라이언스 환경(금융, 공공, 의료): Image Builder가 유리합니다. 자체 보안 파이프라인을 이미 갖춘 팀: Packer가 더 유연합니다.

---

🔍 비용 · 속도 관점

두 도구 모두 빌드 중 임시 EC2 인스턴스를 사용합니다. 도구 자체의 추가 비용은 없습니다. 차이는 빌드 시간에서 납니다.

항목	AWS Image Builder	Pakcer
도구 비용	무료 (EC2 비용만)	무료 (EC2 비용만)
빌드 인스턴스 시작 오버헤드	약 3~5분 (서비스 초기화 포함)	약 1~2분
빌드 실패 시 재시도 비용	매번 인스턴스 재기동	-debug 모드로 인스턴스 유지 가능
로컬 사전 테스트	불가	Docker builder로 가능 (무료)
병렬 멀티 리전 빌드	배포 구성으로 지원	parallel 블록으로 지원

 

Packer의 로컬 사전 테스트 패턴이 실질적인 비용 절감에 유리합니다. 스크립트 오류를 AWS 빌드 전에 로컬 Docker 컨테이너에서 잡아내면 불필요한 EC2 비용이 발생하지 않습니다.

---

🔍 멀티 클라우드 / 하이브리드 환경

Packer의 가장 강력한 카드입니다.

 

AWS AMI, Azure Managed Image, GCP Custom Image, VMware vSphere Template을 동일한 HCL 파일 하나로 관리할 수 있습니다.

# 멀티 클라우드 동시 빌드 예시
source "amazon-ebs" "aws_golden" {
  region        = "ap-northeast-2"
  instance_type = "t3.micro"
  # ... AWS 설정
}

source "azure-arm" "azure_golden" {
  location        = "Korea Central"
  vm_size         = "Standard_B1s"
  # ... Azure 설정
}

build {
  # 두 플랫폼 동시 빌드
  sources = [
    "source.amazon-ebs.aws_golden",
    "source.azure-arm.azure_golden"
  ]
  
  # 동일한 프로비저너를 양쪽에 적용
  provisioner "ansible" {
    playbook_file = "./ansible/golden-base.yml"
  }
}

 

AWS Image Builder는 AWS 전용입니다. 멀티 클라우드나 온프레미스 이미지가 필요한 순간 선택지에서 사라집니다.

---

⚠️ 주의사항 / 흔한 실수

① Image Builder 컴포넌트 버전 관리를 소홀히 하는 것 컴포넌트는 한번 생성하면 수정이 안 됩니다. 변경할 때마다 새 버전을 만들어야 합니다. 버전 정책 없이 운영하면 어떤 버전이 프로덕션에 들어가 있는지 추적이 어려워집니다.

② Packer에서 임시 키페어·보안그룹을 수동 정리하지 않는 것 빌드 중 강제 종료되면 Packer가 생성한 임시 리소스가 AWS에 남을 수 있습니다. packer build에 --on-error=abort 옵션과 함께 정리 스크립트를 CI에 넣어두세요.

③ AMI 이름에 버전 정보를 넣지 않는 것 golden-ami-latest처럼 덮어쓰는 이름을 쓰면 롤백이 불가능합니다. app-v1.2.3-20240327 형태의 불변 이름을 권장합니다.

④ 빌드 IAM 권한을 과도하게 부여하는 것 빌드용 Role에 AdministratorAccess를 붙이는 경우가 있습니다. 최소 권한 원칙으로, AMI 생성·태깅·S3 접근 등 필요한 권한만 정의하세요.

---

✅ 정리 / 마무리

솔직하게 결론을 내리겠습니다.

상황	추천
AWS 단일 환경 + 컴플라이언스 강조 (금융·공공)	AWS Image Builder
AWS Organizations + Inspector 자동 스캔 필요	AWS Image Builder
CI/CD 파이프라인에 완전 통합, 코드로 관리 원함	Packer
멀티 클라우드 또는 온프레미스 이미지 병행	Packer
Terraform 이미 사용 중, HCL에 익숙한 팀	Packer
빠른 반복 개발, 디버깅 편의성 중시	Packer

 

대부분의 DevOps 실무 팀에게는 Packer가 더 나은 선택입니다. CI/CD 통합, 코드 가시성, 멀티 클라우드 유연성, 빠른 반복 개발 — 이 네 가지 관점에서 Packer가 앞섭니다.

 

AWS Image Builder는 AWS 생태계 안에서 Inspector·SCPs·Organizations를 묶어 컴플라이언스를 자동화해야 할 때 진가를 발휘합니다. 두 도구를 혼용하는 팀도 있습니다. Packer로 베이스 이미지를 만들고, Image Builder로 컴플라이언스 검증 레이어를 얹는 방식입니다.

 

결국 도구의 우열보다 팀의 워크플로우와 환경에 무엇이 맞는가가 핵심입니다. 🎯