벡터 데이터베이스 2026 완벽 가이드 - Pinecone · Weaviate · Qdrant · Milvus · pgvector · LanceDB · Chroma · FAISS · DiskANN 심층 분석

들어가며 — 2026년 5월, 벡터 DB는 "범용 인프라"가 됐다

2023년만 해도 벡터 데이터베이스는 "RAG를 만들고 싶은데 어디에 임베딩을 넣어야 하지?"라는 질문에 답하는 신생 카테고리였다. 2026년 5월 현재 그 질문은 끝났다. RAG는 성숙했고, 벡터 검색은 어떤 OLTP/OLAP DB에도 기본 옵션처럼 들어갔으며, 하이브리드 검색(BM25 + dense vector + 리랭커)이 표준이 됐다.

이 글은 마케팅 매트릭스가 아니라 "지금 프로덕션에서 어떤 벡터 DB가 어떤 자리에 들어가는지"를 정직하게 짚는다. Pinecone Serverless v3, Weaviate 1.30, Qdrant 1.13, Milvus 2.5 + Zilliz Cloud, Chroma, LanceDB, pgvector 0.8 + pgvectorscale 0.6 + ParadeDB, Vespa, OpenSearch k-NN, Redis Vector, MongoDB Atlas Vector, Couchbase, SingleStore, Turbopuffer, Marqo, Vald, NGT, FAISS, ScaNN, DiskANN, Annoy, DuckDB VSS, sqlite-vec, jina HnswLib 사용까지 실제 API와 함께 비교한다.

벡터 DB 2026 지형 — 5개 트랙으로 분해하기

먼저 큰 그림이다. 2026년 벡터 DB 시장은 다음 5개 트랙으로 분리됐다.

1. 순수 벡터 DB(pure-play): Pinecone, Weaviate, Qdrant, Milvus, Chroma, LanceDB, Turbopuffer, Marqo
2. 관계형 DB의 벡터 확장: pgvector + pgvectorscale, ParadeDB, SingleStore, Oracle 23ai, SQL Server 2025
3. 검색 엔진의 벡터 확장: Elasticsearch dense_vector, OpenSearch k-NN, Vespa, Solr
4. 다목적 NoSQL의 벡터 확장: MongoDB Atlas Vector, Redis Vector, Couchbase, DynamoDB(2025년 GA)
5. 임베디드/라이브러리: FAISS, ScaNN, DiskANN, Annoy, NGT, HnswLib, Vald, DuckDB VSS, sqlite-vec

같은 ANN 알고리즘(HNSW가 압도적 다수)을 쓰면서도 운영 모델, 가격, 멀티테넌시, 하이브리드 검색 지원에서 크게 갈린다. 아래부터 한 트랙씩 본다.

ANN 알고리즘 1 — HNSW가 사실상 표준이 된 이유

ANN(Approximate Nearest Neighbor) 알고리즘의 2026년 표준은 HNSW(Hierarchical Navigable Small World) 다. Yu. Malkov 와 D. Yashunin의 2016년 논문에서 출발했고, 다층 그래프 위에서 그리디 탐색을 한다.

• 레이어 0: 모든 노드. 가장 조밀한 이웃 연결.
• 상위 레이어: 노드 일부를 확률적으로 승격. 점점 듬성듬성해진다.
• 탐색: 상위 레이어에서 시작해 가까운 노드로 내려간다. 각 레이어에서 ef 후보 큐를 유지.

장점은 삽입/삭제/탐색이 모두 그래프 기반이라 동적 데이터에 강하다는 점이고, 단점은 메모리 점유가 크다는 점이다. 1억 개 768차원 float32 벡터 + HNSW(M=16)는 대략 350GB 메모리를 먹는다.

Pinecone, Weaviate, Qdrant, Milvus, pgvector 0.8, Elasticsearch, OpenSearch, Redis, Chroma, LanceDB, Vespa 모두 HNSW를 기본 또는 옵션으로 제공한다.

ANN 알고리즘 2 — IVF · IVF-PQ · DiskANN · ScaNN의 자리

HNSW가 표준이라지만, 다른 알고리즘도 살아 있다.

