로컬 인덱스와 관리형 중 무엇을 먼저 봐야 할까?
결론부터: 벡터 수·차원·top-k·필터 사용 여부가 같지 않으면 어떤 수치도 서로 비교할 수 없습니다. 먼저 "우리 RAG의 질의 패턴"을 고정하고, 그 다음에 로컬이냐 관리형이냐를 따지는 순서가 맞습니다. 2026년 기준으로도 이 원칙은 바뀌지 않았습니다.
핵심 정리
- 비교 기준(벡터 수, 차원, top-k, 필터, 동시 질의)을 먼저 고정하지 않으면 공개 벤치마크는 자체 환경에서 재현되지 않습니다.
- PostgreSQL을 이미 쓴다면 pgvector가 인프라 추가 없이 가장 단순한 경로입니다.
- 1,000만 벡터 기준 Milvus self-hosted 약 월 500달러, Pinecone 약 월 1,200달러라는 수치는 운영 인력 비용이 빠진 숫자입니다.
- 지연시간은 p50 하나로 판단하지 말고 p95·p99·recall@k·필터 적용 시 성능을 함께 기록해야 합니다.
- 필터링·하이브리드 검색이 핵심이면 Qdrant·Weaviate, 대규모·GPU 검색이면 Milvus/Zilliz 계열이 후보로 분류됩니다.
흔히 빠지는 함정은 "공개 벤치마크 숫자를 우리 서비스에 그대로 대입하는 것"입니다. 예를 들어 pgvectorscale이 5,000만 벡터·99% recall 조건에서 471 QPS를 기록했다는 결과는 실제 Timescale의 하드웨어·인덱스 설정에서 나온 값입니다. 출처 우리 서비스의 임베딩 차원이 다르고 동시 질의 수가 다르면 같은 QPS가 나온다는 보장이 없습니다. 벤치마크는 "이 정도 규모에서 이런 설정이면 이 정도가 가능하다"는 참고치로만 쓰고, 반드시 자체 데이터로 재검증해야 합니다. 출처
비용 숫자, 그대로 믿어도 될까?
그대로 믿으면 안 됩니다. 공개 비교 자료 하나는 1,000만 벡터 기준 Milvus self-hosted 월 인프라 비용을 약 500달러, Pinecone을 약 1,200달러로 제시했지만, 이 수치에는 클라우드 리전·인스턴스 유형·복제본 수·운영 인력 비용이 빠져 있습니다. 출처 즉 "Milvus가 더 싸다"는 결론만 가져가면 Kubernetes 운영, 모니터링, 장애 대응 인력을 누가 담당할지를 빠뜨리게 됩니다.
반대로 Pinecone Standard는 월 최소 50달러, 저장공간 GB당 월 0.33달러, 쓰기 100만 건당 4달러, 읽기 100만 건당 16달러로 구조화돼 있고, 1,000만 개·1,536차원·월 500만 쿼리 조건에서는 약 월 64~80달러로 추정됩니다. 출처 이 추정치는 쿼리당 실제 읽기 단위, 필터링 패턴, 복제 설정에 따라 쉽게 달라지므로 "관리형은 무조건 비싸다"는 결론으로 바로 이어지지 않습니다. 비용 비교는 단가표가 아니라 우리 쿼리 패턴을 넣은 계산값으로 다시 만들어야 합니다.
지연시간 벤치마크는 왜 방향성으로만 봐야 할까?
같은 "p50 지연시간"이라도 조건이 다르면 숫자가 뒤집힙니다. 한 2026년 비교는 100만 벡터·768차원 조건에서 Qdrant 약 8ms, Weaviate 약 15ms, Pinecone 약 20ms를 제시했습니다. 출처 반면 다른 2025년 비교는 1,000만 벡터 조건에서 Pinecone 5~10ms, Milvus 10~20ms를 제시했는데, 벡터 수·차원·하드웨어가 전혀 다르기 때문에 두 자료를 나란히 놓고 "Qdrant가 더 빠르다"는 식으로 합치면 안 됩니다. 출처
실사용 관점에서는 평균이나 p50 하나만 보지 말고 p95·p99, recall@5·recall@10, 필터 적용 시 성능, 색인·재색인 시간을 함께 기록하는 쪽이 안전합니다. 특히 다중 테넌트 환경에서 tenant_id 필터를 걸었을 때 지연시간이 얼마나 늘어나는지는 공개 벤치마크에 잘 나오지 않는 부분이라 직접 측정이 필요합니다.
어떤 워크로드엔 로컬이, 어떤 워크로드엔 관리형이 맞을까?
워크로드별로 선택 기준이 다릅니다. 개발 초기·소규모 문서 실험이라면 로컬 Qdrant나 Chroma처럼 설치가 간단하고 데이터 이동 없이 임베딩·청킹을 자주 바꿀 수 있는 쪽이 반복 실험에 유리합니다. 출처 이미 PostgreSQL 위에 사용자·권한·메타데이터가 올라가 있다면 pgvector로 벡터 검색을 합쳐 조인과 트랜잭션을 분리하지 않는 편이 구현 복잡도를 줄여줍니다. 출처
| 상황 | 후보 | 근거 |
|---|---|---|
| 기존 Postgres 운영 중 | pgvector | SQL 필터+벡터 통합 |
| 강한 필터·하이브리드 검색 | Qdrant, Weaviate | JSON 필터, BM25 결합 |
| 운영 인력 부족, 트래픽 변동 | Pinecone 등 관리형 | 패치·샤딩 부담 감소 |
| 수천만~수십억 벡터, GPU 검색 | Milvus/Zilliz | 대규모 인덱스 설계 |
운영 인력이 부족하고 트래픽 변동이 크다면 Pinecone 같은 관리형이 초기 비용은 높아도 백업·확장·장애 대응을 직접 설계하지 않아도 되는 점이 핵심 차이입니다. 출처 반대로 수천만~수십억 벡터 규모나 GPU 기반 검색이 필요하면 Milvus/Zilliz 계열이 후보로 분류되지만, self-hosted Milvus는 Kubernetes·스토리지·복제·모니터링 운영 역량을 비용 계산에 포함해야 합니다. 출처
관리형은 늘 더 비싸다는 말, 맞을까?
항상 맞는 말은 아닙니다. 벡터 수가 적고 쿼리량이 많지 않은 초기 단계에서는 Pinecone Standard 월 최소 50달러나 Zilliz Cloud 시작가 월 99달러가 self-hosted 클러스터를 처음부터 구축·운영하는 인건비보다 저렴할 수 있습니다. 출처 반대로 벡터 수가 1,000만 개를 넘고 쿼리량이 커지면, 앞서 본 Milvus 약 500달러 대 Pinecone 약 1,200달러 비교처럼 self-hosted 쪽이 인프라 비용만으로는 저렴해 보이는 구간도 있습니다. 출처
문제는 두 수치 모두 "운영 인력 비용이 빠진 인프라 비용"이라는 점입니다. self-hosted 쪽을 선택하면서 운영 인력 시간을 0으로 두면, 실제로는 장애 대응·업그레이드·백업 검증에 들어가는 시간이 관리형의 사용량 과금을 상쇄하거나 넘어서는 경우가 생깁니다. "로컬이 싸다/관리형이 비싸다"는 단정은 총소유비용(TCO) 계산 없이는 성립하지 않습니다.
전환 전에 무엇을 실측해야 할까?
전환이나 선택을 결정하기 전에 다음을 직접 측정하는 편이 안전합니다. 동일한 임베딩 모델과 동일한 chunk 데이터셋을 쓰고, 질의 세트를 단순 의미 검색·긴 문서·메타데이터 필터·다중 테넌트·하이브리드 검색으로 나눠 각각 recall@5, recall@10, p50/p95/p99 지연시간, 초당 질의 수, 색인 시간, 재색인 시간, 장애 복구 시간을 기록합니다.
벡터DB 단독 정확도보다 중요한 건 검색 결과가 최종 답변에 실제로 기여했는지입니다. context precision, context recall, faithfulness, answer correctness를 분리해 측정하고, 프롬프트에는 검색 결과마다 문서 ID·제목·발행일·권한 범위를 함께 전달한 뒤 "제공된 문맥에 없는 내용은 모른다고 답하라"는 제약을 둬야 합니다. 그래야 로컬·관리형 DB 차이가 검색 품질 문제인지 생성 모델의 환각 문제인지 구분할 수 있습니다. 비용 산정 시에는 저장량과 쓰기·읽기 단위뿐 아니라 운영 인력 시간, 장애 대응 SLA, 리전 복제 비용까지 같이 적어야 나중에 "숫자가 안 맞는다"는 재작업을 피할 수 있습니다.
핵심 정리
- 비교는 벡터 수·차원·top-k·필터·동시 질의·하드웨어를 먼저 고정한 뒤 시작해야 공개 벤치마크를 참고치로 쓸 수 있습니다.
- pgvector는 기존 PostgreSQL 환경에서 인프라 추가 없이 가장 단순한 선택지로 평가됩니다.
- 1,000만 벡터 기준 Milvus 약 월 500달러, Pinecone 약 월 1,200달러 비교는 운영 인력 비용이 빠진 수치임을 기억해야 합니다.
- 지연시간은 p50 하나가 아니라 p95·p99·recall@k·필터 적용 시 성능을 함께 봐야 실사용에 가깝습니다.
- 강한 필터·하이브리드 검색엔 Qdrant·Weaviate, 대규모·GPU 검색엔 Milvus/Zilliz, 운영 부담을 줄이고 싶으면 Pinecone 등 관리형이 각각의 후보입니다.