Consolidate data access control backoffice updates

docs/reports/2026-07-10-existing-01-mcp-rag-diagnosis.md

@@ -0,0 +1,108 @@
+# 기존-01 MCP/RAG 진단 리포트
+
+## 대상 시나리오
+
+- 질문 번호: 기존-01
+- 분류: 권한 + RAG 질문형
+- 이해관계자: 설계사 `FC00789`
+- 질의: `C1001006 고객 자동차보험 갱신 상담 전에, 현재 KB 계약(41048)과 삼성화재 보유 자동차보험 약관을 비교해서 고객에게 설명할 차별 포인트를 정리해줘.`
+
+## 정형 MCP 확인 결과
+
+정형 MCP 경로는 복구 확인됐다.
+
+- MCP endpoint: `https://kb.cloud-handson.com/mcp`
+- tool: `ords.query.kb_select_ai_vpd`
+- Select AI profile: `KB_AIDP_SELECTAI_GPT55_OCI_PROFILE_V2`
+- 검증 결과:
+  - `HTTP_STATUS=200`
+  - `MCP_HAS_ERROR=FALSE`
+  - `MCP_IS_ERROR=FALSE`
+  - `ITEM_COUNT=1`
+
+생성 SQL은 `41048`을 `CONTRACT_NO`가 아니라 `PRODUCT_CD`로 해석했다.
+
+```text
+KC.CUST_ID = 'C1001006'
+KC.PRODUCT_CD = '41048'
+EH.EXT_INSURER = '삼성화재'
+EH.EXT_PRODUCT_GRP = '자동차'
+```
+
+대표 반환값:
+
+```text
+CUSTOMER_ID=C1001006
+KB_CONTRACT_NO=CT2699001
+KB_PRODUCT_CODE=41048
+KB_PRODUCT_NAME=41048_KB개인용자동차보험
+KB_PREMIUM=1350000
+EXTERNAL_INSURER=삼성화재
+EXTERNAL_PRODUCT_GROUP=자동차
+EXTERNAL_PRODUCT_TYPE=개인용
+EXTERNAL_CLAUSE_NAME=개인용애니카다이렉트자동차보험
+```
+
+## 적용한 정형 MCP 보완
+
+- `POC_2` KB 업무 테이블/컬럼 comment를 보강했다.
+- Select AI `showprompt` 확인 결과, comment와 annotation이 실제 모델 프롬프트에 포함됨을 확인했다.
+- SQL 정규화/검증 로직을 보완했다.
+  - 마크다운 fence와 선행 wrapper comment를 제거한다.
+  - 문자열 리터럴 내부의 세미콜론/금지어를 실행 문법으로 오판하지 않도록 검사한다.
+  - DDL/DML/PLSQL/system object 차단은 유지한다.
+
+변경 스크립트:
+
+- `sql/adb/65_kb_select_ai_vpd_query_api.sql`
+
+## RAG 근거 검색 확인 결과
+
+RAG corpus는 `POC_2` 스키마에 존재한다.
+
+```text
+POC_2.KB_OWN_TERMS_DOCUMENTS
+POC_2.KB_OWN_TERMS_CHUNKS
+POC_2.KB_COMPETITOR_TERMS_DOCUMENTS
+POC_2.KB_COMPETITOR_TERMS_CHUNKS
+POC_2.KB_TERMS_CHUNKS_ALL_V
+```
+
+건수:
+
+```text
+TOTAL_CHUNKS=38772
+OWN_CHUNKS=28506
+COMP_CHUNKS=10266
+```
+
+KB 41048 약관 근거는 존재한다.
+
+```text
+DOC_41048|KB손해보험|OWN||KB개인용자동차보험|b5b680222361c4cde7a54855925333a3
+SAMPLE_41048|KB손해보험|OWN||KB개인용자동차보험|...|자동차26-41048-1-04 KB개인용자동차보험 ...
+```
+
+## RAG 측 원인 판단
+
+KB 41048 약관 chunk는 있지만 `PRODUCT_CODE` 메타데이터가 비어 있다.
+
+```text
+company_name=KB손해보험
+company_type=OWN
+product_code=<empty>
+product_name=KB개인용자동차보험
+chunk_text contains 자동차26-41048-1-04
+```
+
+따라서 RAG 검색/필터가 `PRODUCT_CODE = '41048'` 또는 상품코드 기반 필터를 사용하면 KB 근거가 제외될 수 있다. 본문 텍스트에는 `41048`이 있으므로 순수 텍스트 검색으로는 찾을 수 있지만, 메타데이터 필터 기준 검색에서는 빠질 가능성이 높다.
+
+## 권고
+
+RAG/약관 적재 담당 영역에서 아래 중 하나를 처리해야 한다.
+
+1. `KB_OWN_TERMS_DOCUMENTS` / `KB_OWN_TERMS_CHUNKS` 적재 시 `자동차26-41048-1-04`에서 업무 상품코드 `41048`을 추출해 `PRODUCT_CODE`에 저장한다.
+2. 기존 적재분에 대해 `KB개인용자동차보험` 또는 `자동차26-41048-1-04` 문서를 대상으로 `PRODUCT_CODE='41048'` backfill을 수행한다.
+3. 검색 필터가 상품코드만 보지 말고 `PRODUCT_NAME`, `CHUNK_TEXT`의 약관 승인번호 패턴도 fallback으로 보도록 보강한다.
+
+VPD 관리 인스턴스에서는 이 영역을 직접 수정하지 않고, 정형 데이터/Select AI 쪽 table comment와 annotation 관리 기능으로 메타데이터 품질을 운영 가능하게 한다.

