Consolidate data access control backoffice updates

docs/design/621-vpd-aso-persona-page-review/README.md

@@ -0,0 +1,83 @@
+# 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용 메타데이터 화면은 자연어 질의 품질에 직접 영향을 주므로, 단순 주석 편집이 아니라 “이 컬럼이 어떤 업무 의미인지”를 사람이 이해하고 보강하는 화면으로 다뤄야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/00-login.md

@@ -0,0 +1,28 @@
+# 로그인 페이지 리뷰
+
+- URL: `/login`
+- 현재 목적: 백오피스 계정으로 VPD 권한 운영 콘솔에 진입한다.
+- VPD/ASO 관련성: 로그인 계정은 백오피스 운영 권한이고, 검증 토큰의 업무 사용자와 다르다.
+
+## 페르소나 의견
+
+- 일반 사용자: 로그인한 계정과 나중에 발급하는 VPD 검증 토큰의 사용자가 같은 것인지 헷갈릴 수 있다.
+- 운영 관리자: 관리자 계정과 guest 계정의 차이가 첫 화면에서 보이면 안전하다.
+- 적용 담당자: “운영 콘솔 로그인”과 “DB 접근 토큰 검증”이 다른 단계임을 알아야 한다.
+- DB 관리자: 이 로그인은 DB 계정 로그인이 아니라 애플리케이션 계정이라는 점이 명확해야 한다.
+
+## 가벼운 개선
+
+1. 로그인 카드 하단에 “이 계정은 백오피스 화면 접근용이며, 실제 VPD 검증은 검증 세션 토큰으로 수행합니다.” 문구를 추가한다.
+2. guest 계정은 읽기 전용임을 로그인 후 배너뿐 아니라 로그인 화면 안내에도 짧게 표시한다.
+3. 로그인 유지 체크박스는 “이 브라우저에서 유지”처럼 보안 범위를 명확히 쓴다.
+
+## Advanced로 둘 내용
+
+- 세션 쿠키 만료 정책
+- 권한별 접근 가능 URL
+- guest read-only 서버 정책
+
+## 우선순위
+
+P2. 혼동을 줄이는 문구 개선이 중심이고, 권한 계산 로직에는 영향이 없다.

docs/design/621-vpd-aso-persona-page-review/pages/01-dashboard.md

@@ -0,0 +1,28 @@
+# 대시보드 리뷰
+
+- URL: `/`
+- 현재 목적: 권한 운영 흐름, 메뉴 안내, 현재 검증 가능한 데이터를 보여준다.
+- VPD/ASO 관련성: VPD 행 필터와 ASO 컬럼 마스킹의 전체 업무 흐름을 처음 설명하는 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: “권한 관리 → 보호·검증 → 연동” 흐름은 좋지만, VPD와 ASO의 차이는 한 문장으로 먼저 보여야 한다.
+- 운영 관리자: 오늘 해야 할 일, 예를 들면 “접근 규칙 수정”, “검증 세션 발급”, “DB 적용 상태 확인”이 바로 보여야 한다.
+- 적용 담당자: 업무 규칙이 필터 조건으로 변환되는 구조가 대시보드에서 먼저 잡혀야 한다.
+- DB 관리자: 실제 DB 정책 상태와 백오피스 설정 상태가 어디에서 확인되는지 바로 연결되어야 한다.
+
+## 가벼운 개선
+
+1. 상단에 `VPD = 행 제한`, `ASO = 컬럼 마스킹`, `Probe = 실제 결과 검증` 3개 요약 카드를 둔다.
+2. “권한 설정값은 VPD 함수가 읽어 WHERE 조건으로 바꿉니다”라는 짧은 설명을 접근 규칙 카드에 붙인다.
+3. “현재 DB 적용 상태” 요약을 보호 상태 또는 운영 현황으로 바로 연결한다.
+
+## Advanced로 둘 내용
+
+- VPD 함수 내부 흐름
+- ASO Data Redaction expression
+- ORDS/MCP 호출 구조
+
+## 우선순위
+
+P1. 홈에서 전체 모델을 정확히 잡으면 다른 화면의 설명량을 줄일 수 있다.

docs/design/621-vpd-aso-persona-page-review/pages/02-users.md

@@ -0,0 +1,28 @@
+# 사용자 페이지 리뷰
+
+- URL: `/users`
+- 현재 목적: 백오피스 권한 모델의 사용자 생성, 목록 확인, 사용자 역할 부여를 수행한다.
+- VPD/ASO 관련성: 사용자는 VPD 필터가 읽는 역할·권한의 출발점이며, ASO 원문 허용 설정의 대상이 된다.
+
+## 페르소나 의견
+
+- 일반 사용자: 여기의 사용자가 실제 보험 설계사/지점장인지, 백오피스 계정인지 구분하기 어렵다.
+- 운영 관리자: 사용자 선택 후 “이 사용자가 최종적으로 어떤 역할과 보호 객체를 갖는지”를 바로 보고 싶다.
+- 적용 담당자: `KB_STAKEHOLDERS`와 토큰 주체의 관계가 사용자 화면에서 보이지 않으면 업무 사용자 매핑을 놓칠 수 있다.
+- DB 관리자: 사용자 추가가 DB 계정 생성이 아니라 애플리케이션 권한 데이터 추가라는 점이 필요하다.
+
+## 가벼운 개선
+
+1. 사용자 상세에 “직접 역할, 그룹 상속 역할, 원문 허용 컬럼, 발급 가능 토큰” 요약을 추가한다.
+2. VPD 데모 사용자라면 `KB_STAKEHOLDERS.USER_ID` 매핑 상태를 배지로 표시한다.
+3. 역할 부여 후 바로 “사용자별 접근 확인”과 “접근 검증”으로 이동하는 버튼을 둔다.
+
+## Advanced로 둘 내용
+
+- 내부 테이블명 `CB_APP_USER`, `CB_USER_ROLE`
+- 그룹 상속 SQL
+- DB 계정과 애플리케이션 사용자의 차이 상세
+
+## 우선순위
+
+P1. 권한 주체를 이해해야 접근 규칙과 토큰 검증의 혼동이 줄어든다.

