핵심 요약
- 빠른 PoC와 개인·팀 단위 RAG는 Chroma가 시작하기 쉽습니다.
- 운영형 RAG API, 메타데이터 필터, 하이브리드 검색이 중요하면 Qdrant가 균형이 좋습니다.
- 대규모 벡터, 분산 구성, 전용 벡터 인프라가 필요하면 Milvus를 검토할 만합니다.
- 기존 PostgreSQL 데이터와 JOIN, 권한, 트랜잭션이 중요하면 pgvector가 현실적인 선택입니다.
관련 글을 함께 보면 설계 흐름을 잡기 쉽습니다. 문서 수집과 전처리는 LangChain RAG 구축 1편: 문서 수집·파싱·전처리 파이프라인, 임베딩과 Vector DB 기본 구조는 LangChain RAG 구축 2편: 임베딩 모델 선택과 Vector DB 구축, 검색 품질 평가는 로컬 LLM 구축 3편: RAG 성능 최적화와 평가 지표 설계를 참고하면 좋습니다.
1. Vector DB 선택 전에 먼저 정해야 할 기준
Vector DB는 임베딩을 저장하고 비슷한 벡터를 빠르게 찾는 저장소입니다. 하지만 RAG에서는 단순 유사도 검색만으로는 부족합니다. 실제 서비스는 사용자 권한, 문서 타입, 날짜, 부서, 프로젝트, 언어, 보안 등 다양한 조건을 함께 걸어야 합니다.
결정 기준 확인 질문 중요한 이유
| 서비스 단계 | PoC인가, 운영 서비스인가? | 초기 개발 편의성과 운영 안정성의 우선순위가 다릅니다. |
| 필터링 | 문서 권한, 카테고리, 날짜 조건이 필요한가? | 권한 필터가 부실하면 RAG 답변이 보안 사고로 이어질 수 있습니다. |
| 검색 방식 | dense, sparse, hybrid 검색이 필요한가? | 키워드와 의미 검색을 함께 쓰면 실무 문서 검색 품질이 좋아집니다. |
| 운영 난이도 | 팀이 별도 DB 클러스터를 운영할 수 있는가? | DB 선택은 개발보다 장애 대응과 비용에서 차이가 납니다. |
| 기존 시스템 | PostgreSQL, 계정, 권한, 감사 로그를 이미 쓰는가? | 기존 데이터와 결합해야 하면 전용 Vector DB보다 pgvector가 단순할 수 있습니다. |
2. Chroma, Qdrant, Milvus, pgvector 한눈에 비교
아래 표는 “좋다/나쁘다”가 아니라 “어디에 맞는가”를 기준으로 정리한 비교입니다. RAG 초반에는 시작 속도가 중요하지만, 운영으로 갈수록 필터, 백업, 관측, 재색인, 권한 모델이 더 중요해집니다.
도구 잘 맞는 상황 강점 주의할 점
| Chroma | PoC, 로컬 개발, 소규모 RAG | 시작이 쉽고 앱 코드와 붙이기 편합니다. | 대규모 운영, 고가용성, 복잡한 운영 정책은 별도 검토가 필요합니다. |
| Qdrant | 운영형 RAG API, 필터 중심 검색 | payload 기반 필터, named vector, dense/sparse/hybrid 검색 구성이 좋습니다. | 필터 필드와 payload index 설계를 초기에 잡아야 합니다. |
| Milvus | 대규모 벡터, 분산 인프라, 전용 검색 플랫폼 | Lite, standalone, distributed 등 단계별 확장 경로가 있습니다. | 운영 복잡도와 인프라 비용을 감당할 팀 역량이 필요합니다. |
| pgvector | PostgreSQL 중심 서비스, 업무 데이터 JOIN | 트랜잭션, 권한, 백업, JOIN 등 PostgreSQL 장점을 그대로 활용합니다. | 초대규모 전용 벡터 검색에서는 튜닝과 구조 설계가 중요합니다. |
3. Chroma: 빠른 PoC와 팀 내부 RAG에 적합
Chroma는 “일단 RAG를 만들어보고 싶다”는 단계에서 특히 편합니다. 문서 임베딩을 저장하고, 메타데이터와 함께 조회하는 흐름이 단순합니다. 로컬 개발, 노트북 실험, 사내 데모, 작은 규모의 문서 검색 API를 빠르게 만들 때 생산성이 좋습니다.
Chroma가 잘 맞는 경우
- RAG 아키텍처를 처음 검증하는 단계
- 문서 수가 많지 않고 로컬 또는 소규모 서버에서 운영하는 경우
- LangChain, LlamaIndex 같은 프레임워크와 빠르게 연결해야 하는 경우
- 검색 품질 실험, chunk size 실험, embedding model 비교가 우선인 경우
Chroma 선택 시 체크포인트
PoC 단계에서는 속도가 장점이지만, 운영으로 넘어갈 때는 백업, 복구, 권한 필터, 모니터링, 재색인 작업을 별도로 정리해야 합니다. Chroma를 계속 운영에 쓸지, Qdrant·Milvus·pgvector로 옮길지를 결정하는 기준을 미리 만들어두는 것이 좋습니다.
문서 수집 → 청킹 → 임베딩 생성 → Chroma 저장
사용자 질문 → 임베딩 변환 → 유사 문서 검색 → LLM 답변 생성4. Qdrant: 필터링과 운영형 RAG API에 강한 선택
Qdrant는 벡터와 함께 payload 메타데이터를 저장하고, 이를 검색 조건으로 활용하는 구조가 강점입니다. 예를 들어 같은 문서라도 사용자 권한, 부서, 프로젝트, 문서 타입, 언어, 작성일에 따라 검색 결과를 제한해야 하는 서비스라면 필터 설계가 핵심이 됩니다.
Qdrant가 잘 맞는 경우
- 사용자별 권한 필터가 중요한 사내 검색·챗봇
- 문서 타입, 카테고리, 기간 조건을 자주 거는 RAG API
- dense 검색과 sparse 검색을 조합하는 하이브리드 검색
- 벡터 종류를 여러 개 관리해야 하는 멀티 임베딩 구조
Qdrant 설계 예시
운영 서비스라면 벡터보다 payload 설계가 먼저입니다. 나중에 필터링해야 하는 필드는 처음부터 명확하게 넣어야 합니다.
{
"id": "policy-2026-001-chunk-12",
"vector": [0.012, -0.044, 0.231],
"payload": {
"document_id": "policy-2026-001",
"department": "finance",
"access_level": "internal",
"language": "ko",
"created_year": 2026
}
}이런 구조를 잡아두면 “재무팀 사용자가 볼 수 있는 2026년 한국어 문서 중에서만 검색” 같은 조건을 검색 단계에서 처리할 수 있습니다. RAG 품질은 결국 좋은 후보 문서를 얼마나 안전하게 좁히는가에 달려 있습니다.
5. Milvus: 대규모 벡터 검색 인프라가 필요할 때
Milvus는 대규모 벡터 검색과 분산 구성을 고려할 때 자주 검토되는 선택지입니다. 로컬 프로토타입에는 Milvus Lite, 단일 서버에는 standalone, 대규모 운영에는 Kubernetes 기반 distributed 구성을 선택할 수 있습니다. 벡터 수가 매우 많거나 전용 검색 플랫폼을 구축하려는 팀에 어울립니다.
Milvus가 잘 맞는 경우
- 문서, 이미지, 로그, 상품 등 대량의 벡터를 저장해야 하는 경우
- 검색 트래픽이 크고 전용 인프라를 운영할 수 있는 경우
- 벡터 검색을 핵심 플랫폼으로 키울 계획이 있는 경우
- 향후 분산 확장과 고성능 인덱스 전략이 필요한 경우
Milvus 선택 시 주의점
Milvus는 강력하지만, 강력한 만큼 운영 설계가 중요합니다. 클러스터 구성, 모니터링, 스토리지, 인덱스 빌드 시간, 백업 정책, 장애 대응 절차를 함께 준비해야 합니다. 작은 팀이 단순 RAG를 만들 때 처음부터 Milvus를 선택하면 개발보다 운영 부담이 더 커질 수 있습니다.
6. pgvector: PostgreSQL 중심 서비스의 현실적인 선택
pgvector는 PostgreSQL에 벡터 검색 기능을 추가하는 방식입니다. 이미 PostgreSQL을 쓰고 있고, 문서·사용자·권한·상품·계약 같은 업무 데이터와 벡터 검색 결과를 JOIN해야 한다면 매력적인 선택입니다. 새로운 DB를 하나 더 운영하지 않아도 되는 점도 실무에서는 큰 장점입니다.
pgvector가 잘 맞는 경우
- 서비스 핵심 데이터가 이미 PostgreSQL에 있는 경우
- 벡터 검색 결과와 업무 테이블을 JOIN해야 하는 경우
- 트랜잭션, 백업, 접근 제어, 감사 로그를 기존 DB 체계로 관리하고 싶은 경우
- 초기에는 단순한 벡터 검색으로 충분하지만, 운영 안정성이 중요한 경우
pgvector 기본 SQL 예시
pgvector는 PostgreSQL 확장으로 설치한 뒤 vector 컬럼을 만들고, 유사도 기준으로 정렬하는 방식으로 사용할 수 있습니다.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE document_chunks (
id bigserial PRIMARY KEY,
document_id text NOT NULL,
content text NOT NULL,
department text NOT NULL,
embedding vector(1536)
);
SELECT document_id, content
FROM document_chunks
WHERE department = 'finance'
ORDER BY embedding <-> '[0.012, -0.044, 0.231]'
LIMIT 5;이 구조의 장점은 명확합니다. 벡터 검색 결과를 가져온 뒤 다시 PostgreSQL에 물어보는 것이 아니라, 처음부터 업무 조건과 함께 검색할 수 있습니다. 사내 시스템, 관리자 페이지, 권한 기반 검색에서는 이 단순함이 큰 힘이 됩니다.
7. 상황별 추천 선택지
아래 기준으로 선택하면 실무 의사결정이 빨라집니다.
상황 추천 이유
| 처음 RAG를 만들고 기능을 검증한다 | Chroma | 설치와 연결이 쉽고 실험 속도가 빠릅니다. |
| 운영 챗봇에서 권한·부서·날짜 필터가 중요하다 | Qdrant | payload 필터와 검색 API 설계가 운영형 RAG에 잘 맞습니다. |
| 수천만~수억 개 이상의 벡터와 분산 확장이 필요하다 | Milvus | 전용 벡터 검색 인프라로 확장하기 좋습니다. |
| PostgreSQL 기반 서비스에 벡터 검색을 추가한다 | pgvector | 기존 권한, 백업, JOIN, 트랜잭션 구조를 활용할 수 있습니다. |
8. RAG Vector DB 운영 체크리스트
Vector DB를 정했다면 다음은 운영 기준입니다. 이 체크리스트를 건너뛰면 RAG는 데모에서는 잘 보이지만 실제 서비스에서는 답변 누락, 권한 사고, 검색 품질 저하가 쉽게 발생합니다.
항목 체크 내용
| 임베딩 차원 | 모델 변경 시 기존 벡터와 차원이 맞지 않으므로 재색인 계획이 필요합니다. |
| 메타데이터 스키마 | document_id, source, department, permission, created_at, language를 표준화합니다. |
| 필터 인덱스 | 자주 쓰는 필터 필드는 인덱스 또는 검색 최적화 대상인지 확인합니다. |
| 재색인 | 문서 변경, chunk 전략 변경, embedding model 변경 시 재색인 절차를 자동화합니다. |
| 평가 지표 | Recall@k, MRR, nDCG, 답변 근거 포함률, hallucination 비율을 추적합니다. |
| 백업·복구 | 원본 문서, chunk, metadata, embedding 생성 파라미터를 함께 복구할 수 있어야 합니다. |
9. RAG 아키텍처에서 Vector DB가 들어가는 위치
Vector DB는 RAG 전체 파이프라인 중 하나의 구성 요소입니다. 검색 품질을 Vector DB만 바꿔서 해결하려고 하면 한계가 있습니다. 문서 청킹, 임베딩 모델, 메타데이터, reranker, 프롬프트까지 같이 봐야 합니다.
수집기
↓
문서 파싱 / 정제 / 중복 제거
↓
Chunking + Metadata 생성
↓
Embedding Model
↓
Vector DB 저장
↓
사용자 질문 → Query Embedding → Vector Search + Metadata Filter
↓
Reranker
↓
LLM 답변 + 출처 표시이 흐름에서 Vector DB는 “후보 문서를 잘 찾는 역할”을 담당합니다. 최종 답변 품질은 검색 후보의 품질, reranking, prompt, LLM의 문맥 처리 능력이 함께 결정합니다. 로컬 LLM 서버까지 같이 운영한다면 로컬 LLM 구축 1편: vLLM·GGUF·FastAPI로 사내 AI 서버 만들기와 로컬 LLM 서버 구축 가이드도 함께 보면 구조를 잡기 좋습니다.
10. 흔한 실수와 해결 방법
실수 1: 벡터 검색만 믿고 키워드 검색을 버린다
업무 문서에는 제품 코드, 계약 번호, 에러 코드, API 이름처럼 키워드가 중요한 정보가 많습니다. 이 경우 의미 검색만 쓰면 오히려 정확도가 떨어질 수 있습니다. dense 검색과 sparse 검색을 조합하거나, 최소한 keyword fallback을 준비하는 것이 좋습니다.
실수 2: metadata를 나중에 추가하려고 한다
문서가 적을 때는 메타데이터 없이도 잘 되는 것처럼 보입니다. 하지만 운영에서는 권한, 부서, 날짜, 문서 상태, 언어 조건이 거의 반드시 필요합니다. metadata 스키마를 늦게 잡으면 전체 재색인이 필요해질 수 있습니다.
실수 3: 임베딩 모델 변경 비용을 계산하지 않는다
임베딩 모델이 바뀌면 벡터 공간도 바뀝니다. 기존 embedding과 새 embedding을 섞어 쓰면 검색 품질이 불안정해질 수 있습니다. 모델 변경 시에는 재임베딩, 재색인, 품질 평가를 하나의 배포 절차로 다루는 것이 안전합니다.
실수 4: 운영 장애를 고려하지 않는다
Vector DB가 장애나 지연을 일으키면 RAG API 전체가 느려집니다. timeout, fallback, circuit breaker, 캐시, 검색 실패 시 답변 정책을 미리 정해야 합니다. API 안정성 관점은 Spring Boot Redis 캐시 적용 전 반드시 확인할 체크리스트의 운영 기준과도 연결됩니다.
11. 최종 결론
Vector DB 선택은 팀의 목적에 맞춰야 합니다. 빠른 실험이 목적이면 Chroma, 운영형 RAG API와 필터링이 중요하면 Qdrant, 대규모 벡터 인프라가 필요하면 Milvus, 기존 PostgreSQL 업무 데이터와 결합해야 하면 pgvector가 좋은 출발점입니다.
실무 추천 순서
- 먼저 Chroma 또는 pgvector로 작은 RAG를 빠르게 검증합니다.
- 권한 필터와 운영 검색 API가 중요해지면 Qdrant를 검토합니다.
- 벡터 규모와 트래픽이 커져 전용 인프라가 필요하면 Milvus를 검토합니다.
- 어떤 선택이든 metadata, 재색인, 평가 지표, 백업 정책을 먼저 문서화합니다.
FAQ
Q1. 처음 RAG를 만들 때 가장 추천하는 Vector DB는 무엇인가요?
처음에는 Chroma 또는 pgvector를 추천합니다. 빠르게 실험하려면 Chroma가 편하고, 이미 PostgreSQL을 쓰는 서비스라면 pgvector가 운영 부담을 줄여줍니다.
Q2. Qdrant와 Milvus 중 무엇을 선택해야 하나요?
운영형 RAG API, 권한 필터, payload 검색이 중요하면 Qdrant가 실용적입니다. 벡터 수가 매우 많고 분산 검색 인프라를 전담 운영할 수 있다면 Milvus를 검토하는 편이 좋습니다.
Q3. pgvector만으로 운영 RAG가 가능한가요?
가능합니다. 특히 PostgreSQL 중심 서비스에서는 pgvector가 매우 현실적인 선택입니다. 다만 데이터 규모, 쿼리 패턴, 인덱스, 응답 시간 목표를 기준으로 부하 테스트를 해야 합니다.
Q4. Vector DB를 바꾸면 RAG 품질이 바로 좋아지나요?
항상 그렇지는 않습니다. 검색 품질은 chunk 전략, embedding model, metadata, reranker, prompt가 함께 결정합니다. Vector DB 변경 전에 평가 데이터셋을 먼저 만들고 Recall@k, MRR 같은 지표로 비교해야 합니다.
참고 공식 문서
RAG 비용 최적화 — GPU·CPU 자원 절감으로 운영비 줄이는 법
📘 LangChain 기반 RAG 시스템 구축9편. RAG 시스템 비용 최적화 + GPU/CPU 자원 절감 전략LangChain 기반 RAG 시스템: 데이터 준비부터 평가까지 전 과정 공개 – 9편RAG 시스템을 실제 운영환경에 올리면 가
hadesyi.tistory.com
'컴퓨터 활용(한글, 오피스 등) > 기타' 카테고리의 다른 글
| 리눅스 | rename, mv (0) | 2026.08.10 |
|---|---|
| CLI 명령어 (0) | 2026.08.07 |
| GGUF, Ollama 방식, llamafile 방식, llama.cpp 설치 (0) | 2026.08.07 |
| 명령어 | mkdir -p -m , 하위 폴더(c)만 내가 지정한 권한(777)으로 만들어진다 (0) | 2026.08.07 |
| 파일 포멧에서 OFFSET 의미 (0) | 2026.08.07 |