Day 4 - Well-Architected Framework 6대 기둥과 클라우드 채택 가치

지금까지 클라우드가 무엇이고(Day 1), 어디에 펼쳐져 있으며(Day 2), 책임이 어떻게 나뉘는지(Day 3)를 배웠다. 그렇다면 "좋은 클라우드 설계"란 무엇일까? AWS는 수많은 고객 경험을 모아 그 답을 Well-Architected Framework(잘 설계된 프레임워크)라는 6개의 기둥(Pillar)으로 정리했다. 오늘은 이 6대 기둥의 개요와, 기업이 클라우드를 채택할 때 얻는 가치를 입문자 눈높이로 살펴본다.

Well-Architected Framework란

Well-Architected Framework는 "클라우드에서 안정적이고 안전하며 효율적인 시스템을 만들려면 무엇을 신경 써야 하는가"를 정리한 모범 설계 지침이다. 시험 문제 하나하나가 사실은 이 6대 기둥 중 어느 하나를 묻는 경우가 많아서, 기둥의 이름과 의미를 잡아 두면 답이 보인다.

왜 이런 게 생겼을까

클라우드를 처음 쓰는 사람은 대개 "일단 돌아가게" 만든다. 서버 하나 띄우고, 데이터베이스 붙이고, 도메인 연결하면 서비스가 열린다. 문제는 그 다음이다.

그 서버가 있는 건물에 정전이 나면 서비스 전체가 멈춘다. 관리자 계정 비밀번호가 유출되면 모든 데이터가 털린다. 트래픽이 10배가 되면 응답이 느려지다 죽는다. 몇 달 뒤 청구서가 예상보다 훨씬 크게 나오면 프로젝트 자체가 중단된다.

이런 사고는 새로운 종류의 사고가 아니다. 수많은 회사가 이미 똑같은 방식으로 넘어졌다. AWS는 고객 시스템을 검토해 주는 과정에서 "넘어지는 방식이 몇 가지로 반복된다"는 것을 발견했고, 그 패턴을 여섯 갈래로 묶어 문서로 만든 것이 Well-Architected Framework다.

Well-Architected Framework를 건축 안전 점검표라고 생각하면 쉽다. 집을 지을 때 "지진에 견디는가(안정성), 도둑이 못 들어오는가(보안), 난방비가 적정한가(비용), 관리인이 상태를 파악할 수 있는가(운영)"를 항목별로 확인하듯, 클라우드 시스템도 여섯 가지 관점에서 점검한다. 이 프레임워크는 "이렇게 만들어라"는 강제 규칙이 아니라 "이걸 확인했는지 물어보는 질문 목록"에 가깝다.

각 기둥은 설계 원칙(지향할 방향, 예: "장애를 자동으로 복구하라"), 모범 사례(실제로 할 일, 예: "여러 AZ에 나눠 배치하라"), 핵심 질문(내 시스템이 그런지 묻는 질문, 예: "한 AZ가 죽으면 어떻게 되는가?")으로 구성된다. AWS는 이 질문들을 자동으로 던져 주고 답을 기록하는 AWS Well-Architected Tool도 콘솔에서 제공한다. 시험 입문 수준에서는 "그런 점검 도구가 있다" 정도만 알면 충분하다.

어떤 스타트업이 서비스를 EC2 서버 한 대에 올려 운영하고 있었다. 잘 돌아갔고 비용도 저렴했다. 그런데 어느 날 그 서버가 있는 시설에 문제가 생겨 몇 시간 동안 서비스가 멈췄고, 그 사이 결제 데이터 일부가 유실됐다. 사고 후 팀이 점검해 보니 백업도, 다른 AZ의 예비 서버도, 장애를 알려 주는 알림도 없었다. 여섯 기둥 중 안정성과 운영 우수성을 통째로 비워 둔 설계였던 것이다. Well-Architected Framework는 이런 "비어 있는 칸"을 사고가 나기 전에 발견하게 해 준다.

6대 기둥 한눈에 보기

머리글자를 모으면 O-S-R-P-C-S. ⑥ Sustainability는 2021년에 추가되어 6번째 기둥이 되었다. 외우는 것보다 "이 시나리오가 어느 기둥을 묻는가?"를 떠올리는 연습이 더 중요하다.

안 지키면 무슨 일이 벌어지나

기둥의 정의를 외우는 것보다, 그 기둥을 비워 뒀을 때 벌어지는 일을 그려 보는 편이 훨씬 오래 남는다.

이 표를 거꾸로 읽으면 그대로 시험 시나리오가 된다.