docs/design/621-vpd-aso-persona-page-review/pages/03-groups.md

@@ -0,0 +1,27 @@
+# 그룹 페이지 리뷰
+
+- URL: `/groups`
+- 현재 목적: 그룹 생성, 그룹 사용자 연결, 그룹 역할 연결을 관리한다.
+- VPD/ASO 관련성: 그룹 역할은 VPD 필터의 effective role 계산에 포함된다.
+
+## 페르소나 의견
+
+- 일반 사용자: 그룹이 실제 조직 지점인지, 권한 묶음인지 알기 어렵다.
+- 운영 관리자: 그룹에 역할을 추가하면 몇 명의 사용자가 영향을 받는지 먼저 봐야 한다.
+- 적용 담당자: 지점·채널 같은 업무 조직과 권한 그룹의 차이를 표시해야 오해가 줄어든다.
+- DB 관리자: 그룹은 VPD predicate에 직접 들어가는 값이 아니라 역할 상속 경로라는 점이 필요하다.
+
+## 가벼운 개선
+
+1. 그룹 선택 시 영향 사용자 수와 상속 역할 목록을 상단에 고정한다.
+2. “그룹은 역할을 묶어 부여하는 운영 단위입니다. 지점/채널 조건은 접근 규칙 또는 stakeholder context에서 평가됩니다.” 문구를 추가한다.
+3. 그룹 역할 변경 후 사용자별 접근 확인으로 이동시키는 CTA를 제공한다.
+
+## Advanced로 둘 내용
+
+- `CB_USER_GROUP`, `CB_GROUP_ROLE` 조인 구조
+- active group만 effective role에 포함되는 조건
+
+## 우선순위
+
+P1. 운영 관리자가 대량 영향 변경을 안전하게 이해하는 데 필요하다.

docs/design/621-vpd-aso-persona-page-review/pages/04-roles.md

@@ -0,0 +1,28 @@
+# 역할 페이지 리뷰
+
+- URL: `/roles`
+- 현재 목적: 역할 생성과 역할 목록 관리를 수행한다.
+- VPD/ASO 관련성: 역할은 접근 규칙과 원문 조회 예외를 연결하는 핵심 단위다.
+
+## 페르소나 의견
+
+- 일반 사용자: 역할 이름만 봐서는 어떤 데이터 범위를 의미하는지 알기 어렵다.
+- 운영 관리자: 역할 삭제나 이름 변경 전에 연결된 사용자·그룹·권한 수가 먼저 보여야 한다.
+- 적용 담당자: “설계사”, “지점장”, “VPD 관리자” 같은 업무 역할과 DB 정책 적용 결과를 같이 보고 싶다.
+- DB 관리자: 역할은 Oracle role이 아니라 백오피스 권한 테이블의 역할이라는 점이 명확해야 한다.
+
+## 가벼운 개선
+
+1. 역할 목록에 연결 사용자 수, 그룹 수, 접근 규칙 수, 원문 허용 규칙 수를 표시한다.
+2. 역할 상세에서 “이 역할이 만드는 VPD/ASO 효과”를 업무 문장으로 요약한다.
+3. 삭제 버튼은 영향 상세 확인 후 노출한다.
+
+## Advanced로 둘 내용
+
+- 내부 role_id
+- 권한 테이블 조인 구조
+- Oracle DB role과의 차이
+
+## 우선순위
+
+P1. 접근 규칙의 주체가 역할이므로 사용자 영향도를 쉽게 보여줘야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/05-permissions.md

@@ -0,0 +1,36 @@
+# 접근 규칙 페이지 리뷰
+
+- URL: `/permissions`
+- 현재 목적: 역할별 보호 객체 접근 규칙을 등록하고 관리한다.
+- VPD/ASO 관련성: 이 화면의 설정은 VPD 필터가 읽어 대상 테이블의 WHERE predicate로 변환한다.
+
+## 페르소나 의견
+
+- 일반 사용자: `CUST_ID = token stakeholder` 같은 축약 표현은 실제 적용 방식을 이해하기 어렵다.
+- 운영 관리자: 저장한 조건이 “최종 SQL”인지 “필터가 읽는 설정값”인지 명확해야 한다.
+- 적용 담당자: 업무 조건을 고르는 방식이어야 한다. 예: 본인 계약, 내 채널 계약, 전체 허용, 정적 SQL 조건.
+- DB 관리자: STATIC_SQL 같은 고급 조건은 검증·차단 규칙과 함께 보여야 한다.
+
+## 가벼운 개선
+
+1. 기본 입력은 업무 조건 선택형으로 둔다.
+   - 전체 행 허용
+   - 본인 계약
+   - 내 채널 계약
+   - 담당 고객
+   - 내 채널 고객
+2. 각 조건 옆에 “필터 변환 예시”를 접힌 형태로 보여준다.
+   - 예: 본인 계약 → `FC_ID = SYS_CONTEXT('CB_AGENT_CTX', 'STAKEHOLDER_USER_ID')`
+3. 목록에는 저장된 rule_type보다 업무 문장을 먼저 보여준다.
+4. STATIC_SQL은 Advanced 영역으로 이동하고, “검증된 컬럼 조건만 허용”을 명시한다.
+
+## Advanced로 둘 내용
+
+- rule_type, rule_column, rule_value 원본
+- 생성되는 VPD predicate 예시
+- safe_static_predicate 방어 규칙
+- ALLOW/DENY 결합 방식
+
+## 우선순위
+
+P0. 사용자가 가장 많이 오해하는 화면이다. “설정값을 필터가 WHERE로 바꾼다”는 표현을 반드시 강화해야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/06-user-masking-rules.md

