문서 QA는 왜 파일명만 봐서는 안 되나 — 권한과 검색 입도의 정렬
← 전체 목차 · 이전: 표를 Markdown으로 잘라 벡터DB에 넣으면 되는 거 아닌가 · 다음: BM25와 벡터 검색은 도대체 무엇이 다른가
"파일명은 믿을 수 없다"만 답하면 너무 빈약하다. 그것은 파일명을 부정했을 뿐 기업 권한 모델이 실제로 어떻게 생겼는지도, 대체 방안도 말하지 않았다.
기업 문서 권한은 다섯 차원이 함께 결정한다.
| # | 차원 | 의미 |
|---|
| 1 | 디렉터리 구조 | 파일이 속한 디렉터리/공간 자체의 접근 제약 |
| 2 | 사용자 역할 | 요청자가 누구이고 어떤 역할에 속하는가 |
| 3 | 문서 밀급 | 공개 / 내부 / 기밀 등의 등급 |
| 4 | 부서 관계 | 부서 간 가시성 |
| 5 | 공유 범위 | 명시적으로 누구에게 공유되었는가 |
파일명은 이 다섯 항목 중 어디에도 들어 있지 않다 — 이것이 "파일명만으로는 턱없이 부족하다"의 구조화된 이유다.
동명 파일, 다른 권한
| 버전 | 파일명 | 권한 표기 |
|---|
| 공개판 | 프로젝트 계획.pdf | 전원 열람 가능 |
| 경영진 내부판 | 프로젝트 계획.pdf | 임원 한정 |
두 파일의 이름이 완전히 같은데(확장자까지) 접근 권한은 정반대다. 파일명이나 키워드 매칭만으로 검색하면 봐서는 안 될 내용이 그대로 검색되어 나오기 쉽다.
RAG의 추가 난제: 권한 단층
RAG 시나리오는 일반 문서 QA보다 한 겹의 리스크가 더 있다. 원본 문서 → 여러 chunk로 분할 → 벡터 DB 저장이라는 링크 때문이다.
파일 층: 권한 통제 있음 ← 정상
↓
Chunk 층: 권한 메타데이터 없음 ← 위험
결과: 현재 사용자 → Chunk 검색 → 이 사용자에게 보여줘도 되는가? 시스템이 답하지 못한다.
결론: 권한 메타데이터는 chunk와 함께 인덱스에 들어가야 하며, 원본 파일 층에서만 권한을 통제하는 것으로는 부족하다.
표준 안전 링크 vs 고위험 안티패턴
| 표준 안전 링크(정답) | 고위험 안티패턴(오답) |
|---|
| 1단계 | 신원 인증 — 사용자 권한 범위 확정 | 전량 자료 리콜 — 월권 데이터 포함 |
| 2단계 | 지식 검색 | 모델이 스스로 판단 |
| 결과 | 모델은 그 사용자가 볼 권한이 있는 내용만 본다 | 월권 내용이 이미 컨텍스트에 들어갔다 |
등가 표현: "먼저 인증하고 검색하거나, 검색 단계에서 권한 필터를 함께 건다" — 인증은 전방 게이트일 수도 있고 검색 시의 metadata filter로 내려앉을 수도 있다. 두 구현 모두 가능하며, 관건은 모델 뒤로 미루면 안 된다는 것이다.
권한 통제의 철칙: 모델 ≠ 권한 시스템
- 모델 ≠ 권한 시스템 — 대규모 모델에는 결정론적 경계가 없다.
- 기억과 재진술 리스크 — 나와서는 안 될 정보를 기억하거나 옮겨 말할 수 있다.
그러므로 권한은 결정론적 시스템이 통제해야지, 확률적 생성 모델이 "알아서 자각하기"에 맡겨서는 안 된다.
표준 답안
대규모 모델 문서 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 층은 무방비
✗ 파일명 / 키워드 매칭으로 권한 판단을 근사
실전 사고: 화이트리스트를 다 걸었는데도 전사 예산이 새어 나갔다
라벨링과 전방 필터를 전부 갖췄다고 안심할 수 없다는 것을 보여주는 실제 사고 패턴이 있다. 마케팅팀 직원이 "이번 분기 전 채널 마케팅 총예산이 얼마인가"라고 물었을 뿐인데, 재무 내부 미공개 예산 명세가 각 부서 인력 비용·프로젝트 기밀 예산까지 포함해 그대로 복술된 사고다.
후속 조사 결과: 민감 문서에는 전부 권한 라벨이 붙어 있었다
│
▼
그런데 검색 링크는 「의미 유사도 매칭」만 수행했고 「권한 전치 검증」이 빠져 있었다
│
▼
고밀급 문서가 그대로 리콜됨
│
▼
모델이 근거로 받은 내용을 여과 없이 복술
즉 라벨은 존재했지만 리콜 결정에 한 번도 참여하지 않았다. "화이트리스트 전치 필터"라는 원칙(위 구현 절차 4~5단계)은 맞았지만, 실제 배포에서는 이 원칙이 코드로 강제되지 않은 채 문서화만 되어 있었다는 뜻이다.
강화된 3층 방어 — 입구·출구·아키텍처
| 층 | 구성 | 핵심 동작 |
|---|
| 1층 · 업무 분급 | 공개 문서 vs 분급 보안 문서 | 보안 문서는 chunk 단위로 부서·직위·직급 3중 권한 라벨을 결합 바인딩, 권한 영역을 절대 넘나들지 않음 |
| 2층 · 검색단 + 전체 링크 검증 | 화이트리스트 전치 + 생성 후 이차 검증 + 감사 로그 | ① 신원별 문서 화이트리스트를 먼저 산출한 뒤 그 범위 안에서만 의미 리콜 ② 출력 내용에 대해 미승인 재무·급여·기술 민감 정보를 탐지해 직접 차단하고 경고를 발동 ③ 매 검색·생성마다 사용자 신원·리콜 문서·출력 내용을 기록 |
| 3층 · 아키텍처 | 물리 격리 + 동적 동기화 + 강권한 모드 | 밀급·권한 영역별로 벡터 DB를 분리 저장해 필터 로직이 잘못돼도 월권이 물리적으로 불가능하게 만들고, 통합 인증 시스템과 연동해 직위·직급 변동을 실시간 반영하며, 재무보고 기간·기밀 유지 기간 같은 민감 시점에는 전체 검증 등급을 올리고 고민감 질의에 사람 복심을 추가하는 스위치를 둔다 |
이 중 생성 후 이차 검증이 이 문서 원래의 "권한 전치" 원칙에 빠져 있던 조각이다. 전치 필터가 문서·chunk 단위로 작동하는 반면, 이차 검증은 최종 출력 내용을 대상으로 하기 때문에 여러 개의 저밀급 chunk가 조합되어 하나의 고밀급 결론을 만들어내는 경우까지 잡아낼 수 있다.
핵심 통찰
- "믿을 수 없다"는 답이 아니고 "대체 방안"이 답이다 — 어떤 방식을 부정하는 것만으로는 절반짜리 답이고, 올바른 권한 모델이 어떻게 생겼는지와 올바른 링크의 배열을 말해야 완전한 답이다. "왜 X를 하면 안 되나" 류 문제의 범용 답변 구조: 부정 → 실제 제약 차원 제시 → 올바른 링크 제시 → 철칙 제시.
- 권한의 입도는 검색의 입도와 정렬되어야 한다 — 이 문서에서 가장 이식성 높은 한 줄이다. RAG 검색의 최소 단위가 chunk라면 권한의 최소 단위도 chunk여야 한다. "통제 입도가 접근 입도보다 거친" 모든 시스템에는 구조적 월권 리스크가 있으며, 이 법칙은 RAG만이 아니라 캐시, 로그, 데이터 레이크 파티션에도 적용된다.
- 분할(chunking)은 한 번의 은밀한 권한 상실이다 — 문서가 잘게 부서질 때 파일 층의 ACL은 chunk에 자동 상속되지 않는다. 이것이 권한 단층이다. ETL/인덱스 파이프라인을 만들 때 "원본 객체를 분해하는" 모든 단계에서 "원본의 보안 속성이 따라왔는가"를 한 번 물어야 한다.
- 확률 시스템은 결정론적 책임을 떠맡을 수 없다 — 대규모 모델에는 결정론적 경계가 없고 "기억과 전술" 두 유출 경로가 있다. 보안·과금·감사처럼 결정론이 요구되는 책임은 반드시 모델 바깥의 결정론적 시스템에 두어야 한다.
- 인증은 내용이 컨텍스트에 들어가기 전에 완료되어야 한다 — 월권 내용이 일단 prompt에 들어가면 이미 유출된 것이다. 이후에 아무리 모델에게 "말하지 마"라고 해도 우회 가능한 소프트 제약일 뿐이다. 보안 경계의 위치가 보안 규칙의 강도보다 중요하다.
- 인증의 두 가지 등가 구현을 모두 말할 수 있어야 한다 — ①검색 전에 사용자의 권한 범위를 먼저 계산(전방 게이트) ②검색 시 권한 조건을 metadata filter로 거는 것(쿼리로 하강). 둘 다 "모델이 보기 전에 완료"를 만족하며, 둘을 함께 말할 수 있으면 구현 경험이 있어 보인다.
- 동명·다른 밀급은 실재하는 고빈도 시나리오다 — "프로젝트 계획.pdf 공개판 / 경영진 내부판"은 지어낸 극단 사례가 아니라 보고 체계가 있는 모든 회사에서 나타나는 상태다. 구체적 반례로 추상적 리스크를 설명하는 편이 원리를 말하는 것보다 설득력이 있다.
- 다중 문서 조합은 chunk 단위 권한만으로 막을 수 없는 새로운 유출 벡터다 — 리콜된 chunk 하나하나는 저밀급이라도, 여러 개를 동시에 조합해 읽으면 고밀급 결론(예: 여러 부서 데이터를 이어붙인 "전사 예산")이 만들어질 수 있다. 그래서 이차 방어는 개별 chunk가 아니라 최종 출력 내용을 대상으로 해야 하며, 이것이 전치 필터만으로는 채워지지 않는 구멍이다.
엔지니어링 실전 Tips
- 권한 필드가 벡터 DB에서 필터 조건으로 쓰일 수 있어야 한다: 선택 시 metadata filtering을 지원하는지(그리고 조회 시 푸시다운되는 사전 필터인지) 확인할 것. 먼저 top-k를 뽑고 나서 거르면 리콜 수가 붕괴한다.
- "필터링 후 top-k 부족" 함정에 주의할 것: 권한 필터링 후 사용 가능한 chunk가 줄어드는데 여전히 고정 k를 쓰면 저권한 사용자의 답변 품질이 뚜렷이 떨어진다. 필터링 후 후보 집합에 맞춰 k를 동적으로 조정하거나 2차 확장 리콜을 할 것.
- 권한 변경 시 인덱스를 역방향으로 갱신할 수 있어야 한다: 문서 밀급 조정, 직원 전보·퇴사 시 벡터 DB의 chunk metadata가 동기화되어야 하며, 그렇지 않으면 인덱스에 옛 권한 스냅샷이 남는다(문서 24 참조).
- prompt에 "기밀을 유출하지 마"를 쓰는 것으로 될 것이라 기대하지 말 것: 소프트 제약이며, 모델에는 "기억하거나 옮겨 말하는" 리스크가 있다. 하드 경계는 검색 층에서만 만들 수 있다.
- 보통은 두 층 모두 하는 것이 실제 답이다: 문서 층 ACL은 거친 입도의 빠른 절삭과 관리 화면 표시에, chunk 층 메타데이터는 검색 시의 정밀 필터링에 쓰인다. 책임이 다르므로 양자택일이 아니다.
- 로그와 감사를 한마디 보태면 가점: 누가 언제 어떤 chunk를 검색했는지는 기업급 지식베이스의 컴플라이언스 필수 항목이다.
- 생성 후 이차 검증을 전치 필터의 대체가 아니라 보완으로 배치할 것: 전치 필터는 "이 사용자가 이 chunk를 볼 수 있는가"를 판정하고, 이차 검증은 "허용된 chunk들을 조합한 출력이 그래도 민감한가"를 판정한다 — 둘은 서로 다른 질문에 답한다.
- 밀급별 벡터 DB 물리 분리는 필터 로직의 버그에 대한 최후 안전판이다: 성능이 아니라 "필터 조건을 잘못 짜도 월권이 물리적으로 불가능하다"는 점이 가치다.
- 강권한 모드 스위치는 사고가 터지기 전에 미리 만들어 둘 것: 재무보고 기간·기밀 유지 기간처럼 리스크 가중치가 높아지는 구간을 미리 정의해 두고, 그 구간에만 검증 등급을 올리고 사람 복심을 추가하는 편이 상시 최고 강도로 운영하는 것보다 가용성을 지킨다.
- 더 파고들 방향: chunk 단위 권한의 저장 비용과 인덱스 팽창 통제, 멀티테넌트 RAG의 격리 전략(공유 인덱스 + 테넌트 filter vs 테넌트별 독립 인덱스), 권한 변경의 인덱스 일관성(증분 갱신 vs 전량 재구축), Agent 시나리오에서 도구가 파일을 읽을 때의 사용자 신원 투과 전달.