폴더 권한을 회수해도 RAG 인덱스에는 예전 권한이 남을 수 있습니다

사내 문서 AI 소개 자료를 개정하다가 제가 고쳐 쓴 문장이 틀렸습니다. 문장은 '권한은 답변 단계가 아니라 검색 단계에서 적용합니다'였습니다.

이전 판 그림은 질의 흐름의 끝에서 권한을 검증하도록 그려져 있었습니다. 끝에서 확인하면 LLM 은 이미 문서 내용을 읽은 뒤입니다. 그래서 확인 위치를 앞으로 옮기는 문장으로 고쳤습니다.

이 문장을 의심한 사람은 자료를 검토하던 분이었습니다. '양쪽 모두 적용하는 것이 맞지 않느냐'는 질문이 나왔습니다. 마이크로소프트 문서를 확인해 보니 검색 인덱스의 권한은 문서 저장소보다 늦을 수 있었습니다.

실제 사고가 난 건은 아닙니다. 자료를 개정하다 발견한 설계 문제이고, 아래 부서 이동 사례도 설명을 위한 예시입니다. 근거 문서가 SharePoint 와 Azure AI Search 기준이라 그 조합으로 설명합니다. 특정 회사의 구성을 말하는 글이 아닙니다.

검색 단계에서 거르는 것만으로 부족한 이유

먼저 용어 셋을 정리합니다.

ACL: 문서별 접근 권한 목록

보안 필터링(security trimming): 사용자가 볼 수 없는 문서를 검색 결과에서 제외하는 처리

인덱스: 검색을 위해 문서 내용과 권한 정보의 사본을 저장한 곳

제 문장의 전제는 '인덱스의 권한 정보가 문서 저장소와 같다'였습니다. 그런데 인덱스는 저장소의 사본이고, 그 안의 권한 정보도 사본입니다. 문서 내용이 늦게 반영될 수 있다면 권한도 늦게 반영될 수 있습니다.

이 구조를 처음 본 것은 아니었습니다. 접근 권한을 사본 테이블로 판정했더니 떠난 담당자가 그대로 남았던 적이 있습니다. 사본이 기준 데이터보다 늦으면 권한 판정도 같이 늦습니다.

공식 문서의 표: 상속 권한 변경은 자동으로 감지되지 않습니다

근거는 Azure AI Search 의 SharePoint 권한 메타데이터 문서입니다. 제가 확인한 것은 2026-08-08판이고, 이 기능은 프리뷰입니다. 문서 내용을 표로 옮기면 이렇습니다.

핵심은 둘째 줄입니다. 인덱서(문서를 읽어 인덱스에 넣는 작업)는 상위 폴더에서 바뀐 상속 권한을 스스로 감지하지 못합니다. 그래서 /resync 나 /resetdocs 같은 갱신 요청을 따로 실행해야 합니다.

문서에는 갱신 절차 없이 권한을 바꾸면 이미 수집한 파일이 변경 전 ACL 로 제공된다고 적혀 있습니다. '자동 동기화'라는 말만 믿고 넘어가면 놓치기 쉬운 문장입니다.

예를 들어 부서를 옮긴 직원의 권한을 폴더 단위로 회수했다고 가정합니다. 저장소에서는 회수가 끝났어도, 갱신 전까지 인덱스에는 이전 권한이 남을 수 있습니다. 이 상태에서 검색 단계 필터만 쓰면 회수된 권한이 그대로 통과할 수 있습니다.

표 밖에도 확인할 제약이 둘 있습니다.

'Anyone' 공유 링크, 조직 전체 공유 링크, 외부 사용자는 프리뷰에서 지원하지 않습니다

청킹(문서를 작은 조각으로 나누는 처리)을 쓰면 모든 청크에 권한 필드를 저장해야 합니다. 빠지면 권한이 있는 사용자에게도 그 청크를 보여 줄 수 없습니다

인덱스에 저장한 권한은 저장 시점의 값입니다. 색인할 때 계산해 저장한 값이 규칙을 고쳐도 옛 데이터에 따라오지 않는 일은 다른 작업에서도 본 적이 있습니다.

표는 프리뷰 기능 기준이라 달라질 수 있습니다. 적용 전에 현재 문서를 다시 확인하는 편이 안전합니다.

문서 단위 접근 제어의 전체 구성은 개요 문서에 따로 정리되어 있습니다.

권한을 확인하는 위치는 네 가지입니다

