RAG 비교를 위한 벡터 저장소
적절한 벡터 DB를 선택하여 RAG 스택 구축하기
정확한 벡터 저장소 선택은 RAG 애플리케이션의 성능, 비용, 확장성에 큰 영향을 미칩니다. 이 포괄적인 비교는 2024-2025년에 가장 인기 있는 옵션들을 다룹니다.

벡터 저장소란 무엇이며, RAG이 왜 이를 필요로 하는가
벡터 저장소는 고차원 임베딩 벡터를 저장하고 쿼리하기 위한 전문적인 데이터베이스입니다. 검색 증강 생성(RAG) 시스템에서 벡터 저장소는 지식의 뼈대 역할을 하며, 의미적 유사도 검색을 통해 맥락에 맞는 문서 검색을 가능하게 합니다.
RAG 파이프라인을 구축할 때, 문서들은 OpenAI의 text-embedding-3-small이나 BGE, E5와 같은 오픈소스 대안과 같은 모델을 통해 임베딩(밀집 수치 벡터)으로 변환됩니다. 최첨단 다국어 성능을 위해 Qwen3 임베딩 및 리랭커 모델은 Ollama와의 로컬 배포에 탁월한 통합을 제공합니다. 다국어 및 다모달 애플리케이션을 위해 크로스 모달 임베딩은 텍스트, 이미지, 오디오와 같은 다양한 데이터 유형을 통합된 표현 공간으로 연결할 수 있습니다. 이러한 임베딩은 의미적 의미를 포착하여 정확한 키워드 일치보다 의미에 따라 문서를 찾을 수 있게 합니다.
벡터 저장소는 다음과 같은 기능을 수행합니다:
- 수십만에서 수십억 개의 벡터 저장
- 빠른 근사 최근접 이웃(ANN) 검색을 위한 인덱싱
- 메타데이터로 검색 범위 축소를 위한 필터링
- 지식 베이스 유지 관리에 필요한 CRUD 작업
관련 문서를 검색한 후, 임베딩 모델을 사용한 리랭킹은 더 복잡한 유사도 측정을 사용하여 후보를 재평가함으로써 검색 품질을 향상시킬 수 있습니다.
빠른 비교 표
| 벡터 저장소 | 유형 | 최적 사용 사례 | 호스팅 | 라이선스 |
|---|---|---|---|---|
| Pinecone | 관리형 | 프로덕션, zero-ops | 클라우드 전용 | Proprietary |
| Chroma | 내장형/서버형 | 프로토타이핑, 간단함 | 자체 호스팅 | Apache 2.0 |
| Weaviate | 서버형 | 하이브리드 검색, GraphQL | 자체 호스팅/클라우드 | BSD-3 |
| Milvus | 서버형 | 확장성, 기업용 | 자체 호스팅/클라우드 | Apache 2.0 |
| Qdrant | 서버형 | 풍부한 필터링, Rust 성능 | 자체 호스팅/클라우드 | Apache 2.0 |
| FAISS | 라이브러리 | 내장형, 연구용 | 메모리 내부 | MIT |
| pgvector | 확장 | Postgres 통합 | 자체 호스팅 | PostgreSQL |
벡터 저장소 상세 분석
Pinecone — 관리형 리더
Pinecone는 머신러닝 애플리케이션을 위해 특별히 설계된 완전히 관리형 벡터 데이터베이스입니다.
from pinecone import Pinecone
pc = Pinecone(api_key="YOUR_API_KEY")
index = pc.Index("my-rag-index")
# 벡터 삽입
index.upsert(vectors=[
{"id": "doc1", "values": embedding, "metadata": {"source": "wiki"}}
])
# 메타데이터 필터링으로 쿼리
results = index.query(
vector=query_embedding,
top_k=5,
filter={"source": {"$eq": "wiki"}}
)
장점:
- 인프라 관리가 필요 없음
- 탁월한 문서화 및 SDK 지원
- 서버리스 티어와 쿼리당 요금제
- 빠른 쿼리 지연 시간 (~50ms P99)
단점:
- 클라우드 전용 (자체 호스팅 불가)
- 사용량에 따라 비용 증가
- 제조사에 대한 의존성 문제
최적 사용 사례: 프로덕션 속도와 운영 간단함을 우선시하는 팀.
Chroma — 개발자들의 최애
Chroma는 “AI 네이티브 오픈소스 임베딩 데이터베이스"로, 간단함과 LangChain 및 LlamaIndex와의 원활한 통합으로 유명합니다.
import chromadb
client = chromadb.Client()
collection = client.create_collection("my-docs")
# 자동 임베딩으로 문서 추가
collection.add(
documents=["Doc content here", "Another doc"],
metadatas=[{"source": "pdf"}, {"source": "web"}],
ids=["doc1", "doc2"]
)
# 쿼리
results = collection.query(
query_texts=["semantic search query"],
n_results=5
)
장점:
- 매우 간단한 API
- 내장 임베딩 지원
- 내장(메모리 내부) 또는 클라이언트-서버 모드 작동
- LangChain/LlamaIndex와의 첫 등급 통합
단점:
- 매우 큰 데이터셋에 대한 확장성 제한
- 기업용 기능이 적음
- 내장 모드에서 지속성 처리가 어려움
최적 사용 사례: 프로토타이핑, 소규모에서 중간 규모 프로젝트, Python 중심 팀.
Weaviate — 하이브리드 검색의 주장
Weaviate는 벡터 검색과 키워드(BM25) 검색을 결합하고 GraphQL API를 제공합니다. 하이브리드 검색이 검색 품질을 향상시키는 시나리오에 적합합니다.
import weaviate
client = weaviate.Client("http://localhost:8080")
# 벡터라이저와 함께 스키마 생성
client.schema.create_class({
"class": "Document",
"vectorizer": "text2vec-openai",
"properties": [{"name": "content", "dataType": ["text"]}]
})
# 하이브리드 검색(벡터 + 키워드)
result = client.query.get("Document", ["content"]) \
.with_hybrid(query="RAG architecture", alpha=0.5) \
.with_limit(5) \
.do()
장점:
- 네이티브 하이브리드 검색(알파 파라미터로 벡터/키워드 균형 조정)
- 내장 벡터라이저 모듈
- GraphQL 쿼리 언어
- 다중 사용자 지원
단점:
- 더 높은 운영 복잡성
- 학습 곡선이 가파름
- 자원 집약적
최적 사용 사례: 하이브리드 검색과 GraphQL API가 필요한 프로덕션 애플리케이션.
Milvus — 기업용 확장성
Milvus는 수십억 개의 벡터 유사도 검색을 위해 설계되었습니다. 기업용 대규모 배포가 필요한 경우의 최고 선택입니다.
from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType
connections.connect("default", host="localhost", port="19530")
# 스키마 정의
fields = [
FieldSchema(name="id", dtype=DataType.INT64, is_primary=True),
FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1536)
]
schema = CollectionSchema(fields)
collection = Collection("documents", schema)
# 삽입 및 검색
collection.insert([[1, 2, 3], [embedding1, embedding2, embedding3]])
collection.search(
data=[query_embedding],
anns_field="embedding",
param={"metric_type": "COSINE", "params": {"nprobe": 10}},
limit=5
)
장점:
- 수십억 벡터 확장성 검증
- 여러 인덱스 유형(IVF, HNSW, DiskANN)
- GPU 가속 지원
- 활발한 기업 커뮤니티(Zilliz Cloud)
단점:
- 복잡한 배포(예: etcd, MinIO 필요)
- 작은 프로젝트에 과도함
- 운영 부담이 큼
최적 사용 사례: 대규모 기업용 배포 및 DevOps 능력이 있는 팀.
Qdrant — 성능과 필터링의 조화
Qdrant는 Rust로 작성되어 뛰어난 성능과 풍부한 메타데이터 필터링 기능을 제공합니다. RAG를 위한 생산성에 점점 인기 있는 선택입니다.
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
client = QdrantClient("localhost", port=6333)
# 컬렉션 생성
client.create_collection(
collection_name="documents",
vectors_config=VectorParams(size=153秒, distance=Distance.COSINE)
)
# 풍부한 페이로드와 함께 삽입
client.upsert(
collection_name="documents",
points=[
PointStruct(id=1, vector=embedding, payload={"category": "tech", "date": "2024-01"})
]
)
# 복잡한 필터링으로 검색
client.search(
collection_name="documents",
query_vector=query_embedding,
query_filter={"must": [{"key": "category", "match": {"value": "tech"}}]},
limit=5
)
장점:
- 탁월한 쿼리 성능(Rust)
- 중첩 조건으로 풍부한 필터링
- 메모리 효율을 위한 양자화
- 기능과 간단함의 균형
단점:
- Pinecone/Weaviate보다 생태계가 작음
- 클라우드 제공이 더 신선함
최적 사용 사례: 복잡한 필터링 요구사항이 있는 팀.
FAISS — 연구용 강력한 도구
FAISS(Facebook AI Similarity Search)는 라이브러리이며, 데이터베이스는 아닙니다. 많은 벡터 DB가 이 라이브러리 위에 구축되어 있습니다.
import faiss
import numpy as np
# 인덱스 생성
dimension = 1536
index = faiss.IndexFlatIP(dimension) # 내적 유사도
# 벡터 추가
vectors = np.array(embeddings).astype('float32')
index.add(vectors)
# 검색
D, I = index.search(query_embedding.reshape(1, -1), k=5)
장점:
- 메모리 내부에서 매우 빠른 검색
- 여러 인덱스 유형(Flat, IVF, HNSW, PQ)
- GPU 지원
- 네트워크 오버헤드 없음
단점:
- 지속성 없음(수동으로 저장/불러오기 필요)
- 메타데이터 필터링 없음
- CRUD 없음(업데이트를 위해 인덱스 재구성 필요)
- 단일 노드만 지원
최적 사용 사례: 연구, 프로토타이핑, 메모리에 벡터가 들어가는 시나리오.
pgvector — PostgreSQL 네이티브
pgvector는 PostgreSQL에 벡터 유사도 검색을 추가합니다. 기존 PostgreSQL 인프라를 벡터에 사용할 수 있습니다.
전통적인 데이터베이스인 PostgreSQL을 벡터 검색에 사용할 수 있나요? 물론 가능하며, 실제로 실용적입니다.
-- 확장 활성화
CREATE EXTENSION vector;
-- 벡터 열이 있는 테이블 생성
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
content TEXT,
embedding vector(1536)
);
-- HNSW 인덱스 생성
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
-- 유사도 검색
SELECT id, content, embedding <=> '[0.1, 0.2, ...]' AS distance
FROM documents
WHERE category = 'tech'
ORDER BY distance
LIMIT 5;
장점:
- 기존 PostgreSQL 기술/인프라 사용
- 벡터와 함께 ACID 트랜잭션
- 관계형 쿼리와 벡터 검색 결합
- 새 데이터베이스 운영 필요 없음
단점:
- 전문 DB에 비해 성능 한계
- PostgreSQL 생태계에 제한
- 인덱스 생성이 느림
최적 사용 사례: PostgreSQL 기반 팀이 새 인프라 없이 벡터를 사용하고자 할 때.
적절한 벡터 저장소 선택
의사결정 프레임워크
다음 질문부터 시작하세요:
-
규모는 어떻게 되나요?
- < 100K 벡터 → Chroma, pgvector, FAISS
- 100K - 10M 벡터 → Qdrant, Weaviate, Pinecone
-
10M 벡터 → Milvus, Pinecone, Qdrant
-
자체 호스팅 또는 관리형이 필요하나요?
- 관리형 → Pinecone, Zilliz (Milvus), Weaviate Cloud
- 자체 호스팅 → Qdrant, Milvus, Chroma, Weaviate
-
하이브리드 검색이 필요하나요?
- 예 → Weaviate, Elasticsearch
- 아니요 → 모든 옵션이 가능
-
필터링 복잡도는 어떻게 되나요?
- 간단 → Chroma, Pinecone
- 복잡한 중첩 필터 → Qdrant, Weaviate
-
FAISS와 전용 벡터 데이터베이스의 차이점은 무엇인가요? 지속성, 분산 검색, 프로덕션 기능이 필요한 경우 데이터베이스를 선택하세요. FAISS는 임베딩된 연구 시나리오에 이상적입니다.
일반적인 RAG 아키텍처 패턴
프로덕션 시스템을 위해 고급 RAG 변형인 LongRAG, Self-RAG, GraphRAG를 고려하세요.
패턴 1: Chroma와의 간단한 RAG
문서 → 임베딩 → Chroma → LangChain → LLM
MVP와 내부 도구에 적합.
패턴 2: Qdrant와의 프로덕션 RAG
문서 → 임베딩 → Qdrant (자체 호스팅)
↓
FastAPI → LLM
비용을 고려한 프로덕션 배포에 적합.
패턴 3: Pinecone과의 기업용 RAG
문서 → 임베딩 → Pinecone (관리형)
↓
앱 → LLM
비용보다 신뢰성을 우선시하는 팀에 적합.
LLM을 RAG 파이프라인에 통합할 때, 구조화된 출력 기술과 Ollama 및 Qwen3을 사용하여 언어 모델에서 일관되고 분석 가능한 응답을 보장할 수 있습니다. 이는 검색된 정보를 추출하고 처리하는 데 도움이 됩니다.
성능 벤치마크
실제 성능은 데이터셋, 쿼리, 하드웨어에 따라 달라집니다. 일반적인 관찰:
| 작업 | FAISS | Qdrant | Milvus | Pinecone | Chroma |
|---|---|---|---|---|---|
| 1M 벡터 삽입 | 30초 | 2분 | 3분 | 5분 | 4분 |
| 쿼리 지연 시간(P50) | 1ms | 5ms | 10ms | 30ms | 15ms |
| 쿼리 지연 시간(P99) | 5ms | 20ms | 40ms | 80ms | 50ms |
| 메모리/1M 벡터 | 6GB | 8GB | 10GB | N/A | 8GB |
참고: Pinecone 지연 시간에는 네트워크 오버헤드가 포함됨; 나머지는 로컬.
이전 고려 사항
Chroma와 Weaviate 중 어떤 것을 RAG 프로젝트에 선택해야 하나요? 이전 경로도 고려해야 합니다:
- Chroma → 프로덕션: 임베딩 내보내기, Qdrant/Pinecone에 다시 가져오기
- pgvector → 전문: COPY로 내보내기, 변환, 로드
- FAISS → 데이터베이스: 인덱스 저장, 벡터를 대상 DB에 로드
대부분의 프레임워크(LangChain, LlamaIndex)는 벡터 저장소를 추상화하여 애플리케이션 레이어에서 이전이 더 쉬워집니다.
비용 비교
관리형 옵션(월, 1M 벡터, 10K 쿼리/일):
- Pinecone Serverless: ~$50-100
- Pinecone Standard: ~$70-150
- Weaviate Cloud: ~$25-100
- Zilliz Cloud: ~$50-200
자체 호스팅(인프라 비용):
- 소형 VM(4GB RAM): $20-40/월
- 중형 VM(16GB RAM): $80-150/월
- Kubernetes 클러스터: $200+/월