RAG 종류 총정리 ⑫ — 색인 수명주기: 삭제·재임베딩·신선도의 청구서

이 시리즈의 모든 색인 비용은 "일회성"으로 적었다. Contextual Retrieval 문서 100만 토큰당 $1.02, GraphRAG 수천 달러, ColPali 페이지당 443ms. 그런데 정확히 말하면 임베딩 모델 세대당 일회성이고, 리더보드는 해마다 바뀐다. 그리고 "법무팀이 이 문서 파기하래요"라는 한 줄이 예산을 두 배로 만든다. 이 글은 색인의 수명주기 비용을 다룬다.

지웠는데 안 지워졌다 — 벡터 DB의 삭제는 전부 툼스톤이다

세 엔진이 독립적으로 같은 숫자를 골랐다는 게 인상적이다. 삭제율 20%가 정리를 시작하는 공통 임계값이다 — Qdrant의 deleted_threshold=0.2, Milvus의 compaction.single.ratio.threshold=0.2, Lucene의 deletes_pct_allowed=20(범위 5~50). 그 전까지 삭제된 벡터는 HNSW 그래프와 RAM에 그대로 남는다. Qdrant 문서의 표현대로 "질의 중 느린 디스크 작업을 피하려고 삭제 표시만" 하기 때문이다.

더 중요한 건 "검색에 안 나옴"과 "파기됨"이 다르다는 점이다. Milvus의 TTL은 만료 엔티티를 즉시 검색에서 제외하지만 물리 삭제는 "보통 24시간 이내"이고, GC 관용 시간이 3시간, 고아 파일 스캔 주기는 7일이다. 물리 삭제 완료 시각을 조회하는 표준 API를 가진 벡터 DB를 찾지 못했다.

삭제 1건의 진짜 청구서

• 그래프 하나가 다시 지어진다. Lucene의 IncrementalHnswGraphMerger는 기존 그래프를 재사용하되 조건이 "삭제 문서를 하나도 포함하지 않을 것"이다. 즉 삭제 1건이 있는 세그먼트는 HNSW 그래프 전면 재구축 대상이 된다.
• pgvector는 삭제 청소가 곧 재빌드다. 공식 권장 절차가 REINDEX INDEX CONCURRENTLY → VACUUM이다. 그리고 dead tuple 누적은 조용한 리콜 손실로 나타난다 — hnsw.ef_search 기본 40에서 조건에 맞는 행이 전체의 10%면 평균 4건만 반환된다.
• force merge는 지우려다 영원히 못 지우게 만든다. 5GB를 넘긴 세그먼트는 이후 정규 병합 대상에서 빠져 소프트 삭제 문서가 계속 쌓인다. max_num_segments=1은 샤드 크기의 최대 3배 디스크를 일시적으로 요구한다. 가벼운 대안은 only_expunge_deletes=true.
• 삭제도 과금된다. Pinecone 서버리스는 삭제에 1KB당 1 WU, 요청당 최소 5 WU를 매긴다.

문서를 지워도 텍스트는 일곱 군데에 남아 있다

이 시리즈에서 소개한 기법들이 여기서 부메랑이 된다. 원문을 지웠을 때 그 텍스트를 여전히 들고 있는 것들:

• Contextual Retrieval의 접두 컨텍스트(청크마다 문서 요약 ~100토큰) — ③편
• RAPTOR 트리의 상위 요약 노드, GraphRAG의 커뮤니티 리포트 — ③·⑥편
• doc2query·HyDE로 생성해 색인한 질문들 — ③·④편
• 시맨틱 캐시 엔트리(답변 본문 전체) — 캐싱 시리즈 ⑥편
• LLM 요청·응답 로그와 트레이싱(프롬프트에 들어간 청크 원문)
• 평가 golden set과 회귀 픽스처 — ⑨편
• 리랭커·파인튜닝 학습 데이터

연쇄 삭제를 문서로 보장하는 벤더는 사실상 OpenAI Vector Stores 하나이고, 그마저 "최종적 일관성이라 제거된 파일의 내용이 잠시 검색에 남을 수 있다"고 적혀 있다(지연 수치는 없다). 나머지는 전부 애플리케이션 책임이다.

