대부분의 기업용 RAG 시스템을 위험하게 만드는 액세스 제어(Access Control)의 공백

기업용 RAG — 실무자의 구축 로그 | 포스트 1/6

정확도 벤치마크(Accuracy Benchmarks)에서는 나타나지 않는 검색 실패 모드가 있습니다. 바로 올바른 문서를 찾아내지만, 이를 잘못된 사람에게 반환하는 시스템입니다. 대부분의 RAG 평가 프레임워크는 검색된 청크(Chunks)가 질문과 관련이 있는지를 측정합니다. 하지만 질문자가 누구인지에 따라 해당 청크가 검색되어야만 했는지를 측정하는 프레임워크는 거의 없습니다. 인사 정책, 엔지니어링 런북(Runbooks), 재무 예측, 보안 사고 보고서가 동일한 지식 베이스(Knowledge Base)에 담겨 있는 기업 환경에서, 이러한 공백은 사소한 예외 사례가 아닙니다. 이는 근본적인 설계 결함입니다. 저는 액세스 제어(Access Control)를 답변 생성 후에 적용하는 사후 고려 사항이 아니라, 일급 검색 요구 사항(First-class retrieval requirement)으로 취급하기 위해 특별히 'Enterprise RAG'를 구축했습니다.

사후 검색 필터링(Post-retrieval filtering)의 문제점

RAG 시스템에서 문서 액세스 제어를 처리하는 순진한 접근 방식은 '먼저 검색하고 나중에 필터링하는 것'입니다. 즉, 모든 후보 청크의 관련성 점수를 매긴 다음, 답변을 생성하기 전에 사용자가 볼 권한이 없는 청크를 제거하는 방식입니다. 이 접근 방식은 두 가지 측면에서 실패합니다.

첫째, 답변으로 정보가 유출됩니다. 제한된 청크 5개를 포함하여 20개의 청크가 주어진 생성 모델(Generative model)은, 응답이 반환되기 전 인용 목록에서 제한된 청크가 제거되더라도 20개 전체의 정보를 합성할 수 있습니다. 모델은 당신이 보여주지 않기로 결정하기 전에 이미 재무 예측 내용을 읽어버린 상태입니다.

둘째, 잘못된 안도감을 제공합니다. 인용 필터링(Citation filtering)은 파이프라인에서 중요한 부분에 액세스 제어를 강제하지 않으면서도, 마치 액세스 제어가 이루어지고 있는 듯한 겉모습만 제공합니다. 응답을 감사(Audit)하면 제한된 인용이 나타나지 않을 수 있지만, 답변의 내용은 그 정보를 반영하고 있을 수 있습니다.

올바른 아키텍처는 검색 점수 산정(Retrieval scoring) 이전에 액세스 제어를 적용하는 것입니다. 권한이 없는 청크는 후보 세트에서 완전히 제외됩니다. 이들은 결코 순위가 매겨지지 않으며, 생성기(Generator)로 전달되지도 않고, 인용되지도 않습니다.

일반적인 내부 지식 베이스(Internal Knowledge Base)에서 조용히 유출되는 것

네 가지 카테고리의 문서를 보유한 단일 내부 지식 베이스를 운영하는 기업을 가정해 봅시다.

• 인사 및 운영 (HR and operations) — 모든 직원에게 공개
• 엔지니어링 런북 (Engineering runbooks) — 엔지니어 및 그 이상의 직급에게 공개
• 재무 예측 및 차이 보고서 (Finance forecasts and variance reports) — 재무 팀 및 경영진에게 공개
• 보안 사고 보고서 (Security incident reports) — 엔지니어 및 보안 팀에게 공개

사후 필터링 (Post-retrieval filtering) 방식의 시스템을 사용하는 상황에서, 일반 직원이 "3분기 매출 차이는 얼마였습니까?"와 같은 질문을 던졌을 때, 설령 재무 문서가 인용 목록(Citation list)에 나타나지 않더라도 재무 데이터를 반영한 답변이 반환될 수 있습니다. 시스템이 해당 데이터를 검색(Retrieve)하고, 점수를 매기고, 생성기(Generator)로 전달한 뒤, 인용 목록에서만 조용히 제거했기 때문입니다. 이는 가상의 시나리오가 아닙니다. 검색(Retrieval)과 액세스 제어(Access Control)가 분리된 파이프라인 단계로 구성된 모든 시스템에서 나타나는 예측 가능한 동작입니다.

대부분의 팀이 수행하지 않는 검증 테스트

