Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

프롤로그 — 2년 사이에 지형이 통째로 바뀌었다
1. 무엇이 바뀌었나 — 가격 붕괴와 오브젝트 스토리지 혁명
2. 매니지드 SaaS — Pinecone Serverless, Turbopuffer, Zilliz Cloud
3. 오픈소스 전용 엔진 — Qdrant, Weaviate, Milvus, Vespa, Vald
4. Postgres 진영 — pgvector + pgvectorscale + Supabase·Neon·Tiger
- 4-1. pgvector + pgvectorscale
- 4-2. 매니지드 — Supabase, Neon, Tiger Cloud
5. 임베디드·분석형 — Chroma, LanceDB, DuckDB VSS
6. 범용 DB의 벡터 — MongoDB Atlas, Couchbase, Elasticsearch/OpenSearch
7. 하이브리드 검색 표준 — BM25 + 밀집 + 리랭커
- 임베딩·리랭커 풍경 (2026년 4월 MTEB 기준)
8. 비용 매트릭스 — 1M 벡터당 월 얼마인가
9. 결정 다이어그램 — "pgvector vs 전용" 갈림길
10. 운영 안티패턴
11. 에필로그 — 체크리스트와 다음 글 예고
- 결정 체크리스트
- 다음 글 예고
참고 / References

프롤로그 — 2년 사이에 지형이 통째로 바뀌었다

2024년 봄에 RAG 파일럿을 시작했을 때, 벡터 DB 선택지는 비교적 단순했다. Pinecone은 비싸고 관리는 편했다. Weaviate는 모듈러였지만 자체 호스팅은 운영 부담이 컸다. Chroma는 노트북용 장난감이었다. pgvector는 "작은 데이터셋에만 쓸 수 있다"는 통념이 있었다.

2026년 5월 시점에 그 통념은 거의 다 깨졌다.

Pinecone Serverless가 가격을 붕괴시켰다. 무료 티어 2GB·5 인덱스, 표준 가격은 read 1M당 8.25달러, write 1M당 2달러, 스토리지 GB당 월 0.33달러 수준. 작은 RAG는 사실상 공짜다.
Turbopuffer가 S3 위에 2.5조 도큐먼트를 띄우면서 "오브젝트 스토리지 + SSD 캐시" 패턴을 산업 표준으로 끌어올렸다. Cursor·Notion이 운영 중이다.
pgvectorscale(Timescale)이 StreamingDiskANN을 넣었다. 5천만 벡터·768차원에서 자체 호스팅 시 Pinecone s1 대비 p95 28배 낮은 지연, 75% 적은 비용을 낸다. "그냥 Postgres 써"가 농담이 아니게 됐다.
Qdrant는 v1.17에서 RocksDB를 통째로 들어내고 자체 스토리지 엔진 gridstore로 교체했다. 5천만 달러 시리즈 B를 받아 엔터프라이즈 모드로 진입했다.
DuckDB VSS 익스텐션은 분석 워크플로 한복판에 HNSW를 끼워 넣었다. "데이터 파이프라인 안에서 벡터 검색"이 가능해졌다.
Vespa는 Spotify가 HNSW를 실서비스로 돌리는 채로 "AI 검색 플랫폼"으로 리브랜딩했다.
하이브리드 검색(BM25 + 밀집 + 리랭커)이 사실상 표준이 됐다. Cohere Rerank 3.5, Voyage Rerank 2.5, Jina Reranker v3, BGE-M3가 골고루 자리를 잡았다.

이 글은 지난해 4월의 "벡터 DB 비교 — Pinecone·Weaviate·Chroma·pgvector"의 후속편이다. 그쪽은 입문용 비교였고, 이건 2026년 5월 기준 실제 운영 지형을 비용·아키텍처·실패 사례로 한 장에 정리하는 딥다이브다.

흐름:

무엇이 바뀌었나 — 가격 붕괴와 오브젝트 스토리지 혁명
매니지드 SaaS — Pinecone Serverless, Turbopuffer, Zilliz Cloud
오픈소스 전용 엔진 — Qdrant, Weaviate, Milvus, Vespa, Vald
Postgres 진영 — pgvector + pgvectorscale + Supabase·Neon·Tiger
임베디드·분석형 — Chroma, LanceDB, DuckDB VSS
범용 DB의 벡터 — MongoDB Atlas, Couchbase, Elasticsearch/OpenSearch
하이브리드 검색 표준 — BM25 + 밀집 + 리랭커
비용 매트릭스 — 1M 벡터당 월 얼마인가
결정 다이어그램 — "pgvector vs 전용" 갈림길
운영 안티패턴
에필로그 — 체크리스트와 다음 글 예고

