RAG는 누구의 권한으로 문서를 읽는가

로그인한 사용자가 검색된 모든 문서를 읽을 수 있는 것은 아니다. Azure AI Search의 문서 권한과 벡터 필터를 사례로, RAG의 사용자 식별부터 청크·검색·권한 회수까지 이어지는 접근 통제를 살핀다.

표지는 사용자별 문서 접근 범위를 표현한 AI 생성 개념 이미지다. 특정 제품의 구성도나 실제 보안 검사 결과가 아니다.

두 직원이 사내 AI에 같은 질문을 한다. “이번 제안의 가격은 어떤 근거로 정했나요?” 한 사람은 고객에게 보낼 제안서를 읽을 수 있고, 다른 사람은 원가와 협상 한도가 담긴 내부 부록까지 볼 수 있다. 두 사람에게 같은 검색 결과와 답변을 돌려주는 것이 언제나 좋은 서비스는 아니다. 이 가상의 사례에서는 질문의 의미가 같아도 답변의 근거로 쓸 수 있는 자료가 다르다.

문서를 찾아 모델에 제공하는 RAG를 평가할 때는 관련 자료를 얼마나 잘 찾는지에 관심을 둔다. 업무에 붙이면 그보다 먼저 정해야 할 범위가 생긴다. 지금 질문한 사람이 읽을 수 있는 문서는 무엇인가. 검색 서비스를 호출하는 애플리케이션이 가진 권한과, 그 서비스를 이용하는 직원의 권한은 어떻게 이어지는가.

앞선 검색된 문서는 명령이 아니다는 읽어 온 내용을 시스템의 지시로 신뢰할 때 생기는 문제를 다뤘다. 이번 글은 읽어 오기 전의 선택을 살핀다. 사용자가 볼 수 있는 근거를 먼저 정하고, 그 범위 안에서 좋은 답을 찾는 과정이다.

로그인에서 문서 권한까지는 한 단계가 더 있다

로그인은 요청한 사람이 누구인지 확인한다. 그 사람이 어떤 자료를 읽을 수 있는지는 별도의 판단이다. 검색 서버에 접속할 수 있는 애플리케이션의 자격만 확인한 뒤 전체 색인에서 자료를 가져오면, 직원별로 나눠 둔 문서 권한이 검색에 반영되지 않을 수 있다.

Azure AI Search의 문서 접근 제어는 이 차이를 보여준다. 검색 클라이언트가 색인을 조회할 권한과 최종 사용자가 개별 문서를 읽을 권한을 따로 다룬다. 기본 제공 문서 권한 기능에서는 사용자 토큰을 쿼리의 x-ms-query-source-authorization에 전달하고, 색인에 들어 있는 권한 정보와 대조한다. 2026년 10월 20일 확인한 문서에서 여러 기본 제공 ACL·RBAC 연동 기능은 미리 보기 단계다. 실제 적용 가능 여부는 데이터 원본과 API 지원 범위를 확인해야 한다. 문서 수준 접근 제어 개요

필터로 직접 구현하는 방식도 있다. 문서에 허용된 사용자나 그룹의 식별자를 넣고, 요청자의 식별자와 맞는 문서만 검색하는 것이다. Microsoft 문서는 이런 보안 필터의 문자열 비교 자체가 인증이나 권한 부여를 수행하지 않는다고 명시한다. 따라서 브라우저가 보낸 그룹 이름을 그대로 믿어서는 안 된다. 신뢰할 수 있는 인증 결과에서 요청자의 범위를 구하고, 서버가 그 범위를 검색 조건에 넣는 연결이 필요하다. 보안 필터 구현 문서

공식 RAG 예제인 Azure-Samples의 azure-search-openai-demo도 인증 사용과 접근 제어 강제를 별도 설정으로 둔다. 확인한 기본 브랜치 main의 고정 버전은 받은 토큰을 검증한 뒤 검색용 토큰을 얻고, 접근 제어가 필요한 경우 이를 전달하도록 구현한다. 로그인 화면이 보인다는 사실만으로 문서별 통제가 켜졌다고 판단할 수 없는 구체적인 이유다. 설정 설명, 인증 처리 코드

문서를 쪼개도 권한은 따라가야 한다

RAG는 긴 문서를 작은 조각인 청크로 나눠 검색하는 경우가 많다. 원본 파일에는 접근 권한이 있어도 검색 대상 청크에서 그 정보를 잃으면, 원본의 통제를 검색에 사용할 수 없다. 어떤 조각이 어느 문서에서 왔는지와 누가 읽을 수 있는지를 함께 추적해야 한다.

Azure AI Search 문서는 스킬셋으로 청크를 만들 때 권한 필드를 자식 문서의 색인 투영에 포함하도록 안내한다. 원본 레코드의 설정이 청크에 자동으로 옮겨졌다고 가정하지 말고, 실제 검색 대상에 권한 정보가 들어 있는지 확인해야 한다는 뜻이다. 청크 색인의 권한 필드 안내

