CS 실시간 대시보드 요청서가 왔다. 위젯 5종.
- 전체 미처리 건수
- 경로별 미답변
- 문의 유형별 분포
- 담당자별 처리 부하(%)
- SLA 경보
데이터를 뒤져보고 2종만 만들었다. 나머지 3종은 "왜 못 만드는지"를 PR 본문에 표로 적어서 냈다.
이 글은 그 표에 대한 이야기다.
먼저 데이터를 본다
요청서를 받으면 바로 화면부터 그리고 싶어진다. 위젯 5개면 카드 5개니까.
그런데 대시보드 위젯은 데이터가 있어야 존재할 수 있다. 그래서 순서를 뒤집었다. 5개 각각에 대해 "이 값을 지금 데이터로 계산할 수 있나"를 먼저 확인했다.
① 전체 미처리 건수 — 이미 있다
화면에 이미 있는 카드가 정확히 그 값이었다. 요청서를 쓴 사람이 다른 이름으로 불렀을 뿐이다.
만들지 않고, 기존 카드가 그 값이라고 답했다. 같은 숫자를 두 번 보여주는 카드를 추가하면, 둘이 어긋나는 날 아무도 어느 쪽이 맞는지 모른다.
② 경로별 미답변 — 만들었다 (단, 예외를 뒀다)
이건 만들었는데, 설계에서 한 가지를 어겼다. 이 값만 화면 필터를 따르지 않는다.
대시보드의 다른 값들은 전부 "지금 보고 있는 범위"를 따른다. 그게 일관성이고, 보통은 그게 맞다.
그런데 이 값의 목적은 "세 경로 중 어디가 밀려 있나" 를 보는 것이다. 탭으로 한 경로를 선택하면 나머지 두 경로가 항상 0이 되고, 그러면 값이 존재할 이유가 사라진다. 일관성을 지키면 기능이 없어지는 경우다.
그래서 예외를 두되, 예외라는 사실을 카드 라벨에 적었다.
경로별 미답변 · 탭·필터 무관
이 한 줄이 없으면 사용자는 "필터를 걸었는데 숫자가 안 변하네? 버그네"라고 생각한다. 의도된 예외와 버그는 화면에서 구별되지 않는다. 구별해주는 건 라벨뿐이다.
단, 권한 범위는 지켰다. 필터는 무시해도 자기가 볼 수 없는 건은 여전히 안 보인다. 편의를 위한 예외가 권한을 뚫으면 그건 예외가 아니라 사고다.
③ 문의 유형별 분포 — 만들었는데, 쓰려던 컬럼을 못 썼다
유형별로 세면 되는 간단한 일이었다. 통합 테이블에 category 컬럼이 있었다.
세어봤더니 대상 12,259건이 전부 같은 값이었다. 색인할 때 기본값으로 OTHER 를 넣고 있었고, 아무도 실제 값으로 채우지 않았다.
컬럼이 있다고 데이터가 있는 게 아니다. 그래서 원본 세 테이블의 유형 컬럼을 합쳐서 셌다. 경로마다 enum 이 달라서, 서버는 원본 값을 그대로 내려주고 화면이 기존 유형 필터와 같은 표로 이름을 붙이게 했다. 필터에서 고르는 이름과 분포에 뜨는 이름이 달라지면 안 되니까.
상위 5개만 내려준다. 세 경로를 합치면 유형이 22종을 넘어서 카드에 안 들어간다.
못 만든 두 개
여기서부터가 이 글의 본론이다.
④ 담당자별 처리 부하 — 구조적으로 불가능
"담당자별로 몇 건씩 들고 있나"를 보려면 문의마다 담당자가 있어야 한다.
handler_id 라는 컬럼이 있었다. 이름만 보면 담당자다. 코드를 따라가 보니 이 값이 채워지는 시점은 답변을 등록할 때였다. 즉 "담당자"가 아니라 "답변한 사람" 이다.
그래서:
- 미처리 건에는 구조적으로 담당자가 없다 — 아직 아무도 답을 안 했으니까
- "담당자별 미처리 건수"로 범위를 낮춰도 항상 0 이다
- 진짜로 만들려면 문의를 담당자에게 배정하는 절차가 먼저 있어야 한다. 그건 위젯이 아니라 업무 흐름이다
이건 "데이터가 없다"가 아니라 "그 개념이 제품에 없다" 였다.
⑤ SLA 경보 — 기준이 0건
"마감 임박 건을 경고로 띄워 달라." 마감 시각 컬럼 sla_due_at 이 있었다.
대상 12,259건 중 sla_due_at 이 채워진 건: 0시작 시각(sla_started_at)은 전부 있었다. 시작은 자동으로 찍히는데 마감 기준을 정한 사람이 없었던 것이다. 몇 시간 안에 답해야 하는지가 어디에도 정의돼 있지 않으니, 경보를 띄울 선이 없다.
표로 적어 낸 이유
PR 본문에 이렇게 넣었다.
| 위젯 | 판단 | 근거 |
|---|---|---|
| 전체 미처리 건수 | 이미 있음 | 기존 카드가 그대로 그 값 |
| 담당자별 처리 부하 | 불가 | 배정 절차가 없음. handler_id 는 답변자 |
| SLA 경보 | 불가 | 대상 12,259건 중 sla_due_at 이 0건 |
세 가지를 노린 것이다.
첫째, 요청자가 다음 결정을 할 수 있다. "못 만듭니다"로 끝나면 대화가 끝난다. "배정 절차가 없어서 못 만듭니다"라고 하면, 요청자는 "그럼 배정 절차를 만들까?" 또는 "그건 나중에 하고 다른 걸 먼저" 를 고를 수 있다. 공을 되돌려주는 게 아니라 선택지를 주는 것이다.
둘째, 6개월 뒤 같은 요청이 다시 온다. 그때 이 표가 없으면 또 같은 조사를 한다. 있으면 "그때 이랬는데 지금은 바뀌었나?"만 확인하면 된다. 조사 결과는 코드보다 오래 산다.
셋째, 숫자를 적어야 믿는다. "SLA 데이터가 부실합니다"는 의견이고, "12,259건 중 0건"은 사실이다. 전자는 반박당하고 후자는 다음 행동으로 이어진다.
안 만드는 것도 결정이다
주니어 때 나는 "못 한다"를 말하는 게 능력 부족을 인정하는 거라고 생각했다. 그래서 어떻게든 만들었다. 담당자별 부하 같은 걸 요청받으면, handler_id 로 대충 그룹핑해서 뭔가 그럴듯한 숫자가 나오는 카드를 만들었을 것이다.
그게 제일 나쁘다. 아무도 그 숫자가 "답변한 사람 기준이라 미처리 건에는 해당 없음"이라는 걸 모른 채, 그 숫자로 사람을 평가하게 된다.
데이터가 없는 위젯을 만들면, 없는 데이터가 있는 것처럼 보인다. 빈 카드보다 나쁘다.
그래서 요즘은 요청서를 받으면 화면보다 데이터를 먼저 본다. 그리고 못 만드는 게 나오면, 못 만든다는 말 대신 무엇이 있어야 만들 수 있는지를 적는다.
다음 글은 "없던 개념을 만든" 쪽 이야기다. 마케팅 수신 동의가 참/거짓 한 칸으로만 저장돼 있던 걸, 분쟁에서 증명 가능한 기록으로 바꾸는 데 네 번의 PR 이 걸렸다.
