[Feature] AI-RAG 권한 보존·감사 가이드 및 검증 체크리스트 추가

[EricSeokgon]

해결하려는 문제 (Problem)

표준프레임워크에는 Spring AI와 LangChain4j를 이용한 공식 RAG 샘플이 제공되고 있고, egovframe-docs에도 AI 실행환경 가이드 영역이 구성되어 있습니다. 다만 공공 업무 시스템에 RAG를 적용할 때 필요한 원본 업무 권한의 보존, 검색 단계 접근 통제, 응답 직전 재검증, 개인정보 마스킹, 감사 추적을 하나의 운영 기준으로 설명하는 문서는 아직 부족합니다.

기존 게시판·FAQ·문서관리 시스템은 사용자, 롤, 그룹, 부서 및 게시물별 권한으로 접근을 통제합니다. 그러나 문서를 벡터 저장소에 적재하는 과정에서 원본 권한이 메타데이터로 함께 보존되지 않거나, 검색 후 결과만 제거하는 방식에 의존하면 권한이 없는 문서가 LLM 컨텍스트 또는 중간 로그에 포함될 수 있습니다.

기관별로 이 부분을 별도로 설계하면 다음 문제가 발생할 수 있습니다.

• 원본 시스템과 벡터 저장소 간 권한 불일치
• 부서·롤 변경 후 기존 색인 권한이 즉시 갱신되지 않는 문제
• 검색 결과, 프롬프트, 응답 및 감사 로그에 개인정보가 남는 문제
• 권한 검증 서비스 장애 시 허용 여부가 구현마다 달라지는 문제
• Spring AI와 LangChain4j 구현 간 보안 기준의 차이

따라서 공식 RAG 샘플을 대체하는 신규 챗봇 구현이 아니라, 기존 자산을 안전하게 업무 시스템에 적용하기 위한 권한 보존형 RAG 보안·감사 프로파일과 검증 체크리스트를 가이드로 제공할 것을 제안합니다.

제안 내용 (Proposed Solution)

기존 대메뉴를 추가하지 않고 egovframe-runtime/ai-layer/ 하위에 다음 문서를 추가하는 방안을 제안합니다.

• 제안 파일명: rag-access-control-and-audit.md
• 제안 문서명: AI-RAG 권한 보존과 감사
• 적용 대상: 공식 egovframe-ai-rag의 Spring AI 및 LangChain4j 구현

1. 위협 모델과 적용 범위

다음 시나리오를 기준 위협으로 정의합니다.

• 다른 부서의 비공개 문서가 자연어 질의로 검색되는 경우
• 인제스트 후 원본 문서 권한이 공개에서 비공개로 변경된 경우
• 퇴직·전보·롤 변경 후 이전 권한이 검색에 남아 있는 경우
• 검색 결과를 제거하기 전에 문서가 LLM 컨텍스트나 로그에 들어간 경우
• 권한 확인 서비스 오류를 허용으로 처리하는 경우

가이드에서는 범용 챗봇 UI, 특정 모델 공급자, 자체 LLM 서버 구축은 범위에서 제외하고 접근 통제와 감사 기준에 집중합니다.

2. 인제스트 단계 권한 메타데이터 상속

원본 문서의 권한 정보를 청크 메타데이터에 함께 저장하는 최소 규격을 제시합니다.

필드 예시	설명
sourceType	게시판, FAQ, 문서관리 등 원본 유형
sourceId	원본 레코드 또는 문서 식별자
ownerDeptId	소유 부서
allowedRoleIds	접근 가능한 롤 목록
allowedGroupIds	접근 가능한 그룹 목록
securityLevel	공개·내부·제한 등 기관별 보안 등급
sourceUpdatedAt	원본 수정 시각
contentHash	변경 감지용 해시

기관마다 권한 체계가 다르므로 필드와 처리 원칙은 표준화하되 실제 값은 설정 또는 어댑터로 매핑하도록 안내합니다.

3. 검색 시점 사전 필터링(pre-filtering)

인증 사용자의 부서·롤·그룹 정보를 검색 조건에 먼저 반영하여, 권한이 없는 문서가 검색 결과와 LLM 컨텍스트에 들어가지 않도록 하는 흐름을 설명합니다.

인증 사용자
  → 권한 컨텍스트 생성
  → 메타데이터 필터 생성
  → 권한 조건이 포함된 벡터 검색
  → 허용 문서만 RAG 컨텍스트 구성

