안녕하세요, 비즈니스 혁신 파트너 BSG입니다.

클라우드를 도입한 기업들이 어느 시점에 반드시 마주치는 질문이 있습니다.
"우리 AWS 구조, 이게 맞게 짜인 걸까요?"
서비스는 돌아가고 있고, 데이터도 쌓이고 있습니다. 하지만 왠지 불안합니다. 
비용이 예상보다 많이 나오고, 장애가 생기면 복구에 시간이 걸리고, 보안 점검을 받으면 지적사항이 나옵니다.

이 질문에 AWS가 공식적으로 내놓은 답이 바로 Well-Architected Framework입니다.

Well-Architected Framework란?

AWS Well-Architected Framework는 클라우드 아키텍처를 올바르게 설계하고 운영하기 위한 AWS 공식 기준서입니다.
수천 개의 고객사 아키텍처를 검토하면서 반복적으로 등장했던 실패 패턴과 성공 원칙을 AWS가 정리했습니다. 
단순한 권고안이 아니라, 실제 운영 현장에서 검증된 설계 철학입니다.이 Framework는 5가지 원칙(Pillar) 으로 구성되어 있습니다.

1. 운영 우수성 (Operational Excellence)
2. 보안 (Security)
3. 안정성 (Reliability)
4. 성능 효율성 (Performance Efficiency)
5. 비용 최적화 (Cost Optimization)

하나씩 살펴보겠습니다.

1. 운영 우수성 (Operational Excellence)

핵심 질문: "우리는 시스템을 얼마나 잘 운영하고 있는가?"
운영 우수성은 단순히 시스템이 돌아가는 것을 넘어, 지속적으로 개선되는 운영 구조를 만드는 것을 의미합니다.

현장에서 자주 보이는 문제는 이렇습니다.

• 배포할 때마다 담당자가 수동으로 작업한다
• 장애가 나면 원인 파악에 시간이 오래 걸린다
• 운영 기준이 문서화되어 있지 않아 담당자가 바뀌면 혼란이 생긴다

Well-Architected는 이 문제를 해결하기 위해 세 가지를 강조합니다.

코드로 운영하라 : 인프라 설정, 배포 과정, 운영 절차 모두를 코드로 관리합니다. 사람이 직접 클릭하는 수작업 운영은 실수를 만들고, 기록이 남지 않습니다.
작게, 자주 변경하라 : 한 번에 큰 변경을 하면 문제가 생겼을 때 원인을 찾기 어렵습니다. 작은 단위로 자주 배포하면 문제 발생 시 빠르게 원인을 찾고 되돌릴 수 있습니다.
실패를 예상하고 준비하라 : 장애는 반드시 발생합니다. 중요한 건 장애가 나지 않는 것이 아니라, 장애가 났을 때 얼마나 빠르게 복구하느냐입니다.

2. 보안 (Security)

핵심 질문: "우리 시스템은 누가 무엇을 할 수 있는지 정확히 통제하고 있는가?"

클라우드 보안에서 가장 흔한 실수는 "일단 만들고, 나중에 보안 설정하자" 는 접근입니다.
Well-Architected는 보안을 설계 단계부터 내재화할 것을 요구합니다.

최소 권한 원칙 
모든 사람, 모든 시스템은 자신이 꼭 필요한 권한만 가져야 합니다.
AWS IAM에서 "일단 Admin 권한 주고 나중에 줄이자"는 방식은 보안 사고의 시작입니다.
모든 계층에서 보안 적용 네트워크만 막는다고 보안이 완성되지 않습니다. 
애플리케이션, 데이터, 인프라 각 계층마다 독립적으로 보안이 적용되어야 합니다. 
하나가 뚫려도 나머지가 방어선이 됩니다.

추적 가능성 확보 
누가, 언제, 무엇을 했는지 모든 행동이 로그로 남아야 합니다. 
보안 사고는 사후 분석이 중요합니다. 
AWS CloudTrail, CloudWatch Logs가 이 역할을 합니다.
데이터 보호 저장 중인 데이터와 전송 중인 데이터 모두 암호화합니다. 
S3, RDS, EBS 모두 암호화 옵션이 있으며, 기본값으로 켜두는 것이 권장됩니다.

3. 안정성 (Reliability)

핵심 질문: "장애가 나도 서비스는 계속 돌아가는가?"

