RAG 권한 필터, 답변보다 먼저 설계해야 하는 보안 기준
사내 RAG를 만들 때 문서 검색 품질보다 먼저 정해야 할 권한 필터, 로그, 예외 승인 기준을 실무 체크리스트로 정리했습니다.
RAG를 붙이면 사내 자료를 빠르게 찾아 답변할 수 있습니다. 그런데 운영 환경에서는 “잘 찾는가”보다 먼저 “보여도 되는 문서만 찾는가”를 정해야 합니다.
문서 권한을 늦게 붙이면 챗봇은 편해지지만, 인사·계약·고객 정보처럼 민감한 자료가 검색 결과에 섞일 수 있습니다. 검색 품질 튜닝보다 권한 필터 설계가 먼저인 이유입니다.
핵심 요약
- RAG 권한은 프롬프트 문구가 아니라 검색 단계의 필터로 먼저 막아야 합니다.
- 사람이 볼 수 없는 문서는 AI도 검색·요약·인용하지 못하게 만드는 것이 기본 원칙입니다.
- 권한 실패를 확인하려면 답변 로그뿐 아니라 검색된 문서 ID, 사용자 역할, 예외 승인 기록을 함께 남겨야 합니다.
- 파일럿 단계부터 부서·직무·프로젝트·고객사 기준의 권한 태그를 정해두면 운영 전환이 훨씬 쉬워집니다.
RAG 보안의 기준은 “AI가 똑똑하게 판단한다”가 아니라 “검색 후보에 올라오는 순간부터 권한 밖 문서는 제외된다”입니다.
1. 권한 필터는 언제 적용해야 할까?
가장 안전한 위치는 벡터 검색 또는 키워드 검색이 문서를 후보로 가져오기 전입니다. 사용자의 부서, 직무, 프로젝트, 고객사, 보안 등급을 검색 조건으로 함께 넣어 권한 밖 문서가 후보 목록에 들어오지 않게 해야 합니다.
답변 생성 후에 “이 내용은 민감하니 빼줘”라고 프롬프트로 부탁하는 방식은 보조 장치일 뿐입니다. 이미 모델 컨텍스트에 문서 내용이 들어갔다면, 요약·추론 과정에서 일부 정보가 섞일 가능성을 배제하기 어렵습니다.
2. 최소한으로 나눠야 할 권한 기준
처음부터 복잡한 IAM 시스템을 만들 필요는 없습니다. 대신 실제 업무에서 문서가 공유되는 경계를 기준으로 태그를 정해야 합니다.
- 조직 기준: 전사, 본부, 팀, TF, 외부 파트너
- 업무 기준: 영업, 운영, CS, 개발, 재무, 인사
- 데이터 등급: 공개 가능, 사내 한정, 제한 문서, 승인 필요
- 고객·프로젝트 기준: 특정 고객사, 특정 계약, 특정 캠페인
- 기간 기준: 현재 유효, 만료, 아카이브, 검토 필요
이 기준은 문서 업로드 화면, Notion/Drive 동기화 파이프라인, 검색 인덱스 메타데이터에 같은 이름으로 들어가야 합니다. 문서 저장소에는 권한이 있는데 검색 인덱스에는 권한이 없으면 RAG는 운영 보안의 빈틈이 됩니다.
3. 사람 승인 루프가 필요한 순간
모든 요청을 막으면 RAG가 일을 못 합니다. 그래서 승인 루프가 필요한 예외 상황을 미리 정해두는 편이 좋습니다.
- 사용자가 권한 밖 문서를 직접 요청한 경우
- 답변에 제한 등급 문서의 인용이 필요한 경우
- 고객 정보, 계약 조건, 인사 정보처럼 민감 정보가 포함된 경우
- AI가 “권한 확인 필요”로 분류했지만 업무상 긴급 조회가 필요한 경우
이때 AI가 바로 답을 주기보다 “권한 확인이 필요한 문서입니다. 승인 요청을 보낼까요?”처럼 업무 흐름을 끊지 않는 방식으로 안내하면 좋습니다. 승인자는 팀장, 문서 소유자, 보안 담당자 중 누가 되는지까지 정해두어야 운영이 멈추지 않습니다.
4. 로그에 남겨야 할 항목
RAG 권한 문제는 사고가 난 뒤에야 확인되는 경우가 많습니다. 그래서 단순히 질문과 답변만 저장하면 부족합니다. 최소한 다음 항목은 추적 가능해야 합니다.
- 사용자 ID 또는 역할 그룹
- 질문 시각과 요청 채널
- 검색 후보로 올라온 문서 ID와 최종 인용 문서 ID
- 적용된 권한 필터 조건
- 차단된 문서 수와 차단 사유
- 예외 승인 요청·승인·반려 기록
로그는 감시 목적만이 아니라 품질 개선에도 필요합니다. 특정 팀의 문서가 계속 차단된다면 권한 설계가 과한지, 문서 태그가 잘못 들어갔는지, 실제로 접근 정책을 바꿔야 하는지 판단할 수 있습니다.
실무 체크리스트
아래 항목 중 3개 이상이 비어 있다면 RAG 파일럿을 바로 전사 공개하기보다 제한된 부서에서 먼저 검증하는 편이 안전합니다.
- 문서마다 소유자와 보안 등급이 들어가 있다.
- 검색 인덱스에 부서·직무·프로젝트 권한 태그가 함께 저장된다.
- 권한 밖 문서는 검색 후보 단계에서 제외된다.
- 예외 조회가 필요한 경우 승인 요청 흐름이 있다.
- 답변 로그와 검색 문서 ID 로그를 함께 남긴다.
- 퇴사자·조직 변경·프로젝트 종료 시 권한 동기화 기준이 있다.
- 민감 문서 테스트 질문으로 정기적인 회귀 테스트를 한다.
도입 순서 제안
- 문서 저장소를 먼저 정리합니다. Drive, Notion, 사내 위키, NAS 등 어디의 문서를 RAG에 넣을지 범위를 줄입니다.
- 권한 태그 표준을 정합니다. 부서명, 프로젝트명, 보안 등급 이름이 사람마다 다르면 검색 필터도 흔들립니다.
- 소규모 부서로 파일럿을 시작합니다. 권한이 단순한 팀에서 검색 품질과 차단 로그를 같이 봅니다.
- 승인 루프와 운영 로그를 붙입니다. “막힘”을 사람이 처리할 수 있어야 업무 자동화로 이어집니다.
- 전사 확장 전에 민감 문서 테스트를 반복합니다. 일부러 권한 밖 질문을 던져 차단되는지 확인합니다.
FAQ
Q. 프롬프트에 “권한 없는 문서는 답하지 마”라고 쓰면 충분한가요?
아니요. 프롬프트는 마지막 방어선에 가깝습니다. 검색 후보에 문서가 들어오기 전, 메타데이터 필터와 접근 정책으로 먼저 제외해야 합니다.
Q. 작은 회사도 권한 필터가 필요할까요?
필요합니다. 규모가 작아도 급여, 계약, 고객 정보, 내부 전략 문서는 존재합니다. 처음에는 전사 공개·팀 한정·승인 필요 정도의 3단계만으로 시작해도 충분합니다.
Q. 이미 만든 RAG에 나중에 권한을 붙여도 되나요?
가능하지만 비용이 커집니다. 문서 재분류, 인덱스 재생성, 로그 구조 변경이 필요할 수 있습니다. 파일럿 단계에서 최소 권한 태그라도 넣어두는 편이 운영 전환에 유리합니다.
HeyRatty가 도와드릴 수 있는 부분
HeyRatty는 사내 AI 비서와 RAG 자동화를 만들 때, 답변 품질뿐 아니라 권한·로그·승인 루프를 함께 설계합니다. 지금 쓰는 Notion, Google Drive, 사내 문서 구조를 기준으로 “어디까지 자동화하고 어디서 사람이 확인할지”를 먼저 정리해드립니다.
RAG 도입을 검토 중이라면, 기술 PoC 전에 문서 권한표와 운영 체크리스트부터 함께 점검해보세요. 작은 파일럿으로 시작해도 운영 기준을 먼저 세우면 확장할 때 흔들림이 줄어듭니다.
참고 및 이미지 출처
- 이미지: Babbage, “Role-based access control”, Wikimedia Commons, CC0 —
참고: NIST SP 800-207 Zero Trust Architecture — https://csrc.nist.gov/publications/detail/sp/800-207/final
참고: OWASP Top 10 for Large Language Model Applications — https://owasp.org/www-project-top-10-for-large-language-model-applications/