vpd-permission-poc/docs/design/dds-persona-ux-review/README.md

DDS 트랙 페르소나 UX 리뷰 및 개선 백로그

상태: 리뷰 완료 · Redmine #578 등록 완료

범위: DDS 독립 인스턴스의 홈, 보호 연결, 권한 반영, 지식 검색, 보호 객체 상세, 공통 메뉴/흐름 바

대상 파일: dds-home.html, vpd-policies.html, dds-provision.html, vector-knowledge.html, dds.html, fragments/layout.html

Redmine 페이지별 리뷰

이슈	페이지	검토 초점
#579	로그인	관리자 콘솔 경계와 최소 안내
#580	홈	상태·다음 행동 중심 대시보드
#581	DDS 보호 연결	집행 모드·보호 상태·드리프트
#582	DDS 권한 반영	게시 안전성·영향·감사
#583	지식 검색	기본 제품 경로와 직접 비교 분리
#584	보호 객체 상세	실제 접근 근거 탐색
#585	공통 메뉴·구조 바	점진적 공개·용어·접근성

#581 구현 하위 일감

이슈	책임	검증 가능한 산출물
#606	보안 설계	Grant 기대값·실제 inventory·게시/검증 이력을 비교하는 상태 전이와 API 계약
#607	UX 설계	서비스 경로 기본 화면, 직접 비교 고급 탭, 상태·조치·오류 상태가 담긴 와이어프레임
#608	개발	객체 상태 화면, 드리프트 판정, 직접 비교 분리와 안전한 오류 처리
#609	QA	정상·미게시·드리프트·검증 실패·만료·inventory 오류 및 접근성 회귀 검증

상세 기준은 dds-protection-connection-review에 기록한다. #581은 이 네 일감의 완료 조건을 묶는 설계 기준이며, 화면 구현 자체는 #608에서 시작한다.

1. 검토 방식

같은 화면을 세 관점에서 검토했다.

페르소나	성공 기준	가장 민감한 실패
UI/UX 전문가	한 화면에서 한 가지 주 행동이 분명하고, 설명은 필요할 때만 열린다.	모든 정보가 같은 무게로 노출되어 사용자가 다음 행동을 고르지 못함
보안 설계자	DDS 집행 경계와 권한 변경의 영향이 틀림없이 드러난다.	토큰 Context 경로와 순수 DDS END USER 경로를 같은 의미처럼 오해함
운영 사용자	지금 상태, 다음 조치, 실패 원인을 짧은 시간에 파악한다.	설명을 읽어도 현재 객체가 보호되는지·게시가 필요한지 모름

2. 세 페르소나의 합의

1. 첫 화면은 설명이 아니라 상태와 다음 행동을 보여 준다.
2. 제품 기본 경로인 서비스 토큰 기반 검색과 보조 기술 검증인 DDS END USER 직접 비교를 같은 무게로 놓지 않는다.
3. DATA GRANT 게시·회수는 보안 변경이다. 단순 브라우저 confirm이 아니라 diff, 영향, 사유, 결과 검증이 필요하다.
4. Context, predicate, DATA GRANT 같은 기술 용어는 제거하지 않되, 기본 표면에서는 업무 결과로 번역하고 상세에서 근거를 보인다.
5. 홈·메뉴·객체 상세의 숫자는 단순 건수가 아니라 정상/미게시/드리프트/검증 실패 같은 운영 상태로 연결돼야 한다.

3. 핵심 설계 경계

현재 DDS 트랙에는 두 종류의 식별 경로가 공존한다. 이 둘을 명확히 구분하지 않으면 제품 사용자가 “Bearer 토큰만으로 DDS END USER가 된다”고 오해할 수 있다.