안정성은 단순히 서버가 안 꺼지는 것이 아닙니다.
장애 상황에서도 서비스가 정상적으로 기능을 유지하는 능력입니다.
지난 글에서 다룬 리전(Region)과 가용 영역(AZ) 개념이 여기서 핵심이 됩니다.

자동 복구 설계 서버 하나가 죽었을 때 사람이 개입하지 않아도 자동으로 새 서버가 뜨는 구조가 필요합니다. AWS Auto Scaling, Elastic Load Balancer가 이 역할을 합니다.
수평 확장 설계 서버 하나를 크게 키우는 것(Scale Up)보다 서버를 여러 대로 늘리는 것(Scale Out)이 안정적입니다. 하나가 죽어도 나머지가 트래픽을 받습니다.
복구 절차 테스트 백업이 있다는 것과 백업으로 실제 복구가 된다는 것은 다릅니다. 정기적으로 복구 훈련을 해야 실제 장애 상황에서 당황하지 않습니다.
변화 관리 예상치 못한 변화가 장애의 원인이 되는 경우가 많습니다. 모든 변경은 계획하고, 검토하고, 기록해야 합니다.

4. 성능 효율성 (Performance Efficiency)

핵심 질문: "우리는 필요한 성능을 가장 효율적인 방식으로 내고 있는가?"

클라우드의 장점은 필요할 때 필요한 만큼 자원을 쓸 수 있다는 것입니다. 하지만 많은 기업이 온프레미스(On-premise) 시절의 사고방식 그대로 클라우드를 씁니다.
"혹시 모르니까 크게 잡아두자."
이 접근은 성능 문제를 해결하지도 못하면서 비용만 올립니다.

올바른 서비스 선택 컴퓨팅, 스토리지, 데이터베이스, 네트워킹 각각에서 워크로드 특성에 맞는 서비스를 골라야 합니다. 
모든 데이터베이스를 RDS로 해결하려 하면 안 됩니다. 시계열 데이터, 캐시, 검색 등 용도에 맞는 서비스가 따로 있습니다.
글로벌 분산 사용자가 전 세계에 있다면 데이터를 사용자 가까운 곳에 두어야 응답 속도가 빠릅니다. CloudFront 같은 CDN이 이 역할을 합니다.
실험과 측정 성능 개선은 감이 아니라 데이터로 해야 합니다. 변경 전후를 측정하고, 더 나은 방향으로 계속 조정합니다.

5. 비용 최적화 (Cost Optimization)

핵심 질문: "우리는 필요한 것에만 돈을 쓰고 있는가?"

클라우드 비용은 방치하면 반드시 늘어납니다. 
개발 환경인데 24시간 켜져 있고, 쓰지 않는 스냅샷이 쌓이고, 이미 서비스가 종료된 리소스가 남아있는 경우가 현장에서 매우 흔합니다.

사용량 기반 지불 필요할 때만 켜고, 끝나면 끄는 구조를 만들어야 합니다. Lambda처럼 쓴 만큼만 과금되는 서버리스 서비스가 이 원칙에 가장 잘 맞습니다.
예약 및 절약 플랜 활용 장기간 안정적으로 사용하는 워크로드는 On-Demand 대신 Reserved Instance나 Savings Plans를 사용하면 최대 72%까지 비용을 낮출 수 있습니다.
지출 추적과 책임 부여 누가 얼마를 쓰는지 팀/프로젝트별로 비용을 추적해야 합니다. AWS Cost Explorer와 태그(Tag) 정책이 이를 가능하게 합니다.
불필요한 리소스 제거 정기적으로 사용하지 않는 리소스를 점검하고 정리합니다. 이것만으로도 비용의 10~20%를 줄이는 경우가 많습니다.

경영진이 알아야 할 한 가지

Well-Architected Framework는 기술팀만의 이야기가 아닙니다.

이 5가지 원칙은 결국 비즈니스 언어로 번역됩니다.

클라우드 투자 대비 성과가 기대에 미치지 못한다면, 이 5가지 중 어딘가에 구조적 문제가 있는 경우가 대부분입니다.

BSG는 AWS Advanced Tier 파트너로서 Well-Architected Review를 포함한 클라우드 아키텍처 설계 및 최적화를 지원합니다. → 문의하러 바로가기 →

출처 : AWS 공식 문서: https://aws.amazon.com/architecture/well-architected/
기획 : 도예원