docs/reports/2026-07-10-select-ai-profile-performance-report.md

@@ -0,0 +1,319 @@
+# Select AI 프로파일 전환 및 호출 시간 리포트
+
+## 대상
+
+- 날짜: 2026-07-10
+- 대상 서비스: VPD 관리 인스턴스 MCP / ORDS Select AI 조회
+- MCP endpoint: `https://kb.cloud-handson.com/mcp`
+- MCP tool: `ords.query.kb_select_ai_vpd`
+- ORDS endpoint: `/ords/cb-ords/kb-select-ai-vpd/query`
+- 테스트 질의:
+
+```text
+C1001006 고객 자동차보험 갱신 상담 전에, 현재 KB 계약(41048)과 삼성화재 보유 자동차보험 약관을 비교해서 고객에게 설명할 차별 포인트를 정리해줘.
+```
+
+## 결론
+
+기존 `openai.gpt-5.5` 기반 Select AI 프로파일은 SQL 생성 시간이 길고, 같은 질의에서도 SQL 생성 실패/거절 응답이 간헐적으로 발생했다.
+
+최종 적용 프로파일은 아래로 변경했다.
+
+```text
+KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1
+```
+
+이 프로파일은 `openai.gpt-5.4-mini`를 사용하고, `comments=true`를 켜서 테이블/컬럼 comment 기반 SQL 생성을 유지한다. 최종 ORDS 직접 호출은 약 4.1초, MCP 호출은 약 4.6~8.2초 범위로 확인됐다.
+
+## 기존 호출 시간
+
+기존 운영 프로파일:
+
+```text
+KB_AIDP_SELECTAI_GPT55_OCI_PROFILE_V2
+model=openai.gpt-5.5
+provider=oci
+region=us-chicago-1
+provider_endpoint=https://inference.generativeai.us-chicago-1.oci.oraclecloud.com
+comments=true
+annotations=true
+constraints=true
+conversation=true
+enforce_object_list=true
+```
+
+관찰된 기존 병목:
+
+| 측정 구간 | 시간 | 결과 |
+|---|---:|---|
+| VPD context 설정 | 282ms | 정상 |
+| 확정 SQL + VPD 실행 | 50ms | 정상 |
+| `showprompt` metadata/prompt 생성 | 43.817초 | prompt 18,806자 |
+| `showsql` 1차 | 38.770초 | SQL 생성 성공 |
+| `showsql` 2차 | 105.505초 | non-SQL refusal |
+| SQLcl direct package 호출 | 61.123초 | SQL 생성 및 2건 반환 |
+| MCP 경로 호출 | 54.3초 | `ORA-20813`, Select AI가 유효 SELECT 생성 실패 |
+| GPT-5.5 재비교 호출 | 72초 | SQL 대신 refusal 메시지 반환 |
+
+판단:
+
+- DB/VPD/ORDS 자체가 느린 것이 아니다.
+- 주 병목은 `DBMS_CLOUD_AI.GENERATE` 내부의 Select AI prompt 구성과 LLM SQL 생성 단계다.
+- `comments`, `annotations`, `constraints`, `conversation`, `enforce_object_list`가 모두 켜진 GPT-5.5 프로파일은 prompt가 커지고 응답 편차가 컸다.
+
+## 후보 프로파일 테스트 결과
+
+### 1. 단순 모델 교체 후보
+
+| 프로파일 | 모델 | 설정 | 결과 |
+|---|---|---|---|
+| `KB_AIDP_SELECTAI_GPT5_MINI_PROFILE_V1` | `openai.gpt-5-mini` | 기존 GPT-5.5와 유사 | `ORA-20404 ... /actions/chat` |
+| `KB_AIDP_SELECTAI_GPT41_MINI_PROFILE_V1` | `openai.gpt-4.1-mini` | 기존 GPT-5.5와 유사 | `ORA-20404 ... /actions/chat` |
+| `KB_AIDP_SELECTAI_GROK43_PROFILE_V1` | `xai.grok-4.3` | 기존 GPT-5.5와 유사 | `ORA-20404 ... /actions/chat` |
+| `KB_AIDP_SELECTAI_GPT54_MINI_PROFILE_V1` | `openai.gpt-5.4-mini` | 기존 GPT-5.5와 유사 | `ORA-20404 ... /actions/chat` |
+
+오류:
+
+```text
+ORA-20404: Object not found - oci://inference.generativeai.us-chicago-1.oci.oraclecloud.com/20231130/actions/chat
+```
+
+단순히 모델명만 바꾸는 방식은 안정적이지 않았다.
+
+### 2. 기존 성공 프로파일 방식 확인
+
+기존에 성공한 프로파일:
+
+```text
+POC_SELECT_AI_ALL
+model=xai.grok-4.3
+```
+
+확인된 차이:
+
+- `oci_compartment_id`가 있음
+- `comments`, `annotations`, `constraints`, `conversation`, `enforce_object_list` 플래그가 없음
+
+비교 결과:
+
+| 프로파일 | 시간 | 결과 |
+|---|---:|---|
+| `KB_AIDP_SELECTAI_GPT55_OCI_PROFILE_V2` | 72초 | refusal 메시지 반환 |
+| `POC_SELECT_AI_ALL` | 16초 | SQL 생성 성공 |
+
+### 3. FAST 프로파일 테스트
+
+`POC_SELECT_AI_ALL` 구조를 기준으로 `oci_compartment_id`를 포함하고, 무거운 메타데이터 플래그를 제거한 FAST 후보를 만들었다.
+
+| 프로파일 | 모델 | showprompt | prompt 크기 | showsql | 결과 |
+|---|---|---:|---:|---:|---|
+| `KB_AIDP_SELECTAI_GROK43_FAST_PROFILE_V1` | `xai.grok-4.3` | 3초 | 5,049자 | 7초 | 성공 |
+| `KB_AIDP_SELECTAI_GPT54_MINI_FAST_PROFILE_V1` | `openai.gpt-5.4-mini` | 0초 | 5,049자 | 4초 | 성공 |
+
+FAST 방식은 빠르지만, 테이블/컬럼 comment 활용이 약해진다. 따라서 최종 적용용으로는 `comments=true`만 추가한 절충형을 별도 테스트했다.
+
+### 4. Full metadata 프로파일 테스트
+
+`comments=true`에 더해 `annotations=true`, `constraints=true`까지 켠 후보를 추가 테스트했다.
+
+프로파일:
+
+```text
+KB_AIDP_SELECTAI_GPT54_MINI_FULLMETA_PROFILE_V1
+model=openai.gpt-5.4-mini
+comments=true
+annotations=true
+constraints=true
+enforce_object_list=true
+```
+
+DBMS_CLOUD_AI 단독 측정:
+
+| 회차 | showprompt | prompt 크기 | showsql | 결과 |
+|---:|---:|---:|---:|---|
+| 1 | 32초 | 19,816자 | 15초 | 성공 |
+| 2 | 3초 | 19,816자 | 6초 | 성공 |
+| 3 | 4초 | 19,816자 | 13초 | 성공 |
+
+ORDS 실제 경로 측정:
+
+| 회차 | HTTP | 총 시간 | 오류 | 반환 건수 |
+|---:|---:|---:|---|---:|
+| 1 | 200 | 8.224초 | 없음 | 2 |
+| 2 | 200 | 7.288초 | 없음 | 2 |
+| 3 | 200 | 6.217초 | 없음 | 2 |
+
+평균:
+
+```text
+7.243초
+```
+
+비교:
+
+| 구성 | ORDS 평균 | 상대 |
+|---|---:|---:|
+| `comments=true` only | 4.156초 | 1.0x |
+| `comments + annotations + constraints` | 7.243초 | 약 1.7x 느림 |
+
+판단:
+
+- Full metadata 구성은 동작한다.
+- 단, prompt 크기가 `12,520자`에서 `19,816자`로 증가한다.
+- ORDS 기준 평균 응답 시간이 `4.156초`에서 `7.243초`로 늘어난다.
+- 데모 응답성 기준으로는 `comments=true` only 구성이 더 적합하다.
+
+## 최종 적용 프로파일
+
+최종 적용:
+
+```text
+KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1
+model=openai.gpt-5.4-mini
+comments=true
+enforce_object_list=true
+oci_compartment_id=<configured>
+```
+
+테스트 결과:
+
+| 구간 | 시간 | 결과 |
+|---|---:|---|
+| `showprompt` | 6초 | 성공 |
+| prompt 크기 | 12,520자 | comment 포함 |
+| `showsql` | 4초 | 성공 |
+
+선택 이유:
+
+- GPT-5.5 대비 훨씬 빠르다.
+- FAST 프로파일보다 prompt가 크지만, 테이블/컬럼 comment를 유지한다.
+- VPD 관리 인스턴스에서 보강한 table/column comment 운영 효과가 Select AI에 반영된다.
+
+## 적용 내용
+
+### DB 패키지
+
+`POC_2.KB_SELECT_AI_VPD_QUERY_API`의 Select AI profile 상수를 변경했다.
+
+```sql
+c_profile_name CONSTANT VARCHAR2(128) := 'KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1';
+```
+
+대상 스크립트:
+
+```text
+sql/adb/65_kb_select_ai_vpd_query_api.sql
+```
+
+### ORDS 응답 표시
+
+ORDS JSON 응답의 profile 표시도 새 프로파일로 변경했다.
+
+```text
+profile=KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1
+```
+
+대상 스크립트:
+
+```text
+sql/adb/66_kb_select_ai_vpd_query_ords.sql
+```
+
+### MCP 응답 표시
+
+MCP tool 응답 payload의 profile 표시와 화면 설명을 새 프로파일 기준으로 변경했다.
+
+대상 소스:
+
+```text
+src/main/java/com/cloudhandson/vpdbackoffice/service/McpSseService.java
+src/main/resources/templates/mcp-sse.html
+```
+
+## 최종 속도 측정
+
+### ORDS 직접 호출
+
+호출 대상:
+
+```text
+https://g329127dfd380ad-kbaipoc.adb.ap-osaka-1.oraclecloudapps.com/ords/cb-ords/kb-select-ai-vpd/query
+```
+
+| 회차 | HTTP | 총 시간 | 응답 profile | 오류 | 반환 건수 |
+|---:|---:|---:|---|---|---:|
+| 1 | 200 | 4.058초 | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | 없음 | 2 |
+| 2 | 200 | 4.216초 | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | 없음 | 2 |
+| 3 | 200 | 4.195초 | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | 없음 | 1 |
+
+평균:
+
+```text
+4.156초
+```
+
+### MCP 호출
+
+호출 대상:
+
+```text
+https://kb.cloud-handson.com/mcp
+```
+
+| 회차 | HTTP | 총 시간 | MCP payload profile | ORDS profile | 오류 | 반환 건수 |
+|---:|---:|---:|---|---|---|---:|
+| 1 | 200 | 4.632초 | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | 없음 | 2 |
+| 2 | 200 | 8.213초 | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | 없음 | 2 |
+| 3 | 200 | 7.279초 | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | `KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1` | 없음 | 1 |
+
+평균:
+
+```text
+6.708초
+```
+
+참고:
+
+- MCP `time_starttransfer`는 약 0.008~0.012초였지만, 최종 응답 body 완료 기준은 `time_total`이다.
+- MCP 경로는 백오피스 HTTP 처리와 ORDS 호출 wrapping이 추가되므로 ORDS 직접 호출보다 약간 느릴 수 있다.
+
+## 개선 효과
+
+| 비교 항목 | 기존 GPT-5.5 | 최종 GPT-5.4-mini comments |
+|---|---:|---:|
+| SQLcl direct package | 61.123초 | 4초대 SQL 생성 |
+| 기존 MCP 실패 사례 | 54.3초 후 실패 | 4.6~8.2초 성공 |
+| GPT-5.5 재비교 | 72초 후 refusal | 4.1초대 ORDS 성공 |
+| prompt 크기 | 18,806~21,776자 | 12,520자 |
+
+정리:
+
+- 최종 ORDS 기준으로 기존 61~72초 구간 대비 약 10~17배 빠르다.
+- MCP 기준으로도 기존 54.3초 실패 사례 대비 성공 응답이 약 4.6~8.2초로 줄었다.
+- DB/VPD 실행 병목이 아니라 Select AI 프로파일/모델/메타데이터 구성이 핵심 병목이었다.
+
+## 남은 주의점
+
+1. 같은 자연어라도 Select AI 생성 SQL은 완전히 결정적이지 않다.
+   - 테스트에서도 반환 건수가 1~2건으로 흔들렸다.
+   - 이는 LLM SQL 생성 특성이다.
+2. 비즈니스 품질을 더 안정화하려면 table/column comment와 annotation을 계속 보강해야 한다.
+3. 특정 데모 질문은 deterministic SQL fallback 후보로 둘 수 있다.
+   - 예: `CUST_ID`, `PRODUCT_CD`, `EXT_INSURER`, `EXT_PRODUCT_GRP`가 명확한 비교 질문.
+4. 장기적으로는 profile을 설정값으로 분리하는 것이 좋다.
+   - 현재는 DB package 상수로 고정되어 있다.
+   - 운영 전환 시 `CB_BACKOFFICE_SETTING` 또는 별도 Select AI 설정 테이블에서 profile을 읽도록 개선할 수 있다.
+
+## 현재 권고
+
+데모/PoC 운영 기준으로는 현재 적용한 아래 프로파일을 유지한다.
+
+```text
+KB_AIDP_SELECTAI_GPT54_MINI_COMMENTS_PROFILE_V1
+```
+
+이유:
+
+- 응답 시간이 데모 가능한 수준이다.
+- comment 기반 스키마 설명을 유지한다.
+- ORDS/MCP 양쪽 모두 실제 호출 성공을 확인했다.

