운영 실무 가이드 · 중상급

RAG 최신성 운영: 생성·수정·삭제·권한 변경과 인덱스 롤백

원본 변경을 create·update·delete·permission change 이벤트로 기록하고 결정적 문서 ID와 버전으로 모든 파생 청크를 멱등 갱신한다. 스키마·파서·임베딩 변경은 새 인덱스를 나란히 구축해 검증 후 alias로 전환하며, 롤백 전에는 삭제·권한 회수 이벤트를 반드시 재적용해 오래된 보안 상태가 되살아나지 않게 한다.

발행 2026-07-14LLM / RAG10분 읽기

30초 답변

RAG 최신성은 “매일 다시 색인”하는 일정이 아니라 원본 변경을 빠짐없이 전달하는 수명주기 문제다. 문서 생성, 본문·메타데이터 수정, 삭제, 권한 변경을 서로 다른 이벤트로 기록하고, 동일 이벤트가 반복되거나 순서가 바뀌어도 안전하게 처리하도록 문서 ID와 버전을 설계해야 한다. 스키마·청킹·임베딩처럼 전체 재색인이 필요한 변경은 기존 인덱스를 덮어쓰지 말고 새 버전을 나란히 구축해 검증한 뒤 alias를 전환한다.

가장 중요한 주의점은 롤백이다. 오래된 인덱스로 되돌릴 때 그동안 발생한 삭제와 권한 회수까지 되돌리면 안 된다. 보안 관련 이벤트를 재적용하거나 안전을 확인할 때까지 해당 문서를 차단해야 한다.

이 글의 핵심

create, update, delete, permission change는 비용과 위험이 다르므로 별도 사건으로 처리한다.
원본 문서 ID와 버전에서 파생 청크 ID를 결정적으로 만들어 중복·고아 청크를 막는다.
삭제는 원본 파일 제거만으로 끝나지 않는다. 색인, 벡터, 크롭 이미지, 캐시, 인용 기록의 파생물을 추적해 제거한다.
권한 회수는 일반 본문 갱신보다 우선순위가 높고, 실패 시 deny-by-default로 처리한다.
새 인덱스는 side-by-side 검증 후 alias로 전환하고, rollback runbook에는 보안 이벤트 재생 절차를 포함한다.

시각	의미
`source_updated_at`	원본 시스템에서 내용이 바뀐 시각
`event_observed_at`	수집기가 변경을 감지한 시각
`index_visible_at`	새 내용이 검색 결과에 보이기 시작한 시각
`cache_invalidated_at`	옛 검색·답변 캐시가 더 이상 사용되지 않는 시각

변경 이벤트의 공통 계약

폴링, CDC, 웹훅, 메시지 큐 중 어떤 방식을 사용하더라도 검색 파이프라인이 받는 이벤트 계약은 일관되어야 한다.

{
  "event_id": "evt-01K...",
  "event_type": "permission_changed",
  "source_document_id": "dms:policy-184",
  "source_version": 27,
  "occurred_at": "2026-07-17T02:04:00Z",
  "content_hash": "sha256:...",
  "permission_version": 12,
  "trace_id": "ingest-..."
}

event_id는 중복 처리를 막고, 단조 증가하는 문서 버전 또는 원본 수정 시각은 늦게 도착한 옛 이벤트가 새 데이터를 덮지 못하게 한다. 메시지는 적어도 한 번 전달될 수 있다고 가정하고 동일 이벤트를 다시 실행해도 같은 결과가 되는 멱등성을 확보한다. 실패 이벤트는 dead-letter queue에 넣는 것으로 끝내지 말고 담당자, 재처리 기준, 최대 체류시간을 정한다.

문서 ID가 파일 경로에만 의존하면 폴더 이동이나 이름 변경이 삭제+생성으로 보이거나 옛 청크가 남을 수 있다. 원본 시스템의 불변 ID를 우선 사용하고, 경로는 수정 가능한 메타데이터로 둔다.

create: 검색 가능 상태를 한 번에 활성화한다

새 문서가 들어오면 다음 순서가 필요하다.

원본 파일과 메타데이터·ACL을 읽는다.
파일 형식, 악성 콘텐츠 정책, 파싱 가능 여부를 검사한다.
텍스트·표·이미지를 파싱하고 청크·임베딩을 만든다.
모든 파생 레코드에 동일한 source_document_id, 문서 버전, ACL을 넣는다.
예상 청크 수, 필수 필드, 파싱 오류를 검증한다.
문서 버전 전체를 검색 가능 상태로 활성화한다.