@@ -0,0 +1,28 @@
+# 원문 조회 허용 사용자 페이지 리뷰
+
+- URL: `/user-masking-rules`
+- 현재 목적: ASO 마스킹 대상 컬럼에 대해 특정 사용자에게 원문 조회 예외를 준다.
+- VPD/ASO 관련성: VPD로 허용된 행 안에서 특정 컬럼을 원문으로 볼 수 있는지 결정한다.
+
+## 페르소나 의견
+
+- 일반 사용자: “원문 허용”이 행 접근 권한까지 주는 것처럼 보일 수 있다.
+- 운영 관리자: 특정 사용자에게 컬럼 원문을 허용하면 어떤 테이블/컬럼에 영향이 있는지 바로 봐야 한다.
+- 적용 담당자: “자기 고객이면 원문, 타 고객이면 마스킹” 같은 조건부 요구는 현재 단순 UNMASK 예외와 다르다는 점이 필요하다.
+- DB 관리자: 이 설정은 ASO expression이 읽는 세션 context를 만드는 입력값이라는 설명이 필요하다.
+
+## 가벼운 개선
+
+1. 상단 문구를 “행 접근은 VPD가 결정하고, 이 화면은 허용된 행의 컬럼 원문 표시만 결정합니다.”로 고정한다.
+2. 사용자 선택 시 “이 사용자가 VPD로 볼 수 있는 행 범위” 링크를 접근 검증으로 연결한다.
+3. 단순 원문 허용과 조건부 원문 허용의 차이를 안내한다.
+
+## Advanced로 둘 내용
+
+- `set_masking_rule_context(user_id)` 흐름
+- `MR_<column_id>` 세션 컨텍스트
+- `DBMS_REDACT.UPDATE_POLICY_EXPRESSION` 적용 방식
+
+## 우선순위
+
+P0. VPD와 ASO 권한을 섞어 이해하면 운영 사고로 이어질 수 있다.

docs/design/621-vpd-aso-persona-page-review/pages/07-effective-matrix.md

@@ -0,0 +1,28 @@
+# 사용자별 접근 확인 페이지 리뷰
+
+- URL: `/effective-matrix`
+- 현재 목적: 사용자별 최종 역할과 보호 객체 접근 현황을 확인한다.
+- VPD/ASO 관련성: VPD가 사용할 effective role과 접근 규칙의 근거를 설명한다.
+
+## 페르소나 의견
+
+- 일반 사용자: 이 화면이 실제 DB 조회 결과인지, 설정상 예상 결과인지 구분이 필요하다.
+- 운영 관리자: 사용자 한 명을 선택하면 직접 역할, 그룹 역할, 최종 접근 객체가 한 흐름으로 보여야 한다.
+- 적용 담당자: “왜 이 사용자가 이 객체를 볼 수 있는가”의 근거 경로가 필요하다.
+- DB 관리자: 실제 DB 정책 적용 여부는 별도 화면이라는 구분이 필요하다.
+
+## 가벼운 개선
+
+1. 상단에 “이 화면은 설정 기반 예상 권한입니다. 실제 조회 결과는 접근 검증에서 확인합니다.”를 표시한다.
+2. 사용자별 카드에 `직접 역할 → 그룹 상속 → 최종 역할 → 접근 객체` 타임라인을 둔다.
+3. 각 보호 객체에서 `접근 검증`으로 바로 이동하게 한다.
+
+## Advanced로 둘 내용
+
+- effective role SQL
+- ALLOW/DENY 결합 로직
+- 그룹 active 여부 반영 방식
+
+## 우선순위
+
+P1. 운영자가 변경 전후 영향 확인에 사용하는 중심 화면으로 만들 필요가 있다.

docs/design/621-vpd-aso-persona-page-review/pages/08-vpd-policies.md

@@ -0,0 +1,28 @@
+# 보호 상태 페이지 리뷰
+
+- URL: `/vpd-policies`
+- 현재 목적: 보호 대상 객체와 DB에 적용된 VPD 정책 상태를 확인하고 연결한다.
+- VPD/ASO 관련성: VPD 함수와 테이블 연결 상태를 DBMS_RLS 기준으로 확인하는 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: “보호 적용”이 행 필터만 의미하는지, 컬럼 마스킹도 포함하는지 혼동할 수 있다.
+- 운영 관리자: 백오피스 설정은 있는데 DB 정책이 빠진 상태를 쉽게 알아야 한다.
+- 적용 담당자: 보호 객체별로 “설정 있음 / DB 적용됨 / 검증 성공” 3단계를 나눠 보고 싶다.
+- DB 관리자: policy_name, function_schema, function_name, enable 상태가 증적으로 필요하다.
+
+## 가벼운 개선
+
+1. 배지를 `설정됨`, `DB VPD 적용`, `최근 검증 성공`으로 분리한다.
+2. 컬럼 마스킹은 별도 ASO 상태임을 마스킹 규칙 화면으로 연결한다.
+3. 보호 연결 버튼 옆에 “연결 후 접근 검증 필요” 문구를 둔다.
+
+## Advanced로 둘 내용
+
+- `DBMS_RLS.ADD_POLICY`/`DROP_POLICY`
+- policy function owner
+- object schema와 policy schema
+
+## 우선순위
+
+P0. “설정은 했는데 DB에 적용됐는지”를 판단하는 핵심 운영 화면이다.

docs/design/621-vpd-aso-persona-page-review/pages/09-masking-rules.md

