"클라우드에 잘 올렸다"는 건 무슨 뜻일까요? 막연한 감이 아니라 점검 기준이 있습니다. AWS가 정리한 Well-Architected 프레임워크는 좋은 아키텍처가 갖춰야 할 다섯 가지 관점을 제시합니다. 처음에는 5개로 시작했고 지금은 6개로 늘었지만, 핵심을 이루는 5대 기둥만 이해해도 내 시스템의 약한 부분을 스스로 진단할 수 있습니다.
5대 기둥 한눈에
| 기둥 | 핵심 질문 | 점검 예시 |
|---|---|---|
| 운영 우수성 | 잘 운영·개선되는가? | 모니터링, 자동화, 배포 절차 |
| 보안 | 데이터와 시스템이 안전한가? | 접근 권한, 암호화, 추적성 |
| 신뢰성 | 장애에도 견디고 복구되는가? | 다중 AZ, 자동 복구, 백업 |
| 성능 효율성 | 자원을 적절히 쓰는가? | 인스턴스 타입 선택, 확장성 |
| 비용 최적화 | 불필요한 지출이 없는가? | 미사용 자원 정리, 적정 사이징 |
다섯 기둥은 따로 노는 항목이 아니라 서로 당기는 관계입니다. 신뢰성을 위해 서버를 여러 대 띄우면 비용이 오르고, 비용을 줄이려 최소한으로 운영하면 신뢰성이 흔들립니다. Well-Architected의 진짜 목적은 이 트레이드오프를 의식적으로 선택하게 만드는 데 있습니다.
기둥끼리 부딪히는 예시
쇼핑몰을 클라우드에 올린다고 가정해 봅니다.
TEXT
"DB를 한 대만 둘까, 두 대로 이중화할까?"
한 대 → 비용 최적화 ↑, 신뢰성 ↓ (장애 시 전체 중단)
두 대 → 신뢰성 ↑, 비용 최적화 ↓ (요금 2배)
정답은 상황에 따라 다릅니다. 결제가 핵심인 서비스라면 신뢰성에 무게를 둬 이중화하고, 사내용 내부 도구라면 비용을 아껴 한 대로 갑니다. 중요한 건 "그냥 한 대 둠"이 아니라 다섯 관점을 놓고 의식적으로 고른 한 대라는 점입니다. Well-Architected는 이렇게 결정에 근거를 부여합니다.
어떻게 활용하나
- 새 시스템 설계 시 — 다섯 기둥을 체크리스트로 두고 빠진 관점이 없는지 점검합니다.
- 기존 시스템 진단 시 — 기둥별로 "지금 약한 곳은 어디인가"를 물어 우선순위를 정합니다.
- 팀 합의 도구로 — "왜 이렇게 설계했나"를 다섯 관점으로 설명하면 결정이 투명해집니다.
다섯 기둥을 모두 만점으로 만들 필요는 없습니다. 서비스 성격에 맞게 어디에 무게를 둘지 정하고, 그 선택을 설명할 수 있으면 충분합니다. Well-Architected는 정답표가 아니라 빠진 관점을 잡아주는 점검 렌즈입니다.
요점 정리
- Well-Architected 5대 기둥은 운영 우수성·보안·신뢰성·성능 효율성·비용 최적화.
- 다섯 기둥은 서로 트레이드오프 관계라 균형과 의식적 선택이 핵심이다.
- 모든 기둥을 만점 낼 필요는 없고, 서비스에 맞는 우선순위를 설명할 수 있으면 된다.
다중 AZ 구성으로 신뢰성을 높이고 적정 인스턴스로 비용을 조절하며 기둥 간 균형을 체감하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.