쉬운 설명
운영 중인 서비스는 언제 어디서 문제가 터질지 모릅니다. 사용자가 알리기 전에 우리가 먼저 알아야 하고, 알아챈 뒤엔 원인을 빠르게 좁혀야 합니다. 모니터링은 그걸 가능하게 하는 '눈과 귀'입니다.
보통 세 가지 신호를 본다고 말합니다('observability의 세 기둥'). ① 메트릭(시간에 따른 숫자 — 응답 시간·요청 수·CPU·메모리). ② 로그(어떤 일이 언제 일어났는지 텍스트 기록). ③ 트레이스(한 요청이 여러 서비스를 지나가는 흐름). 이 세 가지가 잘 갖춰져 있어야 사고가 났을 때 '무엇이, 언제, 어디서, 왜'를 답할 수 있습니다.
메트릭 위에 알람을 두는 게 모니터링의 가장 직접적인 가치입니다. '결제 API 오류율 5% 초과', '응답 시간 P99 1초 초과' 같은 조건이 만족되면 자동으로 슬랙·문자로 알림이 갑니다. 사용자가 신고하기 전에 운영팀이 먼저 알게 되는 일이, 사고의 영향 범위를 가장 크게 줄입니다.
대표 도구: ① Prometheus + Grafana(메트릭 수집·시각화, 오픈소스 표준), ② Datadog·New Relic·Dynatrace(통합 SaaS, 메트릭+로그+트레이스 한곳에서), ③ ELK·Loki(로그), ④ OpenTelemetry(데이터 수집 표준), ⑤ PagerDuty·Opsgenie(알람·온콜). 모니터링 인프라는 시간이 지나며 회사의 영구적인 부품이 됩니다.
잘 만든 모니터링의 목표는 '대시보드를 멋지게 만드는 것'이 아니라 '문제가 사용자에게 도달하기 전에 알람이 울리는 것'입니다. 알람이 너무 많으면 운영팀이 둔감해지고(alert fatigue), 너무 적으면 사고를 놓칩니다. 'SLI·SLO' 같은 개념을 정의해서 사용자에게 의미 있는 지표를 중심으로 알람을 두는 것이 모니터링 성숙도의 척도가 됐습니다.
비유로 보면
모니터링은 자동차의 계기판과 경고등에 비슷합니다. 평소엔 무시해도 되지만, 엔진 과열·연료 부족·타이어 공기압 이상이 생기면 운전자에게 즉시 알려 줍니다. 좋은 계기판은 정상일 때는 조용하고, 이상이 생기는 순간 정확한 정보를 줍니다.
어디에서 만나나
모든 운영 서비스의 필수 인프라. 클라우드 비용 모니터링, 보안 이벤트 모니터링(SIEM), 머신러닝 모델의 성능 드리프트 모니터링, 사용자 경험 모니터링(RUM) 같은 특화 영역으로 점점 세분화되고 있습니다.
작은 예시
스트리밍 서비스 운영팀의 휴대폰이 새벽 3시에 울립니다 — '결제 API 오류율 5% 초과'. 자동 알람이 발화한 거고, 이 알람 한 줄이 있어 운영팀이 30분 만에 원인을 잡고 고칠 수 있게 됩니다. 같은 사고를 사용자 신고로만 알았다면 새벽 6시는 돼야 시작할 수 있었을 겁니다.
자주 하는 오해
한 줄 정리
모니터링의 진짜 비결은 '사용자에게 의미 있는 신호'를 고르는 데 있습니다. 무엇을 보지 않을지 정하는 결정이, 무엇을 볼지 정하는 결정만큼 중요합니다.