사내 RAG는 문서를 찾기 전에 문서의 수명을 관리해야 한다

사내 RAG의 검색 품질을 문서의 권위, 유효 기간, 폐기와 접근 권한 관리에 연결하고 최신 근거를 유지하는 운영 원칙을 살펴본다.

AI로 생성한 개념 이미지이며, 실제 업무 현장이나 시스템의 기록이 아니다.

사내 챗봇이 “출장 숙박비 상한은 12만 원”이라고 답했다. 답변 아래에는 회사 규정 PDF도 붙어 있다. 겉보기에는 모범적인 RAG 결과다. 문제는 그 PDF가 지난 분기까지 유효했던 규정이고, 이번 달부터 적용되는 개정본에는 다른 기준이 적혀 있다는 점이다. 검색은 성공했고 인용도 존재하지만, 업무는 틀린 문서에서 출발했다.

RAG를 구축할 때 관심은 대개 청크 크기, 임베딩 모델, 벡터 검색, 재순위화에 모인다. 모두 중요하다. 하지만 사내 지식은 고정된 책이 아니다. 규정은 개정되고, 제품 안내는 교체되며, 회의 결정은 뒤집히고, 초안은 승인본이 된다. 오래된 문서를 잘 찾는 시스템은 검색 품질이 높은 시스템이 아니라 오래된 근거를 빠르게 재생산하는 시스템이 될 수 있다.

Microsoft의 Azure RAG 아키텍처 문서는 청크에 고유 ID, 제목, 요약, 키워드 같은 메타데이터를 더해 처리와 검색에 활용하는 방식을 설명한다.[3] Google Cloud의 Agent Search 문서는 검색 신호에 문서의 나이를 판단하는 최신성이 포함되며, 메타데이터 필터와 날짜 기반 순위 조정도 사용할 수 있다고 밝힌다.[4] 두 자료는 제품 기능을 설명하지만, 여기서 얻을 운영 교훈은 더 일반적이다. 최신성은 프롬프트에 “최신 자료를 써라”라고 적는 것으로 해결되지 않는다. 문서와 청크가 어떤 원본, 버전, 유효 기간, 책임자에 속하는지 검색 전에 알 수 있어야 한다.

수정일은 유효성을 뜻하지 않는다

파일의 last_modified가 최근이라고 해서 내용이 현재 정책이라는 보장은 없다. 오래된 규정의 서식만 수정해 저장해도 수정일은 갱신된다. 반대로 지금도 유효한 오래된 표준 문서는 수년간 수정되지 않을 수 있다. 최신성 판단에는 적어도 세 종류의 시간이 필요하다.

• 발행 시점: 문서나 결정이 만들어진 때
• 효력 시점: 실제 업무에 적용되기 시작한 때와 끝나는 때
• 수집 시점: RAG 색인에 들어오거나 다시 확인된 때

여기에 버전 관계가 더해진다. 개정본 B가 원본 A를 완전히 대체하는지, 특정 부록만 바꾸는지, 지역이나 부서에 따라 함께 유효한지를 구분해야 한다. 날짜 하나만으로는 이 관계를 표현할 수 없다.

가령 인사 규정의 2026년판이 2025년판을 대체했다면, 2025년판을 삭제하는 것만이 답은 아니다. 과거 의사결정이나 감사 질문에는 당시 규정이 필요할 수 있다. 현재 질문에서는 제외하되, “2025년 7월 당시 기준”이라는 시간 조건이 붙으면 다시 검색돼야 한다. 폐기는 파일 제거가 아니라 어떤 질문에서 근거 자격을 잃는지 표시하는 일에 가깝다.

문서 책임자는 작성자가 아니라 유효성의 답변자다