각 기둥을 쉽게 풀어보기

① Operational Excellence(운영 우수성)는 시스템을 잘 굴리고 꾸준히 나아지게 만드는 것이다. 사람이 손으로 반복하는 일을 자동화하고, 무슨 일이 일어나는지 잘 관찰(모니터링)하며, 작은 변경을 자주 안전하게 반영하는 것이 여기에 속한다.

식당에 비유하면 "주방이 잘 돌아가게 만드는 일"이다. 재료가 떨어지기 전에 알림이 오고, 조리 순서가 매뉴얼로 정리돼 있고, 실수가 나면 원인을 기록해 다음에 안 겪게 만드는 것. 대표적인 지향점은 운영 작업을 코드로 수행하기(콘솔에서 손으로 클릭하지 않기), 변경을 작게·자주·되돌릴 수 있게 하기, 장애 대응을 미리 연습하기, 사고에서 배워 문서를 갱신하기다.

② Security(보안)는 데이터·시스템·자산을 보호하는 것이다. 꼭 필요한 권한만 주는 최소 권한 원칙, 데이터 암호화, 모든 계층에서의 보안 적용, 사고 대비가 핵심이다.

여기서 자주 인용되는 원칙 몇 가지를 알아둔다.

• 최소 권한(Least Privilege): 필요한 만큼만, 필요한 기간만 권한을 준다. 출입증에 비유하면 "전 층 마스터키"가 아니라 "내 사무실 층만 열리는 카드"다.
• 심층 방어(Defense in Depth): 한 겹만 믿지 않고 여러 겹으로 막는다. 성문 하나가 아니라 해자·성벽·내성을 겹치는 식이다.
• 전송 중·저장 중 암호화, 추적 가능성(누가 언제 무엇을 했는지 기록이 남아야 한다), 사고 대비(사고가 "나면"이 아니라 "날 때"를 가정한다).

③ Reliability(안정성)는 장애가 나도 서비스가 멈추지 않고, 멈춰도 빠르게 회복되는 능력이다. 여러 가용 영역(AZ)에 나누어 배치하고, 자동 복구·백업을 갖추는 것이 대표적이다(Day 2의 멀티 AZ 설계를 떠올린다).

안정성의 사고방식은 "고장은 반드시 난다"를 전제로 깔고 시작한다는 점이 특징이다. 고장을 없애려 애쓰는 게 아니라, 고장이 나도 사용자가 눈치채지 못하게 만드는 것이 목표다. 그래서 자동 복구(새벽에 사람이 일어나 고치는 구조를 피한다), 복구 절차의 실제 테스트(백업은 복원해 본 적이 있어야 백업이다), 수평 확장(하나의 큰 자원에 서비스 전체를 걸지 않는다), 수요에 맞춘 용량 조절을 강조한다.

④ Performance Efficiency(성능 효율성)는 자원을 낭비 없이 효율적으로 써서 필요한 성능을 내는 것이다. 작업에 딱 맞는 크기의 자원을 고르고(right-sizing), 필요할 때 적절한 기술을 쓰는 것이다.

"빠르게 만드는 것"만이 아니라 "필요한 만큼의 성능을 가장 적은 자원으로 내는 것"이 핵심이다. 사용자와 가까운 곳에 서비스를 배치해 응답 시간을 줄이거나, 무거운 기능을 직접 만들지 않고 이미 있는 관리형 서비스에 맡기는 것도 이 기둥에 들어간다.

⚠️ 함정: 성능 효율성과 비용 최적화를 같은 것으로 착각하기 쉽다. 둘 다 "자원을 알맞게 쓰자"고 말하지만 묻는 목적이 다르다. 지문이 응답 속도·지연 시간·사용자 경험을 걱정하면 성능 효율성, 청구서·지출·낭비되는 자원을 걱정하면 비용 최적화다.

⑤ Cost Optimization(비용 최적화)는 같은 일을 더 적은 비용으로 하는 것이다. 안 쓰는 자원을 끄고, 사용량에 맞는 가격 모델을 고르며, 비용을 측정·관리하는 것이 여기에 들어간다.

이 기둥에서 특히 강조되는 것은 "누가 얼마를 쓰는지 보이게 만드는 것"이다. 부서별·프로젝트별로 비용이 나뉘어 보이지 않으면 아무도 줄이려 하지 않는다. 그래서 사용량을 측정해 팀별로 귀속시키고, 쓰지 않는 자원을 찾아내 끄고(개발·테스트 환경은 업무 시간 외에 꺼도 되는 경우가 많다), 직접 운영 대신 관리형 서비스로 사람의 운영 비용까지 줄이며, 사용 패턴에 맞는 가격 모델을 고르는 것이 모두 여기에 들어간다.

