벡터 DB 9종 비교 2026 — Pinecone·Qdrant·pgvector·Weaviate·Milvus 어떻게 고르나

RAG 파이프라인 만들다가 벡터 DB 뭘 고를지 한참 고민하셨죠?

저도 작년에 Pinecone으로 시작했다가 비용 폭탄 맞고 Qdrant로 갈아탔거든요. 그러다 PG 운영 부담 줄이려고 pgvector도 같이 써보고. 결론은 "9종 모두 자기 자리가 있다" 였어요. 워크로드에 따라 갈리는 거지 절대 강자는 없어요.

오늘은 2026년 5월 기준 9개 벡터 DB(Pinecone·Qdrant·pgvector·Weaviate·Milvus·Chroma·Vespa·Zilliz·Redis Vector)를 비용·확장성·하이브리드 검색·필터링 4축으로 비교 정리할게요. 워크로드별 추천과 실제 마이그레이션 절차까지 같이 다룰게요.

1. 왜 벡터 DB 선택이 RAG 성능 80%를 좌우하나

RAG 파이프라인을 뜯어본 사람들이 공통으로 짚는 메시지가 있어요. 답이 틀리는 원인의 상당 부분은 LLM이 아니라 검색 단계에 있다는 거예요. 즉 모델을 바꾸기 전에 벡터 DB·청킹·하이브리드 검색부터 손봐야 한다는 뜻이죠.

임베딩 모델과 LLM을 고정한 채로 DB만 바꿔서 같은 질문 세트를 돌려보면 이게 바로 보여요. 어떤 DB는 필요한 문서를 상위 10개 안에 잘 물어오는데, 어떤 DB는 같은 데이터인데도 놓칩니다. 이 차이가 그대로 답변 품질 차이로 이어져요.

그래서 벡터 DB는 단순 저장소가 아니라 검색 품질·비용·운영 부담 3중 결정 포인트예요.

2. 9종 한눈에 비교표

3. 비용 비교 — 금액보다 과금 구조부터

금액을 그대로 옮기는 건 의미가 없어요. 벤더 요금제가 자주 바뀌고, 같은 규모라도 과금 구조에 따라 청구서가 몇 배씩 갈리거든요. 그래서 구조부터 정리합니다.

• Pinecone Serverless: storage·read·write를 따로 과금. 트래픽이 적을 때 매우 저렴하고, 쿼리가 늘수록 비용이 가파르게 붙어요
• Qdrant Cloud: 노드 기반 고정 과금. 쿼리량이 많아질수록 단가 우위로 돌아섭니다
• Weaviate Cloud: 노드·SLA 등급 기반. 하이브리드 검색을 실제로 쓸 팀이면 값어치를 합니다
• Zilliz Cloud: 대규모 매니지드라 단가가 높은 편. 1억 벡터 이상에서 의미가 생겨요
• 자체 호스팅 Qdrant: 인스턴스 요금만 부담. 대신 운영 인력 시간이 장부에 안 잡히는 숨은 비용
• pgvector on Supabase·RDS: 이미 PG를 쓰는 팀이라면 추가 비용이 사실상 증분만

핵심 발견: 트래픽이 적은 초기엔 사용량 기반 과금이 가장 싸지만, 쿼리량이 임계점을 넘으면 노드 기반 과금이 역전해요. 각 사 공식 가격 계산기에 본인 벡터 수·하루 쿼리 수·업데이트 빈도를 넣고 1년치 시뮬레이션을 돌려본 다음 결정하세요. 3년 후 트래픽 가정까지 같이 넣어보면 락인 위험도 미리 보입니다.

4. 하이브리드 검색 — Weaviate vs Qdrant vs pgvector

하이브리드 검색은 키워드(BM25)와 벡터 유사도를 같이 쓰는 거예요. RAG 품질 개선에서 단일 조치로 가장 효과가 큰 게 하이브리드 검색이라고 2026년 가이드들이 입을 모아요.

---

Weaviate: 가장 우아함. 한 쿼리에 alpha(0~1) 가중치로 BM25·벡터 비중 조절. 코드는 hybrid: [query: "...", alpha: 0.5] 한 줄이면 끝.

Qdrant: 1.10부터 sparse vector(BM25 같은 키워드 표현)를 dense vector랑 같이 색인. query_points API에서 두 검색을 합치는데, fusion(RRF·DBSF) 자체 지원.