docs/reports/2026-07-13-vpd-aso-holistic-ui-review.md

@@ -0,0 +1,213 @@
+# 데이터 접근 제어 백오피스 전체 UX/기능 리뷰
+
+작성일: 2026-07-13
+범위: 현재 Spring Boot 백오피스 화면, VPD/ASO/ORDS/MCP/Select AI 운영 흐름
+상태: Review only
+
+## 1. 결론
+
+단순 문구 정리만으로는 충분하지 않다. 지금 화면은 기능은 많이 들어와 있지만, 사용자가 “업무 규칙을 넣으면 DB에서 어떻게 행/컬럼으로 적용되는가”를 끝까지 따라가기 어렵다.
+
+가장 큰 개선 축은 세 가지다.
+
+1. 전체 흐름을 작업 단위로 묶어야 한다.
+   - 사용자/역할 생성
+   - 행 접근 규칙 등록
+   - 보호 정책 연결
+   - 컬럼 마스킹 설정
+   - 토큰 발급
+   - 실제 접근 검증
+
+2. 화면별 기본/고급을 분리해야 한다.
+   - 기본 화면: 업무 의미, 현재 상태, 다음 버튼, 검증 결과
+   - 고급 화면: VPD predicate, PL/SQL source, ORDS handler, raw JSON, SQL trace
+
+3. 모든 설정 화면에서 “설정값 → DB 적용 → 실제 검증”이 이어져야 한다.
+   - 지금은 각 화면이 기능 단위로는 존재하지만, 다음 단계 연결과 검증 루프가 약하다.
+
+## 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. 고급 접근 조건 체크리스트와 검증 강화