저자: Arturo Quiroga, Azure AI 서비스 엔지니어 - 시니어 파트너 솔루션 아키텍트 — Microsoft
며칠 전, 오픈 소스 Azure 아키텍처 다이어그램 빌더를 소개하는 프롬프트에서 프로덕션까지: AI로 Azure 아키텍처 다이어그램 구축하기를 게시했습니다. 그중 가장 많은 질문을 받은 기능은 바로 WAF(Well-Architected Framework) 검증이었습니다. 파트너와 고객의 아키텍트들은—이미 Azure Advisor와 Well-Architected Review를 사용하고 있는 분들이 많았습니다—우리가 정확히 어떤 점수화 알고리즘을 사용하는지, Microsoft의 공식 도구와 어떻게 다른지, 그리고 세 가지를 모두 사용해야 하는지 알고 싶어 했습니다.
이 포스트가 그에 대한 답입니다. 설계 시점(Design-time)의 WAF 검증이 어떻게 작동하는지, Microsoft의 두 가지 공식 WAF 평가 알고리즘은 무엇인지, 그리고 아키텍처 수명 주기의 어느 단계에 각각의 도구가 적합한지 심층적으로 살펴보겠습니다.
요약. Microsoft는 두 가지 WAF 평가 수단을 제공합니다. Well-Architected Review(WAR)(설문 기반, 인간의 답변으로 점수화)와 Azure Advisor 점수(카테고리별로 가중치를 둔 '정상 리소스 ÷ 적용 가능 리소스' 방식, 보안은 Defender 보안 점수, 비용은 비용 가중치 산식 적용)입니다. 두 가지 모두 사람이 양식을 채우거나 실제 Azure 텔레메트리 데이터가 필요합니다. 우리 앱은 설계 시점의 다이어그램에서 작동하며, 아무것도 배포되기 전에 결정론적 규칙 사전 스캔과 LLM 정교화 패스를 거치는 하이브리드 파이프라인을 사용합니다. 동일한 5대 WAF 원칙을 다루지만, 수명 주기의 단계가 다릅니다. 이들은 경쟁 관계가 아니라 상호 보완적인 관계입니다.
왜 설계 시점 검증이 중요한가
제가 지금까지 디버깅했던 모든 비용 초과, 안정성 격차, 보안 사고는 프로덕션 단계보다 화이트보드에서 수정하는 것이 훨씬 저렴했습니다. 하지만 대부분의 WAF 도구는 아키텍처가 이미 존재한다고 가정합니다. 즉, 스캔할 배포된 리소스가 있거나(Advisor), 약 60개의 구체적인 질문에 답할 수 있을 정도로 아키텍처가 구축되어 있어야 합니다(WAR).
이로 인해 간극이 생깁니다. "거친 스케치"와 "배포된 리소스 그룹" 사이에는 알고리즘 기반의 WAF 피드백 루프가 없습니다. 다이어그램 빌더가 바로 이 간극을 메워줍니다.
Microsoft의 두 가지 공식 WAF 평가 알고리즘
우리의 접근 방식을 설명하기 전에, Microsoft가 이미 제공하고 있는 것을 정확히 정의할 필요가 있습니다. "WAF 평가 알고리즘"이라는 용어는 두 가지 매우 다른 것을 의미할 수 있기 때문입니다.
1. Azure Well-Architected Review (WAR) — 설문 기반
Well-Architected Review는 Microsoft Learn에서 호스팅되는 무료 자체 평가 도구입니다.
| 항목 | 상세 내용 |
|---|---|
| 입력 | WAF 원칙 체크리스트에 매핑된 약 60개 질문에 대한 사용자의 답변 |
| 워크로드 변체 | Core WAR 외에도 AI/ML, IoT, SAP on Azure, Azure Stack Hub, SaaS, Mission Critical 등 |
| 점수화 | 답변으로부터 도출 — "아니오" 또는 답변하지 않은 질문마다 원칙 점수에서 차감 |
| 출력 | 원칙별 성숙도 점수 + 우선순위 권장 사항 + 선택적 Advisor 통합 |
| 개선 추적 | "마일스톤" (특정 시점의 스냅샷) |
| 사용 시기 | 정기적인 심층 검토, 그린필드(신규) 설계 베이스라이닝, 브라운필드(기존) 감사 |
WAR은 인간 중심적입니다. 알고리즘은 본질적으로 **"권장되는 관행 중 얼마나 많은 것을 수행하고 있다고 확인했는가?"**이며, 이는 평가자가 워크로드 팀 자신일 때 가장 적합한 알고리즘입니다.
2. Azure Advisor 점수 — 텔레메트리 기반
Advisor 점수는 Microsoft가 제공하는 실제 결정론적 WAF 알고리즘에 가장 가깝습니다. 이는 배포된 Azure 리소스에 대해 지속적으로 실행됩니다.
수식: $$점수 = \frac{\sum 정상_리소스}{\sum 적용_가능_리소스}$$
원칙별 예외 사항:
- **보안(Security)**은 Microsoft Defender for Cloud의 보안 점수(Secure Score) 모델을 사용합니다.
- **비용(Cost)**은 정상 리소스의 소매 가격($) 가중치와 권장 사항의 연령 가중치를 합산하며, 연기/해제된 항목은 분모에서 제외합니다.
- 안정성 / 성능 / 운영 우수성은 위의 정상 리소스 비율을 사용합니다.
주요 용어:
- 정상 리소스(Healthy resource) — 해당 원칙에 대해 해결되지 않은 Advisor 권장 사항이 없는 배포된 리소스.
- 전체 적용 가능(Total applicable) — Advisor가 평가할 수 있었던 리소스(해제/일시 중지 제외).
Advisor는 프로덕션 환경에 있을 때 적합한 도구입니다. 배포 전에는 "정상"이나 "적용 가능"으로 계산할 대상이 없으므로 도움을 줄 수 없습니다.
누락된 단계: 설계 시점
각 도구의 영역을 표시한 수명 주기는 다음과 같습니다.
- 설계 / 다이어그램 — 다이어그램 빌더 검증이 여기에서 실행됩니다.
- 운영 / 관찰 — Azure Advisor가 여기에서 지속적으로 실행됩니다.
- 정기 검토 — WAR가 여기에서 실행됩니다. (일반적으로 분기별 또는 주요 마일스톤 발생 시)
이 세 단계는 순차적이며 상호 보완적입니다. 우리 앱은 Advisor나 WAR를 대체하는 것이 아니라, 수정 비용이 가장 저렴한 수명 주기의 초기 단계에 피드백 루프를 추가하는 것입니다.
Azure 아키텍처 다이어그램 빌더에서 설계 시점 검증이 작동하는 방식
검증기는 2단계 하이브리드 파이프라인입니다. 먼저 로컬 규칙을 결정론적으로 적용한 후, LLM이 이를 정교화합니다. 전체 소스는 다음 세 파일에 있습니다.
src/services/architectureValidator.ts— 오케스트레이터 및 프롬프트src/services/wafPatternDetector.ts— 토폴로지 + 서비스 규칙 엔진src/data/wafRules.ts— 규칙 지식 베이스
1단계 — 결정론적 규칙 사전 스캔 (~1ms, LLM 없음)
검증 시작을 클릭하면, 클라이언트 측 규칙 엔진이 다이어그램의 서비스, 연결 및 그룹에 대해 실행됩니다. 규칙은 두 가지 유형이 있습니다.
아키텍처 패턴 규칙
토폴로지 안티 패턴이 감지될 때 발생합니다:
| 패턴 | 감지 트리거 |
|---|---|
single-region |
3개 이상의 서비스가 있지만 전역 LB(Traffic Manager / Front Door)가 없음 |
single-database |
정확히 하나의 데이터베이스 서비스만 있고 복제 신호가 없음 |
no-cache |
컴퓨팅과 데이터베이스가 존재하지만 Redis/CDN이 없음 |
no-monitoring |
Azure Monitor / App Insights / Log Analytics가 없음 |
no-identity |
Microsoft Entra ID가 없음 |
no-waf |
WAF / Front Door / App Gateway가 없는 공용 웹 계층 |
direct-db-access |
프런트엔드 서비스에서 데이터베이스로 직접 연결된 에지(Edge) |
no-key-vault |
4개 이상의 서비스가 있지만 Key Vault가 없음 |
no-backup |
데이터베이스가 있지만 Azure Backup / Recovery Services가 없음 |
no-api-gateway |
2개 이상의 컴퓨팅 서비스가 있지만 APIM / App Gateway / Front Door가 없음 |
서비스별 규칙
다이어그램의 모든 서비스는 App Service, Functions, AKS, Cosmos DB 등 29개 이상의 정규화된 유형별 SERVICE_SPECIFIC_RULES와 매핑됩니다.
지식 베이스 요약
| 메트릭 | 수치 |
|---|---|
| 전체 규칙 수 | 73 |
| 아키텍처 패턴 규칙 | 10 |
| 서비스별 규칙 | 63 |
| 적용되는 Azure 서비스 수 | 29 |
| 안정성(Reliability) 규칙 | 18 |
| 보안(Security) 규칙 | 34 |
| 비용 최적화(Cost Optimization) 규칙 | 5 |
| 운영 우수성(Operational Excellence) 규칙 | 7 |
| 성능 효율성(Performance Efficiency) 규칙 | 9 |
예비 점수
각 발견 사항에는 심각도가 있으며, 심각도에 따라 기본 점수 100점에서 고정된 점수가 차감됩니다.
| 심각도 | 차감 점수 |
|---|---|
| critical | −12 |
| high | −7 |
| medium | −3 |
| low | −1 |
결과 점수의 하한선은 10점(의도적으로 나쁜 아키텍처라도 최소 10점), 상한선은 95점(발견 사항이 없더라도 모델이 놓친 것이 있을 수 있으므로)으로 설정됩니다. 이것이 LLM이 아키텍처를 보기 전의 결정론적 베이스라인이며, 파이프라인의 재현성을 보장합니다.
2단계 — LLM 문맥 정교화
사전 스캔 결과, 토폴로지, 그리고 선택적인 자연어 설명이 결합되어 Azure OpenAI 모델로 전송됩니다. 시스템 프롬프트는 모델에 명확한 점수화 가이드라인을 제공합니다:
- 추가될 수 있는 것이 아니라, 현재 존재하는 것을 기준으로 점수를 매길 것.
- 적절한 서비스가 잘 연결된 아키텍처는 60~80점 사이여야 함.
- 인증 부재, 모니터링 부재, 단일 장애점과 같은 심각한 결함이 있는 경우에만 50점 미만으로 책정할 것.
- 발견 사항은 개선 제안이며, 점수를 심하게 깎는 이유가 되어서는 안 됨.
모델은 엄격한 JSON 형식을 반환합니다.
두 가지 주목할 점:
- 모든 발견 사항은
rule-based또는ai-analysis로 태그가 지정됩니다. 이 태그는 신뢰도의 척도입니다. 결정론적 엔진이 생성한 결과와 모델이 추가로 기여한 분석을 명확히 구분할 수 있습니다. - LLM에는 전체 규칙 카탈로그 대신 패턴 힌트만 제공됩니다. 이를 통해 프롬프트의 크기를 작고 집중적으로 유지하며, 처음부터 모든 것을 분석하게 하는 것보다 3~5배 더 빠르고 저렴하게 처리합니다.
실행 예시
파트너 데모에서 사용했던 프롬프트를 예로 들어보겠습니다.
"멀티 리전 웹 애플리케이션: West US 2와 East US 2에 있는 두 개의 App Service 인스턴스 앞에 Azure Front Door를 배치. 두 인스턴스 모두 지오 복제(geo-replication)가 설정된 Azure SQL Database에서 데이터를 읽음. 텔레메트리를 위해 Application Insights 사용. Entra ID 및 Key Vault는 없음."
생성 후 검증 실행 결과:
1단계 — 사전 스캔 (결정론적), ~1ms
- 감지된 패턴:
no-identity,no-key-vault - 생성된 발견 사항: 8개 (Critical 1, High 1, Medium 3, Low 3)
- 예비 점수: 100 − 12 − 7 − (3×3) − (1×3) = 69
2단계 — LLM 정교화, ~6~9초 모델은 두 가지 패턴 힌트를 수용하고 문맥 내에서 검증한 뒤, 자체적으로 세 가지 발견 사항을 추가합니다.
| 발견 사항 | 출처 | 원칙 | 심각도 |
|---|---|---|---|
| 인증을 위한 Microsoft Entra ID 부재 | rule-based | 보안 | Critical |
| 비밀 관리를 위한 Key Vault 부재 | rule-based | 보안 | High |
| 안전한 배포를 위한 App Service 슬롯 미사용 | ai-analysis | 운영 우수성 | Medium |
| SQL DB 지오 복제는 있으나 RTO/RPO 미정의 | ai-analysis | 안정성 | Medium |
| Front Door 뒤의 정적 자산을 위한 CDN 부재 | ai-analysis | 성능 효율성 | Low |
최종 점수: 71점 (보안 점수가 52점으로 가장 낮음 — 인간 리뷰어가 가장 먼저 지적할 부분과 일치함).
모델 간 비교
결정론적 베이스라인(1단계)이 동일하기 때문에, 검증 비교(Validation Comparison) 보기는 각 LLM이 동일한 베이스라인 위에 무엇을 추가하는지 보여주는 공정한 비교의 장이 됩니다. 아키텍트는 자신의 검토 스타일과 가장 잘 맞는 모델을 선택할 수 있습니다.
Microsoft 알고리즘과의 정렬 방식
| 정렬 포인트 | 의미 |
|---|---|
| 동일한 5대 원칙 | 공식 WAF와 동일한 명칭 및 범위 사용 |
| 동일한 소스 자료 | WAF 문서 및 Azure 아키텍처 센터의 서비스 가이드를 기반으로 규칙 도출 |
| 심각도별 발견 사항 | Advisor의 높음/중간/낮음 영향도 권장 사항과 개념적으로 매핑 |
| 원칙별 + 종합 점수화 | WAR/Advisor의 출력 형식을 미러링하여 익숙한 결과 제공 |
의도적으로 다른 점과 그 이유
| 관심사 | Microsoft | 다이어그램 빌더 | 이유 |
|---|---|---|---|
| 배포된 리소스 필요 | Advisor: 예 | 아니오 (다이어그램 기반) | 설계 시점 도구이므로 아키텍처가 아직 존재하지 않음 |
| 인간의 질의응답 필요 | WAR: 예 | 아니오 (다이어그램에서 도출) | 설계 흐름 내에서 원클릭 검증 제공 |
| 정상/적용 비율 사용 | Advisor: 예 | 아니오 | 배포 전에는 리소스 상태 신호가 없음 |
| 보안 점수(Defender) | Advisor: 예 | 아니오 | Defender는 배포된 리소스가 필요함 |
| 비용 가중 점수 | Advisor: 예 | 아니오 (별도 기능) | 비용 추정은 앱 내 별도 파이프라인으로 처리 |
| AI/LLM 정교화 | 둘 다 없음 | 예 | 정적 카탈로그가 놓치는 문맥적 이슈를 포착하고 자연어로 설명 |
솔직한 한계점
이러한 한계점을 미리 알고 사용하는 것이 좋습니다.
- LLM 점수 변동성. 동일한 다이어그램에서도 모델에 따라 ±5~10점 정도 차이가 날 수 있습니다. 점수는 방향성으로, 발견 사항은 행동 지침으로 활용하세요.
rule-based태그가 기준점입니다. - 실시간 텔레메트리 없음. App Service가 실제로 가용성 영역을 사용하는지는 알 수 없습니다. 다이어그램에 표시된 것만 알 수 있습니다.
- 일반 규칙 세트. 아직 AI/ML, IoT 등 특정 워크로드 전용 규칙은 부족합니다 (WAR는 이를 제공함).
- 규칙 범위의 한계. 29개 서비스와 73개 규칙은 시작일 뿐입니다. LLM 계층은 이 간극을 보완하기 위해 존재합니다.
세 가지 도구를 함께 사용하는 방법
실제로 효과적인 아키텍처 수명 주기:
- 설계 — 다이어그램 빌더를 사용하여 아키텍처를 스케치하고 설계 시점에 검증합니다. 심각한 발견 사항을 해결하고 점수를 합리적인 수준으로 올립니다.
- 배포 — 다이어그램에서 Bicep을 생성하여 배포하고, Azure Advisor가 실제 리소스를 점수화하게 합니다.
- 운영 — Azure Advisor를 지속적으로 사용합니다. 보안 태세를 위해 Defender 보안 점수를 활용합니다.
- 정기 검토 — 분기별로 또는 주요 마일스톤마다 Core WAR를 실행하여 비즈니스 맥락, 트레이드오프 등 인간만 아는 요소를 캡처합니다.
이 세 가지 중 어느 것도 다른 것을 대체하지 않습니다. 이들은 동일한 루프의 서로 다른 단계를 담당합니다.
다음 단계
로드맵에 있는 몇 가지 계획에 대해 피드백을 부탁드립니다.
- 마일스톤 추적: 설계 시점의 점수를 시간 흐름에 따라 비교할 수 있는 기능.
- 워크로드별 규칙 세트: WAR의 분기처럼 AI/ML 등으로 시작하는 워크로드 특화 규칙.
- Advisor 직접 연동: 다이어그램이 배포되면, 동일한 UI에서 해당 Advisor 권장 사항을 표시하여 루프를 닫는 기능.
직접 시도하고, 포크하고, 피드백을 주세요
- 라이브 앱: https://aka.ms/diagram-builder
- 소스 코드: github.com/Arturo-Quiroga-MSFT/azure-architecture-diagram-builder
이미 Advisor와 WAR를 활용하고 계신 아키텍트분들의 반응이 궁금합니다. 설계 시점의 검증이 실제 업무의 간극을 메워준다고 느끼시나요, 아니면 이미 다른 방식으로 해결하고 계신가요? 저장소에 이슈를 남기거나 LinkedIn에서 의견을 들려주세요.
Azure 아키텍처 블로그 게시됨 · 의견과 이슈는 저장소에서 환영합니다.