필터를 바꿨는데 KPI가 그대로라면: 대시보드 Filter Scope 설계

질문: 대시보드에서 필터를 바꿨는데 일부 KPI가 그대로라면 어떻게 설계해야 할까?

필터는 시각 요소가 아니라 계산 범위에 대한 계약이다. 사용자가 Plant B를 선택했을 때 KPI·차트·표 중 무엇이 바뀌는지 일관되게 정해야 한다. 일부 영역을 고정해야 한다면 “전체 공장 기준”처럼 그 범위를 화면에 직접 표시해야 한다.

Filter Scope는 하나의 Filter가 영향을 주는 데이터·계산·컴포넌트의 범위다. 같은 화면에서 Scope가 다른 값이 함께 보인다면, 그 차이는 값의 이름이나 Context에서 직접 드러나야 한다.

이 글은 Global Filter와 Local Filter의 범위를 어떻게 나눌지, 그리고 “필터는 바뀌었는데 KPI는 그대로”인 상태가 언제 오류이고 언제 의도된 비교가 될 수 있는지를 하나의 가상 제조 데이터로 정리한다.

숫자가 맞아도 Scope가 다르면 화면은 틀리게 읽힌다

대시보드의 신뢰는 개별 숫자의 정확성만으로 생기지 않는다. 같은 화면에 놓인 숫자들이 같은 기간·대상·집계 범위를 공유하는지, 아니면 일부가 다른 범위를 쓰는지 사용자가 알 수 있어야 한다.

아래 데이터는 실제 고객 데이터가 아닌 가상 생산 데이터다. 같은 7일 동안 공장 A·B·C의 검사 수량과 불량 수를 비교한다.

공장	검사 수량	불량 수	불량률
A	1,000	20	2.00%
B	900	45	5.00%
C	920	18	1.96%
전체	2,820	83	2.94%

Before: 필터는 Plant B인데 KPI는 전체 공장 값이다

2,820과 2.94% 자체는 계산상 맞다. 문제는 현재 사용자가 선택한 Plant B가 아니라 전체 공장 범위라는 점이다. 상세 표는 Plant B를 보여주는데 상단 KPI는 전체를 유지하면, 사용자는 같은 필터가 화면 전체에 적용됐다고 자연스럽게 해석할 수 있다.

이 상태를 “KPI는 맞고 표도 맞다”라고 보면 UI 오류를 놓친다. 오류는 숫자 안이 아니라 숫자 사이의 Scope 관계에 있다.

After: Global Filter라면 판단 영역 전체가 같은 범위를 공유한다

여기서는 필터가 바뀌면 Decision summary와 Evidence가 함께 바뀐다. 같은 질문에 답하는 영역들이 같은 Scope를 공유하기 때문에 사용자가 별도로 범위를 추론할 필요가 없다.

모든 컴포넌트를 무조건 같이 바꾸는 것도 정답은 아니다

전체 공장 기준을 유지해야 하는 경우도 있다. 예를 들어 Plant B를 보면서 전체 공장 평균과 비교하는 것이 핵심 과제라면, 전체 값이 고정되는 것은 오류가 아니다. 다만 고정된 Scope를 숨기는 것은 오류가 될 수 있다.

표현	값	Scope	해석
Plant B 불량률	5.00%	선택 공장	현재 선택의 상태
전체 공장 불량률	2.94%	A+B+C 전체	비교 기준
차이	+2.06%p	Plant B − 전체	비교 결과

선택하지 않은 대안은 “모든 KPI를 항상 Global Filter에 종속시키기”다. 구현은 단순해질 수 있지만, Benchmark처럼 의도적으로 고정해야 하는 값까지 함께 움직이면 비교 기준이 사라진다. 반대로 모든 컴포넌트가 개별 Filter를 가지면 자유도는 높아지지만, 사용자가 각 숫자의 Scope를 계속 추적해야 한다.

Global Scope와 Local Scope를 나누는 실무 기준

영역	기본 Scope	Filter 동작	UI에서 남겨야 할 것
Decision KPI	Global	주요 선택과 함께 갱신	기간·대상 Context
Evidence chart	Global + 필요 시 Local	Global을 상속하고 탐색용 Local만 추가	추가 Local 조건
Benchmark	Fixed 또는 별도 Scope	의도적으로 고정 가능	“전체 공장”, “전년 기준” 같은 범위 이름
Detail table	Global 상속	선택 범위로 갱신	필터 요약과 결과 건수

판단 규칙은 간단하다. 필터가 사용자의 핵심 질문에 대한 답을 바꾸면 Global Scope에 둔다. 증거를 탐색하는 방식만 바꾸면 Local Scope가 될 수 있다. Global Filter를 무시하는 요소가 있다면 그 Scope를 이름으로 드러낸다.

상태 설계까지 포함해야 Filter가 제품이 된다

• Loading: 새 조건을 조회 중이라면 과거 값을 새 결과처럼 보이지 않게 한다.
• Empty: “검사 수량 0”과 “현재 Filter 조건에 해당하는 데이터 없음”을 구분한다.
• Error: 일부 영역만 갱신 실패했다면 어느 Scope가 최신인지 표시하고 재시도 경로를 제공한다.
• Back navigation: 상세로 들어갔다 돌아왔을 때 사용자가 방금 보고 있던 Filter Context를 잃지 않도록 상태 규칙을 정한다.

이 네 상태는 숫자를 꾸미는 문제가 아니라 사용자가 “지금 보고 있는 값이 어떤 조건의 결과인가”를 확인하게 하는 문제다. 특히 일부 컴포넌트만 늦게 갱신되는 화면에서는 값의 최신성까지 Scope와 함께 읽혀야 한다.

개발 전에 남길 Filter Scope 명세

1. 이 Filter가 바꾸는 사용자의 핵심 질문은 무엇인가?
2. 어떤 KPI·차트·표가 Global Scope를 상속하는가?
3. Local Filter가 있다면 어느 영역까지만 영향을 주는가?
4. 의도적으로 고정되는 benchmark는 무엇이며 Scope 이름이 보이는가?
5. Loading·Empty·Error·상세 복귀에서 선택 Context가 어떻게 유지되는가?

결론: Filter 설계의 핵심은 컨트롤의 모양이 아니라 “이 선택이 어떤 숫자의 계산 범위를 바꾸는가”를 일관되게 정의하는 것이다. 범위가 다르면 숫자가 정확해도 화면은 잘못 읽힐 수 있다.

대시보드의 전체 판단 순서를 먼저 정하려면 대시보드는 카드의 집합이 아니다를, KPI의 책임·정의·비교 기준을 정하려면 KPI 대시보드 설계: 지표를 고르기 전에 정할 5가지를 함께 볼 수 있다. 기간과 집계 경계 때문에 같은 수치가 다르게 읽히는 문제는 대시보드 비교 기간과 집계 경계 정하기에서 이어진다.

근거와 범위

이 글의 검사 수량·불량 데이터와 Filter UI는 RUDA DIRECTOR의 공개용 가상 사례다. 1,000·900·920과 20·45·18을 사용했으며 전체 불량률 2.94%, Plant B 불량률 5.00%, 차이 +2.06%p를 산술 검산했다. 실제 고객 화면, 사용성 시험, 생산 성과 개선을 주장하지 않는다. Scope Matrix와 Decision Rule은 위 사례를 바탕으로 한 RUDA의 설계 판단이다.