모니터링 대시보드는 모두 초록색이었지만, 사용자 80%는 에러를 겪고 있었다

모든 것이 완벽해 보였습니다. 응답 시간 (Response times)? 200ms 미만. 에러율 (Error rate)? 0.3%. CPU? 12%. 메모리 (Memory)? 양호. 대시보드의 모든 지표가 마음을 편안하게 해주는 초록색으로 칠해져 있었습니다.

그런데도 우리의 고객 지원 편지함은 "앱이 작동하지 않아요"라는 메시지로 가득 차고 있었습니다.

무슨 일이 일어났는지, 어떻게 찾아냈는지, 그리고 관측 가능성 (Observability)에 대한 제 생각을 바꿔 놓은 모니터링 교훈에 대해 말씀드리겠습니다.

문제 (The Problem)

화요일이었습니다. 우리 앱에는 사용자가 업로드한 문서를 처리하는 기능이 있었습니다 — 변환, OCR, 저장. 단순한 파이프라인 (Pipeline) 이었죠. 모니터링 대시보드는 모든 것이 건강하다고 보여주었습니다.

하지만 사용자들은 불만을 제기하고 있었습니다. 크게 떠들썩하게는 아니었습니다. 그저 "제 문서가 처리되지 않았어요"라는 티켓이 꾸준히 흘러들어올 뿐이었습니다.

대시보드를 다시 확인했습니다. 모두 초록색이었습니다.

조사 (The Investigation)

저는 가공된 지표 (Aggregated metrics)가 아니라, 실제 요청 수준의 로그 (Request-level logs)인 로우 로그 (Raw logs)를 파헤쳤습니다. 그리고 그때 그것을 발견했습니다:

• **요청의 20%**는 메인 서비스 (Main service)를 통과하여 → 정상적으로 응답했습니다.
• **요청의 80%**는 제가 몇 주 전 "용량 관리 (Capacity management)"를 위해 추가했던 로드 밸런서 (Load balancer) 규칙에 걸려 → 아무도 사용하지 않는 스테이징 큐 (Staging queue)로 조용히 라우팅되었습니다.

요청이 실패하고 있었던 것이 아니었습니다. 그것들은 막다른 길로 리다이렉트 (Redirected) 되고 있었습니다. 에러도, 타임아웃 (Timeout)도 없었습니다. 그저... 아무 일도 일어나지 않았을 뿐입니다.

우리의 모니터링은 다음을 추적하고 있었습니다:

• ✅ 응답 시간 (완료된 20%에 대한 시간)
• ✅ 에러율 (에러가 없었습니다 — 요청이 그냥 사라져 버렸기 때문입니다)
• ✅ CPU/메모리 (트래픽의 80%가 다른 곳으로 가고 있었기 때문에 메인 서비스는 거의 작동하지 않고 있었습니다)

대시보드가 초록색이었던 이유는 오직 건강한 경로만을 측정하고 있었기 때문입니다.

근본 원인 (The Root Cause)

3주 전, 저는 피크 시간대(Peak loads)에 "오버플로 (Overflow)" 트래픽을 보조 처리 큐 (Secondary processing queue)로 라우팅하는 로드 밸런서 규칙을 추가했습니다. 아이디어는 이랬습니다: 대량의 문서 업로드 상황에서 메인 서비스가 충돌하는 것을 방지하자.

그 규칙은 작동했습니다. 트래픽의 80%를 보조 큐로 라우팅했습니다.

하지만 아무도 그 보조 큐를 위한 컨슈머 (Consumer)를 설정하지 않았습니다.

트래픽은 실패하고 있었던 것이 아닙니다. 그저 _출구 없는 방으로 정중하게 안내되고 있었을 뿐_입니다. 그리고 메인 서비스만을 추적하던 우리의 모니터링 시스템은 이를 전혀 알지 못했습니다.

해결책 (The Fix)

1. 로드 밸런서 (Load Balancer) 규칙 비활성화 (즉각적인 조치)
2. 보조 큐 (Secondary Queue)를 위한 컨슈머 (Consumer) 설정 (근본적인 조치 — 이제 두 경로 모두 모니터링됩니다)
3. 큐 깊이 (Queue-depth) 모니터링 추가 ("트래픽이 어딘가로 흐르고 있지만 소비되지 않는" 시나리오를 포착하기 위함)
4. "침묵하는 장애 (Silent Failure)" 런북 (Runbook) 작성 (지표는 정상처럼 보이지만 사용자가 문제를 보고할 때를 위한 체크리스트)

진짜 교훈 (The Real Lesson)

초록색 대시보드가 시스템이 건강하다는 것을 의미하지는 않습니다. 그것은 당신의 대시보드가 당신이 측정하라고 명령한 것들을 측정하고 있다는 것을 의미할 뿐입니다.

당신이 측정하라고 명령하지 않은 것들? 그것들이 바로 조용히 모든 것을 망가뜨릴 요소들입니다.

저의 새로운 규칙은 이렇습니다: 모든 라우팅 (Routing) 결정은 양 끝단 모두에서 모니터링되어야 합니다. 트래픽을 어딘가로 보낸다면, 그것이 도착했는지 그리고 제대로 처리되었는지 반드시 알아야 합니다.

대응하는 모니터가 없는 라우팅 규칙은 단순히 불완전한 것이 아닙니다. 그것은 위험합니다. 그것은 당신에게 가짜 확신을 주는데, 이는 운영 환경 (Production)에서 가장 최악의 확신입니다.

나의 "침묵하는 장애" 체크리스트

사용자는 문제를 보고하는데 대시보드는 초록색일 때:

• 집계된 지표 (Aggregated metrics)뿐만 아니라 원시 로그 (Raw logs)를 확인하세요
• 단일 요청을 엔드 투 엔드 (End-to-end)로 추적하세요 (단순히 정상 경로 (Happy path)만 확인하지 마세요)
• 예상치 못한 곳으로 흐르는 트래픽이 있는지 확인하세요 (새로운 경로, 오래된 규칙, 로드 밸런서 설정 등)
• 큐 깊이 (Queue depths)와 컨슈머 랙 (Consumer lag)을 확인하세요 (요청이 실패하는 것이 아니라 대기 중일 수 있습니다)
• 질문하세요: "만약 내 대시보드가 볼 수 없는 방식으로 무언가 고장 난다면, 성공적인 상태는 어떤 모습일까?"

마지막 질문에 대한 답이 보통 버그의 정체입니다.

당신의 지표는 당신의 상상력만큼만 훌륭합니다. 무언가가 어떻게 조용히 실패할 수 있는지 상상할 수 없다면, 당신은 그것을 모니터링하지 않을 것입니다. 그리고 모니터링하지 않는다면, 그것은 반드시 실패할 것입니다. 당신의 대시보드가 초록색을 유지하는 동안, 아주 조용하고 자신만만하게 말이죠.

여러분의 "대시보드는 초록색인데 모든 것이 망가졌던" 이야기는 무엇인가요?