• IVF(Inverted File Index): k-means 로 공간을 nlist 셀로 분할 후, 쿼리에서 nprobe 셀만 본다. Milvus와 FAISS의 클래식 옵션.
• IVF-PQ: IVF + Product Quantization. 벡터를 PQ 코드로 압축해 메모리를 1/8 ~ 1/32로 줄인다. 10억 벡터 이상 스케일에서 필수.
• DiskANN(Microsoft Research): NVMe SSD 친화 그래프 인덱스. 10억 벡터를 단일 장비에서 서빙. pgvectorscale의 StreamingDiskANN이 이걸 차용.
• ScaNN(Google): asymmetric quantization + tree 결합. TensorFlow 친화. 정확도/속도 곡선이 매우 우수.
• Annoy(Spotify): random projection forest. 메모리 매핑 친화. 정적 인덱스에 적합.
• NGT(Yahoo Japan): ONNG 그래프. Vald 클러스터의 코어.

선택 가이드를 단순화하면 다음과 같다.

• 1천만 벡터 미만, 동적 갱신: HNSW
• 1억 이상, 메모리 한계: IVF-PQ 또는 DiskANN
• 읽기 전용 대규모: ScaNN, Annoy

리콜 vs 레이턴시 vs 비용 — ann-benchmarks의 현실

ann-benchmarks.com 의 2026년 5월 데이터를 압축하면 다음과 같다. 동일 GIST-960-1M 데이터셋에서:

• HNSW(M=16, ef=200): recall@10 0.99, p99 1.2ms, 메모리 4GB
• IVF-PQ(nlist=4096, nprobe=64, m=32): recall@10 0.93, p99 0.9ms, 메모리 0.5GB
• DiskANN(R=64, L=100): recall@10 0.98, p99 4ms, 메모리 1GB + SSD
• ScaNN(reorder=200): recall@10 0.99, p99 0.6ms, 메모리 3GB

요점은 "공짜 점심은 없다"는 것이다. 리콜을 0.95에서 0.99로 끌어올리는 데 일반적으로 레이턴시는 2 ~ 5배, 메모리는 1.5 ~ 3배 든다. 프로덕션에선 recall@10 = 0.95 가 충분한 경우가 많다.

Pinecone Serverless v3 — 매니지드의 디폴트

Pinecone은 2024년 1월 Serverless GA, 2025년 4분기 v3 라인업으로 storage/compute 완전 분리를 완성했다. 2026년 5월 기준 가장 "그냥 쓰면 되는" 매니지드 옵션이다.

• 인덱스 생성 시 dimension, metric(cosine/dotproduct/euclidean), cloud(aws/gcp/azure), region만 지정.
• 백엔드는 자체 ANN(HNSW 변형 + 파티셔닝). 사용자에게는 노출 안 함.
• 가격은 저장량 + 읽기 단위(RU) + 쓰기 단위(WU) 셋. 콜드 인덱스는 비용이 거의 0에 가까움.
• 멀티 테넌시는 namespace 단위. namespace 당 격리된 인덱스 + RU 카운팅.
• 2025년부터 sparse vector(BM25) + dense vector 하이브리드 1급 지원.
• 2026년 1분기 ColBERT-style late interaction 베타.

전형적 Python 사용은 다음과 같다.

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="pc-...")

pc.create_index(
    name="rag-prod-2026",
    dimension=1024,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)

index = pc.Index("rag-prod-2026")

index.upsert(
    vectors=[
        {"id": "doc-1", "values": [0.01] * 1024, "metadata": {"tenant": "acme", "lang": "ko"}},
    ],
    namespace="tenant-acme",
)

result = index.query(
    vector=[0.01] * 1024,
    top_k=10,
    namespace="tenant-acme",
    filter={"lang": {"$eq": "ko"}},
    include_metadata=True,
)

Pinecone의 가장 큰 강점은 "운영 부담 0"이고, 단점은 가격 예측이 어렵다는 것이다. RU/WU 단위 과금이라 워크로드가 폭증하면 청구서가 따라 폭증한다.

Qdrant — Rust 기반 셀프호스팅 챔피언

Qdrant는 Rust로 작성된 OSS 벡터 DB로, 셀프호스팅 트랙에서 가장 인기 있다. 2026년 5월 기준 1.13 라인업의 특징은 다음과 같다.

