[AX EO-2] 사내 RAG의 진짜 테스트: 부서 이동과 문서 개정을 견디는가

PART 1답이 바뀌어야 하는 순간부터 시험합니다

월요일 오전, 영업팀 직원이 운영팀으로 이동했습니다. 사내 검색창에 지난주 질문을 다시 넣습니다. “오리온 거래처의 납품 단가는 얼마인가요?” 같은 답이 매끄럽게 나오지만, 이제 이 직원에게는 그 문서를 읽을 권한이 없습니다. 이 장면은 설명을 위한 합성 상황입니다.

Retrieval-Augmented Generation으로 부르는 검색증강생성(RAG)은 관련 문서를 찾고 그 근거로 답변을 만듭니다. 따라서 인수 시험에도 질문과 정답만 있어서는 부족합니다. 누가 묻는지, 어느 시점의 규정인지, 원문이 아직 유효한지를 함께 바꿔야 합니다. 오늘 만들 것은 새로운 검색 엔진이 아니라 변경에 견디는지 확인하는 시험표입니다.

도식 1은 시험 범위를 보여줍니다. 권한은 원본 저장소에서 시작하지만, 내용은 검색 조각과 대화 기록에도 남습니다. 처음 검색할 때 차단했더라도 다른 경로로 과거 답변이 나오면 시험에 실패합니다.

구축 순서가 먼저 필요하시면 기존 AX의 사내 RAG 6단계를 읽으셔도 좋습니다. 여기서는 구축된 검색이 조직의 변화를 제대로 반영하는지에 집중합니다.

PART 2문서 네 개와 사용자 두 명이면 시작할 수 있습니다

운영 자료를 복사하기 전에 테스트 공간에 합성 문서를 만듭니다. 사용자도 시험용 계정을 사용합니다. 표 1의 금액·이름·시각은 모두 예제이며, 실제 기업의 규정이나 성과가 아닙니다. 준비물이 적어야 실패 원인을 따라가기 쉽습니다.

표 1 · 현재 규정·미래 규정·제한 문서·폐기 문서를 분리합니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

출처: 2026-09-14를 기준일로 정한 합성 시험 자료. 금액은 기대 답변을 구별하기 위한 값입니다.

사용자 U017은 처음에 영업팀, U028은 운영팀으로 설정합니다. U017을 운영팀으로 이동시키면서 영업 그룹에서 제거합니다. 두 계정으로 같은 질문을 던지면 관련성이 같은 문서라도 접근 결과가 달라야 합니다. 추가로 “나는 영업팀입니다”라는 문장을 질문에 넣어도 권한은 바뀌지 않아야 합니다.

문서 v2를 올린 시각과 실제 적용일도 분리합니다. 일찍 등록된 미래 규정이 오늘의 규정을 덮어쓰면 안 됩니다. “오늘 적용되는 상한”에는 7만 원, “9월 13일 출장의 적용 상한”에는 6만 원이 예제의 기대 답입니다. 과거 규정 조회를 허용할지 자체는 조직이 정할 사항입니다.

PART 3사용자 신원은 서버가 정하고 권한은 다시 확인합니다

접근제어목록(Access Control List·ACL)은 누가 어떤 문서를 읽을 수 있는지 나타내는 규칙입니다. 질문 입력창에 붙인 부서명은 그 규칙을 판단할 근거가 아닙니다. 서버가 로그인 증명의 서명·대상·만료 등을 검증하고 사용자 ID를 식별해야 합니다. 집단 소속과 허용 범위도 서버가 신뢰하는 권한 체계에서 얻습니다.

여기서 한 번 더 구분해야 합니다. 유효한 로그인 증명과 최신 부서 소속은 같은 사실이 아닙니다. 아직 만료되지 않은 증명에 과거 그룹이 들어 있거나, 검색 인덱스가 어제의 ACL을 가지고 있을 수 있습니다. 인사 시스템 변경이 인증·권한·검색에 반영되는 경로와 시간을 각각 확인합니다.

실제 구현 사례도 이 구분을 보여줍니다. Microsoft ISE는 익명 기업 고객의 SharePoint 브리핑 시스템에서 문서 권한을 검색 인덱스로 전달했습니다. 사용자·그룹을 안정적인 식별자로 정규화하고 검색 시 거르는 방식입니다. 해당 고객은 정기 수집 사이의 제한된 권한 전파 지연을 수용했다고 설명합니다. 이는 구현팀의 공개 설명이며 독립 보안 감사 결과는 아닙니다. Microsoft ISE, 2026-04-30

