기준: CLF-C02 시험 가이드오류 제보
지난주가 "서버·스토리지·네트워크"라는 뼈대였다면, 이번 주는 그 위에서 데이터를 다루고 서비스끼리 소통시키며 전체를 감시·자동화하는 "운영 계층"을 배웠다. 데이터베이스, 애플리케이션 통합(메시징), 관리·모니터링 도구, 그리고 인프라를 코드로 만드는 IaC까지. 오늘은 새 개념 없이 이 조각들을 비교표와 선택 기준으로 묶어 복습한다.
핵심은 여전히 "언제 무엇을 고르는가"다. 데이터의 모양, 통신의 형태, 보고 싶은 정보의 종류에 따라 답이 갈린다.
이 글은 처음부터 끝까지 읽는 글이라기보다 틀리기 쉬운 곳을 찾아내는 점검표에 가깝다. 아래 지도를 보며 이름만으로 한 줄 정의가 떠오르는지 확인하고, 애매한 짝을 표시해 둔 뒤, 마지막 "이 상황엔 이 서비스" 표를 답을 가리고 풀어 보면 된다.
CLF-C02가 묻는 방식은 일관적이다. 내부 구조나 설정법이 아니라 "이런 상황이 있다. 무엇을 쓰겠는가"를 묻는다. 그래서 외울 것은 정의문이 아니라 "이 서비스가 해결하려고 태어난 상황"이다.
| 원래의 불편 | 태어난 서비스 |
|---|---|
| DB 서버를 직접 설치·백업·패치하기 힘들다 | RDS / Aurora |
| 관계형 DB로는 초당 수만 건 조회를 감당하기 어렵다 | DynamoDB |
| 수년치 데이터를 집계하면 운영 DB가 멈춘다 | Redshift |
| 요청이 몰리면 뒷단 서비스가 무너진다 | SQS |
| 한 사건을 여러 시스템에 일일이 알려야 한다 | SNS |
| 장애를 고객이 먼저 알려준다 | CloudWatch |
| 누가 설정을 바꿨는지 아무도 모른다 | CloudTrail |
| 규칙 위반 리소스를 손으로 센다 | Config |
| 같은 환경을 두 번 만들면 매번 달라진다 | CloudFormation |
| 분류 | 대표 서비스 | 한 줄 정의 |
|---|---|---|
| 데이터베이스 | RDS | 관리형 관계형 DB(SQL) |
| 데이터베이스 | Aurora | RDS 호환 고성능 클라우드 DB |
| 데이터베이스 | DynamoDB | 관리형 NoSQL(키-값/문서) |
| 데이터베이스 | Redshift | 데이터 웨어하우스(분석용) |
| 통합 | SQS | 메시지 큐(비동기 대기열) |
| 통합 | SNS | 발행/구독 알림(팬아웃) |
| 통합 | EventBridge | 이벤트 버스(서비스 간 연결) |
| 관리 | CloudWatch | 지표·로그·경보(모니터링) |
| 관리 | CloudTrail | API 호출 감사 기록(누가 무엇을) |
| 관리 | Config | 리소스 구성 변경 추적·규정 준수 |
| IaC | CloudFormation | 인프라를 코드(템플릿)로 정의·배포 |
| 배포 | Elastic Beanstalk | 코드만 올리면 실행 환경 자동 구성 |
| 컨테이너 | ECS / EKS | AWS 방식 / 표준 Kubernetes 오케스트레이션 |
| 컨테이너 | Fargate | 노드 관리 없이 컨테이너만 실행 |
| 서버리스 | Lambda | 이벤트 발생 시에만 코드 실행 |
| 관리 | Systems Manager | 대규모 서버 운영·패치·안전 접속 |
이번 주 서비스의 공통 키워드는 "관리형(Managed)"이다. AWS가 패치·백업·확장 같은 운영 부담을 대신 떠안고, 사용자는 데이터와 로직에 집중한다. 이는 책임 공유 모델에서 AWS의 몫이 커지는 방향이다.
네 서비스 모두 "데이터 저장"이지만, 데이터의 모양과 용도가 다르다.
| 항목 | RDS | Aurora | DynamoDB | Redshift |
|---|---|---|---|---|
| 유형 | 관계형(SQL) | 관계형(SQL) | NoSQL(키-값/문서) | 데이터 웨어하우스 |
| 특징 | 다양한 엔진 지원 | MySQL/PostgreSQL 호환·고성능 | 밀리초 응답·자동 확장 | 대규모 분석 쿼리 |
| 적합한 경우 | 일반 트랜잭션 앱 | 고성능 관계형 워크로드 | 초고속·대규모 단순 조회 | 대량 데이터 집계·분석 |
🎯 시나리오: "수백만 사용자의 장바구니를 밀리초 단위로 읽고 써야 한다" → 자동 확장되는 NoSQL인 DynamoDB. "기존 MySQL 앱을 더 빠르고 안정적으로 옮기고 싶다" → Aurora. "수년치 매출 데이터를 모아 복잡한 집계 분석을 돌린다" → Redshift.
⚠️ 함정: "관계형 vs NoSQL"과 "트랜잭션 vs 분석"을 구분한다. RDS/Aurora는 관계형 트랜잭션용, DynamoDB는 NoSQL, Redshift는 분석(OLAP)용이다. "빠른 키 조회"에 Redshift를 고르거나 "복잡한 분석"에 DynamoDB를 고르면 오답이다.
Aurora는 RDS 제품군 안의 한 종류로, MySQL·PostgreSQL과 호환되면서 AWS가 클라우드에 맞게 재설계한 엔진이다. RDS는 "관리형 관계형 DB 묶음", Aurora는 "그중 고성능 옵션"으로 기억하면 된다.
실제로 틀리는 지점은 대부분 아래 네 가지 중 하나다.
첫째, "관계형이냐 아니냐"와 "트랜잭션이냐 분석이냐"를 한 축으로 뭉뚱그린다. 이 둘은 다른 축이라 질문을 따로 던져야 한다.
질문 1: 데이터가 표(테이블) 모양이고 관계가 중요한가?
예 → RDS / Aurora / Redshift 계열
아니오 → DynamoDB
질문 2: 하는 일이 "건건이 빠르게 읽고 쓰기"인가, "쌓인 걸 모아서 분석"인가?
건건이 → RDS / Aurora / DynamoDB
모아서 분석 → Redshift
둘째, "확장"이라는 단어에 반사적으로 DynamoDB를 고른다. "복잡한 조인과 트랜잭션이 필요하다"가 함께 있으면 관계형이 답이다.
셋째, 캐시를 잊는다. "DB 앞단에 두어 반복 조회를 빠르게" 같은 표현이면 ElastiCache(인메모리 캐시)가 답일 수 있다. 데이터를 저장하는 곳과 잠깐 담아 두는 곳은 역할이 다르다.
넷째, "관리형"을 과대 해석한다. 백업·패치·복구 같은 운영 부담을 AWS가 진다는 뜻이지, 스키마 설계나 쿼리 성능까지 알아서 해준다는 뜻이 아니다.
| 상황 표현 | 답 | 이유 |
|---|---|---|
| "여러 테이블을 조인하는 복잡한 트랜잭션" | RDS/Aurora | 관계형의 본령 |
| "초당 수만 건의 단순 키 조회" | DynamoDB | 밀리초 응답·자동 확장 |
| "3년치 로그를 모아 분기별 매출 집계" | Redshift | 분석(OLAP) 전용 |
| "MySQL 앱을 그대로 두고 성능·가용성만 올림" | Aurora | MySQL 호환 |
| "같은 조회가 반복돼 응답을 더 줄이고 싶다" | ElastiCache | 인메모리 캐시 |
서비스끼리 직접 묶지 않고 느슨하게 연결(디커플링)하는 도구들이다.
| 항목 | SQS | SNS | EventBridge |
|---|---|---|---|
| 방식 | 큐(대기열) | 발행/구독(팬아웃) | 이벤트 버스(라우팅) |
| 비유 | 한 줄로 서서 차례로 처리 | 한 번 방송, 여러 명이 동시 수신 | 이벤트를 규칙에 따라 분배 |
| 적합한 경우 | 작업을 순서대로 천천히 처리 | 한 이벤트를 여러 대상에 동시 통지 | 다양한 이벤트를 조건별로 연결 |
🎯 시나리오: "주문이 몰려도 결제 처리를 하나씩 안정적으로 소화하고 싶다" → 대기열에 쌓아 순차 처리하는 SQS. "주문 한 건이 들어오면 알림·재고·배송 시스템에 동시에 알리고 싶다" → 한 번 발행해 여러 구독자에게 팬아웃하는 SNS.
SQS는 "당겨오는(pull)" 큐, SNS는 "밀어주는(push)" 발행/구독이다. 둘을 결합해 SNS로 팬아웃한 뒤 각 SQS 큐가 받는 "팬아웃 패턴"도 흔하다. EventBridge는 여기에 "이벤트 내용에 따른 규칙 라우팅"을 더한 상위 도구다.
이 영역의 함정은 "메시지를 보낸다"가 셋 모두에 해당한다는 점이다. 결정적 구분은 "받는 쪽이 몇이고 어떻게 받느냐"다.
| 질문 | 답 |
|---|---|
| 받는 쪽이 하나이고, 자기 속도로 하나씩 처리하나? | SQS |
| 받는 쪽이 여럿이고, 동시에 같은 내용을 받나? | SNS |
| 이벤트 내용에 따라 다른 대상으로 갈라 보내야 하나? | EventBridge |
또 하나 중요한 개념이 디커플링(decoupling, 느슨한 결합)이다. 왜 중간에 큐를 두는지 그림으로 본다.
[직접 연결] 주문 서비스 ──직접 호출──► 결제 서비스
결제가 멈추면 주문도 함께 멈춘다
[큐 경유] 주문 서비스 ──► [SQS 큐] ──► 결제 서비스
결제가 잠시 멈춰도 주문은 계속 받아 쌓아 둔다
관건은 "한쪽의 장애가 다른 쪽으로 번지지 않게 만드는 것"이다. "서비스 간 결합을 낮춘다", "한 구성 요소의 장애가 전체에 영향을 주지 않게 한다", "트래픽 급증을 흡수한다(버퍼링)" 같은 표현이 보이면 큐/메시징 계열이 답이다.
⚠️ 함정: SNS를 "이메일 보내는 서비스"로만 기억하면 틀린다. SNS의 본질은 한 번 발행하면 여러 구독자에게 동시에 전달하는 구조이고, 이메일·문자는 그 전달 대상 중 하나일 뿐이다. 반대로 SQS를 "알림 서비스"로 착각해서도 안 된다. SQS는 받는 쪽이 준비됐을 때 꺼내 가는 대기열이다.
세 서비스는 모두 "관찰"하지만, 무엇을 보는지가 다르다. 이 셋의 구분은 시험에서 헷갈리기 쉽다.
| 항목 | CloudWatch | CloudTrail | Config |
|---|---|---|---|
| 보는 대상 | 성능 지표·로그·경보 | API 호출(누가·언제·무엇을) | 리소스 구성·변경 이력 |
| 질문 | "지금 잘 돌아가나?" | "누가 이 작업을 했나?" | "이 자원이 규칙을 지키나?" |
| 용도 | 모니터링·알림 | 감사·보안 추적 | 규정 준수·구성 추적 |
함정: "CPU 사용률이 높을 때 경보" = CloudWatch, "누가 이 S3 버킷을 삭제했는지 추적" = CloudTrail, "모든 EBS 볼륨이 암호화되어 있는지 점검" = Config. 셋 다 "관찰"이라 헷갈리지만, 성능·감사·구성 준수로 역할이 갈린다.
CloudTrail은 계정 내 거의 모든 API 활동을 기록하므로 보안 사고 조사와 감사의 1차 증거가 된다. CloudWatch가 "건강 상태계", CloudTrail이 "출입 기록부", Config가 "규정 점검표"라고 비유하면 구분이 쉽다.
세 서비스에 더해 이번 주에 나온 Systems Manager, 그리고 자주 함께 등장하는 Trusted Advisor·Health Dashboard까지 한 번에 정리한다.
| 상황 표현 | 답 |
|---|---|
| "CPU 사용률이 임계값을 넘으면 알린다" | CloudWatch |
| "여러 서버의 애플리케이션 로그를 한곳에서 검색" | CloudWatch Logs |
| "누가 이 리소스를 삭제했는지 밝혀낸다" | CloudTrail |
| "규제 감사를 위해 활동 기록을 보관한다" | CloudTrail |
| "모든 볼륨이 암호화됐는지 지속 점검" | Config |
| "지난달 이 보안 그룹은 어떤 설정이었나" | Config |
| "서버 수백 대에 패치를 일괄 적용" | Systems Manager |
| "비용·보안 개선 권고를 받아본다" | Trusted Advisor |
| "AWS 쪽 장애나 예정된 유지 관리 확인" | AWS Health Dashboard |
함정: "장애 조사"라는 말만 보고 무조건 CloudTrail을 고르지 않아야 한다. 조사 대상이 사람의 행위면 CloudTrail, 시스템의 상태·성능이면 CloudWatch, 설정이 규칙에 맞았는지면 Config다. 한 사건도 셋이 각각 다른 조각을 알려준다 — CloudWatch는 증상, CloudTrail은 범인, Config는 규칙 위반 여부다.
CloudFormation은 인프라를 손으로 클릭하지 않고 템플릿(코드)으로 정의해 자동 생성·관리하는 IaC(Infrastructure as Code) 서비스다. 같은 환경을 실수 없이 반복 재현할 수 있다.
| 개념 | 의미 |
|---|---|
| 템플릿(Template) | 만들 자원을 적은 코드 파일(JSON/YAML) |
| 스택(Stack) | 템플릿으로 함께 만들어진 자원 묶음 |
| 이점 | 재현성·버전 관리·일괄 생성/삭제 |
🎯 시나리오: "개발·테스트·운영용으로 동일한 환경을 세 벌 똑같이 만들어야 한다." → 클릭으로 일일이 만들면 실수가 생기니, CloudFormation 템플릿 하나로 스택을 반복 생성한다. 삭제도 스택 단위로 한 번에 정리된다.
CloudFormation은 "내가 원하는 최종 상태"를 선언하면 AWS가 그 상태가 되도록 자원을 만들고 변경한다. 이런 선언적(declarative) 방식 덕분에 같은 템플릿은 언제 돌려도 같은 결과를 낸다.
이 영역은 "얼마나 AWS에 맡기는가" 하나의 축으로 줄 세우면 정리된다.
내가 더 관리 AWS가 더 관리
─────────────────────────────────────────────────────────►
EC2 직접 → CloudFormation → Beanstalk → Fargate → Lambda
(통제권 큼) (운영 부담 작음)
| 상황 표현 | 답 |
|---|---|
| "스택 단위로 한 번에 만들고 한 번에 삭제" | CloudFormation |
| "개발자가 코드만 올리면 배포가 끝나게" | Elastic Beanstalk |
| "이미 Kubernetes로 운영 중인 워크로드를 옮긴다" | EKS |
| "AWS 방식으로 컨테이너를 단순하게 운영" | ECS |
| "컨테이너는 쓰되 노드(EC2)는 관리하지 않겠다" | Fargate |
| "운영 인력이 없어 관리 부담을 최소화" | 서버리스(Lambda/Fargate) |
| "특정 OS 커널 설정이 필요한 레거시 앱" | EC2 |
함정: CloudFormation과 Elastic Beanstalk을 "무엇이 더 좋은가"로 비교하면 안 된다. Beanstalk은 내부적으로 CloudFormation을 사용하며, 둘의 갈림길은 "인프라 전체를 세밀하게 정의해야 하는가(CloudFormation)" 대 "웹 앱을 빨리 띄우는 게 목적인가(Beanstalk)"다. 마찬가지로 ECS와 EKS는 성능이 아니라 AWS 고유 방식이냐 표준 Kubernetes냐로 갈린다.
답을 손으로 가리고 왼쪽만 읽으며 서비스 이름을 떠올려 본다.
| 상황 | 서비스 |
|---|---|
| 1. 사용자 프로필을 밀리초 단위로 조회, 트래픽 급증에도 자동 확장 | DynamoDB |
| 2. 주문·결제처럼 여러 테이블에 걸친 트랜잭션 처리 | RDS |
| 3. 기존 MySQL을 그대로 쓰면서 성능·가용성을 높이고 싶다 | Aurora |
| 4. 5년치 판매 데이터를 모아 분기별 리포트를 만든다 | Redshift |
| 5. 같은 조회가 반복돼 DB 앞단에 캐시를 두고 싶다 | ElastiCache |
| 6. 주문이 몰려도 결제를 하나씩 안정적으로 소화 | SQS |
| 7. 한 이벤트를 알림·재고·배송 시스템에 동시 통지 | SNS |
| 8. 이벤트 내용에 따라 서로 다른 대상으로 라우팅 | EventBridge |
| 9. 서비스 간 결합을 낮춰 장애 전파를 막는다 | SQS(디커플링) |
| 10. CPU가 임계값을 넘으면 담당자에게 알린다 | CloudWatch(+SNS) |
| 11. 흩어진 애플리케이션 로그를 한곳에서 검색 | CloudWatch Logs |
| 12. 부하에 따라 인스턴스를 자동으로 늘리고 줄인다 | CloudWatch 경보 + Auto Scaling |
| 13. 누가 언제 어떤 리소스를 지웠는지 밝혀낸다 | CloudTrail |
| 14. 모든 S3 버킷이 암호화됐는지 지속 점검한다 | Config |
| 15. 지난주 시점의 리소스 설정을 확인한다 | Config |
| 16. 서버 수백 대에 OS 패치를 일괄 적용한다 | Systems Manager |
| 17. SSH 키 없이, 포트를 열지 않고 서버에 접속한다 | Systems Manager (Session Manager) |
| 18. 동일한 인프라를 세 벌 만들고 한 번에 지운다 | CloudFormation |
| 19. 인프라를 모르는 개발자가 웹 앱을 빠르게 배포한다 | Elastic Beanstalk |
| 20. 파일 업로드 시에만 실행되는 썸네일 생성 작업 | Lambda |
시험 전날 이 목록에 "예"라고 답할 수 있으면 Week 3는 넘어간 것이다.
| 짝 | 결정적 차이 |
|---|---|
| RDS vs DynamoDB | 관계형(SQL) vs NoSQL(키-값·문서) |
| RDS vs Aurora | 여러 엔진을 관리형으로 vs 그중 클라우드 최적화 고성능 옵션 |
| RDS vs Redshift | 트랜잭션(건건이 처리) vs 분석(모아서 집계) |
| DynamoDB vs ElastiCache | 데이터를 저장하는 곳 vs 잠깐 담아 두는 캐시 |
| SQS vs SNS | 하나가 꺼내 감(큐) vs 여럿이 동시에 받음(팬아웃) |
| SNS vs EventBridge | 구독자 전원에게 동일 전달 vs 규칙에 따라 갈라 보냄 |
| CloudWatch vs CloudTrail | 성능·상태 vs 누가 무엇을 했나 |
| CloudTrail vs Config | 누가 바꿨나 vs 무엇이 어떻게 바뀌었나 |
| Trusted Advisor vs Config | 일반적 개선 권고 vs 내가 정한 규칙 준수 평가 |
| Health Dashboard vs CloudWatch | AWS 쪽 상태 vs 내 리소스 상태 |
| CloudFormation vs Beanstalk | 인프라 전체 정의 vs 앱 배포 자동화 |
| 템플릿 vs 스택 | 설계도 파일 vs 만들어진 리소스 묶음 |
| ECS vs EKS | AWS 고유 방식 vs 표준 Kubernetes |
| EC2 vs Fargate | 노드를 내가 관리 vs 노드 관리 없음 |
| Fargate vs Lambda | 컨테이너를 띄워 둠 vs 이벤트 때만 함수 실행 |
| Systems Manager vs CloudFormation | 있는 서버를 운영 vs 인프라를 처음부터 생성 |
선택지 넷이 다 그럴듯해 보일 때 쓰는 순서다.
1) 이 상황이 다루는 게 무엇인가?
데이터 저장 → DB 계열
서비스 간 전달 → 통합 계열
보고·감시 → 관리 계열
만들기·배포 → IaC·컴퓨팅 계열
2) 그 안에서 결정적 단어를 찾는다
DB : 관계형? 분석? 초고속 키 조회?
통합 : 받는 쪽이 하나? 여럿? 조건별?
관리 : 성능? 누가? 규칙?
배포 : 반복 재현? 빠른 배포? 서버 관리 없음?
3) 그래도 남으면 "가장 적은 운영 부담"을 고른다
CLF는 관리형·서버리스 쪽을 정답으로 두는 경우가 많다
3번이 만능은 아니지만, 문항이 "AWS를 쓰면 무엇이 편해지는가"를 확인하려는 성격이라 쓸 만한 기본값이 된다.
이번 주 서비스들이 어떻게 함께 쓰이는지 한 장면으로 묶어 본다. 어느 배달 앱은 주문이 들어오면 SQS에 쌓아 결제 서비스가 순서대로 처리하고, 결과는 SNS로 알림·정산·배차 시스템에 동시에 뿌린다. 주문 데이터는 DynamoDB에, 정산용 집계는 Redshift에 들어간다. 전체 상태는 CloudWatch로 보고, 부하가 오르면 경보가 Auto Scaling을 깨운다. 설정을 누가 바꿨는지는 CloudTrail이, 규칙 위반은 Config가 잡는다. 그리고 이 구성 전체는 CloudFormation 템플릿 한 벌로 다시 만들 수 있다. 개별 서비스를 외우기보다 이렇게 한 장면 안에서 각자의 자리를 기억하는 편이 오래간다.
핵심 서비스 2를 다시 새기면 이렇다. 데이터베이스는 RDS/Aurora(관계형)·DynamoDB(NoSQL)·Redshift(분석)로 데이터 모양에 따라 갈리고, 통합은 SQS(큐)·SNS(팬아웃)·EventBridge(이벤트 라우팅)로 서비스를 느슨하게 잇고, 관리는 CloudWatch(성능)·CloudTrail(감사)·Config(구성 준수)로 보는 대상이 다르며, IaC는 CloudFormation이 인프라를 코드로 재현한다.
시험은 "상황 → 가장 적합한 서비스"로 묻는다는 점을 다시 기억한다. 특히 CloudWatch/CloudTrail/Config 구분과 SQS/SNS 차이는 시험 범위에 든다. 다음 주에는 보안·요금·지원 등 운영과 거버넌스 영역으로 넘어간다.
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
수백만 사용자의 세션 정보를 밀리초 단위로 빠르게 읽고 쓰며, 트래픽 급증에도 자동으로 확장되어야 한다. 가장 적합한 데이터베이스는?
문제 2
주문 한 건이 발생하면 알림 시스템, 재고 시스템, 배송 시스템에 동시에 같은 메시지를 보내고 싶다. 가장 적합한 서비스는?
문제 3
특정 사용자가 언제 어떤 AWS API를 호출해 자원을 삭제했는지 사후에 추적해 보안 감사를 하려 한다. 가장 적합한 서비스는?
문제 4
"모든 EBS 볼륨이 암호화되어 있는지" 같은 리소스 구성 규칙 준수 여부를 지속적으로 점검하고 변경 이력을 추적하려 한다. 가장 적합한 서비스는?
문제 5
개발·테스트·운영용으로 완전히 동일한 인프라 환경을 실수 없이 반복 생성하고, 필요 없을 때 한 번에 삭제하려 한다. 가장 적합한 서비스는?