운영 중인 시스템에서 가장 비싼 순간은 "장애가 났는데 원인을 모르는 시간"이다. 서버가 죽은 게 아니라 응답이 느려졌을 뿐인데, 그게 DB 때문인지 네트워크 때문인지 애플리케이션 코드 때문인지 알 수 없으면 엔지니어는 추측으로 재시작을 반복하고 그 사이 매출은 빠져나간다. 관찰성(Observability)이라는 개념이 단순한 "모니터링"과 구분되어 등장한 이유가 여기 있다. 모니터링은 "내가 미리 정의한 질문(CPU가 80% 넘었나?)에 답하는 것"이고, 관찰성은 "미리 예상하지 못한 질문(왜 이 특정 사용자만 느린가?)에도 데이터로 답할 수 있는 능력"이다. 그리고 이 능력은 메트릭·로그·트레이스라는 세 종류의 데이터를 교차로 엮을 때만 나온다.
AWS가 2009년 출시한 CloudWatch는 처음엔 EC2 CPU 사용률을 그래프로 보여주는 단순한 메트릭 도구였다. 하지만 클라우드가 단일 서버에서 수백 개의 마이크로서비스·Lambda·컨테이너로 분화하면서, CloudWatch도 Metrics(2009) → Logs(2014) → Alarms 고도화 → Logs Insights(2018) → Container/Lambda Insights → Synthetics·RUM으로 계속 확장됐다