1. 무엇이 바뀌었나 — 가격 붕괴와 오브젝트 스토리지 혁명

1-1. 가격 곡선

2023~2024년의 Pinecone은 p1.x1 포드를 띄우는 데 시간당 0.10달러쯤이 기본이었다. 1억 벡터를 안정적으로 굴리려면 월 수천 달러는 깔고 들어갔다. 2024년 1월에 발표된 Serverless 아키텍처가 모든 걸 바꿨다 — 컴퓨트와 스토리지를 분리하고, 콜드 데이터는 오브젝트 스토리지로 내리고, 쿼리 단위로만 과금. 2026년 시점의 표준 가격(Standard 플랜):

항목	단가	비고
Read	1M read units 당 8.25달러	1 read unit ≈ 1KB 페이로드 1회 검색
Write	1M write units 당 2달러	업서트·삭제 모두 포함
Storage	GB·월 0.33달러	메타데이터 포함
Capacity (예약형)	별도 시간당 과금	고동시성 워크로드에서 활성화
무료 티어	2GB · 인덱스 5개	1프로젝트, SLA·RBAC·서포트 없음

작은 RAG(1M 벡터, 일 수만 쿼리)는 월 5~15달러로 떨어졌다. 큰 워크로드는 여전히 비싸지만, 예약형 capacity 청구서가 갑자기 튀는 사례를 보고 들어가는 게 안전하다.

1-2. 오브젝트 스토리지 혁명 — Turbopuffer의 충격

Simon Eskildsen이 Cursor·Notion에 깔리는 Turbopuffer를 만들면서 한 일은 단순했다. "기본 스토리지는 S3·GCS, SSD는 캐시로만 쓴다." 비용은 TB·월 약 70달러로, 전통적인 SSD 3중화(약 600달러)·RAM 캐시 기반(약 1,600달러) 대비 한 자릿수에서 두 자릿수 차이.

2026년 시점의 운영 규모:

도큐먼트 4조개+
초당 1천만+ 쓰기, 2.5만+ 쿼리
2024년 7월 기준 쿼리 단가를 최대 94% 인하

Zilliz는 "스토리지 비용이 전부는 아니다 — 콜드 데이터 미스 시 지연 페널티가 크다"고 반박했지만, 워크로드의 절대다수가 콜드라는 사실이 진영을 갈랐다. 검색 페이지의 롱테일·아카이브·다국어 인덱스에선 Turbopuffer 모델이 압도적으로 싸다.

1-3. "그냥 Postgres 써" 운동

Timescale(현 Tiger Data)이 만든 pgvectorscale이 결정타였다. pgvector 위에 StreamingDiskANN 인덱스 타입을 추가하면서, 5천만 벡터·768차원에서:

p95 지연: Pinecone s1 대비 28배 낮음
처리량: 16배 높음
99% recall에서 AWS EC2 자체 호스팅 시 비용 75% 절감

여기에 Statistical Binary Quantization(SBQ)·Filtered DiskANN(라벨 기반 사전 필터링) 같은 차별점이 붙었다. 2025년 11월에 v0.9.0이 나오면서 PG18과 동시 인덱스 빌드를 지원했고, 2026년 3월에 TimescaleDB 2.26.0과 함께 묶여 Tiger Cloud로 배포됐다.

핵심 메시지는 단순하다 — 이미 Postgres가 운영 중이면 새 DB를 들이지 마라.

2. 매니지드 SaaS — Pinecone Serverless, Turbopuffer, Zilliz Cloud

2-1. Pinecone Serverless

2026년 5월 시점 Pinecone의 위치는 "가장 무난한 매니지드 픽". 무료 티어가 넉넉해서 프로토타입은 사실상 무료, 인프라 운영 부담은 0. 단점은 두 가지:

lock-in: 인덱스 포맷이 외부와 호환되지 않는다. 마이그레이션은 일일이 업서트.
고동시성 청구서 점프: capacity 예약 fee가 별도 계측되는 구간이 있다. AI 에이전트가 초당 수십 쿼리를 날리는 워크로드에서 갑자기 튄다.

언제 고르나:

인프라 팀 없는 스타트업 + 1M~10M 벡터
"이번 분기에 결과를 내야 한다" + 운영 인력 없음
멀티 리전·HA가 SLA 요구사항

2-2. Turbopuffer

"오브젝트 스토리지 우선" 설계라는 단어 자체를 만든 회사. 핸드폰 인덱스부터 4조 도큐먼트까지 한 가격표로 쓴다. 2026년 가격대(공개 기준):

Launch: 월 64달러
Scale: 월 256달러
Enterprise: 별도

스토리지 약 0.02달러/GB(S3·GCS 직과), 캐시 SSD 약 0.1달러/GB, 쿼리·쓰기는 사용량 기반. 콜드 데이터 100배 저렴, 웜 데이터 6~20배 저렴이라는 주장이 운영 사례로 뒷받침된다(Cursor·Notion).

약점:

쿼리 지연의 분포: 캐시 미스 시 S3 fetch가 들어가서 p99가 튀는 패턴이 있다. 리얼타임 추천에서는 권장하지 않는다.
에코시스템: Pinecone·Qdrant만큼 통합·튜토리얼이 두텁지는 않다.

언제 고르나:

대량 인덱스(100M+) + 콜드 비중이 큰 데이터
비용에 민감한 검색·아카이브
"쿼리 한 번에 200ms 정도는 괜찮다"

2-3. Zilliz Cloud (Milvus 2.6 매니지드)

Zilliz Cloud는 2026년 1월 Milvus 2.6.x를 GA로 올렸다. 컴퓨트 시간당 0.096달러, 스토리지 GB·월 0.02달러. 강점은 두 가지:

GPU 인덱스 CAGRA(NVIDIA): 1억 벡터에서 단일 노드 GPU로 수십만 QPS
하이브리드 GPU·CPU 배포: GPU로 그래프 빌드, CPU로 검색

언제 고르나:

100M~10B 벡터 + GPU 인프라 확보 가능
분당 수만 쿼리의 멀티테넌트 SaaS
Spark·NVIDIA RAPIDS 같은 데이터 파이프라인과 함께 운영

3. 오픈소스 전용 엔진 — Qdrant, Weaviate, Milvus, Vespa, Vald

3-1. Qdrant — Rust, 필터 강자

Qdrant의 2026년은 두 가지 사건으로 요약된다.

v1.17 RocksDB 제거: 자체 스토리지 엔진 gridstore로 교체. v1.15에서 v1.17로 직행 업그레이드는 불가능, 1단계씩 거쳐야 한다.
시리즈 B 5천만 달러(2026년 3월): 엔터프라이즈 영업 본격화.

강점:

페이로드 필터링이 인덱스와 통합: category = 'X' AND created_at > '2026-01-01' 같은 정밀 필터에서 Weaviate·Pinecone보다 빠른 사례가 많다.
Rust 네이티브: 메모리 안전 + 단일 바이너리 배포. Helm 차트 한 줄로 끝.
샤딩·복제: 자체 호스팅에서 운영하기 쉬운 구조.

약점:

모듈러 RAG(Weaviate의 리랭커·생성기 모듈 같은)는 없다. 외부 파이프라인이 필요.

3-2. Weaviate — 모듈러 + 멀티벡터

Weaviate는 2026년 시점 하이브리드 검색·ColBERT 멀티벡터·리랭커 모듈에서 선두에 가깝다. BM25F + 밀집을 하나의 쿼리로 묶어 가중치·퓨전을 설정하는 게 1급 시민이다. 라이팅·생성기 모듈로 RAG 파이프라인 자체를 DB 안에 둘 수 있다.

언제 고르나:

GraphQL 친화, "DB가 RAG 파이프라인을 일부 흡수해도 좋음"
ColBERT v2 같은 멀티벡터 late-interaction 모델
하이브리드 검색을 한 쿼리로

3-3. Milvus — 스케일과 GPU

오픈소스 Milvus는 2.6.x에서 더 유연한 CAGRA 배포(하이브리드 GPU·CPU), 분리형 스토리지·인덱스 노드, 더 가벼운 메타데이터 서비스를 가져왔다. 자체 호스팅도 가능하지만, 실제 운영은 거의 다 Zilliz Cloud로 흐른다.

3-4. Vespa — 실시간 검색 + 벡터 하이브리드

