# VPD·ASO 권한 운영 페이지별 페르소나 리뷰

> 상태: Review only
> 작성일: 2026-07-13
> 범위: 현재 Spring Boot 백오피스 화면을 기준으로, 구현 변경 없이 페이지별 개선 의견만 정리

## 1. 이번 리뷰의 전제

이 백오피스의 핵심 목적은 Oracle DB에서 VPD와 ASO(Data Redaction)를 조합해 사용자별 데이터 접근 범위를 운영하는 것이다.

- VPD는 행을 남기거나 제외한다. 토큰이 직접 VPD 함수에 전달되는 것이 아니라, 토큰 검증 후 세션 컨텍스트(`CB_AGENT_CTX`)에 들어간 값이 VPD 필터의 조건으로 쓰인다.
- ASO는 컬럼 값을 원문 또는 마스킹 값으로 반환한다. ASO 정책은 세션 컨텍스트의 `MR_<column_id>` 같은 값을 보고 원문 표시 여부를 판단한다.
- 백오피스에서 등록하는 접근 규칙은 최종 SQL 그 자체가 아니라, VPD 필터가 읽어 SQL predicate로 바꾸는 매핑 데이터다.
- 일반 운영자는 SQL 함수 구조보다 “이 사용자에게 어떤 테이블/행/컬럼이 어떻게 보이는가”를 먼저 이해해야 한다.

## 2. 리뷰 페르소나

| 페르소나 | 관심사 | 실패로 보는 상황 |
|---|---|---|
| 일반 사용자 | 검증 토큰으로 실제 결과를 확인하고 싶다 | VPD, ASO, ORDS, MCP 용어 때문에 무엇을 눌러야 할지 모름 |
| 운영 관리자 | 사용자·역할·권한·마스킹 설정을 안전하게 바꾸고 싶다 | 설정 변경의 영향 범위와 검증 방법이 분리되어 있음 |
| 적용 담당자 | 업무 규칙을 DB 적용 가능한 설정으로 옮기고 싶다 | “본인계약”, “채널내 전체”, “원문 허용”이 실제 필터/컨텍스트와 어떻게 연결되는지 안 보임 |
| DB 관리자 | DB에 어떤 정책과 스크립트가 적용됐는지 확인하고 싶다 | 백오피스 설정과 DBMS_RLS/DBMS_REDACT 실제 상태가 맞는지 증적이 부족함 |

## 3. 공통 개선 원칙

1. 기본 화면은 “현재 상태, 주요 행동, 검증 버튼” 중심으로 둔다.
2. SQL, 패키지, ORDS, VPD 함수, Redaction expression은 Advanced 또는 도움말로 보낸다.
3. 모든 권한 화면은 `업무 표현 → 저장 설정 → VPD/ASO 해석 → 검증 결과` 순서로 설명한다.
4. VPD와 ASO를 섞어 말하지 않는다.
   - VPD: 어떤 행을 볼 수 있는가.
   - ASO: 허용된 행의 어떤 컬럼을 원문으로 볼 수 있는가.
5. 권한 설정 화면에서는 “이 조건이 그대로 DB에 붙는다”가 아니라 “이 설정값을 필터가 읽어 WHERE 조건을 만든다”라고 표현한다.
6. 간단한 설정을 기본으로 두고, 조건식·정책명·패키지명·스키마명은 Advanced에서 확인하게 한다.

## 4. 페이지별 리뷰 파일

