#문서 QA는 왜 파일명만 봐서는 안 되나 — 권한과 검색 입도의 정렬

← 전체 목차 · 이전: PDF 문서는 어떻게 처리하는가 · 다음: BM25와 벡터 검색은 도대체 무엇이 다른가

"파일명은 믿을 수 없다"만 답하면 너무 빈약하다. 그것은 파일명을 부정했을 뿐 기업 권한 모델이 실제로 어떻게 생겼는지도, 대체 방안도 말하지 않았다.

기업 문서 권한은 다섯 차원이 함께 결정한다.

파일명은 이 다섯 항목 중 어디에도 들어 있지 않다 — 이것이 "파일명만으로는 턱없이 부족하다"의 구조화된 이유다.

#동명 파일, 다른 권한

두 파일의 이름이 완전히 같은데(확장자까지) 접근 권한은 정반대다. 파일명이나 키워드 매칭만으로 검색하면 봐서는 안 될 내용이 그대로 검색되어 나오기 쉽다.

#RAG의 추가 난제: 권한 단층

RAG 시나리오는 일반 문서 QA보다 한 겹의 리스크가 더 있다. 원본 문서 → 여러 chunk로 분할 → 벡터 DB 저장이라는 링크 때문이다.

파일 층:   권한 통제 있음      ← 정상
        ↓
Chunk 층:  권한 메타데이터 없음 ← 위험

결과: 현재 사용자 → Chunk 검색 → 이 사용자에게 보여줘도 되는가? 시스템이 답하지 못한다.

결론: 권한 메타데이터는 chunk와 함께 인덱스에 들어가야 하며, 원본 파일 층에서만 권한을 통제하는 것으로는 부족하다.

#표준 안전 링크 vs 고위험 안티패턴

등가 표현: "먼저 인증하고 검색하거나, 검색 단계에서 권한 필터를 함께 건다" — 인증은 전방 게이트일 수도 있고 검색 시의 metadata filter로 내려앉을 수도 있다. 두 구현 모두 가능하며, 관건은 모델 뒤로 미루면 안 된다는 것이다.

#권한 통제의 철칙: 모델 ≠ 권한 시스템

1. 모델 ≠ 권한 시스템 — 대규모 모델에는 결정론적 경계가 없다.
2. 기억과 재진술 리스크 — 나와서는 안 될 정보를 기억하거나 옮겨 말할 수 있다.

그러므로 권한은 결정론적 시스템이 통제해야지, 확률적 생성 모델이 "알아서 자각하기"에 맡겨서는 안 된다.

#표준 답안

대규모 모델 문서 QA는 파일명만으로 권한을 판단할 수 없고, 사용자 신원, 문서 밀급, 공유 범위, chunk 메타데이터를 함께 검색 필터링에 넣어야 한다. 권한 통제는 모델이 내용을 보기 전에 완료되어야 한다.

#구현 절차

【적재 단계】
1. 문서 적재 시 권한 메타데이터를 먼저 수집:
   owner / dept / 밀급(level) / 공유 명단(shared_with) / 디렉터리 경로(path)
2. chunk로 분할할 때 위 권한 필드를 각 chunk의 metadata로 【건별 복사】
   —— 핵심 동작, 「권한 단층」 방지
3. chunk를 권한 metadata와 함께 벡터 DB 인덱스에 기록

【조회 단계】
4. 사용자 질문 수신 → 먼저 신원 인증, 해당 사용자의 권한 범위 해석
   (역할, 소속 부서, 열람 가능 밀급 상한, 공유받은 문서 집합)
5. 검색 시 권한 조건을 metadata filter로 벡터 DB에 푸시다운
   (또는 가시 문서/chunk 화이트리스트를 먼저 계산한 뒤 검색 범위를 한정)
6. 필터링된 chunk만 prompt에 조립
7. 대규모 모델 생성

【절대 금지】
✗ 전량 리콜 → 모델에 투입 → 모델이 답해도 되는지 스스로 판단
✗ 파일 층에서만 ACL, chunk 층은 무방비
✗ 파일명 / 키워드 매칭으로 권한 판단을 근사

#핵심 통찰