@@ -0,0 +1,33 @@
+# 마스킹 규칙 페이지 리뷰
+
+- URL: `/masking-rules`
+- 현재 목적: 사전 정의 마스킹 방식, 마스킹 대상 컬럼, 컬럼별 기본 규칙, DB ASO 정책 동기화를 관리한다.
+- VPD/ASO 관련성: ASO Data Redaction 정책과 컬럼 원문/마스킹 판단의 중심 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: ASO가 행 접근을 막는 기능으로 오해될 수 있다.
+- 운영 관리자: 컬럼 연결을 해제했을 때 DB Redaction 정책도 같이 해제됐는지 확인해야 한다.
+- 적용 담당자: 마스킹 방식과 대상 컬럼 등록, 사용자 원문 허용이 서로 어떤 순서인지 알아야 한다.
+- DB 관리자: DBMS_REDACT 정책명, 적용 expression, 활성 여부가 필요하다.
+
+## 가벼운 개선
+
+1. 화면 상단에 3단계 흐름을 둔다.
+   - 대상 컬럼 등록
+   - 기본 마스킹 방식 연결
+   - 원문 조회 허용 사용자 지정
+2. 각 컬럼 행에 `백오피스 연결 상태`와 `DB ASO 적용 상태`를 따로 표시한다.
+3. “VPD로 허용된 행 안에서만 마스킹 여부가 의미 있습니다.” 문구를 반복 노출한다.
+4. 숫자 컬럼 마스킹과 집계의 관계는 도움말로 분리한다. `SUM`이 원문 합계를 보장한다고 표현하면 안 된다.
+
+## Advanced로 둘 내용
+
+- Redaction function type
+- policy expression
+- `MR_<column_id>` context
+- DBMS_REDACT 오류 코드와 동기화 로그
+
+## 우선순위
+
+P0. ASO 설정의 실제 DB 적용 여부를 화면에서 바로 판단할 수 있어야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/10-tokens.md

@@ -0,0 +1,32 @@
+# 검증 세션 페이지 리뷰
+
+- URL: `/tokens`
+- 현재 목적: 이해관계자 기준 Bearer token을 발급하고 발급 이력을 확인한다.
+- VPD/ASO 관련성: 토큰은 세션 context를 만들기 위한 입력이고, VPD/ASO는 그 context를 읽는다.
+
+## 페르소나 의견
+
+- 일반 사용자: 발급된 토큰이 어디에 쓰이는지 한 번 더 안내가 필요하다.
+- 운영 관리자: 어떤 사용자/이해관계자/역할로 토큰이 발급됐는지 확인해야 한다.
+- 적용 담당자: stakeholder의 role, channel, user_id가 context로 어떻게 들어가는지 알아야 한다.
+- DB 관리자: 토큰 원문 보관 여부와 만료 정책이 중요하다.
+
+## 가벼운 개선
+
+1. 토큰 발급 결과에 “이 토큰으로 세팅되는 context” 요약을 표시한다.
+   - `USER_ID`
+   - `STAKEHOLDER_USER_ID`
+   - `STAKEHOLDER_ROLE`
+   - `STAKEHOLDER_CHANNEL`
+2. 발급 직후 접근 검증으로 넘길 때 토큰을 자동 선택한다.
+3. 토큰 오류 시 “권한이 없거나 만료된 토큰”처럼 사용자 행동 기준 오류를 표시한다.
+
+## Advanced로 둘 내용
+
+- bearer key 저장 방식
+- context package 내부 함수
+- 만료/폐기 SQL
+
+## 우선순위
+
+P0. 토큰이 권한 자체가 아니라 context 설정 입력이라는 점을 명확히 해야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/11-probe.md

@@ -0,0 +1,29 @@
+# 접근 검증 페이지 리뷰
+
+- URL: `/probe`
+- 현재 목적: 토큰과 보호 객체를 사용해 실제 ORDS/DB 조회 결과를 확인한다.
+- VPD/ASO 관련성: VPD 행 필터와 ASO 컬럼 마스킹이 실제 결과에 어떻게 반영됐는지 확인하는 최종 검증 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: “내가 이 사용자라면 실제로 무엇을 볼 수 있나”만 빠르게 보고 싶다.
+- 운영 관리자: 설정 변경 후 검증 결과와 이전 결과를 비교하고 싶다.
+- 적용 담당자: 결과에 VPD predicate와 ASO 마스킹 여부가 같이 보이면 원인 파악이 쉽다.
+- DB 관리자: 재현 SQL, 실행 컨텍스트, 적용 정책 증적이 필요하다.
+
+## 가벼운 개선
+
+1. 결과를 `세션 context`, `VPD 행 결과`, `ASO 컬럼 마스킹`, `원본 응답` 4개 탭으로 나눈다.
+2. 잘못된 토큰은 DB 오류처럼 보이지 않게 “토큰 권한 없음/만료/인식 불가”로 반환한다.
+3. 마스킹된 컬럼은 결과 테이블에서 별도 아이콘이나 툴팁으로 표시한다.
+
+## Advanced로 둘 내용
+
+- SQL trace
+- VPD predicate
+- ORDS handler source
+- DB cursor 증적
+
+## 우선순위
+
+P0. 이 화면은 모든 설정 변경의 성공 기준이다.

docs/design/621-vpd-aso-persona-page-review/pages/12-objects.md

@@ -0,0 +1,28 @@
+# 조회 대상 페이지 리뷰
+
+- URL: `/objects`
+- 현재 목적: ORDS 조회 대상과 보호 객체 후보를 등록하고 관리한다.
+- VPD/ASO 관련성: 보호 객체로 등록된 테이블이 VPD/ASO 정책 적용과 검증의 단위가 된다.
+
+## 페르소나 의견
+
+- 일반 사용자: 조회 대상, 보호 대상, ORDS handler의 차이를 구분하기 어렵다.
+- 운영 관리자: 새 테이블을 등록하면 다음에 무엇을 해야 하는지 안내가 필요하다.
+- 적용 담당자: 업무명, 테이블명, 키 컬럼, 권한 조건 후보를 같이 관리해야 한다.
+- DB 관리자: 스키마와 객체명 검증, 실제 존재 여부, 권한 여부가 필요하다.
+
+## 가벼운 개선
+
+1. 객체 등록 후 다음 행동을 `보호 연결`, `접근 규칙 추가`, `접근 검증`으로 안내한다.
+2. 목록에 업무명과 DB 객체명을 같이 표시하되, 업무명을 먼저 보여준다.
+3. ASO 컬럼 대상 등록은 마스킹 규칙 화면으로 명확히 연결한다.
+
+## Advanced로 둘 내용
+
+- ORDS module/template/handler 연결
+- schema owner
+- 테이블 존재 확인 SQL
+
+## 우선순위
+
+P1. 신규 테이블 온보딩 흐름을 단순하게 만드는 것이 핵심이다.

