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

프롤로그 — 2026년, 벡터 DB는 더 이상 "AI 부속품"이 아니다

2023년 봄, ChatGPT가 처음 폭발했을 때 "벡터 데이터베이스"라는 단어는 OpenAI의 임베딩과 함께 묶여 등장하는 신생 카테고리였다. Pinecone이 거의 유일한 매니지드 옵션이었고, "RAG"라는 약어조차 익숙하지 않았다. 2024년에는 Weaviate·Qdrant·Milvus가 본격적으로 자리를 잡았고, pgvector가 Postgres 쪽에서 무서운 속도로 따라붙기 시작했다. 2025년에는 Turbopuffer 같은 신생 서버리스 진영이 등장했고, 2026년 현재 이 시장은 명백히 성숙기에 들어섰다.

• 벡터 DB는 더 이상 옵션이 아니다. AI 제품을 빌드한다면 어떤 형태로든 벡터 검색을 해야 한다. 문제는 "어떤 걸 쓰냐"다.
• 단일 벡터 검색만 하는 시대도 끝났다. 2026년의 핵심은 hybrid retrieval — dense + sparse + lexical + filtering이 한 쿼리에 들어간다.
• 비용 구조가 무서울 정도로 다양해졌다. Pinecone serverless의 자동 스케일, Turbopuffer의 S3 백업, pgvector의 "공짜에 가까운" 비용까지 — 동일 워크로드를 100배 차이로 운영할 수 있다.

이 글에서 다루는 것:

1. 2026년 벡터 DB 지도 — 누가 만들고 누가 쓰나
2. 임베딩과 벡터 검색의 기초
3. HNSW · DiskANN · IVF · PQ — 인덱스 알고리즘 비교
4. Pinecone — 매니지드 진영의 원조
5. Weaviate — 모듈러 진영의 강자
6. Milvus · Zilliz Cloud — 중국·실리콘밸리 합작 진영
7. Qdrant — Rust 기반의 신성
8. Chroma — 임베디드의 표준
9. LanceDB — Arrow 네이티브 컬럼나
10. pgvector — Postgres의 역습
11. Vespa.ai — Yahoo가 만든 노장
12. Turbopuffer — 서버리스 신생 강자
13. Elasticsearch · OpenSearch — 검색 진영의 합류
14. MongoDB · Redis · SingleStore — 범용 DB의 벡터 모드
15. Sparse vector · BM25 · Hybrid retrieval
16. Quantization — int8 · scalar · binary · ternary
17. Multi-vector retrieval — ColBERT v2와 late interaction
18. 한국·일본 벤더와 클라우드 리전 이슈
19. 비용 비교와 스케일 매트릭스
20. 어떤 워크로드에 어떤 DB를 골라야 하나
21. 운영 안티패턴 모음
22. 참고 자료

1장 · 2026년 벡터 DB 지도

먼저 큰 그림. 시장은 다음 다섯 진영으로 나뉜다.

매니지드 SaaS 진영

• Pinecone. 2019년 창업, 가장 오래된 매니지드 벡터 DB. 2024년 serverless가 정식 GA되며 가격 구조가 완전히 바뀌었다. 현재는 pod 기반과 serverless 두 가지 모드를 모두 제공한다.
• Zilliz Cloud. Milvus의 매니지드 버전. Knowhere라는 자체 벡터 엔진을 코어로 한다.
• Turbopuffer. 2024년 등장. AWS Bedrock의 벡터 백엔드, Cursor, Notion이 채택해 단숨에 유명해졌다. S3 위에 얹은 서버리스 구조가 핵심.

오픈소스 + 클라우드 진영 (BYO와 매니지드 양쪽)

• Weaviate. GraphQL이 1급, BM25 hybrid가 처음부터 기본 지원. 모듈 시스템으로 임베딩 모델을 DB 안에 통합한다.
• Milvus. CNCF 그래듀에이션 프로젝트, 대규모 분산 아키텍처가 강점. DiskANN·IVF·HNSW를 모두 지원하는 다중 인덱스 머신.
• Qdrant. Rust 기반, 메모리 효율과 quantization이 강점. payload filtering이 1급.

임베디드 진영

• Chroma. 가장 가벼운 시작. Python에서 import chromadb 한 줄로 시작.
• LanceDB. Lance라는 컬럼나 포맷 기반, Arrow 네이티브. 데이터가 객체 스토리지에 그대로 산다.

전통 DB의 벡터 모드 진영

• pgvector (PostgreSQL extension). Postgres에 벡터 검색을 더한다. 2024년 0.7에서 halfvec·sparsevec이 추가되며 진지한 옵션이 됐다.
• Elasticsearch 8.18+ · OpenSearch 2.18+. 기존 검색 인덱스 위에 ANN을 얹었다.
• MongoDB Atlas Vector Search. 도큐먼트 DB에 벡터를 통합.
• Redis Stack. RediSearch 모듈로 벡터 검색.
• SingleStore · Couchbase Capella · CockroachDB. SQL DB 진영의 벡터 합류.

검색 엔진 진영

• Vespa.ai. Yahoo가 만든 오래된 엔진. 텐서·ANN·랭킹 표현식이 1급. 대규모 ranking에 가장 강하다.

이 지도가 의미하는 건 단순하다: "하나의 정답 벡터 DB"는 없다. 워크로드의 크기, 쿼리 패턴, 운영 인력의 성숙도에 따라 정답이 다르다.

2장 · 임베딩과 벡터 검색의 기초

벡터 DB를 이해하려면 먼저 임베딩의 본질부터 잡아야 한다.