무언가를 구축하기 전, 저는 시스템이 통과해야 할 평가 테스트를 정의했습니다. 바로 "서로 다른 두 가지 역할(Role)로 동일한 질문을 던지는 것"입니다. 답변의 내용과 인용 목록은 역할에 따라 달라져야 합니다. 만약 일반 직원과 재무 매니저가 "3분기 예측 차이는 무엇입니까?"라고 질문했을 때, 인용 목록의 차이 여부와 관계없이 동일한 정보를 포함한 답변을 받는다면, 액세스 제어(Access Control)가 작동하지 않는 것입니다.

엔터프라이즈 RAG(Enterprise RAG)의 평가 세트에는 테스트 케이스별로 명시적인 금지 문서 ID(Forbidden document IDs)가 포함되어 있습니다. restricted_leak_count 지표는 최소 하나 이상의 금지된 문서를 반환한 평가 케이스가 몇 개인지 측정합니다. 올바른 사전 검색 액세스 제어(Pre-retrieval access control)가 적용된 시스템이라면 이 수치는 0이어야 합니다.

위의 스크린샷은 이 테스트를 통과하는 모습을 보여줍니다. 일반 직원 역할은 공개적으로 접근 가능한 정책 문서에 근거한 답변을 받는 반면, 재무 역할은 제한된 재무 문서를 추가로 인용하는 답변을 받습니다. 질문은 동일하지만, 검색 세트(Retrieval sets)가 다릅니다. 유출은 없습니다.

이것이 운영 측면에서 변화시키는 점
운영상의 함의는 기업용 지식 베이스(Knowledge base)에 RAG를 배포할 때, 소비자용 또는 내부 도구용 RAG와는 다른 검증 표준이 필요하다는 것입니다. 검색 관련성(Retrieval relevance)만으로는 충분하지 않습니다. 다음 사항들이 필요합니다:

• 문서 액세스 권한을 사용자 신원(User identity)에 매핑하는 역할 모델 (Role model)
• 점수 산정(Scoring) 전에 강제되는 검색 전 필터링 (Pre-retrieval filtering)
• 기대되는 문서뿐만 아니라 역할별 금지된 문서를 포함하는 평가 세트 (Evaluation set)
• 통과율(Pass rate) 및 인용 범위(Citation coverage)와 함께 추적되는 제한적 유출 횟수(restricted_leak_count) 지표

이 네 가지가 모두 없다면, 시스템이 제한된 콘텐츠를 유출하고 있는지 알 수 없습니다. 여러분은 시스템이 관련 콘텐츠를 검색하고 있는지만 알 수 있을 뿐이며, 이는 기업 보안 맥락에서는 다르고 덜 중요한 문제입니다.

현재의 한계
현재 구현은 토큰 코사인 유사도(Token cosine similarity) 점수 산정을 사용하는 어휘 검색(Lexical retrieval)을 사용합니다. 의미론적 검색(Semantic retrieval) 또는 하이브리드 검색(Hybrid retrieval)은 계획된 확장 기능입니다. 어휘 검색은 검증 워크플로에 충분히 정확하지만, 프로덕션 환경의 의미론적 검색 품질에는 미치지 못합니다. 역할 메타데이터(Role metadata)는 문서의 프런트 매터(Front matter)에 포함되어 있습니다. 프로덕션 배포 시에는 역할 컨텍스트(Role context)를 요청 본문(Request body) 파라미터가 아닌 Entra ID 또는 OIDC ID 제공자(Identity provider)로부터 도출해야 합니다. 참조 문서는 합성 데이터(Synthetic)입니다. 평가 세트는 프로덕션 규모의 골든 세트(Golden set)가 아니라, 반복 가능한 로컬 검증을 위해 조정되었습니다. 멀티 테넌트 격리(Multi-tenant isolation)는 문서화된 프로덕션 고려 사항입니다. 현재 구현은 단일 조직(Single-organization)용입니다.

다음 엔지니어링 단계
시드된 데모 데이터에 대해 POST /eval/run을 실행하고 restricted_leak_count를 확인하십시오. 이 값이 0이라면 액세스 제어가 강제되고 있는 것입니다. 그런 다음 필터링 전에 점수를 적용하도록 검색 파이프라인(Retrieval pipeline)을 수정하고 평가 출력에서 어떤 변화가 있는지 관찰하십시오.

여러분에게 던지는 질문 하나
만약 오늘 인덱스에 제한된 재무 문서가 있는 상태에서 내부 지식 베이스에 질문을 던진다면, 여러분의 평가 세트는 해당 문서의 내용이 답변에 영향을 미쳤는지 감지할 수 있습니까 — 아니면 단지 인용 목록(Citation list)에 나타났는지 여부만 감지할 수 있습니까?

다음 포스트: 검색 점수 산정(Retrieval scoring)보다 액세스 제어(Access control)를 우선시하는 아키텍처, 그리고 왜 작업 순서(Order of operations)가 설계의 전부인가.