색인 갱신 주기, 벡터DB 선택의 숨은 함정

RAG 벡터DB를 고를 때 색인 갱신 주기, 뭘 봐야 할까?

색인 갱신 주기는 "몇 분마다 전체를 다시 만드나"가 아니라 upsert 승인 후 검색에 노출되기까지의 지연, 즉 신선도 지표로 봐야 한다. 공개 벤치마크에서 이 지연은 Redis 2ms(p50)부터 Chroma 41ms까지 20배 넘게 벌어졌다. 하지만 이 값은 제품 버전·배포 방식·배치 크기에 따라 달라지므로, 최종 판단 근거는 벤더 공식 문서와 직접 재현한 부하 테스트여야 한다. aimultiple.com

이 글의 핵심

• 색인 갱신 주기는 하나의 숫자가 아니라 '신선도 지연', '대량 갱신 안정화 시간', '갱신 중 검색 지연' 세 가지로 나눠 측정해야 한다.
• 공개 수치(Redis 2ms ~ Chroma 41ms)는 검색 노출 지연이지, 전체 색인 재생성 주기가 아니다.
• Milvus는 대량 업데이트 후 색인 재구성이 필요할 수 있어 '즉시 upsert'와 '성능 안정화'를 별도 SLA로 잡아야 한다. deploybase.ai
• Pinecone·Qdrant가 잦은 업데이트를 비교적 잘 처리한다는 평가는 특정 실험의 정성적 결론이라, 실제 문서 크기와 갱신량으로 재현 테스트가 필요하다.

가장 흔한 함정은 벤더 문서의 "거의 실시간 색인" 같은 문구를 보고 색인 갱신 주기를 아예 검토하지 않는 것이다. 실제로는 upsert 승인, flush, segment 처리, 색인 안정화가 각각 다른 시점에 끝난다. 뉴스 기사나 상품 가격처럼 변경 직후 반영이 중요한 서비스에서 이 구간을 하나로 뭉뚱그리면, 운영 중 "분명 업데이트했는데 왜 옛날 문서가 검색되지?"라는 문의에 답을 못 하게 된다.

쓰기 승인과 검색 노출은 같은 순간일까?

아니다. 두 시점 사이에는 제품마다 다른 지연이 존재하고, 이 차이가 체감 신선도를 결정한다. 1백만 개·1,536차원·배치 100개 조건의 2026년 비교에서는 검색 자체의 p50 지연이 Qdrant 4ms, Redis 5ms, Milvus 6ms, Pinecone 8ms, ChromaDB·Weaviate 12ms, pgvector 18ms로 측정됐다. salttechno.ai 이 수치는 '검색 지연'이지 '새 벡터가 검색 가능해지는 시점'과는 다른 측정값이다. 앞서 인용한 쓰기→노출 지연(Redis 2ms~Chroma 41ms)과 검색 p50 지연을 같은 표에 섞으면 제품 비교가 틀어진다. 실제 운영 체크리스트를 만들 때는 두 지표를 반드시 분리된 행으로 기록해야 한다.

지표	의미	예시 수치
신선도 지연	쓰기 승인→검색 노출	Redis 2ms, Weaviate 4ms, Qdrant 9ms, Milvus 12ms, pgvector 14ms, LanceDB 31ms, Chroma 41ms
검색 지연	쿼리→결과 반환	Qdrant 4ms, Redis 5ms, Milvus 6ms, Pinecone 8ms

두 표를 분리해 두지 않으면 "Qdrant가 Redis보다 빠르다"는 식의 섣부른 결론이 나올 수 있는데, 이는 측정 구간이 다른 수치를 비교한 오류다.

대량 문서가 한꺼번에 바뀌면 색인은 바로 안정될까?

바로 안정되지 않는 경우가 많다. 대규모 일괄 갱신에서는 단순 upsert 완료 시점과, flush + compaction을 거쳐 색인이 최적 성능에 도달하는 시점을 따로 측정해야 한다. 한 공개 비교는 삽입 후 flush·compaction과 색인 안정화를 기다린 다음, 워밍업 쿼리 1만 건을 버리고 10만 건을 측정하는 절차를 사용했다. app.ailog.fr Milvus는 대량 업데이트 후 최적 성능을 위해 색인 재구성이 필요할 수 있다고 정리돼 있어, 문서가 한꺼번에 많이 바뀌는 RAG에서는 "즉시 upsert"와 "검색 성능이 안정화되는 시점"을 별도 SLA로 잡는 편이 현실적이다. deploybase.ai

