Microsoft AZ-204: Azure App Service 및 Web Apps — 학습 가이드

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

개요

Azure App Service는 웹 앱, REST API, 백엔드 서비스를 위한 완전 관리형 HTTP 기반 호스팅 플랫폼으로, Windows 및 Linux에서 코드 및 컨테이너 워크로드를 지원합니다. 확장, 배포 워크플로, 인증, 네트워킹 격리, 백그라운드 처리, 보안 구성에 대한 최고 수준의 기능을 제공합니다. 이 서비스를 완전히 익히려면 App Service 요금제 및 확장, 배포 슬롯 및 트래픽 관리, CI/CD 통합 경로, Easy Auth, 사용자 지정 도메인 및 TLS, WebJobs, App Service Environment(ASE), Key Vault를 사용한 보안 구성 패턴을 이해해야 합니다.

요금제, 확장, 배포 슬롯

App Service 요금제는 앱을 호스팅하는 컴퓨팅 리소스를 정의합니다. 하나의 요금제에 속한 모든 앱은 동일한 VM 풀과 확장 구성을 공유합니다.

가격 책정 계층:
- 무료(F1)/공유(D1): 개발 및 테스트 전용입니다. SLA가 없습니다. 사용자 지정 TLS를 사용할 수 없습니다. 배포 슬롯을 사용할 수 없습니다.
- 기본(B1–B3): 전용 VM, 수동 스케일 아웃. 자동 스케일링은 지원하지 않습니다. 기능이 제한적입니다.
- 표준(S1–S3): 자동 스케일링 및 배포 슬롯이 추가됩니다. 프로덕션 환경의 기준이 됩니다.
- 프리미엄 v2/v3 (P1v2/P1v3+): 최신 컴퓨팅, 더 빠른 스토리지, 향상된 네트워킹 기능, 영역 중복성(지원되는 SKU의 경우), 더 높은 확장성을 제공합니다. 엔터프라이즈 프로덕션 및 높은 처리량에 가장 적합합니다.
- ASE의 격리(I1v2+): 고객의 가상 네트워크 전용으로, 네트워크 격리 및 대규모 확장을 제공합니다.
스케일 업 vs 스케일 아웃:
- 스케일 업은 더 많은 CPU, 메모리, 더 빠른 디스크 또는 고급 기능(예: 더 나은 성능과 기능을 위한 Premium v3)을 위해 요금제를 더 높은 SKU로 이동하는 것입니다.
- 스케일 아웃은 인스턴스 수를 늘려 부하를 수평적으로 분산하는 것입니다. 표준 이상 계층은 CPU, 메모리(Linux), HTTP 큐 길이, 요청, 사용자 지정 메트릭 또는 일정과 같은 메트릭 기반 규칙으로 자동 스케일링을 지원합니다. 기본 계층은 수동 스케일 아웃만 지원합니다. 확장은 요금제 내의 모든 앱에 적용됩니다.
배포 슬롯 및 슬롯 교환:
- 표준 이상 계층은 여러 슬롯(예: 스테이징 및 프로덕션)을 지원합니다. 슬롯은 동일한 요금제에서 실행되며, 각 슬롯은 고유한 호스트 이름과 구성을 가집니다.
- 교환은 트래픽 전환 전에 대상을 워밍업하여 거의 제로 다운타임으로 소스 슬롯에서 대상 슬롯으로 콘텐츠와 런타임 상태를 이동합니다. 교환 전에 준비 상태를 확인하려면 applicationInitialization(Windows) 또는 상태 검사를 사용하세요. 미리 보기로 교환 기능을 사용하면 최종 확정 전에 유효성을 검사할 수 있습니다.
- 교환 중에 슬롯에 고정되도록 구성 항목을 슬롯 설정으로 표시하세요(예: 데이터베이스 연결 문자열, 비밀, 진단 엔드포인트). 표시되지 않은 설정은 교환 시 코드와 함께 이동합니다.
슬롯을 사용한 트래픽 라우팅:
- 카나리 테스트(프로덕션 환경에서 테스트)를 위해 라이브 트래픽의 일부를 비프로덕션 슬롯으로 라우팅합니다. 쿠키는 세션 일관성을 유지하기 위해 할당 후 사용자를 특정 슬롯에 고정시킵니다.

배포 및 CI/CD: GitHub, Azure DevOps, 컨테이너 레지스트리

배포 센터는 일반적인 CI/CD 흐름을 통합합니다:

GitHub Actions:
- App Service는 Oryx 빌드 또는 컨테이너 배포를 사용하여 워크플로를 스캐폴딩할 수 있습니다. 특정 브랜치에 푸시하면 Actions가 선택된 슬롯에 빌드하고 배포합니다. 매트릭스 빌드, 환경, 비밀을 지원합니다. Linux 컨테이너의 경우, 워크플로는 ACR 또는 Docker Hub로 빌드 및 푸시한 다음 웹 앱 배포를 트리거할 수 있습니다.
Azure DevOps:
- 파이프라인(YAML 또는 클래식)은 빌드 및 릴리스 단계, 승인, 환경 검사, 다단계 게이팅을 제공합니다. Azure Web App, Azure Web App for Container 또는 ARM/Bicep 기반 배포를 위한 AzureCLI와 같은 태스크를 사용합니다. 변수 그룹 및 Key Vault 기반 비밀은 구성을 중앙 집중화합니다.
컨테이너 레지스트리:
- App Service for Containers는 ACR, Docker Hub 또는 프라이빗 레지스트리에서 이미지를 가져옵니다(pull). 앱에 대한 ACR 웹훅을 통해 지속적인 배포를 구성하면, 새 이미지 푸시가 풀(pull) 및 재시작을 트리거합니다. 태그 또는 다이제스트로 고정할 수 있습니다. 프로덕션 환경의 안전을 위해, 승격하기 전에 이미지 다이제스트와 카나리 슬롯을 사용하세요.
추가 배포 메커니즘:
- Kudu는 재현 가능한 빌드를 위해 Git 기반 푸시, Zip Deploy, Run From Package를 지원합니다. .deployment 파일과 사용자 지정 스크립트는 사이트가 트래픽을 처리하기 전에 빌드 단계를 조정할 수 있습니다. 엔터프라이즈급 릴리스 위생을 위해, 슬롯과 CI/CD를 결합하여 교환 전에 상태 검사 및 워밍업을 검증하세요.

보안, ID, 도메인, TLS

App Service 인증/권한 부여(Easy Auth)는 코드에 미들웨어를 요구하지 않고 ID 관리를 플랫폼에 오프로드합니다.

공급자:
- Microsoft Entra ID(Microsoft ID 플랫폼), Google, Facebook, GitHub, Twitter 및 Entra ID B2C를 포함한 모든 OpenID Connect 호환 공급자. 클라이언트 ID/비밀, 발급자, 허용되는 토큰 대상/범위를 구성합니다. 로그인 작업(익명 허용 vs 인증 필요)을 선택합니다.
토큰 저장소 및 헤더:
- 토큰 저장소를 활성화하여 로그인 흐름 중에 얻은 액세스/새로 고침 토큰을 캐시할 수 있습니다. 이 토큰은 /.auth/me를 통해 검색하고 /.auth/refresh를 통해 새로 고칠 수 있습니다. App Service는 요청 헤더에 사용자 클레임(예: Base64로 인코딩된 X-MS-CLIENT-PRINCIPAL)을 주입하므로 앱은 SDK 종속성 없이 ID를 파생할 수 있습니다. 플랫폼의 로그아웃 엔드포인트를 사용하여 세션을 지웁니다.
사용자 지정 도메인:
- CNAME(권장) 또는 A/ALIAS 레코드를 앱의 기본 호스트 이름에 매핑합니다. 필요한 경우 TXT 레코드로 도메인 소유권을 확인합니다. App Service에서 사용자 지정 호스트 이름을 바인딩합니다.
SSL/TLS 인증서:
- HTTPS만 적용하고 최소 TLS 버전을 설정합니다. SNI(IP당 여러 인증서) 또는 IP 기반 SSL(전용 IP)을 통해 인증서를 바인딩합니다. 프로덕션급 인증서 제어를 위해 개인 인증서(PFX)를 업로드합니다. App Service 관리형 인증서는 와일드카드가 아닌 호스트 이름에 대해 무료로 자동 갱신되는 도메인 유효성 검사 인증서를 제공합니다. 이 인증서는 내보낼 수 없으며 지원되는 계층이 필요합니다. Key Vault 통합을 사용하여 대규모로 개인 인증서를 관리하고 자동 회전하세요.
클라이언트 인증서(mTLS):
- 선택적으로 수신 클라이언트 인증서를 요구하고 유효성 검사를 위해 앱에 전달할 수 있습니다. 엔드투엔드 TLS를 위해 Web Application Firewall 및 리버스 프록시(예: Application Gateway)와 결합하여 사용합니다.

백그라운드 처리 및 격리된 환경

WebJobs와 ASE는 백그라운드 처리 및 네트워크 격리 시나리오를 해결합니다.

