Elasticsearch에서도 벡터 검색을 할 수 있는데, Milvus나 Qdrant 같은 벡터 DB를 따로 도입해야 할까?
먼저 확인할 것은 제품의 분류보다 검색 품질, 필터 조건, 운영 비용이다. Elasticsearch와 별도 벡터 DB 중 어느 쪽이 항상 빠르다는 결론은 데이터와 측정 조건 없이 내릴 수 없다. 하이브리드 검색을 위해 반드시 두 시스템을 운영해야 하는 것도 아니다.
이 글은 각 제품을 동일 조건으로 벤치마크한 결과가 아니라, 검색 시스템을 선택할 때 확인할 기준을 정리한 비교 글이다.
1. 의미를 만드는 모델과 검색하는 저장소를 구분한다
키워드 검색은 분석기를 통해 만든 토큰과 역인덱스를 활용한다. BM25는 역인덱스의 이름이 아니라 관련도를 계산하는 대표적인 점수 산정 방식이다. 상품 코드, 고유 명칭, 오류 메시지처럼 정확한 단어가 중요한 검색에서 유용하다.
벡터 검색은 질의와 문서를 벡터로 표현하고 가까운 벡터를 찾는다. 이때 의미 표현의 품질은 주로 임베딩 모델과 입력 데이터 처리 방식에 영향을 받는다. DB 자체가 이미지와 문장의 의미를 자동으로 이해하는 것은 아니다.
문서 → 분할·전처리 → 임베딩 모델 → 벡터 인덱스
질의 → 같은 표현 공간의 임베딩 → 유사 벡터 검색 → 결과같은 DB를 사용해도 모델, 문서 분할 크기, 거리 함수, 필터에 따라 결과는 달라진다. 반대로 같은 임베딩이라면 텍스트·이미지·음성 중 어떤 데이터에서 생성했는지만으로 특정 DB가 반드시 우수하다고 판단할 수 없다.
2. Elasticsearch도 벡터·하이브리드 검색을 지원한다
Elasticsearch는 키워드 검색뿐 아니라 벡터 검색과 하이브리드 검색을 제공한다. 따라서 벡터 기능을 단순히 “부가 기능이므로 성능이 낮다”고 설명하는 것은 근거가 부족하다.
| 비교할 지점 | Elasticsearch를 검토할 때 | 별도 벡터 DB를 검토할 때 |
|---|---|---|
| 기존 시스템 | 이미 운영하는 검색 인덱스·분석기·집계 기능을 활용할 수 있는가? | 새 저장소의 배포·백업·모니터링을 감당할 수 있는가? |
| 검색 기능 | 키워드·벡터 검색과 필터를 한 시스템에서 충족하는가? | 후보 제품의 인덱스·필터·벡터 기능이 요구에 맞는가? |
| 자원 분리 | 텍스트 검색과 벡터 검색이 같은 자원을 경쟁하는가? | 독립 확장이 이득인지, 동기화 비용보다 큰지 확인했는가? |
| 데이터 변경 | 문서 갱신과 벡터 갱신을 일관되게 반영하는가? | 원본 시스템과 검색 저장소의 변경·삭제를 동기화할 수 있는가? |
| 운영 경험 | 현재 팀의 경험을 활용할 수 있는가? | 장애 복구와 용량 계획을 새로 준비할 수 있는가? |
Milvus와 Qdrant도 하나의 동일한 제품처럼 취급하면 안 된다. 지원하는 인덱스, 필터 구현, 배포 방식과 버전이 다르다. 제품별 문서를 보고 필요한 기능을 확인한 뒤 같은 워크로드로 측정한다.
3. 하이브리드 검색은 검색 신호의 결합이다
예를 들어 “가볍고 시원한 여름 운동용 티셔츠”를 검색한다고 하자. 상품 종류·브랜드 같은 정확한 단어와, 사용 목적·느낌 같은 의미 정보가 모두 중요할 수 있다.
대표적인 구성은 키워드와 벡터 후보를 각각 구한 뒤 결합하는 방식이다.
┌→ 키워드 검색 → 후보 A ┐
질의와 접근 권한 필터 ├→ 순위 결합 → 재정렬 → 결과
└→ 벡터 검색 → 후보 B ┘RRF(Reciprocal Rank Fusion)는 서로 다른 검색기의 점수 크기를 직접 더하는 대신 각 순위를 이용해 결합하는 방법이다. 필요하면 후보 문서에 재정렬 모델을 적용한다. 후보 수와 결합 방식은 정답 데이터로 평가해야 한다.
Elasticsearch 안에서도 이러한 하이브리드 구성을 만들 수 있다. 외부 벡터 DB와 결합하는 것은 별도의 선택이며, 기능별 사용 가능 버전과 라이선스 조건은 적용 환경에서 확인한다.
기존 글의 “키워드로 먼저 거른 뒤 벡터로 재정렬”도 가능한 구조지만 한계가 있다. 첫 단계에서 키워드가 일치하지 않아 제외된 문서는 뒤에서 복구할 수 없다. 의미 검색으로 새 후보를 찾으려는 목적이라면 병렬 후보 검색과 비교해야 한다.
접근 권한이나 판매 중 여부처럼 반드시 지켜야 하는 필터는 관련도 조정보다 우선한다. 두 검색 경로와 최종 반환 단계에서 조건이 일관되게 적용되는지 확인한다.
4. 도입 전에는 이렇게 비교한다
같은 문서 집합, 같은 임베딩 모델, 같은 질의와 정답 기준으로 후보를 비교한다. 인덱스의 검색 정확도를 다르게 맞춘 상태에서 지연 시간만 비교하면 판단을 잘못할 수 있다.
| 지표 | 확인할 질문 |
|---|---|
| Recall@k | 필요한 관련 문서를 후보 안에 충분히 포함하는가? |
| nDCG@k 등 순위 품질 | 더 관련 있는 문서가 상위에 오는가? |
| p95·p99 지연 | 동시 요청과 실제 필터를 적용해도 응답 목표를 지키는가? |
| 인덱싱·갱신 지연 | 신규 문서와 삭제가 언제 검색에 반영되는가? |
| 자원·운영 비용 | 메모리·디스크·복제 비용과 운영 부담은 어느 정도인가? |
필터가 거의 없는 질의만 측정하지 않는다. 사용자의 권한, 지역, 상품 재고처럼 실제 서비스에서 사용하는 조건과 데이터 분포를 반영한다. 임베딩 생성 시간과 검색 엔진의 조회 시간도 나누어 기록한다.
5. 선택의 출발점
이미 Elasticsearch를 운영하고 있다면, 현재 버전에서 필요한 검색 품질과 지연을 달성할 수 있는지 먼저 검증할 수 있다. 별도 시스템 없이 목표를 만족한다면 그 자체로 유효한 선택이다.
독립적인 벡터 워크로드 확장이나 특정 제품의 기능이 필요하다면 Milvus·Qdrant 등을 후보로 추가한다. 이때 얻는 성능·기능상의 이점과 데이터 동기화·운영 비용을 함께 평가한다.
검색 엔진의 출신보다 서비스의 질의와 측정 결과가 선택을 설명할 수 있어야 한다.