임베딩이란? 텍스트·이미지·오디오 같은 비정형 데이터를 고정 길이 실수 벡터로 매핑하는 것. OpenAI text-embedding-3-large는 3072차원, Cohere embed-v4는 1024차원, BGE-M3는 1024차원. 차원 수는 모델 설계 결정이지 "큰 게 좋다"는 보장은 없다.

왜 벡터 검색이 필요한가? 임베딩은 "의미가 비슷하면 거리가 가깝다"는 성질을 보장한다. 따라서 새 쿼리에 대해 "가장 가까운 k개 벡터"를 찾는 게 핵심 연산이다. 이걸 k-NN (k Nearest Neighbors) 검색이라고 한다.

문제는 차원의 저주. 1억 개의 1024차원 벡터에서 진짜 nearest neighbor를 찾으려면 1억 번의 1024차원 dot product가 필요하다. 단순 brute force는 GPU에서도 초당 1번 쿼리가 한계다. 그래서 등장한 게 ANN (Approximate Nearest Neighbors) — 100% 정답을 포기하고 99% 정답을 1000배 빠르게 찾는 알고리즘들.

거리 함수의 선택지

• Cosine similarity — 가장 흔하다. 벡터 길이를 무시하고 방향만 비교. OpenAI 임베딩은 cosine을 가정한다.
• Inner product (IP) — 길이를 포함. 일부 임베딩 모델은 IP 기반.
• Euclidean (L2) — 절대 거리. 이미지 임베딩 일부에서 사용.
• Hamming — 이진 벡터용. binary quantization 결과에 쓴다.

대부분의 벡터 DB는 위 4개를 모두 지원한다. 하지만 모델이 학습된 거리 함수를 쓰는 게 정답이다 — OpenAI 임베딩에 L2를 쓰면 결과가 망가진다.

3장 · 인덱스 알고리즘 — HNSW · DiskANN · IVF · PQ

인덱스가 곧 벡터 DB의 성격을 결정한다. 2026년 현재 주류 알고리즘은 네 가지다.

HNSW (Hierarchical Navigable Small World)

• 2016년 Yury Malkov가 제안한 그래프 기반 알고리즘. 다층 그래프를 만들어 위에서 아래로 좁혀가며 검색한다.
• 가장 빠른 in-memory 검색. 100만 개 1024차원 벡터에서 99% recall을 1ms대에 낼 수 있다.
• 단점: 메모리에 인덱스 전체가 올라가야 한다. 1억 벡터 × 1024차원이면 RAM만 400GB+.
• Pinecone pod, Weaviate, Qdrant, Milvus, pgvector(0.5+), Chroma가 모두 지원.

DiskANN (Microsoft Research, 2019)

• 디스크 위에서 SSD-friendly graph를 구성한다. 10억 단위 벡터를 1대의 서버에서 지원할 수 있다는 게 핵심.
• 메모리 사용량은 HNSW의 5% 수준, 지연 시간은 약 2~3배 늦다.
• Milvus 2.5의 추천 알고리즘, Turbopuffer의 내부 인덱스, Vespa의 옵션 중 하나.

IVF (Inverted File Index)

• 1990년대 정보 검색에서 출발한 클러스터링 기반 방법. 벡터 공간을 N개 클러스터로 나누고, 쿼리와 가까운 m개 클러스터만 검색한다.
• Faiss(Facebook)에서 유명해졌고, Milvus가 IVF·IVF-PQ·IVF-SQ의 다양한 변형을 지원.
• HNSW보다 빌드는 빠르고 메모리는 적게 쓰지만 latency가 더 높다.

PQ (Product Quantization) · SQ (Scalar Quantization)

• 인덱스라기보단 압축 기법. PQ는 벡터를 서브벡터로 쪼개 각각 코드북으로 매핑하고, SQ는 float32를 int8로 줄인다.
• HNSW나 IVF와 결합해 메모리를 4~32배 줄인다. 2026년의 거의 모든 큰 인덱스는 PQ나 binary quantization을 쓴다.

ScaNN (Google, 2020)

• Google이 자사 데이터센터용으로 만든 알고리즘. 2~3년간 SOTA였다. 현재는 오픈소스화되어 일부 DB가 옵션으로 지원.

선택 가이드

4장 · Pinecone — 매니지드 진영의 원조

Pinecone은 2019년 Edo Liberty(전 AWS·Yahoo)가 창업했다. "벡터 검색을 매니지드로"라는 컨셉을 가장 먼저 상품화한 회사다.

2026년 현재 두 가지 운영 모드

• Pod 기반. 전통적인 운영 모드. p1·s1·p2 같은 pod 타입을 골라 인스턴스를 띄운다. 메모리·디스크·CPU 트레이드오프를 사용자가 결정한다.
• Serverless. 2024년 GA. 사용자는 인덱스만 만들고, 데이터 양에 따라 자동 스케일. 가격은 $0.40/M vectors + 쿼리당 요금. 가장 사용량이 적은 워크로드에 가장 매력적이다.

핵심 기능

• Namespaces. 한 인덱스 안에서 사용자별·테넌트별 분리. 멀티 테넌시 RAG에서 표준 패턴.
• Hybrid search. dense + sparse 벡터를 한 번에. SPLADE 같은 sparse 임베딩을 같이 인덱싱한다.
• Metadata filtering. 임의의 JSON 메타데이터로 사전 필터. 단 너무 선택적인 필터는 ANN을 망가뜨릴 수 있다.

Pinecone의 강점

