AZ-400 시험에서 배포 전략 파트는 '코드를 완성한 뒤 어떻게 운영 환경에 안전하게 전달하는가'를 묻습니다. 빌드와 테스트가 끝났다고 해서 작업이 끝난 게 아닙니다. 배포 방식을 잘못 선택하면 수천 명의 사용자가 동시에 오류를 경험하거나, 롤백에 몇 시간이 걸리기도 합니다. 이 파트는 위험을 분산하는 다섯 가지 패턴과, 그것을 코드 레벨에서 제어하는 Feature Flag, 선언형으로 관리하는 GitOps를 다룹니다.
옷가게의 시즌 교체처럼 — Blue-Green과 Recreate
봄 컬렉션을 진열하면서 겨울 컬렉션을 완전히 치워버리는 가게가 있는 반면, 두 매장을 동시에 운영하다가 한쪽으로 손님을 몰아주는 방식을 쓰는 가게도 있습니다. 배포는 전자입니다. 구 버전을 먼저 내리고 신 버전을 올립니다. 가장 단순하지만 전환 순간에 서비스가 완전히 중단됩니다. 유지보수 윈도가 허용된 내부 도구라면 괜찮지만, 외부 사용자가 있는 프로덕션에는 어울리지 않습니다.
배포는 두 개의 동일한 환경을 동시에 유지하는 방식입니다. Blue가 현재 운영 중이고, Green에 신 버전을 배포해 준비합니다. 준비가 완료되면 로드 밸런서나 DNS를 Green으로 원자적으로 전환합니다. 문제가 생기면 다시 Blue로 되돌리면 됩니다. Azure App Service에서는 과 으로 이 패턴을 구현합니다. Slot Swap은 warm-up 요청까지 완료한 뒤 트래픽을 전환하므로 콜드 스타트 문제 없이 즉시 전환됩니다.
단점은 인프라 비용입니다. 두 환경을 동시에 유지해야 하므로 비용이 두 배 가까이 듭니다. 비용이 부담스럽다면 Green 환경을 테스트 기간에만 스케일 업하고 스왑 직후 Blue를 축소하는 방식으로 절충할 수 있습니다.
수도꼭지를 조금씩 트는 것처럼 — Canary와 Rolling
수도꼭지를 한 번에 확 열면 수압이 너무 강해 문제가 생길 수 있습니다. 조금씩 열면서 이상이 없으면 더 열고, 이상이 있으면 바로 잠글 수 있습니다. 배포가 이 방식입니다. 전체 트래픽의 일부(예: 5%)만 신 버전에 보내고, 오류율과 응답 시간을 모니터링하면서 비율을 점진적으로 늘립니다.
Azure에서 Canary는 App Service의 Deployment Slot에서 트래픽 비율을 지정하거나, Azure Kubernetes Service(AKS)에서 Ingress 가중치를 조정해 구현합니다. 핵심은 메트릭을 기준으로 '자동 진행'과 '자동 롤백' 조건을 Azure Monitor 경보와 연결하는 것입니다.
배포는 여러 인스턴스를 순서대로 하나씩 교체합니다. 구 버전과 신 버전이 잠시 동시에 운영되므로 API 하위 호환성이 반드시 유지되어야 합니다. AKS에서 과 파라미터가 이 속도를 제어합니다.
| 패턴 | 다운타임 | 인프라 비용 | 롤백 속도 | |------|----------|------------|----------| | Recreate | 있음 | 낮음 | 느림 | | Blue-Green | 없음 | 높음 | 즉시 | | Canary | 없음 | 중간 | 빠름 | | Rolling | 없음 | 낮음 | 중간 |
!배포 전략 4가지 비교
신약 임상시험처럼 — Feature Flag와 Progressive Delivery
새 기능을 배포했다고 해서 모든 사용자에게 바로 노출할 필요는 없습니다. 신약은 소수 자원자에게 먼저 임상시험을 하고, 결과가 좋아야 다음 단계로 넘어갑니다. 는 코드가 이미 배포된 상태에서 기능 ON/OFF를 런타임에 제어하는 방법입니다. 배포와 릴리즈를 분리하는 핵심 도구입니다.
Azure에서는 과 라이브러리를 함께 씁니다. App Configuration에 feature flag 키-값을 저장하고, .NET/Java/Python 앱이 Azure.Identity로 App Configuration에 연결해 플래그를 읽습니다. 특정 사용자 ID, 사용자 비율(%), 지역 등을 조건으로 설정할 수 있습니다. GitHub Feature Flags나 LaunchDarkly 같은 서드파티 도구를 쓰더라도 같은 개념입니다.
는 Canary + Feature Flag + 관찰 가능성을 조합한 접근법입니다. 코드를 배포하되 플래그를 꺼두고, 플래그를 점진적으로 여는 방식으로 위험을 분산합니다. 기능 실험이 끝나면 플래그 조건 코드를 제거하는 정리 작업도 파이프라인에 포함해야 합니다. 플래그가 누적되면 코드베이스가 복잡해지기 때문입니다.
악보를 선언하면 오케스트라가 알아서 연주하는 것처럼 — GitOps
오케스트라 지휘자가 악보에 '빠르게, 강하게'라고 써두면 연주자들이 알아서 그에 맞게 연주합니다. 는 클러스터의 원하는 상태를 Git 저장소에 YAML로 선언하고, 에이전트가 Git과 실제 클러스터 상태를 지속적으로 비교·동기화하는 방법입니다.
와 가 대표적인 GitOps 도구입니다. Flux는 Git 저장소를 폴링하거나 웹훅으로 변경을 감지해 클러스터에 반영합니다. ArgoCD는 시각화 UI와 동기화 정책을 함께 제공합니다. Azure에서는 AKS에 를 연결해 Flux 확장을 설치하는 방식으로 GitOps를 관리합니다.
GitOps의 핵심 가치는 감사 추적입니다. 모든 인프라 변경이 Git 커밋으로 남으므로 '언제 누가 무엇을 왜 바꿨는지'를 명확히 추적할 수 있습니다. 롤백도 로 처리합니다. Azure Pipelines가 애플리케이션 코드를 빌드·테스트하고, GitOps가 클러스터 상태를 관리하는 역할 분리가 일반적입니다.
도로 공사 중에도 차가 달릴 수 있으려면 — 데이터베이스 마이그레이션
도로를 공사한다고 해서 차를 아예 막아버리면 안 됩니다. 한 차선만 막고 나머지로 우회시키면서 공사를 진행해야 합니다. 배포에서 가장 까다로운 부분이 데이터베이스 스키마 변경입니다. 앱은 빠르게 교체할 수 있지만, 스키마는 롤백이 어렵습니다.
전략은 Expand·Migrate·Contract의 세 단계로 진행합니다. 먼저 새 컬럼을 추가하고(Expand), 데이터를 이전하고(Migrate), 구 컬럼을 제거(Contract)합니다. Blue-Green 배포에서 Green 앱이 신 스키마를 쓰는 동안 Blue 앱이 구 스키마를 계속 쓸 수 있도록, Expand 단계에서는 구·신 두 스키마를 모두 지원하는 상태를 유지합니다.
마이그레이션 원칙은 "절대로 기존 컬럼을 먼저 삭제하지 않는다"입니다. 컬럼 삭제나 이름 변경은 현재 운영 중인 구 버전이 실패할 수 있기 때문입니다. Azure에서는 EF Core Migrations, DACPAC/BACPAC, Flyway 같은 도구로 이 원칙을 자동화합니다. 파이프라인에 마이그레이션 스크립트 실행 단계를 포함하되, 스크립트는 항상 멱등성(여러 번 실행해도 결과가 같음)을 보장해야 합니다.
시험 핵심 정리
"트래픽 일부만 신 버전에 보내 모니터링" -- Canary 배포 "두 환경을 유지하다가 원자적으로 전환" -- Blue-Green / Slot Swap "코드 배포와 기능 릴리즈를 분리" -- Feature Flag "Azure에서 Feature Flag 저장·관리" -- Azure App Configuration + Feature Manager "Git 저장소가 클러스터 상태의 단일 진실 공급원" -- GitOps "AKS에서 GitOps 구현 시 Azure 관리형 에이전트" -- Azure Arc + Flux 확장 "Rolling 배포에서 구·신 버전 동시 운영 시 필수 조건" -- API 하위 호환성 "스키마 변경 시 구 버전 앱이 깨지지 않도록 컬럼 추가 후 데이터 이전 후 삭제" -- Expand-Migrate-Contract (Forward-only) "인스턴스 전체를 내리고 새 버전으로 교체, 다운타임 허용" -- Recreate 배포 "AKS Rolling 배포 속도 제어 파라미터" -- maxUnavailable / maxSurge
Blue-Green = 즉시 롤백, Canary = 점진적 검증, Feature Flag = 배포·릴리즈 분리, GitOps = Git이 진실 공급원.