1. "믿을 수 없다"는 답이 아니고 "대체 방안"이 답이다 — 어떤 방식을 부정하는 것만으로는 절반짜리 답이고, 올바른 권한 모델이 어떻게 생겼는지와 올바른 링크의 배열을 말해야 완전한 답이다. "왜 X를 하면 안 되나" 류 문제의 범용 답변 구조: 부정 → 실제 제약 차원 제시 → 올바른 링크 제시 → 철칙 제시.
2. 권한의 입도는 검색의 입도와 정렬되어야 한다 — 이 문서에서 가장 이식성 높은 한 줄이다. RAG 검색의 최소 단위가 chunk라면 권한의 최소 단위도 chunk여야 한다. "통제 입도가 접근 입도보다 거친" 모든 시스템에는 구조적 월권 리스크가 있으며, 이 법칙은 RAG만이 아니라 캐시, 로그, 데이터 레이크 파티션에도 적용된다.
3. 분할(chunking)은 한 번의 은밀한 권한 상실이다 — 문서가 잘게 부서질 때 파일 층의 ACL은 chunk에 자동 상속되지 않는다. 이것이 권한 단층이다. ETL/인덱스 파이프라인을 만들 때 "원본 객체를 분해하는" 모든 단계에서 "원본의 보안 속성이 따라왔는가"를 한 번 물어야 한다.
4. 확률 시스템은 결정론적 책임을 떠맡을 수 없다 — 대규모 모델에는 결정론적 경계가 없고 "기억과 전술" 두 유출 경로가 있다. 보안·과금·감사처럼 결정론이 요구되는 책임은 반드시 모델 바깥의 결정론적 시스템에 두어야 한다.
5. 인증은 내용이 컨텍스트에 들어가기 전에 완료되어야 한다 — 월권 내용이 일단 prompt에 들어가면 이미 유출된 것이다. 이후에 아무리 모델에게 "말하지 마"라고 해도 우회 가능한 소프트 제약일 뿐이다. 보안 경계의 위치가 보안 규칙의 강도보다 중요하다.
6. 인증의 두 가지 등가 구현을 모두 말할 수 있어야 한다 — ①검색 전에 사용자의 권한 범위를 먼저 계산(전방 게이트) ②검색 시 권한 조건을 metadata filter로 거는 것(쿼리로 하강). 둘 다 "모델이 보기 전에 완료"를 만족하며, 둘을 함께 말할 수 있으면 구현 경험이 있어 보인다.
7. 동명·다른 밀급은 실재하는 고빈도 시나리오다 — "프로젝트 계획.pdf 공개판 / 경영진 내부판"은 지어낸 극단 사례가 아니라 보고 체계가 있는 모든 회사에서 나타나는 상태다. 구체적 반례로 추상적 리스크를 설명하는 편이 원리를 말하는 것보다 설득력이 있다.

#엔지니어링 실전 Tips

• 권한 필드가 벡터 DB에서 필터 조건으로 쓰일 수 있어야 한다: 선택 시 metadata filtering을 지원하는지(그리고 조회 시 푸시다운되는 사전 필터인지) 확인할 것. 먼저 top-k를 뽑고 나서 거르면 리콜 수가 붕괴한다.
• "필터링 후 top-k 부족" 함정에 주의할 것: 권한 필터링 후 사용 가능한 chunk가 줄어드는데 여전히 고정 k를 쓰면 저권한 사용자의 답변 품질이 뚜렷이 떨어진다. 필터링 후 후보 집합에 맞춰 k를 동적으로 조정하거나 2차 확장 리콜을 할 것.
• 권한 변경 시 인덱스를 역방향으로 갱신할 수 있어야 한다: 문서 밀급 조정, 직원 전보·퇴사 시 벡터 DB의 chunk metadata가 동기화되어야 하며, 그렇지 않으면 인덱스에 옛 권한 스냅샷이 남는다(문서 14 참조).
• prompt에 "기밀을 유출하지 마"를 쓰는 것으로 될 것이라 기대하지 말 것: 소프트 제약이며, 모델에는 "기억하거나 옮겨 말하는" 리스크가 있다. 하드 경계는 검색 층에서만 만들 수 있다.
• 보통은 두 층 모두 하는 것이 실제 답이다: 문서 층 ACL은 거친 입도의 빠른 절삭과 관리 화면 표시에, chunk 층 메타데이터는 검색 시의 정밀 필터링에 쓰인다. 책임이 다르므로 양자택일이 아니다.
• 로그와 감사를 한마디 보태면 가점: 누가 언제 어떤 chunk를 검색했는지는 기업급 지식베이스의 컴플라이언스 필수 항목이다.
• 더 파고들 방향: chunk 단위 권한의 저장 비용과 인덱스 팽창 통제, 멀티테넌트 RAG의 격리 전략(공유 인덱스 + 테넌트 filter vs 테넌트별 독립 인덱스), 권한 변경의 인덱스 일관성(증분 갱신 vs 전량 재구축), Agent 시나리오에서 도구가 파일을 읽을 때의 사용자 신원 투과 전달.