Elasticsearch는 훌륭했지만, 벡터 데이터베이스가 미래입니다
이 게시물은 원래 The New Stack에 게시되었으며 허가를 받아 여기에 재게시되었습니다.
수십 년 동안 Elasticsearch로 대표되는 전문 검색이라고도 알려진 키워드 매칭은 엔터프라이즈 검색 및 추천 엔진과 같은 정보 검색 시스템의 기본 선택지였습니다.
AI 기반 검색 기술이 발전함에 따라, 시스템이 사용자 쿼리 뒤에 있는 의미와 의도를 모두 이해할 수 있게 하는 시맨틱 검색으로의 전환이 일어나고 있습니다. 임베딩 모델과 벡터 데이터베이스는 이러한 변화의 중심이 되었습니다.
시맨틱 검색은 데이터를 벡터 임베딩으로 표현하여 키워드 매칭을 능가하며, 검색 의도에 대한 더 미묘한 이해를 제공하고 검색 증강 생성(RAG)부터 멀티모달 검색에 이르는 애플리케이션을 변화시키고 있습니다.
실제로 효과적인 정보 검색 시스템에는 시맨틱 이해와 정확한 키워드 매칭이 모두 필요합니다. 예를 들어 사용자는 검색 결과가 자신의 검색 쿼리와 관련된 개념을 보여주면서도, 특수 용어와 이름 같은 쿼리에 사용된 문자 그대로의 텍스트를 존중하고 정확히 일치하는 결과를 반환하기를 기대합니다.
밀집 벡터로 구동되는 시맨틱 검색은 의미를 이해하는 데 도움이 되며(예: ‘car’와 “automobile”이 같다는 것을 아는 것), 전통적인 전문 검색은 사용자가 기대하는 정확한 결과를 제공합니다(예: “Python 3.9”에 대한 정확한 일치 항목 찾기). 그 결과 많은 조직이 유연한 시맨틱 관련성과 예측 가능한 정확한 키워드 매칭의 균형을 맞추기 위해 두 방법의 강점을 결합한 하이브리드 검색 접근 방식을 채택하고 있습니다.
하이브리드 검색의 과제
하이브리드 검색을 구현하는 일반적인 방법은 효율적이고 확장 가능한 시맨틱 검색을 위해 오픈 소스 Milvus와 같은 목적 특화 벡터 데이터베이스를 사용하고, 전문 검색을 위해 Elasticsearch 또는 OpenSearch와 같은 전통적인 검색 엔진을 함께 사용하는 것입니다.
이 접근 방식은 좋은 결과를 낼 수 있지만, 동시에 새로운 복잡성 계층을 도입합니다. 서로 다른 두 검색 시스템을 관리한다는 것은 별도의 인프라, 구성 및 유지 관리 작업을 처리해야 함을 의미하며, 더 무거운 운영 부담을 만들고 잠재적인 통합 문제의 가능성을 높입니다.
하이브리드 검색에서 Elasticsearch와 Milvus 비교
그림: 하이브리드 검색에서 Elasticsearch와 Milvus 비교
하이브리드 검색을 위한 통합 솔루션은 많은 이점을 제공합니다:
인프라 유지 관리 감소: 두 시스템이 아닌 하나의 시스템을 관리하면 운영 복잡성이 크게 줄어들어 시간과 리소스를 모두 절약할 수 있습니다. 이는 또한 두 가지 서로 다른 API 세트를 익히기 위한 컨텍스트 전환과 정신적 부담이 줄어든다는 의미이기도 합니다.
통합된 데이터 관리: 통합 테이블 구조를 사용하면 밀집(벡터 기반) 및 희소(키워드 기반) 데이터를 공유 메타데이터 레이블과 함께 저장할 수 있습니다. 두 개의 별도 시스템을 사용하면 양쪽 모두에서 메타데이터 필터링을 수행할 수 있도록 메타데이터 레이블을 두 번 저장해야 합니다.
간소화된 쿼리: 단일 요청으로 시맨틱 검색과 전문 검색 작업을 모두 수행할 수 있어, 별도의 시스템에 두 번의 API 호출을 수행할 필요가 없습니다.
향상된 보안 및 접근 제어: 통합된 접근 방식은 모든 접근 제어를 벡터 데이터베이스 내에서 중앙 집중식으로 관리할 수 있어 보안 규정 준수와 일관성을 강화하므로, 보다 간단하고 강력한 보안 관리를 가능하게 합니다.
통합 벡터 접근 방식이 하이브리드 검색을 단순화하는 방법
시맨틱 검색에서 머신 러닝 모델은 텍스트를 그 의미에 기반해 고차원 공간의 점, 즉 밀집 벡터로 “임베딩”합니다. 의미가 유사한 텍스트들은 이 공간에서 서로 더 가깝습니다. 예를 들어, “apple”과 “fruit”는 이 공간에서 “apple”과 “car”보다 더 가까울 수 있습니다. 이를 통해 근사 최근접 이웃(ANN) 알고리즘을 사용해 각 점 사이의 거리를 계산하는 것만으로 의미적으로 관련된 텍스트를 빠르게 찾을 수 있습니다.
이 방법은 문서와 쿼리를 희소 벡터로 인코딩함으로써 전문 검색에도 적용할 수 있습니다. 희소 벡터에서는 각 차원이 하나의 용어를 나타내며, 값은 문서에서 각 용어가 얼마나 중요한지를 나타냅니다.
문서에 존재하지 않는 용어의 값은 0입니다. 일반적으로 주어진 문서는 어휘에 존재하는 모든 가능한 용어 중 작은 일부만 사용하므로, 대부분의 용어는 문서에 나타나지 않습니다. 이는 결과 벡터가 희소하다는 것을 의미합니다 — 값의 대부분이 0입니다. 예를 들어 정보 검색 작업 평가에 일반적으로 사용되는 MS-MARCO 데이터 세트에는 약 900만 개의 문서와 100만 개의 고유 용어가 있지만, 검색 시스템은 일반적으로 관리 용이성을 위해 이 대규모 컬렉션을 더 작은 세그먼트로 나눕니다.
세그먼트 수준에서도 어휘에 수십만 개의 용어가 있으면 각 문서는 일반적으로 100개 미만의 용어를 포함하며, 이는 각 벡터 값의 99% 이상이 0이라는 의미입니다. 이러한 극단적인 희소성은 이 벡터들을 효율적으로 저장하고 처리하는 방식에 중요한 영향을 미칩니다.
이러한 희소성 패턴은 정확도를 유지하면서 검색 성능을 최적화하는 데 활용될 수 있습니다. 원래 밀집 벡터용으로 설계된 벡터 데이터베이스도 이러한 희소 벡터를 효율적으로 처리하도록 조정할 수 있습니다. 예를 들어, 오픈 소스 벡터 데이터베이스 Milvus는 Elasticsearch 및 기타 전문 검색 시스템에서 사용하는 BM25 알고리즘의 희소 벡터 구현인 Sparse-BM25를 사용하여 네이티브 전문 검색 지원을 막 출시했습니다. Sparse-BM25는 다음을 통해 전문 검색을 위한 근사 기반 최적화를 가능하게 합니다:
데이터 프루닝을 통한 효율적인 검색 알고리즘: 세그먼트 인덱스에서 희소 벡터 값이 가장 낮은 문서를 폐기하는 휴리스틱 기반 프루닝을 적용하고 검색 쿼리에서 낮은 값의 희소 벡터를 무시함으로써, 벡터 데이터베이스는 품질 손실을 최소화하면서 인덱스 크기를 크게 줄이고 성능을 최적화할 수 있습니다.
추가 성능 최적화의 실현: 용어 빈도를 역색인 대신 희소 벡터로 표현하면 추가적인 벡터 기반 최적화가 가능해집니다. 여기에는 다음이 포함됩니다:
그래프 인덱싱은 브루트포스 스캔보다 더 효율적인 검색에 사용됩니다.
메모리 사용량을 더욱 줄이기 위한 곱 양자화(PQ) / 스칼라 양자화(SQ).
이러한 최적화 외에도, Sparse-BM25 구현은 고성능 벡터 데이터베이스 Milvus로부터 여러 시스템 수준의 장점도 상속합니다:
효율적인 저수준 구현 및 메모리 관리: Milvus의 핵심 벡터 인덱싱 엔진은 C++로 구현되어 Elasticsearch와 같은 Java 기반 시스템보다 더 효율적인 메모리 관리를 제공합니다. 이것만으로도 JVM 기반 접근 방식에 비해 기가바이트 단위의 메모리를 절약하여 메모리 사용량을 줄입니다.
MMap 지원: Elasticsearch가 메모리와 디스크 모두에서 인덱스 저장을 위해 페이지 캐시를 사용하는 것과 유사하게, Milvus는 인덱스가 사용 가능한 메모리를 초과할 때 메모리 용량을 확장하기 위해 memory mapping (MMap)을 지원합니다.
기존 검색 스택이 벡터 검색에서 한계를 보이는 이유
Elasticsearch는 기존의 역색인을 위해 구축되었기 때문에, 전체 아키텍처를 밀집 벡터 검색에 최적화하는 것은 근본적으로 어렵습니다. 그 영향은 명확합니다. 단 100만 개의 벡터만으로도 Elasticsearch는 검색 결과를 반환하는 데 200밀리초(완전 관리형 Elastic Cloud에서 테스트)를 소요하는 반면, Milvus는 6ms(완전 관리형 Zilliz Cloud에서 테스트)에 불과합니다 — 이는 30배가 넘는 성능 차이입니다. 초당 쿼리 수(QPS)로 측정한 처리량도 3배 차이가 나며, Zilliz Cloud의 가장 성능이 뛰어난 인스턴스는 6000 QPS로 실행되는 반면 Elastic Cloud는 최대 1900 QPS입니다. 또한 Zilliz Cloud는 벡터 데이터를 로드하고 인덱스를 구축하는 데 Elastic Cloud보다 15배 더 빠릅니다. 이러한 성능 격차는 규모가 커질수록 더 벌어지며, Elasticsearch의 Java/JVM 구현은 C++/Go 기반 벡터 데이터베이스의 확장성을 따라잡는 데 어려움을 겪습니다. 또한 Elasticsearch에는 디스크 기반 인덱스(DiskAnn, MMap), 최적화된 메타데이터 필터링, 범위 검색과 같은 중요한 벡터 검색 기능이 부족합니다.
VectorDBBench Benchmarking Results.jpg
그림: VectorDBBench 벤치마킹 결과 (출처)
결론
Milvus로 대표되는 벡터 데이터베이스는 하이브리드 검색을 위한 통합 솔루션으로 Elasticsearch를 능가할 준비가 되어 있습니다. 밀집 벡터 검색과 최적화된 희소 벡터 기술을 통합함으로써, 벡터 데이터베이스는 뛰어난 성능, 확장성 및 효율성을 제공합니다. 이러한 통합 접근 방식은 인프라를 단순화하고, 메모리 사용량을 줄이며, 검색 기능을 향상시켜 고급 검색 요구의 미래가 됩니다. 그 결과, 벡터 데이터베이스는 의미 기반 검색과 전문 검색을 원활하게 결합하는 포괄적인 솔루션을 제공하며, Elasticsearch와 같은 기존 검색 시스템보다 뛰어난 성능을 발휘합니다.
계속 읽기
My Wife Wanted Dior. I Spent $600 on Claude Code to Vibe-Code a 2M-Line Database Instead.
Write tests, not code reviews. How a test-first workflow with 6 parallel Claude Code sessions turns a 2M-line C++ codebase into a daily shipping pipeline.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.
Vector Databases vs. Key-Value Databases
Use a vector database for AI-powered similarity search; use a key-value database for high-throughput, low-latency simple data lookups.