백업과 재색인, 벡터DB 비용의 숨은 변수

벡터DB 비용 비교에서 백업과 재색인을 왜 따로 봐야 할까?

결론부터 말하면, 벡터DB 청구서에서 가장 많이 틀리는 부분은 저장 공간 단가가 아니라 백업·재색인 과정에서 생기는 이중 저장과 추가 컴퓨트다. 같은 GiB당 저장료를 제시하는 두 제품이라도 백업 보존 방식과 재색인 구조가 다르면 실제 운영비는 몇 배 차이가 날 수 있다. 그래서 이 글은 "저장료가 싸다"는 비교 대신, 백업·재색인 비용을 어떤 조건에서 측정해야 제품 간 비교가 공정해지는지를 점검한다.

이 글의 핵심

백업 비용은 스냅샷 저장료 하나가 아니라, 재색인 중 이중 저장·임베딩 재생성·쓰기 단위·복구 컴퓨트·검증 기간까지 합친 값이다.
공개 벤치마크의 QPS·Recall 수치는 검색 성능 측정이지 백업이나 재색인 비용 측정이 아니므로 그대로 환산하면 안 된다.
관리형 제품(Pinecone)은 운영 부담을 줄이지만 RU·WU·전송 단위 청구를 확인해야 하고, 자체 운영(Qdrant, Milvus, pgvector)은 라이선스 비용은 낮지만 백업·복구·재색인 인프라를 운영자가 직접 떠안는다.
임베딩 모델을 교체하면 1억 벡터 규모에서 임베딩 재생성만으로 약 $8,000~$15,000의 일회성 비용이 발생할 수 있다는 분석이 있다.출처: actian.com

이번 점검에서 확인하려는 것은 "특정 제품이 싸다"가 아니라 "백업·재색인 비용을 비교할 때 어떤 조건을 고정해야 하는가"다. 제품 비교표에 저장료만 나란히 적으면 운영 단계에서 예상 밖의 청구서를 받기 쉽다.

어떤 조건을 고정해야 백업·재색인 비용을 공정하게 비교할 수 있을까?

조건을 고정하지 않으면 벤치마크 수치가 서로 다른 전제를 비교하는 셈이 된다. 데이터셋 규모, 임베딩 모델, 인덱스 파라미터를 바꾸면 같은 제품도 결과가 크게 달라지기 때문이다.

실험 설계에서 최소한 고정해야 할 축은 다음과 같다. 먼저 데이터셋은 문서 수, 청크 수, 평균 토큰 수, 벡터 차원, 메타데이터 용량을 함께 공개해야 한다. 임베딩은 모델명과 버전, 배치 크기, API 리전, 입력 토큰 수를 적어야 나중에 같은 조건으로 재현할 수 있다. 인덱스는 HNSW, IVF, DiskANN 중 무엇을 썼는지와 주요 파라미터를 고정해야 한다. 이 세 축이 흔들리면 "Qdrant가 느리다" 같은 단순 비교는 실제로는 데이터 분포나 하드웨어 차이를 비교한 것일 수 있다. 실제로 1백만 벡터·768차원·HNSW 조건의 공개 벤치마크에서는 Qdrant가 약 1,200 QPS, Recall@10 약 99%를 기록했지만 같은 자료는 이 수치가 재색인 오버헤드를 포함하지 않는다고 명시한다.출처: awesomeagents.ai 즉 검색 성능 벤치마크와 백업·재색인 비용 측정은 조건을 분리해서 설계해야 한다.

실제로 스냅샷과 재색인을 측정하면 어디서 비용이 새어나갈까?

측정해보면 비용은 저장 자체가 아니라 "전환 구간"에서 새어나간다. 기존 인덱스를 유지한 채 새 인덱스를 만드는 동안 두 인덱스를 동시에 저장해야 하고, 그 기간 동안의 쓰기 단위와 컴퓨트가 추가로 청구된다.

백업 측정에서는 전체 스냅샷 용량, 생성 시간, 저장 기간, 복구 시간, 복구 후 검색 가능 시점까지를 각각 기록해야 한다. 재색인 측정에서는 기존 인덱스를 유지한 상태로 새 인덱스를 구축할 때 걸리는 전체 시간과 최대 디스크 사용량을 함께 봐야 한다. 자체 운영 제품에서는 이 구간에 스냅샷 저장소, 복구용 컴퓨트, 메시지 큐·메타데이터 계층까지 얽히므로 "DB 사용료"만으로는 총비용을 설명할 수 없다. Milvus는 저장소·컴퓨트·인덱싱 계층이 분리되어 있어 재색인 컴퓨트를 독립적으로 확장할 수 있다는 장점이 있지만, 동시에 인덱스 재생성용 워커와 객체 저장소를 별도로 관리해야 한다.출처: awesomeagents.ai 반면 pgvector 계열은 기존 PostgreSQL 백업·복제 체계를 재사용할 수 있어 별도 벡터DB 백업 체계를 추가하지 않아도 되지만, 임베딩 테이블이 커지면 WAL 증가와 인덱스 재생성용 디스크 여유 공간이 병목이 될 수 있다.

제품별 벤치마크 수치를 백업 비용으로 바로 써도 될까?

안 된다. QPS와 Recall은 검색 성능 지표이지 백업·재색인 비용 지표가 아니다. 두 지표를 섞어 쓰면 "빠른 제품이 곧 싼 제품"이라는 틀린 결론에 이를 수 있다.