권한을 어디서 확인하느냐에 따라 구성은 네 가지로 나뉩니다.

제 첫 수정은 (A) 를 피해 (B) 로 옮긴 것이었습니다. 문제 하나를 고치면서 다른 문제를 만든 셈입니다. 최종 규칙은 (C) 입니다. (D) 는 이번에 비교 검증을 하지 않아 판단을 내리지 않았습니다.

기준은 '답변을 보여 주기 전'이 아니라 '모델에 넘기기 전'입니다

답변을 화면에 보여 주기 직전에 막아도, 모델에는 이미 문서 내용이 들어간 뒤입니다. 그래서 권한 확인은 LLM 이 내용을 읽기 전에 끝내기로 정했습니다.

(C) 에서 두 단계가 맡는 일은 다릅니다. 검색 단계는 인덱스의 권한 정보로 볼 수 없는 문서를 먼저 거릅니다. 재확인 단계는 최종 근거 문서의 권한을 저장소에서 다시 읽어, 인덱스에 아직 반영되지 않은 변경을 확인합니다.

앞 단계와 뒤 단계 중 하나를 고르는 문장은 그럴듯해 보입니다. 제 문장이 그랬습니다. 그러나 둘이 맡는 일이 다르면 둘 다 필요합니다.

남은 것은 재확인이 실패했을 때입니다. 저장소 응답을 받지 못하거나 권한을 판단할 수 없으면 허용하지 않고 거부합니다. 허용을 기본값으로 두면 저장소에 장애가 난 동안 권한 없는 사람에게도 문서가 넘어갈 수 있습니다. 권한 쪽의 기본값은 '모르면 거부'입니다.

소개 자료를 다시 고치고 규칙 여섯 개로 정리했습니다

소개 자료의 질의 흐름 장을 고치고 아래 규칙으로 정리했습니다.

검색 단계에서 인덱스의 권한 정보로 먼저 거른다

LLM 에 넘기기 전에 최종 근거 문서의 저장소 권한을 다시 확인한다

'답변 후' 필터는 쓰지 않는다

권한을 확인할 수 없으면 허용하지 말고 거부한다

상속 권한 변경을 반영하는 정기 갱신 절차를 운영 범위에 넣는다

청킹을 쓰면 모든 청크에 권한 필드를 저장한다

규칙 5 는 개발이 끝나도 계속되는 일입니다. 상속 권한 변경은 자동으로 감지되지 않기 때문에, 갱신을 일회성 설정이 아니라 운영 업무로 적었습니다.

여기까지가 이번에 정리한 범위입니다. 고친 것은 소개 자료의 문장과 규칙이고, 실제 제품 구현에 이 구성이 들어가는지는 확인하지 않았습니다. 규칙 2 가 응답 시간에 주는 영향도 측정하지 않았습니다.

아직 확인하지 못한 것

표는 2026-08-08판, 프리뷰 기능 기준입니다

SharePoint 와 Azure AI Search 조합의 내용입니다. 다른 문서 저장소나 검색 제품은 권한 변경이 어떻게 반영되는지 따로 확인이 필요합니다

두 단계를 함께 쓰도록 정한 공식 표준은 찾지 못했습니다. 검색 자료는 대부분 벤더 글이었고, OWASP RAG 보안 지침은 검색 요약으로만 보았을 뿐 원문을 읽지 않았습니다

재확인 대상은 최종 근거 문서로 잡았습니다. 근거를 고르는 과정에 LLM 을 쓰는 구성이라면 그 입력도 따져 봐야 할 것으로 추정합니다

같은 구성을 쓴다면 먼저 볼 것

동기화 기능이 어떤 권한 변경까지 자동 감지하는지 표로 확인했는가

상위 폴더·사이트의 권한 변경을 반영하는 갱신 절차가 운영 범위에 있는가

LLM 에 넘기기 전에 문서 저장소의 권한을 다시 확인하는 단계가 있는가

권한을 확인할 수 없을 때 거부하도록 정해 두었는가

모든 청크에 권한 필드가 저장되어 있는가

'자동 동기화된다'는 말만으로는 어떤 변경까지 따라오는지 알 수 없습니다. 이번 표에서도 개별 항목은 감지되고 상속 권한은 감지되지 않았습니다. 사내 문서 AI 의 권한을 설계하고 있다면 쓰는 제품의 문서에서 이런 표부터 찾아보시길 권합니다.