Microsoft AZ-305: Well-Architected Framework 및 설계 원칙 — 학습 가이드

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

개요

Azure Well-Architected Framework(WAF)는 Azure에서 안정적이고, 안전하며, 비용 효율적이고, 운영이 뛰어나며, 성능이 우수한 워크로드를 설계, 구축, 운영하기 위한 지침이 되는 원칙들의 집합입니다. 솔루션을 5가지 핵심 요소인 안정성, 보안, 비용 최적화, 운영 우수성, 성능 효율성에 맞추면, 아키텍처 결정이 비즈니스 우선순위, 위험 허용 범위, 데이터 주권 및 예산과 같은 제약 조건에 따라 정보에 입각한 명시적인 절충(trade-off)을 보장합니다. 대규모 환경에서 일관성을 달성하려면 랜딩 존, 정책 기반 거버넌스, 기본으로서의 자동화가 필요합니다. 최신 설계는 디커플링, 이벤트 기반 통신, 그리고 CQRS, Strangler Fig, 마이크로서비스와 같은 패턴을 강조하며, 이는 빠른 변화와 엄격한 규정 준수를 모두 수용하기 위해 Azure 네이티브 서비스와 통합된 관찰 가능성(observability)으로 구현됩니다.

5가지 핵심 요소: 안정성, 보안, 비용, 운영 우수성, 성능

안정성은 워크로드가 장애 발생 시나 변경 중에도 비즈니스 SLA를 지속적으로 충족하도록 보장합니다. 가용성 영역(Availability Zones) 또는 지역 쌍(region pairs)에 배포하여 장애 도메인(fault domains)과 업데이트 도메인(update domains)을 고려해 설계하고, 기본 제공되는 HA 기능이 있는 관리형 서비스를 선택하며, 복원력 패턴을 구현합니다. 카오스 엔지니어링과 재해 복구 훈련을 통해 복구 가능성을 테스트합니다. 상태 저장 데이터(stateful data)의 경우, RPO/RTO 기능을 갖춘 서비스(예: Azure SQL Database Active Geo-Replication 또는 Cosmos DB 다중 지역 쓰기)를 선택하고, 자동화된 백업 및 테스트된 런북(runbook)과 결합합니다.

보안은 제로 트러스트(Zero Trust)에 기반한 심층 방어(defense in depth) 계층입니다. Azure RBAC, Privileged Identity Management(PIM), 그리고 지속적인 권한 상태 유지를 위한 액세스 검토(access reviews)를 통해 최소 권한 원칙을 적용합니다. 프라이빗 엔드포인트, NSG, Azure Firewall을 사용하여 네트워크 폭발 반경(blast radius)을 격리하고, Azure Front Door 또는 Application Gateway에 웹 애플리케이션 방화벽(WAF)을 통합합니다. Defender for Cloud를 통한 지속적인 모니터링, Sentinel의 위협 탐지, 그리고 엄격한 ID 보호(MFA, 조건부 액세스)를 통해 ‘침해를 가정(Assume breach)‘합니다.

비용 최적화는 비즈니스 가치와 총소유비용(TCO)의 균형을 맞추는 것입니다. 원격 측정(telemetry) 데이터를 기반으로 컴퓨팅 및 계층의 크기를 적절하게 조정하고, 스케일링을 사용하여 수요에 맞추고 비프로덕션 환경은 전원을 끕니다. 안정적인 워크로드에는 예약(reservations) 및 절약 플랜(savings plans)으로 약정하고, 중단 가능한 컴퓨팅에는 Spot VM을 활용하며, 스토리지 및 데이터 보존 계층을 나누고, 워크로드 프로필에 맞는 경우 서버리스를 선호합니다. 태깅과 예산을 강제하고, Azure Policy를 사용하여 비용 통제를 표준화합니다.

