과거에 데이터 검색이라고 하면 SQL로 완전 일치 조건을 작성하는 것이 일반적이었습니다. 하지만 현재는 AI와 시맨틱 검색 (Semantic Search)의 시대입니다. AI는 키워드를 대조할 뿐만 아니라, 사용자의 의도를 이해하여 정보를 검색합니다.

이러한 변화를 뒷받침하고 있는 것이 벡터 데이터베이스 (Vector Database)입니다. 벡터 데이터베이스는 ChatGPT의 검색 시스템, Netflix의 개인화된 추천, Tesla의 자율 주행 스택 등 고도의 AI 애플리케이션의 기반으로서 이용되고 있습니다.

하지만 모든 벡터 데이터베이스가 동일하게 설계되어 있는 것은 아닙니다.

• RAG (Retrieval-Augmented Generation) 애플리케이션에서는 수십억 건의 문서에 대한 고속 시맨틱 검색이 필요함
• 추천 시스템에서는 대량의 트래픽 하에서도 서브 밀리초 (Sub-millisecond) 단위의 응답이 요구됨
• 컴퓨터 비전 (Computer Vision) 파이프라인에서는 급증하는 이미지 데이터를 비용 효율적으로 처리할 필요가 있음

한편, 시장에는 Elasticsearch, Milvus, PGVector, Qdrant, AWS의 S3 Vector 등 수많은 선택지가 있습니다. 각각이 우수성을 내세우고 있지만, 중요한 것은 "무엇에 최적화되어 있는가"입니다. 선택을 잘못하면 수개월 분량의 개발 공수나 인프라 비용을 낭비하게 되어 제품의 경쟁력을 해칠 가능성이 있습니다.

본 기사에서는 벡터 데이터베이스를 선택할 때의 판단 축을 다음 세 가지 관점에서 정리합니다.

• 기능
• 퍼포먼스 (Performance)
• 에코시스템 (Ecosystem)

인기나 인지도만으로 판단하지 않고, 자사의 유스케이스 (Use case)에 적합한 벡터 데이터베이스를 선택하기 위한 실전적인 프레임워크입니다.

벡터 데이터베이스 선정의 토대가 되는 것이 기능입니다. 단순히 벡터를 저장할 수 있으면 되는 것이 아닙니다. 실제 AI 워크로드 (Workload)에서는 다양하고 대규모이며, 현실 세계의 AI 워크로드에서 흔히 발생하는 복잡하고 다루기 어려운 요구사항을 지원하는 것이 요구됩니다.

장기 운용을 견딜 수 있는지를 판단하려면, 핵심이 되는 벡터 처리 기능과 장기적인 존속 가능성을 좌우하는 엔터프라이즈용 기능을 모두 평가해야 합니다.

텍스트, 이미지, 음성, 사용자 행동 등 AI 태스크 (Task)에 의해 생성되는 벡터의 종류는 다릅니다. 운영 시스템에서는 여러 종류의 벡터를 동시에 다루는 케이스도 드물지 않습니다.

EC 사이트의 상품 검색을 예로 들면, 다음과 같은 데이터가 사용됩니다.

상품 이미지: 이미지의 시각적 유사도 판정이나, 이미지를 입력으로 한 유사 이미지 검색에 사용하는 Dense Vector -
상품 설명: 키워드 매칭이나 전문 검색 (Full-text search)에 사용하는 Sparse Vector -
클릭, 구매, 즐겨찾기 등의 사용자 행동: 흥미를 고속으로 대조하기 위한 Binary Vector

표면적으로는 단순한 "검색"처럼 보여도, 내부에서는 멀티 벡터 및 멀티모달 (Multimodal) 검색 처리가 이루어지고 있습니다.

multi-vector_multimodal-search.png

벡터 검색에는 재현율 (Recall), 속도, 비용의 트레이드오프 (Trade-off)가 있습니다. 견고한 벡터 데이터베이스에는 유스케이스에 따라 적절한 균형을 선택할 수 있는 복수의 인덱스 (Index) 알고리즘이 필요합니다.

대표적인 선택지에는 다음과 같은 것들이 있습니다.