Yahoo에서 분사된 Vespa는 2026년에 AI 검색 플랫폼으로 리브랜딩됐다. 강점은 "벡터 + BM25 + 텐서 + 머신러닝 랭킹을 하나의 쿼리로". Spotify 검색이 실시간 HNSW를 이걸로 굴린다.

특이점:

텐서 스토리지: 다차원 표현(텍스트·이미지·수치)을 한 곳에
랭킹 함수가 1급 시민: ML 랭킹을 DB 단에서 실행
운영 난이도가 가장 높다: Vespa는 가볍지 않다. 풀스택 검색팀이 필요.

언제 고르나:

검색 서비스를 본업으로 굴리는 팀
추천·랭킹·하이브리드를 한 쿼리로 묶고 싶음
Lucene·Solr 출신 인력이 있음

3-5. Vald — Yahoo Japan의 OSS

Vald는 Yahoo JAPAN이 NGT를 기반으로 만든 Kubernetes 네이티브 ANN 엔진. 빌리언 스케일을 밀리초로 처리하는 사례가 일본 내부에선 많다. 2024년 이후 글로벌 활동은 줄었지만, K8s 친화·gRPC 우선 설계는 여전히 가치가 있다. 일본 시장 또는 NGT 알고리즘 의존이 분명한 곳에 권장.

4. Postgres 진영 — pgvector + pgvectorscale + Supabase·Neon·Tiger

4-1. pgvector + pgvectorscale

2026년 5월 기준, "그냥 Postgres 써"가 농담이 아닌 이유:

pgvector 0.9.x: HNSW + IVFFlat. 트랜잭션·JOIN·JSONB와 한 자리에서 다룬다.
pgvectorscale: StreamingDiskANN 인덱스. 5천만 벡터 벤치에서 Pinecone s1 대비 p95 28배 낮음, 75% 비용 절감.
Filtered DiskANN: 라벨 기반 사전 필터링이 인덱스와 통합. "테넌트 ID = X AND 임베딩 ~ ..." 같은 멀티테넌트 RAG의 표준 쿼리가 빠르다.
SBQ(Statistical Binary Quantization): 메모리 점유를 1/32 수준으로 압축.

자체 호스팅 운영 시 단점:

HNSW 빌드 시간이 길다(수천만 벡터 기준 수십 분~수 시간).
HA·복제는 일반 Postgres 운영의 연장선 — 만만치 않다.
pg_repack·VACUUM 정책을 벡터 인덱스 관점에서 다시 짜야 한다.

4-2. 매니지드 — Supabase, Neon, Tiger Cloud

Supabase: pgvector를 1급 시민으로 모셔둔 BaaS. 인증·Realtime·Edge Functions까지 한 묶음. 100M 벡터까지 가성비 좋다.
Neon: 서버리스 Postgres + pgvector. branching·copy-on-write가 RAG 실험에서 강력하다.
Tiger Cloud(구 Timescale): pgvectorscale을 1급으로 굴리는 곳. 시계열·벡터 조합에서 가장 매끄럽다.

언제 고르나:

이미 Postgres 운영 중 + 1B 벡터 미만
트랜잭션·관계형 데이터와 벡터를 같은 트랜잭션에서 다뤄야 함
인프라 팀이 새 DB 들이는 걸 거부함 (현실)

5. 임베디드·분석형 — Chroma, LanceDB, DuckDB VSS

5-1. Chroma — 개발자 친화, Cloud 합류

Chroma는 1.0이 한참 지나 2026년 5월 기준 1.5.9. 2025년 8월 Chroma Cloud GA, 11월 BM25·SPLADE 희소 벡터 1급 지원, 2026년 1월 CMEK, 2월 메타데이터 배열·contains 연산자.

여전히 가장 "쉬운" 시작점이다. pip install chromadb로 5분이면 RAG 데모 완성. 하지만 1억 벡터 이상에선 다른 도구가 낫다.

5-2. LanceDB — Lance 컬럼나, 임베디드 우선

LanceDB는 Lance 컬럼나 포맷 위에 만든 인프로세스 벡터 DB. Rust로 코어를 짰고, Python·Node·Rust·REST API를 제공한다. "데이터 레이크 위의 벡터"라는 포지셔닝이 분명하다.

장점:

인프로세스 + 제로카피: 서버 없이도 빠르다.
컬럼나 분석: 벡터·텍스트·메타데이터를 한 파일에 두고 SQL·DataFrame으로 조회.
버전 관리: Lance 포맷이 트랜잭션·버전 관리를 지원.