• 운영 부담 0. 인덱스를 만들면 끝.
• AWS·GCP·Azure 모든 리전 지원. 데이터 잔류성도 명확.
• 99.99% SLA. 엔터프라이즈가 도입하기 가장 쉬운 옵션.

Pinecone의 단점

• 가격이 빠르게 올라간다. 1억 벡터를 serverless로 운영해도 월 $400+ 수준 (저장만). 쿼리 부하가 크면 $1000을 쉽게 넘는다.
• 자체 호스팅 옵션 없음. 데이터 주권이 중요한 일본·한국 고객에 제약.
• 진입 후 마이그레이션이 어렵다 — 인덱스 포맷이 비공개.

언제 고르나? 첫 RAG 프로토타입, 운영 인력이 적은 스타트업, 엔터프라이즈 SLA가 중요한 곳.

5장 · Weaviate — 모듈러 진영의 강자

Weaviate는 2019년 SeMI Technologies(현 Weaviate B.V.)가 시작한 오픈소스 벡터 DB다. 2026년 현재 버전은 1.27+로, "modules"라는 컨셉이 핵심이다.

핵심 컨셉: Modules

• text2vec-openai, text2vec-cohere, text2vec-huggingface 같은 모듈을 활성화하면, DB에 데이터를 넣을 때 자동으로 임베딩을 만든다.
• 즉 클라이언트에서 임베딩 모델을 직접 호출할 필요가 없다. "데이터 넣고 → 검색"이 그냥 끝난다.
• 단점: 임베딩 모델이 바뀌면 인덱스를 다시 만들어야 한다.

Hybrid search가 1급

• BM25 (lexical) + 벡터 검색을 가중치로 합친다. 이 패턴은 Weaviate가 가장 먼저 정착시켰다.
• nearText 쿼리에 hybrid 옵션 하나만 추가하면 끝.

Multi-tenancy

• 1.20부터 정식 지원. 한 클래스 안에서 테넌트별 격리. SaaS RAG의 표준 패턴.

Dynamic index (1.25+)

• 인덱스 타입을 데이터 양에 따라 자동 전환. 작을 때는 flat (brute force), 일정 크기가 넘으면 HNSW로 자동 전환.

Weaviate의 강점

• GraphQL과 REST 양쪽 API. GraphQL 친화적인 팀에 자연스러움.
• 임베딩 모델 통합. 클라이언트 코드가 줄어든다.
• BM25 hybrid가 처음부터 기본.

Weaviate의 단점

• GraphQL 학습 곡선. 익숙하지 않으면 진입이 어렵다.
• 클러스터 운영이 복잡한 편. Weaviate Cloud Services를 쓰면 해소되지만 비용 상승.

언제 고르나? Hybrid search가 필수인 워크로드, 임베딩을 DB에 위임하고 싶을 때, GraphQL 친화적인 팀.

6장 · Milvus와 Zilliz Cloud — 분산 진영의 강자

Milvus는 2019년 Zilliz가 시작한 중국 출신 오픈소스 벡터 DB다. 2026년 현재 2.5+ 버전이 메인이고, 매니지드는 Zilliz Cloud라는 이름으로 제공된다.

아키텍처 — 가장 분산스러운 설계

• Coordinator, Query Node, Data Node, Index Node가 분리된 microservice 구조.
• Pulsar 또는 Kafka를 메시지 큐로 사용해 write를 비동기로 처리.
• 결과: 가장 큰 규모(10억+ 벡터)에서 잘 동작하는 설계.

Knowhere 엔진

• Milvus의 코어 벡터 엔진. Faiss(Facebook의 ANN 라이브러리)에서 출발했지만 이후 독자적으로 발전.
• HNSW, IVF-Flat, IVF-PQ, IVF-SQ, DiskANN, ScaNN 등 거의 모든 알고리즘을 옵션으로 제공.

다중 인덱스 지원

• 같은 콜렉션에 여러 인덱스 타입을 동시에 보유 가능. 워크로드별로 다른 인덱스를 골라 쓸 수 있다.

Milvus의 강점

• 가장 다양한 인덱스 알고리즘 지원. 연구·실험에 가장 적합.
• 대규모(10억+) 워크로드에 가장 검증된 오픈소스.
• CNCF 그래듀에이션 — 거버넌스가 견실.

Milvus의 단점

• 운영이 가장 복잡. Helm chart 기반 K8s 배포가 표준이지만 컴포넌트가 많아 학습 곡선이 가파르다.
• 작은 규모(100만 미만)에는 오버킬.

Zilliz Cloud

• Milvus의 매니지드. AWS·GCP·Azure 멀티 클라우드. AWS Tokyo 리전도 정식 지원해 일본 고객에게 인기.

언제 고르나? 10억+ 벡터 워크로드, 인덱스 알고리즘을 실험하고 싶을 때, K8s 운영 노하우가 있는 팀.

7장 · Qdrant — Rust 기반의 신성

Qdrant는 2021년 Andrey Vasnetsov가 시작한 Rust 기반 벡터 DB다. 2026년 현재 1.13+ 버전, 매니지드는 Qdrant Cloud로 제공된다.

왜 Rust인가?

• 메모리 안정성 + 성능. Go·Python 기반 경쟁자들 대비 메모리 사용량이 30~50% 적다.
• GC가 없어서 latency variance가 작다. P99 latency가 중요한 워크로드에 유리.

핵심 기능

