본문으로 건너뛰기
AI 8분 읽기

RAG 접근 제어 설계: 벡터 검색에도 사용자 권한이 필요하다

사내 문서를 벡터화할 때 원문 권한이 사라지는 문제를 막기 위한 메타데이터, 필터, 감사 로그 기준을 설명한다. RAG·Access Control·Vector DB 관점에서 처음 접하는 독자도 개념, 적용 조건, 실패 가능성을 차례대로 이해할 수 있게 설명한다.

박지민
에디터
2026년 6월 21일
RAG 접근 제어 설계: 벡터 검색에도 사용자 권한이 필요하다

핵심 요약

RAG는 원문을 벡터로 바꾸는 순간 기존 문서 시스템의 권한을 자동으로 이어받지 않는다. 수집·청킹·색인·검색·프롬프트 조립·로그 저장의 모든 단계에서 테넌트와 사용자 권한을 보존하고, 검색 전에 권한 필터를 적용하며, 원문 권한 변경과 삭제를 색인에 동기화해야 한다.

사내 검색형 AI를 빠르게 만들 때 가장 흔한 설계는 문서를 모두 수집해 하나의 벡터 저장소에 넣고, 질문과 가까운 청크를 찾아 모델에 전달하는 방식이다. 이 구조는 검색 품질만 보면 단순하지만, 원문 문서의 폴더 권한·보안 등급·퇴사자 차단·고객별 테넌트 경계가 벡터 저장소에서 사라질 수 있다.

벡터는 사람이 읽기 어려운 숫자 배열이지만 안전한 데이터가 아니다. 벡터와 메타데이터, 청크 원문, 검색 결과, 모델 입력 로그를 결합하면 민감한 내용을 복원하거나 노출할 수 있다. 따라서 접근 제어는 모델 응답 뒤에서 검사하는 것이 아니라 검색 후보를 만들기 전부터 적용되는 데이터 경계여야 한다.

권한이 끊기는 지점을 먼저 찾는다

단계권한 손실 위험필요한 통제
수집서비스 계정이 모든 문서를 읽고 출처 ACL을 버림원문 ACL·테넌트·등급을 함께 수집
청킹하위 청크가 원문 식별자와 권한을 잃음모든 청크에 원문 ID와 정책 버전 상속
임베딩민감 원문이 외부 임베딩 서비스로 전송데이터 처리 범위·보존·지역 검증
색인여러 테넌트가 같은 네임스페이스에 혼합논리·물리 분리와 기본 거부 필터
검색top-k 이후 애플리케이션에서 사후 필터검색 엔진 단계에서 권한 선필터
프롬프트허용되지 않은 청크가 모델 컨텍스트에 포함모델 호출 전 최종 정책 검증
로그질문·검색 청크·응답이 장기 보존최소 수집, 마스킹, 접근·보존 정책

권한 검사는 사용자가 볼 수 없는 문서를 답변에서 숨기는 수준에 그치면 안 된다. 허용되지 않은 청크가 모델 입력이나 디버그 로그에 들어간 순간 이미 경계가 깨진 것이다.

권한 메타데이터의 최소 스키마

벡터 청크마다 검색 품질 필드와 별도로 다음 정보를 유지한다.

{
  "tenant_id": "tenant-42",
  "source_id": "doc-8f1a",
  "chunk_id": "doc-8f1a#17",
  "classification": "confidential",
  "allowed_subjects": ["group:finance", "user:1234"],
  "denied_subjects": ["user:5678"],
  "policy_version": "2026-06-18T09:00:00Z",
  "source_updated_at": "2026-06-18T08:55:00Z",
  "expires_at": null,
  "deleted": false
}

실제 스키마는 IdP와 문서 시스템에 맞게 정하되, 최소한 테넌트, 원문 ID, 청크 ID, 권한 주체, 정책 버전, 삭제 상태를 추적할 수 있어야 한다. 그룹 목록이 매우 크면 모든 사용자를 청크에 복제하기보다 정책 ID나 ACL 집합 ID를 참조하고, 검색 시점에 현재 사용자의 그룹을 정책 엔진에서 해석한다.

검색 전에 권한을 줄인다

권장 흐름은 다음과 같다.

  1. 인증된 사용자와 테넌트 정보를 서버 세션에서 얻는다.
  2. 현재 역할·그룹·고위험 상태를 정책 엔진에서 계산한다.
  3. 벡터 검색 쿼리에 테넌트와 권한 필터를 함께 전달한다.
  4. 반환된 청크의 정책 버전과 원문 상태를 재검증한다.
  5. 허용된 청크만 모델 컨텍스트에 넣는다.
  6. 응답에는 출처 링크와 권한 범위 내 인용만 제공한다.

top-k 검색 후 애플리케이션에서 금지 문서를 빼는 사후 필터만 사용하면 품질과 보안이 동시에 흔들린다. 상위 결과 대부분이 금지 문서일 경우 허용된 결과가 부족해지고, 이미 검색 결과 로그나 추적 데이터에 금지 문서가 남을 수 있다.

원문 권한 변경을 색인에 동기화한다