운영 우수성은 자동화, 반복성, 학습 루프를 강조합니다. Bicep/ARM 또는 Terraform을 사용하여 환경을 코드로 취급하고(environments as code), 드리프트(drift) 수정을 강제하며, 일관된 CI/CD를 구현합니다. 운영 인사이트는 구조화된 로그, 메트릭, 추적, 합성 테스트에서 나오며, 이 모든 것은 경고 및 SLO 대시보드에 연결되어 MTTR을 단축하고 사전 예방적 개선을 위한 정보를 제공합니다.

성능 효율성은 워크로드가 다양한 부하 조건에서 처리량 및 지연 시간 목표를 충족하도록 보장합니다. 스케일 아웃(scale-out)을 위해 설계하고, 적극적으로 캐시하며, 콘텐츠를 엣지(edge)로 푸시하고, 액세스 패턴에 적합한 데이터 파티션 및 읽기 복제본(read replicas)을 선택합니다. 현실적인 부하 테스트로 검증하고 증거에 기반하여 튜닝합니다.

Azure의 안정성 및 성능 패턴

복원력 패턴은 지연 시간을 예측 가능하게 유지하면서 장애의 확률과 영향을 줄입니다.

지수 백오프 및 지터(jitter)를 사용한 재시도: Storage, Service Bus 또는 Cosmos DB와 같은 서비스에서 발생하는 일시적인 오류를 처리하기 위해 Azure SDK의 구성 가능한 재시도 정책이나 Polly(.NET)와 같은 라이브러리를 사용합니다. 지터를 사용한 백오프는 ‘썬더링 허드(thundering herds)’ 현상을 방지합니다. 재시도 횟수에 상한을 두어 SLA를 보호하고 장애를 제때 파악할 수 있도록 합니다.
서킷 브레이커: 오류율이 임계값을 초과할 때 빠르게 실패(fail fast)하여 복구 기간을 확보할 수 있도록 외부 API 호출과 같은 아웃바운드 호출을 서킷 브레이커로 감쌉니다. 연쇄적인 장애를 피하기 위해 클라이언트 계층에서 Polly를 사용하거나 게이트웨이에서 API Management 정책(재시도, 타임아웃, 캐시)을 사용하여 구현합니다.
벌크헤드: 하나의 ‘시끄러운 이웃(noisy neighbor)‘이 시스템을 고갈시키지 않도록 리소스를 분할합니다. 스레드 풀, 컨테이너 복제본, 메시지 처리 파티션을 격리합니다. 플랫폼 수준에서는 장애를 격리하기 위해 바운디드 컨텍스트(bounded context)별로 별도의 App Service 플랜, AKS 노드 풀 또는 Service Bus 큐/토픽을 사용합니다.
상태 엔드포인트 모니터링: 서비스에 liveness 및 readiness 프로브(probe)를 노출합니다. Application Gateway/Front Door의 상태 프로브는 정상 인스턴스로만 트래픽을 라우팅합니다. AKS에서는 Kubernetes 프로브가 파드(pod) 재시작 및 롤아웃 게이팅(rollout gating)을 관리합니다. Application Insights 가용성 테스트 및 사용자 지정 “/healthz” 엔드포인트와 결합하여 종속성 저하를 조기에 감지합니다.

성능 패턴은 복원력을 보완합니다:

캐싱 전략: 자주 액세스하는 데이터(hot data) 및 세션 오프로드를 위해 Azure Cache for Redis를 사용합니다. 멱등성(idempotent) GET 요청에 대해 Azure Front Door 또는 API Management에서 출력 캐싱을 적용합니다. 적절한 경우 write-through 또는 write-behind 패턴을 선호하고, 키 또는 이벤트를 통해 캐시를 무효화하여 최신 상태를 유지합니다. 데이터 계층에서는 Cosmos DB 통합 캐시가 읽기 중심 워크로드의 RU 소비를 줄여줍니다.
CDN: Azure Front Door 또는 Azure CDN을 사용하여 정적 자산과 동적 콘텐츠를 사용자에게 더 가까이 푸시하고, 압축, TLS, WAF를 활성화합니다. 규칙 기반 캐싱, 오리진(origin) 상태 확인, 지역 필터링(geo-filtering)을 구성하여 지연 시간과 비용을 최적화합니다.
읽기 복제본: 읽기 중심 워크로드는 Azure SQL Database의 읽기 가능한 보조 복제본(Active Geo-Replication) 또는 Hyperscale 명명된 복제본(named replicas)으로 확장하고, 분석 또는 보고용으로는 Azure Database for PostgreSQL/MySQL 읽기 복제본을 사용하며, 비즈니스 요구 사항에 맞춰 일관성 모델링(예: 세션, 일관된 접두사)을 적용하여 Cosmos DB에서 다중 지역 읽기를 활성화합니다.
자동 스케일링 패턴: Virtual Machine Scale Sets, App Service 자동 스케일링 규칙, 이벤트 기반 스케일링을 위한 AKS HPA/KEDA, 그리고 Functions 소비/프리미엄 플랜을 사용하여 수평적 스케일링을 구현합니다. 데이터의 경우, 폭증하는 트래픽을 처리하기 위해 Cosmos DB 자동 스케일링 RU/s 및 Event Hubs 자동 확장(auto-inflate)을 사용합니다. 진동(oscillation)을 피하기 위해 항상 스케일링 임계값과 재사용 대기 시간(cool-down periods)을 검증합니다.

운영 우수성, 비용 최적화, 보안 설계 원칙

코드형 인프라(Infrastructure as code): Bicep/ARM 또는 Terraform 모듈로 표준화하고, Git에서 버전을 관리하며, 배포 전 테스트 및 코드형 정책(policy-as-code)으로 검증합니다. 재사용을 위해 템플릿 스펙이나 Terraform 레지스트리를 사용합니다. 환경별로 매개변수화하고, 일관된 태그, 리소스 잠금, 진단 설정을 강제합니다. Azure DevOps 또는 GitHub Actions와 통합하고, 단계적 배포와 승인을 사용하여 통제된 프로모션을 수행합니다.

배포 자동화: 배포 슬롯, 블루-그린, 카나리 전략을 선호하며, 이는 App Service, AKS(Deployment 전략을 사용한 점진적 롤아웃), 가중치 기반 라우팅을 위한 Traffic Manager/Front Door에서 지원됩니다. 마이그레이션 파이프라인과 하위 호환성을 보장하는 계약을 통해 데이터베이스 스키마 변경을 자동화합니다. 상태 프로브(health probe)와 비즈니스 KPI를 사용하여 롤아웃을 통제합니다.

관찰 가능성(Observability): OpenTelemetry로 애플리케이션을 계측하고, 분산 추적, 메트릭, 종속성 맵을 위해 Application Insights로 내보냅니다. 플랫폼 메트릭을 위해 Azure Monitor를 활성화하고, Log Analytics 작업 영역을 배포하며, SLO 및 용량을 위한 통합 문서(Workbook)와 대시보드를 생성합니다. 동적 임계값으로 경고 규칙을 정의하고, ITSM과 통합하며, 감사 및 포렌식을 위해 활동 로그(Activity Log)와 진단 로그를 중앙에서 저장합니다.

적정 규모 설정(Right-sizing) 및 비용 제어: Azure Advisor, Azure Monitor 사용량 메트릭, Application Insights 프로파일링을 사용하여 낭비 요소(유휴 코어, 과도하게 프로비저닝된 vCore, 과할당된 RU/s)를 식별합니다. 안정적인 워크로드(VM, SQL, Synapse)에는 예약(Reservation)/절감 플랜(Savings Plan)을, Storage에는 예약 용량을, Cosmos DB에는 약정 계층(commitment tier)을 적용합니다. 빌드 에이전트, 배치, 체크포인팅을 사용하는 ML 학습에는 Spot VM을 선택합니다. 아키텍처 상의 트레이드오프 균형을 맞춥니다. 관리형 PaaS는 단위 비용이 더 높을 수 있지만 운영 비용을 줄이고 안정성을 향상시킬 수 있습니다. 캐싱은 데이터 송신(egress) 및 RU 비용을 낮추지만, 캐시 무효화의 복잡성이 증가하는 단점이 있습니다. 다중 리전 HA는 비용을 증가시키지만 RTO/RPO 요구사항에 따라 필요할 수 있습니다.