현재 Azure AI Search 문서도 검색 시 검사가 인덱스에 동기화된 권한 메타데이터에 의존한다고 명시합니다. SharePoint의 개별 고유 권한 변경과 상위 폴더에서 상속한 변경은 갱신 방식이 다릅니다. 후자는 명시적인 refresh가 필요합니다. native ACL 관련 기능의 preview 여부도 사용 API와 함께 확인해야 합니다. Microsoft Learn, 2026-08-12 갱신

그러므로 “검색할 때 권한을 검사한다”는 설명만으로 인수를 끝내면 안 됩니다. 어떤 시점의 권한으로 검사하는지를 물어야 합니다. 매우 민감한 문서에 지연을 허용할 수 없다면 최신 권한 확인이 가능한 경로를 마련해야 합니다. 그 경로가 없을 때는 해당 문서의 검색 제공을 보류하는 선택도 필요합니다.

PART 4개정과 삭제는 캐시와 인용까지 따라갑니다

권한 철회가 실패하는 시간을 눈으로 보이게 만들어 보겠습니다. 예제에서는 철회 후 60초 안에 신규 응답의 노출을 중단한다는 시험 조건을 정합니다. 이 값은 설명용이며 어떤 공급자의 보장이나 보안 권장값도 아닙니다. 실제 허용 시간은 자료 소유자와 보안 담당자가 정해야 합니다.

캐시를 비우는 것만으로 끝나지 않습니다. 사용자나 권한 조건을 구분하지 않은 공용 답변 캐시는 다른 사람의 결과를 재사용할 수 있습니다. 사용자 범위·문서 버전·권한 버전을 캐시 식별에 반영하고, 응답을 돌려줄 때도 접근 가능성을 확인하는 설계가 필요합니다. 캐시 키에 사용자 ID를 넣었다는 사실만으로 철회가 반영되지는 않습니다.

이전 대화도 시험합니다. 지난주 답변을 대화 문맥에 그대로 넣으면, 검색에서 차단한 단가를 모델이 다시 말할 수 있습니다. 서버가 다음 호출에 제공하는 과거 근거도 현재 사용 가능 여부에 맞춰 걸러야 합니다. 다만 이미 사용자 화면에 표시됐거나 다운로드한 내용까지 지울 수 있다고 약속해서는 안 됩니다.

문서 삭제에는 재노출을 막는 삭제 표시가 유용합니다. 원본이 없어지면 해당 ID를 우선 검색 제공 대상에서 제외하고, 인덱스·캐시·파생 요약을 정리합니다. 실물 삭제와 검색 제공 중단의 완료 시각을 따로 남깁니다. 백업·감사 기록의 보관은 별도 정책을 따르며, 일반 질의가 그 보관본을 우회 검색하지 못하게 합니다.

인용 역시 클릭했을 때의 권한을 확인해야 합니다. 생성 답변의 구간과 원문 참조를 연결하는 구조는 AWS의 Citation 자료형에서도 확인할 수 있습니다. 그러나 인용 번호가 있다고 근거가 유효해지는 것은 아닙니다. 삭제·개정된 근거로 작성한 이전 답변에는 재검토가 필요하다는 상태를 연결합니다.

PART 5같은 질문으로 여섯 가지 변경을 재현합니다

이제 표 2를 테스트 공간에서 실행합니다. 각 행에는 변경 전 상태를 복원한 뒤 한 가지 변경만 적용합니다. 그래야 문서가 안 보이는 이유가 권한 때문인지 삭제 때문인지 구분할 수 있습니다. 시각·문서 ID·버전·검색된 근거·캐시 사용 여부를 함께 기록합니다.

표 2 · 검색 정답과 변경 반영을 따로 판정합니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

출처: 합성 자료에 대한 시험 설계. 기대 결과는 실제 실행 결과가 아닙니다.

아래 블록은 담당자에게 그대로 전달할 수 있는 시험 요청입니다. 실제 문서나 계정 정보 대신 예제 식별자를 유지합니다. 아직 실행하지 않은 칸에 PASS를 미리 채우지 않는 것이 중요합니다.