청크를 하나씩 즉시 노출하면 처리 도중 사용자가 문서의 절반만 검색할 수 있다. 검색 엔진이 문서 단위 트랜잭션을 지원하지 않는다면 ingestion_status=staging 같은 필드로 파생물을 먼저 적재하고, 검증 후 활성 버전 필터가 가리키는 상태를 바꾸는 패턴을 사용할 수 있다. 공개 전 ACL이 반드시 존재해야 하며, ACL 추출 실패를 public으로 해석하지 않는다.

update: 무엇이 바뀌었는지에 따라 작업을 줄인다

수정 이벤트는 네 종류로 나눌 수 있다.

본문 변경: 재파싱, 영향 청크 재생성, 해당 임베딩 갱신
검색 메타데이터 변경: 제목, 시행일, 태그 등 필드 갱신
경로·표시 정보 변경: 원문 URL, 파일명, 페이지 라벨 갱신
파이프라인 변경: 파서, 청킹, 임베딩, 스키마 변경으로 전체 재색인 가능성

본문 해시가 같으면 임베딩 계산을 생략할 수 있지만 제목이 검색 텍스트에 포함되거나 섹션 계층이 바뀌었다면 관련 청크를 다시 만들어야 한다. 변경 감지 최적화는 필드 의존성을 명시한 뒤 적용한다.

새 문서 버전의 청크 수가 이전보다 줄었을 때 upsert만 하면 사라진 뒷부분 청크가 남는다. 새 버전을 별도 ID로 완성한 뒤 활성 버전을 교체하고 옛 버전을 삭제하거나, 현재 파생 ID 집합과 새 집합을 비교해 차집합을 삭제한다. 어떤 방식이든 “추가·덮어쓰기”만으로는 충분하지 않다.

Azure AI Search의 인덱스 업데이트·재구축 문서는 문서 작업에서 mergeOrUpload, merge, delete를 구분하고, 필드 형식·분석기 같은 일부 스키마 변경은 전체 재구축이 필요하다고 설명한다. 제품별 지원 범위를 확인해 in-place update와 새 인덱스 구축을 구분한다.

delete: tombstone을 먼저 전달하고 파생물을 지운다

원본을 먼저 물리 삭제한 뒤 수집기가 다음 주기에 알아서 찾기를 기대하면 고아 문서가 남을 수 있다. 삭제 이벤트 또는 soft-delete 표식을 먼저 만들고, 검색 파이프라인이 이를 처리한 사실을 확인한 후 원본 보존 정책에 따라 물리 삭제한다.

삭제 대상에는 다음이 포함된다.

전문 검색 문서와 벡터 청크
표·이미지 설명과 크롭 이미지
문서별 검색 결과·답변 캐시
미리보기·자동완성용 보조 인덱스
재처리용 중간 산출물

감사 로그나 이미 생성된 대화 기록은 별도 보존 정책이 적용될 수 있으므로 무조건 같은 방식으로 지우지 않는다. 대신 문서 삭제 후 과거 답변의 원문 링크가 어떻게 동작할지 정책을 정한다.

Microsoft의 Azure Storage 변경·삭제 감지 문서는 변경 감지와 삭제 감지가 같은 기능이 아니며, 삭제 추적 정책을 첫 indexer 실행 전에 설정하지 않으면 고아 검색 문서가 남을 수 있다고 설명한다. 또한 indexer reset 문서는 reset·run이 원본에 없는 고아 문서를 자동 정리하지 않는다고 명시한다. “전체 재실행하면 삭제도 해결된다”는 가정은 사용 중인 제품의 공식 동작으로 검증해야 한다.

삭제 API가 성공해도 실제 검색에서 즉시 사라지는지 별도 확인한다. 제품에 따라 물리 정리는 비동기일 수 있다. 보안상 즉시 차단이 필요하면 tombstone 목록을 query filter에 먼저 반영하고, 색인 삭제 완료 후 해제한다.

permission change: 재임베딩보다 차단 속도가 중요하다

권한 변경은 본문이 그대로이므로 보통 임베딩을 다시 만들 필요는 없다. 그러나 문서와 모든 청크의 ACL 메타데이터, 원문 링크 권한, 검색·답변 캐시를 갱신해야 한다.

권한 확대와 권한 축소의 위험은 다르다.

권한 확대가 지연되면 사용자가 당분간 문서를 못 본다.
권한 축소가 지연되면 더 이상 볼 수 없는 문서가 노출된다.