많은 사내 문서에는 작성자 이름은 있어도 현재 책임자가 없다. 작성자는 퇴사하거나 부서를 옮길 수 있고, 회의록 작성자는 결정 권한자가 아닐 수 있다. RAG 운영에서 필요한 책임자는 “이 문서를 계속 써도 되는가”라는 질문에 답하거나 답할 사람을 지정할 수 있는 역할이다.

문서마다 다음 필드를 두면 수명을 추적하기 쉽다.

• source_id: 원본 문서를 안정적으로 가리키는 식별자
• revision_id: 이번 내용 버전
• effective_from, effective_until: 업무상 효력 범위
• status: draft, approved, superseded, withdrawn 같은 상태
• owner_role: 유효성을 확인할 부서나 역할
• supersedes: 대체한 이전 버전
• verified_at: 마지막으로 사람이 유효성을 확인한 때

이 필드명은 [3]이나 [4]의 표준 스키마가 아니라 저자의 운영 예시다. 조직에 이미 문서관리시스템의 상태와 권한 모델이 있다면 새 체계를 만들기보다 그 정보를 색인으로 전달해야 한다. RAG가 별도의 비공식 정본을 만들면 원래 시스템과 답이 갈라진다.

책임자를 붙이는 이유는 오류를 탓할 사람을 만들기 위해서가 아니다. 개정 신호가 왔을 때 누가 대체 관계를 확인하고, 모순이 발견됐을 때 누가 현재 근거를 판정하며, 기한이 지난 문서를 누가 보류할지 정하기 위해서다. 소유권 없는 지식은 수집 순간부터 서서히 낡는다.

수집, 검색, 답변에서 각각 최신성을 검사한다

최신성 검사는 한 곳에만 두면 쉽게 새어 나간다.

수집 단계에서는 원본 변경을 감지하고 영향을 받은 문서와 청크만 다시 처리한다. 같은 원본의 새 버전이 들어오면 이전 버전의 상태를 갱신하고, 새 청크가 어떤 개정본에서 파생됐는지 연결한다. Microsoft 문서가 고유 ID를 처리 중 중복 판단에 쓸 수 있다고 설명하는 이유도 이런 계보 관리와 맞닿아 있다.[3]

검색 단계에서는 질문의 시간과 권한을 해석한다. 현재 규정을 묻는 질문이라면 승인 상태이면서 현재 효력 범위에 있는 문서만 후보로 삼는다. 과거 사건을 묻는다면 사건 시점에 유효했던 버전을 찾는다. Google Cloud 문서는 최신성을 검색과 순위 신호로 다루고 메타데이터 필터로 후보를 좁힐 수 있다고 설명한다.[4] 다만 새 문서를 무조건 위로 올리는 것은 위험하다. 관련성 낮은 최신 공지가 핵심 규정보다 앞설 수 있으므로 날짜는 자격과 순위의 한 신호로 사용해야 한다.

답변 단계에서는 최종 근거의 버전과 효력 범위를 노출한다. “최신 규정에 따르면”이라고 쓰려면 어떤 문서를 언제 확인했는지 보여줘야 한다. 유효한 근거가 없거나 두 승인본이 충돌하면 모델이 하나를 고르게 하지 말고 답변을 보류해 책임자에게 보낸다.

가상의 휴가 규정 질문으로 시험한다

가상의 회사에 다음 자료가 있다고 해보자.

• A: 2025년 휴가 규정, 승인, 2026년 3월 31일까지 유효
• B: 2026년 휴가 규정, 승인, 2026년 4월 1일부터 유효, A를 대체
• C: 2026년 개정 검토안, 초안, 효력 미정
• D: 팀장이 작성한 요약 메모, B를 설명하지만 공식 정본은 아님

“지금 배우자 출산휴가는 며칠인가?”라는 질문에는 B가 근거 후보가 되어야 한다. C는 내용이 더 최신이어도 초안이므로 제외하고, D는 탐색을 돕더라도 최종 근거가 될 수 없다. “2026년 2월에는 며칠이었나?”에는 A가 필요하다. 이 작은 사례만으로도 벡터 유사도와 문서 자격이 다른 문제임을 알 수 있다.