WebJobs:
- 연속(Continuous) WebJobs는 웹 앱의 각 인스턴스에서 영구적으로 실행되며, 큐 처리나 이벤트 루프에 적합합니다. 계속 실행되려면 Always On(Standard 등급 이상) 설정이 필요합니다. 앱 플랜의 인스턴스 수에 따라 확장되며, 활성 작업자를 하나만 원하는 경우 코드에서 싱글톤(singleton) 동작을 적용해야 합니다.
- 트리거(Triggered) WebJobs는 온디맨드 또는 일정(settings.job을 통한 CRON)에 따라 실행됩니다. 배치 작업, ETL 또는 주기적인 유지 관리에 이상적입니다.
- WebJobs SDK는 선언적 함수 메서드와 자동 체크포인팅을 통해 Azure Storage Queues, Service Bus 큐/토픽, Blobs, Timers에 대한 트리거와 바인딩을 제공합니다. 큐 트리거 WebJob은 새 메시지에 즉시 반응하고, 앱 인스턴스와 함께 확장되며, 오류 격리를 위해 포이즌 큐(poison queue) 처리를 사용합니다. 로그와 대시보드는 Kudu에서 액세스할 수 있습니다.
App Service Environment (ASE):
- ASEv3는 Isolated v2 SKU를 사용하여 VNet 내부에 App Service 플랜을 호스팅하며, 전용 컴퓨팅, 데이터 평면 격리, 프라이빗 IP를 제공합니다. 퍼블릭 인그레스(public ingress)를 위해서는 외부(External) ASE를 선택하고, 모든 인바운드를 VNet 내에서 프라이빗하게 유지하려면 내부 부하 분산 장치(Internal Load Balancer, ILB) ASE를 선택합니다. 필요에 따라 프라이빗 DNS, 방화벽, NVA/WAF와 통합합니다.
- ASE는 세분화된 이그레스(egress) 제어, 네트워크 검사, 규정 준수 조정을 지원합니다. 예측 가능한 네트워크 경계로 대규모 호스팅을 지원하며 플랜 인스턴스와는 별도로 요금이 청구됩니다.

구성, 연결 문자열, Key Vault 참조

앱 구성은 런타임에 주입되며 슬롯별로 지정할 수 있습니다.