docs/design/621-vpd-aso-persona-page-review/pages/13-structured-data.md

@@ -0,0 +1,31 @@
+# 정형 데이터 조회 페이지 리뷰
+
+- URL: `/structured-data`
+- 현재 목적: KB 원장성 테이블을 관리자용으로 미리 조회한다.
+- VPD/ASO 관련성: 실제 사용자별 적용 결과가 아니라 관리자용 원장 미리보기라는 점이 중요하다.
+
+## 페르소나 의견
+
+- 일반 사용자: 여기 결과가 본인 토큰 기준인지 관리자 원본 기준인지 헷갈릴 수 있다.
+- 운영 관리자: 데모 데이터 구조를 확인하는 용도로는 좋지만, 권한 검증과 분리되어야 한다.
+- 적용 담당자: 각 테이블의 업무 의미, 주요 조인 키, VPD 조건 후보가 같이 보여야 한다.
+- DB 관리자: 원장 데이터 조회가 마스킹 정책을 우회하는 관리자 조회인지 표시가 필요하다.
+
+## 가벼운 개선
+
+1. 상단에 “관리자용 데이터 미리보기이며, 사용자별 결과는 접근 검증에서 확인합니다.”를 더 강하게 표시한다.
+2. 각 테이블에 권한 기준 컬럼을 표시한다.
+   - 고객: `CUST_ID`
+   - 계약: `FC_ID`, `FC_CHANNEL`, `CUST_ID`
+   - 보상/외부보유: `CUST_ID`
+3. 접근 검증으로 바로 이동하는 버튼을 둔다.
+
+## Advanced로 둘 내용
+
+- 전체 컬럼 목록
+- 샘플 SQL
+- 테이블 조인 구조
+
+## 우선순위
+
+P1. 관리자 미리보기와 사용자별 VPD 결과의 차이를 분명히 해야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/14-ords-handlers.md

@@ -0,0 +1,29 @@
+# 조회 연동 페이지 리뷰
+
+- URL: `/ords-handlers`
+- 현재 목적: ORDS handler와 source를 확인한다.
+- VPD/ASO 관련성: 외부 호출이 어떤 DB 세션에서 context를 세팅하고 조회하는지 확인하는 기술 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: ORDS handler source는 기본 화면에서 볼 필요가 거의 없다.
+- 운영 관리자: endpoint 상태와 보호 객체 연결 여부가 먼저 필요하다.
+- 적용 담당자: handler가 토큰을 받아 context를 세팅한 뒤 조회하는 흐름이 중요하다.
+- DB 관리자: handler source와 DB package, 정책 적용 대상이 증적으로 필요하다.
+
+## 가벼운 개선
+
+1. 기본 화면은 endpoint, method, 보호 객체, 최근 검증 상태만 보여준다.
+2. source와 수정 기능은 Advanced 상세로 접는다.
+3. handler가 VPD/ASO를 우회하지 않는 이유를 짧게 표시한다.
+
+## Advanced로 둘 내용
+
+- ORDS source
+- `set_vpd_context` 호출
+- SQL trace
+- handler 재배포 절차
+
+## 우선순위
+
+P1. 운영 화면과 개발자 화면의 밀도를 분리해야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/15-vector-knowledge.md

@@ -0,0 +1,28 @@
+# 지식 검색 페이지 리뷰
+
+- URL: `/vector-knowledge`
+- 현재 목적: 지식자료 등록, 접근 정책 설정, 권한 기반 검색을 수행한다.
+- VPD/ASO 관련성: 정형 VPD/ASO와 달리 벡터 지식 검색은 문서 단위 접근 정책과 RAG 검색 품질을 다룬다.
+
+## 페르소나 의견
+
+- 일반 사용자: 정형 데이터 권한과 벡터 검색 권한이 같은 방식인지 헷갈릴 수 있다.
+- 운영 관리자: 자료 등록, 접근 정책, 검색 검증이 한 화면에 섞이면 운영 순서가 흐려진다.
+- 적용 담당자: 상품/회사/약관 메타데이터가 부족하면 RAG 결과가 경쟁사 근거로 치우칠 수 있다.
+- DB 관리자: VPD/ASO가 직접 적용되는 테이블 조회와 벡터 검색 정책을 구분해야 한다.
+
+## 가벼운 개선
+
+1. `자료 등록`, `접근 정책`, `검색 검증`을 탭 또는 단계로 분리한다.
+2. 검색 결과에 “정형 MCP 결과 없음 / 벡터 근거만 있음” 같은 출처 구분을 표시한다.
+3. 상품 필터와 문서 메타데이터 품질 점검 링크를 DB 메타데이터 화면과 연결한다.
+
+## Advanced로 둘 내용
+
+- embedding 상태
+- hybrid rerank 파라미터
+- vector table/source table 구조
+
+## 우선순위
+
+P2. VPD/ASO 핵심 화면보다 후순위지만, MCP 질의 품질에는 중요하다.

docs/design/621-vpd-aso-persona-page-review/pages/16-mcp-chatbot.md