• HNSW + scalar/product quantization(int8, binary, PQ) 결합. binary quant + reorder로 디스크/메모리를 4 ~ 32배 절약.
• Payload 인덱스: keyword, integer, float, geo, full-text, datetime 인덱스를 자체적으로 만든다. pre-filter 시 사실상 RDB처럼 동작.
• Sparse vector + dense vector 동시 검색 + RRF/DBSF 융합.
• Multi-vector(ColBERT 등 late interaction) 1급 지원.
• Distributed cluster(샤딩 + Raft)와 Qdrant Cloud 매니지드 둘 다 제공.

컬렉션 생성과 쿼리 예는 다음과 같다.

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue,
)

client = QdrantClient(url="http://qdrant:6333", api_key="q-...")

client.create_collection(
    collection_name="rag_prod",
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE),
)

client.upsert(
    collection_name="rag_prod",
    points=[PointStruct(id=1, vector=[0.01] * 1024, payload={"lang": "ko", "tenant": "acme"})],
)

hits = client.search(
    collection_name="rag_prod",
    query_vector=[0.01] * 1024,
    query_filter=Filter(must=[FieldCondition(key="lang", match=MatchValue(value="ko"))]),
    limit=10,
)

Qdrant Cloud는 GCP/AWS/Azure에 매니지드를 제공하며, 가격은 메모리/디스크 기반이라 Pinecone 보다 예측 가능하다. 셀프호스팅도 Helm chart로 가능해 K8s 친화적이다.

Weaviate — 모듈 + 하이브리드의 강자

Weaviate는 Go로 작성된 OSS 벡터 DB로, 모듈 시스템과 하이브리드 검색 1급 지원이 강점이다. 2026년 5월 1.30 라인업 기준:

• 모듈: text2vec-openai, text2vec-cohere, text2vec-jina, multi2vec-clip, generative-openai, reranker-cohere 등. 임베딩 생성을 DB 안에서 해결.
• Hybrid search: BM25 + dense + Reciprocal Rank Fusion 한 줄로.
• Multi-tenancy: 테넌트마다 별도 인덱스 디렉토리. 수만 ~ 수십만 테넌트 친화.
• Weaviate Cloud Services(WCS): 매니지드. Hybrid Cloud(BYOC) 옵션도 2025년 4분기 GA.
• Generative 검색: 검색 결과를 LLM에 바로 넘겨 RAG 응답을 받는 한 줄 API.

스키마 생성과 하이브리드 검색 예다.

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    name="Doc",
    properties=[
        Property(name="content", data_type=DataType.TEXT),
        Property(name="lang", data_type=DataType.TEXT),
    ],
    vectorizer_config=Configure.Vectorizer.text2vec_openai(model="text-embedding-3-large"),
    generative_config=Configure.Generative.openai(model="gpt-4.1-mini"),
)

docs = client.collections.get("Doc")
result = docs.query.hybrid(
    query="벡터 데이터베이스 비교",
    alpha=0.5,
    limit=10,
)

Weaviate의 강점은 "임베딩 + 검색 + 생성"을 한 시스템에서 끝낼 수 있다는 것이다. 단점은 모듈 의존성이 복잡해 셀프호스팅 시 운영 비용이 늘어난다는 점.

Milvus 2.5 + Zilliz Cloud — 대규모 + GPU의 챔피언

Milvus는 LF AI & Data Foundation 산하의 대규모 벡터 DB로, 십억 ~ 백억 벡터 스케일에서 가장 검증됐다. 2026년 5월 2.5 라인업:

• 분산 아키텍처: query node, data node, index node, coord 분리. K8s 친화.
• 인덱스 옵션: HNSW, IVF, IVF-PQ, DiskANN, GPU-CAGRA, GPU-IVF-PQ.
• GPU 인덱싱: NVIDIA cuVS / RAFT 기반 GPU-CAGRA. CPU 대비 10 ~ 100배 처리량.
• 하이브리드 검색: BM25 + dense + RRF, 다중 벡터 필드, partition_key 기반 멀티 테넌시.
• Zilliz Cloud: Milvus 제작사가 운영하는 매니지드. AWS/GCP/Azure 전 리전.

컬렉션 생성과 하이브리드 검색 예는 다음과 같다.

from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://milvus:19530", token="root:Milvus")

