새 아키텍처 리뷰 회의. "잘 만든 것 같은데, 정말 괜찮은 건가요?"라는 질문에 아무도 명확히 답하지 못합니다. 누군가는 비용을, 누군가는 장애를 걱정하지만 기준이 제각각입니다. 6개월 뒤 그 시스템은 보안 사고와 비용 폭증을 동시에 겪었습니다 — 아무도 체계적으로 점검할 공통 기준이 없었기 때문입니다. Well-Architected는 그 공통 기준입니다.
- 1Well-Architected 6대 기둥과 각 기둥의 핵심 질문을 안다
- 2기둥들이 서로 상충하며 트레이드오프가 불가피함을 이해한다
- 3이 트랙에서 배운 모듈들을 6대 기둥에 매핑할 수 있다
- 4아키텍처를 '느낌'이 아니라 기둥별 질문으로 점검할 수 있다
- 5비즈니스 요구에 따라 기둥 우선순위를 정할 수 있다
좋은 설계를 가르는 6개의 질문
Well-Architected — 정답이 아니라 점검 프레임
Well-Architected는 "이렇게 만들어라"가 아니라 6개 관점의 질문으로 설계를 점검합니다. 목적은 숨은 위험·개선점을 드러내고, 트레이드오프를 의식적으로 결정하게 하는 것입니다. 모든 기둥을 동시에 최대화할 수는 없으니, 무엇을 위해 무엇을 양보하는지를 알고 선택합니다.
6대 기둥: 운영 우수성 · 보안 · 신뢰성 · 성능 효율 · 비용 최적화 · 지속가능성.
위 그림은 6대 기둥과 이 트랙의 각 모듈이 어떤 기둥을 다루는지 매핑한 것입니다. 모듈을 학습하면서 어떤 기둥의 어떤 질문에 답하는지 의식하면 아키텍처 사고가 깊어집니다.
위 그림처럼 성능과 비용, 신뢰성과 비용, 보안과 운영 민첩성은 서로 충돌합니다. 좋은 아키텍처는 이 충돌을 모르고 당하지 않고, 의도적으로 선택하고 문서화하는 것입니다.
위 그림처럼 Well-Architected 검토는 측정→우선순위→개선→검증→학습→공유의 반복 사이클입니다. 서비스가 성장하면 아키텍처도 달라져야 하므로 정기적 재검토가 필요합니다.
각 기둥이 묻는 것 — 그리고 이 트랙의 어디서 배웠나
- 운영 우수성: 변경을 코드로(IaC와 Terraform), 관측으로 파악(관측과 거버넌스), 회고로 개선하는가
- 보안: 최소 권한(계정과 IAM), 비밀 관리(시크릿·키 관리), 네트워크 격리(VPC와 서브넷), 가드레일을 갖췄는가
- 신뢰성: Multi-AZ·자동 복구(오토스케일링 + 로드밸런서), 백업·DR(백업과 재해복구), 비동기 격리(메시지 큐와 이벤트)로 장애를 견디는가
- 성능 효율: 적합한 컴퓨트(가상 서버(EC2)), 캐시·CDN(DNS와 CDN), 적합한 스토리지(오브젝트·블록·파일 스토리지)를 쓰는가
- 비용 최적화: 고아 자원 정리·rightsizing·예약/스팟(클라우드 비용 최적화)으로 새는 돈을 막는가
- 지속가능성: 자원을 덜 쓰고(미사용 종료·효율 타입), 매니지드·서버리스로 활용률을 높이는가
기둥은 서로 상충한다 — 우선순위를 정한다
기둥들은 자주 부딪힙니다. 멀티리전 핫스탠바이는 신뢰성↑ 이지만 비용↑, 강한 보안 통제는 보안↑ 이지만 운영 민첩성↓. 모두를 최대로 만들 수는 없습니다.
그래서 워크로드별 우선순위를 정합니다: 결제 시스템은 신뢰성·보안 우선(비용 양보), 내부 분석 도구는 비용 우선(신뢰성 일부 양보). Well-Architected의 가치는 이 양보를 모르고 당하지 않고 알고 선택하게 하는 데 있습니다.
완성된 시스템을 6개 질문으로 빠르게 점검합니다. '느낌'이 아니라 질문으로 빈 곳을 찾습니다.
□ 운영: 인프라가 코드(IaC)이고, 핵심 지표에 알람이 있는가?
□ 보안: 루트 미사용·최소권한·비밀은 시크릿매니저·DB는 프라이빗인가?
□ 신뢰성: Multi-AZ인가, 백업이 복구 검증됐는가(RTO/RPO)?
□ 성능: 워크로드에 맞는 인스턴스/스토리지·캐시를 쓰는가?
□ 비용: 고아 자원·과대 프로비저닝·예약 미적용이 없는가?
□ 지속가능성: 미사용 자원을 끄고 활용률을 높였는가?
보안 △(비밀 일부 환경변수), 신뢰성 ✗(단일 AZ) → 우선 개선 대상
(아키텍처 리뷰 체크)점검에서 나온 빈 곳을 전부 한 번에 고치지 말고, 위험이 크고 노력이 작은 것부터 처리합니다.
높은위험·낮은노력 → 즉시 (예: 0.0.0.0/0 SSH 닫기, 백업 켜기)
높은위험·높은노력 → 계획 (예: 단일AZ→멀티AZ 전환)
낮은위험 → 백로그
즉시: 퍼블릭 DB 차단, 비밀 시크릿매니저 이전 / 계획: 멀티AZ 전환
(리스크 매트릭스)- 6개 기둥 중 한 번도 점검 안 된 기둥 — 보통 그곳에 가장 큰 위험이 숨어 있음(특히 신뢰성·보안). 빠진 기둥부터 질문
- 모든 워크로드에 같은 수준을 적용 중인지 — 내부 도구에 결제급 신뢰성은 비용 낭비, 결제에 내부도구급은 사고. 차등 적용 여부 확인
- 트레이드오프가 '결정'됐는지 '방치'됐는지 — 단일 AZ가 '비용 위해 의식적 선택'인지 '몰라서 방치'인지. 후자면 리스크
- 점검에서 나온 개선 항목이 위험·노력으로 우선순위화됐는지 — 전부 동시에 고치려다 아무것도 못 고치는 일 방지
상황: 리뷰가 막연한 인상 평가로 끝나 실행으로 이어지지 않음.
원인: 공통 기준(기둥별 질문) 없이 각자 관심사(누구는 비용, 누구는 보안)만 말해 비교·우선순위가 안 됨. '괜찮다/아니다'의 이분법은 트레이드오프를 못 담음.
진단: 6개 기둥별로 구체 질문에 ✓/△/✗를 매겼는지 → 각 결함의 위험·노력을 추정했는지 → 워크로드 중요도에 맞춘 목표가 있는지 확인.
해결: 기둥별 체크리스트로 ✓/△/✗를 매겨 빈 곳을 가시화하고, 위험·노력 매트릭스로 우선순위화(SLO·에러버짓·포스트모템의 위험 기반 사고와 연결). '괜찮다'가 아니라 "신뢰성 △ — 단일 AZ, 비용 위해 의식적 선택, 분기 내 멀티AZ 검토"처럼 결정과 근거를 남깁니다. 리뷰의 산출물은 인상이 아니라 우선순위가 매겨진 개선 목록입니다.
Well-Architected는 클라우드 아키텍트·SRE의 공통 언어입니다. 설계 리뷰·면접에서 "이 아키텍처 어떻게 평가하나요?"에 6개 기둥으로 구조화해 답하면 — "보안은 최소권한·프라이빗 서브넷으로 양호, 신뢰성은 단일 AZ라 개선 필요, 비용은 예약 미적용으로 절감 여지" — 막연한 인상보다 훨씬 설득력 있습니다.
PM 관점에서도 유용합니다. 기둥은 비즈니스 우선순위를 기술 결정으로 번역하는 틀입니다 — "이 서비스는 다운이 곧 매출 손실이니 신뢰성에 투자하고 비용을 감수한다"처럼. 이 모듈은 트랙 전체(왜 클라우드인가부터 관측과 거버넌스까지)의 종합 복습이기도 합니다 — 각 모듈이 어느 기둥을 채우는지 다시 짚어보면 클라우드 설계의 큰 그림이 완성됩니다.
이 모듈로 Cloud 트랙의 큰 그림이 닫힙니다 — 왜 클라우드인가부터 마이그레이션·설계·운영·보안·복원력, 그리고 그 전체를 평가하는 6대 기둥까지. 더 깊은 운영은 인프라 운영·Kubernetes, 개발 협업 언어는 SW 엔지니어링 트랙으로 이어집니다.