RAG 문서 갱신 실전 — 바뀐 규정과 삭제 문서 반영하기
규정을 수정해도 AI가 이전 내용으로 답하는 문제를 해결하기 위해 문서 버전·시행일·색인 교체·삭제 반영·캐시 무효화와 갱신 후 검수 절차를 정리했습니다.
사내 출장비 규정을 바꿨는데 AI가 여전히 이전 금액을 안내할 수 있습니다. 원본 파일의 수정 날짜가 최신이고 업로드도 성공했다면, 원본에서 검색 결과와 답변까지 이어지는 갱신 과정을 살펴보세요. 어느 단계에 이전 내용이 남았는지 확인하는 것이 먼저입니다.
RAG 청킹 실전이 문서를 어떻게 나눌지에 관한 글이라면, 이번 글은 나눈 문서를 언제 교체하고 어떻게 제외할지에 관한 글입니다. 아래 출장비 규정과 금액은 모두 설명용 가상 사례입니다.
파일 교체와 답변 갱신은 같은 작업이 아닙니다
RAG가 참조하는 자료는 원본 파일 하나로 끝나지 않을 수 있습니다. 문서 추출본, 청크, 검색 인덱스, 답변 캐시, 대화 이력에 이전 내용이 남을 수 있습니다.
먼저 문제가 발생한 답변에서 근거 문서 ID와 버전을 확인하세요. 검색 결과부터 이전 버전이라면 색인과 필터를, 검색 결과는 최신인데 답변만 오래됐다면 전달한 문맥과 캐시를 살펴봅니다. 검색과 생성의 구분은 RAG 검색 품질 점검법을 함께 참고하세요.
| 확인 위치 | 점검 질문 |
|---|---|
| 원본 | 승인된 문서와 시행일이 맞는가? |
| 추출·청킹 결과 | 바뀐 문장과 연결된 각주가 함께 반영됐는가? |
| 검색 인덱스 | 새 버전이 검색되고 이전 버전은 의도대로 제외되는가? |
| 답변 캐시 | 이전 근거로 만든 답변을 재사용하지 않는가? |
| 대화 이력 | 과거 답변이 최신 근거처럼 다시 전달되지 않는가? |
문서 ID와 버전을 분리해서 관리하세요
파일 이름에 최종, 진짜최종을 붙이는 대신 문서의 정체성과 변경 이력을 나눕니다. 문서 ID는 유지하고, 내용이 바뀔 때 버전과 내용 해시를 갱신하는 방식으로 시작할 수 있습니다.
다음 필드와 값은 특정 검색 제품의 필수 스키마가 아닌 내부 관리 예시입니다.
document_id=travel-policy
version=v2
content_hash=[현재 내용의 해시]
status=active
effective_from=2026-09-01
access_group=all-employees
index_generation=travel-v2-reviewed
source_locator=출장비 규정 / 제4조 / 3쪽
수정 날짜와 시행일은 다릅니다. 오늘 등록한 자료가 아직 시행 전일 수도 있고, 과거 출장에 적용할 기준을 묻는 질문일 수도 있습니다. “항상 가장 최근 파일”이 아니라 질문의 기준일과 사용자 권한에 맞는 유효 문서를 선택해야 합니다.
수정 문서를 반영하는 다섯 단계
- 승인된 원본에서 내용 변경과 시행일을 확인합니다.
- 새 버전의 추출·청킹 결과를 별도 작업 영역에 만듭니다.
- 변경된 조항과 예외 조건을 질문으로 검사합니다.
- 검수한 버전으로 검색 대상을 전환하고 구버전의 현재 검색 노출을 막습니다.
- 관련 답변 캐시를 무효화하고 실제 질의 경로에서 다시 확인합니다.
검색 대상을 전환할 때는 새 버전과 구버전이 함께 검색되는 구간이 있는지 확인하세요. 그 시간을 줄이는 방법으로 검수용 인덱스와 운영 인덱스를 분리하거나, 검색이 참조하는 세대 값을 바꾸는 구조를 검토할 수 있습니다.
전환을 한 번에 처리하는 원자적 전환을 제품이 지원하는지는 별도로 확인해야 합니다.
청크를 다시 만들 때는 수정한 문장뿐 아니라 제목 경계와 표 구조도 대조하세요. 이 구조가 바뀌면 뒤쪽 청크도 달라질 수 있어, 청크 하나만 교체해서는 변경을 모두 반영하지 못할 수 있습니다.
청크 ID를 추적하기 어렵다면 변경된 문서에 속한 청크 전체를 교체하는 방식도 검토해 보세요.
삭제는 별도의 경로로 검증하세요
원본 저장소에서 파일을 지웠다고 검색 인덱스에서도 자동으로 없어지는 것은 아닙니다. 예를 들어 Azure AI Search의 변경·삭제 감지 문서는 변경 감지와 삭제 감지를 구분하고, 삭제 정책의 설정 조건을 설명합니다. 사용하는 저장소와 색인 방식에 맞춰 지원 범위를 확인해야 합니다.
운영 점검에서는 삭제 대상 문서 ID에 연결된 청크 목록부터 확보하세요. 한 원본이 여러 청크로 나뉘었다면 부모 문서 한 건만 지우고 끝낼 수 없습니다.
삭제 요청 접수
→ 문서 ID와 파생 청크 목록 확인
→ 신규 검색·답변에서 즉시 제외
→ 검색 인덱스·추출본·관련 캐시 정리
→ 원본과 보관 사본의 정책에 따른 처리
→ 검색 및 직접 ID 조회로 잔존 여부 확인
deleted=true 같은 표시만 저장하고 검색 필터가 이를 사용하지 않으면 자료는 계속 검색됩니다. 제외 규칙은 사용자 요청문이 아니라 서버가 결정하는 검색 조건에 포함해야 합니다.
삭제된 자료를 복구용 구버전 인덱스에 남겨 두었다면 롤백할 때 다시 노출될 수 있습니다. 복구 경로에도 삭제 목록과 최신 권한 조건이 적용되는지 확인하세요. 보관 사본의 처리 기간은 조직 정책과 적용 의무에 맞춰 정합니다.
가상 출장비 규정으로 갱신 전후를 점검해 보세요
예시에서는 v1의 숙박비 상한을 8만 원, v2를 10만 원으로 정합니다. v2는 2026-09-01부터 적용하며, 교육 참석에는 별도 승인 조건이 있다고 가정합니다. 실제 회사 규정이나 법정 기준이 아닙니다.
| 시험 질문 | 확인할 근거와 결과 |
|---|---|
| 현재 일반 출장 숙박비 상한은? | v2의 10만 원과 적용 범위 |
| 2026-08-20 출장에는 어떤 기준인가? | 과거 조회를 허용한 경우 v1과 당시 시행 조건 |
| 교육 참석도 같은 금액이면 되는가? | 금액 외 별도 승인 조건도 포함 |
| 폐기한 임시 규정의 문구를 검색하면? | 현재 검색과 인용에서 제외 |
| 접근 권한 없는 사용자가 같은 질문을 하면? | 보호된 문서 내용과 인용 모두 미노출 |
과거 규정을 제공하지 않는 서비스라면 두 번째 질문에 과거 값을 추측하지 않고 담당 부서 확인을 안내하는 것이 기대 결과입니다. 어떤 행동을 허용할지 먼저 정한 뒤 검사하세요.
기대 결과·실패 징후·확인 순서
기대 결과: 현재 질문과 과거 질문의 기준이 구분되고, 수정된 금액뿐 아니라 예외 조건도 반영됩니다. 삭제·권한 변경은 검색 결과와 답변에 함께 적용됩니다.
실패 징후: 같은 질문에서 버전이 번갈아 나오거나, 검색에는 없어진 문서를 캐시 답변이 인용하거나, 인덱스 복구 후 삭제 문서가 다시 나타납니다.
확인 순서
- 답변의 문서 ID·버전·원본 위치를 확인합니다.
- 추출본과 청크에서 변경 부분을 대조합니다.
- 실제 사용자 권한으로 검색 결과를 확인합니다.
- 새 대화와 기존 대화에서 각각 시험합니다.
- 캐시가 있는 경우와 없는 경우를 나눠 검사합니다.
- 수정·삭제·복구 후 같은 질문 묶음을 다시 실행합니다.
자주 묻는 질문
Q1. 문서를 수정할 때마다 전체 인덱스를 다시 만들어야 하나요? 변경 문서만 교체할 수 있는 구조라면 전체 재생성을 피할 수 있습니다. 다만 청크 추적, 삭제 반영, 전환 중 일관성까지 확인해야 합니다.
Q2. 구버전은 모두 삭제하는 것이 맞나요? 과거 기준 조회와 보관 목적이 있다면 접근 범위를 나눠 보관할 수 있습니다. 현재 답변용 검색에서 제외하는 것과 물리적으로 삭제하는 것은 다른 결정입니다.
Q3. 업로드 성공 로그만 있으면 반영 완료인가요? 아닙니다. 검색 가능한 상태가 됐는지, 사용자 요청 경로에서 새 근거가 선택되는지까지 확인해야 합니다.
Q4. 문서 변경이 없는데 권한만 바뀌어도 갱신해야 하나요? 권한 메타데이터와 검색 필터를 갱신하고 기존 캐시의 재사용 조건도 확인해야 합니다. 내용 해시만 비교하면 권한 변경을 놓칠 수 있습니다.
공식 자료와 확인 기준일
확인 기준일: 2026-09-06 — 버전 필드, 전환 흐름, 출장비 사례는 운영 설계를 위한 예시입니다. 특정 제품의 자동 처리 범위를 뜻하지 않습니다.