schema = client.create_schema()
schema.add_field("id", DataType.INT64, is_primary=True, auto_id=True)
schema.add_field("dense", DataType.FLOAT_VECTOR, dim=1024)
schema.add_field("sparse", DataType.SPARSE_FLOAT_VECTOR)
schema.add_field("tenant", DataType.VARCHAR, max_length=64)

idx = client.prepare_index_params()
idx.add_index("dense", index_type="HNSW", metric_type="COSINE", params={"M": 16, "efConstruction": 200})
idx.add_index("sparse", index_type="SPARSE_INVERTED_INDEX", metric_type="IP")

client.create_collection("rag", schema=schema, index_params=idx)

Milvus는 "엔터프라이즈 대규모"가 정체성이다. 1억 미만 워크로드라면 오히려 운영 부담이 크니, Pinecone/Qdrant/Weaviate 가 낫다.

pgvector + pgvectorscale + ParadeDB — Postgres가 "충분히 좋다"는 진영

2026년의 흥미로운 흐름은 Postgres + pgvector가 "특별한 요구가 없으면 충분히 좋다"는 디폴트로 자리잡은 것이다.

• pgvector 0.8: HNSW + IVFFlat 인덱스. 2025년 binary quantization, halfvec(16비트) 추가.
• pgvectorscale 0.6(Timescale): StreamingDiskANN 인덱스 + statistical binary quantization. pgvector 보다 10 ~ 100배 빠른 필터 검색.
• ParadeDB: Postgres 위에 BM25(pg_search) + 벡터를 결합. 하이브리드 검색을 Postgres 안에서 끝낸다.
• Supabase, Neon, Aurora, Cloud SQL: 모두 pgvector 기본 설치.

전형적 사용은 다음과 같다.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS vectorscale;

CREATE TABLE doc (
    id bigserial PRIMARY KEY,
    tenant_id uuid NOT NULL,
    content text NOT NULL,
    embedding vector(1024) NOT NULL
);

CREATE INDEX ON doc USING diskann (embedding vector_cosine_ops);
CREATE INDEX ON doc (tenant_id);

SELECT id, content, 1 - (embedding <=> $1) AS score
FROM doc
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

장점은 트랜잭션 + JOIN + 권한 + 백업이 그냥 Postgres와 같다는 점이다. 단점은 1억 벡터 이상에서 HNSW 메모리 압박이 심하고, 멀티테넌시를 RLS로 풀면 인덱스 효율이 떨어진다는 점.

Chroma · LanceDB — 임베디드/로컬 트랙

프로덕션 단일 노드 또는 노트북에서 RAG 프로토타입을 만들 때 가장 흔히 쓰이는 두 도구.

• Chroma: Python/JS 우선. 단일 프로세스 임베디드, 또는 HTTP 서버. SQLite + DuckDB + HNSWLib 조합. 2026년 1분기 distributed 모드 베타.
• LanceDB: Rust로 작성. Apache Arrow + Lance 파일 포맷 기반. S3/GCS 위에 그대로 올려도 동작. 임베디드 + 서버 모두 가능. multimodal 친화.

LanceDB의 매력은 "S3에 .lance 파일 하나로 끝낸다"는 점이다. 매니지드도 따로 없지만 LanceDB Cloud(베타)와 SageMaker 통합 옵션이 늘고 있다.

import lancedb

db = lancedb.connect("s3://my-bucket/lance-db")
tbl = db.create_table(
    "docs",
    data=[{"id": 1, "vector": [0.01] * 1024, "lang": "ko"}],
    mode="overwrite",
)
tbl.create_index(metric="cosine", index_type="IVF_HNSW_SQ", num_partitions=256)

hits = tbl.search([0.01] * 1024).where("lang = 'ko'").limit(10).to_list()

Elasticsearch · OpenSearch · Vespa — 검색 엔진 트랙

기존 BM25 검색 엔진이 dense vector를 본격 지원하면서, 별도 벡터 DB를 도입하지 않고 같은 클러스터에서 하이브리드 검색을 하는 흐름이 자리잡았다.

