Role-based Dashboard는 직급별로 KPI 몇 개를 바꾸는 화면이 아니다. 같은 사건을 보더라도 사용자가 내려야 할 Decision, 책임지는 시간 범위, 실행 권한에 맞춰 정보의 순서와 Action을 다시 구성하는 설계다.
팀장과 담당자가 같은 고객지원 Queue를 본다고 가정하자. 이 합성 사례에서는 두 역할 모두 A–D 네 건을 볼 권한이 있다고 가정한다. 공통 데이터 정의와 Source of Truth는 같지만, 화면의 위계와 Action은 다르다. 그러나 팀장은 “어디에 병목이 생겼고 누구를 재배치할 것인가”를 판단해야 한다. 담당자는 “지금 어떤 문의를 먼저 처리하고 언제 Escalation할 것인가”를 결정해야 한다. 데이터 정의가 같다는 이유로 화면까지 같아야 하는 것은 아니다.
가상 사례 — 같은 Queue, 다른 다음 행동
아래는 설계 원리를 설명하기 위한 합성 고객지원 사례다. 실제 회사·고객·운영 성과와 관계없다. 10월 1일 09:00 기준 미처리 문의 네 건이 있고, 내부 예시 규칙은 접수 후 4시간 안에 1차 응답하는 것이다.
| 문의 | 접수 시각 | 1차 응답 기한 | 영향 | 현재 담당 |
|---|---|---|---|---|
| A · 결제 중복 | 05:20 | 09:20 | 결제 차단 | 미배정 |
| B · 계정 권한 | 06:10 | 10:10 | 팀 8명 사용 중단 | 민지 |
| C · 사용 방법 | 06:40 | 10:40 | 개인 문의 | 현우 |
| D · 데이터 내보내기 | 07:15 | 11:15 | 보고 일정 영향 | 민지 |
이 표는 이 합성 사례의 공통 Evidence다. 여기서 Shared Evidence는 공통 정의와 단일 Source of Truth를 뜻하며, 모든 역할이 모든 행·필드를 열람한다는 뜻은 아니다. 실제 노출 범위는 별도 권한 정책을 따른다. 이 사례에서는 두 역할 모두 A–D를 볼 수 있다는 전제 아래, 같은 Evidence를 어떤 Decision 앞에 놓느냐에 집중한다.
팀장은 Queue를, 담당자는 다음 사건을 본다
팀장 화면 · Queue Decision
첫 질문 — 어느 유형과 담당자에 일이 몰렸는가?
- 우선 노출: 60분 이내 기한 임박 1건 · 미배정 1건 · 사용 중단 영향 1건
- 비교: 담당자별 열린 문의 수와 기한 위험
- Evidence: A–D 전체 Queue와 분류 기준
- Action: 배정 변경 · 인력 재배치 · 운영 기준 조정
담당자 화면 · Case Decision
첫 질문 — 지금 어떤 문의를 처리해야 하는가?
- 우선 노출: 내 담당 중 B · 10:10까지 70분
- Context: 팀 8명 사용 중단 · 계정 권한 문의
- Evidence: 고객 이력 · 이전 응답 · 필요한 확인 항목
- Action: 답변 · 보류 사유 기록 · Escalation
같은 A–D 데이터를 사용하지만, 팀장은 포트폴리오 수준의 병목을 보고 담당자는 한 Case의 다음 행동을 본다. 색 없이도 질문·Evidence·Action의 차이가 남도록 텍스트 구조로 표현했다.
모든 역할에 같은 Dashboard를 주면 생기는 세 가지 실패
1. 팀장에게 상세가 먼저 보인다
고객 메시지와 Case history가 화면 상단을 차지하면 팀장은 문의 하나를 깊게 읽게 된다. 그러나 팀장의 첫 판단이 재배치라면 먼저 필요한 것은 전체 Queue의 집중과 기한 위험이다. 상세는 Drill-down 이후에 있어도 된다.
2. 담당자에게 평균이 먼저 보인다
평균 응답시간과 전체 미처리 건수는 운영 Context로 유용하다. 하지만 담당자가 지금 답해야 할 Case를 고르는 데는 기한, 영향, 담당 상태가 더 직접적이다. 전체 평균이 좋아도 A의 기한은 20분 뒤 끝난다.
3. 보이는 Action과 실제 권한이 어긋난다
담당자에게 “전체 재배치” 버튼을 보여주고 권한 오류로 막거나, 팀장에게 “답변 보내기”를 Primary Action으로 두면 시각적 약속과 시스템 권한이 충돌한다. Role-based design은 정보 노출뿐 아니라 Action·Permission·Error state까지 함께 설계해야 한다.
역할을 직급이 아니라 Decision Boundary로 정의한다
| 설계 축 | 팀장 | 담당자 |
|---|---|---|
| Decision | 업무를 어디에 재배치할까 | 어떤 Case를 지금 처리할까 |
| Time horizon | 현재 교대·오늘 | 지금·다음 기한 |
| Unit | Queue·유형·담당자 | 내 Case·고객 |
| Data visibility | A–D Queue 열람(합성 사례 가정) | A–D Queue 열람(합성 사례 가정) |
| Comparison | 담당자 간 부하·기한 위험 | 내 Case 간 기한·영향 |
| Primary Action | 배정·재배치·기준 변경 | 답변·기록·Escalation |
| Permission | 팀 범위 변경 | 내 담당 범위 실행 |
| Verify | 재배치 후 위험 건수 변화 | 처리 후 Case 상태 변화 |
이 Matrix에서 중요한 것은 “팀장은 높은 권한, 담당자는 낮은 권한”이라는 서열이 아니다. 각 역할이 책임지는 Decision Boundary가 다르다는 점이다. 같은 직급이라도 당직·품질 검토·승인 업무를 맡으면 필요한 Time horizon과 Action이 달라질 수 있다.
선택한 안 — 공통 정의는 공유하고, Summary와 Action은 분리한다
역할마다 완전히 다른 제품을 만드는 안은 선택하지 않았다. 공통 데이터 정의와 Case detail까지 갈라놓으면 숫자의 기준이 흔들리고 Handoff가 어려워질 수 있기 때문이다. 반대로 하나의 화면에 모든 역할의 정보와 Action을 넣는 안도 버렸다. 사용자는 자기 판단과 무관한 요소를 계속 걸러내야 한다.
따라서 구조는 세 층으로 나눈다.
- Shared Evidence: 문의 정의와 시간 기준처럼 역할 간 합의가 필요한 공통 정의와 Source of Truth. 실제 행·필드의 노출 범위는 별도 권한 정책을 따른다
- Role Summary: 같은 Evidence를 각 Decision에 맞게 집계·정렬한 요약
- Authorized Action: 사용자가 실제로 실행하고 결과를 확인할 수 있는 조치
이 구조를 쓰면 팀장이 A를 민지에게 배정한 뒤 담당자 화면에 새 Case가 나타나고, 담당자가 답변한 뒤 팀장 화면의 기한 위험이 줄어드는 양방향 흐름을 설계할 수 있다. 여기서 “줄어든다”는 제품 성과 주장이 아니라 상태 전환에 대한 요구사항이다.
비례와 시각 위계 — 황금비보다 1:1 비교를 선택한 이유
주 화면에서는 Primary Decision이 supporting evidence보다 먼저 읽히도록 순서·크기·강조를 조절할 수 있다. 하지만 두 역할의 차이를 설명하는 비교 도해에서는 한쪽을 더 크게 만들면 역할의 중요도 차이로 읽힐 수 있다. 그래서 위 비교는 동일한 폭과 동일한 항목 수를 유지했다.
실제 제품 화면에서는 팀장 화면의 첫 번째 위계를 Queue risk, 두 번째를 분포와 원인, 세 번째를 Case detail로 둔다. 담당자 화면은 다음 Case, 처리 Context, 전체 Queue Context 순서다. 같은 Type scale을 재사용하더라도 역할별 Primary statement는 달라진다. 이 원리는 데이터가 많은 화면의 타이포그래피에서 정의한 Decision·Primary metric·Comparison·Evidence·Context 역할과 연결된다.
WHEN NOT TO APPLY — 역할별 화면을 나누지 않아도 되는 경우
- 한 사람이 두 역할을 함께 수행하는 작은 팀: 화면을 두 개로 나누기보다 Mode switch나 저장된 View로 충분할 수 있다.
- 공동 상황 인지가 우선인 관제 화면: 모두가 같은 위험을 동시에 봐야 한다면 공통 Summary를 유지하고 개인 Action만 분기한다.
- 감사·교육 목적: 다른 역할이 무엇을 봤고 어떤 판단을 했는지 추적해야 한다면 읽기 전용 교차 View가 필요하다.
- 데이터 정의가 아직 합의되지 않은 단계: 역할별 집계를 먼저 만들면 서로 다른 숫자가 생긴다. Shared Evidence와 계산 기준을 먼저 고정한다.
개발 전에 작성할 Role–Decision Spec
| 항목 | 작성 질문 |
|---|---|
| Role | 직급이 아니라 어떤 책임을 맡고 있는가? |
| Decision | 이 화면에서 반드시 내려야 할 판단은 무엇인가? |
| Time horizon | 지금·교대·일·주 중 어느 범위를 책임지는가? |
| Evidence | 그 판단을 설명하는 최소 데이터는 무엇인가? |
| Data visibility | 역할이 볼 수 있는 행·필드의 범위와 가림 규칙은 무엇인가? |
| Action | 사용자가 실제로 실행할 수 있는 다음 조치는 무엇인가? |
| Permission | 보이지만 실행할 수 없는 Action은 없는가? |
| Verify | 실행 후 어떤 상태 변화로 결과를 확인하는가? |
Decision Rule: 역할별 Dashboard를 나누기 전에 KPI 목록을 비교하지 않는다. 먼저 Role마다 Decision·Time horizon·Permission을 적고, 같은 Evidence에서 어떤 Summary와 Action이 달라져야 하는지 결정한다.
전체 Dashboard의 흐름은 대시보드는 카드의 집합이 아니다에서, KPI와 책임·후속 조치의 연결은 KPI 대시보드 설계에서 이어진다. 좁은 화면에서 위험·상세·복귀 순서를 다시 구성하려면 모바일 대시보드 설계를 함께 볼 수 있다.
이 명세를 실제 화면으로 옮길 때 사용할 구성 요소는 무료 React 대시보드 템플릿 KPI Kit에서 살펴볼 수 있다. 매출·고객·운영 화면을 출발점으로 삼되, 역할별 정보 순서와 실행 권한은 앞의 Role–Decision Spec에 맞춰 설계한다.
근거와 범위
Role–Decision Matrix, 합성 고객지원 데이터, 화면 위계와 적용 예외는 RUDA DIRECTOR의 공개용 편집 synthesis다. 모든 숫자와 운영 규칙은 설명을 위해 만든 가상 예시이며 실제 조직의 SLA·고객·성과를 뜻하지 않는다. 이 글은 정적 정보 구조를 검토하며 실제 사용자 시험이나 처리 시간 개선을 주장하지 않는다.