Microsoft AZ-400: Azure Pipelines를 사용한 CI/CD 파이프라인 — 학습 가이드

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft DevOps Engineer Expert AZ-400 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

배포, 환경, 전략 및 게이트

배포 작업은 CD의 핵심 의미 체계를 제공합니다. 배포 작업은 특정 환경을 대상으로 하며, 롤아웃과 수명 주기 후크를 제어하는 전략에 따라 실행됩니다:

• 환경은 배포 대상(예: dev, test, prod)을 나타내며, Kubernetes 클러스터, 가상 머신과 같은 리소스나 플랫폼에 구애받지 않는 배포를 위한 일반 “none” 리소스를 포함할 수 있습니다. 환경은 텔레메트리, 승인, 검사를 통합 관리합니다.
• 승인 및 검사는 환경과 서비스 연결에 연결됩니다. 승인은 배포가 진행되기 전에 지정된 승인자의 허가를 요구합니다. 검사는 업무 시간, 필수 작업 항목, Azure Monitor 신호, REST API 또는 Azure Functions 호출, 분기 보호와 같은 조건을 평가하는 게이트 역할을 합니다. 이를 통해 성능 기준이나 규정 준수 조건이 충족되지 않으면 상위 환경으로의 승격을 방지합니다.
• 전략은 업데이트가 롤아웃되는 방식을 결정합니다:
  • runOnce는 preDeploy 및 postDeploy 후크를 사용하여 단일 웨이브로 변경 사항을 적용합니다.
  • rolling은 안전한 진행을 위해 maxParallel 및 실패 임계값을 사용하여 인스턴스 전반에 걸쳐 배치 단위로 배포합니다.
  • canary는 전체 롤아웃 전에 유효성을 검사하기 위해 routeTraffic 및 postRouteTraffic 단계를 거쳐 트래픽을 점진적으로 전환합니다.
  • blue-green(red/black이라고도 함)은 병렬 환경이나 슬롯에 배포한 후 로드 밸런서 또는 App Service 슬롯 교환을 통해 트래픽을 전환하는 방식으로 구현됩니다. blue-green은 YAML에서 명명된 전략은 아니지만, 환경, 라우팅, 교환 작업을 통해 구현되며 트래픽을 되돌려 빠른 롤백을 제공합니다.

배포 로직은 환경 스테이지별 배포 작업으로 인코딩하세요. 강력한 게이트를 구현하려면 임시 스크립트 폴링 대신 환경 검사를 활용해야 합니다. 비밀이 필요한 경우, 변수에 포함시키지 말고 서비스 연결을 통해 Azure Key Vault에서 검색하세요.

아티팩트, 캐싱 및 서비스 연결

아티팩트와 캐싱은 재사용성과 성능을 향상시킵니다:

• 파이프라인 아티팩트는 빌드 결과물을 게시하고 사용하는 네이티브 방식입니다. 명명된 아티팩트를 게시하려면 PublishPipelineArtifact를 사용하고, 현재 또는 특정 실행에서 가져오려면 DownloadPipelineArtifact를 사용하세요. 이들은 YAML에서 안정성과 스테이지 간 공유에 최적화되어 있습니다. 다른 파이프라인에서 아티팩트를 사용할 때는 파이프라인 리소스를 선언하고 해당 아티팩트 리소스 이름을 사용하여 정확하게 검색합니다.
• 유니버설 패키지는 특정 언어에 국한되지 않는 자산(예: CLI 도구, 데이터 파일)을 위해 Azure Artifacts를 통해 버전 관리되는 불변의 바이너리 배포를 제공합니다. Universal Packages 작업을 사용하여 게시 및 다운로드하고, 피드 뷰(예: prerelease 대 release)를 통해 구성하며, 피드에서 보존을 관리합니다.
• 파이프라인 캐싱은 종속성 복원 속도를 높입니다. Cache 작업은 키와 경로를 사용합니다. 키는 정확한 무효화를 위해 잠금 파일(package-lock.json, Pipfile.lock, packages.lock.json, go.sum)과 OS 및 도구 버전을 해시해야 합니다. 복원 키는 부분적인 캐시 히트에 대한 대체 일치 항목을 제공합니다. 캐시 경로에 비밀을 포함하지 말고, 캐시 크기 제한을 준수하며, 잠금 파일이 불안정한 임시 도구의 경우 캐싱을 비활성화하세요. cacheHitVar를 관찰하여 작업 동작을 분기할 수 있습니다.

서비스 연결은 Azure Pipelines가 외부 시스템에 접근할 때 사용하는 ID를 정의합니다:

• 유형에는 Azure Resource Manager(Azure 구독 및 리소스 그룹용), GitHub(리포지토리 읽기/쓰기, 상태 보고용), Docker/Container Registry(Docker Hub, ACR용)가 포함됩니다. 그 외 AWS, GCP, 일반 서비스 엔드포인트, 패키지 레지스트리용 연결도 있습니다.
• OIDC 페더레이션(워크로드 아이덴티티 페더레이션)은 Azure DevOps와 클라우드 ID 공급자 간의 신뢰 관계를 설정하여 장기 수명 비밀을 제거합니다. ARM의 경우, Azure DevOps 발급자 및 리포지토리/파이프라인 클레임에 바인딩된 페더레이션 자격 증명을 사용하여 Entra ID 애플리케이션을 구성합니다. 런타임에 Azure DevOps는 단기 수명 토큰을 클라우드 액세스 토큰으로 교환하여 서비스 주체 비밀을 제거하고 자격 증명 유출 위험을 줄입니다.
• 범위 지정 및 거버넌스는 매우 중요합니다. ARM 연결의 범위를 최소 권한(이상적으로는 사용자 지정 RBAC을 사용하는 리소스 그룹 수준)으로 지정하세요. “모든 파이프라인에 액세스 권한 부여” 옵션을 비활성화하고 대신 파이프라인을 명시적으로 승인하세요. 사용 전에 수동 검토나 정책 유효성 검사를 요구하도록 서비스 연결에 승인 및 검사를 연결하세요.

클래식 vs YAML 및 마이그레이션

클래식 파이프라인은 빌드와 릴리스 개념이 분리된 시각적 디자이너를 사용합니다. 작업 기반 작성, 변수 관리, 릴리스 환경 및 게이트 기능을 제공합니다. YAML 파이프라인은 코드형 파이프라인(pipeline-as-code), 다단계 통합, 템플릿, 그리고 리포지토리와 연동된 강력한 버전 관리를 제공합니다. 기능 패리티는 대부분 달성되었습니다. 릴리스 게이트는 환경 승인 및 검사로 대체되었고, 배포 작업은 환경을 모델링하며, 파이프라인 아티팩트는 빌드 아티팩트를 대체합니다. 또한 템플릿과 extends는 대규모 중앙 거버넌스를 구현합니다. 남아있는 차이점은 주로 UI 기반의 수동 개입과 일부 특수한 릴리스 디자이너 기능에 관한 것이며, 이는 YAML에서 수동 유효성 검사(Manual Validation) 작업과 환경 검사를 통해 처리됩니다.

실용적인 마이그레이션 경로는 다음과 같습니다.

1. 클래식 빌드 및 릴리스 정의, 작업, 변수, 환경, 승인 및 게이트를 목록화합니다.
2. 어시스턴트를 사용하거나 YAML로 내보내기 기능을 이용해 빌드를 YAML로 변환한 후, 재사용성과 유지보수성을 위해 템플릿으로 리팩터링합니다.
3. 각 릴리스 환경을 환경을 대상으로 하는 배포 작업이 포함된 YAML 스테이지로 모델링합니다. 릴리스 게이트는 환경 승인 및 검사(예: Azure Monitor 쿼리 검사, 작업 항목 쿼리 검사)로 변환합니다.
4. 공유 변수를 변수 그룹으로 외부화하고, 비밀 관리를 위해 Key Vault를 연결합니다. 서비스 주체 시크릿은 OIDC 기반 서비스 연결로 교체합니다.
5. 릴리스 아티팩트 트리거를 파이프라인 리소스 트리거로 교체합니다. CI에서 파이프라인 아티팩트를 게시하고 CD 스테이지에서 소비합니다.
6. 두 파이프라인을 일시적으로 함께 실행하여 기능이 동일한지 검증한 후, 적절한 롤백 계획을 세워 전환하고 클래식 정의를 폐기합니다.

실제 문제 시나리오

Starbucks는 마이크로서비스 플랫폼의 배포를 표준화해야 하며, 클래식 릴리스에서 YAML로 마이그레이션하면서 성능 게이트를 강제하고, 자격 증명 위험을 줄이며, 빌드 속도를 높여야 합니다.

1. extends 템플릿을 사용하여 다단계 YAML 작성

• 접근 방식: 정적 분석, SCA, 보안 검사를 위한 공통 스테이지와 표준 알림을 주입하는 중앙 조직 수준의 extends 템플릿을 생성합니다. 각 서비스 파이프라인은 이 템플릿을 확장(extend)하고 서비스별 빌드 및 배포 스테이지를 정의합니다.
• 근거: Extends는 거버넌스를 일관되게 강제하고, 필수 규정 준수 단계를 보장하면서 서비스 파이프라인을 간결하게 유지합니다.