따라서 권한 축소 이벤트를 높은 우선순위로 처리하고, 새 ACL을 확인할 수 없거나 파생 청크 일부만 갱신된 상태에서는 해당 문서 전체를 일시 차단한다. 색인 성공 수와 예상 청크 수를 비교한 뒤 활성화한다. Microsoft의 검색 보안 모범 사례는 권한 메타데이터를 색인하고 질의 시 집행하는 구조와, 사용하는 기능에 따라 권한 변경 후 재색인이 필요할 수 있음을 안내한다.

캐시 키에 사용자 권한 컨텍스트가 없으면 ACL 색인만 고쳐도 옛 답변이 계속 노출될 수 있다. 권한 이벤트 처리 완료 조건에 캐시 무효화를 포함한다.

전체 재색인: 새 인덱스를 옆에 구축한다

청킹 규칙, 임베딩 모델, 벡터 차원, 분석기, 필드 형식이 바뀌면 기존 인덱스를 부분 갱신해 혼합 상태로 운영하기 어렵다. 새 인덱스 이름에 배포 번호만 넣는 대신 재현 가능한 manifest를 둔다.

index_version: knowledge-2026-07-17-v3
source_snapshot: dms-watermark-884201
schema_version: 8
parser_version: layout-4
chunker_version: section-aware-5
embedding_model: embedding-family-x@revision-y
permission_schema_version: 3
build_started_at: 2026-07-17T00:00:00Z
build_completed_at: null

권장 전환 절차는 다음과 같다.

현재 인덱스는 계속 서비스한다.
특정 원본 watermark로 새 인덱스 전체를 구축한다.
구축 중 들어온 create/update/delete/permission change 이벤트를 새 인덱스에도 재생한다.
문서 수뿐 아니라 문서 ID 집합, 활성 버전, ACL 누락, 청크 수, 임베딩 차원, 샘플 원문을 검증한다.
고정 평가셋과 shadow traffic으로 검색 품질·지연·권한 필터를 비교한다.
소수 canary 또는 내부 사용자로 확인한다.
애플리케이션이 참조하는 alias를 새 인덱스로 전환한다.
전환 후 오류, no-result, 최신성 지연, 권한 거부를 집중 모니터링한다.

Azure 공식 문서는 운영 스키마 변경 시 새 인덱스를 나란히 만들고 테스트한 뒤 index alias로 전환하는 방식을 권장한다. alias 지원과 전환의 원자성·제약은 검색 제품과 API 버전마다 확인해야 한다.

rollback: 애플리케이션은 되돌려도 보안 상태는 되돌리지 않는다

새 인덱스에서 검색 품질이나 성능 문제가 발생하면 alias를 이전 버전으로 돌리는 것이 가장 빠른 복구 수단일 수 있다. 그러나 이전 인덱스에는 전환 이후 삭제된 문서나 회수된 ACL이 남아 있을 수 있다. 단순 alias rollback은 기능 복구와 동시에 데이터·권한 회귀를 일으킬 수 있다.

롤백 전 필수 절차는 다음과 같다.

이전 인덱스가 어떤 source watermark에서 만들어졌는지 확인한다.
그 이후의 delete와 permission-revocation 이벤트를 최우선으로 재생한다.
create·update 이벤트의 호환성을 확인하고 필요한 최신 변경을 재생한다.
폐기 문서, 권한 회수 사용자, 테넌트 격리 smoke test를 실행한다.
애플리케이션 버전이 이전 인덱스 스키마와 호환되는지 확인한다.
검증 후 alias를 되돌리고 캐시를 해당 index version으로 분리 또는 무효화한다.

보안 이벤트를 재생할 수 없다면 이전 인덱스로 바로 롤백하지 않는다. 영향 문서 또는 전체 비공개 검색을 일시 차단하고 안전한 복구 경로를 선택한다. 그래서 변경 이벤트 로그와 index manifest는 디버깅 편의가 아니라 롤백 안전장치다.

이전 인덱스는 즉시 삭제하지 말고 정해진 관찰 기간 보존하되, 읽기·관리 권한을 제한한다. 보존 기간이 끝나면 비용과 데이터 최소화 정책에 따라 삭제한다.

운영 관측: “indexer 성공”보다 사용자 가시성을 본다

대시보드에는 다음 항목이 필요하다.

이벤트 유형별 처리량, 실패율, 재시도 수
queue depth와 oldest event age
원본 수정부터 검색 노출까지의 freshness lag
문서별 예상 청크 수와 실제 활성 청크 수
ACL 누락·불일치 문서 수
tombstone 미처리·고아 청크 후보 수
인덱스 버전별 문서 수, 저장량, 검색 지연
캐시 무효화 실패와 옛 버전 응답 비율
사용자 신고 “옛 문서” 사례와 연결된 trace ID