실제 보안 원칙:

심층 방어(Defense in depth): ID부터 데이터까지 제어를 계층화합니다. Private Link를 사용하여 트래픽이 공용 인터넷을 통하지 않도록 하고, NSG와 ASG로 마이크로세분화를 구현하며, Azure Firewall Premium으로 TLS 검사를, 엣지에서는 WAF를 사용합니다. Defender for Cloud 권장 사항과 Just-In-Time VM 액세스를 활성화합니다.
최소 권한 원칙(Least privilege): 관리 그룹/구독/리소스 그룹 수준으로 범위가 지정된 세분화된 RBAC를 구현하고, 보안 암호(secret)보다 관리 ID(managed identity)를 선호하며, Azure Policy와 그룹, 엔터프라이즈 앱, 권한 있는 역할에 대한 액세스 검토(access review)를 통해 대규모로 거버넌스를 적용합니다.
침해 가정(Assume breach): MFA와 조건부 액세스를 요구하고, Sentinel로 모니터링하며, 별도의 랜딩 존과 구독으로 워크로드를 격리합니다. 플랫폼 키 또는 Key Vault의 CMK로 미사용 데이터(data at rest)를 암호화하고, 규제 기관이 요구하는 경우 이중 암호화를 사용합니다. 시간 제한이 있는 스토리지 액세스에는 SAS를 사용하고 정책에 따라 키를 순환시킵니다.
데이터 분류: Microsoft Purview로 데이터를 카탈로그화하고, 민감도를 레이블링하며, DLP를 적용합니다. 암호화, 보존, 액세스를 데이터 분류 등급에 맞추고, PII에 대한 액세스를 기록하며, 해당되는 경우 Dynamic Data Masking 및 Always Encrypted와 같은 기능으로 개인 정보 보호 요구 사항을 지원합니다.

Azure Landing Zones 및 최신 아키텍처 패턴

Azure Landing Zones는 프레임워크를 대규모로 운영화합니다. 관리 그룹 계층(루트 → 플랫폼 → 사업부)을 구성하여 Azure Policy, RBAC, 예산의 범위를 지정합니다. 플랫폼 랜딩 존은 공유 서비스—ID(Azure AD), 연결(Azure Firewall, DDoS, DNS가 있는 허브), 관리(Log Analytics, Automation, Update Management), 보안(Defender for Cloud)—를 제공합니다. 애플리케이션 랜딩 존은 워크로드를 호스팅하며, 환경 및 규정 준수 경계에 따라 분할되고 태그 지정, 진단, 허용된 리소스 유형을 강제하는 상속된 정책을 가집니다. Cloud Adoption Framework(CAF) Enterprise-Scale 설계 또는 Terraform/Bicep 기반 랜딩 존 가속기를 채택하여 빠르고 일관되게 부트스트랩합니다.

Azure의 마이크로서비스는 분리된 팀과 독립적으로 배포 가능한 서비스를 강조합니다:

서비스 검색(Service discovery): AKS에서는 클러스터 내부 확인을 위해 Kubernetes DNS/CoreDNS를 사용하고, 이름 기반 검색 및 재시도를 위해 Dapr 사이드카로 기능을 향상시킵니다. Service Fabric은 상태 저장(stateful) 서비스를 위한 내장된 이름 지정 및 상태 관리 기능을 제공합니다.
API 게이트웨이 패턴: Azure API Management를 사용하여 라우팅, 버전 관리, 인증(OAuth 2.0/JWT 유효성 검사), 할당량, 캐싱을 중앙 집중화합니다. 글로벌 애니캐스트, SSL 오프로드, WAF를 위해 그 앞에 Azure Front Door를 배치하고, 리전별로 라우팅하며 카나리 릴리스를 안전하게 수행합니다.
이벤트 기반 통신: 순서가 보장되는 트랜잭션 명령에는 세션과 함께 Azure Service Bus를 사용하고, 높은 처리량의 원격 측정 데이터에는 Event Hubs를, 반응형 푸시 스타일 이벤트 구독에는 Event Grid를 선택합니다. 최소 한 번 전송(at-least-once delivery), 멱등성 핸들러, 포이즌 메시지 처리, DLQ를 고려하여 설계합니다.

