프로덕션 벡터 DB (Qdrant, Milvus, Weaviate, Pinecone)
벡터 DB를 고르려고 비교표를 열어 보면 기능이 수십 개씩 나옵니다. 검색 속도나 QPS 같은 숫자를 나란히 놓아도 실제 서비스에 무엇을 써야 할지는 쉽게 결정되지 않습니다.
Qdrant, Milvus, Weaviate, Pinecone은 모두 벡터 검색과 메타데이터 기반 필터링을 제공하지만 어떤 문제를 우선해서 해결하도록 설계됐는지는 다릅니다. 직접 운영하기 쉬운가, 대규모 분산 확장이 중요한가, 검색 기능을 하나의 시스템 안에서 얼마나 많이 제공하는가, 인프라 운영을 서비스에 얼마나 맡길 것인가에 따라 선택이 달라집니다.
그래서 벡터 DB는 기능 개수만으로 고르기 어렵습니다. 같은 데이터 규모라도 필터 조건이 많은 서비스와 순수 ANN 검색이 많은 서비스는 요구사항이 다르고, 단일 노드에서 시작하는 경우와 수십억 벡터를 분산 운영하는 경우도 기준이 달라집니다.
각 제품이 어떤 문제를 중심으로 설계됐는지를 하나씩 살펴보고, 마지막에는 기능표가 아니라 데이터 규모, 검색 패턴, 필터링, 운영 방식, 비용이라는 실제 workload 기준으로 선택하는 방법을 정리합니다.
1장. 왜 이 넷인가
공통 문제. 임베딩만으로는 가격이 5만 원 이하인 것 중에서 가장 비슷한 상품을 못 찾습니다. 의미 유사도에 정형 필터와 키워드 검색을 한 번에 얹어야 실전 검색이 됩니다.
Qdrant 공식 문서도 의미 유사도가 유일한 고려 요소인 경우는 드물고 임베딩은 가격 같은 속성을 담지 못한다고 못 박습니다.
벡터 DB가 하는 일. ANN 인덱스와 메타데이터 필터를 한 시스템으로 묶은 저장소입니다. 여기에 CRUD와 영속성, 복제, 백업, 멀티테넌시, 접근 제어, 모니터링 같은 운영 기능이 붙습니다. FAISS 같은 라이브러리와 갈리는 지점이 이 운영 기능입니다.
네 제품의 한 줄 정체.
Qdrant 필터를 그래프 안으로 넣은 Rust 엔진
Milvus 컴퓨트와 스토리지를 분리한 분산 DB
Weaviate 임베딩부터 재순위까지 한 서버에 담은 배터리 포함형
Pinecone 인프라가 안 보이는 완전관리형 SaaS| Qdrant | Milvus | Weaviate | Pinecone | |
|---|---|---|---|---|
| 언어 | Rust | Go | Go | 비공개 |
| 라이선스 | Apache-2.0 | Apache-2.0 | BSD-3-Clause | 독점 SaaS |
| 거버넌스 | Qdrant 사 | LF AI & Data | Weaviate 사 | Pinecone 사 |
| self-host | 가능 | 가능 | 가능 | 불가 |
| 매니지드 | Qdrant Cloud | Zilliz Cloud | Weaviate Cloud | 유일한 형태 |
2장. Qdrant, 필터를 그래프 안으로
다섯 개의 조각.
컬렉션 (collection)
벡터를 담는 최상위 단위
만들 때 벡터 차원 수와 거리 함수를 정한다
포인트 (point)
컬렉션에 저장되는 하나의 레코드
id + vector + payload
payload
벡터에 딸린 구조화 메타데이터
문자열 매치, 숫자 범위, geo 위치 등으로 필터링
HNSW 인덱스
Qdrant 의 ANN 엔진
양자화 (quantization)
벡터를 압축해 RAM 사용량과 검색 비용을 줄이는 선택적 최적화지원 거리는 Cosine, Dot, Euclid, Manhattan 넷이고 희소 벡터는 항상 Dot을 씁니다.
필터를 거는 두 순진한 방법과 그 문제. 선필터는 먼저 조건에 맞는 것만 추린 뒤 그 안에서 벡터 검색을 합니다. 조건이 빡세면 후보가 너무 적어지고 HNSW 그래프의 연결이 끊겨 품질이 무너집니다.
후필터는 벡터로 top-k를 뽑은 뒤 필터로 걸러냅니다. 걸러내고 나면 원하는 개수가 안 남을 수 있어서, top 10을 뽑았는데 조건 통과가 2개뿐인 상황이 생깁니다.
필터러블 HNSW. Qdrant는 payload 인덱스를 HNSW 그래프에 확장해 그래프를 탐색하는 바로 그 순간에 필터 조건을 함께 적용합니다. 공식 문서 표현으로는 payload 인덱스가 HNSW 그래프를 확장해 시맨틱 검색 단계에서 필터링 기준을 적용한다는 것입니다.
별도의 사전과 사후 단계 없이 단일 패스로 비슷하면서 조건도 맞는 이웃을 찾습니다. 강한 필터가 걸리는 워크로드에서 Qdrant가 강한 이유입니다.
현재 Qdrant 문서는 filtered search 품질을 위해 payload index를 데이터 ingest 전에 생성하는 것을 강하게 권장합니다. 그래야 HNSW를 만들 때 filter-aware 추가 edge를 함께 구성할 수 있습니다. Qdrant 1.16부터는 여러 strict filter 조합에서 기본 filterable HNSW의 연결성이 부족할 때 사용할 수 있는 ACORN search도 제공합니다. 직접 이웃이 filter에서 탈락하면 이웃의 이웃까지 더 넓게 탐색해 recall을 보완하는 방식이며, 정확도를 얻는 대신 검색 비용이 늘 수 있습니다.
언제 고르나. 필터가 강하게 걸리는 대규모 시맨틱 검색, 직접 호스팅하고 싶을 때, Apache-2.0이라 상용에 얹기 부담이 적을 때 고릅니다. 완전 무관리 SaaS를 원하거나 기존 SQL에 벡터만 얹고 싶으면 맞지 않습니다.
3장. Milvus, 컴퓨트와 스토리지 분리
배포 스펙트럼이 정체입니다. Milvus는 로컬 프로토타입부터 분산 클러스터까지 같은 API 계열로 확장할 수 있습니다.
| 배포 형태 | 성격 | 언제 |
|---|---|---|
| Milvus Lite | 애플리케이션에 임베드하는 경량 형태 | 프로토타입, 노트북, 소규모 로컬 |
| Standalone | 단일 서버 배포 | 중소 규모 프로덕션 |
| Distributed | 여러 worker를 독립 확장하는 클러스터 | 대규모 데이터와 높은 동시성 |
핵심 설계는 storage와 compute의 분리입니다. 데이터는 공유 storage에 두고 query와 ingest/compaction 같은 worker를 독립적으로 확장합니다.
현재 Milvus 2.6의 아키텍처는 네 층으로 설명됩니다.
접근 계층
Stateless Proxy
요청 검증, 라우팅, 결과 축약
Coordinator
클러스터 토폴로지, DDL/DCL, 스케줄링
Query/Streaming/Data worker 관리
Worker Nodes
Streaming Node WAL 기반 실시간 ingest와 growing data query
Query Node sealed/historical segment 검색
Data Node compaction과 index build 같은 offline 처리
Storage
etcd metadata
object storage segment와 index 파일
WAL storage write ordering과 recovery2.6에서 중요한 변화가 Streaming Node의 GA입니다. 이전 버전 설명처럼 Proxy가 WAL에 쓰고 QueryNode/DataNode가 stream을 각각 읽는 구조만 기억하면 현재 구조를 놓칩니다. Streaming Node가 shard 단위 WAL read/write와 growing data 처리를 맡고 Query Node가 historical data 검색을 담당합니다.
WAL 의존성도 버전별로 봐야 합니다. 과거 distributed 배포 설명에서는 Pulsar/Kafka 같은 외부 message broker가 핵심 의존성이었습니다. Milvus 2.6에서는 Woodpecker가 optional WAL로 추가됐고, object storage를 활용해 외부 broker 운영 부담을 줄일 수 있습니다. 따라서 Milvus = 항상 etcd + object storage + Pulsar/Kafka라고 고정해서 설명하면 최신 배포 형태를 놓칩니다. 실제 구성은 버전과 mq.type에 따라 확인해야 합니다.
검색 기능. Milvus는 HNSW, IVF 계열, DiskANN, GPU CAGRA 등 다양한 index를 제공하고 dense/sparse/hybrid search와 BM25 계열 검색을 지원합니다. 또 Strong, Bounded, Eventually, Session 네 consistency level을 제공하며 현재 기본은 Bounded입니다.
언제 고르나. 데이터와 QPS가 크고 수평 확장이 중요할 때, index와 GPU 옵션을 세밀하게 선택하고 싶을 때, 분산 인프라 운영 역량이 있을 때 강합니다. 반대로 작은 서비스에서 단순한 운영이 최우선이면 Distributed 구성은 과할 수 있습니다.
4장. Weaviate, 배터리 포함형
벡터 검색 시스템을 직접 짜려면 조각이 여러 개입니다. 임베딩을 만드는 추론 서버, 벡터를 저장하고 검색하는 인덱스, 키워드 검색용 전문검색 엔진, 그 결과를 합치는 융합 로직입니다.
이것을 각각 붙이면 운영 지점이 늘고 임베딩 모델을 바꿀 때마다 여러 곳을 고쳐야 합니다. Weaviate의 존재 이유는 이 조각들을 하나의 서버로 합친 것입니다.
부품.
컬렉션과 스키마
데이터를 담는 구조화된 컨테이너
속성과 인덱싱과 벡터화 방식을 정의한다
vectorizer 모듈
텍스트를 벡터로 바꿔주는 내장 모듈
text2vec-openai, text2vec-cohere, text2vec-ollama 등
이미 만든 벡터를 넣는 self_provided 도 지원
벡터 인덱스
기본은 HNSW
소규모용 flat, 자동 전환하는 dynamic 도 있다
역인덱스
BM25 키워드 검색과 정형 필터링용
API 3 종
REST, gRPC, GraphQLvectorizer가 막는 흔한 사고. 임베딩이 DB 안에 있어서 데이터를 넣을 때와 검색할 때의 임베딩이 같은 설정으로 자동 처리됩니다.
그래서 임포트 때 쓴 모델과 쿼리 때 쓴 모델이 달라서 검색이 이상해지는 사고가 구조적으로 줄어듭니다. RAG 시스템에서 의외로 자주 나는 사고이고, 모델을 업그레이드했는데 기존 인덱스를 재생성 안 한 경우가 대표적입니다.
하이브리드가 네이티브입니다. 벡터 검색과 BM25를 각각 다른 시스템에서 돌린 뒤 애플리케이션에서 합치는 대신, 한 질의로 둘을 실행하고 서버가 융합해 돌려줍니다. alpha 하나로 가중을 조절합니다. 현재 서버의 alpha 기본값은 0.75지만, client/server 버전에 따라 unset 값을 실제로 전달하는 방식이 달라질 수 있습니다. 검색 가중이 중요하면 기본값에 기대지 말고 alpha를 명시적으로 지정하는 편이 안전합니다.
언제 고르나. 운영 지점을 줄이고 싶을 때, 임베딩 관리를 DB에 맡기고 싶을 때, Hybrid Search와 재순위를 한 인터페이스로 쓰고 싶을 때 고릅니다. 임베딩 파이프라인을 직접 통제하고 싶거나 초대규모 분산이 필요하면 맞지 않습니다.
5장. Pinecone, 운영을 안 한다
무엇이 상품인가. 벡터 DB를 직접 운영하는 순간 일이 커집니다. 노드를 몇 대 둘지, 언제 샤딩하고 복제할지, 인덱스가 커지면 어떻게 리밸런싱할지, 장애가 나면 어떻게 페일오버할지, 백업과 업그레이드는 누가 할지, 트래픽이 튈 때 스케일을 누가 판단할지가 전부 일입니다.
Pinecone의 존재 이유는 이 운영 부담을 통째로 벤더에게 넘기는 것입니다. 코드에서 다루는 추상화는 인덱스에 데이터를 올리는 것과 질의하는 것 딱 두 가지이고 그 아래 클러스터는 보이지 않습니다.
자체 구축 벡터 DB가 서버를 사서 직접 운영하는 자가발전기라면 Pinecone은 콘센트에 꽂아 쓰는 전기입니다. 전압과 발전량을 신경 쓸 필요 없이 필요한 만큼 뽑아 쓰는 대신, 발전소 내부는 들여다볼 수 없고 쓴 만큼 요금을 냅니다.
계층. 인덱스 안에 네임스페이스가 있고 그 안에 레코드가 들어갑니다.
인덱스는 벡터 데이터를 담는 최상위 컨테이너이고, 네임스페이스는 인덱스 내부를 논리적으로 나누는 파티션입니다. 일반적인 upsert와 query는 특정 namespace를 대상으로 하며, namespace는 별도 생성 API 없이 데이터 upsert 과정에서 만들어질 수 있습니다. 여러 namespace를 가로지르는 검색이 필요하면 사용하는 API의 지원 방식과 비용을 별도로 확인해야 합니다.
네임스페이스의 이득은 둘입니다. 고객마다 하나씩 배정해 데이터를 격리하는 멀티테넌시, 그리고 질의가 관련 네임스페이스만 스캔해 빨라지는 성능입니다.
검색 형태. Pinecone은 dense vector 검색뿐 아니라 sparse retrieval과 metadata filtering, integrated inference를 managed API로 제공합니다. 다만 내부 index 구조나 ANN 구현을 self-host 제품처럼 직접 선택하는 방식은 아닙니다. 사용자는 index, namespace, record, metadata 같은 상위 추상화를 주로 다룹니다.
언제 고르나. 무관리 확장과 안정적 운영이 인프라 튜닝 자유도보다 중요할 때, 팀에 인프라 인력이 없을 때, 트래픽 변동이 커서 자동 확장이 필요할 때 고릅니다.
self-host가 필요하거나 오픈소스여야 하거나 세밀한 튜닝이 필요하거나 비용 통제가 중요하거나 데이터를 밖으로 못 보내면 맞지 않습니다.
주의. 내부 ANN 알고리즘과 정확한 가격, SLA 수치는 공개 문서만으로 단정하기 어렵습니다. 구조와 API는 공식 문서로 확인되지만 금액과 SLA는 반드시 공식 pricing 페이지에서 확인합니다.
6장. 축별 비교
| 축 | Qdrant | Milvus | Weaviate | Pinecone |
|---|---|---|---|---|
| 대표 설계 | filterable HNSW / ACORN | storage-compute 분리 | integrated retrieval stack | 완전관리형 service |
| 인덱스 제어 | HNSW와 quantization 중심 | HNSW, IVF, DiskANN, GPU CAGRA 등 선택 폭 큼 | HNSW/flat/dynamic과 compression | 내부 ANN 세부는 관리형 추상화 |
| 임베딩 생성 | 외부 중심, inference 기능도 선택 가능 | 외부 중심 | vectorizer 내장 가능 | integrated inference 가능 |
| 하이브리드 | dense/sparse query 구성 | dense/sparse/BM25 계열 | BM25F + vector fusion, alpha |
dense/sparse 검색 기능 |
| self-host | 가능 | 가능 | 가능 | 불가 |
| 운영 성격 | 비교적 단순한 self-host 가능 | Distributed는 가장 복잡 | 검색 기능을 한 제품에 많이 통합 | 인프라 운영을 서비스에 위임 |
무엇이 진짜 차이인가. 이제 네 제품 모두 필터와 하이브리드 기능을 상당 부분 제공하므로 체크박스만으로는 잘 갈리지 않습니다. 차이는 필터와 ANN을 결합하는 방식, 분산 구조, 검색 파이프라인을 DB 안에 넣는 범위, 사용자가 직접 운영할 수 있는 영역에서 나타납니다.
7장. 공통 개념
ANN index는 제품마다 선택 폭이 다릅니다. Qdrant와 Weaviate는 HNSW가 핵심이고 Milvus는 HNSW뿐 아니라 IVF, DiskANN, GPU CAGRA 등 여러 index를 선택할 수 있습니다. Pinecone은 내부 ANN 세부 구현을 제품 사용자가 직접 튜닝하는 방식이 아닙니다. 따라서 "넷 다 HNSW이니 튜닝도 같다"고 묶으면 제품 차이를 놓칩니다.
양자화. self-host 제품들은 vector를 압축해 RAM과 storage 사용량을 줄이는 여러 방식을 제공합니다. Qdrant의 scalar/product/binary quantization, Milvus의 SQ/PQ 계열 index, Weaviate의 PQ/BQ/SQ처럼 이름과 적용 지점이 다릅니다. 공통 trade-off는 메모리·비용을 줄이는 대신 recall이나 재랭킹 비용을 조정해야 한다는 점입니다.
Hybrid Search. dense semantic retrieval과 sparse/BM25 계열 lexical retrieval을 합칩니다. 고유명사, 제품번호, 코드처럼 exact match가 중요한 질의는 lexical signal이 semantic search를 보완합니다. 다만 fusion 방식은 제품마다 다르므로 hybrid 지원이라는 체크박스 하나만 보고 같은 동작이라고 생각하면 안 됩니다.
멀티테넌시. Qdrant는 payload/filter와 shard 설계, Milvus는 database/partition과 권한 구조, Weaviate는 내장 multi-tenancy, Pinecone은 namespace를 주로 활용합니다. 고객별 데이터 격리와 filter selectivity가 검색 성능에 직접 영향을 줄 수 있으므로 실제 tenant 수로 테스트해야 합니다.
8장. 고르는 법
제품 이름보다 먼저 요구사항을 고정합니다.
① self-host가 필수인가
예 Qdrant / Milvus / Weaviate 중심으로 비교
아니오 Pinecone 포함
② strict metadata filter가 핵심인가
filter가 걸린 상태의 recall / latency를 따로 벤치
Qdrant의 filterable HNSW와 ACORN 같은 설계를 확인
③ 대규모 수평 확장과 index 선택 폭이 핵심인가
Milvus 같은 분리형 분산 구조를 검토
④ embedding / BM25 / rerank를 한 제품에 묶고 싶은가
Weaviate의 integrated retrieval stack을 검토
⑤ 인프라 운영 자체를 넘기고 싶은가
Pinecone 같은 managed service를 검토수억 벡터면 무조건 Milvus, 필터면 무조건 Qdrant 같은 고정 임계값은 위험합니다. 벡터 차원, filter selectivity, update rate, QPS, replica 수, hardware에 따라 결과가 달라집니다.
이 넷을 안 써도 되는 경우. 이미 PostgreSQL을 안정적으로 운영하고 규모가 크지 않다면 pgvector가 더 단순할 수 있습니다. 프로토타입이나 로컬 개발에서는 Milvus Lite나 Chroma 같은 경량 선택지가 편할 수 있고, 순수 인메모리 ANN 성능만 필요하며 운영 기능이 필요 없다면 FAISS가 맞을 수 있습니다.
벡터 DB를 하나 추가한다는 것은 검색 기능뿐 아니라 백업, 업그레이드, 모니터링, 장애 대응 대상이 하나 늘어난다는 뜻입니다.
평가할 때. 자기 데이터로 같은 embedding과 동일한 품질 목표를 놓고 다음을 같이 봅니다.
- recall@k / nDCG
- p50 / p95 / p99 latency
- QPS와 ingest/update throughput
- 실제 RAM / disk 사용량
- filter 없는 검색과 strict filter 검색
- tenant 수가 늘 때의 성능
- index build/rebuild 시간과 failover
- managed 제품이면 실제 cloud cost
특히 filter가 있는 상태의 recall과 tail latency는 제품의 filter/index 결합 방식 차이가 잘 드러나는 지점입니다.
9장. 정리
넷 다 벡터 검색과 필터를 제공하지만 설계 철학이 다릅니다. 기능 목록이 아니라 철학으로 골라야 합니다.
Qdrant는 filtered retrieval을 HNSW와 깊게 결합하고, Milvus는 분리형 분산 구조와 index 선택 폭이 강점입니다. Weaviate는 embedding·BM25·rerank 같은 retrieval 기능을 한 제품 안에 많이 넣고, Pinecone은 인프라 운영을 managed service로 넘기는 선택입니다.
제품 비교에서는 filter가 걸린 상태의 recall과 tail latency, ingest/update 비용, 실제 운영 복잡도를 함께 재야 합니다.
어느 제품이 절대적으로 좋으냐보다 우리 팀이 어떤 운영 책임을 직접 가져갈지를 먼저 정하는 편이 빠릅니다. 운영을 맡길지, embedding lifecycle을 DB에 넣을지, 분산 index를 직접 튜닝할지의 답이 제품 선택을 좁혀 줍니다.
용어 정리
| 용어 | 한 줄 뜻 |
|---|---|
| 벡터 DB | ANN 인덱스와 메타데이터 필터를 운영 기능과 함께 묶은 저장소 |
| payload | Qdrant에서 벡터에 딸린 구조화 메타데이터 |
| 필터러블 HNSW | 그래프 탐색 중에 필터 조건을 함께 적용하는 Qdrant의 기법 |
| 선필터 / 후필터 | 벡터 검색 전에 거르기 / 후에 거르기. 둘 다 약점이 있음 |
| 컴퓨트와 스토리지 분리 | 계산 노드와 저장소를 떼어 각각 독립 확장하는 Milvus 구조 |
| 무상태 노드 | 상태를 안 들고 있어 즉시 교체 가능한 워커. K8s와 잘 맞음 |
| vectorizer 모듈 | 넣을 때와 검색할 때 임베딩을 자동 생성하는 Weaviate 내장 모듈 |
| alpha | Weaviate Hybrid Search에서 벡터와 키워드의 가중을 조절하는 값 |
| 네임스페이스 | Pinecone 인덱스 내부를 나누는 파티션. 멀티테넌시와 성능에 쓰임 |
| dense / sparse 벡터 | 의미를 담는 밀집 벡터 / 키워드를 담는 희소 벡터 |
| 서버리스 | 저장과 연산을 분리해 쓰는 만큼 자동 확장되는 운영 모델 |
| 일관성 레벨 | 쓰기가 읽기에 언제 반영되는지의 강도. Milvus는 4단계 제공 |
참고자료
- Qdrant 공식 문서
- Qdrant Indexing / Filterable HNSW / ACORN
- qdrant/qdrant GitHub (Rust, Apache-2.0)
- Milvus 공식 문서
- Milvus 2.6 Architecture Overview
- Milvus 2.6 Woodpecker WAL
- milvus-io/milvus GitHub (Go, Apache-2.0, LF AI & Data)
- Weaviate 공식 문서
- weaviate/weaviate GitHub (Go, BSD-3-Clause)
- Pinecone 공식 문서
- Efficient and robust approximate nearest neighbor search using HNSW (arXiv 1603.09320)
'RAG > Retrieval' 카테고리의 다른 글
| Reranking (0) | 2025.11.12 |
|---|---|
| HNSW(Hierarchical Navigable Small World) (0) | 2025.01.06 |
| Chunking(청킹) 이란? (0) | 2024.11.01 |
| Hybrid search (0) | 2024.09.25 |
댓글