Azure Image Builder의 5가지 구성 요소 완벽 이해하기
By Mirko Peters ·
클라우드 환경이 커질수록 가상 머신 이미지를 관리하는 일은 금세 물류 문제가 될 수 있습니다. 깨끗한 가상 머신을 띄우고, 소프트웨어를 설치하고, 중요한 보안 업데이트를 적용한 뒤 마스터 이미지를 캡처하는 과정을 수작업에 의존하고 있다면, 그 워크플로가 얼마나 취약한지 이미 잘 아실 겁니다. 사람의 실수, 빠뜨린 단계, 동일해야 할 빌드 간의 미세한 구성 차이는 인프라 전반의 보안과 일관성을 해칠 수 있습니다. 다행히 Azure Image Builder는 반복 가능하고 자동화된 기반을 제공해 가상 머신 이미지 관리 방식을 완전히 바꿔 줍니다.
Automatically translated with AI from the original post. Read the English original

클라우드 환경이 커질수록 가상 머신 이미지를 관리하는 일은 금세 물류 문제가 될 수 있습니다. 깨끗한 가상 머신을 띄우고, 소프트웨어를 설치하고, 중요한 보안 업데이트를 적용한 뒤 마스터 이미지를 캡처하는 과정을 수작업에 의존하고 있다면, 그 워크플로가 얼마나 취약한지 이미 잘 아실 겁니다. 사람의 실수, 빠뜨린 단계, 동일해야 할 빌드 간의 미세한 구성 차이는 인프라 전반의 보안과 일관성을 해칠 수 있습니다. 다행히 Azure Image Builder는 이 과정을 근본적으로 바꿔 놓습니다. 반복 가능하고 자동화된 기반을 제공해 가상 머신 이미지를 안정적으로 만들 수 있게 해 주기 때문입니다.
이번 심층 분석에서는 Azure Image Builder의 핵심 아키텍처를 다섯 가지 필수 구성 요소로 나누어 살펴보겠습니다. 초기 소스 설정부터 버전이 지정된 프로덕션 준비 복사본 배포까지, 이 구성 요소들을 이해하면 조직이 가상 머신 프로비저닝을 처리하는 방식을 바꿀 수 있습니다.
Azure Image Builder 소개와 5가지 구성 요소
본격적인 작동 방식을 살펴보기 전에, Azure Image Builder가 실제로 무엇을 하고 무엇을 하지 않는지 이해하는 것이 도움이 됩니다. 많은 관리자가 Image Builder가 일상적인 프로덕션 워크로드의 프로비저닝과 관리를 담당한다고 잘못 생각합니다. 실제로는 Azure Image Builder를 승인된 마스터 복사본을 만드는 궁극의 공장으로 생각하는 편이 맞습니다. 프로덕션 가상 머신을 직접 실행하지는 않으며, 대신 표준화된 골든 이미지를 만들고 이를 바탕으로 한 대, 열 대, 혹은 수천 대의 VM을 안전하게 배포할 수 있게 해 줍니다.
내부적으로 Azure Image Builder는 HashiCorp Packer를 기반으로 동작합니다. 따라서 Azure 빌드를 자동화하기 위해 별도의 Packer 인프라를 구성하거나 확장하거나 유지 관리할 필요가 없습니다. 대신 이미지 템플릿이라고 부르는 명확한 지침 세트를 작성하면, 임시 백엔드 오케스트레이션은 Azure가 관리합니다. 이 서비스를 제대로 활용하려면 소스, 사용자 지정, 유효성 검사, 배포, 버전 관리라는 다섯 가지 핵심 축을 이해해야 합니다.
1단계: 소스 - 기본 이미지로 기반 다지기
성공적인 이미지 빌드는 모두 소스에서 시작됩니다. 소스 이미지는 운영 체제와 초기의 깨끗한 기본 구성을 제공합니다. 대상 워크로드에 따라 이 단계의 선택은 크게 달라질 수 있습니다.
최신 웹 앱 인프라를 배포하는 팀은 Azure Marketplace에서 제공하는 깨끗한 Ubuntu Linux 이미지로 빌드를 시작할 수 있습니다. 엔터프라이즈 애플리케이션 개발 팀은 표준화된 Windows Server 버전을 선택할 수 있고, Azure Virtual Desktop(AVD) 배포에는 일반적으로 사용자 지정된 Windows 11 다중 세션 이미지가 필요합니다. 중요한 점은 Marketplace의 새 이미지만 사용할 수 있는 것은 아니라는 것입니다. 조직은 이전에 캡처한 회사 이미지나 Azure Compute Gallery에 안전하게 저장된 기존 마스터 이미지를 Azure Image Builder의 소스로 지정할 수도 있습니다. 이러한 유연성 덕분에 운영 체제를 완전히 업그레이드해야 하는 경우가 아니라면 기반 계층을 처음부터 다시 만들 필요가 없습니다.
2단계: 사용자 지정 - 변경 사항 자동화와 스크립트 간소화
기본 이미지가 임시 빌드 환경에 로드되면 Azure Image Builder는 사용자 지정 단계로 넘어갑니다. 조직마다 고유한 노하우가 드러나는 단계입니다. 사용자 지정은 이미지를 확정하기 전에 적용해야 할 모든 수정 사항을 정의합니다. 스크립트와 명령으로 라인 오브 비즈니스 애플리케이션을 설치하고, 최신 운영 체제 패치를 적용하고, 모니터링 에이전트를 통합하고, 엔터프라이즈 인증서를 구성하고, 언어 팩을 주입하고, 보안 설정을 강화할 수 있습니다.
이 단계에서 가장 중요한 원칙은 사용자 지정 항목을 작고 모듈화된 형태로 유지하는 것입니다. 수백 줄의 코드를 하나의 단일형 스크립트에 몰아넣으면 빌드가 실패했을 때 문제를 해결하기가 매우 어려워집니다. 대신 로직을 나눠야 합니다. 조직의 모니터링 에이전트 설치만 담당하는 스크립트, 보안 기준선 적용에 집중하는 스크립트, 애플리케이션 종속성을 검증하는 스크립트를 각각 따로 두십시오. 또한 Azure는 정의된 순서대로 단계를 엄격하게 실행하므로 종속성과 재부팅을 신중하게 고려해야 합니다. 모든 작업이 헤드리스 환경에서 자동으로 실행되므로, 설치 프로그램은 관리자가 "다음"을 클릭하기를 기다리며 멈추는 일 없이 무인 설치 매개변수를 반드시 지원해야 합니다.
블록 3: 검증 - 프로덕션 적용 전 이미지 테스트
설치 스크립트가 성공적으로 실행되었다고 해서 이미지가 실제 환경에서 올바르게 작동한다는 보장은 없습니다. 바로 이 지점에서 검증 단계가 중요해집니다. 검증 단계에서는 조직이 프로덕션에 게시하기 전에, 새로 사용자 지정된 이미지를 대상으로 자동화된 상태 점검과 기본 동작 테스트를 실행할 수 있습니다.
검증 과정에서는 필수 백그라운드 서비스가 정상적으로 시작되는지 확인하거나, 중요한 구성 레지스트리 키가 올바른 값을 갖고 있는지 점검하거나, 모니터링 엔드포인트에 연결할 수 있는지 확인하는 스크립트를 실행할 수 있습니다. 검증 블록의 궁극적인 목표는 수백 대의 프로덕션 가상 머신이 이미 배포되어 최종 사용자에게 전달된 뒤에 문제를 발견하는 것이 아니라, 이미지 빌드 파이프라인 안에서 문제를 미리 찾아내는 것입니다.
블록 4: 배포 - 마스터 복사본 게시
이미지가 빌드와 검증 단계를 성공적으로 통과하면, 이제 일반적인 사용을 위해 이미지를 제공할 차례입니다. 배포 블록은 새로 만든 마스터 복사본을 최종 대상 위치에 게시하는 작업을 담당합니다.
Azure Image Builder는 표준 관리 이미지와 스토리지 계정에 저장되는 원시 VHD 파일을 비롯해 여러 대상 유형을 지원합니다. 다만 클라우드 운영 규모를 키우는 조직에는 Azure Compute Gallery가 가장 적합한 대상입니다. Compute Gallery는 이미지 정의를 체계적으로 구성하고, 여러 Azure 리전에 걸쳐 전역 복제를 처리하며, 버전 롤아웃을 관리하고, 비즈니스 부서별 액세스 권한을 제어할 수 있는 강력한 기능을 제공합니다.
블록 5: 버전 관리 - 릴리스와 롤백 관리
이미지는 고정된 결과물이 아니며, 보안을 유지하려면 지속적으로 업데이트해야 합니다. 이미지 빌드 템플릿을 실행할 때마다 명확하고 구별되는 새 버전을 생성할 수 있습니다. 예를 들어 4월 이미지 릴리스에는 특정 Windows 보안 패치와 회사 텔레메트리 에이전트 4.2 버전이 포함될 수 있고, 5월 릴리스에는 더 최신 패치와 4.3 버전이 포함될 수 있습니다.
명확한 버전 관리 전략은 완벽한 추적성을 제공합니다. 새로 배포된 가상 머신에서 이상 동작이 나타나면, 해당 머신의 메타데이터를 즉시 확인하여 어떤 이미지 버전으로 생성되었는지 정확히 알아낼 수 있습니다. 더 나아가 버전 관리는 안전망 역할도 합니다. 새로 패치된 이미지에 예상치 못한 호환성 문제가 발생하면, 배포 파이프라인이 문제없이 검증된 이전 릴리스 버전으로 즉시 롤백할 수 있습니다.
백그라운드 살펴보기: 템플릿, 관리 ID, 임시 VM
이 다섯 가지 구성 블록을 원활하게 조율하기 위해 Azure는 몇 가지 핵심 백그라운드 구성 요소에 의존합니다. 이들을 이해해 두면 로그를 모니터링하거나 리소스 그룹을 문제 해결할 때 많은 시간을 절약할 수 있습니다.
첫 번째는 이미지 템플릿입니다. 이는 모든 원본, 사용자 지정 스크립트, 검증 단계, 대상 위치를 구조화된 형식으로 정의하는 기준 청사진 역할을 합니다. 두 번째는 관리 ID입니다. Azure는 설치 바이너리를 읽고, 로그를 기록하고, 이미지를 게시하기 위해 명시적인 권한이 필요하지만, 자동화 스크립트 안에 암호나 비밀 정보를 하드코딩해서는 안 됩니다. 관리 ID는 최소 권한 원칙에 따라 정밀한 액세스를 안전하게 부여합니다.
마지막으로, 빌드가 시작되면 임시 가상 머신과 연결된 스토리지 디스크 같은 추가 인프라가 스테이징 리소스 그룹에 나타날 수 있습니다. 이는 전혀 이상한 현상이 아닙니다! Azure는 원본 자산을 직접 수정하지 않고 구성을 안전하게 적용하기 위해 임시 작업 환경을 만듭니다. 빌드가 완료되어 최종 이미지가 배포되면, 이 임시 컴퓨팅 및 스토리지 리소스는 자동으로 삭제됩니다.
결론: 한 번 빌드하고 여러 번 배포하기
Azure Image Builder는 클라우드에서 운영 일관성을 확보하는 엔지니어링 팀의 방식을 근본적으로 바꿉니다. 오류가 발생하기 쉬운 수동 체크리스트 대신 소스, 커스터마이징, 검증, 배포, 버전 관리로 구성된 구조화되고 반복 가능한 파이프라인을 사용하면, 조직 전체에 배포되는 모든 가상 머신이 안전하고 예측 가능한 기준 상태에서 시작되도록 보장할 수 있습니다.
가상 머신이 처음 부팅될 때마다 귀중한 시간을 들여 패치를 내려받고 소프트웨어를 구성하는 대신, 이미지를 만드는 과정에서 무거운 작업을 한 번에 끝내 두십시오. 이 워크플로에 대한 포괄적인 오디오 안내 설명과 추가 배포 팁을 듣고 싶다면 함께 제공되는 팟캐스트 에피소드 Azure Image Builder - Simply Explained도 꼭 들어 보시기 바랍니다.