이번 주 우리는 AWS 자격증의 가장 기초가 되는 클라우드 개념을 차근차근 쌓았다. 클라우드가 무엇인지(Day 1), 그것이 어디에 펼쳐져 있는지(Day 2), 보안 책임은 어떻게 나뉘는지(Day 3), 좋은 설계의 기준은 무엇인지(Day 4)를 배웠다. 오늘은 이 모든 조각을 하나의 큰 그림으로 다시 맞추며, 머릿속에 단단히 자리 잡게 한다.
클라우드 컴퓨팅은 인터넷을 통해 컴퓨팅 자원을 필요할 때 빌려 쓰고, 사용한 만큼만 비용을 내는 방식이다. 전기를 콘센트에서 쓰듯 서버를 빌려 쓴다.
AWS가 강조하는 6가지 이점을 다시 외워 둔다.
자본비용 → 가변비용 전환 (선투자 대신 쓴 만큼 지불)
대규모 규모의 경제 (많은 고객 덕분에 단가 하락)
용량 추정 불필요 (수요에 맞춰 조절)
속도와 민첩성 향상 (몇 분 만에 자원 확보)
데이터센터 운영비 절감 (전력·냉방·하드웨어 부담 제거)
몇 분 만에 전 세계 배포
6가지 이점의 바탕에는 "탄력성(수요에 따라 자동으로 늘고 줄음)"이 있다. 특히 ③ 용량 추정 불필요와 ④ 속도·민첩성이 탄력성 덕분에 가능하다.
여기서 자주 틀린다. ①과 ②를 헷갈리는 경우가 많다. ①은 지불 방식의 변화(미리 → 쓴 만큼), ②는 단가의 변화(AWS가 대량으로 사서 싸게 공급)다. 지문에 "선투자 없이"가 나오면 ①, "AWS의 대규모 구매력 덕분에"가 나오면 ②다.
⚠️ 함정: "클라우드는 항상 더 싸다"는 보기는 대부분 오답이다. 클라우드의 이점은 "싸다"가 아니라 "쓴 만큼만 낸다"이다. 24시간 꽉 채워 최대 성능으로 돌리는 워크로드는 온프레미스가 더 저렴할 수도 있다. 시험은 "총비용이 무조건 낮아진다" 같은 절대적 표현을 오답으로 자주 쓴다. "항상", "무제한", "완전 무료", "100%" 같은 단어가 보이면 일단 의심한다.
리전(Region) ← 세계 곳곳의 지리적 거점 (서울, 도쿄 등)
└ 가용 영역(AZ) ← 리전 안의 독립된 시설 (보통 3개 이상)
└ 데이터센터 ← AZ를 구성하는 물리 건물
여기에 엣지 로케이션(사용자 가까이서 콘텐츠를 캐싱·전달, CloudFront 등)이 더해진다.
서비스는 두 종류로 나뉜다.
리전 서비스(대부분): EC2, RDS, S3 등 — 리전을 골라 사용
글로벌 서비스(일부): IAM, Route 53, CloudFront — 전 세계 하나로 동작
고가용성 설계의 기본은 "2개 이상의 AZ에 나누어 배치"다. 한 AZ가 통째로 죽어도 다른 AZ에서 서비스가 살아남기 때문이다.
리전은 왜 나뉘어 있을까. 세 가지 이유로 정리하면 기억에 오래 남는다.
지연 시간: 사용자와 물리적으로 가까울수록 응답이 빠르다. 서울 사용자에게 서울 리전이 유리하다.
규정 준수: 어떤 나라·산업은 "데이터가 국경을 넘으면 안 된다"고 정해 두었다. 그래서 리전 선택은 법적 문제이기도 하다.
재해 격리: 한 지역에 대형 재해가 나도 다른 리전은 영향받지 않는다.
여기에 비용도 리전마다 다를 수 있다는 점, 모든 서비스가 모든 리전에 있는 것은 아니다라는 점까지 더하면 "리전을 고르는 기준" 문항은 거의 다 커버된다.
⚠️ 함정: AZ와 데이터센터를 같은 것으로 착각하는 실수가 가장 흔하다. AZ는 하나 이상의 데이터센터로 이뤄진 논리적 단위이며, 같은 리전 안의 다른 AZ와는 물리적으로 떨어져 있으면서도 빠른 네트워크로 연결돼 있다. 또 하나, 엣지 로케이션은 애플리케이션을 실행하는 곳이 아니다. 콘텐츠를 사용자 가까이에서 전달·캐싱하는 곳이다. "사용자에게 정적 콘텐츠를 빠르게 전달"이면 엣지, "서버를 어디에 둘까"면 리전이다.
핵심 한 문장: AWS는 "클라우드 자체(OF the cloud)", 고객은 "클라우드 안(IN the cloud)"의 보안을 책임진다.
AWS 책임
고객 책임
데이터센터, 하드웨어
데이터, 데이터 암호화
가상화(하이퍼바이저)
IAM 사용자·권한
글로벌 네트워크 인프라
게스트 OS 패치(EC2), 방화벽 설정, 앱 보안
그리고 경계선은 서비스에 따라 움직인다. EC2 → RDS → Lambda로 갈수록(더 관리형) 고객 책임은 줄지만, 데이터와 IAM 권한은 언제나 고객 몫이다.
"추상화 수준이 올라갈수록 고객 책임은 위로 좁아진다." 단, 데이터와 권한만큼은 어느 단계에서도 줄지 않는다 — 이 두 문장이 공동 책임 모델 문제의 만능 열쇠다.
공동 책임 모델을 아파트 임대에 비유하면 감이 온다. 건물 구조·엘리베이터·현관 출입 시스템은 건물주(AWS) 몫이다. 하지만 내 집 현관문을 잠그는 것, 비밀번호를 아무에게나 알려 주지 않는 것, 집 안의 귀중품을 관리하는 것은 세입자(고객) 몫이다. 건물이 아무리 튼튼해도 세입자가 문을 열어 두면 도둑이 든다.
실제 클라우드 보안 사고 중 상당수는 AWS 인프라가 뚫려서 생긴 것이 아니라, 고객이 저장소를 공개로 설정해 두어 아무나 데이터를 볼 수 있게 된 경우다. 이런 사고의 책임은 100% 고객 쪽이다. 시험에서 "데이터가 유출되었다. 누구의 책임인가?"류의 지문이 나오면, 원인이 설정·권한·데이터에 있는지 물리 인프라·하이퍼바이저에 있는지만 보면 답이 갈린다.
여기서 한 가지 더 챙길 것이 있다. Well-Architected와 이름이 비슷한 CAF(Cloud Adoption Framework)를 헷갈리지 않아야 한다. Well-Architected는 시스템 한 채를 잘 지었는지 보는 6개 기둥(Pillar)이고, CAF는 조직 전체가 어떻게 클라우드로 옮겨갈지 보는 6개 관점(Perspective, 비즈니스·사람·거버넌스·플랫폼·보안·운영)이다.
이번 주 내용에서 시험이 실제로 노리는 지점은 대부분 "비슷한데 다른 두 개념"이다. 아래 표가 Week 1의 알맹이다.
헷갈리는 짝
왼쪽
오른쪽
구분하는 한마디
리전 vs 가용 영역(AZ)
세계 곳곳의 지리적 거점
리전 안의 독립된 시설 묶음
리전이 큰 그릇, AZ가 그 안의 칸막이
가용 영역 vs 데이터센터
하나 이상의 DC로 이뤄진 논리 단위
AZ를 구성하는 물리 건물
AZ는 논리, DC는 건물
리전 서비스 vs 글로벌 서비스
EC2, RDS, S3 등 — 리전을 골라 씀
IAM, Route 53, CloudFront — 전 세계 하나
지문에 "리전을 선택"이 있으면 리전 서비스
엣지 로케이션 vs 리전
콘텐츠를 사용자 가까이 전달·캐싱
서비스를 실제로 실행
엣지는 배달, 리전은 주방
확장성 vs 탄력성
자원을 늘릴 수 있는 능력
수요에 맞춰 자동으로 늘고 줆
"자동"이라는 단어가 있으면 탄력성
자본비용 vs 가변비용
미리 크게 나가는 선투자
쓴 만큼 나가는 비용
클라우드는 자본비용 → 가변비용
고가용성 vs 재해 복구
장애가 나도 계속 동작
큰 사고 후 복구하는 계획
고가용성은 안 멈추게, 재해 복구는 되살리게
퍼블릭 vs 프라이빗 vs 하이브리드
여러 고객 공유
한 조직 전용
둘(또는 온프레미스)을 연결하면 하이브리드
IaaS vs PaaS vs SaaS
인프라만 빌림
실행 환경까지 빌림
완성된 소프트웨어까지면 SaaS
AWS 책임 vs 고객 책임
클라우드 자체(OF)
클라우드 안(IN)
데이터·권한은 언제나 고객
Well-Architected vs CAF
시스템 설계 점검(기둥 6개)
조직 전환 계획(관점 6개)
주어가 워크로드면 WA, 회사면 CAF
성능 효율성 vs 비용 최적화
속도·지연 시간이 걱정
청구서·낭비가 걱정
걱정의 대상이 시간인가 돈인가
함정: 확장성과 탄력성은 시험에서 뒤바뀌기 쉬운 짝이다. "자동으로", "수요에 따라", "필요 없을 땐 줄인다"가 보이면 탄력성(Elasticity)이다. 그냥 "더 큰 규모를 감당할 수 있다"면 확장성(Scalability)이다. 탄력성은 줄어드는 방향까지 포함한다는 점이 결정적 차이다.
지문의 사고 원인이 무엇인가?
├ 설정·권한·데이터·앱 코드 → 고객 책임 (IN the cloud)
└ 건물·하드웨어·가상화 계층 → AWS 책임 (OF the cloud)
※ 애매하면: "고객이 콘솔에서 바꿀 수 있는 것인가?"
바꿀 수 있으면 고객 책임이다.
흐름 2 — 어느 기둥인지 묻는다면
지문이 가장 걱정하는 것은?
├ 멈추는 것 → 안정성
├ 털리는 것 → 보안
├ 느린 것 → 성능 효율성
├ 돈 → 비용 최적화
├ 사람 손이 많이 감 → 운영 우수성
└ 환경 영향 → 지속 가능성
흐름 3 — 인프라 개념을 묻는다면
"어디에 둘까" → 리전 (지연·규정·비용·서비스 가용성)
"안 멈추게 하려면" → 여러 AZ에 분산
"빠르게 전달하려면" → 엣지 로케이션
"전 세계 하나로 동작하는가" → 글로벌 서비스(IAM, Route 53, CloudFront)
"국내 규제로 데이터를 해외에 둘 수 없는 금융사가, 서비스 중단이 허용되지 않는 시스템을 만들려 한다"는 지문을 본다. 조각을 하나씩 떼어 보면 답이 저절로 나온다. "데이터를 해외에 둘 수 없다" → 국내 리전 선택, "중단이 허용되지 않는다" → 그 리전 안의 여러 AZ에 분산, 그리고 이 설계 전체가 묻는 기둥은 안정성이다. 지문이 길어도 조각으로 쪼개면 각 조각은 이번 주에 배운 것 하나씩이다.
CLF-C02는 지식보다 함정 회피로 갈리는 경우가 많다. 이번 주 범위에서 반복되는 오답 유형은 다음과 같다.
오답 패턴
왜 틀렸나
"클라우드는 비용이 항상 저렴하다"
클라우드의 본질은 저렴함이 아니라 사용량 기반 과금이다
"AWS가 고객 데이터의 보안까지 전부 책임진다"
데이터와 권한은 언제나 고객 몫이다
"가용 영역 안에 리전이 있다"
포함 관계가 반대다. 리전 안에 AZ가 있다
"엣지 로케이션에서 애플리케이션을 실행한다"
엣지는 전달·캐싱이 역할이다
"규정 준수(Compliance)는 6대 기둥 중 하나다"
기둥이 아니다. 보안 기둥 안에서 다뤄진다
"확장성 = 자동으로 늘고 주는 것"
그건 탄력성이다
"하이브리드 = 여러 퍼블릭 클라우드를 함께 쓰는 것"
하이브리드는 퍼블릭 + 프라이빗/온프레미스 연결이다
함정: 보기 중 "모든", "항상", "전혀", "무제한", "완전 자동" 같은 절대적 표현이 들어간 것은 오답인 경우가 많다. 반대로 "~하는 경우에 적합하다", "~를 줄일 수 있다"처럼 조건을 단 표현이 정답인 경우가 많다. 물론 절대적 표현이 정답인 예외도 있다 — "데이터는 항상 고객 책임"처럼. 규칙이 아니라 의심 신호로 쓴다.
[무엇인가] 클라우드 = 빌려 쓰는 컴퓨팅 + 6가지 이점 (Day 1)
↓
[어디인가] 리전·AZ·엣지에 펼쳐진 글로벌 인프라 (Day 2)
↓
[누가 책임] AWS(OF) vs 고객(IN)의 공동 책임 모델 (Day 3)
↓
[어떻게 잘] Well-Architected 6대 기둥으로 좋은 설계 (Day 4)
즉 클라우드가 무엇인지 알고 → 그것이 펼쳐진 인프라 지도를 그리고 → 그 위에서 책임이 어떻게 나뉘는지 이해하고 → 마지막으로 "잘 만드는 기준"까지 갖추면, 클라우드 개념의 토대가 완성된다. 다음 주부터는 이 토대 위에 실제 AWS 서비스들을 하나씩 올려 본다.
이 네 조각이 서로를 어떻게 떠받치는지도 봐 둔다. 인프라(Day 2)를 모르면 안정성 설계(Day 4)를 이해할 수 없고, 책임 경계(Day 3)를 모르면 보안 기둥(Day 4)이 공허해진다. 다음 주에 배울 EC2·S3 같은 서비스도 결국 "이 서비스는 어느 리전에 있고, 어디까지가 내 책임이며, 어느 기둥을 만족시키는가"라는 세 질문으로 되돌아온다. 그래서 이번 주 내용은 시험 범위의 한 조각이 아니라 나머지 전부를 읽는 렌즈다.