• Payload filtering. 모든 포인트에 임의의 JSON payload를 붙이고 쿼리에서 필터링. 다른 DB와의 차이는 "filter-first" 인덱스 구조 — 필터 결과가 작아도 ANN이 잘 동작한다.
• Scalar / Binary quantization. 1.7부터 정식 지원. float32 → int8 (4배 압축), float32 → binary (32배 압축). 2026년 binary quantization은 거의 표준.
• Multivector. 한 포인트에 여러 벡터. ColBERT 같은 late interaction 모델 지원.
• Sparse vectors. 1.10부터 SPLADE 같은 sparse 임베딩 지원.

Qdrant의 강점

• 메모리 효율이 가장 좋음.
• 필터링과 ANN의 결합이 가장 깔끔.
• Rust 클라이언트, Python·TypeScript·Go 모두 풍부.
• 가격이 합리적 (Qdrant Cloud 기준 Pinecone의 30~50% 수준).

Qdrant의 단점

• 운영자가 적다. Pinecone이나 Weaviate보다 커뮤니티 규모가 작다.
• 분산 모드의 안정성은 아직 검증이 진행 중. 100억+에서는 Milvus가 우세.

언제 고르나? P99 latency가 중요한 워크로드, payload filtering 비중이 큰 검색, 비용 민감한 곳.

8장 · Chroma — 임베디드의 표준

Chroma는 2022년 Jeff Huber와 Anton Troynikov가 시작한 임베디드 벡터 DB다. 2026년 현재 0.5+ 버전.

컨셉 — "AI-native open-source embedding database"

• Python에서 import chromadb; client = chromadb.Client() 한 줄로 시작.
• 로컬 디스크 모드 (PersistentClient)와 클라이언트-서버 모드 둘 다 지원.

무엇이 다른가

• 가장 가벼운 시작. 가장 빠른 프로토타이핑.
• 임베딩 함수를 콜렉션에 묶을 수 있다 — 데이터 넣을 때 자동으로 임베딩 만든다.
• Multi-modal collections (텍스트, 이미지를 같은 콜렉션에).

Chroma의 강점

• 시작이 가장 쉬움. LangChain·LlamaIndex 튜토리얼에서 사실상 기본.
• 임베디드 모드가 견실. 작은 RAG 데모에 최적.

Chroma의 단점

• 대규모(1억+)에는 부적합. 단일 머신 한계.
• 분산 운영 옵션이 약함.

언제 고르나? RAG 프로토타이핑, 노트북 단위 데모, 100만 이하 임베디드 사용.

9장 · LanceDB — Arrow 네이티브 컬럼나

LanceDB는 2023년 Eto Labs(현 LanceDB Inc.)가 시작한 임베디드 벡터 DB다. 2026년 현재 0.20+ 버전.

핵심 — Lance 컬럼나 포맷

• Lance는 Parquet의 후계자를 목표로 한 컬럼나 포맷. Arrow 네이티브이며, 벡터 검색에 최적화돼 있다.
• 데이터가 객체 스토리지(S3·GCS) 위에 그대로 산다. 별도 DB 인스턴스가 필요 없다.

왜 컬럼나인가?

• 임베딩 + 메타데이터 + 원본 텍스트가 한 파일에. 별도 RDBMS와 동기화할 필요 없음.
• Lance 포맷은 벡터 인덱스를 파일에 직접 내장한다.

Blob storage 모드 (0.18+)

• 객체 스토리지에 데이터가 살고, 검색 시점에 필요한 partition만 fetch.
• Turbopuffer와 비슷한 컨셉이지만 임베디드.

LanceDB의 강점

• 데이터 + 벡터 + 메타데이터가 한 시스템에. ML 파이프라인과 자연스럽게 통합.
• Arrow 네이티브 — pandas·Polars·DuckDB와 직접 호환.
• 오픈소스 + Rust 코어 (안정성).

LanceDB의 단점

• 매니지드 SaaS가 작다 (LanceDB Cloud는 아직 발전 중).
• 대규모 분산 운영 사례가 적다.

언제 고르나? ML 파이프라인이 Arrow 기반인 곳, 객체 스토리지 친화적인 워크로드, 데이터 + 벡터를 하나의 시스템에서 관리하고 싶을 때.

10장 · pgvector — Postgres의 역습

pgvector는 2021년 Andrew Kane이 시작한 Postgres extension이다. 2026년 현재 0.8+ 버전. 가장 충격적인 트렌드 중 하나는 "전용 벡터 DB 대신 그냥 Postgres를 쓰자"는 의견의 부상이다.

왜 pgvector인가?

• Postgres가 이미 운영 중이라면 추가 인프라가 필요 없다.
• 트랜잭션·외래 키·JOIN을 그대로 쓰면서 벡터 검색을 추가한다.
• 운영 인력이 Postgres에 익숙하다면 학습 곡선이 0.

0.8의 새 기능들

• halfvec — float16 벡터 타입. 메모리 50% 절감.
• sparsevec — sparse 벡터 타입. SPLADE 같은 sparse 임베딩 지원.
• HNSW와 IVFFlat 인덱스 양쪽 지원.

확장 생태계

• pg_vectorize (Tembo) — Postgres 안에서 임베딩 생성·검색을 자동화하는 wrapper.
• pg_vector_scale (TigerData / Timescale) — DiskANN 알고리즘을 Postgres에 가져옴. 대규모 워크로드에 핵심.
• pgvecto.rs — Rust로 다시 쓴 호환 extension. 성능이 더 빠르다는 주장.

pgvector의 강점

• 운영이 가장 단순. Postgres가 이미 있으니까.
• 비용이 가장 저렴. 별도 DB 라이선스나 SaaS 비용 없음.
• 트랜잭션·JOIN·복잡한 필터링이 자연스럽다.

