기준: DVA-C02 시험 가이드오류 제보
한 주 동안 CloudWatch, X-Ray, CloudTrail, EventBridge를 따로따로 봤지만, 이 넷은 하나의 질문을 네 각도에서 답하는 도구들이다. 그 질문은 "운영 중인 시스템 안에서 무슨 일이 일어나고 있는가, 그리고 우리는 어떻게 알고 어떻게 반응하는가"다. 이 마지막 날은 개별 서비스를 복습하는 데 그치지 않고, 네 서비스가 어떻게 하나의 관측 가능성(observability) 그림으로 맞물리는지를 정리한 뒤, 실전 시험 유형의 시나리오 문제로 그 이해를 검증한다.
모니터링 도구를 "이름 → 기능"으로 단순 암기하면 비슷한 이름 앞에서 쉽게 흔들린다. 대신 두 개의 축으로 좌표를 잡으면 각 도구가 왜 그 자리에 있는지가 보인다.
첫 번째 축은 무엇을 보는가다. 숫자(지표)인가, 텍스트(로그)인가, 요청의 경로(추적)인가, 행동의 기록(감사)인가. 두 번째 축은 언제 작동하는가다. 사후에 관찰만 하는가, 실시간으로 반응하는가.
| 서비스 | 무엇을 보는가 | 핵심 질문 |
|---|---|---|
| CloudWatch | 지표·로그 (양적 상태) | "지금 건강한가? 무엇이 느린가?" |
| X-Ray | 요청의 경로 (인과) | "어디서 느린가? 어느 단계가 병목인가?" |
| CloudTrail | API 호출 기록 (감사) | "누가 무엇을 했는가?" |
| EventBridge | 이벤트 (반응) | "이 사건에 무엇으로 대응할까?" |
이 좌표에서 보면 CloudWatch는 "무엇이 느린가"까지만 답하고 "어디서"는 X-Ray로 넘긴다. CloudTrail은 성능이 아니라 책임을 추적한다. EventBridge는 관찰자가 아니라 반응자다. 다른 셋이 "안다"면 EventBridge는 "행동한다". 그래서 가장 강력한 패턴은 이들의 결합이다. CloudTrail이 root 로그인을 알고, EventBridge가 그에 반응해 Lambda를 호출하고 SNS로 통지하는 식이다.
현대 모니터링은 "관측 가능성(observability)"이라는 더 넓은 개념으로 재정의됐다. 제어 이론에서 온 이 용어는 "시스템의 외부 출력만 보고 내부 상태를 얼마나 추론할 수 있는가"를 뜻한다.
시험은 미세한 디테일의 차이를 묻는다. 한 주의 함정을 한자리에 모은다.
| 헷갈리는 쌍 | 핵심 차이 |
|---|---|
| EC2 Basic / Detailed Monitoring | 5분 / 1분 (Detailed는 추가 비용) |
| 기본 / 고해상도 지표 | 1분 / 1초 (고해상도 유료) |
DiskReadOps / disk_used_percent | 기본 지표 / Agent 필요 (하이퍼바이저 경계) |
| EC2 메모리 | 항상 Agent 필요 (OS 내부 측정) |
| Management / Data Events | 컨트롤 플레인·기본 ON / 데이터 플레인·기본 OFF·과금 |
| CloudTrail Event History / Trail | 90일 조회 캐시 / S3 영구 |
| CloudWatch Events / EventBridge | 같은 서비스 (EB가 상위 호환) |
| X-Ray Annotation / Metadata | 인덱싱·검색 가능(50개 한도) / 인덱싱 X·무제한 |
| Lambda Active Tracing / EC2 데몬 | 토글만 / 데몬 직접 실행 (UDP 2000) |
| Synthetics / R53 Health Check | 스크립트·다단계 흐름 / 단순 ping |
| Anomaly Detection / 정적 임계값 | ML 계절성 밴드 / 고정 선 |
| EMF / PutMetricData | 로그로 자동 추출 / 동기 API |
| Metric Stream / Subscription Filter | 지표를 외부로 / 로그를 외부로 |
| Container Insights / AMP | CloudWatch 푸시 / Prometheus 풀 |
| cron / rate | 특정 시각·캘린더 / 주기 간격 |
⚠️ 함정: 특히 헷갈리기 쉬운 셋을 다시 짚는다. ① EC2 메모리·디스크 공간은 기본 지표가 아니다 — 하이퍼바이저가 OS 내부를 못 보기 때문. ② CloudTrail Data Events는 기본 OFF — S3 GetObject·Lambda Invoke 추적은 명시적 활성화 필요. ③ ALB는 X-Ray 미지원 — 추적은 API Gateway부터.
[애플리케이션]
|
+-- API 호출 ──────→ [CloudTrail] ──→ [EventBridge] ──→ [Lambda] ──→ 보안 대응
| (root 로그인 등 패턴 매칭)
|
+-- 분산 요청 ─────→ [X-Ray] (Trace ID 전파, 서비스 맵)
|
+-- 성능 지표 ─────→ [CloudWatch Metrics] ──→ [Alarm] ──→ [SNS / Auto Scaling]
| ↑
| [EMF / Metric Filter]
| ↑
+-- 로그 ──────────→ [CloudWatch Logs] ──→ [Logs Insights / Subscription Filter]
이 그림에서 중요한 것은 화살표의 방향이다. CloudTrail과 X-Ray, CloudWatch는 애플리케이션에서 나오는 신호를 받고, EventBridge와 Alarm은 그 신호를 받아 되돌아가 자동 대응한다. 관측(왼쪽)과 반응(오른쪽)의 순환이 모니터링 아키텍처의 본질이다.
🔍 더 깊이: 이 순환에서 놓치기 쉬운 연결이 "로그 → 지표 → 알람"의 변환이다. 로그(텍스트)는 그 자체로는 알람을 걸 수 없다. 알람은 지표(숫자)에만 걸린다. 그래서 Metric Filter(로그의 패턴을 세어 지표화)와 EMF(JSON 로그에서 지표 자동 추출)라는 두 다리가 로그 세계와 지표 세계를 잇는다. 이 변환을 이해하면 "로그에 ERROR가 뜨면 알람"이라는 요구가 왜 곧장은 안 되고 Metric Filter를 거쳐야 하는지가 명확해진다. CloudWatch의 모든 자동 대응은 "지표 → 알람 → 액션"이라는 단일 경로로 수렴하며, 다른 신호(로그·이벤트)는 이 경로에 합류하기 위해 지표나 이벤트 형태로 변환된다.
| 약어 | 풀네임 | 비고 |
|---|---|---|
| CW / CWL / CWA | CloudWatch / Logs / Agent | |
| EMF | Embedded Metric Format | 로그로 지표 자동 추출 |
| EB | EventBridge | 구 CloudWatch Events |
| ADOT | AWS Distro for OpenTelemetry | X-Ray 호환 표준 추적 |
| AMP / AMG | Managed Prometheus / Grafana | 쿠버네티스 표준 모니터링 |
| SLO / SLI / SLA | Service Level Objective/Indicator/Agreement | |
| RUM | Real User Monitoring | CloudWatch RUM |
| APM | Application Performance Monitoring |
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
API Gateway → Lambda → DynamoDB → 외부 결제 API로 이어지는 요청에서 간헐적 타임아웃이 발생한다. *어느 단계*에서 지연이 생기는지 파악하려면?
문제 2
EC2 인스턴스의 메모리 사용률과 디스크 사용 공간(used %)을 CloudWatch에서 모니터링하려 한다. 동시에 DiskReadOps도 보고 싶다. 무엇이 추가로 필요한가?
문제 3
컴플라이언스 감사를 위해 S3 버킷의 모든 객체 다운로드(GetObject)를 누가, 언제 했는지 7년간 보존·분석해야 한다. 적절한 구성은?
문제 4
마이크로서비스에서 "특정 주문 ID를 가진 모든 trace를 X-Ray 콘솔에서 검색"하려 한다. 그리고 디버깅용으로 주문의 전체 JSON 본문도 trace에 첨부하려 한다. 각각 무엇을 쓰는가?
문제 5
Lambda 함수에서 비즈니스 지표(주문 수)를 CloudWatch로 보내려 한다. 실행 시간 과금이므로 비용과 지연을 최소화하고 싶다. 그리고 EC2/ECS에서는 X-Ray를 쓰는데 trace가 안 보인다. 각각의 해법은?
문제 6
root 계정으로 누군가 콘솔 로그인하면 즉시 Slack 알림을 받고 싶다. 가장 적절한 패턴은?
문제 7
트래픽이 낮·밤·주말로 크게 달라지는 API의 지연 시간 지표에 알람을 걸려 한다. 단일 정적 임계값은 낮엔 너무 둔감하고 밤엔 오탐이 많다. 해법은?
문제 8
"에러 100건 초과 시 알람"을 걸었는데 트래픽이 평소의 10배로 늘자 정상 상태에서도 알람이 계속 울린다. 더 견고한 알람을 만들려면?
문제 9
CloudWatch 지표를 회사 표준 모니터링 도구(Datadog)로 거의 실시간 통합하고, 동시에 애플리케이션 로그도 OpenSearch로 보내려 한다. 각각 무엇을 쓰는가?
문제 10
ECS Fargate 서비스에서 특정 태스크가 메모리 부족으로 반복 재시작되는데, 호스트 수준 CloudWatch 지표로는 평균이 정상이라 안 보인다. 컨테이너 레벨 가시성을 확보하려면?
문제 11
"매일 새벽 2시에 정확히 한 번" 배치 Lambda를 실행하되, 향후 수천 개의 서로 다른 스케줄로 확장될 수 있다. 가장 적절한 구성은?
문제 12
신규 배포 직후 API가 200을 반환하지만 사용자 화면의 결제 버튼이 깨져 클릭이 안 된다. 지표상으론 모두 정상이다. 이런 "기술적으로는 작동하지만 사용자에겐 고장"인 상태를 자동 감지하려면?
Week 10의 네 서비스는 "관측하고 반응한다"는 하나의 순환으로 묶인다. CloudWatch가 양적 상태("무엇이 느린가")를, X-Ray가 인과("어디서 느린가")를, CloudTrail이 책임("누가 했는가")을 관측하고, EventBridge가 그 신호에 반응("무엇으로 대응할까")한다. 시험 함정의 대부분은 이 순환 위 어느 지점의 미세한 디테일 — EC2 메모리의 하이퍼바이저 경계, Data Events의 기본 OFF, Annotation의 인덱싱, Lambda 토글 vs EC2 데몬 — 을 묻는다. 개별 기능을 외우는 대신 "이 도구는 무엇을 보고 언제 작동하는가"라는 좌표로 이해하면, 처음 보는 시나리오도 그 좌표 위 어디쯤인지 짚어 답을 찾을 수 있다.