@@ -0,0 +1,29 @@
+# 대화형 검색 페이지 리뷰
+
+- URL: `/mcp-chatbot`
+- 현재 목적: 자연어 질의로 MCP/Select AI/Vector 검색을 호출한다.
+- VPD/ASO 관련성: 자연어 질의라도 정형 DB 호출에는 VPD/ASO context가 적용되어야 한다.
+
+## 페르소나 의견
+
+- 일반 사용자: 질문 입력과 답변이 중심이어야 하고, 도구명은 보조 정보여야 한다.
+- 운영 관리자: 어떤 토큰으로 어떤 도구가 호출됐는지 알 수 있어야 한다.
+- 적용 담당자: Select AI가 잘못된 SQL을 만들면 테이블/컬럼 comment 보강으로 이어져야 한다.
+- DB 관리자: DB 오류, 모델 지연, VPD 차단, ASO 마스킹을 구분해야 한다.
+
+## 가벼운 개선
+
+1. 결과를 `답변`, `호출 도구`, `정형 데이터 결과`, `근거 문서`, `오류 원인`으로 분리한다.
+2. Select AI 호출 시간이 길면 모델/profile/재시도 여부를 표시한다.
+3. “권한 때문에 안 보임”과 “질의 생성 실패”를 다른 오류로 보여준다.
+
+## Advanced로 둘 내용
+
+- MCP tool JSON
+- Select AI showprompt/showsql
+- LLM profile
+- raw ORDS response
+
+## 우선순위
+
+P2. 데모 품질에는 중요하지만, 먼저 권한 운영 화면을 정리한 뒤 다루는 것이 좋다.

docs/design/621-vpd-aso-persona-page-review/pages/17-mcp-reasoning.md

@@ -0,0 +1,29 @@
+# 검색 해석 페이지 리뷰
+
+- URL: `/mcp-reasoning`
+- 현재 목적: MCP 도구 선택과 권한 결과 해석을 확인한다.
+- VPD/ASO 관련성: 자연어 질의가 어떤 protected tool로 라우팅되고, 어떤 토큰으로 실행됐는지 설명한다.
+
+## 페르소나 의견
+
+- 일반 사용자: “왜 이 도구가 선택됐는가”를 업무 문장으로 알고 싶다.
+- 운영 관리자: 실패 시 정형 MCP, 벡터 검색, Select AI 중 어느 구간이 문제인지 봐야 한다.
+- 적용 담당자: 라우팅 결과와 스키마 메타데이터 부족을 연결해야 한다.
+- DB 관리자: 실제 DB 호출과 VPD/ASO 적용 여부를 증적으로 보고 싶다.
+
+## 가벼운 개선
+
+1. 결과 타임라인을 `질문 → 도구 선택 → 토큰 context → DB/RAG 호출 → 응답` 순서로 표시한다.
+2. 각 단계의 시간과 오류 원인을 표시한다.
+3. Select AI prompt 또는 generated SQL은 Advanced에서 열람한다.
+
+## Advanced로 둘 내용
+
+- routing payload
+- tool allowlist
+- generated SQL
+- raw trace
+
+## 우선순위
+
+P2. MCP 진단용 화면으로서 기본 사용자보다 적용 담당자 중심으로 정리한다.

docs/design/621-vpd-aso-persona-page-review/pages/18-mcp-sse.md

@@ -0,0 +1,28 @@
+# MCP 서비스 페이지 리뷰
+
+- URL: `/mcp-sse`
+- 현재 목적: MCP endpoint와 JSON-RPC 호출 정보를 제공한다.
+- VPD/ASO 관련성: MCP 외부 클라이언트가 VPD 적용 Select AI tool을 호출하는 진입점이다.
+
+## 페르소나 의견
+
+- 일반 사용자: 프로토콜 설명보다 “어디에 등록하면 되는가”가 먼저 필요하다.
+- 운영 관리자: endpoint, 인증 방식, 허용 tool, 상태를 한눈에 봐야 한다.
+- 적용 담당자: Bearer token을 MCP 서버 인증과 업무 사용자 token으로 나누면 혼동된다. 가능하면 업무 토큰 하나로 설명해야 한다.
+- DB 관리자: MCP 호출이 ORDS와 DB context 세팅을 거치는지 확인해야 한다.
+
+## 가벼운 개선
+
+1. 상단에 복사 가능한 client 설정 명세를 제공한다.
+2. 인증 헤더는 실제 설계 기준으로 하나만 설명한다. 이중 토큰이 필요하면 이유를 명확히 쓴다.
+3. 허용 tool이 하나라면 tool allowlist를 단순하게 표시한다.
+
+## Advanced로 둘 내용
+
+- JSON-RPC 예시
+- streaming/http transport 차이
+- timeout/retry 정책
+
+## 우선순위
+
+P2. 외부 연동 개발자에게 필요한 문서형 화면으로 정리한다.

docs/design/621-vpd-aso-persona-page-review/pages/19-mcp-client-demo.md

@@ -0,0 +1,29 @@
+# 연동 점검 페이지 리뷰
+
+- URL: `/mcp-client-demo`
+- 현재 목적: Java client로 MCP 호출을 점검한다.
+- VPD/ASO 관련성: MCP를 통해 호출한 정형 DB 결과에도 VPD/ASO가 적용되는지 확인한다.
+
+## 페르소나 의견
+
+- 일반 사용자: Java client 호출 정보는 과하다.
+- 운영 관리자: 현재 endpoint가 호출 가능한지, 권한 오류인지, timeout인지 알고 싶다.
+- 적용 담당자: client 설정과 서버 tool 명세가 일치하는지 확인해야 한다.
+- DB 관리자: 호출이 어떤 DB profile과 ORDS endpoint를 쓰는지 추적하고 싶다.
+
+## 가벼운 개선
+
+1. 기본은 `연결 가능`, `도구 호출 가능`, `VPD 적용 결과 수신` 3개 상태로 표시한다.
+2. curl 예시와 MCP client 설정 예시를 복사 버튼으로 제공한다.
+3. Java stack/detail은 Advanced로 보낸다.
+
+## Advanced로 둘 내용
+
+- Java client raw request/response
+- timeout 설정
+- retry 횟수
+- tool schema
+
+## 우선순위
+
+P2. 연동 개발자용 진단 화면이다.

