사내 문서용 폐쇄형 RAG 구축 가이드: 데이터 보안과 접근 제어

사내 문서를 대상으로 RAG를 구축하면 검색과 질의응답이 훨씬 편리해질 수 있다. 하지만 사내 문서는 공개 웹 문서와 성격이 다르다. 인사 정보, 고객 정보, 계약 내용, 프로젝트 계획처럼 접근 권한이 서로 다른 자료가 한 저장소 안에 뒤섞여 있는 경우가 많기 때문이다. 문서를 임베딩해서 벡터 데이터베이스에 넣는 작업만으로는 안전한 검색 시스템이 되지 않는다. 폐쇄형 RAG에서는 "답을 잘 찾는가"만큼 "권한 없는 사용자에게 문서가 노출되지 않는가"가 중요한 질문이며, 검색 품질만 먼저 만들고 접근 제어를 나중에 붙이려 하면 구조를 크게 다시 손봐야 하는 경우가 많다.

접근 제어는 검색 단계에서부터 설계되어야 한다

왜 답변 생성 직전 확인만으로는 부족한가

RAG는 보통 문서 수집, 전처리, 임베딩, 검색, 답변 생성의 흐름으로 이루어진다. 이 중 접근 제어를 답변 생성 직전 단계에서만 확인하면 이미 늦다. 검색 단계에서 권한 없는 문서 조각이 후보로 올라오는 순간, 모델의 답변이나 로그 어딘가에 민감한 내용이 노출될 가능성이 생긴다. 그래서 문서 조각마다 소유 부서, 접근 그룹, 문서 등급, 원본 위치 같은 메타데이터를 함께 저장하고, 검색을 실행하는 시점에 현재 사용자의 권한 조건으로 후보를 걸러내는 구조가 필요하다.

문서 단위 권한과 청크 단위 권한

문서 하나가 전부 같은 권한을 갖는 경우도 있지만, 하나의 문서 안에 공개 섹션과 제한 섹션이 함께 들어 있는 경우도 드물지 않다. 가능하다면 청크 단위로도 권한 메타데이터를 유지하는 편이 안전하며, 최소한 문서 단위 권한이 청크에 정확히 전달되어야 한다. 문서가 이동하거나 권한이 바뀌었는데 인덱스가 갱신되지 않으면, 원본에서는 이미 막힌 접근이 검색 결과에는 여전히 남아 있는 상황이 발생할 수 있다.

폐쇄형 환경이 의미하는 범위

폐쇄형 RAG는 외부 공개 검색을 쓰지 않는다는 뜻에 그치지 않는다. 데이터가 물리적으로 어디에 저장되는지, 임베딩을 생성하는 요청이 외부 API로 나가는지, 로그가 어떤 환경에 보관되는지, 모델을 호출하는 과정에서 문서 내용이 외부 서비스로 전달되는지까지 포함하는 개념이다. 조직의 보안 요구 수준에 따라 온프레미스로 전부 처리할지, 전용 클라우드를 쓸지, 외부 API 사용 범위를 어디까지 허용할지를 각각 다르게 설계해야 한다.

실제로 적용할 수 있는 방법

문서를 수집하기 전 등급부터 나누기

문서를 모으기 전에 공개 가능, 사내 일반, 부서 제한, 민감 정보 포함처럼 등급을 먼저 정의한다. 모든 문서를 같은 방식으로 처리하면 나중에 접근 제어를 붙이기가 훨씬 번거로워진다. 등급별로 임베딩 저장 위치, 로그 보관 정책, 모델 호출 방식을 다르게 적용할 수 있도록 처음부터 파이프라인을 나누어 설계하는 편이 좋다.

메타데이터 필터를 선택이 아니라 필수 조건으로 두기

검색 쿼리를 실행할 때는 사용자 ID나 그룹 정보를 바탕으로 필터를 함께 적용한다. 유사도 점수가 높은 결과를 먼저 가져온 뒤 나중에 걸러내는 방식보다, 처음부터 권한 조건을 검색 조건 자체에 포함하는 편이 훨씬 안전하다. 벡터 데이터베이스를 선택할 때도 메타데이터 필터의 표현력과 성능을 함께 확인해야 하는 이유가 여기에 있다.

답변에 원문 링크와 근거를 함께 표시하기

답변에는 가능한 한 근거가 된 문서 제목과 링크를 함께 제공한다. 사용자가 실제로 자신의 권한으로 원문을 열 수 있어야 하며, 원문 접근이 막혀 있다면 그 내용은 애초에 답변에도 포함되지 않아야 한다. 근거를 표시해두면 잘못된 답변을 검토하기도 쉽고, 혹시 발생할 수 있는 권한 문제를 조기에 발견하는 데도 도움이 된다.

삭제와 권한 변경을 인덱스에 반영하기

문서가 삭제되거나 권한이 바뀌었는데 벡터 인덱스에는 예전 청크가 그대로 남아 있으면 문제가 된다. 수집 파이프라인에는 삭제 반영, 재색인, 권한 메타데이터 갱신 절차가 반드시 포함되어야 한다. 특히 퇴사자 계정, 종료된 프로젝트 문서, 만료된 고객 계약 문서는 갱신이 누락되지 않도록 별도로 점검하는 편이 안전하다.

주의할 점

임베딩에는 원문의 의미가 압축되어 담기기 때문에, 임베딩 저장소 역시 민감 데이터 저장소와 동일하게 취급해야 한다. "원문 그대로가 아니니 상대적으로 안전하다"고 판단하는 것은 위험한 가정이다. 접근 권한, 암호화, 백업, 삭제 정책을 원문 저장소와 비슷한 수준으로 관리하는 편이 바람직하다.

또 하나 놓치기 쉬운 부분은 답변 로그다. 모델이 생성한 답변에는 민감한 문서 내용이 그대로 포함될 수 있으므로, 품질 개선을 목적으로 대화 로그를 저장하더라도 보관 기간과 접근 권한을 제한해야 한다. 운영자의 디버깅 편의를 이유로 모든 답변을 평문으로 오래 보관하면, 애써 구축한 폐쇄형 RAG의 보안 의미가 크게 약해질 수 있다.

정리

사내 문서용 폐쇄형 RAG는 검색 품질과 보안을 처음부터 함께 설계해야 하는 과제다. 문서와 청크에 권한 메타데이터를 붙이고, 검색 시점에 사용자 권한으로 결과를 필터링하며, 원문의 삭제와 권한 변경이 인덱스에도 곧바로 반영되도록 만들어야 한다. 임베딩 저장소와 답변 로그까지 민감 데이터로 간주하고 관리한다면, 운영을 시작한 뒤에도 조직 내부에서 신뢰를 유지하기가 한결 수월해진다.