RAG 종류 총정리 ⑪ — 권한 인식 검색과 보안: 인사팀 문서가 영업 답변에 섞이면

사내 RAG 파일럿을 실제로 중단시키는 질문은 nDCG가 아니다. "인사팀 문서가 영업사원 답변에 섞이면 어떡하죠?"다. 그리고 이건 부가 기능이 아니라 아키텍처 결정이다 — 앞의 열 편에서 다룬 기법 중 상당수가 문서 경계를 지우는 방식으로 동작하기 때문이다.

검색은 관련성으로 줄 세운다, 권한으로 줄 세우지 않는다

벡터 검색은 "질문과 가장 비슷한 것"을 올린다. 다른 부서의 연봉 테이블이 질문과 제일 비슷하면 top-1이 된다. 흔한 구현은 top-k를 뽑은 뒤 권한으로 걸러내는 사후 필터인데, 두 가지가 잘못된다. 첫째, 권한이 희소한 사용자(신입·외부 파트너)에게는 k개가 전부 걸러져 검색되는 게 없다. 둘째, 더 위험하게는 버리기 전에 이미 로그와 LLM 컨텍스트에 들어간 구현이 많다.

사전 필터 vs 필터러블 HNSW — recall과 지연의 삼각형

• 사전 필터(권한 통과 집합만 완전 탐색)는 recall 100%지만 집합이 커지면 선형 스캔이라 지연이 터진다. Qdrant의 full_scan_threshold 기본값이 10,000KB(대략 1만 벡터)인 이유다 — 그 아래에서만 경제적이고, 넘어가면 조용히 그래프 탐색으로 돌아간다.
• 필터러블 HNSW는 권한 값 기반으로 그래프에 추가 간선을 심어 조각남을 막는다. ACORN은 같은 recall에서 처리량이 2~1,000배 차이 난다고 보고했다. 다만 Qdrant 공식 문서도 필터가 아주 강하면 "HNSW 그래프가 무너지기 시작한다"고 인정한다.
• 구현 디테일이 초 단위를 가른다. Azure 공식 문서에 따르면 그룹 수백~수천 개를 Id eq 'a' or Id eq 'b' ...로 나열하면 응답이 "수 초" 느려지지만 search.in()을 쓰면 1초 미만이다. AD 그룹이 수백 개인 조직에서는 아키텍처 결정에 가깝다.
• 권한 필드는 처음부터 잡아라. Qdrant는 payload 인덱스를 데이터 적재 후에 만들면 HNSW 재구축 비용이 든다고 명시한다.

인덱스를 나눌 것인가 — 진짜 비용 계산

"공유 인덱스가 싸다"는 통념은 인프라 요금 이야기이고, 질의 요금은 반대일 수 있다. Pinecone 공식 문서의 계산이 명료하다 — 1GB짜리 테넌트 100개일 때 네임스페이스를 나누면 질의당 1 RU, 단일 100GB 인덱스에 메타데이터 필터를 걸면 100 RU다. 필터를 걸어도 데이터 전체를 스캔하기 때문이고, 그래서 같은 질의에 100배가 나온다.

그렇다고 무작정 쪼개면 벤더가 말린다. Qdrant는 "컬렉션마다 자원 오버헤드가 있어 금방 비싸진다"며 클러스터당 1,000개를 상한으로 두고, Milvus는 DB 64 / 컬렉션 65,536 / 파티션 1,024 / 파티션 키 수백만이라는 층위를 갖는데 파티션 이하에는 RBAC이 없다. 즉 격리가 필요한 단위와 비용이 싼 단위가 어긋난다. 관리형 서비스의 하드 리밋도 미리 봐야 한다 — Vertex AI Search는 문서당 reader 3,000개에 데이터 스토어 생성 후 접근제어 변경 불가(= 전량 재색인), Kendra는 문서당 ACL 200개에 속성 필터 그룹 100개, Bedrock Knowledge Bases는 필터 5개 × 그룹 5개에 중첩 1단계다. "부서 × 직급 × 프로젝트" 조합은 이 숫자에 먼저 부딪힌다.

청크를 합치는 순간 권한이 사라진다