검색 가능 여부를 확인하는 합성 모니터를 둔다. 테스트 문서를 생성하고 검색 노출을 확인한 뒤 수정, 권한 회수, 삭제까지 주기적으로 실행하면 파이프라인 성공 로그만으로 발견하기 어려운 단절을 잡을 수 있다. 테스트 데이터는 운영 사용자에게 노출되지 않는 격리된 테넌트와 권한으로 구성한다.

사용자 경험과 실패 시나리오

“새 규정을 올렸는데 챗봇은 어제 규정을 답합니다”

색인 지연뿐 아니라 검색 결과 캐시나 답변 캐시가 원인일 수 있다. 답변에 문서 시행일과 최종 반영 시각을 표시하고, 운영 로그에서 source·index·cache 시각을 한 trace로 연결한다. 긴급 규정에는 수동 재색인 버튼보다 우선 이벤트 경로와 완료 확인 기능이 필요하다.

“문서를 삭제했는데 제목 검색에는 남아 있습니다”

본문 벡터만 지우고 자동완성·메타데이터 인덱스가 남았거나, 원본 물리 삭제가 삭제 이벤트보다 먼저 발생했을 수 있다. 문서 파생물 목록을 registry로 관리하고 삭제 완료 조건을 전체 파생 시스템의 확인으로 정의한다.

“수정 후 답변에 새 조항과 옛 조항이 함께 나옵니다”

옛 버전 청크 일부가 남거나 새 버전이 완성되기 전에 노출된 상황이다. 쿼리가 active_source_version만 검색하게 하고, 버전 교체를 문서 단위로 활성화한다. 전체 청크 수와 ID 차집합을 검증한다.

“롤백했더니 퇴사자가 예전 문서를 다시 볼 수 있습니다”

인덱스 롤백이 ACL 상태까지 과거로 돌린 심각한 실패다. alias 전환 전에 이전 인덱스에 permission-revocation과 delete 이벤트를 재생하고, 대표 퇴사·부서 이동 계정으로 권한 smoke test를 통과시킨다.

“indexer는 성공인데 일부 문서만 검색되지 않습니다”

배치가 부분 성공했거나 특정 파서 오류가 성공 작업 안에 포함됐을 수 있다. 작업 수준 상태 외에 문서별 결과, 예상 청크 수, 필수 필드, dead-letter 체류시간을 확인한다. 사용자에게는 처리 중·실패 상태를 운영 화면에서 구분해 보여준다.

실무 체크리스트

자주 묻는 질문

Q1. 주기적 전체 재색인만 하면 최신성 문제가 해결되나요?

아니다. 주기 사이의 지연이 있고, 삭제 감지가 자동으로 되지 않는 제품·데이터 소스가 있으며, 권한 회수는 다음 전체 작업까지 기다리기 위험하다. 증분 이벤트 경로를 기본으로 두고 전체 재색인은 스키마 변경, 누락 복구, 정합성 점검 수단으로 사용한다.

Q2. 문서 수정 때 전체 임베딩을 다시 만들어야 하나요?

본문과 청킹 결과가 바뀐 청크는 다시 만들어야 한다. ACL, 태그, 원문 URL만 바뀌었고 해당 필드가 임베딩 입력에 포함되지 않았다면 메타데이터 갱신으로 충분할 수 있다. 어떤 필드가 파서·검색 텍스트·임베딩에 영향을 주는지 의존성 표를 유지한다.

Q3. alias를 이전 인덱스로 돌리면 롤백이 끝난 것 아닌가요?

아니다. 이전 인덱스가 최신 삭제와 권한 회수를 반영했는지, 현재 애플리케이션 스키마와 호환되는지, 캐시가 어느 버전 결과인지 확인해야 한다. 특히 보안 이벤트를 재적용하지 않은 rollback은 폐기 문서와 권한 없는 내용을 다시 노출할 수 있다.

근거 자료

Microsoft Learn, Azure AI Search 인덱스 업데이트 또는 재구축
Microsoft Learn, indexer 실행·reset과 증분 처리
Microsoft Learn, Azure Storage 변경·삭제 감지
Microsoft Learn, 검색 인덱스 생성과 index alias
Microsoft Learn, Azure AI Search 보안 모범 사례
Google Cloud, Agent Search documents REST resource의 create·delete·patch

KMWorks AI Tech Lab은 기업 환경에서 검증·운영할 수 있는 AI 시스템 설계 기준을 공유합니다.