⑥ Sustainability(지속 가능성)는 클라우드 사용이 환경에 주는 영향을 줄이는 것이다. 에너지를 덜 쓰는 효율적인 설계, 적절한 리전 선택 등이 해당한다.

가장 최근에 추가된 기둥이라 낯설지만 사고방식은 단순하다. "덜 쓰면 덜 배출한다." 필요 없는 자원을 끄고, 같은 결과를 더 적은 연산으로 내고, 오래된 데이터는 저렴하고 효율적인 저장소로 옮기는 것이 모두 여기에 들어간다. 비용 최적화와 방향이 겹치는 경우가 많은데, 판단 기준이 "돈"이면 비용 최적화, "환경 영향·탄소·에너지"면 지속 가능성이라고 구분하면 된다.

6대 기둥은 서로 트레이드오프(trade-off) 관계일 수 있다. 예를 들어 안정성을 높이려 자원을 여러 AZ에 늘리면 비용이 올라간다. Well-Architected Framework의 목적은 "정답 하나"를 주는 게 아니라, 이런 균형을 의식적으로 고민하게 만드는 것이다.

6대 기둥은 시스템이 넘어지는 여섯 가지 방식을 뒤집은 것이다. 정의를 외우기보다 "이 기둥을 안 지키면 무슨 일이 나는가"로 기억한다.

기둥끼리 부딪칠 때 어떻게 판단하나

현실의 설계는 여섯 기둥을 모두 100점으로 만들 수 없다. 하나를 올리면 다른 하나가 내려간다.

핵심 태도는 "무엇을 포기했는지 알고 포기하는 것"이다. 비용을 아끼려 단일 AZ에 두는 결정 자체는 틀리지 않다 — 내부용 도구라면 합리적일 수 있다. 문제는 그 선택을 의식하지 못한 채 하는 것이다.

⚠️ 함정: 시험에서 "가장 비용 효율적인 방법은?"과 "가장 안정적인 방법은?"은 정반대의 답을 요구한다. 지문에 조건이 여러 개 붙어 있을 때는 마지막 문장에 오는 요구가 대개 채점 기준이다. "예산이 빠듯한 스타트업이지만 서비스 중단은 절대 안 된다"면 답은 비용이 아니라 안정성 쪽이다. 지문의 형용사가 아니라 요구사항 문장을 본다.

기둥은 서로 충돌하므로, 지문의 요구사항 문장이 어느 기둥을 우선하라는지 찾는 것이 곧 정답 찾기다.

시나리오 → 기둥 매핑 연습

시험에서 가장 쓸모 있는 기술은 시나리오를 보고 어느 기둥을 묻는지 알아채는 것이다.

키워드를 조금 더 늘려 본다. 시험 지문은 아래 표현을 자주 쓴다.

함정: "모니터링"이라는 단어가 나왔다고 무조건 운영 우수성은 아니다. 비용을 모니터링하면 비용 최적화, 보안 이벤트를 모니터링하면 보안이다. 단어 하나가 아니라 그 단어가 무엇을 향하고 있는지를 봐야 한다. 이것이 CLF-C02에서 기둥 문항을 틀리는 가장 흔한 이유다.

클라우드 채택의 가치

기업이 클라우드를 도입하면 단순히 "서버를 빌리는 것" 이상의 가치를 얻는다. Day 1의 6가지 이점과도 이어진다.

• 민첩성(Agility): 새 아이디어를 며칠이 아니라 몇 분 만에 실험하고 출시한다.
• 비용 효율: 미리 큰돈을 들이지 않고 쓴 만큼만 낸다(자본비용 → 가변비용).
• 확장성·탄력성: 사용자가 늘면 자동으로 자원을 늘리고, 줄면 줄인다.
• 글로벌 도달: 클릭 몇 번으로 전 세계 사용자에게 서비스한다.
• 핵심 사업 집중: 데이터센터 운영 같은 부담을 덜고 본업에 집중한다.

이 다섯 가지는 서로 떨어져 있지 않고 하나의 사건에서 함께 나타난다.

계절 상품을 파는 온라인 쇼핑몰을 떠올려 본다. 평소 트래픽은 잔잔하지만 특정 시즌 한 주 동안 수십 배가 몰린다. 온프레미스 시절이라면 그 한 주를 위해 1년 내내 놀 장비를 사둬야 했다. 클라우드에서는 그 기간에만 자원을 늘렸다가 끝나면 줄인다. 여기서 작동한 가치가 탄력성이자 비용 효율이고, 아낀 돈으로 새 기능을 만들었다면 그건 민첩성이다.

