# 데이터 접근 제어 백오피스 전체 UX/기능 리뷰

작성일: 2026-07-13
범위: 현재 Spring Boot 백오피스 화면, VPD/ASO/ORDS/MCP/Select AI 운영 흐름
상태: 1차 P0 UX 보강 구현/배포 완료 — 2026-07-14

## 1. 결론

단순 문구 정리만으로는 충분하지 않다. 지금 화면은 기능은 많이 들어와 있지만, 사용자가 “업무 규칙을 넣으면 DB에서 어떻게 행/컬럼으로 적용되는가”를 끝까지 따라가기 어렵다.

가장 큰 개선 축은 세 가지다.

1. 전체 흐름을 작업 단위로 묶어야 한다.
   - 사용자/역할 생성
   - 행 접근 규칙 등록
   - 보호 정책 연결
   - 컬럼 마스킹 설정
   - 토큰 발급
   - 실제 접근 검증

2. 화면별 기본/고급을 분리해야 한다.
   - 기본 화면: 업무 의미, 현재 상태, 다음 버튼, 검증 결과
   - 고급 화면: VPD predicate, PL/SQL source, ORDS handler, raw JSON, SQL trace

3. 모든 설정 화면에서 “설정값 → DB 적용 → 실제 검증”이 이어져야 한다.
   - 지금은 각 화면이 기능 단위로는 존재하지만, 다음 단계 연결과 검증 루프가 약하다.

## 1.1 2026-07-14 반영 결과

이 리뷰의 P0 항목 중 화면 설명·상태 요약·검증 흐름 보강으로 처리 가능한 범위를 먼저 반영했다. DB VPD/ASO 정책 함수, 권한 계산 로직, ORDS 실행 경로는 변경하지 않았다.

| P0 항목 | 반영 상태 | 근거 |
|---|---|---|
| 대시보드 전체 그림 + 체크리스트 | 반영 | `dashboard.html`, `app.css` |
| 접근 검증 결과의 단계형 설명 | 반영 | `probe.html`, `fragments/probe-result.html` |
| 행 접근 규칙 predicate 변환 설명 | 반영 | `permissions.html` |
| 컬럼 마스킹 단계/사용자별 결과 설명 | 반영 | `masking-rules.html` |
| 운영 현황 health 요약 | 반영 | `OperationHealthSummary.java`, `operation-status.html` |

검증 결과:

- 커밋: `a40102a Improve data access control UX guidance`
- 테스트: `mvn -q test` 통과
- 패키징: `mvn -q -DskipTests package` 통과
- 배포: `161.33.6.45`의 `vpd-backoffice.service` active
- 공개 확인: `https://kb.cloud-handson.com/login`에서 `데이터 접근 제어 콘솔` 확인

## 2. 페르소나별 핵심 불만

| 페르소나 | 현재 불만 | 필요한 개선 |
|---|---|---|
| 일반 사용자 | VPD/ASO/ORDS/MCP가 섞여 무엇을 눌러야 할지 모른다 | “이 사용자는 무엇을 볼 수 있나?” 중심의 단순 경로 |
| 운영 관리자 | 변경 전후 영향과 실제 적용 여부를 한 번에 보기 어렵다 | 영향 사용자, 대상 객체, 검증 버튼, 최근 결과 |
| 적용 담당자 | 업무 조건이 WHERE predicate로 바뀌는 연결이 화면마다 끊긴다 | 업무 조건 → 저장 rule → VPD/ASO 해석 → 검증 결과 |
| DB 관리자 | 백오피스 설정과 DB 실제 정책이 일치하는지 증적이 부족하다 | DBMS_RLS/DBMS_REDACT/FGA/ORDS 상태를 한곳에서 확인 |
| 보안 담당자 | guest/read-only, 토큰 처리, 원문 표시 예외의 경계가 더 명확해야 한다 | 변경 가능 여부, 원문 표시 범위, 감사 증적 |
| 데모/영업 사용자 | KB 보험 시나리오가 화면 흐름으로 자연스럽게 보이지 않는다 | 설계사/지점장/관리자 시나리오 preset과 결과 비교 |

## 3. 우선순위 개선안

### P0. 반드시 해야 할 개선

#### 3.1 대시보드를 “전체 그림 + 오늘 할 일” 중심으로 재구성

현재 대시보드는 구조 설명은 좋아졌지만, 사용자가 다음 행동을 결정하기에는 아직 기능 나열에 가깝다.

개선:

- 상단에 3개 핵심 카드:
  - 행 접근: “누가 어떤 행을 보는가”
  - 컬럼 마스킹: “허용된 행의 어떤 컬럼을 원문/마스킹으로 보는가”
  - 접근 검증: “토큰으로 실제 DB 결과를 확인한다”
- “처음 설정” 체크리스트:
  1. 사용자/역할 준비
  2. 행 접근 규칙 등록
  3. 보호 상태 적용
  4. 컬럼 마스킹 연결
  5. 토큰 발급
  6. 접근 검증