Flat: 검색 시 쿼리 벡터를 데이터셋 내의 모든 벡터와 비교하는 방식. 속도를 희생하는 대신 높은 정밀도를 얻기 쉬움 -
IVF (Inverted File Index): 벡터를 사전에 클러스터링하여 관련성이 높은 클러스터만을 검색하는 방식. 대규모 데이터셋에 적합하며 스케일러블하고 고속인 검색을 실현함 -
HNSW: 벡터끼리 다층 그래프로 연결하여, 그 그래프를 따라 근방을 고속으로 탐색하는 방식. 높은 재현율과 낮은 레이턴시 (Latency)의 균형이 좋은 반면, 인덱스 구축 시간과 메모리 사용량이 크다는 특징이 있음

엔터프라이즈용 시스템에서는 다음과 같은 기능도 중요합니다.

• 페타바이트 규모의 데이터를 저비용으로 저장하기 위한 디스크 기반 인덱싱 (Disk-based indexing) - 주) Disk-based indexing이란, 벡터 인덱스의 주요 부분을 RAM이 아닌 SSD 등의 디스크 상에 저장하고 검색 시 필요한 부분만 읽어들이는 방식입니다. 인덱스 전체를 RAM 상에 유지하여 고속이지만 비용이 높은 In-memory indexing에 비해, Disk-based indexing은 스토리지 비용을 억제하면서 대규모 데이터에 대응하기 쉽다는 점이 특징입니다.

• 초저지연 (Ultra-low latency) 처리를 위한 GPU 가속 (GPU Acceleration)

• 검색 및 추론의 각 처리 경로를 비즈니스 요구 사항에 맞춰 최적화하기 위한 세밀한 파라미터 조정 (Fine-grained parameter tuning) - 예를 들어, 검색 정밀도를 우선할지 속도를 우선할지, 몇 개의 후보를 탐색할지, 어떤 인덱스를 사용할지 등

제한된 리소스에서 최대한의 성능을 끌어내기 위해서는 인덱스의 동작을 세밀하게 조정할 수 있는 것이 중요합니다.

Top-K 유사 검색은 기본 기능에 불과합니다. 실제 애플리케이션에서는 더 고도화된 검색 전략이 필요합니다. 예를 들어,

• 필터 검색 (Filtered Search): 가격대, 재고 상황, 임계값 등에 의한 필터링
• 그룹 검색 (Grouped Search): 드레스, 스커트, 슈트 등 카테고리의 다양성을 고려한 검색 결과
• 하이브리드 검색 (Hybrid Search): 희소(Sparse) 텍스트 벡터 검색, 이미지의 밀집 임베딩 (Dense Embedding)을 이용한 유사 검색, 여기에 전문 검색 (Full-text search)을 결합한 하이브리드 검색

예를 들어, EC 사이트에서 "드레스를 보여줘"라는 요청을 처리할 경우, 내부에서는 다음과 같은 처리가 이루어질 수 있습니다.

• 상품의 이미지 벡터와 텍스트 벡터를 사용한 유사 검색

• 가격과 재고 상황에 의한 스칼라 필터링 (Scalar filtering)

• 스칼라 필터링 (Scalar filtering)이란 가격, 재고 수, 카테고리 등의 일반적인 속성값을 조건으로 검색 대상을 좁히는 것을 말합니다.

• 다양한 카테고리를 제시하기 위한 최적화

• 사용자 프로필의 임베딩과 구매 이력을 결합한 개인화 (Personalization)

단순해 보이는 추천 (Recommendation)도 여러 검색 기능을 계층적으로 결합함으로써 실현됩니다.

hybridsearch.png

비구조화 데이터는 급격히 증가하고 있습니다. IDC에 따르면, 2027년에는 246.9 제타바이트 (Zettabyte)에 달하며, 전 세계 데이터의 86.8%를 차지할 것으로 예상됩니다. 이러한 데이터를 AI 모델로 처리하면 대량의 벡터 데이터가 생성되며, 그 규모는 더욱 확대됩니다.

소규모 실험용으로 설계된 벡터 데이터베이스는 이러한 성장에 대응하지 못할 가능성이 있습니다. 엔터프라이즈 규모에서는 클라우드 네이티브 (Cloud-native)의 유연성과 확장성 (Scalability)이 필요합니다.

• 예측할 수 없는 부하 급증에 대응하는 탄력적 스케일링 (Elastic scaling)
• 여러 팀과 애플리케이션이 안전하게 인프라를 공유하기 위한 멀티테넌시 (Multi-tenancy) 지원
• 배포와 스케일링을 자동화하는 Kubernetes 및 클라우드 서비스와의 통합