| 영역 | 페이지 | 리뷰 파일 |
|---|---|---|
| 시작 | 로그인 | [00-login.md](pages/00-login.md) |
| 시작 | 대시보드 | [01-dashboard.md](pages/01-dashboard.md) |
| 권한 주체 | 사용자 | [02-users.md](pages/02-users.md) |
| 권한 주체 | 그룹 | [03-groups.md](pages/03-groups.md) |
| 권한 주체 | 역할 | [04-roles.md](pages/04-roles.md) |
| 권한 설정 | 접근 규칙 | [05-permissions.md](pages/05-permissions.md) |
| 권한 설정 | 원문 조회 허용 사용자 | [06-user-masking-rules.md](pages/06-user-masking-rules.md) |
| 권한 설정 | 사용자별 접근 확인 | [07-effective-matrix.md](pages/07-effective-matrix.md) |
| 보호·검증 | 보호 상태 | [08-vpd-policies.md](pages/08-vpd-policies.md) |
| 보호·검증 | 마스킹 규칙 | [09-masking-rules.md](pages/09-masking-rules.md) |
| 보호·검증 | 검증 세션 | [10-tokens.md](pages/10-tokens.md) |
| 보호·검증 | 접근 검증 | [11-probe.md](pages/11-probe.md) |
| 연동 | 조회 대상 | [12-objects.md](pages/12-objects.md) |
| 연동 | 정형 데이터 조회 | [13-structured-data.md](pages/13-structured-data.md) |
| 연동 | 조회 연동 | [14-ords-handlers.md](pages/14-ords-handlers.md) |
| 연동 | 지식 검색 | [15-vector-knowledge.md](pages/15-vector-knowledge.md) |
| 연동 | 대화형 검색 | [16-mcp-chatbot.md](pages/16-mcp-chatbot.md) |
| 연동 | 검색 해석 | [17-mcp-reasoning.md](pages/17-mcp-reasoning.md) |
| 연동 | MCP 서비스 | [18-mcp-sse.md](pages/18-mcp-sse.md) |
| 연동 | 연동 점검 | [19-mcp-client-demo.md](pages/19-mcp-client-demo.md) |
| 운영 | 운영 현황 | [20-operation-status.md](pages/20-operation-status.md) |
| 관리자 | VPD 필터 구조 | [21-vpd-filter-runtime.md](pages/21-vpd-filter-runtime.md) |
| 관리자 | DB 메타데이터 | [22-schema-metadata.md](pages/22-schema-metadata.md) |
| 관리자 | 보안 SQL 스크립트 | [23-security-sql-scripts.md](pages/23-security-sql-scripts.md) |
| 관리자 | 고급 접근 조건 | [24-vpd-filter-policies.md](pages/24-vpd-filter-policies.md) |
| 관리자 | 시스템 설정 | [25-settings.md](pages/25-settings.md) |
| 관리자 | DB 준비 상태 | [26-settings-database.md](pages/26-settings-database.md) |

## 5. 적용 우선순위 제안

| 우선순위 | 대상 | 이유 |
|---|---|---|
| P0 | 접근 규칙, 마스킹 규칙, 원문 조회 허용 사용자, 접근 검증 | 사용자가 VPD/ASO의 차이와 실제 적용 방식을 가장 많이 혼동하는 지점 |
| P0 | 보호 상태, 운영 현황 | DB 실제 적용 상태와 백오피스 설정 상태를 구분해야 장애 판단이 가능 |
| P1 | 사용자, 그룹, 역할, 사용자별 접근 확인 | 권한 주체와 상속 경로를 업무 담당자가 이해하기 쉽게 해야 함 |
| P1 | DB 메타데이터, 보안 SQL 스크립트, VPD 필터 구조 | 적용 담당자와 DB 관리자의 증적 확인 화면 |
| P2 | MCP/Select AI/Vector 연동 화면 | 기능 자체보다 권한이 적용된 호출 흐름과 지연 원인을 보여주는 방향으로 정리 |

## 6. 구현 전 확인할 설계 판단

- ASO는 컬럼 마스킹만 담당하고, 행 접근은 VPD만 담당한다는 원칙을 화면 문구와 메뉴명에 일관되게 반영한다.
- “원문 조회 허용 사용자”는 현재 사용자 단위 UNMASK 예외 중심이다. 향후 “내 담당 고객은 원문, 타인은 마스킹” 같은 조건부 원문 표시가 필요하면 VPD로 행 범위를 먼저 제한하고 ASO 컨텍스트 계산 방식을 확장해야 한다.
- 지점장 집계 요구는 ASO 마스킹 컬럼에 직접 `SUM`을 걸어 해결한다고 가정하면 안 된다. 집계 전용 trusted path나 별도 검증 가능한 API 설계가 필요하다.
- Select AI용 메타데이터 화면은 자연어 질의 품질에 직접 영향을 주므로, 단순 주석 편집이 아니라 “이 컬럼이 어떤 업무 의미인지”를 사람이 이해하고 보강하는 화면으로 다뤄야 한다.
