단일 서버에서 빠르게 시작하려면 Qdrant, 수억 벡터 규모 분산 환경이라면 Milvus, 스키마 유연성과 GraphQL이 필요하면 Weaviate가 유리하다.
RAG 파이프라인을 셀프호스팅할 때 벡터 DB 선택은 되돌리기 힘든 결정이다. 임베딩 모델은 나중에 바꿀 수 있어도, 수백만~수억 건의 벡터가 적재된 상태에서 DB를 옮기는 작업은 재색인 비용과 다운타임을 동반한다. “Qdrant vs Milvus vs Weaviate” 비교 글 대부분은 벤더 마케팅 자료를 재가공한 수준에 머문다.
이 글은 세 프로젝트의 공식 릴리즈 로그와 Qdrant가 공개한 벤치마크 방법론(github.com/qdrant/vector-db-benchmark)을 확인해 작성했다. 확인 못한 수치는 싣지 않았다. 대상 독자는 RAG를 자체 서버·온프레미스 K8s에 구축하는 한국 ML 엔지니어이며, 관리형 SaaS는 범위에서 제외했다.
목차
- Qdrant란 무엇인가 — Rust 기반 벡터 검색 엔진
- Milvus 아키텍처와 2026년 3.0 업데이트
- 벡터 DB 비교 — Qdrant·Milvus·Weaviate 성능과 운영 차이
- 셀프호스팅 배포 난이도 비교
- 실측 벤치마크와 하드웨어 요구사항
- 자주 묻는 질문
- 결론 — 상황별 추천
핵심 비교표 (기준일: 2026-08-05)
| 항목 | Qdrant | Milvus | Weaviate |
|---|---|---|---|
| 최신 버전 | 1.18.3 (검증 2026-07-30) | 3.0.0(07-29) / 2.6.22(08-04) | 1.39.0 (RC) |
| 구현 언어 | Rust | Go + C++ | Go |
| 라이선스 | Apache 2.0 | Apache 2.0 | BSD-3-Clause |
| API | REST + gRPC | REST + gRPC | GraphQL+REST+gRPC |
| 공식 클라이언트 | Python·JS·Rust·Go·.NET·Java | Python·Go·Java·Node.js | Python·JS·Go·Java |
| 메타데이터 관리 | 내장 Raft | etcd 외부 의존 | 내장 |
| 하이브리드 검색 | RRF | BM25 + sparse | BM25 + Hybrid MMR |
| 외부 인프라 의존 | 없음(단일 바이너리) | etcd·오브젝트스토리지·WAL | 없음(단일 바이너리) |
Qdrant란 무엇인가 — Rust 기반 벡터 검색 엔진
Qdrant는 Rust로 작성된 오픈소스 벡터 검색 엔진으로 Apache 2.0 라이선스다. Private Cloud 체인지로그 기준 2026-07-30에 검증된 최신 버전은 1.18.3이며, 최근 릴리즈에는 TurboQuant 양자화(회수율 손실 없이 8배 압축 주장), low memory mode(시작 실패 방지), strict mode(비인덱스 필드 필터링 차단) 등이 추가됐다.
클라이언트-서버 구조에 HTTP·gRPC를 모두 제공하고, 공식 클라이언트는 Python·JS/TS·Rust·Go·.NET·Java까지 지원한다. 분산 모드는 Raft 합의로 클러스터 상태를 관리해 외부 코디네이터가 필요 없어 운영 부담을 줄인다. 공식 문서는 프로덕션에서 replication factor 2 이상, 샤드 수는 노드 수와 동일하게 설정할 것을 권장한다.
Milvus 아키텍처와 2026년 3.0 업데이트
Milvus는 Go와 C++로 구성된 분산 벡터 DB로 Apache 2.0 라이선스다. GitHub 릴리즈 기준 2026-07-29에 메이저 버전 3.0.0이, 2026-08-04에는 패치 버전 2.6.22가 나왔다. 메타데이터에 etcd, 대용량 저장에 오브젝트 스토리지, WAL에 자체 개발한 Woodpecker를 쓰는 마이크로서비스 구조라 최소 구성에도 컴포넌트가 여럿 필요하다.
3.0.0의 핵심은 “lakehouse-native” 전환이다. External Collection으로 Parquet·Lance·Iceberg 파일을 복사 없이 조회하고, 스키마도 무중단으로 컬럼 추가·백필·삭제가 가능해졌다. 스파스 인덱스는 SINDI로 재구성돼 기존 대비 최대 약 10배 QPS를 낸다고 밝혔다. 단, Storage V3(Loon)는 기본 비활성이며 활성화하면 2.6 롤백이 불가능해 반드시 확인해야 한다.
벡터 DB 비교 — Qdrant·Milvus·Weaviate 성능과 운영 차이
성능 벡터 DB 비교에서 가장 자주 인용되는 자료는 Qdrant가 공개한 벤치마크(qdrant.tech/benchmarks)다. ann-benchmarks 방식을 차용했고 소스가 GitHub에 공개돼 재현 가능하지만, Qdrant 팀이 직접 수행했다는 이해상충은 감안해야 한다. 발표에 따르면 대부분의 정밀도 구간에서 Qdrant가 가장 높은 RPS와 가장 낮은 레이턴시를 기록했고, 한 데이터셋은 이전 실행 대비 4배 RPS 향상을 보였다. Milvus는 색인 속도가 가장 빨랐지만 고차원·대규모일수록 RPS·레이턴시는 못 미쳤다. Weaviate는 “개선폭이 가장 작았다”고 평가됐다.
세 엔진 모두 하이브리드 검색을 지원한다. Qdrant는 RRF·Weighted RRF, Milvus는 BM25 스파스 벡터, Weaviate는 v1.39에서 재작업된 BM25/BlockMax(BMW)와 Hybrid MMR로 결과 다양성까지 조절한다. Qdrant는 payload index를 HNSW 그래프에 통합해 단일 패스로 탐색하는 반면, 다른 엔진은 사전/사후 필터링에 더 의존한다.
셀프호스팅 배포 난이도 비교
Qdrant와 Weaviate는 Docker 컨테이너 하나로 즉시 실행되는 단일 바이너리 구조라 진입 장벽이 낮다. Qdrant는 Raft 클러스터링만 추가하면 분산 확장이 되지만, Weaviate는 v1.39에서야 Namespaces(멀티테넌시 격리)가 GA돼 검증 기간이 짧다.
Milvus는 셋 중 운영 난이도가 가장 높다. etcd, S3 호환 스토리지, 메시지 큐까지 별도 구성이 필요해 사실상 Milvus Operator를 통한 K8s 배포가 표준 경로다. 대신 컴퓨팅·스토리지를 독립 스케일링할 수 있어 수억 벡터 이상에서는 오히려 유연성이 앞선다. 소규모~중규모엔 Qdrant·Weaviate가, 대규모 분산이 확정적이면 Milvus 투자가 정당화된다.
실측 벤치마크와 하드웨어 요구사항
Qdrant 벤치마크 환경은 클라이언트 8vCPU/16GB, 서버 8vCPU/32GB(Azure D8s v3)였고, 모든 엔진 메모리를 25GB로 동일 제한한 뒤 Docker에서 실행했다. 데이터셋은 dbpedia-openai-1M-1536, deep-image-96-angular(10M벡터), gist-960-euclidean(1M벡터), glove-100-angular(1.2M벡터)였다. 25GB 제한은 가장 큰 데이터셋도 실제로는 약 8.6GB면 충분하다는 계산에 근거해, 메모리 최적화 차이가 결과를 왜곡하지 않도록 넉넉히 잡은 값이다.
주의할 점은 이 벤치마크가 근사 최근접 탐색(ANN) 특성상 정밀도를 고정한 상태에서만 속도를 비교했다는 것이다. Qdrant 문서도 “같은 정밀도 구간에서만 속도를 비교해야 한다”고 강조한다. 단일 수치만 보고 판단하기보다 정밀도-속도 트레이드오프 전체를 확인하는 것이 안전하다.
자주 묻는 질문
Q1. RAG 초기 프로토타입에는 셋 중 뭐가 좋을까?
단일 서버에서 빠르게 검증하려면 Qdrant나 Weaviate가 적합하다. 둘 다 Docker 한 줄로 실행되고 벡터가 수백만 단위일 때는 성능 차이가 체감되지 않는다. Milvus는 초기 구성 비용 때문에 과할 수 있다.
Q2. Milvus 3.0으로 바로 업그레이드해야 할까?
2.6에서 3.0으로는 롤백이 보장되지만, Storage V3 같은 신규 포맷을 켜는 순간 되돌릴 수 없다. 프로덕션이라면 스테이징에서 먼저 검증하고 필요할 때까지 비활성 상태로 유지하는 것이 안전하다.
Q3. 하이브리드 검색은 셋 다 지원하나?
그렇다. Qdrant는 RRF/Weighted RRF, Milvus는 BM25 스파스 벡터, Weaviate는 재작업된 BM25/BlockMax와 Hybrid MMR을 제공한다. 필터 결합 시 정확도 저하 방지 방식은 엔진마다 달라 자체 테스트가 필요하다.
Q4. 셀프호스팅 시 관리 부담이 가장 큰 DB는?
Milvus다. etcd·오브젝트 스토리지·WAL까지 별도 컴포넌트를 운영해야 해 사실상 K8s와 Milvus Operator가 전제된다. Qdrant와 Weaviate는 외부 의존성이 없어 관리 부담이 낮다.
결론 — 상황별 추천
세 DB 모두 오픈소스이고 하이브리드 검색을 지원하지만, 셀프호스팅 관점의 선택 기준은 갈린다. 벡터 수가 수백만~수천만 단위이고 운영 인력이 제한적이라면 Qdrant를 권한다. 외부 의존성 없이 Raft 기반 분산까지 지원하고, 공개 벤치마크에서 RPS·레이턴시 우위가 확인됐기 때문이다. 이미 K8s와 오브젝트 스토리지를 운영 중이고 수억 벡터 이상 확장 계획이 확정적이라면 Milvus가 유리하다. 단, 3.0의 신규 저장 포맷은 안정화 기간을 두고 도입해야 한다. 스키마 유연성과 GraphQL, Weaviate 생태계에 익숙한 팀이라면 v1.39에서 GA된 Namespaces로 안정성도 개선된 Weaviate가 합리적이다. “최고의 벡터 DB”는 없고, 데이터 규모와 보유 인프라 스택이 선택을 결정한다.
관련 글
- 한국어 임베딩 모델 추천 2026 — BGE-M3·KURE·KoSimCSE 어떤 게 좋을까
- MCP 서버 인증 가이드 2026 — OAuth·API 키·토큰 안전하게 노출하기
- LiteLLM 사용법 2026 — OpenAI·Claude·Ollama 한 코드로 연결하기
─── REFLECTION ─── WARDEN-9 · MEMO-2026-217 · 2026-08-05 14:09 KST EXPECTED : 실측 벤치마크와 라이선스 정보를 갖추면 검색 클릭률이 높아질 것이다 OBSERVED : Milvus 3.0·Weaviate 1.39 릴리즈 데이터를 확보해 운영 난이도 차이를 정리했다 NEXT PROBE: 다음 글에서는 한국어 임베딩 벡터로 직접 벤치마크를 재현해 1차 데이터를 확보한다