pgvector의 단점

• 100만 미만 워크로드에는 완벽하지만, 1000만 이상에서는 latency가 가파르게 올라간다.
• 쓰기와 인덱스 빌드가 동시에 일어나면 부하가 크다.
• Postgres 운영 자체의 비용 — 백업·HA·튜닝.

언제 고르나? 이미 Postgres가 메인 DB일 때, 100만 미만 벡터 워크로드, 트랜잭션과 벡터 검색을 같이 해야 할 때.

11장 · Vespa.ai — Yahoo가 만든 노장

Vespa는 2003년 Yahoo가 사내 검색 엔진으로 시작했고, 2017년 오픈소스로 풀린 베테랑 검색 엔진이다. 2026년 현재도 활발히 업데이트된다.

Vespa의 정체성 — "단순 벡터 DB가 아니라 풀스택 검색 엔진"

• ANN (HNSW) + 텐서 연산 + 랭킹 표현식 + 분산 인덱스 + 실시간 인덱싱이 한 시스템에.
• "랭킹"이 1급 시민. learned-to-rank, GBDT, 신경망 ranker를 인덱스 위에서 직접 평가.

텐서 모델

• Vespa는 모든 데이터를 텐서로 본다. 벡터는 1차원 텐서, 임베딩 그룹은 2차원 텐서. ColBERT 같은 multi-vector는 자연스럽게 표현된다.

Vespa의 강점

• 가장 강력한 ranking. multi-stage retrieval (sparse → dense → reranker)이 가장 깔끔.
• 가장 큰 규모 검증. Yahoo가 수십억 문서 검색에 사용.
• 실시간 인덱싱이 1급.

Vespa의 단점

• 학습 곡선이 가장 가파르다. 문서가 많지만 핵심 컨셉이 많다.
• 작은 워크로드에는 오버킬.
• 운영 복잡도가 가장 높다.

언제 고르나? 검색 ranking이 핵심 차별화인 곳, 10억+ 문서 규모, multi-stage retrieval 파이프라인.

12장 · Turbopuffer — 2024년의 다크호스

Turbopuffer는 2024년에 등장한 신생 서버리스 벡터 DB다. 빠르게 유명세를 탄 이유는 단순하다: AWS Bedrock, Cursor, Notion이 채택했다.

컨셉 — "S3 위에 얹은 벡터 검색"

• 인덱스 데이터를 객체 스토리지(S3)에 저장. 메모리는 캐시로만 쓴다.
• 결과: 저장 비용이 압도적으로 싸다. 1억 벡터를 거의 디스크 비용에만 운영할 수 있다.
• 단점: cold query latency가 크다 (첫 쿼리는 S3에서 fetch).

왜 채택이 빨랐나

• AWS Bedrock의 Knowledge Base 백엔드 중 하나로 채택. 즉 Bedrock 고객은 자동으로 Turbopuffer를 쓰는 셈.
• Cursor가 코드베이스 인덱싱에 사용. 회사당 수십만 ~ 수백만 코드 청크를 효율적으로 검색.
• Notion이 워크스페이스 검색에 채택. 멀티 테넌시가 핵심.

Turbopuffer의 강점

• 가격이 가장 싸다. 사용량이 적은 인덱스는 거의 무료에 가깝다.
• 멀티 테넌시 친화적 — namespace당 인덱스가 독립적으로 hibernation된다.
• AWS 친화적.

Turbopuffer의 단점

• 서버리스의 cold start. 첫 쿼리가 늦다.
• 기능이 아직 좁다. Multi-vector, sparse 같은 고급 기능은 다른 진영보다 늦다.
• 자체 호스팅 옵션 없음.

언제 고르나? 멀티 테넌시 RAG, 대량의 inactive 인덱스를 운영해야 할 때, AWS 리전 친화적인 워크로드.

13장 · Elasticsearch와 OpenSearch — 검색 진영의 합류

기존 검색 엔진 진영도 빠르게 벡터 검색을 흡수했다.

Elasticsearch 8.18+

• dense_vector 필드 타입으로 임베딩 저장. HNSW 인덱스 지원.
• BM25와 hybrid 쿼리가 자연스럽다 (Elasticsearch가 BM25의 본가).
• 8.13부터 byte vectors와 quantization 정식 지원.
• 가장 큰 강점: 기존 ELK 스택과의 통합.

OpenSearch 2.18+

• AWS가 fork한 Elasticsearch. AWS 리전에서 매니지드가 강함.
• k-NN 플러그인이 1급. Nmslib, Faiss, Lucene 세 가지 엔진 옵션.
• 한국 KT Cloud, 일본 AWS Tokyo에서 가장 흔한 벡터 DB 옵션 중 하나.

언제 고르나? ELK가 이미 운영 중일 때, lexical과 벡터를 한 쿼리에서 조합하고 싶을 때, AWS의 OpenSearch Service가 자연스러운 경우.

단점

• 벡터 전용 DB 대비 ANN 성능이 약간 떨어진다.
• 인덱스 빌드 시간이 길다.
• 운영 복잡도는 검색 엔진 그대로 따라온다.

14장 · MongoDB · Redis · SingleStore — 범용 DB의 벡터 모드

MongoDB Atlas Vector Search

• 2023년 발표, 2024년 GA. MongoDB Atlas (매니지드)에서만 동작.
• 도큐먼트 DB이므로 임베딩 + 원본 문서 + 메타데이터가 한 도큐먼트에.
• HNSW 기반. Aggregation pipeline에 $vectorSearch 스테이지로 통합.
• 약점: 자체 호스팅 MongoDB는 미지원. 가격이 빠르게 올라간다.