구분	기본 서비스 경로	보조 직접 비교 경로
사용자 식별	기술 사용자 세션 + Bearer로 만든 애플리케이션 Context	DDS END USER 직접 연결
집행	보호 객체별 DATA GRANT predicate가 공통 권한 테이블을 평가	END USER → DATA ROLE → DATA GRANT
목적	제품 기능: 권한 기반 지식 검색	DDS 선언형 권한 동작 검증
화면 위치	기본 경로	고급 검증/상세 화면

화면 표준 용어는 아래로 고정한다.

• 토큰 기반 서비스 경로: 제품에서 사용하는 기본 검색 경로
• DDS END USER 직접 비교: DDS Data Role/Data Grant 동작을 확인하는 고급 검증
• 보호 객체: DDS Data Grant가 연결된 VIEW/TABLE
• 권한 게시: 공통 권한의 변경을 DDS 선언으로 반영하는 보안 변경

4. 페이지별 리뷰

A. 홈 (/ · dds-home.html)

관점	관찰	합의된 개선
UI/UX	단계 카드, 매크로/마이크로, 숫자, 검증 대상이 같은 위계로 보여 첫 행동이 흐리다.	상단을 상태 요약과 추천 행동으로 재구성하고, 단계 카드는 상태가 있는 작업 카드로 전환한다.
설계	역할·권한 규칙 건수는 보호 상태를 보장하지 않는다.	보호 객체의 Grant 상태, 마지막 게시, 마지막 검색 검증, 드리프트 여부를 핵심 지표로 올린다.
운영	“오늘 무엇을 해야 하나?”에 답이 없다.	게시 필요, 검색 검증 필요, 정상 중 하나를 명확한 CTA로 제공한다.

완료 조건: 설명을 열지 않아도 보호 상태와 다음 행동을 파악하고, 두 번 이하의 클릭으로 수정·검증을 시작한다.

B. 지식 검색 (/vector-knowledge · vector-knowledge.html)

관점	관찰	합의된 개선
UI/UX	자료 등록, 권한 설정, 토큰 검색, END USER 직접 비교가 한 화면에 이어져 처음 보는 사용자는 두 검색의 목적을 구분하기 어렵다.	기본 표면은 자료 등록과 토큰 기반 서비스 검색에 집중하고, 직접 비교는 고급 검증으로 접거나 별도 화면으로 이동한다.
설계	토큰 경로와 END USER 경로의 집행·신뢰 경계가 다르다.	두 경로에 목적·입력·결과 해석을 다른 배지와 문구로 표시한다.
운영	결과가 0건일 때 권한 차단인지 검색 관련도 문제인지 판단하기 어렵다.	결과 상단에 사용자, 허용 TAG, 제외 수, 반환 수, 토큰 상태를 요약한다.

완료 조건: 일반 사용자는 토큰 검색 하나만으로 업무를 완료하고, 직접 비교는 의도적으로 고급 검증을 선택했을 때만 사용한다.

C. DDS 보호 연결 (/vpd-policies · vpd-policies.html)

관점	관찰	합의된 개선
UI/UX	DDS 화면인데 route와 일부 용어가 VPD를 드러내며, 설명은 많지만 보호 상태가 보이지 않는다.	표면 용어를 DDS 보호 객체로 통일하고, 객체 카드를 중심으로 정보 구조를 바꾼다.
설계	공통 권한 관리와 DDS 집행이 섞여 있고, 토큰 Context/END USER의 구분이 약하다.	객체마다 집행 모드, Grant 상태, predicate 버전, 마지막 검증을 보여 준다.
운영	어떤 객체가 미게시·드리프트·검증 실패인지 알 수 없다.	정상/미게시/드리프트/검증 실패 상태와 바로 실행 가능한 조치를 제공한다.

완료 조건: 한 화면에서 보호 객체의 상태, 집행 모드, 마지막 검증, 필요한 조치를 판별한다.

D. DDS 권한 반영 (/dds-provision · dds-provision.html)

