한 주 동안 CloudWatch를 다섯 갈래로 쪼개 봤다. 메트릭(시계열·차원·알람), 로그(그룹·스트림·구독·Insights), 워크로드별 관찰성(Container/Lambda Insights·EMF), 사용자 경험 측정(Synthetics·RUM·Evidently). 그런데 시험과 실무에서 이들은 따로 놀지 않는다. 진짜 인시던트는 이 도구들이 한 줄기로 엮여 "탐지 → 진단 → 근본 원인 → 교정 → 예방"으로 흐른다. 오늘은 한 주의 개념을 다시 한번 압축하고, 그것들이 실제 상황에서 어떻게 함께 작동하는지를 시나리오 문제로 종합한다.
종합일의 목표는 단순한 복습이 아니다. 오늘 파고들 것은 도구들 사이의 이음새(seam) 다 — 메트릭이 알람을 깨우고, 알람이 Composite로 묶이고, SNS로 사람을 부르고, 그 사람이 Logs Insights로 로그를 뒤지고, 로그에 박힌 correlation ID가 X-Ray 추적으로 이어지는 한 줄기. 옵저버빌리티(observability)라는 단어 자체가 제어이론(Kalman, 1960)에서 왔다 — 시스템이 "관측 가능(observable)"하다는 것은 출력만 보고 내부 상태 전체를 재구성할 수 있다는 뜻이다. CloudWatch 스택의 목적도 정확히 그것이다 — 외부 신호(메트릭·로그·추적)만으로 분산 시스템 내부에서 무슨 일이 벌어졌는지를 사후에 재구성하는 능력.
💡 관련 이론: "모니터링"과 "옵저버빌리티"는 다른 층위다