앱 설정:
- 앱에서 환경 변수로 사용할 수 있는 키-값 쌍입니다. 슬롯마다 다른 값을 유지하려면 슬롯 설정으로 표시합니다. 배포 중 순환에서 비정상 인스턴스를 제거하려면 상태 검사(Health check) 경로를 활용합니다. 프레임워크에서 동적 다시 로드 패턴으로 구성하지 않는 한, 변경 시 앱이 다시 시작됩니다.
연결 문자열:
- 별도로 관리되며 환경 변수로 노출됩니다. .NET 앱은 공급자별 구성도 받습니다. 유형에는 SQLAzure, SQLServer, MySQL, PostgreSQL, Custom이 포함됩니다. 비밀(secret)이 스왑되지 않도록 적절한 경우 슬롯 설정으로 표시합니다.
Key Vault 참조:
- 특수 구문인 @Microsoft.KeyVault(SecretUri=https://<vault>.vault.azure.net/secrets/<name>/<version>) 또는 버전 없는 URI를 사용하여 앱 설정 및 연결 문자열에서 비밀을 직접 참조하면 교체된 내용을 자동으로 가져올 수 있습니다. 시스템 할당 또는 사용자 할당 관리 ID를 앱에 할당한 다음, 해당 ID에 vault에 대한 비밀 가져오기(Get secret) 권한(RBAC 또는 액세스 정책)을 부여합니다. 플랫폼은 App Service 구성에 비밀을 노출하지 않고 값을 확인하고 새로 고칩니다. Key Vault의 TLS 인증서를 사용하려면 인증서로 가져오거나 플랫폼에서 지원하는 인증서 참조를 사용합니다.

배포 슬롯 심층 분석 및 운영 우수성

스테이징 슬롯을 CI/CD 대상으로 사용합니다. 배포 후:

웜업(warm-up) 핑과 상태 확인을 실행하여 JIT, 캐시, 데이터베이스 연결을 준비합니다.
슬롯 설정을 사용하여 구성 차이점을 검증하고 프로덕션 비밀과 엔드포인트를 격리합니다.
미리 보기로 교환(swap with preview)을 수행하여 최종 교환 전에 프로덕션 호스트 이름으로 스테이징 슬롯을 테스트합니다. 오류가 발생하면 교환을 취소하여 즉시 롤백합니다.
점진적 배포를 위해, 트래픽 라우팅을 사용하여 적은 비율의 트래픽을 카나리 슬롯으로 보내고 App Insights 메트릭과 로그를 모니터링합니다. 점진적으로 비율을 늘리다가 SLO가 유지되면 교환을 완료합니다.

실제 문제 시나리오

Starbucks가 새로운 웹 주문 플랫폼을 출시합니다. 이 플랫폼은 프로모션 기간 동안의 트래픽 급증을 처리하고, 소셜 로그인을 통합하며, 내부 API를 보호하고, 백그라운드 주문 워크플로를 안정적으로 처리해야 합니다.

두 개의 배포 슬롯(스테이징, 프로덕션)이 있는 Premium v3 App Service 요금제 선택

이유: Premium v3는 더 빠른 CPU와 SSD를 제공하여 페이지 로드 지연 시간을 줄이고 처리량을 높이며, 슬롯과 자동 크기 조정(autoscale) 기능도 포함합니다. 슬롯을 사용하면 프로모션 트래픽 급증 시 무중단 교환과 빠른 롤백이 가능합니다.

GitHub Actions로 CI/CD를 구현하여 스테이징 슬롯에 배포

이유: GitHub Actions는 리포지토리 네이티브 자동화를 제공합니다. 스테이징에 배포하면 고객 트래픽에 영향을 주기 전에 웜업과 검증을 수행할 수 있습니다. 워크플로는 Oryx를 사용하여 main 브랜치에 푸시될 때 빌드 및 배포를 수행하므로 일관된 빌드를 보장합니다.

Microsoft Entra ID 및 Google 공급자로 Easy Auth 활성화; 토큰 저장소(Token Store) 활성화

이유: Easy Auth는 OAuth/OIDC 흐름의 부담을 덜어주어 사용자 지정 보안 코드의 노출 영역을 줄입니다. 여러 공급자를 통해 소비자의 로그인 선호도를 지원할 수 있습니다. 토큰 저장소는 /.auth 엔드포인트를 통해 노출되는 캐시된 토큰을 사용하여 다운스트림 API 호출(예: 로열티 프로필 마이크로서비스)을 간단하게 만듭니다.

사용자 지정 도메인 및 TLS 구성

이유: CNAME을 통해 order.starbucks.com을 바인딩하고, ‘HTTPS만’을 강제하며, 규정 준수를 위해 최소 TLS 1.2를 설정합니다. 스테이징 슬롯에는 App Service Managed Certificate를 사용하여 관리 오버헤드를 줄이고, 프로덕션에는 회사 CA에서 발급한 PFX를 업로드하여 브랜드 및 인증서 정책을 충족합니다.

주문 처리를 위해 Azure Storage Queue 트리거와 함께 WebJobs SDK 사용

이유: 연속(continuous) WebJob은 메시지가 도착하는 대로 처리하여 결제와 주문 처리 과정을 분리(decoupling)하고 트래픽 피크를 완화합니다. ‘항상 실행(Always On)’ 및 요금제 기반 스케일 아웃을 통해 인스턴스가 추가되면 처리량이 자동으로 증가합니다. 포이즌 큐(Poison queue) 처리는 파이프라인을 중단시키지 않고 잘못된 메시지를 격리합니다.

Key Vault 참조 및 시스템 할당 관리 ID로 아웃바운드 비밀 보안

이유: 비밀은 App Service 구성에 저장되지 않습니다. ID는 Key Vault에 대한 최소 권한 액세스를 가지며, 버전 없는 비밀 URI를 통해 원활한 순환(rotation)이 가능합니다.

네트워킹으로 내부 API 보호

이유: 내부 마이크로서비스를 프라이빗 엔드포인트 뒤에 배치합니다. 공개 웹 앱은 VNet Integration(Premium v3)을 통해 보안 백엔드를 호출합니다. 향후 더 엄격한 격리가 필요한 경우, 웹 계층을 ILB ASE로 마이그레이션하여 App Service 기능은 유지하면서 모든 인그레스(ingress)를 프라이빗으로 만들 수 있습니다.

카나리 배포 및 교환을 사용한 릴리스 전략

이유: 프로모션 기간 동안 트래픽의 5%를 스테이징으로 라우팅하여 실시간 검증을 수행합니다. Application Insights를 통해 지연 시간, 오류 예산, 결제 전환율을 모니터링합니다. 상태가 정상이면 미리 보기로 교환을 수행하고, 그렇지 않으면 교환을 취소하고 원인을 조사하여 고객 경험을 유지합니다.

모든 도메인 · Azure Functions 및 Serverless 컴퓨팅 →

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