2. CI, PR, 스케줄, 파이프라인 트리거 구현

• 접근 방식: 각 서비스에 대해 경로 필터가 있는 CI 및 PR 트리거를 구성하고, 장시간 실행되는 통합 테스트를 위해 야간 스케줄을 추가하며, 패키징 파이프라인이 파이프라인 리소스를 통해 배포 파이프라인을 트리거하도록 연결합니다.
• 근거: 코드 변경에 대한 빠른 피드백, 주기적인 상태 확인, 그리고 알려진 아티팩트의 결정론적 프로모션을 보장합니다.

3. 에이전트 풀을 사용한 혼합 에이전트 전략 사용

• 접근 방식: 빌드 작업은 탄력성을 위해 Microsoft-hosted ubuntu-latest에서 실행하고, 배포 작업은 내부 클러스터에 접근할 수 있는 Starbucks VNet 내의 자체 호스팅 에이전트에서 실행합니다. 환경별로 풀을 사용하여 에이전트를 격리하고 풀 사용을 제한합니다.
• 근거: 호스팅 에이전트는 CI의 유지보수 부담을 최소화하고, 자체 호스팅 에이전트는 CD를 위한 안전한 네트워크 접근을 제공합니다. 풀 범위 지정은 최소 권한 원칙을 강제합니다.

4. 변수 그룹과 런타임 매개변수를 사용한 변수 관리

• 접근 방식: 공유되는 비-비밀 값은 변수 그룹에 배치하고, 비밀은 연결된 변수 그룹을 통해 Azure Key Vault에서 검색하며, 비-프로덕션 브랜치에서 성능 게이트를 토글하기 위해 불리언(boolean) 매개변수 enablePerfGate를 노출합니다.
• 근거: 중앙 집중식 구성은 중복을 방지하고, Key Vault는 비밀을 보호하며, 매개변수는 컴파일 타임의 구조적 선택을 결정합니다.

5. 환경, 승인, 검사를 포함한 배포 작업 정의

• 접근 방식: dev, staging, prod를 환경으로 모델링합니다. staging과 prod에 승인을 추가합니다. 검사 추가: prod에는 업무 시간(business hours) 검사를, staging의 지연 시간이 기준치를 초과하면 프로모션을 차단하는 Azure Monitor 쿼리 검사를 추가합니다.
• 근거: 환경 수준의 승인 및 검사는 통제된 프로모션을 구현하고 프로덕션 배포 전에 SLO를 강제합니다.

6. 카나리 후 블루-그린 전략 적용

• 접근 방식: staging 환경에서 카나리 전략을 사용하여 증분 변경 사항을 검증합니다. 프로덕션 환경에서는 병렬 슬롯/환경에 배포하고 즉시 롤백 기능과 함께 트래픽을 스왑합니다(블루-그린/레드-블랙).
• 근거: 카나리는 검증 중 위험을 줄이고, 블루-그린은 배포 시간을 최소화하며 가장 빠른 롤백을 제공합니다.

7. 파이프라인 아티팩트와 캐싱으로 최적화

• 접근 방식: 빌드 결과물을 파이프라인 아티팩트로 게시하고 배포 스테이지에서 소비합니다. 폴백을 위해 restoreKeys와 함께 lockfile 해시 키를 사용하여 의존성 복원을 캐시합니다.
• 근거: 아티팩트는 불변하고 추적 가능한 프로모션을 보장하며, 캐싱은 정확성을 희생하지 않으면서 빌드 시간을 크게 단축합니다.

8. OIDC와 범위가 지정된 권한으로 서비스 연결 보안 강화

• 접근 방식: 워크로드 아이덴티티 페더레이션(workload identity federation)을 사용하여 리소스 그룹으로 범위가 지정된 ARM 서비스 연결을 생성합니다. 서비스 연결에 대한 승인 및 검사를 요구하고 “모든 파이프라인에 액세스 권한 부여” 옵션을 비활성화합니다.
• 근거: 수명이 긴 비밀을 제거하고 감사 가능한 승인을 통해 최소 권한 원칙을 강제합니다.

이 엔드투엔드 설계는 코드형 YAML(YAML-as-code) 거버넌스를 엔터프라이즈급 승인 및 검사와 연계하고, 캐싱과 아티팩트를 통해 배포를 가속화하며, OIDC 및 범위가 지정된 서비스 연결을 통해 보안을 강화합니다.

← 소스 제어 및 리포지토리 관리 · 모든 도메인 · 코드형 인프라 및 구성 관리 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Microsoft 찾아보기 →