시험명: U017 부서 이동 후 신규 응답의 권한 철회 확인
공간: 운영 데이터가 없는 테스트 환경
준비: BID-17 v3, 영업 폴더 ACL 상속, U017 영업 그룹
사전 질문: 오리온 거래처의 납품 단가는 얼마인가요?
사전 기대: 4만 원, 근거 BID-17 v3
변경: 2026-09-14 10:00:00에 영업 그룹에서 U017 제거
조건: 예제의 철회 반영 허용 시간은 60초
재시험: T+5초, T+30초, T+65초에 같은 질문
경로: 새 대화 / 기존 대화 / 캐시 적중 / 인용 직접 열기
필수 기록: 서버 사용자 ID, 권한 버전, 문서 버전, 응답 시각
실패 조건: T+65초 신규 응답에 제한 단가 또는 제한 근거 노출
현재 판정: 미실행. 담당자가 실제 응답과 증거를 첨부합니다.

금액 문자열만 검사하면 표현을 바꾼 누출을 놓칠 수 있습니다. “네 장의 만 원권”처럼 우회한 답도 내용은 같습니다. 반대로 4만 원이 일반 문서에도 있다면 그 숫자가 나왔다는 이유만으로 누출로 단정할 수 없습니다. 검색 근거의 ID와 최종 문장을 함께 확인해야 합니다.

PART 6통과해도 남는 실패 조건이 있습니다

작은 시험표의 통과는 전체 자료의 안전 보증이 아닙니다. 중첩 그룹, 공유 링크, 예외 권한이 다른 문서에 남아 있을 수 있습니다. 실제 권한 종류를 목록으로 만들고 각 종류가 시험에 들어갔는지 확인합니다. 한 계정의 성공을 모든 부서에 확대하지 않습니다.

변경과 응답이 동시에 일어나는 경우도 남습니다. 검색을 시작할 때는 권한이 있었지만 응답을 반환하기 전에 철회될 수 있습니다. 어느 시점을 기준으로 차단할지 계약에 적고, 필요하면 반환 직전 재확인을 둡니다. 확인 서비스가 고장 났을 때 과거 허용 결과를 무조건 재사용하면 철회 조건이 무너집니다.

기록 자체의 노출도 살펴봅니다. 제한 문서의 제목·질문·생성 답변이 운영 로그에 남으면 일반 검색만 막아서는 부족합니다. 로그의 열람 권한과 보관 기간을 따로 정합니다. 근거 링크가 열리지 않는 경우에도 제목이나 발췌문으로 제한 정보를 드러내지 않는지 확인합니다.

이 글은 시험 설계이며 특정 제품의 보안을 인증하지 않습니다. Microsoft 사례가 수용한 전파 지연을 여러분 조직이 그대로 수용할 이유도 없습니다. 개인정보·계약·영업 기밀마다 요구가 다르면 자료 집합을 나누고 다른 제공 조건을 적용하는 편이 명확합니다.

PART 7첫 입력은 우리 회사의 변경 한 건입니다

처음에는 인덱스 크기를 늘리기보다 최근에 바뀐 규정 한 건을 고릅니다. 누가 언제부터 어떤 버전을 읽어야 하는지 문서 소유자와 적어봅니다. 이어 시험용 계정으로 변경 전·후 질문을 반복합니다. 설명 자료보다 실제 응답과 근거가 남는 작은 시험이 다음 결정을 도와줍니다.

사내 RAG는 현재 허용된 근거를 찾아야 합니다. 변경은 검색뿐 아니라 캐시·대화·인용까지 도달해야 합니다. 통과했다면 그 결과가 적용되는 자료와 권한 범위를 남깁니다.

이번 편은 근거를 읽는 경계를 다뤘습니다. 다음 편은 그 근거로 업무를 등록할 때의 경계입니다. 응답이 끊겼다는 이유로 같은 업무를 두 번 만들지 않으려면 실행 상태가 필요합니다.

이전: 우리 회사 업무, 어디까지 Agent에 맡길까 · 다음: 회의록에서 업무 등록까지 · 전체 읽기 순서

공개 자료 확인 기준: 2026-09-13. 예제의 조직·문서·계정·금액·시간은 합성 자료입니다.