언제 고르나:

노트북·CLI·로컬 RAG
데이터 레이크(S3·GCS) 위에 벡터를 같이 두고 싶음
ML 워크플로 + 멀티모달

5-3. DuckDB VSS — 분석 한복판에서 벡터

DuckDB의 VSS 익스텐션은 ARRAY 컬럼 위에 HNSW 인덱스를 만든다. INSTALL vss; LOAD vss; 두 줄로 끝. array_cosine_distance, array_negative_inner_product가 인덱스로 가속된다.

INSTALL vss;
LOAD vss;
CREATE TABLE docs (id INTEGER, embedding FLOAT[768]);
CREATE INDEX idx ON docs USING HNSW (embedding)
  WITH (metric = 'cosine');
SELECT id FROM docs
ORDER BY array_cosine_distance(embedding, ?::FLOAT[768])
LIMIT 5;

VSS는 아직 실험적(experimental)이라 프로덕션 권장은 아니다. 그러나 분석 워크플로 안에서의 벡터 검색(데이터 사이언티스트의 노트북에서 임시 인덱스 띄워 탐색) 용도는 이미 강력하다.

언제 고르나:

데이터 분석 파이프라인 + 임시 벡터 검색
"ETL 한 번 돌리고, 인덱스 만들고, 검색해보고, 결과 보고서 만들기"

6. 범용 DB의 벡터 — MongoDB Atlas, Couchbase, Elasticsearch/OpenSearch

기존 DB들이 벡터 컬럼·인덱스를 붙이는 흐름이 2024~2026 사이에 사실상 표준이 됐다.

MongoDB Atlas Vector Search: 매니지드. 도큐먼트 + 벡터를 같은 컬렉션에. 도큐먼트 DB 사용자에겐 편하다.
Couchbase Vector Search: 마찬가지로 매니지드, FTS + 벡터 조합.
Elasticsearch/OpenSearch kNN: BM25 + 밀집 벡터 하이브리드. 운영 부담은 적지 않지만, 이미 ES 운영 중이라면 자연스러운 선택.
Redis Stack의 벡터 인덱스: 캐시·세션 + 벡터. 작은 데이터셋에서 빠름.

이쪽 진영의 가치 명제는 단순하다 — "이미 우리 DB가 있으면 벡터 컬럼 하나 더 만들고 끝낸다." 운영 일관성이 가장 큰 장점.

7. 하이브리드 검색 표준 — BM25 + 밀집 + 리랭커

2026년에 "벡터 검색만으로 충분하다"는 주장은 거의 사라졌다. 표준 RAG 파이프라인은 세 단계.

질의(query)
  ├─ BM25 검색 (희소) ──┐
  ├─ 밀집 벡터 검색 ─────┼──> Reciprocal Rank Fusion 또는 가중합
  └─ (선택) ColBERT/Late ┘
                            │
                            ▼
                        후보 50~200건
                            │
                            ▼
                  Cross-Encoder 리랭커
                  (Cohere Rerank 3.5,
                   Voyage Rerank 2.5,
                   Jina Reranker v3,
                   BGE Reranker)
                            │
                            ▼
                        최종 5~10건 → LLM

임베딩·리랭커 풍경 (2026년 4월 MTEB 기준)

임베딩 — voyage-3-large (Voyage AI): retrieval 단독 최고 점수에 가까움
NV-Embed-v2: 전체 MTEB 평균 1위급
OpenAI text-embedding-3-large: 범용 기본값
Cohere embed-v3 + Rerank v3.5: 페어 운영 시 강력
BGE-M3: 100+ 언어 멀티링구얼, 자체 호스팅 표준
Nomic Embed v2: 멀티링구얼 저비용
Jina Reranker v3: BEIR nDCG@10에서 61.94로 평가 대상 중 최고, 188ms 지연
Cohere Rerank 3.5 / Voyage Rerank 2.5: 평균 600ms 내외

운영 팁:

BM25를 끄지 마라. 고유명사·코드·약어에서 밀집 벡터가 약하다.
리랭커는 반드시 cross-encoder. bi-encoder를 두 번 돌리는 게 아니다.
임베딩 모델은 바꿀 일이 생긴다. 인덱스 재빌드 비용을 처음부터 잡아두자.

8. 비용 매트릭스 — 1M 벡터당 월 얼마인가