시험 질문에는 정답뿐 아니라 쓰면 안 되는 근거도 적는다. 현재 질문에 A를 쓰면 실패, 승인되지 않은 C를 쓰면 실패, D만 인용하고 B를 열지 않으면 보류처럼 판정한다. 삭제된 문서가 검색 캐시나 파생 청크에 남는지도 살핀다. 원본 목록에서 사라졌다고 검색 결과에서도 사라졌다고 가정하면 안 된다.

문서 묘지를 만들지 않는 폐기 루프

사내 RAG는 추가 파이프라인보다 제거 파이프라인이 늦게 만들어지는 경우가 많다. 수집 성공률은 대시보드에 나오지만, 대체된 문서가 언제 검색에서 빠졌는지는 보이지 않는다. 최소한 다음 사건은 색인 갱신을 촉발해야 한다.

1. 원본의 새 버전 승인
2. 효력 종료일 도달
3. 문서 상태가 승인에서 철회로 변경
4. 책임 부서 변경
5. 보안 등급이나 열람 권한 변경
6. 답변 검토 중 근거 충돌 발견

정기 재색인만으로도 시작할 수 있지만 변경이 잦은 영역은 승인 사건과 연결하는 편이 낫다. 반대로 자주 바뀌지 않는 자료까지 매분 다시 색인하면 비용과 장애 면적만 커진다. 갱신 주기는 문서 종류와 오류 영향에 맞춰야 한다.

폐기 뒤에는 세 대상을 대조한다. 원본 시스템의 현재 상태, 검색 색인의 문서·청크 상태, 실제 질의 응답에 노출된 근거다. 세 곳 중 하나라도 이전 버전을 현재 근거로 취급하면 완료가 아니다. RAG는 원본을 복사한 별도 세계이므로, 동기화 성공 로그보다 질문으로 확인한 결과가 중요하다.

최신성은 정확도 기능이면서 조직 설계다

문서 수명 관리는 검색팀만의 일이 아니다. 규정을 승인하는 부서, 문서를 보관하는 시스템, 색인을 운영하는 기술팀, 답을 검토하는 현업이 같은 버전 관계를 공유해야 한다. 기술팀이 날짜 필드를 만들 수는 있어도 어떤 문서가 정본인지 대신 결정할 수는 없다.

시작은 작게 할 수 있다. 자주 묻고 자주 바뀌는 문서군 하나를 고른다. 현재본, 과거본, 초안, 요약본을 함께 넣고 시간 조건이 다른 질문을 만든다. 현재 질문에서 폐기 문서가 제외되는지, 과거 질문에서 필요한 이전 문서가 돌아오는지, 충돌하면 답변이 멈추는지 확인한다. 이 실험이 통과하면 그때 문서군을 넓힌다.

RAG의 신뢰는 얼마나 많은 문서를 넣었는가보다 어떤 문서가 지금 답할 자격이 있는가를 설명할 수 있는 데서 생긴다. 검색 품질을 높이기 전에 문서의 탄생, 승인, 대체, 폐기, 책임을 연결해야 한다. 지식은 저장되는 순간 완성되는 것이 아니라, 유효성을 잃는 순간까지 운영된다.

이 글의 근거와 한계

[3]과 [4]는 각각 Microsoft Azure와 Google Cloud의 제품 문서다. 메타데이터와 최신성 신호의 실제 구현 가능성을 보여주지만 모든 RAG 스택의 공통 표준은 아니다. 책임자·효력일·폐기 사건을 묶은 스키마와 가상 규정 사례는 저자의 제안이며, 각 조직의 기록관리·보안·법적 보존 의무에 맞춰 조정해야 한다.

참고 자료

[3] Azure Architecture Center — RAG chunk enrichment phase [4] Google Cloud Agent Search — About retrieval and ranking