관점	관찰	합의된 개선
UI/UX	큰 Grant 표와 SQL은 보이지만 변경 전후 차이와 영향이 먼저 보이지 않는다.	게시 전 요약을 추가/변경/회수/경고로 분리하고, 상세 SQL은 접는다.
설계	Data Grant 교체·회수는 권한 확대/축소를 만들 수 있는 보안 변경이다.	영향 사용자·객체·원문 컬럼, 게시 사유, 승인 확인, 검증 결과를 남긴다.
운영	브라우저 confirm만으로 게시하면 사후 근거와 실패 복구 경로가 부족하다.	미리보기 → 변경 사유 → 영향 확인 → 게시 → DB 결과/검증 단계로 바꾼다.

완료 조건: 게시 전에 영향과 변경 방향을 알 수 있고, 게시 후 결과·검증·재적용 기준이 감사 가능한 형태로 남는다.

E. 보호 객체 상세 (/dds · dds.html)

관점	관찰	합의된 개선
UI/UX	정적 세일즈 사례와 구현 단계가 길고 현재 접근 결과를 탐색하는 기능이 약하다.	기본 화면은 주체 → 규칙 → 보호 객체 → 결과 근거 체인으로 재구성한다.
설계	객체, 행 판단 컬럼, Grant, 공통 권한 규칙의 연결 근거가 한 번에 추적되지 않는다.	선택한 사용자/토큰 기준으로 적용된 Data Grant와 허용·차단 사유를 표시한다.
운영	차단됐을 때 토큰 문제인지 권한 문제인지 Grant 문제인지 모른다.	토큰 무효, 권한 없음, 객체 Grant 없음, TAG 불일치별 다음 조치를 제공한다.

완료 조건: 하나의 주체가 왜 허용·차단됐는지를 한 화면에서 추적하고, 정적 사례와 실제 상태를 혼동하지 않는다.

F. 공통 메뉴·구조 바 (fragments/layout.html)

관점	관찰	합의된 개선
UI/UX	모든 페이지에 긴 구조 설명과 메뉴가 반복되어 콘텐츠보다 프레임이 무겁다.	구조 바는 현재 단계·상태만 남기고 설명은 접는다. 메뉴는 기본 작업과 고급 검증을 분리한다.
설계	기술 경계가 반복 문구마다 조금씩 달라질 위험이 있다.	표준 용어와 상태 배지의 단일 사전을 적용한다.
운영	현재 위치와 다음 작업이 메뉴에서 분명하지 않다.	활성 메뉴, 경고 배지, 최근 실패 링크를 제공한다.

완료 조건: 화면 공통 프레임이 주 작업을 방해하지 않고, 같은 개념이 일관된 용어로 보인다.

5. 우선순위와 진행 순서

우선순위	개선 묶음	이유
P0	서비스 토큰 경로와 DDS END USER 직접 비교 경로 분리, 게시 안전 흐름	보안 의미를 잘못 전달하거나 권한 변경을 오조작할 위험
P1	홈 상태·다음 행동, 보호 객체 상태/드리프트 표시	운영자가 무엇을 해야 할지 판단하지 못하는 문제
P2	보호 객체 근거 체인, 공통 용어/점진적 공개/접근성	제품 학습 비용과 반복적인 설명 과다를 줄임
P3	모바일 밀도, 결과 시각화, 추가 자동화	기본 경로가 안정된 뒤 개선

6. 검증 시나리오

1. 세일즈 토큰으로 SALES 태그 자료만 검색된다.
2. 다른 부서 태그는 관련도가 높아도 제외된다.
3. 회수·만료 토큰은 사용자 정보와 자료를 표시하지 않는다.
4. DDS END USER 직접 비교에서 Grant 없음은 객체 미노출/차단으로 해석된다.
5. 권한 게시 화면은 변경·회수·경고·검증 결과를 구분해 보여 준다.
6. 키보드와 모바일에서도 기본 검색과 고급 검증을 혼동하지 않고 완료할 수 있다.