Well-Architected Framework는 SAA에서 한 번 본 사람이 많지만, Professional DevOps의 눈으로 다시 보면 완전히 다른 도구가 된다. 6개 Pillar를 "외울 항목"이 아니라 "어떤 시나리오든 즉시 분류하는 사고 프레임"으로 쓰는 법이 오늘의 주제다.
DOP-C02 시나리오 문제가 어려운 이유는 답이 2~3개 다 동작하기 때문이다. 그 중 "가장 적합한 것"을 찾으려면 시나리오가 어느 Pillar를 묻고 있는지를 먼저 잡아야 한다. 이 분류 능력이 곧 합격선이다.
2012년 AWS 솔루션 아키텍트들이 "고객이 자주 묻는 똑같은 질문"을 정리하기 시작했다. "어떻게 설계해야 잘 한 건가요?"라는 질문에 매번 다른 답을 주는 게 비효율적이라, 사내 best practice 문서로 통합했다. 2015년 외부 공개, 2016년 5 Pillars 정립, 2021년 Sustainability 추가로 6 Pillars 완성. 이 진화 과정 자체가 클라우드 설계의 우선순위 변화를 반영한다 — 처음엔 안정성·성능만 중요했고, 비용 압박이 오면서 Cost Optimization이 강화됐고, ESG 시대가 오면서 Sustainability가 들어왔다.
DevOps 관점에서 W-AF가 특별한 이유는 DevOps Guidance가 W-AF의 한 lens로 별도로 발행됐다는 점이다(2023). 즉 AWS는 "DevOps는 W-AF의 모든 Pillar에 걸쳐 있는 cross-cutting concern"으로 본다. Operational Excellence 하나만의 문제가 아니다.
💡 관련 이론: W-AF는 ISO 9126(소프트웨어 품질 모델)의 클라우드 버전에 가깝다. ISO 9126은 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성 6축으로 SW 품질을 분류했는데, W-AF는 그 클라우드 버전이다. 또한 ITIL v4의 "Service Value System"과도 맞물린다 — ITIL의 Continual Improvement 원칙이 W-AF의 review 사이클에 반영되어 있다.
"Run and monitor systems to deliver business value, and continually improve processes and procedures." 한국어로 번역하면 "운영을 통해 비즈니스 가치를 전달하고, 프로세스를 끊임없이 개선한다"인데, 이게 곧 DevOps의 정의와 거의 같다.
핵심 design principle:
AWS 도구 매핑:
🔍 더 깊이: "Operations as code"는 단순히 IaC가 아니다. Runbook as code까지 포함한다. SSM Automation Document는 YAML/JSON으로 정의되어 git에 들어가고, 사람이 콘솔에서 클릭하는 절차가 코드로 표현된다. 그래서 같은 사고가 재발해도 자동으로 동일한 복구 절차가 실행된다. 이게 "MTTR 1시간 → 5분"의 결정적 메커니즘이다.
전통적 보안은 "배포 후 보안팀이 점검"이었지만 DevSecOps는 "shift left" — 보안을 파이프라인 왼쪽(개발 단계)으로 당긴다. SAST(정적 분석)는 CodeBuild의 한 phase로 들어가고, DAST(동적 분석)는 staging 환경에서 자동 실행되며, 컨테이너 이미지 스캔(ECR Scan, Inspector)은 빌드 시점에 실행된다.
AWS 도구 매핑:
📚 사례: 2019년 Capital One 사고(1억 600만 고객 데이터 유출)는 보안의 shift left 부재가 어떤 결과를 가져오는지 보여준다. SSRF 취약점이 있는 WAF + IMDSv1 + 과도한 IAM 권한이 결합되어 사고로 이어졌는데, 이 모든 요소가 CI/CD 단계에서 자동으로 검출 가능했던 것이다. AWS는 이 사고 직후 IMDSv2를 출시했고, Inspector v2(2021)에 자동 IMDSv1 검출 룰을 추가했다.
💡 관련 이론: NIST CSF(Cybersecurity Framework)의 5 함수(Identify, Protect, Detect, Respond, Recover)가 W-AF Security Pillar의 best practice와 거의 1:1로 매핑된다. DOP-C02는 NIST 용어를 직접 묻지는 않지만, "Detective control vs Preventive control" 같은 분류는 자주 나온다.
"Workload performs its intended function correctly and consistently when expected." 핵심은 두 가지 — 장애가 일어나지 않게(prevention)와 장애가 일어나도 자동 복구(self-healing).
핵심 design principle:
AWS 도구 매핑:
🔍 더 깊이: AWS의 Reliability 철학은 "Cell-based architecture"로 진화하고 있다. 한 리전을 여러 독립적인 cell로 나누고, 한 cell의 장애가 다른 cell에 전파되지 않게 격리한다. 이게 2017년 S3 us-east-1 장애 이후 AWS 내부적으로 점진적으로 적용되어 왔다. 시험에서는 직접 안 나오지만, "blast radius 최소화"라는 키워드로 같은 개념이 등장한다.
"Use computing resources efficiently to meet system requirements." 단순히 "빠르게"가 아니라 "필요한 만큼만 효율적으로"가 핵심이다.
핵심 design principle:
DevOps 관점에서 중요한 건 "experimentation 인프라"다. AWS Evidently로 A/B 테스트를 코드로 정의하고, AppConfig로 점진적 롤아웃을 하며, CloudWatch RUM으로 실사용자 성능을 측정한다.
💡 관련 이론: "Mechanical sympathy"는 Martin Thompson이 2011년 만든 용어로, "하드웨어 특성을 이해하고 그에 맞는 코드를 짠다"는 뜻이다. AWS에서는 워크로드별 인스턴스 family 선택(C5: 컴퓨트 집약, R5: 메모리, M5: 균형, X1: 인메모리 DB)이 정확히 이 개념이다. Graviton(ARM)이 등장하면서 가격-성능 trade-off가 다시 등장했다.
"Run systems to deliver business value at the lowest price point." DevOps와 직접 연관되는 부분은 "자동화된 비용 거버넌스"다.
핵심 design principle:
AWS 도구 매핑:
🎯 시나리오: 한 회사가 "야간에만 사용하는 분석 워크로드"라는 시나리오를 제시하면, 답은 Cost Optimization 쪽이다. 패턴은 ① EC2 → Spot 인스턴스로 전환 ② Scheduled Scaling으로 야간만 켜기 ③ S3 → IA/Glacier로 콜드 데이터 이동 ④ Lambda나 Fargate로 idle cost 제거.
탄소 발자국 최소화. DevOps 관점에서는:
AWS는 2025년까지 100% 재생에너지, 2040년까지 net-zero carbon을 약속했다. 시험에서 직접 묻는 비중은 낮지만, "어느 리전이 가장 친환경적인가" 같은 보기가 종종 등장한다.
W-AF의 진짜 어려운 점은 6 Pillar가 서로 충돌한다는 것이다. 어느 하나를 강화하면 다른 하나가 약해진다.
| 충돌 | 설명 | 예시 |
|---|---|---|
| Reliability ↔ Cost | Multi-AZ/Region은 안정성을 높이지만 비용 2-3배 | RDS Multi-AZ vs Single-AZ |
| Security ↔ Operational Excellence | 강한 보안은 자동화를 어렵게 함 | Cross-account 자동 배포 vs IAM 분리 |
| Performance ↔ Cost | 고성능 인스턴스는 비싸다 | C5n vs C5 |
| Reliability ↔ Performance | 동기 복제는 안정성 ↑, latency ↑ | RDS Multi-AZ sync replication |
| Sustainability ↔ Performance | 친환경 리전이 사용자와 멀 수 있음 | Stockholm 리전 vs Seoul 사용자 |
이 trade-off가 시험 시나리오의 본질이다. 예를 들어 "RTO 5분, 비용 최소화"가 동시에 요구되면 Pilot Light DR 패턴(평소엔 최소 자원만, 사고 시 빠르게 확장)이 정답이다. 둘 중 하나만 극단적으로 잡으면 모두 망친다.
⚠️ 함정: 시험에서 "모든 Pillar를 동시에 만족하는 솔루션"이 보기에 있으면 거의 함정이다. 현실에서 그런 게 없다. 시나리오에서 명시된 우선순위(예: "비용보다 안정성 우선")를 잡아내고, 그 우선순위에 맞춰 답을 골라야 한다.
2023년 AWS는 W-AF의 lens 중 하나로 DevOps Guidance를 별도 발행했다. 6 Pillar에 새로 추가된 게 아니라, 6 Pillar 전체에 걸쳐 DevOps 관점에서 추가된 가이드라인이다.
DevOps Guidance의 4개 영역:
이 lens가 등장한 의미는 크다 — AWS가 공식적으로 "DevOps는 W-AF 안에서 별개의 lens가 필요할 만큼 중요한 cross-cutting concern"으로 인정한 셈이다. DOP-C02 시험은 이 lens의 내용을 직접 묻진 않지만, 시나리오의 배경 사고로 깔려 있다.
📚 사례: 한 글로벌 핀테크가 DevOps Guidance lens로 자체 진단을 했을 때 "Organizational Adoption" 영역에서 가장 낮은 점수가 나왔다. 도구는 다 있는데(CodePipeline, X-Ray, GuardDuty) 팀 책임이 명확하지 않아 사고 시마다 "누가 답할 차례냐"로 시간을 허비했다. 해결책은 SLO + Error Budget + Incident Manager runbook 일원화. 6개월 후 MTTR이 4시간 → 30분으로 단축됐다.
콘솔에서 6 Pillar를 자동 진단해주는 도구가 Trusted Advisor다. 250+ 체크 항목이 5개 카테고리(Cost, Performance, Security, Fault Tolerance, Service Limits)로 분류된다.
| 카테고리 | W-AF Pillar 매핑 | 예시 체크 |
|---|---|---|
| Cost Optimization | Cost Optimization | 미사용 EIP, 낮은 사용률 EC2 |
| Performance | Performance Efficiency | High CPU 인스턴스, EBS 사용률 |
| Security | Security | MFA 없는 root, 0.0.0.0/0 SG |
| Fault Tolerance | Reliability | Single AZ RDS, ASG 미설정 |
| Service Limits | Reliability + Cost | API rate limit 근접 |
Business/Enterprise Support 플랜에서 전체 체크가 활성화되고, Developer 플랜에서는 기본 7개만 제공된다. EventBridge 통합으로 체크 결과를 자동화 워크플로에 연결할 수 있다(예: 0.0.0.0/0 SG 발견 시 Slack 알림 + Lambda 자동 수정).
🔍 더 깊이: AWS Trusted Advisor와 AWS Config Rules는 비슷해 보이지만 다르다. Trusted Advisor는 AWS가 정의한 250+ best practice를 체크, Config Rules는 고객이 정의한 임의 규칙을 체크. 시험에서 "AWS-managed best practice check"가 키워드면 Trusted Advisor, "custom compliance rule"이면 Config다.
콘솔의 AWS Well-Architected Tool은 워크로드를 등록하고 6 Pillar의 질문에 답하면 risk 점수를 산출해준다. CLI로도 가능:
# Workload 생성
aws wellarchitected create-workload \
--workload-name "prod-payment-api" \
--description "Payment processing API" \
--environment PRODUCTION \
--aws-regions ap-northeast-2 us-east-1 \
--lenses wellarchitected serverless devops
# Review 진행
aws wellarchitected list-answers \
--workload-id $WORKLOAD_ID \
--lens-alias wellarchitected
# 자동화: improvement plan 추출
aws wellarchitected get-workload --workload-id $WORKLOAD_ID \
| jq '.Workload.RiskCounts'
# 출력 예: {"UNANSWERED": 0, "HIGH": 3, "MEDIUM": 7, "NONE": 21, "NOT_APPLICABLE": 5}여기서 HIGH risk 3개가 우선순위. AWS Console에서 각 HIGH를 클릭하면 구체적인 improvement plan(예: "Enable Multi-AZ for RDS")이 나온다.
시험장에서 한 시나리오를 받으면 이렇게 분류한다:
이 4단계가 익숙해지면 시나리오 문제가 단순한 패턴 인식 작업이 된다.
다음 글에서는 AWS의 DevOps 도구 전체 지도 — Code* 시리즈, CDK, SSM, CloudWatch, X-Ray 등을 한눈에 정리해 어디서 어떤 도구를 쓰는지 감을 잡는다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
한 회사가 "사용자 응답 시간을 50ms 이하로 보장하면서, 동시에 비용도 최저화하라"는 요구를 제시했다. 이 시나리오에서 W-AF Pillar 간 trade-off로 가장 정확한 분석은?
문제 2
Trusted Advisor와 AWS Config Rules의 차이로 가장 정확한 것은?
문제 3
W-AF의 6 Pillar 중 "Make frequent, small, reversible changes"를 design principle로 명시한 것은?
문제 4
어떤 회사가 자체 환경에서 W-AF Tool을 실행한 결과 HIGH risk 5개, MEDIUM risk 12개가 나왔다. 우선순위 처리 순서로 가장 적절한 것은?
문제 5
DevOps Guidance lens가 2023년 W-AF에 추가된 의미로 가장 정확한 것은?
문제 6
한 회사가 EU 사용자 대상 서비스를 운영하는데 GDPR 준수와 응답 시간 단축이 모두 중요하다. 다음 중 가장 적합한 설계는?
문제 7
Cost Optimization Pillar의 "Adopt a consumption model" 원칙에 가장 부합하는 AWS 도구 조합은?