실무 설계에서는 색인을 만들 때 이를 검사하는 편이 유용하다. 원본 식별자와 권한 정보가 연결되지 않은 청크는 검색에 노출하지 않고, 공개 자료는 공개라는 상태를 명시하도록 정할 수 있다. 이것은 특정 제품이 모두 보장한다는 설명이 아니라, 누락된 값을 무제한 공개로 해석하지 않기 위한 운영 제안이다.

검색 결과에 붙는 인용 링크도 같은 관점에서 봐야 한다. 본문을 제한했어도 링크를 따라 원본을 여는 경로에서 권한을 확인하지 않으면 전체 흐름을 검증한 것이 아니다. 앞의 공식 예제는 인용 대상 파일의 경로를 확인할 때도 사용자 토큰을 붙여 해당 파일의 검색 결과가 허용되는지 검사한다. 검색과 원문 열기가 같은 사용자의 범위로 이어지는지를 살펴볼 만한 구현이다. 인용 경로 권한 검사

권한 안에서 잘 찾는 일도 따로 평가해야 한다

권한 조건을 적용했다고 해서 검색 품질까지 해결되는 것은 아니다. 먼저 전체 자료에서 가까운 후보를 좁힌 뒤 허용되지 않은 문서를 빼면, 읽을 수 있는 좋은 문서가 처음 후보에 들어오지 못할 수 있다. “답할 자료가 없다”는 결과가 실제 자료의 부재인지, 필터 적용 순서가 만든 누락인지 구분해야 한다.

Azure AI Search의 벡터 검색은 이 순서를 명시한다. preFilter는 각 샤드의 HNSW 그래프를 탐색하는 동안 조건을 적용한다. postFilter는 샤드별로 먼저 찾은 상위 후보를 거른 뒤 결과를 합치므로, 조건에 맞는 문서가 드물거나 후보 수가 작으면 누락이 생길 수 있다. 미리 보기 기능인 strictPostFilter는 전체 상위 후보를 정한 뒤 거른다. 반대로 탐색 중 필터링은 조건이 까다로울 때 연산량과 지연이 늘 수 있다. 벡터 검색 필터의 적용 시점

여기서 사후 필터라는 말은 검색 엔진 내부의 후보 선택 순서를 가리킨다. 허용되지 않은 본문을 모델에 먼저 보내고 최종 답변에서 가리는 방식과 혼동하면 안 된다. 어떤 검색 모드를 쓰더라도 모델에 넘길 근거와 사용자에게 돌려줄 결과가 요청자의 허용 범위 안에 있는지 확인해야 한다.

앞의 가상 사례로 돌아가면 평가 정답도 직원별로 달라진다. 제안서만 볼 수 있는 직원에게는 그 제안서 안의 가격 설명을 찾는지가 중요하다. 내부 부록의 세부 원가까지 답해야 높은 점수를 주는 평가라면, 접근 통제를 제대로 한 시스템을 오히려 감점하게 된다. 팀은 권한 밖 자료의 유출 여부와 권한 안 자료의 검색 누락을 별도로 측정할 수 있다. 같은 질문에 서로 다른 권한을 붙여 비교하면 두 문제를 구분하기 쉽다.

권한을 회수한 뒤에도 같은 결과가 나오는가

접근 권한은 조직 이동과 프로젝트 종료에 따라 바뀐다. 원본 저장소에서 권한을 바꾼 시각과 검색 색인이 그 변경을 반영한 시각 사이에 차이가 있다면, 그동안 어떤 요청을 허용할지 정해야 한다. 필터 방식의 Microsoft 문서는 문서의 그룹 목록이 바뀔 때 색인의 해당 필드도 갱신하도록 설명한다. 필터를 처음 추가하는 것만으로 이후의 권한 변경까지 처리되지는 않는다. 보안 필터의 권한 갱신

팀이 운영 기준으로 삼을 검사는 작고 구체적일 수 있다. 아래는 제품의 성능 측정 결과가 아니라, 이 흐름을 점검하기 위한 시험 설계 예시다.

답변을 재사용하는 캐시가 있다면 이 검사에는 캐시를 거친 응답도 포함해야 한다. 관련된 문제는 의미 캐시의 적중 경계에서 다뤘다. 새 검색이 올바르게 제한되어도 이전에 만든 답을 누구에게나 반환하면, 사용자별로 근거를 나눈 효과가 사라질 수 있다.

사내 RAG의 품질을 판단할 때는 질문과 답 사이에 요청자의 권한을 놓아야 한다. 누가 읽는지 확인하고, 문서를 쪼개는 과정에서 그 범위를 보존하며, 허용된 자료 안에서 검색 품질을 측정하고, 권한 회수까지 검증하는 것이다. 같은 질문에 항상 같은 답을 주는 것보다 각 사람이 읽을 수 있는 근거로 정확히 답하는 것이 업무 시스템에 필요한 일관성이다.