CQRS 및 이벤트 소싱은 성능 및 복잡성 분리를 위해 쓰기 모델과 읽기 모델을 분리합니다. 추가 전용(append-only) 이벤트를 이벤트 저장소(Cosmos DB, Azure SQL 또는 다운스트림 스토리지를 통한 압축 기능이 있는 Event Hubs)에 영속화하고, 이를 재생하여 상태를 재구성하며, Azure SQL Database, Cosmos DB 컨테이너 또는 Azure Cognitive Search와 같은 쿼리에 최적화된 읽기 모델로 프로젝션합니다. Cosmos DB 변경 피드는 프로젝션의 핵심 요소입니다. Azure Functions 또는 Azure Stream Analytics는 변경 사항을 처리하여 거의 실시간으로 읽기 저장소를 업데이트할 수 있습니다. Event Hubs는 대용량 이벤트 스트림을 버퍼링하며, 소비자는 독립적으로 확장됩니다. 명확한 SLA와 사용자 경험 패턴(예: 명령 확인 후 읽기 모델 수렴)을 갖춘 최종적 일관성을 채택합니다.

스트랭글러 피그(Strangler Fig) 패턴은 점진적인 현대화를 가능하게 합니다. 모놀리스 앞에 Azure API Management를 배치하여 특정 엔드포인트를 새로운 마이크로서비스로 라우팅하고, 나머지는 계속해서 레거시 백엔드로 전달합니다. 헤더 기반 라우팅, 응답 변환, 인증을 위해 정책을 사용합니다. 변경 데이터 캡처(예: Azure Data Factory 또는 Database CDC to Event Hubs)로 데이터를 동기화하고, Cosmos DB + 변경 피드로 새로운 읽기 모델을 구축하여 점차적으로 모놀리스 기능을 폐기합니다. 기능 플래그, Front Door에서의 카나리 라우팅, 포괄적인 관찰 가능성을 통해 동작을 비교하며 위험을 관리합니다.

실제 문제 시나리오

Starbucks는 현재 단일 리전의 VM에서 호스팅되는 글로벌 주문 플랫폼을 현대화하고 있습니다. 리전 간 안정성을 개선하고, 모바일 클라이언트의 지연 시간을 줄이며, 최소 권한 및 제로 트러스트를 강제하고, 비즈니스 중단 없이 점진적으로 마이그레이션해야 합니다.

엔터프라이즈 랜딩 존 구축

플랫폼 및 애플리케이션 랜딩 존이 있는 관리 그룹 계층을 만듭니다. 태그 지정, 진단, 허용된 SKU, 프라이빗 엔드포인트에 대해 Azure Policy를 적용합니다. ID, 연결(Azure Firewall Premium, Private DNS가 있는 허브), 관리(중앙 Log Analytics)를 위해 CAF Enterprise-Scale 참조를 선택합니다. 이유: 랜딩 존은 일관된 보안, 네트워킹, 거버넌스 기준을 강제하여 워크로드가 설계에 따라 제어를 상속받도록 합니다.

모놀리스 앞에 엣지 및 API 퍼사드 배치

Azure Front Door(Standard/Premium)와 WAF를 배포하여 글로벌 애니캐스트 진입점, TLS 종료, DDoS 보호를 제공합니다. Azure API Management를 API 게이트웨이로 배치하고 Front Door와 통합하여 클라이언트를 인증(OAuth 2.0)하고, 소비자 그룹별로 속도 제한을 적용하며, 요청/응답을 변환합니다. 이유: Front Door는 지연 시간을 줄이고 엣지에서 보호합니다. API Management는 API 게이트웨이 패턴을 구현하여 스트랭글러 피그 접근 방식과 테넌트별 스로틀링을 가능하게 합니다.

스트랭글러 피그 마이그레이션 구현