반대로 같은 비교에서 Pinecone과 Qdrant는 잦은 업데이트를 비교적 잘 처리한다고 평가됐다. 다만 이는 특정 실험 조건의 정성적 결론이므로, 자사 문서 크기·갱신 빈도·필터 조건으로 재현 테스트를 거치지 않고 그대로 채택하는 것은 위험하다. 색인 처리량 자체도 조건에 따라 크게 갈린다. 1백만 개·768차원·top-10 검색 조건에서는 Milvus 초당 1만8천 벡터(67초→56초 구간), Qdrant 초당 1만5천 벡터(67초), Weaviate 초당 1만2천 벡터(83초), Pinecone 초당 8천5백 벡터(118초)로 보고됐다. aicited.org 아카이브형 RAG처럼 전체 재색인이 잦은 용도라면 이 처리량 차이가 운영 시간표에 직접 영향을 준다.

색인 갱신 주기 = 전체 재색인 스케줄이라는 생각, 맞을까?

틀린 전제다. "5분마다 전체 색인 재생성"이라는 표현은 배치형 파이프라인 시절의 습관이고, 실제로 측정해야 할 것은 upsert·flush·segment 처리 후 검색 반영까지의 신선도 지연이다. aimultiple.com 이 둘을 혼동하면 두 가지 테스트 케이스를 빠뜨리게 된다. 첫째, 이전 문서가 최신 버전으로 교체됐는지. 둘째, 삭제된 문서가 검색 결과에서 실제로 사라졌는지다. "새 문서가 검색되는가"만 확인하고 끝내면, 같은 질문에 옛 버전과 새 버전이 함께 top-k에 뜨는 사고를 놓치기 쉽다. 사내 규정·매뉴얼처럼 하루 또는 주 단위로 바뀌는 데이터라면 이 교체·삭제 테스트를 배치 주기마다 자동화해 두는 편이 재발 방지에 유리하다.

증분 갱신 비용, 실제로 어디서 새나갈까?

비용은 임베딩 호출 자체보다 색인 재구성과 운영 복잡도에서 더 자주 새어나간다. 100K~5천만 벡터, 768·1,536차원 조건을 다룬 비교는 p50/p95/p99 지연·색인 처리량·메모리·비용을 함께 평가하는 방식을 썼다. aicited.org 즉 "색인 갱신 주기"를 비교할 때는 최소한 다섯 가지—초당 처리 벡터 수, 전체 갱신 소요 시간, 검색 노출 지연, 갱신 중 검색 지연, recall 변화—를 함께 기록해야 비용이 어디서 나오는지 보인다. 대규모 문서 아카이브라면 Milvus처럼 높은 색인 처리량을 보이는 선택지와, compaction·재구성에 드는 운영 복잡도를 같은 저울에 올려야 한다.

재현성을 위해 실험 로그에는 임베딩 모델명, 벡터 차원(768 또는 1,536), 문서·청크 수, 증분 갱신량(전체의 0.1%·1%·10% 등), upsert 배치 크기, 색인 방식(HNSW·IVF 및 ef_search, M, nprobe)을 적어두는 편이 좋다. 측정 구간은 "요청 승인 시점"부터 "검색 결과에 새 문서가 처음 나타나는 시점"까지로 고정하고, p50·p95·p99 신선도 지연과 Recall@k를 같이 남기면 다음 벤치마크에서 조건을 바꿔도 비교가 가능하다. 2026년 기준으로는 이 다섯 수치를 한 표에 함께 두는 비교가 점점 표준에 가까워지는 분위기다.

핵심 정리

• 색인 갱신 주기는 전체 재색인 스케줄이 아니라 upsert→검색 노출 신선도 지연으로 측정해야 한다.
• 공개 벤치마크의 쓰기→노출 지연(Redis 2ms~Chroma 41ms)과 검색 p50 지연(Qdrant 4ms~pgvector 18ms)은 서로 다른 구간이니 섞어 쓰면 안 된다.
• Milvus처럼 대량 갱신 후 재구성이 필요한 제품은 "즉시 upsert"와 "성능 안정화 시점"을 별도 SLA로 분리해야 한다.
• 교체·삭제 테스트(옛 문서 사라짐, 최신 버전 top-k 진입)를 신선도 테스트에 반드시 포함한다.
• 비용 비교는 처리량·전체 갱신 시간·recall 변화를 함께 로그로 남겨야 다음 실험에서 재현 가능하다.