AWS Well-Architected Framework: 클라우드를 '제대로' 설계하는 6가지 기둥

들어가며: "이게 맞게 한 건가?"

AWS 콘솔에 로그인했다. EC2 인스턴스를 하나 띄웠다. S3 버킷을 만들고, RDS 데이터베이스를 연결했다. 서비스가 돌아간다.

그런데 이상하게 불안하다.

"보안 설정 이거 맞아?" "요금 폭탄 맞는 거 아냐?" "서버 죽으면 어떡하지?" "나중에 사용자 늘어나면 버틸 수 있나?"

이 불안함은 자연스러운 것이다. 클라우드는 자유도가 너무 높다. 같은 서비스를 만들어도 설계 방법은 수십 가지이고, 그중 대부분은 "돌아가긴 하지만 좋은 설계는 아닌" 상태다.

AWS도 이 문제를 알고 있었다. 2012년부터 고객 아키텍처를 리뷰하면서, 같은 실수가 반복된다는 것을 발견했다. 보안 그룹을 0.0.0.0/0으로 열어놓는다든가, 단일 가용 영역에 모든 것을 배치한다든가, 로그를 전혀 남기지 않는다든가.

그래서 AWS는 이 경험을 체계화했다. 그것이 Well-Architected Framework다.

이 글에서는 Well-Architected Framework의 6가지 기둥(Pillar)을 하나씩 뜯어보겠다. 각 기둥이 무엇을 다루는지, 왜 중요한지, 실무에서 어떤 모습인지를 20대 눈높이에서 풀어본다.

---

1. Well-Architected Framework이란 무엇인가

한 줄 정의

AWS Well-Architected Framework는 클라우드 워크로드를 설계하고 운영할 때 따라야 할 모범 사례를 6가지 기둥으로 정리한 공식 가이드다.

건축에 비유하면 이해가 쉽다. 건물을 지을 때 "건축법"이 있다. 내진 설계, 방화 구획, 비상구 위치 같은 것들. 건축법을 무시하고 지어도 건물은 서 있을 수 있지만, 지진이 오거나 화재가 나면 무너진다.

Well-Architected Framework은 클라우드의 건축법이다. 지키지 않아도 서비스는 돌아가지만, 트래픽이 몰리거나 보안 사고가 나거나 요금 청구서를 열어보는 순간 후회하게 된다.

6가지 기둥 한눈에 보기

중요한 포인트: 기둥 간 트레이드오프

6가지 기둥은 서로 독립적이지 않다. 하나를 극대화하면 다른 하나가 희생될 수 있다.

• 안정성을 높이려고 Multi-AZ로 배포하면 → 비용이 올라간다
• 성능을 높이려고 큰 인스턴스를 쓰면 → 비용 최적화와 충돌한다
• 보안을 강화하려고 암호화를 추가하면 → 성능에 미세한 오버헤드가 생긴다

Well-Architected Framework은 "모든 기둥을 100점으로 만들어라"가 아니다. 비즈니스 상황에 맞게 기둥 간 균형을 잡아라는 것이다. 그래서 프레임워크를 이해하는 것이 중요하다 — 어떤 선택이 어떤 기둥에 영향을 미치는지 알아야 현명한 트레이드오프를 할 수 있다.

---

2. Pillar 1 — 운영 우수성 (Operational Excellence)

핵심 질문

"장애가 터졌을 때, 우리 팀은 당황하지 않고 체계적으로 대응할 수 있는가?"

운영 우수성은 시스템을 얼마나 잘 운영하는가에 관한 기둥이다. 코드를 잘 짜는 것만큼이나 운영 프로세스를 잘 설계하는 것이 중요하다는 메시지다.

핵심 원칙 5가지

실무 예시: IaC 전후 비교

주요 AWS 서비스

---

3. Pillar 2 — 보안 (Security)

핵심 질문

"누가 무엇에 접근할 수 있는가? 데이터는 안전한가?"

보안 기둥은 다른 5개 기둥과 다르게 양보가 불가능하다. 성능을 조금 포기하거나 비용을 조금 더 쓰는 건 괜찮지만, 보안을 "적당히"하면 비즈니스 자체가 위험해진다.

보안 설계 원칙