• Elasticsearch 8.x ~ 9.x: dense_vector 필드 + HNSW. _search 안에 knn + query(BM25) 결합으로 하이브리드. ELSER(Elastic Learned Sparse Encoder)로 sparse vector도 자체 제공.
• OpenSearch 2.x ~ 3.x: knn 플러그인. FAISS/Lucene/NMSLib 백엔드 선택. AWS OpenSearch Service에서 매니지드.
• Vespa: Yahoo가 만들고 오픈소스로 푼 검색 엔진. tensor 표현이 1급. multi-vector, 멀티 스테이지 랭킹이 강점. Spotify Discover Weekly, Yahoo Mail이 사용.

기존 검색 클러스터가 있는 조직이 가장 먼저 시도하는 경로다. 단점은 벡터 전용 DB만큼 인덱싱 처리량/메모리 효율이 좋지는 않다는 점.

NoSQL의 벡터 확장 — Mongo · Redis · Couchbase · SingleStore · DuckDB · SQLite

운영 데이터가 이미 들어 있는 DB가 벡터를 지원하면 운영이 가장 단순해진다.

• MongoDB Atlas Vector Search: Atlas의 전용 검색 인덱스(Lucene 기반). $vectorSearch aggregation 단계.
• Redis 8 Vector Search: HNSW + flat. Redis Stack/Redis Enterprise. 인-메모리라 ms 미만 응답.
• Couchbase Vector Search: 2024년 GA. SQL++ 안에서 벡터 쿼리.
• SingleStore: 분산 SQL DB + 벡터. 분석/검색/트랜잭션 한 클러스터.
• DuckDB VSS 확장: in-process 분석 + HNSW. 데이터프레임/Parquet에 그대로 인덱스.
• sqlite-vec: Alex Garcia가 만든 SQLite 확장. 모바일/엣지 RAG 용.

이 트랙의 공통점은 "벡터를 위해 별도 클러스터를 만들지 않는다"는 점이다. 1억 벡터 미만, 본업이 OLTP인 서비스라면 가장 합리적인 선택이 된다.

신흥 트랙 — Turbopuffer · Marqo · Vald · NGT · Tair Vector

매니지드/특화 시장에서도 신규 진입자가 늘었다.

• Turbopuffer: S3 위에 올린 서버리스 벡터 DB. 가격이 매우 낮고(스토리지 + 쿼리당 과금), 콜드 데이터에 강하다. 2025년 Notion이 채택해 주목받음.
• Marqo: 임베딩 + 검색을 한 묶음으로 제공. multimodal 친화. cloud + 셀프호스팅.
• Vald(Yahoo Japan/LY): K8s 네이티브, NGT 기반 분산 벡터 DB. LINE 검색에 사용.
• NGT(Yahoo Japan): 그래프 기반 ANN 라이브러리. ONNG, PANNG, QG 변형.
• Tair Vector(Alibaba Cloud): Redis 호환 + 벡터. 중국 시장 디폴트.

FAISS · ScaNN · DiskANN · Annoy · HnswLib — 라이브러리 트랙

DB가 아니라 라이브러리로 직접 인덱스를 다루는 트랙이다. 학습/연구나 임베디드에서 여전히 핵심.

• FAISS(Meta): C++/Python. IVF, HNSW, IVF-PQ, GPU FAISS. Meta 내부 + 학계 디폴트.
• ScaNN(Google): TensorFlow 친화. asymmetric quantization. 정확도/속도 비율 우수.
• DiskANN(Microsoft): SSD 친화 그래프. pgvectorscale, Milvus가 차용.
• Annoy(Spotify): random projection. 메모리 매핑. 정적 인덱스에 적합.
• HnswLib: hnsw 알고리즘 저자가 만든 단순한 HNSW 라이브러리. Chroma, Jina, Weaviate 초기 백엔드.
• NGT(Yahoo Japan): 그래프 기반. 일본/한국에서 채택 사례 많음.

라이브러리 직접 사용 예(FAISS):

import numpy as np
import faiss

d = 1024
nb = 100000
xb = np.random.random((nb, d)).astype("float32")
xq = np.random.random((1, d)).astype("float32")

index = faiss.IndexHNSWFlat(d, 32)
index.hnsw.efConstruction = 200
index.add(xb)
index.hnsw.efSearch = 64

D, I = index.search(xq, 10)
print(I, D)

하이브리드 검색 — BM25 + dense + RRF + Reranker가 표준이 된 이유

2024년 이후 명확해진 사실은 dense vector 하나만으로는 부족하다는 것이다. 키워드(이름, ID, 코드) 매칭에 약하고, OOD(out-of-domain) 쿼리에서 무너지기 쉽다. 2026년 표준은 다음 4단계 파이프라인이다.

