이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- Chroma, Qdrant, Weaviate, Milvus 같은 vector DB 생태계에서 무엇을 배워야 하는가?
- RAG 구현은 왜 단순 vector search가 아닌가?
- 운영 RAG에서 문서 lifecycle과 권한을 어떻게 봐야 하는가?
개요
2026-06-30 GitHub API 확인 기준으로 Chroma, Qdrant, Weaviate, Milvus는 모두 수만 star와 활발한 업데이트를 가진다. 각각의 세부 기능은 다르지만, 백엔드 개발자가 배울 공통점은 명확하다.
RAG는 검색 인프라, 데이터 파이프라인, 권한 모델, 평가 시스템이 결합된 기능이다.
배울 패턴
RAG 오픈소스 구현은 보통 다음 단계를 가진다.
- document loading
- parsing
- chunking
- embedding
- indexing
- metadata filtering
- retrieval
- reranking
- context assembly
- answer generation
- evaluation
이 단계 중 하나만 약해도 답변 품질이 흔들린다.
Vector DB 선택보다 먼저 볼 것
- 문서 source of truth가 어디인가?
- 문서 삭제 이벤트가 index 삭제로 연결되는가?
- tenant와 role 권한은 metadata로 표현 가능한가?
- embedding model version을 저장하는가?
- 재색인 중 online serving은 어떻게 유지하는가?
- backup과 restore는 필요한가?
- index build가 batch 리소스를 얼마나 쓰는가?
vector DB는 도구일 뿐이고, 운영 RAG의 핵심은 데이터 lifecycle이다.
코드로 이해하기
metadata filter는 권한 모델과 연결되어야 한다.
def build_vector_filter(*, tenant_id: str, role: str) -> dict:
return {
"must": [
{"key": "tenant_id", "match": {"value": tenant_id}},
{"key": "allowed_roles", "match": {"value": role}},
{"key": "deleted", "match": {"value": False}},
]
}실제 구현에서는 DB 권한 모델과 vector metadata가 불일치할 수 있으므로 검색 후 서버에서 한 번 더 검증하는 방어도 고려한다.
장애 상황과 대응
RAG 장애는 다음처럼 온다.
- 검색 결과가 없다.
- 검색 결과가 오래된 문서다.
- 권한 없는 문서가 검색된다.
- 색인 후 품질이 떨어졌다.
- index build가 online serving을 느리게 만든다.
대응은 retrieval eval과 answer eval을 분리하고, source id와 document version을 trace에 남기는 것이다.
인프라 협업 포인트
인프라팀과는 다음을 논의한다.
- vector DB 배포 방식
- index 크기와 growth rate
- query latency SLO
- metadata cardinality
- backup/restore
- batch indexing 격리
- embedding worker scaling
RAG는 API 기능이 아니라 검색 인프라를 하나 더 운영하는 것이다.
실전 팁
- source id와 embedding model version을 metadata에 저장한다.
- deleted flag만 믿지 말고 실제 delete 절차도 둔다.
- 최신성이 중요한 문서는 updated_at을 ranking에 반영한다.
- retrieval 실패 케이스를 eval dataset에 추가한다.
위험 신호!
- vector DB에 문서 본문만 있고 source metadata가 없다.
- 문서 삭제가 index 삭제와 연결되지 않는다.
- 권한 필터가 프롬프트에만 있다.
- embedding model version을 모른다.
- 재색인 계획 없이 embedding 모델을 바꾼다.
확인 질문
확인 질문
- RAG 운영에서 source id가 중요한 이유는 무엇인가?
- 답변 근거, 삭제 처리, 장애 추적, eval을 연결하기 위해서다.
- vector DB metadata filter만 믿으면 위험한 이유는 무엇인가?
- 실제 DB 권한 모델과 metadata가 불일치할 수 있기 때문이다.