IAM — 모든 보안의 시작점

AWS 보안에서 가장 먼저 이해해야 할 것은 IAM(Identity and Access Management)이다.

암호화: 저장 시 + 전송 시

보안에서 자주 나오는 암호화는 두 가지 상태를 다룬다.

탐지 제어 (Detective Controls)

보안은 "차단"만으로는 부족하다. 누군가 벽을 넘었을 때 알아채는 것도 중요하다.

---

4. Pillar 3 — 안정성 (Reliability)

핵심 질문

"서버 하나가 죽으면 서비스도 같이 죽는가?"

안정성 기둥은 시스템이 장애로부터 복구하고, 수요 변화에 적응하며, 중단 없이 운영되는 능력에 관한 것이다.

"다 죽어도 살아남는" 설계

클라우드의 가장 큰 장점은 장애를 전제로 설계할 수 있다는 것이다. 온프레미스에서는 서버가 죽지 않기를 바라지만, 클라우드에서는 "서버는 반드시 죽는다"를 전제로 아키텍처를 짠다.

AZ(Availability Zone)는 같은 리전 내에서 물리적으로 분리된 데이터센터 그룹이다. AZ-a에 있는 서버가 전부 죽어도, AZ-b와 AZ-c에서 서비스가 계속된다. 이것이 Multi-AZ 배포다.

핵심 개념 3가지

SLA 99.9% vs 99.99%의 차이

"9가 하나 더 붙는 게 뭐가 다르냐"고 생각할 수 있다. 하지만 그 차이는 크다.

99.999%(Five 9s)를 달성하려면 연간 다운타임이 5분 남짓이어야 한다. 이 수준을 달성하려면 Multi-Region 배포, 자동 장애 조치(Auto Failover), Health Check 기반 라우팅 등 고도화된 아키텍처가 필요하고 — 당연히 비용도 올라간다. 그래서 우리 서비스에 어떤 수준의 가용성이 필요한지 먼저 판단해야 한다.

Auto Scaling — 수요에 맞춰 늘고 줄고

Auto Scaling은 탄력성(Elasticity)의 핵심이다. 피크 시간에 서버 10대, 새벽에 서버 2대 — 수요에 맞게 리소스가 자동으로 조절된다. "최대 부하에 맞춰 항상 서버 10대를 유지"하는 온프레미스 방식과의 결정적 차이다.

주요 AWS 서비스

---

5. Pillar 4 — 성능 효율성 (Performance Efficiency)

핵심 질문

"지금 사용하는 리소스가 워크로드에 최적인가?"

성능 효율성은 단순히 "빠르면 좋다"가 아니다. 컴퓨팅 리소스를 효율적으로 사용하면서 성능 요구사항을 충족하는 것, 그리고 기술이 발전하면 이에 맞게 지속적으로 최적화하는 것이다.

Right-Sizing: 맞는 옷 입히기

초보자가 가장 많이 하는 실수 중 하나가 인스턴스 유형을 잘못 선택하는 것이다.

ML 학습에 범용 인스턴스를 쓰면 GPU가 없어서 학습이 느리고, 웹 서버에 GPU 인스턴스를 쓰면 비싼 GPU가 놀고 있다. 워크로드의 특성을 파악하고 맞는 유형을 선택하는 것이 Right-Sizing이다.

성능 효율성의 4대 영역

캐싱 전략: 반복 연산을 줄여라

같은 데이터를 매번 데이터베이스에서 읽어오는 것은 비효율적이다. 캐싱은 자주 접근하는 데이터를 빠른 저장소에 미리 올려놓는 전략이다.

CDN(Content Delivery Network)은 글로벌 성능을 혁신적으로 개선한다. 한국 사용자가 미국 서버에서 이미지를 받으면 200ms가 걸리지만, 서울 엣지 로케이션의 CloudFront에서 받으면 20ms 안에 끝난다.

---

6. Pillar 5 — 비용 최적화 (Cost Optimization)

핵심 질문

"우리가 쓰는 비용 중에 낭비되는 부분은 없는가?"

클라우드의 가장 큰 장점인 "쓴 만큼만 낸다(Pay-as-you-go)"는, 뒤집으면 "관리하지 않으면 끝없이 나간다"는 뜻이기도 하다.

