개념에서 자주 갈리는 축은 확장성 vs 탄력성, 가용성 vs 내구성, 리전 vs AZ vs 엣지 셋이다.
서비스는 이름이 아니라 "어떤 상황이면 이것"이라는 조건을 외운다. 문항은 언제나 상황을 묘사한다.
스토리지 3형제(S3·EBS·EFS)와 DB 3형제(RDS·DynamoDB·Redshift)는 매 회차 나온다고 보고 준비하면 된다.
오늘의 목표는 읽는 것이 아니라 가리고 말해 보는 것(인출 연습)이다.
마지막 한 주가 시작됐다. 이번 주는 새로운 지식을 더 쌓기보다 이미 배운 것을 시험에서 꺼낼 수 있도록 정리하는 데 집중한다. 오늘은 CLF-C02 4개 시험 영역 중 비중이 가장 큰 두 영역인 Domain 1 (클라우드 개념, 24%) 과 Domain 3 (클라우드 기술 및 서비스, 34%) 을 한 번에 훑어본다.
지금부터는 새로 읽는 시간이 아니라 꺼내는 시간이다. 눈으로 훑으면 "안다"고 착각하기 쉽지만, 시험장에서 필요한 것은 아무것도 안 보이는 상태에서 끄집어내는 능력이다. 그래서 오늘 문서는 표가 많다. 표를 볼 때마다 오른쪽(정답 열)을 가리고, 왼쪽만 보고 소리 내어 답한 뒤, 막힌 항목만 표시해 원래 회차로 돌아가면 된다.
이렇게 답을 먼저 떠올린 뒤 확인하는 방식을 인출 연습(retrieval practice)이라고 한다. 같은 시간을 써도 여러 번 다시 읽는 것보다 기억에 오래 남는다. 시험이 요구하는 동작 자체가 '인출'이므로, 연습도 같은 동작으로 해야 효과가 크다.
이 여섯 가지가 왜 '이점'인지는 클라우드가 없던 시절을 떠올리면 바로 이해된다. 예전에는 사람이 몇 명 올지를 개발 전에 숫자로 정하고, 그에 맞춰 장비를 주문하고, 배송·설치·전력·냉방까지 준비한 뒤에야 코드를 올릴 수 있었다. 그런데 그 예측은 어차피 틀린다. 많이 사면 놀리는 장비에 돈이 묶이고, 적게 사면 사람이 몰리는 바로 그 순간에 서비스가 멈춘다. 클라우드는 "미리 맞힐 필요"를 없애서 이 딜레마를 지웠고, 나머지 이점은 대부분 여기서 파생된다.
개념 영역에서 실제로 점수가 갈리는 곳은 아래 네 짝이다. 이름이 비슷해서 대충 넘기기 쉬운데, 문항은 정확히 이 차이를 노린다.
짝
차이
한 줄 기억법
확장성(Scalability) vs 탄력성(Elasticity)
늘릴 수 있는가 vs 수요에 맞춰 자동으로 늘고 주는가
능력이냐, 자동이냐
고가용성(High Availability) vs 내결함성(Fault Tolerance)
장애가 나도 금방 회복 vs 장애가 나도 끊김 없이 계속
빨리 복구냐, 아예 안 멈추냐
가용성 vs 내구성(Durability)
지금 접근 가능한가 vs 데이터가 사라지지 않는가
열리느냐, 남아 있느냐
민첩성(Agility) vs 확장성
새로 시작하는 속도 vs 커지는 능력
빨리 해보기냐, 크게 키우기냐
⚠️ 함정: "수요가 늘면 서버를 추가한다"는 문장만 보고 무조건 탄력성을 고르면 위험하다. 사람이 손으로 추가한다면 그것은 확장성이다. 탄력성이라는 단어가 정답이 되려면 "자동으로", "수요에 따라 자동 조절" 같은 표현이 함께 있어야 한다. 반대로 "수동으로 크기를 조정할 수 있다"는 문장에 탄력성을 고르면 틀린다.
IaaS는 사용자가 OS까지 관리(EC2), PaaS는 코드만 관리(Elastic Beanstalk), SaaS는 사용만 함(즉시 사용 가능한 완제품). "운영체제를 직접 패치한다"는 키워드가 나오면 IaaS이다.
세 모델이 아직 손에 안 잡힌다면 식사 준비로 바꿔 생각해 보면 된다. 재료와 주방을 빌려 직접 요리하면 IaaS, 주방장이 있는 부엌에 레시피(코드)만 건네면 PaaS, 완성된 음식을 사 먹으면 SaaS이다. 위로 갈수록 편하지만 내가 손댈 수 있는 범위는 줄어든다. 문항이 "통제권을 최대한 갖고 싶다"고 하면 아래쪽(IaaS), "관리 부담을 최소화하고 싶다"고 하면 위쪽(PaaS/SaaS)이다.
가용 영역(AZ): 한 리전 안의 물리적으로 분리된 데이터센터 묶음. 고가용성의 기본 단위
엣지 로케이션(Edge Location): CloudFront 콘텐츠 캐싱 지점
셋의 관계는 포함 구조로 보면 한 번에 정리된다.
[ 리전 (예: 서울) ]
├── 가용 영역 A ← 물리적으로 떨어진 데이터센터 묶음
├── 가용 영역 B ← 여기에 나눠 배치 = 고가용성
└── 가용 영역 C
[ 엣지 로케이션 ] ← 리전 밖, 사용자와 가까운 곳에 다수
콘텐츠를 캐싱해 응답을 빠르게 (CloudFront)
그래서 문항이 무엇을 묻는지에 따라 답이 이렇게 갈린다.
문항이 요구하는 것
답
한 리전 안에서 장애에 견디는 구성
여러 가용 영역에 분산
재해 복구, 국가 단위 분산, 데이터 주권
여러 리전 사용
전 세계 사용자에게 콘텐츠를 빠르게
엣지 로케이션(CloudFront)
법적으로 데이터를 특정 국가 안에 둬야 함
리전 선택
⚠️ 함정: "지연 시간을 줄이고 싶다"는 표현 하나로 답이 결정되지 않는다. 정적 콘텐츠(이미지·영상·파일)를 전 세계에 빠르게 전달하는 것이면 엣지 로케이션(CloudFront)이지만, 사용자와 가까운 곳에서 애플리케이션 자체를 돌리고 싶다면 그 지역의 리전을 고르는 것이 답이다. 또한 엣지 로케이션은 캐싱 지점일 뿐 가용 영역을 대신하는 고가용성 수단이 아니다.
컴퓨팅은 "내가 어디까지 관리할 것인가" 하나의 사다리로 보면 외울 것이 확 줄어든다. 관리할 것이 많은 쪽부터 EC2(OS까지 내가) → ECS/EKS(컨테이너 관리) → Fargate(서버 없음) → Lambda(코드만) 순이다.
상황 묘사
답
OS를 직접 골라 패치하고 소프트웨어를 설치해야 한다
EC2
이벤트가 올 때만 잠깐 실행되는 짧은 코드
Lambda
코드만 올리면 알아서 인프라를 구성해 주면 좋겠다
Elastic Beanstalk
컨테이너로 만든 앱을 여러 대에 걸쳐 돌리고 싶다
ECS 또는 EKS
컨테이너는 쓰고 싶지만 서버는 관리하기 싫다
Fargate
이미 쿠버네티스를 쓰고 있어 그대로 옮기고 싶다
EKS
함정: "서버리스"라는 단어를 보면 무조건 Lambda를 고르는 실수가 잦다. AWS에서 서버리스는 Lambda만의 성질이 아니다. Fargate(컨테이너), DynamoDB(데이터베이스), S3(스토리지)도 사용자가 서버를 관리하지 않는다. 문항이 "컨테이너"를 함께 말하면 Fargate, "NoSQL 데이터베이스"를 말하면 DynamoDB 쪽으로 갈라야 한다.
사진 공유 서비스를 만든다고 가정한다. 사용자가 올린 사진은 제한 없이 쌓이고 웹에서 바로 내려받아야 하니 S3에 둔다. 사진을 처리하는 EC2에는 OS와 프로그램이 깔린 디스크가 필요하니 EBS가 붙는다. 처리 서버를 여러 대로 늘렸는데 모두 같은 작업 폴더를 봐야 한다면 EFS를 붙인다. 3년이 지나 아무도 안 보는 원본은 S3 Glacier로 옮긴다. 한 서비스 안에서 넷이 각자 다른 자리를 맡는다는 점이 핵심이다.
함정: "여러 서버가 같은 데이터를 봐야 한다"에 반사적으로 EBS를 고르면 틀린다. 여러 EC2가 동시에 마운트해 공유하는 요구는 EFS이다. 또 인스턴스 스토어는 EC2에 붙은 임시 디스크라 중지하면 데이터가 사라진다. "영구 보관" 문항에서는 오답이다.
네트워킹도 도시 비유로 잡아 두면 편하다. VPC는 내가 분양받은 부지에 친 담장이고, Route 53은 주소를 알려주는 전화번호부이며, CloudFront는 동네마다 둔 물류 거점, Direct Connect는 우리 회사와 AWS를 잇는 전용 도로다. 인터넷이라는 공용 도로를 쓰지 않고 따로 낸 길이라 속도와 대역폭이 안정적이다.
여기에 ELB와 Auto Scaling이 자주 함께 나온다. 이름이 비슷해 보이지만 하는 일이 다르다. ELB는 들어온 요청을 여러 서버에 나눠 주는 은행 창구 안내원이고, Auto Scaling은 손님이 몰리면 창구를 더 여는 지점장이다.
둘은 경쟁 관계가 아니라 짝이다. Auto Scaling이 대수를 조절하고 ELB가 그 대수에 맞춰 요청을 배분해야 비로소 "수요에 따라 자동으로 늘고 주는" 탄력성이 완성된다. 문항이 "요청을 고르게 분산"이면 ELB, "부하에 따라 인스턴스 수를 자동 조절"이면 Auto Scaling으로 갈라 읽으면 된다.
"관계형 + 관리형"이면 RDS, "NoSQL + 서버리스"면 DynamoDB, "대규모 분석/웨어하우스"면 Redshift이다. 이 세 가지 매핑만 확실해도 DB 문제 다수를 맞출 수 있다.
데이터베이스도 상황 묘사로 갈라 두면 훨씬 빨리 답이 나온다.
상황 묘사
답
표와 관계, SQL, 기존 MySQL·PostgreSQL을 옮김
RDS
같은 관계형인데 더 높은 성능이 필요
Aurora
키-값, 스키마가 유연함, 서버 관리 없음, 대규모 트래픽
DynamoDB
수년치 데이터를 모아 리포트·분석 쿼리
Redshift
같은 조회가 반복돼 응답을 빠르게 하고 싶음
ElastiCache
함정: 관계형과 비관계형의 구분을 "무엇을 저장하느냐"로 외우면 흔들린다. 기준은 구조다. 행과 열이 정해져 있고 표끼리 관계를 맺으면 관계형(RDS·Aurora), 항목마다 담기는 속성이 달라도 되는 유연한 구조면 NoSQL(DynamoDB)이다. 또한 ElastiCache는 데이터베이스를 대체하는 것이 아니라 앞에 두는 캐시다. "원본 데이터를 보관"하는 용도로 고르면 오답이다.