프로덕션에서도 견딜 수 있는 벡터 데이터베이스 선택 5가지 기준

Source: Elastic Blog

대부분의 팀은 근사 최근접 이웃(ANN) 벤치마크를 찾아보고, recall@10 순으로 정렬하고, GitHub 스타 수를 확인한 뒤, 50,000개의 샘플 벡터로 개념 증명을 실행하고, 이를 바로 배포하는 방식으로 벡터 데이터베이스를 선택합니다. 하지만 6개월이 지나면 선택한 데이터베이스에 BM25 인덱스가 없어서 별도의 Elasticsearch 클러스터를 새로 구축하게 되거나, 문서 수준 접근 제어가 없어 보안 검토에서 차단되거나(엔터프라이즈 고객이 사용자별 데이터 격리를 요구), Confluence와 SharePoint에서 벡터 스토어로 문서를 동기화하는 작업이 문서가 업데이트될 때마다 깨져서 두 명의 엔지니어가 기능 개발 대신 파이프라인 유지보수에 매달리게 되는 상황에 직면합니다. 이 블로그에서는 커밋하기 전에 평가해야 할 다섯 가지 기준을 다룹니다.

벡터 데이터베이스가 전통적인 데이터베이스와 다른 점

전통적인 데이터베이스는 정확한 값을 매칭합니다. user_id = 42 혹은 status = 'active'와 같이 질의하면 데이터가 정확히 일치하는 행을 찾아줍니다. 관계형 데이터베이스, 키‑값 스토어, 문서 데이터베이스 모두 이 방식을 사용합니다. 이들이 사용하는 인덱스 구조인 B‑tree와 해시 맵은 정확한 조회를 위해 설계되었습니다.

벡터 데이터베이스는 의미적 유사도로 검색합니다. 정확한 값을 질의하는 대신, 의미를 나타내는 부동소수점 숫자들의 리스트인 벡터를 제공하면, 데이터베이스는 고차원 공간에서 해당 벡터와 가장 가까운 레코드를 찾아줍니다. 이 벡터는 텍스트, 이미지, 기타 데이터를 압축해 밀집된 수치 표현으로 변환하는 임베딩 모델(신경망)에서 생성됩니다. “how do I reset my password”와 “forgot credentials”는 단어가 전혀 겹치지 않지만, 의미가 비슷한 벡터를 만들어 공간상에서 가깝게 위치합니다.

이때 사용되는 인덱스 구조가 Hierarchical Navigable Small World (HNSW) 입니다. HNSW는 근사 최근접 이웃을 다층 그래프로 구성해, 약간의 recall 정확도 손실을 대가로 쿼리 속도를 크게 높입니다. “근사(approximate)”가 핵심 키워드이며, HNSW는 정확한 결과보다 속도를 우선시하고, recall‑throughput 트레이드오프가 이 블로그의 첫 번째 평가 기준이 됩니다.

Elasticsearch는 두 방식을 모두 결합합니다. 동일한 시스템·동일 문서·동일 쿼리 안에서 정확히 매칭되는 구조화 질의와 벡터 유사도 검색을 동시에 수행하고, 결과는 Reciprocal Rank Fusion (RRF) 으로 병합됩니다.

기준 1: 데이터 기반 Recall 및 Throughput

Recall@k는 가장 중요한 검색 품질 지표입니다. “k‑most relevant documents(정확히 brute‑force 검색으로 구한 k개 가장 관련 있는 문서)” 중 근사 검색이 실제로 반환한 비율을 묻습니다. 예를 들어 recall@10이 0.95이면 HNSW 인덱스가 평균 10개 중 9.5개를 찾아냈다는 의미입니다. 0.95와 0.99 사이 차이는 작아 보이지만, 프로덕션 RAG 파이프라인에서는 5%의 쿼리가 반드시 찾아야 할 문서를 놓치게 되어 답변 품질이 디버깅하기 어려운 방식으로 저하됩니다.

Queries per second(QPS)는 처리량을 나타냅니다. recall@10이 0.99이면서 50 QPS인 시스템은 애플리케이션이 500 QPS를 요구한다면 쓸모가 없습니다. 두 메트릭은 서로 트레이드오프 관계에 있습니다. HNSW의 ef_search 파라미터를 높이면 recall은 올라가지만 throughput은 감소합니다. 적절한 운영 포인트는 워크로드에 따라 달라집니다.

ANN Benchmarks 프로젝트는 알고리즘·데이터셋 별로 재현 가능한 recall‑vs‑QPS 곡선을 제공합니다. 이는 전반적인 풍경을 이해하기 위한 출발점입니다. ANN 벤치마크는 표준 벤치마크 데이터셋을 사용하므로(귀사의 데이터가 아님) 분포 이동을 고려해야 합니다. 예를 들어 파인‑튜닝된 모델의 제품 카탈로그 임베딩은 벤치마크에 쓰인 GloVe나 SIFT 벡터와 전혀 다른 특성을 보입니다. Elasticsearch Labs에서는 HNSW 설정·양자화 레벨(int8, binary 등)을 포함한 재현 가능한 벤치마크 구성을 제공하니, 자체 테스트의 기준점으로 활용하세요.