API Management 정책을 사용하여 선택된 엔드포인트(예: 메뉴, 매장 찾기)를 두 리전의 AKS에서 실행되는 새로운 마이크로서비스로 라우팅합니다. 다른 모든 경로는 내부 로드 밸런서 뒤의 레거시 모놀리스로 향합니다. 이유: 점진적 라우팅은 빅뱅 방식의 전환을 피하고 팀이 독립적으로 기능을 마이그레이션할 수 있게 합니다.

복원력 있고 성능 좋은 패턴으로 마이크로서비스 구축

AKS에서 이벤트 기반 오토스케일링을 위해 KEDA와 함께 HPA를 활성화합니다. 서비스 간 서비스 검색, 지수 백오프 및 서킷 브레이커를 사용한 재시도를 위해 Dapr를 사용합니다. 핫 리드(hot read) 및 세션 오프로드를 위해 Azure Cache for Redis를 통합합니다. 이유: AKS와 Dapr는 플랫폼에 구애받지 않는 복원력과 서비스 검색을 제공합니다. 캐싱은 읽기 지연 시간과 백엔드 부하를 줄입니다.

이벤트 기반 통신 및 CQRS 채택

도메인 이벤트를 Azure Event Hubs에 게시하고, 주문은 고객 또는 매장별로 파티셔닝하여 Cosmos DB에 영속화합니다. Cosmos DB 변경 피드를 Azure Functions와 함께 사용하여 Azure SQL Database(보고용) 및 Azure Cognitive Search(매장 재고 검색용)의 읽기 모델로 프로젝션합니다. 이유: Event Hubs는 높은 처리량으로 생산자와 소비자를 분리합니다. 변경 피드는 쓰기 성능에 영향을 주지 않으면서 CQRS를 위한 거의 실시간 구체화된 뷰(materialized view)를 가능하게 합니다.

보안 및 ID 강화

데이터 서비스에 대한 프라이빗 엔드포인트, 세분화를 위한 NSG/ASG, 송신 제어를 위한 Azure Firewall을 강제합니다. 모든 워크로드에 관리 ID를 사용하고, 권한 있는 역할에는 PIM을, API Management 제품 구독에는 액세스 검토를 사용합니다. 운영 직원을 위해 조건부 액세스 및 MFA를 활성화합니다. 이유: 심층 방어(Defense in depth)와 최소 권한 원칙은 영향 반경과 자격 증명 위험을 줄입니다. 액세스 검토는 권한 상태를 깨끗하게 유지합니다.

안정성 및 관찰 가능성을 위한 설계

각 리전의 가용성 영역(Availability Zones)에 걸쳐 배포하고, 액티브-액티브 Front Door 라우팅 및 API Management 다중 리전을 구성합니다. Front Door 및 AKS 프로브로 상태 엔드포인트 모니터링을 활성화하고, 새로운 서비스에 대한 카나리 릴리스를 구성합니다. OpenTelemetry로 Application Insights에 계측하고, 로그를 Log Analytics에 중앙 집중화하며, 경고 기능이 있는 SLO 대시보드를 만듭니다. 상태 저장소에 대한 백업/DR을 구현하고 카오스 실험을 실행합니다. 이유: 영역 및 리전 중복성, 상태 기반 라우팅, 포괄적인 관찰 가능성은 SLA를 유지하고 신속한 인시던트 대응을 가능하게 합니다.

지속적인 비용 최적화

원격 측정 데이터를 기반으로 AKS 노드 풀과 App Service 계획의 크기를 적절하게 조정하고, 안정적인 컴퓨팅에 대해 Reservations/Savings Plans를 적용하며, 중요하지 않은 배치 작업에는 Spot VM을 사용합니다. Cosmos DB 오토스케일을 활성화하고 약정 등급을 평가합니다. 예산/태그를 강제하고 매월 Azure Advisor 권장 사항을 검토합니다. 이유: 체계적인 비용 거버넌스는 낭비와 단위 비용을 최소화하면서 성능을 유지합니다.

← 마이그레이션 및 현대화 · 모든 도메인

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