- DB 상태 요약:
  - VPD 정책 누락 수
  - ASO 정책 불일치 수
  - ORDS handler 누락 수
  - 최근 검증 실패 수

#### 3.2 접근 검증 결과 화면을 탭/단계형으로 재설계

접근 검증은 이 백오피스의 최종 판단 화면이다. 현재도 결과는 나오지만, “왜 그렇게 나왔는지”를 단계별로 보기에는 부족하다.

개선:

- 결과를 4개 섹션으로 분리:
  1. 토큰 해석 결과: 사용자, stakeholder, role, channel
  2. 행 접근 결과: 반환 행 수, 적용된 VPD predicate, ALLOW/DENY 근거
  3. 컬럼 마스킹 결과: 마스킹 대상 컬럼, 원문 허용 여부, ASO policy 상태
  4. DB 감사 증적: FGA SQL, RLS_INFO, request id
- 잘못된 토큰은 DB 오류처럼 보이지 않게:
  - 토큰 없음
  - 등록되지 않은 토큰
  - 만료/회수 토큰
  - 권한 없음
  을 분리한다.
- 결과 테이블에서 마스킹된 컬럼에 아이콘/툴팁 표시.

#### 3.3 행 접근 규칙 화면에 “업무 조건 → predicate 변환”을 더 강하게 표시

현재도 wizard와 preview가 있으나, 적용 담당자가 원하는 것은 “내가 고른 업무 조건이 실제 어떤 WHERE 조각이 되는가”다.

개선:

- 조건 선택 옆에 즉시 preview:
  - 본인 담당 계약 → `FC_ID = SYS_CONTEXT(...STAKEHOLDER_USER_ID...)`
  - 채널 고객 → `EXISTS (...) FC_CHANNEL = SYS_CONTEXT(...STAKEHOLDER_CHANNEL...)`
  - 정적 SQL 조건 → 검증된 현재 객체 컬럼 조건만 허용
- 목록 기본값은 raw rule보다 업무 문장 우선.
- 상세에는 저장 rule, 변환 predicate, 결합 방식(AND/OR/DENY)을 같이 표시.
- 삭제/변경 시 영향 사용자 수와 최근 검증 결과 링크 표시.

#### 3.4 컬럼 마스킹 화면에서 설정 단계와 DB 적용 상태를 더 선명하게 분리

지금 기능은 맞지만 사용자에게는 “대상 컬럼 추가”, “규칙 연결”, “사용자 원문 허용”, “DB 정책 동기화”가 섞여 보일 수 있다.

개선:

- 단계형 표시:
  1. 마스킹 후보 컬럼 등록
  2. 기본 마스킹 규칙 연결
  3. 원문 표시 허용 사용자 지정
  4. DB ASO 정책 동기화 상태 확인
- 컬럼별 “현재 실제 동작” preview:
  - 일반 사용자: 마스킹
  - 원문 허용 사용자: 원문
  - 행 접근 권한 없는 사용자: 행 없음
- DBMS_REDACT 정책 상태와 백오피스 설정 차이를 컬럼 단위로 표시.

#### 3.5 운영 현황을 통합 health dashboard로 강화

현재 운영 현황은 표가 있지만, 장애 상황에서 “무엇이 문제인지”를 바로 알려주는 구조가 약하다.

개선:

- 상단 전체 상태:
  - 정상 / 주의 / 장애
- 영역별 health:
  - App 로그인/세션
  - DB 연결
  - VPD 정책
  - ASO 정책
  - ORDS handler
  - MCP/Select AI endpoint
- 각 상태에:
  - 마지막 확인 시각
  - 영향받는 기능
  - 다음 조치
  - 관련 화면 이동 링크

## 4. 화면별 추가 리뷰

