124 lines
9.5 KiB
Markdown
124 lines
9.5 KiB
Markdown
# DDS 트랙 페르소나 UX 리뷰 및 개선 백로그
|
|
|
|
> **상태**: 리뷰 완료 · Redmine 등록 진행
|
|
>
|
|
> **범위**: DDS 독립 인스턴스의 홈, 보호 연결, 권한 반영, 지식 검색, 보호 객체 상세, 공통 메뉴/흐름 바
|
|
>
|
|
> **대상 파일**: `dds-home.html`, `vpd-policies.html`, `dds-provision.html`, `vector-knowledge.html`, `dds.html`, `fragments/layout.html`
|
|
|
|
## 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. 키보드와 모바일에서도 기본 검색과 고급 검증을 혼동하지 않고 완료할 수 있다.
|