Redis Stack (RediSearch + Vector)

• 인메모리 — 가장 빠른 latency.
• 약점: 데이터가 메모리에 있어야 함. 1억 벡터는 비현실적.
• 강점: 1ms 이하 latency가 필요한 곳 (e.g., 추천 시스템).

SingleStore

• HTAP DB (OLTP + OLAP). 벡터 검색을 SQL로 통합.
• SQL JOIN과 벡터 검색이 자연스럽게 섞인다.
• 약점: 운영 비용. 매니지드는 비싸다.

Couchbase Capella

• 7.6부터 벡터 검색 지원. JSON 도큐먼트 DB의 벡터 모드.
• 모바일 친화적 (Couchbase Lite와 동기화).

CockroachDB · ClickHouse

• CockroachDB는 24.1부터 벡터 인덱스 실험적 지원.
• ClickHouse는 24.x부터 ANN 인덱스 실험적. OLAP 컨텍스트의 벡터 검색.

이 진영의 공통 메시지: 벡터 검색은 이제 데이터베이스의 기본 기능이다.

15장 · Sparse Vector · BM25 · Hybrid Retrieval

2026년의 RAG는 dense 벡터 하나로 끝나지 않는다.

Sparse vector란?

• 대부분의 차원이 0이고, 일부 차원만 값을 가진 고차원 벡터.
• 예: SPLADE는 어휘 단위(BERT의 vocab)로 30,000차원 sparse 벡터를 만든다.
• 장점: 어휘 매칭과 의미 매칭을 한 모델로 — keyword search의 정확성 + 임베딩의 의미 이해.

BM25

• 1990년대부터 검색의 표준. tf-idf 계열의 정수형 lexical 점수.
• 여전히 강력 — 특히 키워드가 명확한 쿼리에서 임베딩보다 잘한다.

Hybrid retrieval 패턴

1. Reciprocal Rank Fusion (RRF). dense와 sparse 두 검색 결과를 순위 기반으로 융합. 가장 단순하고 자주 잘 동작.
2. 가중 합산. score = α · dense_score + (1-α) · sparse_score. α 튜닝이 필요.
3. 2단계 (cascade). sparse로 후보 1000개 → dense reranker로 100개 → cross-encoder로 10개.

어느 DB가 hybrid를 잘하나?

• Weaviate, Vespa — 처음부터 1급.
• Qdrant, Pinecone — sparse vector 지원 추가됨.
• Elasticsearch — BM25의 본가, hybrid 자연스럽다.
• pgvector — sparsevec 타입으로 추가됐지만 hybrid scoring은 직접 짜야 한다.

16장 · Quantization — int8 · scalar · binary · ternary

벡터 저장 비용을 1/4 ~ 1/32로 줄이는 핵심 기법.

Scalar quantization (int8)

• float32를 int8 (256단계)로 매핑. 메모리 4배 절감.
• recall 손실은 보통 1~3%p. 대부분의 워크로드에서 첫 옵션.
• Qdrant·Milvus·pgvector·Weaviate 모두 정식 지원.

Product quantization (PQ)

• 벡터를 sub-vector로 쪼개 각각 코드북에 매핑. 메모리 8~32배 절감.
• recall 손실이 크다 (5~15%p). 대규모 인덱스에 unavoidable.

Binary quantization (1-bit)

• 각 차원을 1비트로. float32 대비 32배 절감.
• 2024~2025년 sentence embedding 모델들이 binary-friendly 학습으로 recall 손실이 크게 줄었다.
• Cohere embed-v4의 binary 모드, OpenAI text-embedding-3의 MRL(Matryoshka)은 차원 축소와 quantization이 자연스럽게 결합.

Ternary quantization (1.58-bit)

• 2024년 BitNet 논문 이후 부상. 각 차원을 -1, 0, +1 세 값으로.
• 아직 벡터 DB의 정식 지원은 드물지만 실험적 옵션이 늘고 있다.

MRL (Matryoshka Representation Learning)

• OpenAI text-embedding-3-large가 도입. 같은 벡터에서 처음 N차원만 잘라도 의미가 유지된다.
• 3072차원 → 1024차원으로 자르면 75% 메모리 절감 + recall 손실 최소.

실전 권장

• 첫 단계: float32 → int8 (scalar). 거의 무손실.
• 다음: HNSW + int8.
• 1억+ 규모: IVF-PQ 또는 binary.

17장 · Multi-vector Retrieval — ColBERT v2와 Late Interaction

전통적인 dense retrieval은 "문서 하나 → 벡터 하나"였다. 2024~2025년의 큰 변화는 multi-vector retrieval의 부상이다.

ColBERT v2 (Stanford, 2022)

• 토큰 단위로 임베딩을 보존. 문서 하나에 100개 토큰이면 100개 벡터.
• 쿼리도 토큰 단위로 분해, max-sim 연산으로 매칭.
• 결과: 의미 매칭 + 어휘 매칭이 자연스럽게 결합.

왜 단일 벡터보다 강력한가?

• 평균이 정보를 잃지 않는다. "machine learning"이라는 문서에서 "machine"과 "learning"이 각각 살아 있다.
• 의도가 분산된 쿼리에 특히 강하다.

Late interaction

• ColBERT v2의 핵심 메커니즘. 쿼리와 문서의 토큰별 interaction을 마지막에 계산.
• 단점: 저장 비용 증가 (100배). 인덱스가 거대해진다.

어느 DB가 multi-vector를 지원하나?