권한 동기화는 초기 수집보다 어렵다. 문서가 공개에서 비공개로 바뀌거나, 사용자가 부서에서 이동하거나, 계약 종료 고객의 데이터가 삭제될 때 벡터 색인도 같은 속도로 바뀌어야 한다.

  • 원문 시스템의 변경 이벤트나 증분 크롤링으로 ACL 변경을 감지한다.
  • 권한이 강화된 문서는 재임베딩보다 먼저 검색 차단 상태로 전환한다.
  • 삭제 요청은 원문, 청크, 임베딩, 캐시, 평가 데이터, 로그 복제본까지 추적한다.
  • 동기화 실패 시 마지막 성공 시각과 지연량을 경보로 만든다.
  • 정책 버전이 오래된 청크는 검색에서 기본 제외하도록 설계한다.
  • 전체 재색인 중에도 구색인과 신색인의 권한 규칙이 동일한지 검증한다.

특히 그룹 멤버십은 매 검색 시 최신 상태를 확인하거나 짧은 캐시 만료를 사용한다. 퇴사자나 권한 회수 사용자가 오래된 세션·그룹 캐시로 문서를 계속 검색하지 못하도록 세션 폐기와 ACL 캐시 무효화를 연결한다.

멀티테넌트 분리 수준을 정한다

하나의 벡터 DB에서 tenant_id 필터만 사용하는 방식은 운영이 단순하지만, 필터 누락 한 번이 전체 고객 간 노출로 이어질 수 있다. 데이터 민감도와 장애 영향에 따라 다음을 선택한다.

  • 저위험 내부 지식: 공유 인덱스 + 강제 테넌트 필터 + 자동 테스트
  • 고객별 기밀 데이터: 테넌트별 네임스페이스 또는 컬렉션 분리
  • 규제·고위험 데이터: 별도 프로젝트·계정·암호화 키·운영 권한 분리

어떤 방식을 선택하든 애플리케이션 개발자가 필터를 선택적으로 넣지 못하도록 공통 검색 라이브러리나 게이트웨이에서 강제한다.

실패 모드와 탐지 신호

신호가능한 실패즉시 확인
응답 출처의 테넌트가 사용자와 다름테넌트 필터 누락쿼리 필터, 세션 테넌트, 캐시 키
ACL 동기화 지연이 기준 초과변경 이벤트 누락·크롤러 장애마지막 성공 시각, 실패 큐
source_id 없는 청크 증가청킹 파이프라인 메타데이터 손실수집 버전과 변환 코드
권한 거부율 급감정책이 우회되거나 기본 허용으로 변경최근 정책 배포와 필터 조건
검색 로그에서 기밀 분류 청크 발견로그 마스킹·접근 통제 실패추적 샘플, 로그 보존·조회자
동일 질문의 결과가 사용자별로 같아짐사용자 권한이 캐시 키에 미포함검색·응답 캐시 키 구성

탐지용으로 가짜 기밀 문서와 고유 canary 문자열을 넣어 권한 없는 테스트 계정에서 절대 검색되지 않는지 지속 검사할 수 있다. 이 문서가 검색되면 모델 응답 전 단계에서 즉시 배포를 차단한다.

권한 회귀 테스트

최소한 다음 케이스를 자동화한다.

  • 같은 테넌트의 허용 사용자와 비허용 사용자
  • 서로 다른 테넌트의 동일 문서명
  • 사용자의 그룹 탈퇴 직후
  • 문서 등급이 공개에서 기밀로 바뀐 직후
  • 원문 삭제 후 캐시·로그·평가셋 검색
  • 인덱스 재구축과 롤백 중
  • 프롬프트 인젝션 문서가 다른 문서 접근을 요구하는 경우

모델의 자연어 답변만 판정하지 말고 검색된 chunk_id, source_id, tenant_id, 정책 결정 결과를 구조화해 검사한다.

사고 대응 순서

  1. 의심 인덱스와 응답 캐시의 검색을 중지하거나 안전한 컬렉션으로 전환한다.
  2. 영향받은 사용자·테넌트·청크 ID를 감사 로그로 산정한다.
  3. 모델 제공자와 관측성 시스템에 원문이 전송·보존됐는지 확인한다.
  4. 노출 가능 세션과 서비스 계정 토큰을 회수한다.
  5. 관측성 데이터 개인정보 점검으로 로그 2차 노출을 확인한다.
  6. 확인된 사실과 조사 범위를 사고 커뮤니케이션 절차에 따라 공유한다.
  7. 필터 누락이 재현되는 테스트를 CI 차단 조건으로 추가한다.

운영 체크리스트

  • 모든 청크에 테넌트·원문 ID·정책 버전이 있다.
  • 검색 엔진 단계에서 권한을 선필터한다.
  • 공통 검색 계층이 테넌트 필터를 강제한다.
  • 원문 ACL 변경·삭제가 색인과 캐시에 전파된다.
  • 정책 동기화 지연과 메타데이터 누락을 경보로 만든다.
  • 사용자·테넌트·권한 버전이 캐시 키에 포함된다.
  • 질문·검색 청크·응답 로그의 접근과 보존 기간을 제한한다.
  • canary 문서로 교차 테넌트 검색을 지속 테스트한다.
  • 모델 호출 전에 반환 청크를 최종 재검증한다.

함께 읽을 글

RAG가 검색 결과를 바탕으로 외부 시스템을 실행한다면 AI 에이전트 도구 권한 설계를 반드시 함께 적용해야 한다.

참고 기준

결론

RAG의 검색 정확도는 권한 정확도보다 우선할 수 없다. 원문 권한을 청크 메타데이터에 보존하고, 검색 전에 강제하며, 권한 변경과 삭제를 지속 동기화하는 구조가 없으면 벡터 검색은 사내 지식 도구가 아니라 새로운 데이터 우회 경로가 된다.

전체 댓글 0

댓글을 불러오는 중입니다...
새로고침

태그

RAG Access Control Vector DB

공유하기

관련 기사