이 글은 누구를 위한 것인가
- RAG 시스템을 구축하면서 어떤 벡터 DB를 써야 할지 결정해야 하는 엔지니어
- pgvector로 시작했는데 규모가 커지면서 성능이 걱정되는 팀
- 벡터 DB 비교 글을 읽었지만 "그래서 나는 무엇을 쓰면 되나요?"가 명확하지 않은 개발자
벡터 DB가 필요한 이유
LLM은 텍스트를 벡터(고차원 숫자 배열)로 표현한다. 의미적으로 유사한 텍스트는 벡터 공간에서 가깝다. 벡터 DB는 이 고차원 벡터에 대해 빠른 근사 최근접 이웃 탐색(ANN) 을 제공한다.
"나이키 러닝화 추천해줘"와 "조깅용 운동화 알려줘"는 단어가 다르지만 벡터 공간에서 가까운 위치에 있다. 기존 키워드 검색으로는 연결할 수 없는 의미 기반 검색이 가능해진다.
주요 옵션 개요
| Pinecone | Weaviate | pgvector | Qdrant | |
|---|---|---|---|---|
| 유형 | 완전 관리형 SaaS | 오픈소스 / 클라우드 | PostgreSQL 확장 | 오픈소스 / 클라우드 |
| 운영 부담 | 없음 | 중간 | 낮음 (PG 있다면) | 낮음~중간 |
| 비용 | 유료 (벡터 수 기준) | 자체 호스팅 무료 | PostgreSQL 비용만 | 자체 호스팅 무료 |
| ANN 알고리즘 | HNSW | HNSW | HNSW, IVFFlat | HNSW |
| 메타데이터 필터 | 지원 | 매우 강력 | SQL 조건 | 지원 |
| 멀티 테넌시 | 네임스페이스 | 클래스 격리 | 테이블/스키마 | 컬렉션 |
| 하이브리드 검색 | 미지원 | 지원 | 별도 구현 필요 | 지원 |
1. pgvector: 이미 PostgreSQL을 쓰고 있다면
언제 선택하는가
- 이미 PostgreSQL 인프라가 있다
- 벡터 수가 100만 미만 (그 이상은 성능 테스트 필요)
- 벡터와 관계형 데이터를 JOIN해서 조회해야 한다
- 인프라 추가 없이 벡터 검색을 빠르게 시작하고 싶다
핵심 사용법
-- 확장 설치
CREATE EXTENSION vector;
-- 임베딩 컬럼 추가
ALTER TABLE documents ADD COLUMN embedding vector(1536);
-- HNSW 인덱스 생성 (cosine 유사도 기준)
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- 유사도 검색
SELECT id, title, 1 - (embedding <=> :query_embedding) AS similarity
FROM documents
WHERE category = 'tech' -- 메타데이터 필터 (SQL)
ORDER BY embedding <=> :query_embedding
LIMIT 10;
한계
- 수천만 벡터 이상에서 HNSW 인덱스 빌드 시간과 메모리 사용량이 급증
- 하이브리드 검색(키워드 + 벡터)은 PostgreSQL FTS와 직접 조합해야 함
- 벡터 전용 튜닝 옵션이 전문 벡터 DB보다 제한적
2. Qdrant: 성능과 운영 편의성의 균형
언제 선택하는가
- 자체 호스팅을 원하지만 운영 복잡도를 낮추고 싶다
- 메타데이터 필터링이 중요하다
- 하이브리드 검색(벡터 + 키워드)이 필요하다
- 100만~1억 벡터 규모
핵심 사용법
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue
client = QdrantClient("localhost", port=6333)
# 컬렉션 생성
client.create_collection(
collection_name="documents",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
# 문서 삽입
client.upsert(
collection_name="documents",
points=[
PointStruct(
id=doc_id,
vector=embedding,
payload={"title": title, "category": category, "date": date}
)
]
)
# 필터와 함께 검색
results = client.search(
collection_name="documents",
query_vector=query_embedding,
query_filter=Filter(
must=[FieldCondition(key="category", match=MatchValue(value="tech"))]
),
limit=10,
with_payload=True
)
강점
- 페이로드 필터링: 검색과 필터를 동시에 효율적으로 처리 (post-filtering 대비 성능 우월)
- Sparse + Dense 하이브리드: BM25 + 임베딩을 네이티브로 지원
- Docker로 즉시 시작 가능:
docker run -p 6333:6333 qdrant/qdrant
3. Weaviate: 풍부한 스키마와 GraphQL
언제 선택하는가
- 객체 중심의 풍부한 스키마 모델링이 필요하다
- GraphQL API로 접근하는 것이 편하다
- 멀티모달(텍스트 + 이미지) 벡터가 필요하다
- Weaviate Cloud의 관리형 서비스를 원한다
특징
- Auto-vectorization: OpenAI, Cohere 등 외부 임베딩 모델과 직접 통합, 문서를 넣으면 자동으로 임베딩
- GraphQL API: 복잡한 쿼리를 선언적으로 표현
- 하이브리드 검색: BM25 + 벡터를
alpha파라미터로 비율 조정
한계
- 학습 곡선이 높음 (Weaviate만의 개념과 스키마 모델 이해 필요)
- 자체 호스팅 시 메모리 사용량이 큼
- 소규모 프로젝트에는 과도한 복잡성
4. Pinecone: 운영 없이 시작하고 싶다면
언제 선택하는가
- 인프라 관리 없이 즉시 프로덕션 수준의 벡터 검색이 필요하다
- 팀에 ML 인프라 전문가가 없다
- 빠른 프로토타입 후 스케일이 필요하다
특징
- 완전 관리형: 인덱스 관리, 리플리케이션, 스케일링 자동
- 네임스페이스: 멀티 테넌시를 네임스페이스로 간단 구현
- Serverless 플랜: 스토리지 기반 과금, 소규모 비용 절감
한계
- 비용: 사용량이 늘면 자체 호스팅 대비 비싸짐
- 메타데이터 필터: 지원하지만 Qdrant/Weaviate보다 제한적
- 하이브리드 검색: 네이티브 미지원 (별도 구현 필요)
- 벤더 락인: 데이터 이전이 번거로움
5. 선택 기준 정리
기존에 PostgreSQL을 쓰고 있는가?
└─ YES + 벡터 수 < 100만 → pgvector
인프라 운영 없이 SaaS를 원하는가?
└─ YES → Pinecone (비용 감당 가능한지 확인)
자체 호스팅을 원하는가?
├─ 메타데이터 필터 + 하이브리드 검색 중요 → Qdrant
└─ 풍부한 스키마 + GraphQL + 멀티모달 → Weaviate
규모는?
├─ < 100만 벡터: pgvector or Qdrant
├─ 100만 ~ 1억: Qdrant or Weaviate or Pinecone
└─ 1억+: Qdrant (자체 호스팅) or Pinecone (SaaS)
운영 고려사항
공통으로 필요한 것
- 임베딩 모델 버전 관리: 임베딩 모델을 바꾸면 전체 재임베딩 필요. 모델 버전을 메타데이터에 기록한다
- 차원 수 고정: 1536(OpenAI text-embedding-3-small), 3072(text-embedding-3-large). 컬렉션 생성 후 변경 불가
- 배치 업서트: 대량 데이터는 배치(500~1000개)로 삽입해 성능 최적화
- 백업: 벡터 DB는 임베딩 원본(텍스트)이 있으면 재생성 가능. 메타데이터 백업이 더 중요
맺으며
벡터 DB 선택에서 가장 흔한 실수는 "나중에 스케일하겠지"라는 생각으로 처음부터 가장 복잡한 솔루션을 도입하는 것이다. 대부분의 초기 RAG 시스템은 pgvector 또는 Qdrant로 충분하다.
현재 인프라와의 통합 비용, 팀의 운영 역량, 실제 데이터 규모를 먼저 평가하고 선택한다. 기능 차이보다 운영 비용이 장기적으로 더 큰 영향을 미친다.