docs/design/621-vpd-aso-persona-page-review/pages/20-operation-status.md

@@ -0,0 +1,29 @@
+# 운영 현황 페이지 리뷰
+
+- URL: `/operation-status`
+- 현재 목적: 백오피스와 DB/ORDS/MCP 관련 운영 상태를 확인한다.
+- VPD/ASO 관련성: 설정 상태와 DB 실제 적용 상태, 최근 동기화 결과를 구분해야 한다.
+
+## 페르소나 의견
+
+- 일반 사용자: 정상/주의/장애만 먼저 보고 싶다.
+- 운영 관리자: 장애가 어느 기능에 영향을 주는지 알아야 한다.
+- 적용 담당자: ASO 동기화 실패, VPD 정책 누락, ORDS 오류를 구분해야 한다.
+- DB 관리자: DB 조회 기반 상태와 애플리케이션 설정 기반 상태를 분리해서 봐야 한다.
+
+## 가벼운 개선
+
+1. 상단에 전체 상태 배너를 둔다.
+2. 상태 항목을 `앱`, `DB 연결`, `VPD 정책`, `ASO 정책`, `ORDS`, `MCP/Select AI`로 나눈다.
+3. 각 항목에 최근 확인 시각, 영향 범위, 권장 조치를 표시한다.
+
+## Advanced로 둘 내용
+
+- raw health response
+- SQL check query
+- systemd/log 위치
+- DB 오류 전문
+
+## 우선순위
+
+P0. 운영자가 “지금 정상인가”를 판단하는 중심 화면이다.

docs/design/621-vpd-aso-persona-page-review/pages/21-vpd-filter-runtime.md

@@ -0,0 +1,29 @@
+# VPD 필터 구조 페이지 리뷰
+
+- URL: `/vpd-filter-runtime`
+- 현재 목적: `CB_AGENT_DOC_VPD_FILTER`의 연결 상태와 배포된 함수 소스를 읽기 전용으로 보여준다.
+- VPD/ASO 관련성: VPD 행 필터가 권한 설정을 실제 WHERE predicate로 바꾸는 핵심 구조를 설명한다.
+
+## 페르소나 의견
+
+- 일반 사용자: 함수 소스는 기본적으로 너무 어렵다.
+- 운영 관리자: 이 화면은 수정 화면이 아니라 근거 확인 화면이라는 점이 필요하다.
+- 적용 담당자: 토큰이 context로 바뀌고, 필터가 context와 권한 테이블을 읽는 흐름을 이해해야 한다.
+- DB 관리자: 실제 DB 함수 소스와 Git source가 일치하는지 확인하고 싶다.
+
+## 가벼운 개선
+
+1. 상단 도움말에 “토큰 → context → 권한 테이블 → VPD predicate → 결과 행” 흐름을 유지한다.
+2. 함수 소스는 기본 접힘으로 두고, 주요 블록별 설명을 먼저 보여준다.
+3. ASO와의 차이 표를 유지하되 “VPD는 컬럼 값을 NULL 처리하지 않는다”를 명시한다.
+
+## Advanced로 둘 내용
+
+- 전체 PL/SQL source
+- safe column/static SQL 검증
+- ALLOW/DENY predicate 조립
+- policy binding metadata
+
+## 우선순위
+
+P1. 적용 담당자와 DB 관리자의 신뢰 확보용 화면이다.

docs/design/621-vpd-aso-persona-page-review/pages/22-schema-metadata.md

@@ -0,0 +1,29 @@
+# DB 메타데이터 페이지 리뷰
+
+- URL: `/schema-metadata`
+- 현재 목적: 테이블/컬럼 comment와 annotation을 확인하고 수정한다.
+- VPD/ASO 관련성: Select AI가 자연어 질의를 SQL로 바꿀 때 테이블·컬럼 의미를 이해하게 돕는 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: comment와 annotation의 차이를 알기 어렵다.
+- 운영 관리자: 자연어 질의 실패 원인이 메타데이터 부족일 수 있음을 알아야 한다.
+- 적용 담당자: 업무 용어, 조인 키, 권한 기준 컬럼을 명확히 입력해야 한다.
+- DB 관리자: 실제 DB comment와 백오피스 annotation 저장소가 어떻게 동기화되는지 봐야 한다.
+
+## 가벼운 개선
+
+1. 각 컬럼에 `업무 의미`, `권한 기준`, `Select AI 힌트`를 나눠 표시한다.
+2. `CUST_ID`, `CONTRACT_NO`, `FC_ID`, `FC_CHANNEL` 같은 권한 기준 컬럼은 배지로 강조한다.
+3. 자연어 질의 오류 리포트에서 이 화면으로 연결한다.
+
+## Advanced로 둘 내용
+
+- DB comment DDL
+- annotation storage schema
+- Select AI showprompt
+- generated SQL 비교
+
+## 우선순위
+
+P1. 자연어 기반 Select AI 품질 개선의 핵심 운영 화면이다.

docs/design/621-vpd-aso-persona-page-review/pages/23-security-sql-scripts.md