이 시리즈에서 가장 덜 알려진 함정이 여기 있다. ③편의 Contextual Retrieval은 청크에 문서 전체 기반 맥락을 주입하고, RAPTOR는 여러 청크를 재귀적으로 요약하며, ⑥편의 GraphRAG는 여러 문서를 가로질러 커뮤니티 리포트를 쓰고, ⑦편의 에이전트 메모리는 세션을 넘나들며 사실을 축적한다. 넷 다 서로 다른 ACL을 가진 원본을 하나의 새 텍스트로 합친다. 그런데 이 합쳐진 산출물의 권한이 무엇인지에 대한 답이 거의 어디에도 없다 — GraphRAG의 출력 스키마에는 접근제어 필드 자체가 없다.

유일하게 이를 문서화한 벤더가 Azure다. 공식 문서는 "스킬셋이 청킹을 하면 ACL 필드를 index projection으로 옮겨야 하고, 민감도 레이블도 각 청크 행에 투영하지 않으면 청크 단위 참조가 필터링되지 않는다"고 못 박는다. 실무 규칙은 한 줄로 정리된다 — 파생 청크의 권한 = 기여한 원본들의 교집합(가장 제한적인 쪽), 교집합이 공집합이면 그 요약은 만들지 않는다. Contextual Retrieval이 문서 100만 토큰당 $1.02에 검색 실패율을 크게 줄여 준다 해도, 권한 설계가 먼저다.

그리고 검색 경로는 공격받는다

권한을 통과한 문서가 명령이 될 수 있다는 것이 다음 층위의 문제다. 코퍼스 크기는 방어가 아니다:

• PoisonedRAG(USENIX Security 2025): 수백만 건 DB에 표적 질문당 악성 텍스트 5개를 넣어 공격 성공률 90%.
• BadRAG: 패시지 10개로 검색 성공률 98.2%, GPT-4 거부율이 0.01% → 74.6%로.
• AgentPoison: 에이전트 메모리 오염률 0.1% 미만으로 평균 ASR 80% 이상, 정상 성능 저하는 1% 미만 — 대시보드에 안 잡힌다.
• InjecAgent: 도구를 쓰는 에이전트에서 ReAct GPT-4가 약 24% 취약, 유도 프롬프트를 더하면 거의 두 배.

그리고 벡터 DB 자체가 개인정보다. 임베딩 역전 연구는 32토큰 입력의 92%를 정확히 복원했고 임상 노트에서 실명을 뽑아냈다. OWASP의 LLM08:2025가 교차 컨텍스트 유출과 임베딩 역전을 공식 위험으로 등재한 이유이고, "임베딩이니 가명처리됐다"는 논리가 성립하지 않는다는 뜻이다.

마지막으로 방어 전략의 순서. Microsoft 연구팀은 2025년 논문에서 프롬프트 새니타이즈·출력 필터·시스템 격리·학습단 프라이버시가 모두 확률적이라 권한 통제로는 신뢰할 수 없다고 단언하고, "참여한 모든 사용자에게 명시적으로 인가된 콘텐츠만 사용한다"는 결정론적 원칙을 제시했다(Copilot Tuning에 실제 배포). 가드레일은 권한 통제가 아니다.

한국 상황을 덧붙이면, 2026-08-20 개인정보 보호법 개정안이 국회를 통과해 AI 개발 활용 특례가 신설됐고 민감정보·고유식별정보 처리 시 사전 위험평가가 필수, 공포 후 6개월 시행이다. 사내 RAG는 대개 "수집 목적 외 이용"에 해당하므로 이 설계가 곧 아키텍처 요구사항이 된다. 그리고 망분리·CSAP 환경에서는 Azure·Vertex의 네이티브 ACL을 쓸 수 없는데 국내 벤더의 권한 인식 RAG 공개 레퍼런스를 찾지 못했다 — 직접 만들어야 하고 참고할 설계가 없다는 뜻이다. 다음 글은 또 하나의 숨은 비용, 색인의 수명주기다.

— RAG 종류 총정리 시리즈 ⑪ / 다음 글: 색인 수명주기 — 삭제·재임베딩·신선도의 청구서