법적 요구와 대조하면 간극이 분명해진다. 개인정보 보호법 제21조는 "지체 없이" 파기하고 "복구 또는 재생되지 아니하도록" 조치하라고 하며, 시행령 제16조는 전자적 파일의 경우 "복원이 불가능한 방법으로 영구 삭제"를 요구한다 — 툼스톤 상태를 인정하지 않는다. GDPR 17조 2항의 "copy or replication" 삭제 통지 의무는 위 목록을 그대로 가리킨다. 실무 파기 증적은 다섯 개가 필요하다: ① 요청 수신 시각, ② 논리 삭제 시각, ③ compaction/vacuum 완료 = 물리 삭제 확정 시각, ④ 파생물별 삭제 확인, ⑤ 백업·스냅샷 만료. ③을 API로 주는 벡터 DB가 없다는 게 이 항목의 핵심 리스크다.

임베딩 모델을 갈아끼우는 데 드는 돈 — $2 vs $290

100M 토큰 코퍼스를 재색인한다고 하면:

방식	100M 토큰 재색인
평문 임베딩 (text-embedding-3-small)	약 $2
Contextual Retrieval 재생성	약 $290 (배치 시 ~$145)
GraphRAG 전체 추출 재실행	$537~1,075
ColPali형 시각 인덱스 (10만 페이지)	약 10.8 GPU시간 + 저장 25.75GB

평문과 컨텍스추얼의 차이가 145배다. 여기서 설계 규칙이 하나 나온다 — 접두 컨텍스트 텍스트를 임베딩과 분리해 원본 저장소에 보존하면 모델을 바꿔도 그 $290을 다시 내지 않는다. 그리고 GraphRAG는 "임베딩만 교체"가 애초에 불가능하다는 점(⑥편)이 여기서 다시 비용으로 나타난다. 시각 인덱스는 색인이 표준 파이프라인보다 18배 빠른 대신 저장이 30배 크다(페이지당 257.5KB vs 8.60KB)는 트레이드오프가 있다.

국내 레퍼런스로는 토스의 기록이 정확하다 — "임베딩 모델을 바꾸면 벡터 저장소 운영이 따라와요." 대응책 세 가지를 명시했다: 벡터의 생성 버전 추적, 서빙 버전의 일관성 유지, 모델과 인덱스를 함께 교체. 한 인덱스에 서로 다른 모델의 벡터가 섞이는 사고를 구조로 막은 것이다. blue-green 전환 기간에는 저장·질의 비용이 2배로 뜨니 이중 보유 기간을 짧게 잡아야 한다.

신선도는 주기가 아니라 이벤트로

엔터프라이즈 RAG의 실질 신선도 하한은 생각보다 느리다 — Azure AI Search 인덱서 최소 5분(실행 창 2시간, 반복 실패 시 최대 24시간까지 자동 후퇴), Amazon Q Business 시간별, Vertex AI Search는 1일·3일·5일 세 옵션뿐이다. 더 위험한 건 커넥터가 기본적으로 삭제를 전파하지 않도록 설계돼 있다는 점이다. Vertex의 기본 INCREMENTAL 모드는 upsert라 원본 삭제가 반영되지 않고(전파하려면 FULL), Amazon Q에는 삭제 예정 비율이 임계를 넘으면 삭제 단계를 통째로 건너뛰는 safeguard가 있다. 파기 파이프라인을 커넥터에 의존시키면 안 된다.

대안적 설계로 LY Corporation의 사례가 참고할 만하다. 주기 배치 대신 PR 머지가 갱신 트리거이고, 저장을 raw(원본 근거·변경 이력)와 knowledge(현시점 유효 내용만)로 나눈 뒤 staleness lint 5종(깨진 참조, 식별자 무결성, raw 변경 미반영, 메타데이터 누락, 배포본 비동기화)을 자동으로 돌린다. 마지막으로 낡음이 만드는 오답은 전체 정확도로는 안 보인다 — ⑨편의 CRAG 벤치마크는 질문을 실시간 10% / 일 단위 13% / 연 단위 23% / 불변 54%로 나눠 두었다. 자사 평가셋도 이렇게 쪼개고 색인 지연을 바꿔 가며 슬라이스별 정확도를 재는 것이 신선도를 측정하는 유일한 방법이다. 다음 글은 이 열두 편을 한국 상황에 맞춰 하나의 결정 트리로 접는다.

— RAG 종류 총정리 시리즈 ⑫ / 다음 글: 한국어 조건과 결정 트리 (완결)