@@ -0,0 +1,29 @@
+# 보안 SQL 스크립트 페이지 리뷰
+
+- URL: `/security-sql-scripts`
+- 현재 목적: Git에 저장된 VPD/ASO/ORDS/Select AI 관련 SQL 스크립트를 확인하고 LLM 설명을 생성한다.
+- VPD/ASO 관련성: 운영자가 실제 DB 적용 스크립트를 이해하고 검토하는 증적 화면이다.
+
+## 페르소나 의견
+
+- 일반 사용자: 전체 SQL보다 “이 스크립트가 뭘 적용하는가”가 먼저 필요하다.
+- 운영 관리자: 실행 대상, 영향 범위, 되돌리기 가능 여부가 중요하다.
+- 적용 담당자: 토큰/context/VPD/ASO 흐름을 스크립트 단위로 설명해야 한다.
+- DB 관리자: 원본 SQL, 주석, LLM 설명, DB 적용 상태를 나란히 보고 싶다.
+
+## 가벼운 개선
+
+1. 스크립트마다 `목적`, `적용 객체`, `변경되는 DB 정책`, `검증 방법`을 상단 카드로 요약한다.
+2. LLM 설명은 “토큰이 어떻게 context가 되고, VPD/ASO가 무엇을 읽는가”를 반드시 포함하게 한다.
+3. 원본 SQL은 그대로 보여주되, 비전문가 설명은 먼저 제공한다.
+
+## Advanced로 둘 내용
+
+- 전체 SQL source
+- script diff
+- DB 배포 이력
+- LLM prompt 전문
+
+## 우선순위
+
+P1. 복잡한 스크립트를 이해하기 위한 설명 화면으로 방향이 맞다.

docs/design/621-vpd-aso-persona-page-review/pages/24-vpd-filter-policies.md

@@ -0,0 +1,29 @@
+# 고급 접근 조건 페이지 리뷰
+
+- URL: `/vpd-filter-policies`
+- 현재 목적: 기본 접근 규칙으로 처리하기 어려운 고급 필터 정책을 관리한다.
+- VPD/ASO 관련성: VPD predicate 생성에 영향을 주는 예외적 고급 조건이다.
+
+## 페르소나 의견
+
+- 일반 사용자: 이 화면은 기본 사용자가 접근할 이유가 없다.
+- 운영 관리자: 대부분의 변경은 접근 규칙에서 끝난다는 안내가 현재 방향과 맞다.
+- 적용 담당자: 고급 조건을 쓰기 전 업무 조건으로 해결 가능한지 판단해야 한다.
+- DB 관리자: 임의 SQL 조건은 injection 방어와 검증 결과가 필요하다.
+
+## 가벼운 개선
+
+1. 기본 화면은 “접근 규칙으로 처리 가능한가?” 체크리스트부터 보여준다.
+2. 고급 조건 작성은 Advanced로 접고, 저장 전 검증 결과를 필수로 표시한다.
+3. 실제 predicate 예시와 실패 시 fail-closed 동작을 설명한다.
+
+## Advanced로 둘 내용
+
+- raw predicate
+- validation rules
+- 대상 컬럼 whitelist
+- DBMS_ASSERT 처리
+
+## 우선순위
+
+P1. 잘못 쓰면 접근 범위를 넓힐 수 있으므로 일반 설정과 분리해야 한다.

docs/design/621-vpd-aso-persona-page-review/pages/25-settings.md

@@ -0,0 +1,32 @@
+# 시스템 설정 페이지 리뷰
+
+- URL: `/settings`
+- 현재 목적: ORDS Base URL 등 시스템 연결 설정을 관리한다.
+- VPD/ASO 관련성: 권한 검증과 MCP/ORDS 호출의 기반 연결 정보다.
+
+## 페르소나 의견
+
+- 일반 사용자: 일반 사용자가 자주 볼 화면은 아니다.
+- 운영 관리자: 연결 URL 변경이 어떤 기능에 영향을 주는지 알아야 한다.
+- 적용 담당자: DB 준비 상태와 ORDS 연결 설정을 구분해야 한다.
+- DB 관리자: 운영 설정 변경 이력과 검증 결과가 필요하다.
+
+## 가벼운 개선
+
+1. 변경 가능한 설정과 읽기 전용 환경 설정을 분리한다.
+2. 설정 변경 후 영향을 받는 기능을 표시한다.
+   - 접근 검증
+   - MCP 호출
+   - ORDS handler 조회
+3. 저장 후 자동 health check를 실행하고 결과를 보여준다.
+
+## Advanced로 둘 내용
+
+- 환경 변수명
+- systemd env 파일
+- connection timeout
+- proxy/TLS 설정
+
+## 우선순위
+
+P2. 기능 안정성에는 중요하지만 일반 권한 흐름보다는 후순위다.

docs/design/621-vpd-aso-persona-page-review/pages/26-settings-database.md

@@ -0,0 +1,29 @@
+# DB 준비 상태 페이지 리뷰
+
+- URL: `/settings/database`
+- 현재 목적: 지원 테이블과 VPD runtime 준비 상태를 확인하고 초기 구성 SQL을 실행한다.
+- VPD/ASO 관련성: 권한 운영에 필요한 메타 테이블, context package, policy function, ASO metadata의 준비 상태를 다룬다.
+
+## 페르소나 의견
+
+- 일반 사용자: 거의 볼 필요가 없는 관리자 화면이다.
+- 운영 관리자: 운영 중 재실행하면 위험한 작업과 안전한 확인 작업을 구분해야 한다.
+- 적용 담당자: 어떤 단계가 누락되면 어떤 화면이 실패하는지 알고 싶다.
+- DB 관리자: 실행 전 SQL, 실행 권한, 생성 객체, 재실행 안전성이 필요하다.
+
+## 가벼운 개선
+
+1. 상태 확인과 변경 실행을 완전히 분리한다.
+2. 변경 실행 전에는 생성/수정/건너뜀/위험 항목을 요약한다.
+3. VPD와 ASO 준비 항목을 별도 섹션으로 표시한다.
+
+## Advanced로 둘 내용
+
+- 전체 DDL
+- package/function source
+- DB 권한 grant
+- 재실행 idempotency 설명
+
+## 우선순위
+
+P1. DB 준비 화면은 강력한 변경 화면이므로 안전 장치와 설명이 필요하다.