쉽게 이해하기

문서나 이미지를 임베딩으로 바꾸면 각 항목은 긴 숫자 벡터가 됩니다. 문제는 벡터가 수백만 개로 늘어나면 하나씩 모두 비교하는 방식이 너무 느리다는 점입니다. 벡터 데이터베이스는 이 벡터들을 검색하기 좋게 인덱싱하고, 필요한 메타데이터 필터를 함께 적용해 “의미적으로 가까운 항목”을 빠르게 찾습니다.

비유와 예시

비유하자면 단어 그대로 찾는 사전이 아니라 의미별로 정리된 도서관 색인입니다. “환불 정책 변경”이라고 검색하면 같은 표현이 없어도 비슷한 의미의 고객지원 문서를 찾을 수 있습니다. 이미지 검색에서는 사진과 비슷한 상품을 찾고, 코드 검색에서는 정확한 함수명이 없어도 비슷한 의도의 코드 조각을 찾습니다.

한눈에 비교

• 관리형 벡터 DB: 운영 부담이 낮고 빠르게 시작하기 좋지만 비용과 벤더 종속성을 확인해야 합니다.
• 오픈소스 분산 벡터 DB: 대규모와 제어권에 유리하지만 클러스터 운영 역량이 필요합니다.
• pgvector 같은 DB 확장: PoC나 관계형 데이터와 함께 쓰기 좋지만 대규모 tail latency를 따로 검증해야 합니다.
• Redis 같은 벡터 캐시: 매우 뜨거운 일부 데이터의 저지연 조회에 적합하지만 메모리 비용이 큽니다.

어디서 왜 중요한가

RAG 품질은 모델만이 아니라 “무엇을 검색해 가져왔는가”에 크게 좌우됩니다. 벡터 데이터베이스는 관련 문서를 빠르게 찾고, tenant·날짜·제품 같은 메타데이터로 범위를 좁히며, 새 데이터가 검색 가능해지는 시점과 검색 지연을 운영 지표로 관리하게 해줍니다.

자주 하는 오해

• ❌ 오해: 벡터 DB는 관계형 DB를 대체한다.
• ✅ 실제: 의미 검색을 보완하는 저장소입니다. 트랜잭션, 복잡한 조인, 원장성 기록은 여전히 다른 DB가 더 적합할 수 있습니다.
• ❌ 오해: 벡터만 많이 넣으면 검색 품질이 좋아진다.
• ✅ 실제: chunking, 임베딩 모델, 메타데이터, 평가셋이 함께 맞아야 합니다.
• ❌ 오해: 가장 빠른 인덱스가 항상 최선이다.
• ✅ 실제: recall@k, p95 latency, freshness, 비용을 함께 봐야 합니다.

대화에서는 이렇게

• "검색 결과가 이상하면 먼저 chunking, 임베딩 버전, 메타데이터 필터를 확인합시다."
• "PoC는 pgvector로 충분하지만, backfill 이후 p95가 올라가면 전용 벡터 DB를 검토하죠."
• "속도만 보지 말고 recall@k와 latency를 같이 추적합시다."

함께 읽으면 좋은 용어

• 기초
  Embedding — 벡터 DB가 저장하고 검색하는 기본 단위입니다.
• 기초
  Approximate Nearest Neighbor — 빠른 유사도 검색을 가능하게 하는 인덱스 계열입니다.
• 대안
  pgvector — PostgreSQL 안에서 벡터 검색을 시작할 때 자주 쓰입니다.
• 확장
  Hybrid Search — 벡터 검색과 키워드 검색을 결합합니다.
• 확장
  RAG — 벡터 검색이 가장 자주 쓰이는 LLM 워크플로우입니다.