운영 환경에서는 확장성뿐만 아니라 회복 탄력성 (Resilience)도 필수적입니다.

• 자동 페일오버 (Failover)를 갖춘 고가용성 (High availability)
• 리전(Region) 또는 존(Zone)을 넘나드는 멀티 레플리카 (Multi-replica) 구성과 재해 복구 (Disaster recovery)
• 장애를 감지하고 사람의 개입 없이 복구하는 자가 치유형 (Self-healing) 인프라

대규모 벡터 처리에서 중요한 것은 쿼리 속도만이 아닙니다. 데이터량에 맞춰 성장하고, 장애로부터 시스템을 보호하면서 엔터프라이즈 규모에서도 비용 효율성을 유지할 수 있는 아키텍처가 필요합니다.

필요한 기능을 충족했다면, 다음에 확인해야 할 것은 퍼포먼스 (Performance)입니다. 현재의 워크로드 (Workload)를 처리할 수 있을 뿐만 아니라, 트래픽이 급증할 때도 무리 없이 스케일링할 수 있어야 합니다.

평가 시에는 단순한 검색 속도뿐만 아니라 여러 지표를 확인합니다.

벡터 데이터베이스 평가에서는 최소한 다음 지표들을 확인합니다.

• 레이턴시 (Latency, P50, P95, P99): 일반적인 상황뿐만 아니라 최악의 조건에서의 응답 시간을 파악합니다. (P50, P95, P99는 레이턴시의 백분위수 값입니다.)
• 처리량 (Throughput, QPS): 실제 부하 상황에서 동시 실행 성능을 측정합니다.
• 정확도 (Recall@K): 근사 검색 (Approximate search)에서도 관련성이 높은 결과를 반환할 수 있는지 확인합니다.
• 데이터 규모 적응성: 데이터량을 수백만, 수천만, 수십억 건으로 늘렸을 때의 성능을 평가합니다.

실제 운영을 상정하는 경우에는 다음 항목들도 추가로 측정합니다.

• 해당 데이터 비율이 1%~99%로 달라지는 필터 조건하에서의 검색 성능. 1%~99%까지 조건의 엄격함을 변경하며 측정함으로써 운영 환경에서의 성능 안정성을 확인합니다.
• 지속적인 데이터 삽입과 실시간 검색을 동시에 수행하는 스트리밍 워크로드 (Streaming workload)
• CPU, 메모리, 디스크 I/O 등의 리소스 효율성

검색이 빠르더라도 대량의 리소스를 소비하는 구성이라면 비용 효율성에 문제가 생길 수 있습니다.

ANN-Benchmark는 알고리즘 수준의 평가 수단으로 널리 알려져 있습니다. 다만, 주로 기반이 되는 알고리즘 라이브러리를 대상으로 하고 있어 동적인 시나리오는 충분히 커버하지 못합니다. 데이터셋이나 유스케이스 (Use case) 또한 실제 운영 환경을 상정하기에는 너무 단순할 수 있습니다.

실제 벡터 데이터베이스 (Vector Database)를 평가할 때는 오픈 소스인 VDBBench를 이용할 수 있습니다. VDBBench는 실제 운영 환경에 가까운 여러 시나리오를 커버하도록 설계되었습니다.

VDBBench를 통한 평가는 주로 다음 3단계로 진행됩니다.

이용 시나리오 결정

SIFT1M 또는 GIST1M 등의 데이터셋을 선택하고, Top-K 검색, 필터 검색, 동시 읽기/쓰기 등의 시나리오를 설정합니다. -
데이터베이스와 VDBBench 파라미터 설정

공정하고 재현 가능한 테스트가 될 수 있도록, 데이터베이스와 벤치마크의 파라미터를 맞춥니다. -
테스트 실행 및 분석

웹 인터페이스를 통해 테스트를 실행하고 성능 지표를 자동으로 수집합니다. 결과를 비교하여 데이터에 기반해 제품을 선정합니다.

실제 워크로드 (Workload)에 가까운 벤치마크 방법에 대해서는 다음 기사도 참조해 주세요.