비용 최적화 핵심 전략

EC2 구매 옵션 비교

태깅(Tagging)으로 비용 추적

비용 최적화의 시작은 "돈이 어디에 나가는지 아는 것"이다. AWS 리소스에 태그를 달면 팀별, 프로젝트별, 환경별로 비용을 분류할 수 있다.

주요 AWS 비용 관리 서비스

---

7. Pillar 6 — 지속 가능성 (Sustainability)

핵심 질문

"같은 결과를 더 적은 에너지로 달성할 수 있는가?"

지속 가능성은 2021년에 추가된 가장 최신 기둥이다. 기후 변화에 대한 글로벌 관심이 높아지면서, 클라우드 아키텍처가 환경에 미치는 영향도 고려해야 한다는 인식이 반영됐다.

클라우드가 이미 친환경인 이유

아키텍트가 할 수 있는 것

지속 가능성 기둥은 "전력 회사를 바꿔라"가 아니다. 아키텍처 설계 단계에서 환경 영향을 줄이는 선택을 하라는 것이다.

AWS Customer Carbon Footprint Tool

AWS는 콘솔에서 Customer Carbon Footprint Tool을 무료로 제공한다. 내 AWS 사용량이 만들어내는 탄소 배출량을 확인하고, 시간에 따른 추세를 볼 수 있다.

---

8. Well-Architected Tool: 무료 셀프 리뷰

"내 아키텍처는 괜찮은가?"를 직접 점검하기

AWS 콘솔에서 무료로 사용할 수 있는 AWS Well-Architected Tool은 6가지 기둥에 대한 셀프 리뷰 질문지를 제공한다.

Lens: 맞춤형 리뷰

기본 6가지 기둥 외에도, 특정 도메인에 맞는 Lens(렌즈)를 적용할 수 있다.

---

9. Well-Architected Labs: 직접 해보기

Well-Architected Framework을 읽는 것과 직접 해보는 것은 완전히 다르다. AWS는 Well-Architected Labs라는 핸즈온 실습 자료를 무료로 제공한다.

기둥별 추천 실습

---

10. AWS 자격증과의 연결

Well-Architected Framework을 공부하면 자연스럽게 AWS 자격증 준비가 된다. 특히 Solutions Architect Associate (SAA-C03) 시험은 Well-Architected Framework의 내용과 상당 부분 겹친다.

자격증 로드맵에서의 위치

SAA 시험에서 Well-Architected가 나오는 방식

SAA 시험은 직접적으로 "Well-Architected Framework의 6가지 기둥을 나열하시오" 같은 문제를 내지 않는다. 대신, 시나리오 기반으로 Well-Architected 원칙을 적용하는 능력을 평가한다.

시험 영역별 Well-Architected 매핑

시험의 96%가 Well-Architected 기둥과 직접 매핑된다. Well-Architected Framework을 제대로 이해하면 SAA 시험의 기반이 완성된다.

---

11. 6가지 기둥 종합 비교

지금까지 다룬 6가지 기둥을 한 번에 정리하면 다음과 같다.

---

마치며: 프레임워크는 지도다

Well-Architected Framework은 "정답"이 아니라 "지도"다.

모든 서비스에 적용되는 만능 아키텍처는 존재하지 않는다. 스타트업의 MVP와 금융권의 핵심 서비스는 같은 프레임워크로 평가되지만, 각 기둥의 가중치는 완전히 다르다. 스타트업은 비용 최적화에 무게를 두고, 금융권은 보안과 안정성에 무게를 둔다.

중요한 것은 "이런 기둥들이 있고, 내 선택이 각 기둥에 어떤 영향을 미치는지 인지하는 것"이다.

처음부터 완벽한 아키텍처를 만들 필요는 없다. 하지만 Well-Architected의 6가지 렌즈를 알고 있으면, EC2 인스턴스 하나를 띄울 때도 "보안 그룹은 필요한 포트만 열었는가?", "Multi-AZ가 필요한가?", "On-Demand로 충분한가?"를 자연스럽게 생각하게 된다.

이것이 클라우드를 "쓰는" 것과 "제대로 쓰는" 것의 차이다.