1. BM25 검색(sparse)으로 top-50 ~ 100
2. Dense vector 검색으로 top-50 ~ 100
3. RRF(Reciprocal Rank Fusion) 또는 가중 합으로 후보 100 ~ 200 정리
4. Reranker(Cohere Rerank 3.5, Voyage Reranker 2, BGE Reranker v2-m3, Jina Reranker v2)로 top-10

RRF 가중 식은 단순하다.

def rrf(rankings: list[list[str]], k: int = 60) -> dict[str, float]:
    scores: dict[str, float] = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return scores

리랭커는 cross-encoder 구조로 쿼리와 문서 쌍을 동시에 본다. 검색 점수 대비 NDCG@10이 5 ~ 15% 오르는 게 일반적이다. Cohere Rerank 3.5는 100개 문서 리랭킹에 약 80ms, 가격은 1,000 쿼리당 $2 수준이다.

멀티벡터와 ColBERT · ColPali — 새로운 정확도 표준

문서 하나를 단일 벡터로 압축하면 디테일이 사라진다. 그래서 등장한 게 멀티벡터(multi-vector) 접근이다.

• ColBERT v2(Stanford 2022 → 2024년 PLAID 최적화): 문서 토큰별 벡터를 다 저장 + 쿼리 토큰과 late interaction(MaxSim). dense single-vector 대비 NDCG가 크게 좋음.
• ColPali(2024): 비전 트랜스포머로 페이지 이미지를 패치 벡터 다발로 임베딩. PDF/슬라이드 RAG에 혁신적.
• ColQwen2: ColPali의 Qwen2-VL 백본 버전.

문제는 저장량이다. 토큰당 벡터를 저장하면 데이터셋이 50 ~ 200배 커진다. Qdrant, Vespa, Weaviate, ParadeDB 가 멀티벡터를 네이티브로 지원하고, Pinecone은 2026년 1분기 베타 단계다.

필터 검색 — pre-filter vs post-filter, 그리고 메타데이터 인덱스

벡터 검색은 거의 항상 메타데이터 필터와 함께 쓴다("tenant_id = X AND lang = ko").

• Post-filter: ANN 검색 후 필터. 후보 부족 위험.
• Pre-filter: 필터 먼저 적용 후 ANN. Qdrant/Weaviate/Milvus/pgvector가 잘 한다.
• Indexed filter: 메타데이터 자체에 인덱스를 만들어 결합 검색.

Pinecone, Weaviate, Qdrant, Milvus, Elasticsearch는 메타데이터 인덱스를 자체로 만든다. pgvector는 Postgres B-tree/GIN 인덱스에 의존. 멀티테넌시가 큰 워크로드라면 pre-filter 성능을 항상 벤치마크해야 한다.

임베딩 모델 선택 — OpenAI vs Cohere vs Voyage vs BGE vs E5 vs Jina

벡터 DB만 잘 골라도 임베딩이 나쁘면 검색 품질은 무너진다. 2026년 5월 MTEB 리더보드 상위권은 다음과 같다.

• OpenAI text-embedding-3-large(3072d, matryoshka 256/1024/3072). 균형 좋음.
• Cohere Embed v4(1024d, 멀티모달, 멀티링구얼, matryoshka).
• Voyage 3 / Voyage 3-large(1024d, 도메인 특화 + 일반 우수).
• BGE-M3(1024d, dense + sparse + ColBERT 동시 출력, OSS).
• E5-Mistral-7B-instruct(4096d, OSS).
• gte-Qwen2-7B-instruct(3584d, OSS).
• Jina Embeddings v3(1024d, multilingual, late chunking 지원).

선택 기준은 (1) 멀티링구얼이 필요한지, (2) matryoshka로 차원 축소가 필요한지, (3) 셀프호스팅이 필요한지, (4) 비용을 어디까지 받아들이는지다. 한국어/일본어 환경에서는 BGE-M3, Cohere v4, Jina v3, multilingual-e5-large가 안전한 선택이다.

RAG-specific 패턴 — chunking · contextual retrieval · parent-child

벡터 DB 위에 RAG를 올릴 때 2026년 표준 패턴은 다음과 같다.