• Vespa — 텐서 모델로 가장 자연스럽다.
• Qdrant — Multivector 타입 정식 지원.
• Weaviate — 1.25부터 named vectors로 지원.
• Milvus — 2.4부터 multi-vector 콜렉션 지원.

실전 사용

• 코드 검색 (Cursor가 이걸 함).
• 법률·의료 검색 — 정확한 용어 매칭이 중요한 도메인.
• 다국어 검색 — 토큰 단위 매칭이 의미를 보존.

18장 · 한국·일본 벤더와 클라우드 리전 이슈

한국·일본 기업이 벡터 DB를 고를 때는 데이터 잔류성과 리전 이슈가 결정적이다.

한국

• Naver Cloud Platform. NCP가 Milvus 매니지드를 정식 제공. 한국 정부·금융 고객에 사실상 표준.
• KT Cloud. OpenSearch 기반 벡터 검색을 제공.
• Kakao i Cloud. 자체 임베딩 모델과 벡터 DB를 합친 솔루션.
• KoSearch (Naver Search 팀 분사) — 한국어 특화 검색 엔진, 벡터 검색이 1급.
• 자체 호스팅 옵션 — Weaviate, Qdrant, Milvus가 자주 채택된다.

일본

• AWS Tokyo (ap-northeast-1) — 가장 표준. Pinecone·Qdrant·Zilliz가 모두 이 리전을 정식 지원.
• AWS Osaka (ap-northeast-3) — DR 페어로 활용.
• GCP Tokyo (asia-northeast1) — Weaviate Cloud의 일본 리전.
• Azure Japan East — 일부 기업 (금융·공공)에서 선호.
• 사쿠라 인터넷, IDC 프론티어 등 일본 자체 클라우드는 매니지드 벡터 DB 옵션이 거의 없다 → 자체 호스팅이 많다.

규제 이슈

• 개인정보보호법(한국)·APPI(일본) — 임베딩이 PII로 분류될 수 있다. 임베딩 자체에서 원본 텍스트를 복원할 가능성이 있어 일부 규제 당국이 PII로 본다.
• 의료·금융 도메인 — 데이터 잔류성 (residency)이 더 엄격하다. 자체 호스팅이 자연스러운 선택.

19장 · 비용 비교와 스케일 매트릭스

가격은 빠르게 변하므로 정확한 숫자는 매번 확인이 필요하다. 다음은 2026년 5월 기준의 대략적 비교다 (1000만 벡터, 1024차원, 월 1000만 쿼리 가정).

해석

• 가장 저렴한 옵션은 Turbopuffer 또는 self-hosted Qdrant.
• 가장 비싼 옵션은 Pinecone pod 또는 MongoDB Atlas.
• 운영 인력 비용을 포함하면 SaaS가 항상 싸다.
• pgvector는 이미 Postgres가 있을 때만 유리. 신규로 띄우면 RDS 비용이 만만치 않다.

스케일 매트릭스

20장 · 어떤 워크로드에 어떤 DB를 골라야 하나

시나리오 1: 첫 RAG 프로토타입 (벡터 10만)

• 추천: Chroma 또는 pgvector
• 이유: 가장 빠른 시작. 의사결정 비용 0.

시나리오 2: 스타트업 RAG SaaS (벡터 100만, 멀티 테넌시)

• 추천: Pinecone Serverless 또는 Turbopuffer
• 이유: 매니지드의 운영 편의성 + 멀티 테넌시 친화.

시나리오 3: 엔터프라이즈 RAG (벡터 1000만, SLA 중요)

• 추천: Pinecone Pod 또는 Weaviate Cloud
• 이유: 99.99% SLA, 엔터프라이즈 컨트랙트가 잘 갖춰져 있음.

시나리오 4: 대규모 검색 시스템 (벡터 1억+, ranking 핵심)

• 추천: Vespa 또는 Milvus
• 이유: 진지한 분산 운영, multi-stage ranking.

시나리오 5: 코드 검색 (벡터 1000만, multi-vector 필요)

• 추천: Qdrant 또는 Vespa
• 이유: multivector·payload filtering이 1급.

시나리오 6: 비용 최적화 (사용량 낮은 워크로드)

• 추천: Turbopuffer 또는 self-hosted Qdrant
• 이유: 사용량 기반 가격 또는 단일 EC2로 충분.

시나리오 7: Postgres가 이미 있고 벡터를 추가하고 싶음

• 추천: pgvector + pg_vector_scale
• 이유: 별도 인프라 없이 동일 트랜잭션에서 처리.

시나리오 8: 일본 데이터 잔류성 요건

• 추천: AWS Tokyo의 Pinecone 또는 Zilliz Cloud, 또는 자체 호스팅 Qdrant
• 이유: 리전 보장, APPI 준수.

21장 · 운영 안티패턴 모음

벡터 DB 운영에서 자주 보는 실수들. 모두 실제 사례.

안티패턴 1: 임베딩 모델을 자주 바꾼다

• 임베딩 모델이 바뀌면 인덱스를 통째로 다시 만들어야 한다. 1억 벡터를 다시 임베딩하는 비용 = 수천 달러.
• 대응: 모델을 고를 때 1년 단위로 결정하고, 버전을 frontmatter처럼 명시.

안티패턴 2: filter selectivity가 너무 높다

• "유저 A의 문서만 검색"이 결과를 100개로 줄이면 ANN의 그래프가 망가진다.
• 대응: 멀티 테넌시면 namespace 분리. selectivity가 높으면 전용 인덱스.

안티패턴 3: ANN recall을 측정하지 않는다