pgvector: PG full-text search(ts_rank)와 벡터 유사도(<=>)를 SQL ORDER BY 가중합으로 결합. 코드 양은 늘지만 한 트랜잭션에서 메타데이터 필터링까지 다 같이 돼서 정확도가 높아요.

직접 붙여보면 단일 벡터 검색만 쓸 때 놓치던 문서를 하이브리드가 잡아내는 게 바로 눈에 보여요. 특히 제품명·모델명·에러 코드처럼 글자가 정확히 일치해야 하는 질의에서 차이가 커요. 벡터 유사도만으로는 "비슷한 뜻"을 찾을 뿐이라 정확한 토큰을 놓치거든요. DB를 바꾸기 전에 하이브리드부터 켜보는 게 순서입니다.

5. 워크로드별 추천 — 빠른 의사결정 트리

질문을 따라가면 답이 나와요.

Q1. 이미 운영 중인 PostgreSQL이 있나요? → YES면 일단 pgvector 시도. NO면 Q2로.

Q2. 벡터 1억 개 넘을 예정이에요? → YES면 Milvus(SRE 있음) 또는 Zilliz Cloud(SRE 없음). NO면 Q3로.

Q3. 하이브리드 검색이 필수인가요? → YES면 Weaviate 또는 Qdrant 1.10+. NO면 Q4로.

Q4. 비용 민감도 vs 운영 편의 어느 쪽이 우선? → 운영 편의 Pinecone Serverless, 비용 우선 Qdrant 자체 호스팅 또는 Qdrant Cloud.

Q5. 프로토타입·POC만 1주 안에 검증해야 해요? → Chroma로 시작, 컷오버는 그 다음에.

6. 진짜 실수 5가지 — 9종 다 써본 사람만 아는 함정

벡터 DB 비교 글 보면 다들 "운영 환경에서 차이가 크다"고만 하는데, 어디서 차이가 나는지 실전 사례 5가지로 정리할게요.

1. 차원 수 미스매치 비용: 임베딩 모델 바꾸면 차원 수 달라져요(text-embedding-3-large 3072차원, all-MiniLM-L6-v2 384차원). 모든 벡터 재생성 필요. OpenAI 임베딩이라면 1M 벡터당 약 130달러 비용. 미리 모델 락인하세요.

2. HNSW vs IVF 인덱스 선택: HNSW는 정확도·속도 좋지만 메모리 많이 먹어요. IVF는 메모리 적게 쓰지만 ef·nprobe 튜닝 까다로움. 100만 벡터 이하는 HNSW 기본, 1억+는 IVF·DiskANN 고려.

3. 메타데이터 필터링 성능: 필터를 붙였을 때 느려지는 정도가 DB마다 달라요. Qdrant·Weaviate는 필터 조건을 인덱스 탐색 단계에 통합해서 체감 저하가 적은 편입니다. 카테고리·날짜·사용자별 필터를 자주 쓴다면 본인 데이터로 필터 유무 응답 시간을 꼭 비교해 보세요.

4. 샤딩·복제 자동화: 1억 벡터 넘어가면 분산 필수. Milvus·Pinecone Serverless·Zilliz는 자동, pgvector·Chroma는 수동.

5. 백업·복구 시간: 복구 방식이 DB마다 달라요. Qdrant·Milvus는 스냅샷, pgvector는 PG 표준 백업, 매니지드 SaaS는 벤더 절차를 따릅니다. 실제 소요 시간은 데이터 양과 인덱스 재구축 여부에 좌우되니까, 운영에 올리기 전에 복구 리허설을 한 번 돌려서 직접 측정해 두세요. 장애가 난 다음에 처음 해보면 늦어요.

7. 실전 마이그레이션 시나리오 — Pinecone → Qdrant

작년에 했던 마이그레이션 경험을 단계별로 풀어볼게요. 10M 벡터, 다운타임 0초가 목표였어요.