예를 들어 5,000만 개, 768차원, Recall 99% 조건의 공개 벤치마크에서 pgvectorscale은 471 QPS, Qdrant는 41.47 QPS로 보고됐고, pgvectorscale의 p95 지연이 Pinecone s1보다 28배 낮았다는 수치도 있다.출처: firecrawl.dev 그러나 이 수치는 검색 지연을 비교한 것이지, 같은 조건에서 백업 생성 시간이나 전체 재색인 완료 시간을 비교한 것이 아니다. 같은 자료를 백업 비용 근거로 인용하려면 데이터베이스 버전, PostgreSQL 설정, 하드웨어, 인덱스 파라미터가 비교 조건과 일치하는지 다시 확인해야 한다. 이 혼동을 피하려면 리뷰 글에서 "검색 성능"과 "운영 비용"을 별도 표로 분리하고, 각 표에 측정일과 제품 버전을 함께 적는 편이 안전하다.

공개 자료는 백업·재색인 비용에 대해 무엇을 실제로 보여주나?

공개 자료는 비용 구조의 "항목"은 보여주지만, 모든 조건의 "실측 총액"까지 보여주지는 않는다. 이 차이를 구분하지 않으면 특정 사례의 수치를 일반화하는 오류가 생긴다.

Weaviate의 경우 2025년 이후 요금 체계에서 백업 항목이 GiB당 월 약 $0.022~$0.033 범위로 제시된 사례가 있고, 1,536차원 벡터 1,000만 개를 압축 없이 저장하는 예시에서는 백업 전 월 비용이 약 $1,459로 계산됐다.출처: awesomeagents.ai 이 값은 특정 가격표와 저장 조건을 적용한 계산 예시이지, 모든 배포에 적용되는 실측 청구액은 아니다. Pinecone 쪽에서는 쿼리 비용이 네임스페이스 크기에 따라 계산되고 쿼리당 최소 0.25 RU가 적용된다는 점이 지적되는데, 소규모 RAG는 쿼리량이 적어도 최소 과금 단위가 누적될 수 있다.출처: actian.com 2026년 기준으로 이런 공개 자료는 대부분 벤더 소개 자료이거나 개인 실험 결과이므로, 실제 리뷰를 쓸 때는 자신의 데이터셋과 플랜으로 다시 측정한 값을 함께 적는 것이 필요하다.

이 비교로 확인할 수 없는 것은 무엇일까?

이 점검으로는 "어떤 제품이 더 싸다"는 결론을 확정할 수 없다. 공개 자료가 다루는 조건(데이터 규모, 하드웨어, 가격 시점)이 실제 운영 환경과 다를 가능성이 크기 때문이다.

특히 재색인 비용 중 인건비, 운영 팀의 장애 대응 시간, dual-write 기간의 데이터 정합성 검증 비용은 공개 벤치마크 어디에도 수치로 나오지 않는다. 또한 pgvector 계열에서 임베딩 테이블이 커질 때의 백업 크기 증가나 VACUUM 비용 증가는 검색 결과에서 공통된 실측치가 확인되지 않아, 이 글에서도 구체적 금액을 단정하지 않았다. 즉 이 글은 "무엇을 측정해야 하는가"의 체크리스트까지만 제공하며, "얼마가 드는가"는 각자의 데이터셋·플랜·리전으로 다시 계산해야 하는 영역으로 남는다.

이번 점검에서 남은 질문은 무엇일까?

이번 점검에서 가장 분명해진 것은, 벡터DB 선택 기준에 "백업·복구·재색인 소요 시간"을 별도 항목으로 넣지 않으면 운영 중반에 비용이 급증할 수 있다는 점이다. 반대로 아직 풀리지 않은 질문은 같은 데이터셋으로 여러 제품의 전체 재색인 시간과 복구 후 검색 가능 시점을 동일 조건에서 비교한 공개 자료가 많지 않다는 점이다. 다음 단계로는 중소 규모 데이터셋(예: 100만~500만 벡터)을 기준으로 pgvector, Qdrant 자체 운영, Pinecone Serverless 세 가지를 동일 질의 세트로 백업 생성·복구·재색인 시간까지 직접 측정해 비교표를 만드는 것이 자연스러운 다음 실험이 될 것이다.

핵심 정리

백업·재색인 비용은 스냅샷 저장료 하나가 아니라 이중 저장, 임베딩 재생성, 쓰기 단위, 복구 컴퓨트, 검증 기간을 합친 값으로 봐야 한다.
QPS·Recall 같은 검색 벤치마크 수치를 백업·재색인 비용으로 환산하면 안 되며, 두 지표는 별도 조건에서 측정해야 한다.
관리형 제품은 운영 부담을 줄이지만 RU·WU·전송 단위 청구 구조를 확인해야 하고, 자체 운영 제품은 라이선스는 가볍지만 백업·복구·재색인 인프라를 운영자가 부담한다.
임베딩 모델 교체는 1억 벡터 규모에서 임베딩만 약 $8,000~$15,000의 일회성 비용을 발생시킬 수 있어, 모델 선택을 자주 바꾸지 않는 편이 비용 관리에 유리하다.
모든 공개 수치는 측정일·제품 버전·가격표 시점이 다르므로, 실제 비교에는 자신의 데이터셋으로 재측정한 값을 병기해야 한다.