벡터 데이터베이스는 단독으로 동작하는 것이 아닙니다. 주변 에코시스템 (Ecosystem)에 따라 도입의 용이성, 확장 속도, 장기적인 운영 가능성이 달라집니다.

평가 시에는 다음 4가지 관점을 확인합니다.

운영 환경에 대응하는 벡터 데이터베이스는 이미 사용 중인 AI 도구와 직접 연동될 수 있어야 합니다.

• OpenAI, Claude, Qwen 등의 주요 LLM 및 임베딩 (Embedding) 서비스에 대한 네이티브 지원
• LangChain, LlamaIndex, Dify 등의 개발 프레임워크와의 호환성
• 텍스트, 이미지, 자체 모델 등 여러 소스에서 생성된 벡터를 다룰 수 있는 유연성

이러한 연동이 가능하다면 RAG 파이프라인, 추천 엔진, Q&A 시스템 등을 기존의 기술 스택 (Tech Stack)과 무리 없이 조합하여 구축할 수 있습니다.

고성능 벡터 데이터베이스라도 운영이 어렵다면 운영 환경에 정착할 수 없습니다. 주변 도구와의 호환성을 포함하여 다음과 같은 운영 기능을 확인합니다.

• 데이터 관리, 성능 모니터링, 권한 관리를 수행하는 비주얼 대시보드
• 전체 백업 및 증분 백업을 지원하는 백업 및 복구 (Backup & Recovery)
• 필요한 리소스를 예측하고 클러스터를 효율적으로 확장하는 캐파시티 플래닝 (Capacity Planning)
• 로그 분석, 병목 현상 탐지, 트러블슈팅을 지원하는 진단 및 튜닝 기능
• Prometheus나 Grafana 등 표준 도구와 연동된 모니터링 및 알림 (Alerting)

이것들은 단순히 "있으면 편리한" 기능이 아닙니다. 심야 시간대의 트래픽 급증 시에도 시스템을 안정적으로 가동하기 위해 필요한 운영 기반입니다.

벡터 데이터베이스는 현재도 급격히 진화하고 있습니다. 오픈 소스는 개발 속도와 커뮤니티의 피드백이라는 장점이 있지만, 대규모 프로젝트에는 지속 가능한 상용 지원도 필요합니다.

Spark, MongoDB, Kafka 등의 주요 데이터 플랫폼도 오픈 혁신과 그 배후에 있는 기업의 지원을 양립하고 있습니다.

상용 서비스를 평가할 때는 특정 클라우드에 과도하게 의존하지 않고, 탄력적(Elastic)이며 운영 부하가 낮고, 산업 및 지역별 요구사항에 유연하게 대응할 수 있는지도 중요합니다.

마케팅 자료뿐만 아니라 실제 고객 사례도 확인할 필요가 있습니다.

신뢰할 수 있는 벡터 데이터베이스에는 금융, 의료, 제조, 인터넷, 법률 등의 산업 분야 사례와 다음과 같은 유스케이스 (Use case)에서의 실적이 요구됩니다.

• 검색

• 추천 (Recommendation)

• 리스크 관리

• 고객 지원

• 품질 검사

동일한 산업군이나 유사한 요구사항을 가진 기업이 이미 성공했다는 점은 유력한 판단 근거가 됩니다. 다만, 최종적으로는 자사의 데이터와 워크로드를 사용하여 PoC를 실시하는 것이 중요합니다.

기능, 성능, 에코시스템이라는 세 가지 관점에서 평가하면 모든 조건을 일관되게 충족하는 벡터 데이터베이스는 한정적입니다. Milvus가 그중 하나입니다.

Milvus는 오픈 소스 프로젝트로 탄생하여 Zilliz에 의해 지원되고 있습니다. AI 네이티브 워크로드에 맞게 설계되어 고도의 인덱스 (Index) 및 검색 기능과 더불어 엔터프라이즈급 신뢰성도 갖추고 있습니다.

RAG, AI 에이전트, 추천 엔진, 시맨틱 검색 (Semantic Search) 시스템을 구축하는 개발자도 사용하기 쉬운 설계입니다. GitHub에서 45,000개 이상의 스타(Star)를 획득했으며, 10,000개 이상의 기업에서 채택하고 있습니다.

Milvus는 단일 API로 여러 가지 배포 방식을 제공합니다.