평가 프로토콜

• 실제 프로덕션 데이터(또는 가장 근접한 프록시)에서 10,000~100,000개의 벡터를 샘플링합니다.
• brute‑force 정확 검색으로 정답 최근접 이웃을 계산해 ground‑truth를 만든 뒤, 이것을 recall 상한선으로 둡니다.
• 각 후보 시스템에 기본 설정으로 벡터를 색인합니다.
• 목표 p99 레이턴시(예: 100 ms 이하)에서 recall@10과 QPS를 측정합니다.
• HNSW 파라미터(num_candidates, ef_construction, m 등)를 튜닝하고 위 과정을 반복합니다.
• 전체 프로덕션 규모로 확장했을 때 인덱스 크기와 메모리 사용량이 어떻게 변하는지 확인합니다.

가장 중요한 수치는 피크 recall이나 피크 QPS가 아니라, 목표 QPS에서 달성할 수 있는 recall입니다.

기준 2: 하이브리드 검색 기능

순수 벡터 검색은 의미적 유사도로만 결과를 반환합니다. 이는 “이 약의 부작용은?”, “이 문서와 유사한 문서 찾기”, “방금 본 제품과 비슷한 제품 보여줘”와 같은 의도 매칭에 적합합니다. 하지만 실제 애플리케이션은 벡터 검색만으로는 충족할 수 없는 요구사항을 가집니다.

예를 들어 법률 문서 검색 시스템을 생각해 보세요. 사용자가 termination clause를 검색하면서 jurisdiction: 'California'와 filed_after: '2024-01-01'이라는 필터를 함께 지정합니다. 의미적 컴포넌트는 “termination clause”와 관련된 문서를 찾아내고, 필터는 결과를 2024년 이후 캘리포니아에 제출된 문서로 제한합니다. 의미적 유사도가 아무리 높아도 이 필터를 대체할 수는 없습니다—정확한 요구사항이기 때문입니다.

이 패턴은 프로덕션에서 지속적으로 나타납니다.

• 이커머스: 의미 기반 제품 탐색 + 브랜드·가격 필터
• 헬스케어: 임상 노트 검색 + 환자 코호트 필터
• 코드 검색: 의미 기반 함수 검색 + 언어·레포지토리 필터
• 고객 지원: 티켓 유사도 검색 + 우선순위·상태 필터

Reciprocal Rank Fusion (RRF) 은 벡터 결과와 키워드 결과를 병합하는 표준 방법입니다. 각 서브 검색에서 문서의 순위 역수를 점수로 사용하고 이를 합산합니다. 공식은 score = Σ 1/(k + rank_i)이며, 여기서 k는 스무딩 상수(보통 60)입니다. RRF는 BM25와 벡터 유사도 간 점수 스케일 차이에 강건하기 때문에 선형 스코어 결합보다 일관되게 우수합니다.

하이브리드 검색 시스템의 쿼리 흐름 예시:

flowchart LR
    Q[User query] --> V[Vector search HNSW]
    Q --> L[Lexical search BM25]
    Q --> F[Filters / structured queries]
    V --> R[RRF merger]
    L --> R
    F --> R
    R --> RE[Reranker - optional]
    RE --> OUT[Results]

벡터 데이터베이스를 하이브리드 검색 관점에서 평가할 때 스스로에게 물어볼 질문:

• 별도 검색 서비스 없이 네이티브 BM25를 지원하나요?
• 벡터 검색과 메타데이터 필터를 단일 쿼리에서 동시에 적용할 수 있나요, 아니면 전·후 처리 단계가 필요한가요?
• 같은 요청 안에서 팩터드 카운트·날짜 히스토그램 같은 구조화된 집계가 가능한가요?
• 하이브리드 검색이 첫 번째 클래스 API 기능인가요, 아니면 벡터 API 위에 얹은 우회 방법인가요?

Elasticsearch는 위 모든 기능을 네이티브하게 제공합니다. Pinecone, Qdrant와 같은 전용 벡터 데이터베이스는 메타데이터 필터링은 지원하지만 BM25 인덱스가 없으므로 키워드 검색을 위해 두 번째 시스템(보통 Elasticsearch 또는 OpenSearch)을 별도로 도입하거나, 애플리케이션 레이어에서 직접 구현해야 합니다. 이중 스택 방식은 가능하지만, 두 시스템을 배포·모니터링·동기화해야 하는 부담이 늘어납니다