대략의 자체 산정. 1M 벡터, 1536차원, 일일 1만 쿼리, 한국·미국 리전 자체 호스팅 또는 매니지드 표준 플랜 가정. 정확한 단가는 운영 패턴·약정에 따라 다르다.

옵션	월 비용 추정	비고
Pinecone Serverless (Standard)	5~30달러	무료 티어가 2GB·5인덱스이므로 1M·1536D면 free에 거의 들어옴
Turbopuffer (Launch)	64달러 고정 + 사용량	인덱스 여러 개 합쳐도 1M은 Launch 안
Zilliz Cloud (Serverless 소형)	30~80달러	CU 시간당 0.096달러 + 스토리지
Qdrant Cloud	25~70달러	단일 노드 기준
Weaviate Cloud	25~80달러	모듈 활성화 따라 변동
pgvector + pgvectorscale on Tiger	20~60달러	시계열·트랜잭션 같이 사용 시 가성비 좋음
Supabase (Pro + pgvector)	25달러부터	인증·Realtime 포함
Neon (서버리스 pgvector)	19달러부터	branching이 강력
LanceDB OSS	0달러	스토리지 비용만 (S3 등)
Chroma OSS	0달러	인프라 비용만
DuckDB VSS	0달러	인프로세스, 실험적
MongoDB Atlas Vector	30~100달러	M10 인스턴스부터
Elasticsearch (Elastic Cloud)	95달러부터	BM25 + kNN

100M 벡터 구간에서 격차가 벌어진다. Turbopuffer·pgvectorscale·Milvus 자체 호스팅이 가격·성능 비율에서 강하다. 1B 벡터 이상이면 Milvus/Vespa/Vald 같은 분산 엔진이 사실상 필수.

9. 결정 다이어그램 — "pgvector vs 전용" 갈림길

                          ┌──────────────────────────────┐
                          │  벡터 100K 미만, 프로토타입   │──> Chroma / LanceDB / DuckDB VSS
                          └──────────────────────────────┘
                                       │
                                       ▼
                          ┌──────────────────────────────┐
                          │ 이미 Postgres 운영 중?       │
                          └─────────────┬────────────────┘
                                        │
                          예 ◀──────────┴──────────▶ 아니오
                          │                          │
                          ▼                          ▼
            ┌────────────────────────┐   ┌──────────────────────────┐
            │ 벡터 1B 미만 +         │   │ 인프라 팀 없음 +         │
            │ 트랜잭션·JOIN 필요     │   │ "이번 분기에 결과"        │──> Pinecone Serverless
            │ → pgvector +            │   └─────────────┬────────────┘
            │   pgvectorscale         │                 │
            │   (Tiger / Supabase /   │                 ▼
            │    Neon)                │   ┌──────────────────────────┐
            └────────────────────────┘   │ 콜드 비중 큼 + 비용 민감 │──> Turbopuffer
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ 자체 호스팅 OK +          │
                                         │ 필터·페이로드 강함        │──> Qdrant
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ ColBERT 멀티벡터 +        │
                                         │ 모듈러 RAG               │──> Weaviate
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ 100M+ + GPU 인프라        │──> Milvus / Zilliz
                                         └─────────────┬────────────┘
                                                       │
                                                       ▼
                                         ┌──────────────────────────┐
                                         │ 검색이 본업 +             │
                                         │ ML 랭킹 통합             │──> Vespa
                                         └──────────────────────────┘

기본 분기점은 단순하다.

이미 Postgres가 있으면 pgvector + pgvectorscale부터 시도. 90%의 RAG는 여기서 끝난다.
운영 인력이 없으면 Pinecone Serverless. 무료 티어가 넓다.
콜드 데이터가 많으면 Turbopuffer. 가격이 한 자릿수 다르다.
필터가 강하면 Qdrant, 모듈러 RAG면 Weaviate, 스케일·GPU면 Milvus/Zilliz, 검색이 본업이면 Vespa.
노트북·CLI는 Chroma·LanceDB·DuckDB VSS.

10. 운영 안티패턴

운영에서 자주 보는 사고들. 정직하게 적어두자.