• Chunking: 토큰 300 ~ 800 + 50 토큰 오버랩이 가장 흔하다. 의미 기반 분할(semantic chunking)도 인기.
• Contextual retrieval(Anthropic 2024 발표): 청크마다 "이 청크는 어떤 문서의 어디인가"를 LLM이 짧게 쓰게 해 임베딩 전에 prepend. 검색 실패율을 절반 가까이 줄임.
• Parent-child: 작은 청크로 검색, 부모 청크/문서를 LLM에 넘긴다.
• Query expansion: HyDE(가상 응답 생성 후 임베딩), multi-query, query rewriting.
• Reranking: top-100 → top-10 cross-encoder 리랭킹은 거의 모든 RAG에서 권장.

이 패턴은 DB와 무관하지만, 멀티벡터/sparse 지원 여부가 어떤 패턴을 쉽게 쓸 수 있는지를 결정한다.

GPU 벡터 인덱싱 — RAFT · cuVS · NVIDIA 가속

NVIDIA RAPIDS의 cuVS(RAFT의 후속)가 2025년 GA되면서 GPU 벡터 인덱싱이 본격화됐다.

• CAGRA: GPU 친화 그래프 ANN. HNSW 대비 빌드는 10배 이상 빠르고 쿼리도 GPU에서 5 ~ 50배 빠름.
• GPU IVF-PQ: 십억 벡터 인덱스 빌드를 시간 단위에서 분 단위로 단축.
• Milvus GPU CAGRA, FAISS GPU 모듈, RAPIDS cuVS가 채택. Pinecone, Weaviate, Qdrant는 GPU를 코어로 쓰지는 않음(쿼리 시 CPU가 보편).

학습이 아니라 검색 단계에서도 GPU가 의미 있어지는 변곡점이 2025 ~ 2026년이다. 다만 비용 구조상 단일 노드 1억 벡터 미만이라면 CPU + HNSW 가 여전히 우월하다.

비용 경제학 — Pinecone vs Weaviate Cloud vs 셀프호스팅 Qdrant

대략적인 가격 비교(2026년 5월, 1억 벡터 1024d, p50 50ms 타깃).

• Pinecone Serverless: 약 $2,500 ~$4,000/월(저장 + 평균 트래픽).
• Weaviate Cloud(Serverless): 약 $2,000 ~$3,500/월.
• Zilliz Cloud(Milvus): 약 $1,500 ~$3,000/월.
• Qdrant Cloud: 약 $1,200 ~$2,500/월.
• Turbopuffer: 약 $300 ~$800/월(콜드 워크로드).
• 셀프호스팅 Qdrant on K8s(EKS, 4 x r6i.2xlarge): 약 $1,200/월 인프라 + 운영 인력.
• 셀프호스팅 pgvector(Aurora Serverless v2): 약 $700 ~$1,500/월.

가격은 트래픽 패턴에 따라 4 ~ 10배까지 갈라진다. 콜드 RAG라면 Turbopuffer/pgvector가 우월하고, 항상 따끈한 트래픽이면 셀프호스팅 Qdrant가 가장 싸진다.

한국 도입 사례 — Naver, Kakao, Toss, 당근

한국 IT 시장의 2026년 5월 벡터 DB 현황은 다음과 같다.

• Naver Clova: 자체 HyperCLOVA X RAG 인프라. Milvus 변형 + 자체 임베딩으로 추정.
• Kakao Brain: pgvector + 자체 임베딩 모델로 KoGPT 응용 RAG.
• Toss: 검색팀이 Vespa 기반 멀티스테이지 랭킹 구축. 벡터는 사내 인덱스.
• 당근: 마켓플레이스 추천에 Faiss + 자체 임베딩. Qdrant 적용 사례 발표.
• 삼성SDS, LG CNS: 사내 RAG에 Pinecone 또는 Weaviate 매니지드 사용 사례.
• 스타트업 챗봇/검색 도메인: Qdrant, Weaviate, pgvector가 가장 흔함.

한국어 임베딩은 BGE-M3, Cohere Embed v4, multilingual-e5-large가 사실상 표준 후보다. 한국어 특화 모델(KoSimCSE 등)은 도메인이 좁을 때 강점이 있다.

일본 도입 사례 — Vald(LY), NGT(Yahoo), Mercari, LINE 검색

