グラフの壁は誰も見ない

한 줄 요약

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

왜 이게 필요했나

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

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

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

어떻게 동작하나

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

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

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

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

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

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

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

흔한 착각

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

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

패널 하나를 읽을 수 있게 만드는 것들

같은 데이터라도 그리는 방식에 따라 30초 만에 읽히기도 하고 한참을 들여다봐도 모르기도 한다. 상태 대시보드의 패널에는 최소한 이 넷이 갖춰져 있어야 한다.

기준선이 함께 보인다. 지금 값만 있으면 그것이 좋은지 나쁜지 알 수 없다. 목표치를 가로선으로 긋거나, 지난주 같은 시각을 겹쳐 그린다. 특히 트래픽처럼 하루 주기가 뚜렷한 지표는 어제나 지난주와 겹쳐 보는 것이 절대값보다 훨씬 유용하다.

단위와 범위가 정직하다. 축이 0에서 시작하지 않으면 작은 변화가 절벽처럼 보이고, 반대로 지나치게 넓은 범위는 진짜 변화를 평평하게 만든다. 비율은 퍼센트로, 시간은 밀리초나 초로, 크기는 바이트 단위로 표시해 사람이 암산하지 않게 한다.

색이 상태를 뜻한다. 여러 선을 무지개로 칠하면 아무 뜻이 없다. 정상은 차분한 색으로, 문제 상태만 눈에 띄는 색으로 둔다. 그리고 빨강은 정말 나쁠 때만 쓴다. 평소에도 빨간 것이 하나 있으면 그 대시보드 전체가 빨강에 둔감해진다.

시간 범위가 질문에 맞다. 지금 정상인지를 묻는 화면의 기본 범위가 30일이면 최근 몇 분의 변화가 한 점으로 뭉개진다. 상태 대시보드는 짧게(한 시간 안팎), 용량 대시보드는 길게 잡는다.

여기에 하나를 더 권한다. 패널에 설명을 달아 둔다. 이 값이 무엇을 세는지, 어디서 오는지, 이상하면 어디를 보면 되는지를 한두 줄로 적어 두면, 그 패널을 처음 보는 사람이 만든 사람에게 묻지 않아도 된다. 대시보드를 만든 사람이 언제나 그 자리에 있는 것은 아니다. 그리고 설명을 쓰다가 한 문장으로 적히지 않는 패널을 만나면, 그 패널은 스스로도 무엇을 보는지 모르는 것이므로 지울 후보다.

실무에서 진짜 중요한 것

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

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