임베딩 모델 사일런트 교체: text-embedding-ada-002에서 voyage-3-large로 바꾸면서 인덱스 재빌드를 안 하면, 코사인 거리 공간이 달라 검색 품질이 무너진다. 반드시 재빌드 + A/B 검증.
BM25를 끔: 코드·고유명사·약어에서 밀집 벡터는 약하다. 사내 위키에서 K8s, pgbouncer, RAGAS가 안 나오면 거의 이 케이스.
리랭커를 건너뜀: top-50 후보를 cross-encoder로 재정렬하지 않으면, RAG 답변 품질의 30% 이상이 모래에 묻힌다.
HNSW M·ef_construction을 기본값으로 둠: 작은 데이터셋에선 차이가 안 보여도, 1M 넘어가면 recall 차이가 벌어진다. 차원·분포·쿼리 패턴에 맞춰 튜닝.
필터를 인덱스 밖에서 함: Qdrant·pgvectorscale의 강점은 필터를 인덱스 안으로. 멀티테넌트 RAG에서 테넌트 ID를 페이로드 필터로 인덱스에 넣어야 빠르다.
메타데이터에 BLOB을 박음: 벡터 DB에 큰 텍스트·이미지를 저장하면 read unit이 폭주한다. 참조만 두고 본문은 오브젝트 스토리지.
재시도·백오프 없음: 매니지드 SaaS는 429를 자주 던진다. exponential backoff + jitter는 옵션이 아니다.
모니터링 = 평균 지연 하나만: p50은 의미가 적다. p95·p99·recall@k가 함께 가야 한다.
벡터 DB lock-in을 무시함: Pinecone에서 마이그레이션은 일일이 업서트. 임베딩 원본을 S3·GCS에 항상 따로 보관.
"RAG 한다면서 인덱스에 전부 다 박음": 검색 풀에 노이즈 문서가 50%면, 어떤 DB를 써도 답변 품질은 무너진다. 선별·청크 전략이 DB 선택보다 먼저.

11. 에필로그 — 체크리스트와 다음 글 예고

결정 체크리스트

운영을 시작하기 전에 자기 자신에게 던지는 질문 12개.

다음 글 예고

다음 글에서는 **"RAG 평가 파이프라인 핸즈온 — RAGAS·Ragas·Phoenix·LangSmith로 retriever·reranker·generator를 각각 측정하기"**를 다룬다. 벡터 DB를 골랐다고 끝이 아니다. 답변 품질이 떨어지면 어디서 떨어졌는지(retrieval recall·rerank precision·generation faithfulness) 분리해 측정할 수 있어야 운영이 된다. 본문에서 다룬 모든 DB가 같은 평가 프레임 안에서 비교 가능해진다.

프롤로그 — 2년 사이에 지형이 통째로 바뀌었다

1. 무엇이 바뀌었나 — 가격 붕괴와 오브젝트 스토리지 혁명

1-1. 가격 곡선

1-2. 오브젝트 스토리지 혁명 — Turbopuffer의 충격

1-3. "그냥 Postgres 써" 운동

2. 매니지드 SaaS — Pinecone Serverless, Turbopuffer, Zilliz Cloud

2-1. Pinecone Serverless

2-2. Turbopuffer

2-3. Zilliz Cloud (Milvus 2.6 매니지드)

3. 오픈소스 전용 엔진 — Qdrant, Weaviate, Milvus, Vespa, Vald

3-1. Qdrant — Rust, 필터 강자

3-2. Weaviate — 모듈러 + 멀티벡터

3-3. Milvus — 스케일과 GPU

3-4. Vespa — 실시간 검색 + 벡터 하이브리드

3-5. Vald — Yahoo Japan의 OSS

4. Postgres 진영 — pgvector + pgvectorscale + Supabase·Neon·Tiger

4-1. pgvector + pgvectorscale

4-2. 매니지드 — Supabase, Neon, Tiger Cloud

5. 임베디드·분석형 — Chroma, LanceDB, DuckDB VSS

5-1. Chroma — 개발자 친화, Cloud 합류

5-2. LanceDB — Lance 컬럼나, 임베디드 우선

5-3. DuckDB VSS — 분석 한복판에서 벡터

6. 범용 DB의 벡터 — MongoDB Atlas, Couchbase, Elasticsearch/OpenSearch

7. 하이브리드 검색 표준 — BM25 + 밀집 + 리랭커

임베딩·리랭커 풍경 (2026년 4월 MTEB 기준)

8. 비용 매트릭스 — 1M 벡터당 월 얼마인가

9. 결정 다이어그램 — "pgvector vs 전용" 갈림길

10. 운영 안티패턴

11. 에필로그 — 체크리스트와 다음 글 예고

결정 체크리스트

다음 글 예고

참고 / References