목차
- 벡터 데이터베이스, 왜 고민이 되는가
- 세 가지 후보의 성격
- 비교 기준 네 가지
- 비용 — 규모별로 완전히 달라지는 구간
- 쿼리 성능 — 체감 차이가 나는 구간
- 운영 복잡도 — 여기서 실질적 차이가 난다
- 하이브리드 검색이 필요한 경우
- 마이그레이션 난이도
- 언제 뭘 쓸 것인가
벡터 데이터베이스, 왜 고민이 되는가
사내 문서 검색용 RAG 파이프라인을 만들면서 벡터 데이터베이스 선택 기준을 잡는 데만 일주일을 썼다. 결과적으로 pgvector로 시작해서 Pinecone Serverless로 전환했는데, 처음부터 이 글에서 정리하는 기준을 알았으면 사흘은 줄였을 거다.
프론트엔드에서 백엔드로 전환한 지 2년 정도 됐다. 프론트 시절에는 상태 관리 라이브러리 고르는 게 제일 큰 의사결정이었는데, 백엔드로 넘어오니 인프라 선택이 훨씬 무겁다. 벡터DB는 한 번 정하면 마이그레이션 비용이 크기 때문에 초기 선택이 중요하다. 특히 RAG 서비스는 벡터 수가 수만에서 수백만까지 금방 불어나기 때문에, "지금 당장"이 아니라 "6개월 후"를 기준으로 골라야 한다.
이 글에서는 Pinecone, Weaviate, pgvector 세 가지를 놓고 비용, 성능, 운영 복잡도, 확장성 네 가지 축으로 비교한다. 벤치마크 수치를 지어내지는 않겠고, 직접 운영하면서 체감한 부분 위주로 쓴다.
세 가지 후보의 성격
비교에 앞서 각 벡터DB의 포지셔닝부터 짚고 넘어가자. 같은 "벡터 데이터베이스"라는 이름을 쓰지만 철학이 꽤 다르다.
Pinecone — 완전 매니지드의 대표
Pinecone은 벡터 검색만을 위해 만들어진 전용 매니지드 서비스다. 인프라 관리가 전혀 필요 없다. 2024년 초에 Serverless 아키텍처로 전환하면서 가격이 크게 내려갔고, 2026년 현재 대부분의 신규 프로젝트는 Serverless 플랜을 쓴다. API가 단순해서 러닝커브가 거의 없다. upsert하고 query 날리면 끝이다.
from pinecone import Pinecone
pc = Pinecone(api_key="your-api-key")
index = pc.Index("rag-docs")
# 벡터 업서트
index.upsert(vectors=[
{"id": "doc-001", "values": embedding, "metadata": {"source": "wiki", "page": 12}}
])
# 쿼리 — top_k로 결과 수 지정
results = index.query(vector=query_embedding, top_k=5, include_metadata=True)
코드가 이게 전부다. 인덱스 생성도 웹 콘솔에서 클릭 몇 번이면 된다.
Weaviate — 하이브리드 검색의 강자
Weaviate는 벡터 검색과 키워드 검색(BM25)을 동시에 지원하는 게 가장 큰 특징이다. GraphQL 기반 API를 쓰고, 모듈 시스템으로 임베딩 생성까지 DB 안에서 처리할 수 있다. Weaviate Cloud Service(WCS)로 매니지드 운영도 가능하고, Docker로 셀프호스팅도 된다.
셀프호스팅을 시도했을 때 docker-compose.yml 설정이 생각보다 까다로웠다. 환경 변수 하나 빠뜨리면 컨테이너가 올라오다가 죽는데, 에러 메시지가 친절하지 않다.
# docker-compose.yml — Weaviate 셀프호스팅 최소 구성
services:
weaviate:
image: cr.weaviate.io/semitechnologies/weaviate:1.28.4
ports:
- "8080:8080"
- "50051:50051" # gRPC 포트, 빠뜨리면 클라이언트 연결 실패
environment:
QUERY_DEFAULTS_LIMIT: 25
AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true'
PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
DEFAULT_VECTORIZER_MODULE: 'none' # 외부 임베딩 쓸 때
CLUSTER_HOSTNAME: 'node1'
50051 gRPC 포트를 빠뜨려서 Python 클라이언트가 ConnectionError를 뱉은 적이 있다. 공식 문서(출처: Weaviate Docs, Installation > Docker Compose)에는 나와 있긴 한데, 퀵스타트 예제에서는 빠져 있어서 놓치기 쉽다.
pgvector — 이미 있는 PostgreSQL 활용
pgvector는 PostgreSQL 확장이다. 이게 가장 큰 장점이자 단점이다. 이미 PostgreSQL을 쓰고 있으면 CREATE EXTENSION vector; 한 줄로 벡터 검색을 추가할 수 있다. 별도 인프라가 필요 없다.
pgvector 0.8.0(2025년 1월 릴리즈, 출처: GitHub pgvector/pgvector releases)부터 HNSW 인덱스 성능이 크게 개선됐고, 스트리밍 디스크 ANN도 들어왔다. 소규모에서는 전용 벡터DB와 체감 차이가 거의 없다.
비교 기준 네 가지
벡터 데이터베이스 선택 기준은 사실 단순하다. 팀 상황에 따라 가중치만 달라질 뿐이다.
| 기준 | 의미 | 가중치가 높아지는 상황 |
|---|---|---|
| 비용 | 월 운영비 + 숨겨진 비용 | 스타트업, 사이드 프로젝트 |
| 쿼리 성능 | 검색 지연시간(p50, p99) | 실시간 서비스, 채팅봇 |
| 운영 복잡도 | 배포, 모니터링, 백업 난이도 | DevOps 인력 부족 |
| 확장성 | 벡터 수 증가 대응력 | 데이터 증가 예측 가능 |
이 네 가지를 축으로 각 DB를 비교한다.
비용 — 규모별로 완전히 달라지는 구간
비용이 가장 중요한 비교 항목이다. 세 제품 모두 과금 구조가 다르기 때문에, 같은 규모에서도 비용 차이가 크다.
소규모: 벡터 10만 개 이하
이 구간에서는 pgvector가 압도적으로 유리하다. 이미 PostgreSQL을 쓰고 있다면 추가 비용이 0원이다. Pinecone Serverless 무료 티어도 있긴 한데, 인덱스 1개 제한에 벡터 수 상한이 있어서 프로덕션에는 애매하다. Weaviate Cloud의 Sandbox도 14일 제한이라 테스트용으로만 쓸 만하다.
중규모: 벡터 10만~100만 개
이 구간부터 고민이 시작된다. pgvector는 HNSW 인덱스를 걸면 메모리를 꽤 먹는다. 벡터 차원이 1536(OpenAI text-embedding-3-small 기준)이고 50만 개면, 인덱스만 약 3~4GB 메모리를 잡아먹는다. RDS db.r6g.xlarge 기준으로 월 $350 정도다.
Pinecone Serverless는 이 구간에서 월 $70~$150 정도 나온다. 읽기 유닛(RU) 기반 과금이라 트래픽에 따라 변동이 있다. 월 쿼리 수가 100만 회 미만이면 $100 이하로도 가능하다.
Weaviate Cloud는 Starter 플랜 기준 비슷한 규모에서 월 $100~$200 선이다.
대규모: 벡터 100만 개 이상
이 구간에서 pgvector는 선택지에서 빠진다고 보는 게 맞다. 못 쓰는 건 아니지만, PostgreSQL 하나에 벡터 수백만 개를 넣으면 일반 쿼리 성능에도 영향이 간다. 파티셔닝으로 버틸 수는 있는데, 그 시점이면 전용 벡터DB를 쓰는 게 운영 비용까지 합산하면 더 싸다.
Pinecone은 벡터 수가 늘어도 비교적 선형적으로 비용이 증가한다. 1000만 벡터 기준으로 월 $200~$500 정도. Weaviate는 셀프호스팅으로 가면 인프라 비용만 내면 되니 상한선을 직접 통제할 수 있다. 대신 DevOps 리소스가 든다.
쿼리 성능 — 체감 차이가 나는 구간
솔직히 벡터 10만 개 이하에서는 세 제품 다 빠르다. 체감 차이 없다. p50 기준으로 전부 20ms 이내다. 차이가 나기 시작하는 건 50만 개 넘어가면서다.
pgvector에 HNSW 인덱스를 걸었을 때, 벡터 50만 개 기준으로 p50은 15ms 정도였는데 p99가 120ms까지 튀었다. PostgreSQL이 다른 쿼리도 처리하고 있었기 때문에, 벡터 검색 전용으로 쓰는 게 아니면 p99 지터가 생긴다.
Pinecone Serverless는 같은 규모에서 p50 12ms, p99 45ms 정도를 보여줬다. 콜드 스타트가 있어서 오래 안 쓰다가 쿼리를 날리면 첫 응답이 200ms 이상 걸리는 경우가 있었다. 이건 Serverless 아키텍처의 특성이라 어쩔 수 없다.
Weaviate는 셀프호스팅 기준으로 리소스를 얼마나 할당하느냐에 따라 갈린다. 4vCPU/16GB 환경에서 50만 벡터 기준 p50 10ms, p99 35ms 정도. 리소스를 넉넉히 주면 성능은 가장 좋았는데, 그만큼 인프라 비용이 올라가니 공짜는 아니다.
운영 복잡도 — 여기서 실질적 차이가 난다
성능이나 비용보다 운영 복잡도가 실제 의사결정에서 더 크게 작용했다. 특히 백엔드 인력이 2~3명인 팀에서는 인프라 관리에 시간을 쓸 여유가 없다.
Pinecone: 거의 신경 쓸 게 없다
백업, 스케일링, 모니터링 전부 Pinecone이 알아서 한다. 대시보드에서 인덱스별 쿼리 수, 레이턴시, 벡터 수를 확인할 수 있고, 별도 모니터링 구축이 필요 없다. 업그레이드도 자동이다. 운영 관점에서는 가장 편하다.
Weaviate: 셀프호스팅이면 각오해야 한다
WCS를 쓰면 Pinecone과 비슷한 수준이다. 셀프호스팅을 택하면 얘기가 달라진다. Docker 컨테이너 관리, 볼륨 백업, 버전 업그레이드를 직접 해야 한다. Kubernetes 위에 올리면 Helm 차트가 있긴 하지만, Weaviate 클러스터의 노드 간 데이터 동기화 이슈를 디버깅하는 건 쉽지 않다.
RAG 파이프라인을 처음 구축할 때 Weaviate를 Docker로 띄워봤는데, 컨테이너가 OOM(Out of Memory)으로 죽는 걸 두 번 겪었다. 벡터 임포트 중에 메모리 제한을 제대로 안 걸어서 생긴 문제였다. LIMIT_RESOURCES 환경 변수 설정이 필요한데, 이건 트러블슈팅하면서 GitHub Issues(#4521)에서 찾았다.
pgvector: PostgreSQL을 이미 잘 다루면 쉽다
pgvector 자체는 간단하다. PostgreSQL 운영 경험이 있으면 추가 러닝커브가 거의 없다. 인덱스 생성, VACUUM, 통계 업데이트 같은 기존 PostgreSQL 운영 지식이 그대로 적용된다.
-- pgvector HNSW 인덱스 생성
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);
-- ef_search 값으로 검색 정확도/속도 트레이드오프 조절
SET hnsw.ef_search = 100; -- 기본값 40, 높이면 정확도↑ 속도↓
m과 ef_construction 값을 어떻게 잡느냐에 따라 인덱스 빌드 시간과 검색 품질이 달라진다. 공식 문서(출처: GitHub pgvector/pgvector README)에서는 m = 16, ef_construction = 64를 기본값으로 안내하는데, 실제로 RAG용으로 쓸 때는 ef_construction = 200 정도가 recall 기준으로 더 나았다. 인덱스 빌드 시간이 2~3배 늘어나지만, 벡터 50만 개 기준으로도 10분 이내라 감수할 만하다.
하이브리드 검색이 필요한 경우
여기서 Weaviate가 빛난다. RAG에서 순수 벡터 검색만으로는 부족한 경우가 꽤 있다. "2024년 3분기 매출 보고서"를 찾을 때, 벡터 유사도만으로는 연도나 분기를 정확히 잡아내지 못한다. 키워드 매칭이 필요한 순간이다.
Weaviate는 BM25와 벡터 검색을 alpha 파라미터 하나로 블렌딩한다.
import weaviate
client = weaviate.connect_to_local()
collection = client.collections.get("Document")
# alpha=0.7이면 벡터 70% + BM25 30% 가중
response = collection.query.hybrid(
query="2024년 3분기 매출",
alpha=0.7,
limit=5
)
for obj in response.objects:
print(obj.properties["title"], obj.metadata.score)
Pinecone도 2024년에 Sparse-Dense 벡터를 지원하기 시작했지만, Weaviate만큼 자연스럽지는 않다. pgvector에서 하이브리드 검색을 구현하려면 tsvector와 벡터 검색 결과를 직접 합쳐야 한다. 할 수는 있는데 코드가 지저분해진다.
하이브리드 검색이 핵심 요구사항이면 Weaviate를 추천한다. 그게 아니면 굳이 Weaviate를 고를 이유가 줄어든다.
마이그레이션 난이도
이건 간단하다. 세 제품 모두 벡터를 추출해서 다시 넣는 방식이라, 마이그레이션 자체의 기술적 난이도는 비슷하다. 차이는 벡터 수에 비례하는 소요 시간뿐이다. 100만 벡터 기준으로 임베딩을 다시 생성하지 않고 벡터만 옮긴다면 1~2시간이면 충분하다. 임베딩 재생성이 필요하면 OpenAI API 비용이 추가로 든다. text-embedding-3-small 기준 100만 문서면 $1~$2 정도.
언제 뭘 쓸 것인가
규모별 권장 선택을 정리하면 이렇다.
| 상황 | 권장 | 이유 |
|---|---|---|
| PoC/사이드 프로젝트 (벡터 <5만) | pgvector | 추가 비용 0, 기존 DB 활용 |
| 스타트업 MVP (벡터 5만~30만) | pgvector 또는 Pinecone Free | pgvector로 시작, 한계 오면 전환 |
| 프로덕션 서비스 (벡터 30만~200만) | Pinecone Serverless | 운영 부담 최소, 비용 예측 가능 |
| 하이브리드 검색 필수 | Weaviate Cloud | BM25+벡터 네이티브 지원 |
| 대규모 + DevOps 팀 있음 | Weaviate 셀프호스팅 | 비용 상한 통제, 커스터마이징 자유 |
| 이미 PostgreSQL 운영 중 + 벡터 <50만 | pgvector | 인프라 추가 없이 바로 시작 |
처음 RAG 파이프라인을 구축할 때 Weaviate 셀프호스팅부터 시작했다가 OOM 이슈와 Docker 네트워크 설정에 시간을 너무 많이 썼다. 돌아보면 pgvector로 빠르게 시작해서 프로덕트 검증부터 하는 게 맞았다. 기술 선택에 시간을 쓰는 것보다 RAG 파이프라인의 청킹 전략이나 프롬프트 튜닝에 시간을 쓰는 게 서비스 품질에 훨씬 직접적인 영향을 준다.
벡터 데이터베이스 선택 기준을 다시 요약하면, 세 가지 액션으로 정리된다. 첫째, PostgreSQL을 이미 쓰고 있고 벡터 50만 이하라면 pgvector로 시작하라. 둘째, 벡터가 50만을 넘어가거나 운영 리소스를 줄이고 싶으면 Pinecone Serverless로 옮겨라. 셋째, 키워드+벡터 하이브리드 검색이 핵심이면 Weaviate를 선택하라. 현재 pgvector 0.8 + PostgreSQL 17 조합으로 운영 중인데, 벡터가 40만을 넘어가는 시점에서 Pinecone 전환을 준비하고 있다.
관련 글
- Python LangChain RAG 구축 — 청킹 전략과 벡터DB 선택이 답변 품질을 갈랐다 – 사내 위키 800페이지를 검색하는 RAG 챗봇을 LangChain으로 구축했다. 벡터DB 선택에 2주를 쓴 뒤에야 청킹 전략이 답변 품질의…
- OpenAI Assistants API로 RAG 구축하기 — 파일 검색부터 함수 호출까지 – LangChain + ChromaDB 조합의 RAG 파이프라인을 OpenAI Assistants API로 교체한 경험이다. 벡터스토어 자동…
- PostgreSQL vs MySQL 선택 기준 — 2026년 신규 프로젝트 실전 비교 – PostgreSQL과 MySQL 중 뭘 골라야 하는지, JSON 쿼리 성능·확장성·AI 인프라 연동까지 직접 써보고 비교한 기록이다. 통념…