• Yahoo Japan / LY Corporation: NGT 라이브러리 개발, Vald 분산 벡터 DB OSS. LINE 검색/추천에 사용.
• Mercari: 시맨틱 검색에 Elasticsearch + 자체 임베딩, 그리고 일부 워크로드에 Vespa.
• CyberAgent: 광고 추천에 Faiss 기반 자체 시스템.
• Rakuten: 상품 검색에 Solr/Elastic + 자체 임베딩 결합.
• Preferred Networks: 사내 RAG에 Qdrant 도입 사례 발표.

NGT는 한국에서도 알려진 라이브러리지만, Vald 클러스터를 직접 돌리는 사례는 일본 내에서도 LY/네이버 등 일부에 한정된다. Mercari의 Vespa 도입은 검색 도메인에서 자주 인용된다.

의사결정 가이드 — 워크로드별 추천

마지막으로 워크로드별 추천을 단순화한다.

• 노트북/단일 노드 RAG 프로토타입: Chroma, LanceDB, DuckDB VSS, sqlite-vec
• 모놀리식 SaaS, 1억 벡터 미만, Postgres 운영 중: pgvector + pgvectorscale (+ ParadeDB)
• K8s 셀프호스팅, 1억 ~ 10억 벡터: Qdrant, Weaviate, Milvus
• 운영 부담 최소화 매니지드: Pinecone Serverless, Qdrant Cloud, Zilliz Cloud, Weaviate Cloud
• 10억 벡터 초과, GPU 인덱싱 필요: Milvus GPU(CAGRA), Vespa, 자체 FAISS 인프라
• 콜드 워크로드, 가격 최적화: Turbopuffer, pgvector, LanceDB on S3
• 검색 클러스터가 이미 있다: Elasticsearch dense_vector, OpenSearch k-NN, Vespa
• OLTP DB 위에서 끝낸다: MongoDB Atlas Vector, Redis Vector, Couchbase, SingleStore
• 임베디드/모바일: sqlite-vec, LanceDB embedded
• 하이브리드 검색 + 리랭킹 1급 지원이 필요: Qdrant, Weaviate, Vespa, Milvus, ParadeDB
• 멀티벡터(ColBERT/ColPali) 1급 지원: Qdrant, Vespa, Weaviate, ParadeDB

"기본값을 정해 두고 예외만 옮긴다"는 원칙을 적용하면, 2026년 5월 기준 새 RAG의 디폴트는 (A) Postgres + pgvector + pgvectorscale 또는 (B) Qdrant 매니지드가 가장 안전하다.

References

• Pinecone — Serverless v3 매니지드 벡터 DB
• Weaviate — 모듈 + 하이브리드 + 생성 검색
• Qdrant — Rust 기반 OSS 벡터 DB
• Milvus — 대규모 분산 벡터 DB
• Zilliz Cloud — Milvus 매니지드
• Chroma — 임베디드 벡터 DB
• LanceDB — Arrow 기반 멀티모달 벡터 DB
• pgvector — Postgres 벡터 확장
• pgvectorscale — StreamingDiskANN
• ParadeDB — Postgres BM25 + 벡터
• Vespa — Yahoo 검색 엔진
• OpenSearch k-NN — k-NN 플러그인
• Elasticsearch dense_vector — 벡터 검색
• Redis Vector Search — 인메모리 벡터 검색
• MongoDB Atlas Vector Search — Atlas 벡터 검색
• Turbopuffer — S3 위 서버리스 벡터 DB
• Marqo — 임베딩 + 검색
• Vald — Yahoo Japan 분산 벡터 DB
• NGT — Yahoo Japan 그래프 ANN
• FAISS — Meta 벡터 라이브러리
• DiskANN — Microsoft SSD 그래프 인덱스
• ScaNN — Google ANN
• Annoy — Spotify 정적 ANN
• HnswLib — HNSW 참조 구현
• Cohere Rerank — Rerank 3.5 리랭커
• Voyage Reranker — Voyage Reranker 2
• MTEB Leaderboard — 임베딩 벤치마크
• ann-benchmarks — ANN 알고리즘 벤치마크
• ColBERT — late interaction
• ColPali — 비전 멀티벡터
• Anthropic Contextual Retrieval — 청크 컨텍스트화