"대시보드는 다 초록불인데 사용자는 느리다고 한다." 운영을 하다 보면 이런 순간을 만납니다. 모니터링과 관측성(Observability)은 자주 섞여 쓰이지만 초점이 다릅니다. 모니터링은 미리 정한 지표가 정상인지 지켜보는 것이고, 관측성은 예상 못 한 문제가 생겼을 때 그 원인을 시스템 바깥에서 데이터로 파고들 수 있는 능력입니다. 모니터링이 "열이 나는가?"를 재는 체온계라면, 관측성은 "왜 열이 나는지" 진단할 수 있는 검사 장비에 가깝습니다.
두 개념 비교
| 구분 | 모니터링 | 관측성 |
|---|---|---|
| 질문 | "정상인가?" (알려진 문제) | "왜 이러지?" (모르는 문제) |
| 방식 | 미리 정한 지표·임계값 감시 | 임의 질문을 데이터로 탐색 |
| 결과 | 알림(임계값 초과) | 원인 추적·디버깅 |
| 관계 | 관측성의 일부 | 모니터링을 포함하는 더 넓은 능력 |
둘은 대립이 아닙니다. 모니터링은 "문제가 있다"를 알려주고, 관측성은 "어디서 왜 생겼는지"까지 파고들게 해줍니다. 좋은 운영은 모니터링으로 빨리 알아채고 관측성으로 빨리 원인을 좁힙니다.
관측성의 세 기둥
관측성은 보통 세 종류의 데이터(telemetry) 위에 세워집니다.
| 기둥 | 무엇 | 답하는 질문 |
|---|---|---|
| 메트릭(Metrics) | 수치 시계열(CPU, 요청 수) | "지금 상태가 어떤가?" |
| 로그(Logs) | 시점별 이벤트 기록 | "그때 무슨 일이 있었나?" |
| 트레이스(Traces) | 요청이 거친 서비스 경로 | "어느 구간에서 느려졌나?" |
예를 들어 응답이 느리다는 알림(메트릭)을 받으면, 해당 요청의 트레이스로 어느 마이크로서비스 호출이 오래 걸렸는지 보고, 그 서비스의 로그에서 구체적 에러를 확인하는 식으로 좁혀갑니다.
시나리오로 보는 차이
주문 API의 지연이 갑자기 늘었다고 해봅시다.
TEXT
1. 메트릭: p95 응답시간이 200ms → 2초로 급증 (모니터링이 알림)
2. 트레이스: 느린 요청을 따라가니 payment 서비스 호출이 1.8초
3. 로그: payment 로그에 "DB connection pool exhausted" 반복
→ 원인: 커넥션 풀 고갈. 모니터링은 '느리다'까지, 관측성이 '왜'까지.
모니터링만 있었다면 "느리다"에서 멈췄겠지만, 트레이스와 로그를 연결할 수 있어 근본 원인까지 도달했습니다. 이것이 관측성이 주는 차이입니다.
요점 정리
- 모니터링은 알려진 지표가 정상인지 감시(문제 감지), 관측성은 모르는 문제의 원인까지 탐색(문제 진단).
- 관측성은 모니터링을 포함하는 더 넓은 능력이다.
- 메트릭·로그·트레이스 세 기둥을 연결할 때 비로소 "왜"에 답할 수 있다.
Prometheus로 메트릭을 수집하고 로그·트레이스를 엮어 장애 원인을 추적하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.