검색 후 제거(post-filtering)는 보조 방어 수단으로만 설명하고, 기본 구현은 사전 필터링을 사용하도록 권고합니다.

4. 응답 직전 원본 권한 재검증

벡터 저장소의 권한 메타데이터는 인제스트 시점의 정보일 수 있으므로, 검색된 sourceId를 기준으로 원본 시스템의 현재 권한을 다시 확인하는 절차를 제시합니다.

• 원본 삭제 문서 제외
• 공개에서 비공개로 변경된 문서 제외
• 사용자 부서·롤 변경 반영
• 권한 검증 실패 시 기본 거부(fail closed)
• 허용된 문서만 출처 목록에 표시

5. 개인정보 마스킹과 최소 수집

질의문, 검색 청크, 최종 응답 및 관리자 감사 화면에서 개인정보를 처리하는 지점을 구분하고, 기존 공통컴포넌트의 개인정보 처리 기능과 연계하는 방법을 안내합니다.

기본 감사 로그에는 원문 질의 전체보다 마스킹된 텍스트 또는 질의 해시를 저장하고, 원문 보관은 기관 정책에 따라 명시적으로 활성화하도록 제안합니다.

6. 감사 이벤트 표준

다음 항목을 구조화하여 기록하는 예시를 제공합니다.

항목	설명
요청자	사용자 식별자, 부서, 롤
질의 식별	마스킹 질의 또는 질의 해시
검색 근거	sourceId, 보안 등급, 검색 점수
제외 근거	권한 필터·재검증 제외 건수와 사유 코드
모델 정보	provider와 model 식별자
처리 결과	성공, 거부, 부분 응답, 오류
성능 정보	검색·모델·전체 지연시간
추적 ID	요청 전 구간 상관관계 ID

7. 구현별 예제

동일한 보안 원칙을 다음 두 구현에 대칭적으로 제시합니다.

• Spring AI: VectorStore 메타데이터 필터 적용 예시
• LangChain4j: 검색 필터 또는 Retriever 확장 예시
• 공통: 원본 권한 재검증 인터페이스와 감사 이벤트 처리 예시

특정 벡터 저장소나 권한 저장소에 종속되지 않도록 인터페이스와 어댑터를 분리하는 방향을 권고합니다.

8. 검증 체크리스트와 인수 테스트

문서 말미에 다음 필수 검증 항목을 체크리스트로 제공합니다.

• 권한 없는 문서는 벡터 검색 결과에 포함되지 않는다.
• 권한 없는 문서는 LLM 컨텍스트와 출처 목록에 포함되지 않는다.
• 인제스트 후 원본 권한을 변경하면 응답 직전 재검증에서 제외된다.
• 권한 검증 서비스 오류 시 해당 문서를 허용하지 않는다.
• 원문 민감 질의가 기본 감사 로그에 그대로 저장되지 않는다.
• 사용자별 동시 요청에서 권한 컨텍스트가 서로 섞이지 않는다.
• 감사 이벤트로 요청자, 근거 문서, 모델, 처리 결과와 지연시간을 추적할 수 있다.
• 관리자 화면에서도 권한 없는 원문과 민감 값은 마스킹된다.

9. 단계별 적용안

1. 1단계: 위협 모델, 메타데이터 규격, 체크리스트 문서화
2. 2단계: 공식 AI-RAG를 이용한 최소 참조 예제
3. 3단계: 공통컴포넌트 권한관리·게시판·FAQ 연동 어댑터 검토

제안자는 문서 초안, 최소 권한 시나리오, 단위·통합 테스트 예시를 준비하여 후속 PR로 기여할 의사가 있습니다.

대안 (Alternatives)

1. egovframe-ai-rag README에 보안 주의사항만 추가하는 방법

   • 장점: 변경 범위가 작습니다.
   • 한계: 실행환경 가이드와 분리되고, 두 기술 스택에 공통으로 적용할 운영 기준과 체크리스트를 충분히 설명하기 어렵습니다.

2. 일반적인 AI 보안 체크리스트만 제공하는 방법

   • 장점: 특정 구현에 종속되지 않습니다.
   • 한계: 공통컴포넌트의 사용자·롤·그룹·부서 권한과 실제 연결하는 방법이 부족합니다.

