운영 중인 시스템에 문제가 생겼을 때, 가장 먼저 던지는 질문은 늘 같다. "지금 뭐가 잘못됐는가, 그리고 그걸 우리는 어떻게 알았어야 하는가." 모니터링이라는 분야 전체가 사실 이 두 문장을 자동화하려는 시도다. AWS CloudWatch는 그 자동화를 "모든 것은 결국 시계열 숫자(metric)다"라는 단 하나의 추상화 위에 올려놓은 서비스다. CPU 사용률도, 람다 호출 횟수도, 로그에서 추출한 에러 개수도, 심지어 사용자 정의 비즈니스 지표도 — CloudWatch 안에서는 전부 (timestamp, value, dimensions)라는 동일한 형태의 데이터 포인트로 환원된다. 이 단일 추상화가 왜 강력한지를 이해하면, 지표·로그·알람·대시보드가 따로 노는 기능들이 아니라 하나의 파이프라인이라는 게 보인다.
DVA-C02 시험에서 CloudWatch는 모니터링 섹션의 중심축이다. 단독 출제도 잦지만, 그보다 "EC2 메모리는 왜 기본 지표가 아닌가", "로그에서 알람을 만들려면 무엇을 거쳐야 하는가", "람다에서 비용 안 들이고 지표를 만드는 법" 같은 통합 시나리오로 더 자주 나온다. 이번 글은 CloudWatch가 어디서 출발한 서비스인지, 푸시(push) 기반 모델이 무엇을 가능하게 했는지, 그리고 메트릭 한 개가 어떻게 알람과 Auto Scaling 같은 자동 대응으로 이어지는지를 깊이 들여다본다.