그래프 벽은 아무도 안 본다

한 줄 요약

대시보드는 그림이 아니라 질문 하나에 답하는 도구다. 패널을 늘리는 일과 답을 빨리 얻는 일은 반대 방향으로 간다.

왜 이게 필요했나

장애 때 대시보드를 여는 이유는 하나다 — "지금 무엇이 정상이 아닌가" 를 30초 안에 알기 위해서. 그런데 대부분의 대시보드는 그 질문에 답하지 못한다. 패널이 마흔 개고, 그중 서른여덟 개는 평소와 같고, 어느 것이 평소와 다른지를 사람이 눈으로 찾아야 한다. 새벽 3시에 그 일을 하는 사람은 결국 대시보드를 닫고 로그를 본다.

패널이 늘어나는 방식도 정해져 있다. 누군가 "이것도 보이면 좋겠다" 며 하나 붙인다. 지우는 사람은 없다. 지우려면 "이건 아무도 안 본다" 를 증명해야 하는데, 대시보드에는 그걸 증명할 방법이 없다. 그래서 대시보드는 한 방향으로만 자란다.

질문을 먼저 적어 두면 그 흐름이 끊긴다. 패널마다 "이건 무슨 질문에 답하나" 를 한 문장으로 쓸 수 없으면 그 패널은 지울 수 있다. 지울 근거가 생기는 것이 질문을 적는 진짜 이유다.

어떻게 동작하나

질문 → 패널의 순서로 만든다. 반대로 하면 "이 지표가 있으니 그려 보자" 가 되고, 그렇게 붙은 패널은 아무도 해석하지 못한다.

| 질문 | 패널 | 왜 이 지표인가 |
|---|---|---|
| 지금 사용자에게 실패를 돌려주고 있나 | 5xx 비율 | 개수는 트래픽이 늘면 같이 는다. 사용자가 겪는 확률은 비율이다 |
| 느려졌나 | p95 응답시간 | 평균은 느린 절반을 숨긴다 |
| 얼마나 들어오고 있나 | 초당 요청 수 | 오류율이 떨어져도 트래픽이 0이면 정상이 아니다 |
| 자원이 곧 바닥나나 | 디스크·커넥션 사용률 | 상한이 있는 값만 여기 온다 |

이 네 가지가 구글 SRE 책의 네 가지 골든 시그널(지연·트래픽·오류·포화)이다. 새 서비스의 대시보드를 만들 때 이 넷으로 시작하면 대개 맞다.

대시보드는 한 종류가 아니다

섞으면 셋 다 못 하게 되는 세 종류가 있다.

| 종류 | 답하는 질문 | 보는 사람 | 패널 수 |
|---|---|---|---|
| 상태(health) | 지금 정상인가 | 호출을 받은 사람 | 4~6 |
| 진단(diagnosis) | 왜 아픈가 | 원인을 찾는 사람 | 많아도 된다 |
| 용량(capacity) | 언제 늘려야 하나 | 계획하는 사람 | 주 단위로 본다 |

상태 대시보드에 진단용 패널을 섞는 순간 그 대시보드는 30초 안에 답을 못 준다. 진단 패널은 다른 대시보드로 빼고 링크로 잇는다.

흔한 착각

"많이 보여 줄수록 안전하다." 반대다. 화면에 신호가 많을수록 이상한 하나를 놓칠 확률이 올라간다. 상태 대시보드의 패널이 여섯 개를 넘으면 대개 진단용이 섞인 것이다.

"CPU 부터 놓는다." CPU 가 80% 인 것은 사용자에게 아무 뜻이 없다. 사용자가 겪는 것(오류·지연)이 먼저 오고, 자원은 그다음이다. CPU 는 "왜" 를 묻는 진단 대시보드의 재료다.

실무에서 진짜 중요한 것

대시보드를 만들고 나면 인시던트 테스트를 해 본다. 새벽 3시에 호출을 받았다고 치고, 이 대시보드를 열어 30초 안에 "정상/비정상" 을 말할 수 있는가. 말할 수 없으면 패널이 모자란 것이 아니라 많은 것이다.

그리고 대시보드 제목에 답하는 질문을 그대로 적어 둔다. "shop-api 개요" 보다 "shop-api — 지금 사용자에게 실패를 돌려주고 있는가" 가 낫다. 제목이 질문이면, 그 질문에 답하지 않는 패널은 눈에 띈다.