기업용 RAG에서 가장 무서운 실패는 엉뚱한 답이 아니라 권한 없는 문서가 답에 섞이는 것입니다. 전략 문서나 미공개 재무, 인사 정보가 한 문장으로 새면 검색 정확도는 의미가 없습니다.

10월 7일 AWS가 이 문제의 해법을 구조로 공개했습니다. Amazon Quick과 Bedrock Knowledge Bases에서 쓰는 실시간 ACL 강제입니다. 검색 인덱스의 권한 정보로 먼저 걸러낸 다음, 원본 시스템에 현재 권한을 다시 확인하는 2단계 방식입니다.

인덱스 사전 필터와 원본 시스템 실시간 검증을 거친 문서만 LLM에 전달되는 2단계 권한 구조

위 그림이 전부입니다. 빠른 필터로 후보를 좁히고, 진짜 권한은 원본에 물어봅니다.

왜 기존 방식은 뚫리나: 세 가지 구멍

흔한 방식은 복제 후 필터입니다. 커넥터가 주기적으로 ACL을 가져와 인덱스에 속성으로 저장하고, 조회 때 로그인 사용자와 대조해 걸러냅니다. 겉보기엔 합리적이지만 구멍이 셋 있습니다.

첫째, AI 시스템이 권한의 주인이 아닙니다. SharePoint와 Drive, Confluence는 권한 모델이 제각각이라 상속과 그룹, 조건부 정책, 거부 규칙을 커넥터마다 옮겨 담아야 합니다. 옮기는 코드가 곧 보안 경계가 되는데, 이 매핑은 틀리기 쉽습니다.

둘째, 동기화 사이가 비어 있습니다. 커넥터는 주문형이나 예약 동기화를 돕니다. Confluence처럼 그룹 변경 이벤트를 안 주는 시스템도 있습니다. 접근이 철회된 사용자가 다음 동기화 전까지는 못 봐야 할 문서를 AI 답으로 받는 겁니다. 몇 시간이나 며칠씩 구멍이 열립니다.

셋째, 원본이 바뀝니다. SharePoint에 새 권한 기능이 생기거나 Drive 공유 모델이 바뀌면 매핑 로직이 뒤처집니다. 커넥터가 고쳐지기 전까지 노출됩니다.

그래서 AWS는 기존 사전 필터 위에 실시간 검사를 한 층 더 올렸습니다. 인덱스 정보는 효율용, 진짜 판단은 조회 시점의 원본 확인용입니다.

2단계 구조: Drive 예시로 보기

Quick 에이전트가 Google Drive 지식베이스를 쓰는 흐름으로 보죠.

1단계는 사전 필터입니다. 벡터 인덱스에서 의미 검색을 돌리고, 인덱스에 든 ACL로 후보를 먼저 좁힙니다. 인덱스 전체를 매번 실시간으로 물어보면 비용이 감당이 안 되니 꼭 필요한 단계입니다.

2단계는 실시간 검증입니다. 관리자가 준 서비스 계정으로 사용자별 토큰을 가장해서 Drive API에 물어봅니다. 권한의 진실은 Drive에 있습니다. 권한 없는 문서는 검색 결과에서 빠지고, 남은 문서만 LLM 컨텍스트로 갑니다.

사용자 질문
  -> Stage 1: 인덱스 검색 + 저장된 ACL로 후보 추출
  -> Stage 2: 원본 API에 현재 권한 확인
     · 허용이면 LLM 컨텍스트로 전달
     · 거부이면 제외, deny가 allow를 이김
  -> LLM 답변 생성

이중 구조라 성능과 보안을 함께 잡습니다. Bedrock 쪽에는 Guardrails와 그라운딩 검사 같은 책임 AI 제어도 붙습니다.

지원 범위는 커넥터마다 다릅니다. SharePoint와 OneDrive, Google Drive, Confluence는 사전 필터와 실시간 검증을 같이 씁니다. S3와 Custom은 고객이 준 메타데이터가 진실이라 실시간 검증이 없습니다. 웹 크롤러는 권한 모델이 없어 ACL 자체가 안 됩니다.

실패는 닫힌 쪽으로 흐릅니다. 그룹 해석이나 실시간 확인, 내부 오류가 나면 해당 문서는 안 내보냅니다. 일시 장애가 권한 없는 노출로 바뀌지 않는 겁니다. 대신 앱이 사용자를 먼저 인증하고, 메일이 원본과 정확히 일치해야 합니다. 메일이 다르면 조용히 결과가 빕니다. ACL 기능 자체가 인증을 대신하지 않는다는 점은 문서에 못 박혀 있습니다.

현장의 한마디: 3만 5천 명의 눈치

Mondelēz의 얘기가 인용됐습니다. 보안과 컴플라이언스 팀의 최우선 요구가 동료는 허가된 정보만 보게 해달라는 것이었고, 많은 플랫폼이 이걸 제대로 못 풀었다는 겁니다. Quick의 실시간 접근 제어가 내부 심사를 통과시켰고, 4개 지역 3만 5천 명이 넘는 직원에 배포됐다고 합니다.

디버깅 통로도 열려 있습니다. 9월에 나온 CheckIngestedDocumentAcl과 GetIngestedDocumentAcl API, 콘솔의 문서 접근 제어 화면으로 특정 사용자의 문서 접근 여부와 문서의 전체 ACL을 직접 확인할 수 있습니다. 권한 문제인지 다른 문제인지 가르는 데 씁니다.

CodeBridge Mini Lab: 철회 직후를 재현하라

브리핑의 실무 액션 그대로, 공유 권한을 뺀 직후를 시험하세요.

1. 문서 하나와 사용자 둘: 허용 사용자와 철회 대상
2. 철회 직후 질문: 해당 문서 내용만으로 답할 수 있는 질문 던지기
3. 확인: 검색 결과와 AI 답변에서 해당 문서가 빠지는지
4. 경계: 거부 규칙이 허용을 이기는지, 그룹 변경도 반영되는지
5. 장애: 원본 API가 느릴 때 문서가 열리지 않고 닫히는지

S3나 Custom처럼 실시간 검증이 없는 커넥터는 동기화 주기를 문서로 남기고, 철회 반영 시간을 따로 재세요. 이메일 재할당 같은 생명주기 문제도 앱에서 먼저 막아야 합니다.

검색 품질 얘기는 고전·그래프·에이전트 RAG 글과 실패 분석 글에서, 사내 문서 챗봇 설계는 내부 문서 챗봇 글에서 이어집니다.

결론: RAG 보안은 필터가 아니라 확인이다

한 줄로 정리합니다.

인덱스의 권한은 후보용, 답에 쓰는 권한은 조회 시점의 원본 확인용.

동기화 사이를 없앨 수는 없어도 실시간 확인으로 좁힐 수는 있습니다. 권한 철회 직후 테스트를 통과하지 못한 RAG는 검색을 더 고치기 전에 권한 층부터 손보세요. 못 보는 문서를 안 보여주는 일이 정확도만큼 중요합니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

검색과 생성의 구조를 개선하고, 권한과 비용, 지연까지 함께 설계해보고 싶다면 Classic과 Graph, Agentic RAG를 잇는 과정이 이 글의 2단계 검증 이야기와 바로 이어집니다.