| 화면 | 현재 상태 | 남은 개선 |
|---|---|---|
| 로그인 | 제품명 정리됨 | 백오피스 계정과 업무 사용자 토큰이 다르다는 안내, guest/read-only 안내 보강 |
| 대시보드 | 전체 구조 설명 있음 | 실제 작업 체크리스트와 상태 요약 부족 |
| 사용자 | application user 설명 있음 | `KB_STAKEHOLDERS` 매핑 상태, 직접 역할/그룹 역할/토큰 발급 링크 부족 |
| 그룹 | 영향 사용자/역할 일부 표시 | 그룹이 지점/채널 조건이 아니라 역할 상속 단위라는 설명 보강 |
| 역할 | 삭제 영향 표시 있음 | 역할별 접근 규칙 수, 원문 허용 컬럼 수, 영향 사용자 요약 보강 |
| 행 접근 규칙 | wizard와 preview 있음 | 업무 조건별 predicate preview, 삭제 영향/검증 링크 보강 |
| 컬럼 원문 표시 허용 | VPD/ASO 경계 설명 있음 | 조건부 원문 허용이 아니라 사용자 단위 UNMASK라는 한계 명시 필요 |
| 사용자별 접근 확인 | 설정 기반 권한 확인 가능 | 실제 DB 결과가 아니라 예상 권한이라는 구분과 접근 검증 CTA 강화 |
| 보호 상태 | VPD 적용 상태 확인 가능 | `설정됨 / DB 적용됨 / 최근 검증 성공` 3단계 배지 필요 |
| 컬럼 마스킹 | ASO 동기화 기능 있음 | 컬럼별 실제 사용자 결과 preview와 정책 불일치 원인 설명 필요 |
| 검증 세션 | 토큰 발급/이력 있음 | “토큰은 권한을 담지 않고 사용자 식별만 한다”를 더 강하게 표시 |
| 접근 검증 | 핵심 검증 가능 | 결과를 토큰/context/행/컬럼/감사 증적으로 분리 필요 |
| 조회 대상 | ORDS 대상 등록 가능 | 신규 대상 등록 후 다음 단계 안내 부족 |
| 정형 데이터 조회 | 관리자 preview 가능 | 사용자별 접근 결과가 아님을 더 강하게 표시, 권한 기준 컬럼 배지 필요 |
| 조회 연동 | ORDS source 확인 가능 | 기본은 endpoint 상태, source는 Advanced로 더 숨기는 편이 좋음 |
| 지식 검색 | 등록/검색/정책이 한 화면 | 자료 등록, 접근 정책, 검색 검증을 탭으로 분리 필요 |
| 대화형 검색 | 자연어 질의 가능 | 결과를 답변/정형 결과/근거 문서/오류 원인으로 분리 필요 |
| 검색 해석 | 라우팅 결과 확인 가능 | 단계별 타임라인과 소요시간, showprompt/showsql Advanced 필요 |
| MCP 서비스 | endpoint/tool 설명 있음 | 복사 가능한 client 설정 명세와 curl 예시를 상단에 제공 |
| 연동 점검 | client 호출 가능 | 연결 가능/도구 호출 가능/권한 적용 결과 3단계 health 필요 |
| 운영 현황 | 정책/ORDS/ASO 상태 표 있음 | 통합 health, 최근 확인 시각, 영향 범위, 조치 링크 필요 |
| 행 접근 필터 구조 | 기술 흐름 있음 | 함수 소스보다 블록별 설명과 Git/DB source 차이 표시가 우선 |
| DB 메타데이터 | comment/annotation 수정 가능 | 권한 기준 컬럼 배지, Select AI 실패 리포트와 연결 필요 |
| 보안 SQL 스크립트 | 원문/LLM 설명 가능 | 스크립트별 목적/대상/변경 정책/검증 방법 summary card 필요 |
| 고급 접근 조건 | Advanced 성격 있음 | 기본 접근 규칙으로 해결 가능한지 체크리스트 선행 필요 |
| 시스템 설정 | ORDS Base URL 관리 | 저장 후 자동 health check와 영향 기능 표시 필요 |
| DB 준비 상태 | preflight와 DDL 있음 | 확인 작업과 변경 작업을 더 강하게 분리, 실행 전 영향 요약 필요 |

## 5. 설계상 더 명확히 해야 할 원칙

### 5.1 토큰은 권한 묶음이 아니다

토큰은 사용자를 식별하고 context를 세팅하는 열쇠다. 실제 권한은 요청 시점에 사용자/그룹/역할/행 접근 규칙/마스킹 규칙을 조회해서 계산된다.

화면 전반에 이 문장을 반복해야 한다.

### 5.2 VPD와 ASO의 결합 방식

- VPD는 행을 줄인다.
- ASO는 남은 행의 컬럼 표시 방식을 바꾼다.
- 원문 표시 허용은 행 접근 권한을 늘리지 않는다.
- 행 접근 권한이 없으면 ASO 원문 허용도 의미가 없다.

### 5.3 “집계만 허용”은 별도 설계가 필요하다

ASO로 마스킹된 컬럼에 대해 자연스럽게 집계가 된다고 가정하면 안 된다. 지점장에게 상세는 마스킹하고 집계만 허용하려면 trusted API, aggregate 전용 path, 또는 별도 검증 가능한 query boundary가 필요하다.

### 5.4 Select AI 품질은 메타데이터 운영 문제다

자연어 질의 실패를 프롬프트로만 해결하면 재현성이 떨어진다. 테이블/컬럼 comment, annotation, constraint, 업무명, 조인 키를 운영자가 보강하는 흐름이 있어야 한다.

## 6. 추천 구현 순서

### 1차: 운영 사고를 줄이는 P0

1. 접근 검증 결과 화면 재구성
2. 운영 현황 health dashboard 강화
3. 행 접근 규칙 predicate preview/영향도 강화
4. 컬럼 마스킹 단계형 구성과 사용자별 preview

### 2차: 온보딩과 이해도 개선

1. 대시보드 체크리스트와 상태 요약
2. 사용자/역할/그룹 영향도 보강
3. 보호 상태 3단계 배지
4. 조회 대상 등록 후 다음 단계 안내

### 3차: MCP/Select AI 품질과 고급 운영

1. DB 메타데이터 권한 기준 컬럼 배지
2. MCP/검색 결과 타임라인과 소요시간 표시
3. 보안 SQL 스크립트 summary card
4. 고급 접근 조건 체크리스트와 검증 강화