Consolidate data access control backoffice updates
This commit is contained in:
devmrko
@@ -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. 혼동을 줄이는 문구 개선이 중심이고, 권한 계산 로직에는 영향이 없다.
|
||||
@@ -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. 홈에서 전체 모델을 정확히 잡으면 다른 화면의 설명량을 줄일 수 있다.
|
||||
@@ -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. 권한 주체를 이해해야 접근 규칙과 토큰 검증의 혼동이 줄어든다.
|
||||
@@ -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. 운영 관리자가 대량 영향 변경을 안전하게 이해하는 데 필요하다.
|
||||
@@ -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. 접근 규칙의 주체가 역할이므로 사용자 영향도를 쉽게 보여줘야 한다.
|
||||
@@ -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로 바꾼다”는 표현을 반드시 강화해야 한다.
|
||||
@@ -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 권한을 섞어 이해하면 운영 사고로 이어질 수 있다.
|
||||
@@ -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. 운영자가 변경 전후 영향 확인에 사용하는 중심 화면으로 만들 필요가 있다.
|
||||
@@ -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에 적용됐는지”를 판단하는 핵심 운영 화면이다.
|
||||
@@ -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 적용 여부를 화면에서 바로 판단할 수 있어야 한다.
|
||||
@@ -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 설정 입력이라는 점을 명확히 해야 한다.
|
||||
@@ -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. 이 화면은 모든 설정 변경의 성공 기준이다.
|
||||
@@ -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. 신규 테이블 온보딩 흐름을 단순하게 만드는 것이 핵심이다.
|
||||
@@ -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 결과의 차이를 분명히 해야 한다.
|
||||
@@ -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. 운영 화면과 개발자 화면의 밀도를 분리해야 한다.
|
||||
@@ -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 질의 품질에는 중요하다.
|
||||
@@ -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. 데모 품질에는 중요하지만, 먼저 권한 운영 화면을 정리한 뒤 다루는 것이 좋다.
|
||||
@@ -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 진단용 화면으로서 기본 사용자보다 적용 담당자 중심으로 정리한다.
|
||||
@@ -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. 외부 연동 개발자에게 필요한 문서형 화면으로 정리한다.
|
||||
@@ -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. 연동 개발자용 진단 화면이다.
|
||||
@@ -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. 운영자가 “지금 정상인가”를 판단하는 중심 화면이다.
|
||||
@@ -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 관리자의 신뢰 확보용 화면이다.
|
||||
@@ -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 품질 개선의 핵심 운영 화면이다.
|
||||
@@ -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. 복잡한 스크립트를 이해하기 위한 설명 화면으로 방향이 맞다.
|
||||
@@ -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. 잘못 쓰면 접근 범위를 넓힐 수 있으므로 일반 설정과 분리해야 한다.
|
||||
@@ -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. 기능 안정성에는 중요하지만 일반 권한 흐름보다는 후순위다.
|
||||
@@ -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 준비 화면은 강력한 변경 화면이므로 안전 장치와 설명이 필요하다.
|
||||
Reference in New Issue
Block a user