3. 별도 공통컴포넌트를 즉시 구현하는 방법

   • 장점: 동작 결과를 빠르게 확인할 수 있습니다.
   • 한계: 인터페이스와 인수 기준에 대한 합의 전에 구현 범위가 커질 수 있습니다.

따라서 우선 문서와 검증 기준을 합의하고, 이후 최소 PoC 또는 연동 어댑터로 확장하는 방안을 제안합니다.

관련 영역 (Affected Area)

• 개발환경 (egovframe-development/)
• 실행환경 (egovframe-runtime/)
• 공통컴포넌트 (common-component/)
• 기타 (README, 설정 파일 등)

참고 자료 (References)

• eGovFramework AI RAG 샘플: https://github.com/eGovFramework/egovframe-ai-rag
• eGovFramework 실행환경 AI 가이드: https://github.com/eGovFramework/egovframe-docs/tree/main/egovframe-runtime/ai-layer
• 관련 제안 [Feature] eGovFrame MCP Server 및 AI 친화 가이드 메타데이터 표준 제안 (AI 에이전트·LLM 연계) #628: [Feature] eGovFrame MCP Server 및 AI 친화 가이드 메타데이터 표준 제안 (AI 에이전트·LLM 연계) #628
• 관련 제안 [Feature] 표준프레임워크 AI 코드 생성 프롬프트 가이드 문서 추가 (LLM 연계) #636: [Feature] 표준프레임워크 AI 코드 생성 프롬프트 가이드 문서 추가 (LLM 연계) #636

[EricSeokgon]

현행 egovframe-ai-rag 코드 기준 갭 실측

제안 내용을 뒷받침하기 위해 현재 저장소를 확인했습니다. 가이드가 다루려는 지점이 실제로 비어 있어 공유드립니다.

1. 인제스트 메타데이터에 권한 필드가 없습니다

리더가 채우는 메타데이터는 다음 4개입니다 (EgovDocxReader · EgovHwpReader 등 공통).

필드	값
source	파일명
file_name	파일명
type	docx / hwp / pdf …
content_length	본문 길이

원본 시스템의 부서·롤·공개여부를 담을 자리가 없습니다. 현재 샘플이 파일 기반이라 자연스러운 결과이지만, 업무 시스템(게시판·문서관리)에 적용할 때 권한을 어디에 실어야 하는지에 대한 규격이 없다는 뜻이기도 합니다.

2. 검색 단계에 필터가 걸려 있지 않습니다

EgovRagConfig의 retriever 설정은 similarityThreshold 와 topK 만 사용합니다.

return VectorStoreDocumentRetriever.builder()
        .similarityThreshold(similarityThreshold)
        .topK(topK)
        .vectorStore(redisVectorStore)
        .build();

Spring AI의 VectorStoreDocumentRetriever 는 filterExpression 을 지원하지만 저장소 전체에서 사용처가 0건입니다. langchain4j 쪽 EgovHybridContentRetriever.retrieve(Query) 도 필터를 받지 않습니다.

즉 본 제안의 "검색 단계 pre-filtering"을 현 샘플 구조로는 시연할 수 없습니다.

3. 그래서 가이드만으로는 부족해 보입니다

문서로 "권한을 메타데이터에 상속하고 검색 시 pre-filtering 하라"고 적어도 참고할 코드가 없으면 기관마다 제각기 구현하게 됩니다. 이는 본 이슈가 지적한 문제(구현마다 기준이 달라짐)를 그대로 남깁니다.

가이드 + 최소 훅 예제를 함께 두는 방안을 제안드립니다.

• 가이드: 위협 모델 · 필드 규격 · 검증 체크리스트 (본 이슈)
• 예제: 메타데이터에 권한 필드를 싣고 filterExpression 으로 pre-filtering 하는 최소 경로 1건

예제는 인증 체계를 새로 도입하지 않고, 이미 있는 메타데이터 경로에 선택적 필드를 얹고 필터를 거는 수준으로 한정하면 샘플의 최소 골격 성격을 해치지 않을 것으로 봅니다. 기본값이 없으면 기존과 동일하게 동작하도록 하여 기존 사용자에게 영향이 없게 하고, 신규 의존성도 추가하지 않는 범위를 생각하고 있습니다.

방향에 대한 의견 주시면 그에 맞춰 진행하겠습니다. 예제가 이 저장소(egovframe-docs)가 아니라 egovframe-ai-rag 에 있어야 한다면 그쪽으로 별도 제안드리겠습니다.