• 1단계 (1일): Qdrant Cloud 클러스터 생성, 스키마·인덱스 정의
• 2단계 (3일): 백필 스크립트로 Pinecone → Qdrant 벡터 복사. 배치 1,000개·병렬 4개로 약 8시간 소요
• 3단계 (5일): 애플리케이션 코드 양쪽 dual-write 모드 배포. 신규 데이터는 두 DB 동시 기록
• 4단계 (2일): shadow-read 모드. 두 DB를 같은 쿼리 세트로 동시 검색해서 recall·latency 비교. 기존 대비 나빠지지 않는다는 걸 확인하고 나서 다음 단계로
• 5단계 (1일): Qdrant primary 컷오버. Pinecone read-only 2주 유지 후 종료

다운타임 0초로 마무리하는 핵심은 dual-write·shadow-read 패턴이었어요. 예산 잡을 때는 두 DB 요금이 겹쳐서 나가는 이중 운영 기간과, 실패 시 되돌릴 롤백 경로를 미리 계산에 넣으세요.

내부 가이드로는 RAG 파이프라인 구축 완벽 가이드 - 2026년 벡터DB 선택부터 실전 코드까지도 같이 보세요. 이번 글은 비교에 집중했고, 그 글은 코드 레벨이에요.

7.5. 조직 유형별로 갈리는 선택 패턴 4가지

추상적 비교 말고, 도입 상담에서 반복해서 나오는 조직 유형 4가지로 정리할게요.

유형 A — 소규모 스타트업, 사내 문서 검색: 사내 매뉴얼·계약서·정책 문서 정도면 데이터 규모가 크지 않아요. 이미 PostgreSQL을 쓰고 있다면 pgvector가 거의 항상 답입니다. 인프라가 늘지 않으니 운영 인력을 추가할 필요가 없고, 문서 접근 권한을 기존 SQL 스키마로 같이 처리할 수 있다는 게 결정적이에요.

유형 B — 이커머스, 상품 추천과 고객 문의 통합: 상품명·브랜드명·옵션명처럼 글자가 정확히 맞아야 하는 검색이 많아서 하이브리드 검색이 사실상 필수예요. Qdrant Cloud나 Weaviate가 유리합니다. 트래픽이 몰리는 시간대가 뚜렷한 업종이라 노드 기반 과금이 예산 예측에도 편해요.

유형 C — 미디어·아카이브 검색: 연 단위로 쌓인 기사·자막을 검색하는 경우예요. 규모가 커지고 키워드 검색 비중도 높아서 Weaviate 자체 호스팅이 자주 선택됩니다. 대신 인덱스 재구축과 스키마 변경을 감당할 전담 인력이 최소 한 명은 있어야 안정적이에요.

유형 D — 공공기관·금융권, 망 분리 환경: 매니지드 SaaS를 못 쓰니 선택지가 자체 호스팅으로 좁혀져요. 대규모면 Milvus, 중간 규모면 Qdrant입니다. 폐쇄망 구축은 초기 구축비와 연간 운영비가 클라우드 대비 훨씬 크니까 예산 계획을 길게 잡아야 하고, 보안 검토 일정도 별도로 확보해야 합니다.

결론: 회사 규모·데이터 거주지·운영 인력에 따라 최적 선택이 명확히 갈려요. 같은 나라, 같은 업종이라고 답이 같지 않습니다. 도입 전 본인 회사의 데이터 양·트래픽·보안 요구도·예산·운영 인력 5가지를 미리 정리하고 견적 받으세요. 견적 받을 때는 1년 후·3년 후 트래픽 시뮬레이션도 같이 요청하면 비용 폭증을 예방할 수 있어요. SI 업체 통한 구축은 폐쇄망 환경에서만 검토하세요. 일반 클라우드 환경은 내부 엔지니어가 PoC 직접 만들고 결정하는 게 가장 빠르고 정확해요. 유형 A처럼 단순한 구성에서 시작해서 트래픽 따라 단계적으로 확장하는 게 가장 안전한 접근법이에요.

8. 2026년 5월 기준 업데이트 정리

제품 흐름에서 눈여겨볼 변화 4가지예요. 정확한 도입 버전과 날짜는 각 프로젝트 릴리스 노트를 직접 확인하세요.

• Qdrant의 GPU 인덱스 빌드: 인덱스 구축을 GPU로 넘길 수 있게 되면서 대량 백필 시간이 크게 줄었어요. 자체 호스팅 운영자들에게 큰 호재.
• Weaviate Agents: RAG 에이전트 기능이 DB에 내장. LangChain·LlamaIndex 없이도 에이전트 구축 가능.
• pgvector의 HNSW 개선: 인덱스 빌드 메모리 효율과 병렬 빌드가 버전을 거듭하며 개선되는 중. PG 단일 노드로 감당할 수 있는 규모가 계속 올라가고 있어요.
• Pinecone Inference API: 임베딩 생성을 Pinecone에서 직접 처리. 외부 임베딩 API 라운드트립이 사라져서 검색 지연이 줄어듭니다.