AWS는 기업이 클라우드로 옮겨갈 때 길잡이가 되는 Cloud Adoption Framework(CAF)도 제공한다. CAF는 비즈니스·사람·거버넌스·플랫폼·보안·운영 같은 관점에서 무엇을 준비해야 하는지를 정리한 것으로, "어떻게 클라우드로 전환할까"의 큰 그림을 그려 준다.

CAF: 조직이 클라우드로 옮겨가는 지도

Well-Architected가 시스템 한 채를 잘 짓는 법이라면, CAF는 회사 전체가 이사하는 계획표다. 클라우드 전환이 실패하는 이유는 대개 기술이 아니라 사람·조직·절차 쪽에 있기 때문에, AWS는 이를 6가지 관점(Perspective)으로 정리했다.

앞의 셋(비즈니스·사람·거버넌스)은 경영·조직, 뒤의 셋(플랫폼·보안·운영)은 기술에 가깝다. 앞3/뒤3으로 나눠 기억하면 헷갈리지 않는다. CAF는 전환을 한 번에 하라고 말하지 않고 구상(Envision) → 정렬(Align) → 시작(Launch) → 확장(Scale) 단계를 밟으며 작은 성공을 먼저 만들고 넓히는 방식을 권한다.

Well-Architected vs CAF — 헷갈리면 이 표

함정: 두 프레임워크 모두 "보안"과 "운영"이라는 단어가 들어 있어서 헷갈린다. 구분의 열쇠는 주어다. 지문의 주어가 "이 아키텍처/워크로드"면 Well-Architected, "이 회사/조직이 클라우드로 이전하면서"면 CAF다. 또 "기둥(pillar)"이라는 단어가 보이면 Well-Architected, "관점(perspective)"이 보이면 CAF다.

Well-Architected는 시스템을, CAF는 조직을 대상으로 한다. 주어가 워크로드인지 회사인지만 보면 둘은 헷갈리지 않는다.

다음 글에서는 Week 1에서 배운 클라우드 개념 전체를 한 번에 복습한다.

📖 용어

• Well-Architected Framework : 클라우드 시스템을 잘 만들었는지 6가지 기둥(Pillar)으로 점검하는 AWS의 설계 지침.
• 트레이드오프(trade-off) : 하나를 얻으려면 다른 하나를 내줘야 하는 관계. 안정성↑ → 비용↑ 같은 것.
• 최소 권한 원칙 : 꼭 필요한 권한만, 필요한 기간만 부여하는 보안 원칙.
• 심층 방어(Defense in Depth) : 보안 장치를 한 겹이 아니라 여러 겹으로 쌓는 방식.
• right-sizing : 작업에 딱 맞는 크기의 자원을 고르는 것. 과하면 낭비, 모자라면 성능 저하.
• CAF(Cloud Adoption Framework) : 조직의 클라우드 전환 준비 사항을 6가지 관점(Perspective)으로 정리한 AWS의 지침.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

Well-Architected Framework의 6대 기둥에 해당하지 않는 것은?

• A안정성(Reliability)
• B보안(Security)
• C규정 준수(Compliance)
• D비용 최적화(Cost Optimization)

문제 2

"한 가용 영역(AZ)에 장애가 나도 서비스가 계속 동작해야 한다"는 요구는 주로 어떤 기둥과 관련되는가?

• A비용 최적화(Cost Optimization)
• B안정성(Reliability)
• C지속 가능성(Sustainability)
• D운영 우수성(Operational Excellence)

문제 3

"사용하지 않는 야간 시간에는 자원을 꺼서 지출을 줄인다"는 접근은 어떤 기둥에 해당하는가?

• A보안(Security)
• B성능 효율성(Performance Efficiency)
• C비용 최적화(Cost Optimization)
• D안정성(Reliability)

문제 4

2021년에 Well-Architected Framework에 새로 추가되어 6번째가 된 기둥은?

• A지속 가능성(Sustainability)
• B보안(Security)
• C안정성(Reliability)
• D운영 우수성(Operational Excellence)

문제 5

기업이 클라우드를 채택할 때 얻는 가치로 보기 어려운 것은?

• A아이디어를 빠르게 실험하고 출시하는 민첩성
• B사용량에 따라 자원을 늘리고 줄이는 탄력성
• C데이터센터를 직접 짓고 운영해야 하는 부담 증가
• D클릭 몇 번으로 전 세계에 서비스하는 글로벌 도달