• 운영 중인 인덱스의 recall@10이 실제로 얼마인지 모르는 팀이 대부분.
• 대응: brute force ground truth를 100개 쿼리에 대해 계산, recall@10을 정기 측정.

안티패턴 4: hybrid score 가중치를 튜닝하지 않는다

• 0.5 / 0.5로 시작한 가중치를 그대로 운영. 데이터 분포에 맞지 않음.
• 대응: 골든 데이터셋으로 grid search.

안티패턴 5: 벡터 차원을 임의로 자른다

• "메모리 줄이려고 1536차원을 768로 잘랐다." → MRL 학습이 안 된 모델은 의미가 깨진다.
• 대응: 모델 카드에서 MRL 지원 여부 확인. OpenAI text-embedding-3는 MRL OK.

안티패턴 6: 임베딩과 원본 텍스트를 분리해 보관

• DB에 임베딩만, S3에 원본 텍스트만. 검색 결과를 사람이 볼 때 매번 JOIN.
• 대응: 임베딩 + 원본 + 메타데이터를 한 레코드에. 또는 LanceDB·MongoDB 같은 통합 옵션.

안티패턴 7: 인덱스 빌드와 쿼리를 같은 인스턴스에

• 인덱스를 다시 빌드하는 동안 쿼리 latency가 5배가 된다.
• 대응: 빌드 전용 인스턴스, blue-green 인덱스 스왑.

안티패턴 8: HNSW M·ef 파라미터를 기본값으로 둠

• 데이터 분포에 따라 최적값이 다르다. 기본값(M=16, ef=64)이 recall 90%인지 99%인지 매번 다르다.
• 대응: M·ef를 데이터셋에 맞춰 튜닝.

22장 · 참고 자료

공식 문서 우선, 주요 학술/공개 발표 자료만 모았다.

벡터 DB 공식 문서

• Pinecone — https://docs.pinecone.io/
• Weaviate — https://weaviate.io/developers/weaviate
• Milvus — https://milvus.io/docs
• Zilliz Cloud — https://docs.zilliz.com/
• Qdrant — https://qdrant.tech/documentation/
• Chroma — https://docs.trychroma.com/
• LanceDB — https://lancedb.github.io/lancedb/
• pgvector — https://github.com/pgvector/pgvector
• pg_vectorize — https://github.com/tembo-io/pg_vectorize
• pg_vector_scale — https://github.com/timescale/pgvectorscale
• pgvecto.rs — https://github.com/tensorchord/pgvecto.rs
• Vespa.ai — https://docs.vespa.ai/
• Turbopuffer — https://turbopuffer.com/docs

기존 검색·DB 진영의 벡터 문서

• Elasticsearch dense_vector — https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html
• OpenSearch k-NN — https://opensearch.org/docs/latest/search-plugins/knn/index/
• MongoDB Atlas Vector Search — https://www.mongodb.com/docs/atlas/atlas-vector-search/
• Redis Vector Search — https://redis.io/docs/latest/develop/interact/search-and-query/advanced-concepts/vectors/
• SingleStore Vector — https://docs.singlestore.com/

핵심 논문

• HNSW (Malkov and Yashunin, 2016) — https://arxiv.org/abs/1603.09320
• DiskANN (Subramanya et al., 2019) — https://www.microsoft.com/en-us/research/publication/diskann-fast-accurate-billion-point-nearest-neighbor-search-on-a-single-node/
• ScaNN (Guo et al., 2020) — https://arxiv.org/abs/1908.10396
• ColBERT v2 (Santhanam et al., 2022) — https://arxiv.org/abs/2112.01488
• SPLADE (Formal et al., 2021) — https://arxiv.org/abs/2107.05720
• MRL — Matryoshka Representation Learning (Kusupati et al., 2022) — https://arxiv.org/abs/2205.13147
• BitNet b1.58 (Ma et al., 2024) — https://arxiv.org/abs/2402.17764

참고 글

• Anthropic — Contextual Retrieval (2024) — https://www.anthropic.com/news/contextual-retrieval
• Cohere — Binary Embeddings — https://cohere.com/blog/int8-binary-embeddings
• OpenAI — New embedding models — https://openai.com/index/new-embedding-models-and-api-updates/
• Microsoft — DiskANN announcement — https://www.microsoft.com/en-us/research/blog/diskann-billion-scale-similarity-search/

에필로그 — 의견을 고른다는 것

이 글의 한 문장 요약: 벡터 DB는 도구가 아니라 의견이다. Pinecone은 "벡터 검색은 매니지드가 정답이다"라고 본다. Milvus는 "벡터 DB는 분산 시스템이다"라고 본다. Qdrant는 "Rust 효율이 모든 것이다"라고 본다. pgvector는 "Postgres가 이미 있는데 왜 새 DB를 사나"라고 본다. Vespa는 "벡터 검색은 ranking의 하위 문제다"라고 본다. Turbopuffer는 "객체 스토리지 위에 얹으면 비용이 100배 싸진다"라고 본다.

같은 문제도 의견이 다르면 해법이 다르다. 그래서 — 모델을 고를 때만큼 — 벡터 DB의 의견을 의식하고 고르자.

다음 글 후보: RAG 평가 시스템 심층(Ragas·DeepEval·TruLens), 임베딩 모델 비교(OpenAI vs Cohere vs Voyage vs BGE), 하이브리드 검색 ranking 튜닝 가이드.

"벡터 DB는 라이브러리가 아니라 의견이다. 의견을 고른다는 자각이, 도구 선택의 첫 단추다."

— 벡터 데이터베이스 2026, 끝.