내부 가이드로 Claude Projects 1M 컨텍스트 활용, Claude Opus 4.7 1M 컨텍스트 실전도 같이 참고하면 RAG 풀스택 그림이 잡혀요.

9. 한국 기업 환경에서 자주 묻는 5가지 추가 질문

한국 팀들과 RAG 도입 컨설팅하면서 반복해서 받은 질문들이에요.

Q1. 사내 망 분리 환경에서 어떤 DB가 좋아요? 공공기관·금융권은 매니지드 SaaS 사용이 어려워요. 자체 호스팅이 가능한 Qdrant·Milvus·pgvector·Weaviate 중에서 골라야 해요. 운영 인력 1~2명 있으면 Qdrant, 더 작으면 pgvector(이미 PG 운영 인력 있다는 전제), 1억 벡터 넘는 대규모면 Milvus 추천.

Q2. 데이터 주권·GDPR 대응은요? 국내 데이터 센터 보유 여부가 핵심. Pinecone은 서울 리전 있지만 데이터가 미국 백업 가능성 명문화 X. Qdrant·Weaviate·Milvus는 자체 호스팅 시 100% 국내 보장. 금융권·의료 데이터는 자체 호스팅이 안전.

Q3. 한국어 임베딩 모델 성능은 어떻게 측정해요? 한국어 RAG 벤치마크 KorRAG·KMMLU·Ko-IR-Bench 3가지를 추천. OpenAI text-embedding-3-large·BGE-m3·Cohere v3가 한국어에서 상위권. 도메인 특화 데이터 있으면 BGE-m3에 LoRA 미세조정도 가성비 좋아요.

Q4. 한국 SaaS 결제·세금 처리가 복잡한가요? Pinecone·Qdrant Cloud·Weaviate Cloud 모두 USD 결제. 사업자등록증 있는 법인은 부가세 환급 받으려면 reverse charge 처리 필요. 회계팀과 미리 협의. 한국 카드사 일부 해외 SaaS 결제 한도 낮으니 법인카드 확인.

Q5. 데이터 백업·재해 복구 어떻게 해요? Qdrant·Milvus는 snapshot 기능 내장(S3·MinIO 백업 가능). pgvector는 PG 표준 백업으로 충분. Pinecone·Weaviate Cloud는 자동 백업 제공. RTO(목표 복구 시간) 1시간 이하 필요한 비즈니스는 multi-region 클러스터 구성 권장.

10. 마무리 — 지금 당장 할 일 3가지

1. 현재 워크로드 측정: 벡터 수·하루 쿼리 수·메타데이터 필터 패턴 3가지 숫자 먼저 파악. 이게 없으면 비교가 의미 없어요.
2. 2개 DB 평행 테스트: 한 번에 갈아타지 마세요. dual-write·shadow-read로 2주 비교 후 결정.
3. 임베딩 추상화 레이어: LlamaIndex·LangChain VectorStore로 코드 감싸 두기. 다음 마이그레이션 한 달이 일주일로 줄어요.

벡터 DB 9종 중 "당신한테 맞는 1개"는 존재해요. 비용·규모·하이브리드 필요성 3축만 똑바로 측정하면 답이 나와요. 처음엔 Chroma·pgvector로 가볍게 시작하고, 운영 트래픽이 임계점 넘는 시점에 Qdrant·Weaviate로 단계적 확장하는 게 가장 위험 적은 경로예요. 한 번에 Milvus 같은 대규모 시스템부터 도입하면 운영 부담에 압도당해서 RAG 자체가 좌초할 위험이 커요. 작게 시작해서 측정하고, 측정 결과에 따라 다음 단계 정하세요. 결국 벡터 DB 선택은 기술 결정이 아니라 운영 조직 규모와 비즈니스 우선순위가 결정해요. 9종 모두 잘 만든 도구이고, 어떤 도구든 본인 워크로드에 맞게 깊이 익히면 충분히 좋은 RAG가 가능합니다.