Booking.com이 OpenSearch 대신 Weaviate를 벡터 DB로 선택한 과정

기존 OpenSearch 기반 벡터 검색이 수억 개 임베딩과 필터 검색, 높은 동시 요청을 처리하면서 클러스터 규모와 운영 비용이 계속 커짐 공개 벤치마크는 데이터가 작고 부하가 단순해 실제 환경을 반영하지 못한다고 보고, 1억 개 임베딩과 운영 형태를 재현한 자체 평가를 진행함 검색 품질을 약 99% Recall로 맞춘 뒤 전체 검색, 메타데이터 필터 검색, 쓰기 20%가 섞인 부하에서 P99 지연시간과 처리량, 자원 사용량, 안정성을 비교함 전용 벡터 DB는 OpenSearch보다 낮은 꼬리 지연시간과 예측 가능한 확장성을 보였으며, 같은 품질과 SLO 기준에서 사용 비용을 약 40% 줄임 여러 후보 중 전반적으로 가장 일관된 성능을 보인 Weaviate를 새 백엔드로 선택했으며, 기존에 DB 접근을 내부 서비스로 추상화해 대부분 설정 변경만으로 이전 가능했음 벡터 검색이 핵심 인프라가 된 배경 소수의 실험에서 출발한 Booking.com의 임베딩·벡터 검색은 유사도 검색, 의미 기반 필터링, 검색 증강 생성(RAG)을 지원하는 공용 인프라로 성장함 벡터 검색은 단순한 백엔드 구현을 넘어 사용자 경험을 직접 좌우함 검색 가능한 도메인 데이터가 넓어질수록 정확하고 개인화된 경험에 필요한 문맥을 더 깊게 확보할 수 있음 기반 벡터 데이터베이스는 기본 데이터 저장소나 메시지 큐처럼 예측 가능성과 확장성이 필요한 인프라임 사용 팀이 늘면서 요구사항도 다양해짐 하이브리드 검색과 다중 벡터 지원 같은 고급 기능 더 큰 벡터 용량과 높은 초당 요청 수(RPS) 대규모 데이터에서의 낮은 지연시간과 높은 동시성 임베딩과 검색 워크로드 임베딩은 텍스트나 이미지 같은 항목을 나타내는 고정 길이 숫자 배열이며, 고차원 공간에서 벡터 사이의 거리가 의미적 관련성을 근사함 질의 벡터와 가장 가까운 벡터를 찾아 의미적으로 유사한 항목을 검색할 수 있음 대표적인 활용 사례는 RAG이며, 파트너-투숙객 메시징 에이전트에도 사용됨 대부분의 워크로드는 대규모 벡터 컬렉션에서 빠른 k-최근접 이웃 검색, 메타데이터 필터링, 높은 동시성을 함께 요구하므로 저장 계층도 모델만큼 중요함 OpenSearch로 시작한 이유와 확장 한계 초기 내부 Embedding Service의 벡터 데이터베이스 백엔드로 OpenSearch를 선택함 사내에서 이미 사용 중이었음 AWS에서 이용할 수 있었음 Terraform 설정으로 쉽게 프로비저닝할 수 있었음 새 기...