Vector Database Selection
“가장 중요한 교훈은 특정 벤더나 기능이 아니라 평가 자체의 소유권이었다.”
핵심 개념
벡터 검색은 더 이상 백엔드 구현 세부가 아니다. RAG·추천·시맨틱 검색이 프로덕트의 전면에 오면서 벡터 DB 선택은 primary datastore나 메시지 큐를 고르는 것과 같은 급의 인프라 결정이 되었다.
그런데 이 결정을 뒷받침해야 할 공개 벤치마크는 대부분 작은 데이터셋 · 합성 워크로드 · 낮은 동시성을 쓴다. 프로덕션은 정반대다 — 수억 임베딩, 메타데이터 필터와 결합된 쿼리, 높은 동시성, 조여진 tail latency 기대. 이 규모에서는 레이턴시나 효율의 작은 차이가 사용자 경험과 비용 양쪽에 큰 영향을 준다.
결론: 자체 프로덕션 형태 평가를 설계하고 소유하라.
흔한 출발점과 그것이 깨지는 지점
거의 모든 조직이 이미 있는 검색 엔진에 벡터 기능을 켜는 것으로 시작한다(OpenSearch/Elasticsearch, PostgreSQL + pgvector). 합리적이다 — 사내에 이미 채택되어 있고, 관리형으로 가용하고, Terraform으로 프로비저닝되어 새 기술이나 운영 오버헤드 없이 첫 유스케이스를 온보딩할 수 있다.
깨지는 조건:
| 변화 | 증상 |
|---|---|
| 데이터셋이 수억 임베딩으로 | 목표 recall 유지에 필요한 클러스터가 계속 커짐 |
| 쿼리가 필터와 결합 | prefiltering 경로가 최적화되지 않아 레이턴시 급등 |
| 동시성 증가 | P99 tail latency가 비선형으로 악화 |
| 사용자 대면 SLO | 지속적 튜닝이 상시 업무가 됨 |
“근본적으로 망가진 것은 없었지만 운영하기 어려워지고 진화가 느려지고 비싸졌다. 위에 만든 고가치 유스케이스를 가능하게 하는 것보다 인프라를 관리하는 데 더 많은 시간을 쓰고 있었다.”
이것이 전형적인 “엔진의 내재적 한계를 하드웨어로 보상” 패턴이다. 비용 곡선이 워크로드 곡선보다 가파르게 올라가면 엔진 교체 신호다.
평가 설계 템플릿
Booking.com의 설계를 일반화하면 4개 축이다.
1. 데이터셋 — 프로덕션 규모로
- 소규모 편향(small-scale bias)을 피한다. 1천만이 아니라 1억 규모로. 인덱스가 메모리에 다 들어가느냐 마느냐에서 순위가 뒤집힌다
- 임베딩 모델은 사내 카탈로그에서 실제로 쓰는 것을 쓴다 (예:
all-MiniLM-L6-v2) - 벡터만 넣지 말고 메타데이터(rating, tag)도 함께 넣는다 — filtered KNN이 실제 워크로드다
2. 워크로드 3종
| 워크로드 | 무엇을 재는가 |
|---|---|
| Full a-KNN | 제약 없는 ANN의 순수 효율 |
| Filtered a-KNN | prefiltering 경로 — 실제 사용에 가장 가깝다. 검색은 좀처럼 제약 없지 않다 |
| 혼합 read/write | 전체 연산의 ~20%를 지속 인제스션으로. 동시 인덱싱 압박 하의 쿼리 레이턴시 |
혼합 워크로드는 closed-loop으로 돌린다 — 각 클라이언트가 응답을 받는 즉시 다음 요청을 발행해 시스템을 자연스럽게 포화로 민다.
3. 스케일링 축
동시성(5 → 50 → 100 스레드) → 요청률은 그에 따라 자연히 상승. P50이 아니라 P99 tail latency에 주목한다 — 그것이 사용자 경험을 가장 가깝게 반영한다.
4. recall 정규화 — 가장 자주 빠뜨리는 단계
ANN은 정확도를 속도와 교환한다. 이 통제 없이 레이턴시를 비교하면 “더 대충 찾는 시스템”이 이긴다.
- 인덱스에 이미 있는 벡터를 랜덤 샘플링(예: 200만 개)해 각각을 쿼리로 사용
- 쿼리 벡터 자신이 top-k 최근접 이웃에 나타나는지 확인 →
Recall@k - 각 시스템의 search breadth 등 ANN 파라미터를 튜닝해 모두 동일한 목표 recall(~0.99) 로 맞춘다
- 그제서야 레이턴시·처리량·리소스 차이가 검색 품질이 아니라 시스템 효율을 반영한다
관찰되는 일관된 패턴
전용 벡터 DB는 벡터 기능이 추가된 범용 검색 엔진과 다르게 행동한다 — 더 낮은 tail latency, 동시성 하의 더 나은 처리량, 더 예측 가능한 스케일링 특성을 더 적은 리소스로.
Booking.com 결과: 비교 가능한 recall과 SLO에서 OpenSearch baseline 대비 컴퓨트·메모리 footprint 약 40% 감소, 시나리오 전반에서 가장 일관된 Weaviate 채택.
주의: 이것은 “Weaviate가 최고”라는 결론이 아니다. 당신의 필터 선택도, 벡터 차원, 갱신 비율에서는 순위가 다를 수 있다. 이 글의 이전 가능한 결론은 순위가 아니라 방법론이다.
마이그레이션을 가능하게 하는 사전 조건 — 추상화
Booking.com에서 마이그레이션을 크게 단순화한 것은 평가가 아니라 훨씬 이전에 내린 아키텍처 결정이었다:
모든 DB 접근이 이미 사내 Embedding Service 뒤로 추상화되어 클라이언트가 기저 스토리지와 직접 상호작용한 적이 없었다.
덕분에 여러 DB를 병렬로 돌리고 백엔드를 투명하게 전환할 수 있었고, 대부분의 팀에게 마이그레이션은 설정 변경 수준이었다.
교훈: 벡터 DB를 처음 도입할 때 클라이언트에 벤더 SDK를 직접 노출하지 마라. 얇은 사내 서비스/라이브러리 레이어 하나가 3년 뒤의 재선택 비용을 100배 줄인다. → Query Proxy와 같은 패턴.
체크리스트
- 프로덕션 규모(전체 데이터셋)로 테스트했는가 — 샘플이 아니라
- 모든 후보를 동일 recall로 정규화했는가
- filtered 쿼리를 포함했는가
- 동시 write 하의 read 를 측정했는가
- P99를 봤는가
- 목표 SLO 달성에 필요한 CPU/RAM/노드 수로 환산했는가 (= 비용)
- 스토리지 레이어가 애플리케이션에서 추상화되어 있는가
- “최고 수치”가 아니라 안정성으로 최적화했는가
연관 개념
- Multimodal Search — 벡터 검색의 상위 개념과 하이브리드 검색
- RAG — 벡터 DB의 최대 소비처
- Puffin-Backed Derived Data — 벡터 인덱스를 별도 DB가 아니라 테이블 포맷 사이드카에 두는 대안
- Lake Point Query Indexing — 레이크 위 저지연 조회라는 같은 문제의 다른 축
- Data Engineering FinOps — 효율 = recall/SLO당 리소스
- Query Proxy — 백엔드 전환을 가능하게 하는 추상화 레이어
- LLM Platform Engineering
- Distributed Systems Reliability
Source: How We Selected the Next Vector Database at Booking.com