• Milvus Lite: 신속한 실험 및 프로토타이핑 (Prototyping)에 적합한 경량 버전
• Standalone: 단순한 운영 환경 배포 (Production Deployment)용
• Cluster: 수십억 개의 벡터까지 확장 가능한 분산 배포용

이러한 유연성 덕분에 소규모 구성으로 시작하여 코드 수정 없이도 스케일 아웃 (Scale-out)할 수 있습니다.

Milvus의 주요 특징은 다음과 같습니다.

포괄적인 기능: 텍스트, 이미지, 음성 등의 멀티모달 벡터 (Multimodal Vector), IVF, HNSW, 디스크 기반, GPU 가속 등의 인덱스 방식 (Index Methods), 하이브리드 검색, 필터 검색, 그룹 검색, 전체 텍스트 검색 등의 고급 검색 방식
검증된 성능: 10억 건 규모의 데이터셋에 최적화되어 있으며, 인덱스 설정을 조정할 수 있을 뿐만 아니라 VDBBench와 같은 도구를 사용한 벤치마크 (Benchmark)에도 대응
견고한 에코시스템 (Ecosystem): LLM, 임베딩 모델 (Embedding Model), LangChain, LlamaIndex, Dify 등과 연동되며, 모니터링, 백업, 복구, 용량 계획 (Capacity Planning)을 포함한 운영 툴체인 (Toolchain) 제공
엔터프라이즈 대응: 고가용성 (High Availability), 멀티 레플리카 (Multi-replica)를 통한 재해 복구, RBAC, 관측성 (Observability)을 비롯하여, 완전 관리형 서비스인 Zilliz Cloud 이용 가능

Milvus는 오픈 소스 (Open Source)의 유연성, 엔터프라이즈 시스템에 필요한 확장성 및 신뢰성, 그리고 AI 개발을 가속화하는 에코시스템 연동을 결합하고 있습니다.

Milvus는 오픈 소스이며 무료로 사용할 수 있습니다. 반면, 인프라 운영이 아닌 AI 애플리케이션 개발에 집중하고 싶다면 Zilliz Cloud를 권장합니다.

Zilliz Cloud는 Milvus 개발팀이 제공하는 완전 관리형 (Fully Managed) Milvus 서비스입니다. Milvus의 기능에 더해, 운영 부담을 줄이면서 사용할 수 있는 엔터프라이즈급 기능을 제공합니다.

주요 특징은 다음과 같습니다.

• 몇 분 만에 배포 가능하며 자동으로 스케일링 (Scaling)
• 사용량 기반 요금 체계
• 자연어를 통한 쿼리 (Query)
• 엔터프라이즈급 보안
• 글로벌 규모의 확장성 및 각 지역에 최적화된 높은 성능
• 99.95% 가동률 SLA (Service Level Agreement)

스타트업이든 대기업이든, 기술 팀은 데이터베이스 관리가 아닌 제품 개발에 시간을 써야 합니다. Zilliz Cloud는 스케일링, 보안, 신뢰성 관리를 담당하여 팀이 AI 애플리케이션 개발에 집중할 수 있는 환경을 제공합니다.

벡터 데이터베이스는 급격히 진화하고 있으며, 새로운 기능과 최적화가 지속적으로 등장하고 있습니다. 이번에 소개한 다음 세 가지 평가 축을 사용하면 수많은 선택지를 구조적으로 비교할 수 있습니다.

• 기능
• 성능
• 에코시스템

하지만 이론적인 비교만으로는 충분하지 않습니다. 평가 프레임워크 (Framework)를 통해 후보를 좁히고, 자사의 데이터와 워크로드 (Workload)를 사용한 PoC (Proof of Concept)를 통해 검증하는 것이 중요합니다.

AI 애플리케이션이 고도화되고 데이터량이 증가함에 따라, 현재 선택한 벡터 데이터베이스는 미래의 인프라를 지탱하는 중요한 요소가 됩니다. 충분한 시간을 들여 평가하는 것은 향후의 성능, 확장성, 그리고 팀의 생산성 향상으로 이어집니다.

시맨틱 검색 (Semantic Search)을 효과적으로 활용할 수 있는지 여부가 AI 애플리케이션의 경쟁력을 좌우합니다. 인기나 광고 문구에 휘둘리지 말고, 자사의 요구사항에 기반하여 벡터 데이터베이스를 선택하십시오.