권한을 뺏었는데 사내 AI는 문서를 보여준다? RAG가 원본 권한을 다시 확인해야 하는 이유

반응형

SharePoint, Google Drive와 Confluence를 AI에 연결하면 직원은 자연어로 사내 지식을 찾을 수 있습니다. 문제는 검색 색인이 문서뿐 아니라 권한도 복사해 보관한다는 점입니다.

퇴사나 부서 이동으로 원본 권한을 회수해도 다음 동기화 전까지 색인에는 이전 권한이 남을 수 있습니다. AWS는 2026년 10월 7일 이 간극을 줄이기 위해 검색 순간에 원본 시스템의 권한을 다시 확인하는 RAG 접근 제어 구조를 공개했습니다.

3줄 핵심 요약

• 사내 문서 권한을 검색 색인에 복사하는 방식은 다음 동기화 전까지 오래된 권한이 남아 AI 답변으로 민감정보가 노출될 수 있습니다.
• AWS는 벡터 검색 때 저장된 권한으로 후보를 줄인 뒤 Google Drive 같은 원본 시스템에 실시간으로 다시 묻는 2단계 검증 구조를 공개했습니다.
• 최종 권한이 확인된 문서 조각만 LLM에 전달해야 하며, 계정 매핑·원본 API 장애·감사 로그와 실패 시 차단 정책도 함께 설계해야 합니다.

복사된 권한은 현재 상태가 아니라 과거의 사진이다

일반적인 RAG 연결기는 문서를 가져올 때 접근 제어 목록도 함께 복사해 검색 색인의 속성으로 저장합니다. 질문이 들어오면 로그인한 사용자를 이 속성과 비교해 검색 결과를 걸러냅니다.

빠르고 단순하지만 저장된 권한은 마지막 동기화 시점의 상태일 뿐입니다. 동기화 간격 사이에 바뀐 인사와 공유 설정을 즉시 반영하지 못할 수 있습니다.

그룹에서 빠져도 다음 동기화 전에는 답변이 남을 수 있다

사용자를 프로젝트 그룹에서 제거했더라도 색인의 ACL이 갱신되지 않았다면 제한 문서가 검색 후보에 포함될 수 있습니다. 일부 원본은 그룹 멤버십 변경 이벤트를 제공하지 않아 이벤트 기반 갱신만으로도 완전하지 않습니다.

원본 서비스가 새 공유 기능이나 거부 규칙을 추가하면 연결기의 권한 변환 로직이 따라오기 전까지 또 다른 간극이 생길 수 있습니다.

1단계는 저장된 권한으로 검색 후보를 빠르게 줄인다

모든 문서의 권한을 매 질문마다 원본 API로 확인하면 비용과 지연이 커집니다. 먼저 벡터 색인에서 의미상 관련된 문서 조각을 찾고, 색인에 저장된 ACL로 1차 필터링합니다.

이 단계는 확인해야 할 문서 수를 작은 후보 집합으로 줄여 대규모 지식베이스에서도 검색 성능을 유지하는 역할을 합니다.

2단계는 원본 시스템에 지금 권한을 다시 묻는다

1차 후보가 정해지면 Amazon Quick은 Google Drive 같은 원본 서비스 API를 호출해 현재 사용자가 각 문서를 볼 수 있는지 실시간으로 확인합니다. 원본 시스템을 권한의 최종 기준으로 삼는 방식입니다.

권한이 확인되지 않은 문서는 검색 결과에서 제외되고, 검증을 통과한 문서 조각만 LLM의 문맥으로 전달됩니다.

LLM에 넣기 전에 차단해야 하는 이유가 있다

민감한 문서가 모델 문맥에 들어간 뒤 답변에서만 가리는 방식은 충분하지 않습니다. 생성 결과에 직접 나타나지 않아도 로그, 캐시와 추적 데이터에 남을 수 있고 다른 문장에 간접 반영될 위험이 있습니다.

권한 검증은 프롬프트를 구성하기 전 검색 계층에서 끝내고, 허용된 최소 조각만 모델로 보내는 것이 안전합니다.

실시간 검증도 계정 매핑과 장애 정책이 맞아야 한다

AI 서비스의 사용자 신원이 원본 시스템 계정과 정확히 연결되지 않으면 올바른 권한을 조회할 수 없습니다. 원본 API가 느리거나 실패했을 때 검증을 건너뛰고 답변하는 대신 기본 차단하는 정책도 필요합니다.

어떤 사용자와 문서를 확인했고 왜 제외했는지 감사 기록을 남기며, 서비스 계정과 사용자 가장 권한은 최소 범위로 제한해야 합니다.

사용자와 업계에 미치는 영향

사내 AI를 도입하는 조직은 문서를 얼마나 많이 연결했는지보다 권한 변경이 답변에 얼마나 빨리 반영되는지 측정해야 합니다. 사용자는 원래 볼 수 없는 문서를 AI가 요약해 주지 않는다는 보장을 받아야 하고, 보안팀은 색인의 복제 권한과 원본의 현재 권한 사이 차이를 관찰해야 합니다.

2단계 검증은 검색 성능을 유지하면서도 최종 판단을 원본에 맡기는 현실적인 구조지만, 신원 전파와 장애 시 차단이 함께 작동해야 의미가 있습니다.

확인할 점

이 글은 AWS가 2026년 10월 7일 공개한 Amazon Quick과 Amazon Bedrock Knowledge Bases의 기술 설명을 바탕으로 정리했습니다. 공개 글은 Google Drive 예시를 중심으로 하며 모든 데이터 소스와 권한 모델이 동일하게 지원된다는 뜻은 아닙니다.

실시간 확인 속도, API 할당량, 연결기 기능과 비용은 원본 서비스와 구성에 따라 달라집니다. 도입 전 지원 데이터 소스, 계정 가장 방식, 실패 시 동작, 로그 보존과 최신 제품 문서를 확인해야 합니다.

출처

함께 읽을 글

• AI 에이전트에 도구 170개를 보여주면 왜 틀릴까: Postman의 4천만 사용자 운영 교훈
• Claude Haiku 5.5, AWS Bedrock 출시: 빠른 AI 서브에이전트에 맞춘 모델
• localhost 공유 링크, 이제 이메일로 잠근다: Cloudflare 보호형 Quick Tunnel

• AWS Artificial Intelligence Blog — Rethinking access control for RAG with Amazon Quick and Amazon Bedrock

728x90