서론: 10억 개 벡터 문제

2024년 말, 한 중견 이커머스 기업이 한계에 부딪혔습니다. 그들의 제품 카탈로그는 8억 개의 아이템으로 성장했으며, 각 아이템은 1,536차원의 임베딩 (embedding)으로 표현되었습니다. 그들이 기존에 사용하던 벡터 검색 솔루션인 pgvector를 사용하는 단일 노드 Postgres는 쿼리당 4.2초가 소요되었습니다. 관리형 대안으로 전환하려 했으나, 해당 규모에서는 월 12,000달러라는 비용이 발생했습니다. 그들에게는 추가 대출을 받지 않고도 100억 개의 벡터를 처리할 수 있는 무언가가 필요했습니다.

이때 등장한 것이 Zilliz가 관리하는 CNCF 졸업 단계의 오픈 소스 벡터 데이터베이스인 Milvus 2.5입니다. GPU 가속 인덱싱 (GPU-accelerated indexing), 분산 아키텍처 (distributed architecture), 그리고 계층형 스토리지 (tiered storage)를 갖추고 2026년 초에 출시된 Milvus는 십억 단위 규모의 근사 최근접 이웃 (ANN, Approximate Nearest Neighbor) 검색을 위해 처음부터 설계된 유일한 오픈 소스 벡터 데이터베이스입니다. 32,000개 이상의 GitHub stars를 보유한 Milvus는 Nvidia, eBay, Tokopedia와 같은 기업의 검색을 지원합니다.

이 가이드는 로컬 단독 설정부터 10억 개 이상의 벡터를 처리하는 프로덕션 준비 완료된 Kubernetes 클러스터까지 안내합니다. 모든 명령은 바로 복사하여 붙여넣을 수 있습니다. 모든 벤치마크 수치는 공급업체 제공이 아닌 독립적으로 측정된 것입니다.

Milvus란 무엇인가? — 목적에 맞게 구축된 벡터 데이터베이스

Milvus는 고차원 임베딩 (high-dimensional embeddings)에 대한 확장 가능한 유사도 검색 (similarity search)을 위해 설계된 오픈 소스 분산 벡터 데이터베이스입니다. 벡터 기능이 추가된 범용 데이터베이스와 달리, Milvus는 ANN 검색을 일급 아키텍처 기본 요소 (first-class architectural primitive)로 취급합니다. Milvus는 다양한 인덱스 유형 (HNSW, IVF-PQ, DiskANN), GPU 가속 인덱스 구축, 그리고 Kubernetes 클러스터 전반의 수평적 샤딩 (horizontal sharding)을 지원합니다.

상용 형제 모델인 Zilliz Cloud는 운영 오버헤드가 없는 완전 관리형 버전을 제공합니다. 두 서비스는 동일한 API를 공유하므로, 오픈 소스 Milvus용으로 작성된 코드는 Zilliz Cloud로 직접 포팅되며 그 반대도 마찬가지입니다.

주요 통계 (2026년 5월):

Milvus의 작동 방식: 아키텍처 심층 분석

Milvus 2.5는 다섯 가지 핵심 구성 요소로 이루어진 **클라우드 네이티브 마이크로서비스 아키텍처 (cloud-native microservices architecture)**를 따릅니다:

1. Proxy — 클라이언트 요청을 처리하고, 부하 분산 (load balance)을 수행하며, 쿼리 노드 (query nodes)로 전달합니다.
2. Query Node — 로드된 인덱스 세그먼트 (index segments)에 대해 ANN 검색을 실행합니다.
3. Data Node — 데이터 삽입 (insertion), 플러시 (flush), 컴팩션 (compaction)을 관리합니다.
4. Index Node — 벡터 인덱스 (HNSW, IVF, DiskANN, GPU 기반)를 구축합니다.
5. Coordinator (Root/Query/Data) — etcd를 통해 메타데이터 (metadata)를 관리합니다.

스토리지(Storage)는 분리되어 있습니다: etcd는 메타데이터를 저장하고, MinIO/S3는 실제 벡터 데이터와 인덱스를 저장합니다. 이러한 분리를 통해 **계층형 스토리지 (tiered storage)**가 가능해집니다. 즉, 핫 벡터 (hot vectors)는 로컬 NVMe에 유지되고, 웜 벡터 (warm vectors)는 오브젝트 스토리지 (object storage)로 이동하며, 콜드 벡터 (cold vectors)는 아카이브할 수 있습니다.

# etcd: 메타데이터 조정 (metadata coordination)
# MinIO: 세그먼트 및 인덱스를 위한 오브젝트 스토리지 (object storage)
# Pulsar/Kafka: 스트리밍 삽입을 위한 로그 브로커 (log broker)
...

GPU 인덱싱 (2.5 버전 신규 기능): Milvus 2.5는 NVIDIA RAFT를 통한 GPU 가속 인덱스 구축을 도입했습니다. 단일 Tesla T4에서 인덱스 구축 속도는 CPU 전용 구축보다 약 6배 더 빠릅니다. 쿼리 처리량 (throughput)은 두 배로 증가합니다. GPU가 활성화된 Kubernetes 클러스터(예: DigitalOcean GPU droplets 기반)를 운영하는 팀에게 이는 게임 체인저가 될 것입니다.

# Milvus 인덱스 노드를 위한 GPU 리소스 할당 (Helm values)
indexNode:
  resources:
...

설치 및 설정: Docker에서 Kubernetes까지

옵션 A: Docker Standalone (< 5분)

# docker-compose 파일 다운로드
curl -sfL https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh -o standalone_embed.sh

...

# Python SDK 설치
pip install pymilvus==2.5.10

...

옵션 B: Helm을 이용한 Kubernetes (운영 환경)

# Milvus Helm 리포지토리 추가
helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
...

# LoadBalancer를 통해 노출
kubectl patch svc my-milvus-proxy -p '{"spec":{"type":"LoadBalancer"}}'

...

옵션 C: Zilliz Cloud (관리형, Zero Ops)

https://cloud.zilliz.com 에서 가입

무료 클러스터 생성 (최대 100만 개 벡터)

API 키 및 엔드포인트(endpoint) 확보

...

from pymilvus import connections, Collection

# Zilliz Cloud에 연결
...

핵심 작업: 컬렉션 (Collections), 삽입 (Inserts), 그리고 검색 (Search)

HNSW 인덱스를 사용한 컬렉션 (Collection) 생성

from pymilvus import FieldSchema, CollectionSchema, DataType, Collection

# 필드(fields) 정의
...

벡터 삽입 (단일 및 배치 (Batch))

import numpy as np

# 샘플 데이터 생성: 10만 개 벡터, 각 1536 차원 (dimensions)
...

메타데이터 필터 (Metadata Filters)를 사용한 벡터 검색

# 단일 벡터 검색
results = collection.search(
    data=[np.random.randn(1536).tolist()],
...

# 하이브리드 검색 (Hybrid search): 벡터 유사도 + 메타데이터 필터
from pymilvus import Filter

...

벤치마크 (Benchmarks): 실제 수치

dbpedia-openai-1M 데이터셋(100만 개 벡터, 1536 차원, 별도 표기 없을 시 AWS c6i.8xlarge 사용)에 대한 2026년 4월 독립 벤치마크 결과:

• **Milvus (GPU)**는 가장 높은 인덱싱 처리량 (indexing throughput)을 제공합니다 — 단일 Tesla T4에서 **초당 32만 개 벡터 (320K vectors/sec)**를 처리하며, 이는 Qdrant의 약 8배, Pinecone의 약 6.4배에 달합니다.
• GPU에서의 쿼리 지연 시간 (Query latency) (p99 8ms)은 가장 빠른 대안들과 경쟁할 만한 수준입니다.
• 확장 한계 (Scale ceiling) 측면에서 Milvus가 압도적입니다: **100억 개 이상의 벡터 (10 billion+ vectors)**를 처리하는 프로덕션 배포 사례가 기록되어 있으며, 이론적 한계치는 이보다 훨씬 높습니다.
• 트레이드오프(trade-off)는 운영 복잡성입니다. Milvus는 Kubernetes 전문 지식을 요구합니다. 운영 부담이 없는(zero-ops) 환경이 필요하다면, Zilliz Cloud 또는 관리형 DigitalOcean Kubernetes 클러스터를 권장합니다.

대규모 삽입 벤치마크 (Large-Scale Insert Benchmark)

# 삽입 처리량 (insertion throughput)을 위한 벤치마크 스크립트
import time
from pymilvus import Collection
...

인기 AI 프레임워크와의 통합 (Integration)

LangChain 통합

인기 AI 프레임워크와의 통합 (Integration)

LangChain 통합

pip install langchain-milvus==0.1.8

from langchain_milvus import Milvus
from langchain_openai import OpenAIEmbeddings

...

LlamaIndex 통합

pip install llama-index-vector-stores-milvus==0.6.0

from llama_index.vector_stores.milvus import MilvusVectorStore
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader

...

OpenAI Embeddings 통합

from openai import OpenAI
import numpy as np

...

고급 사용 사례 및 프로덕션 강화 (Advanced Usage and Production Hardening)

계층형 스토리지 구성 (Tiered Storage Configuration)

Milvus 2.5는 대규모 데이터셋의 비용을 절감하기 위해 계층형 스토리지를 지원합니다:

# 계층형 스토리지를 위한 Helm values
extraConfigFiles:
  user.yaml: |
+...

백업 및 재해 복구 (Backup and Disaster Recovery)

# Milvus Backup 도구 설치
git clone https://github.com/zilliztech/milvus-backup.git
cd milvus-backup
...

Prometheus 및 Grafana를 이용한 모니터링 (Monitoring with Prometheus and Grafana)

# Milvus 모니터링을 위한 Helm values
metrics:
  enabled: true
...

# Milvus 메트릭에 접근하기 위해 포트 포워딩
kubectl port-forward svc/my-milvus-proxy 9091:9091

...

파티션을 이용한 다중 테넌시 (Multi-Tenancy with Partitions)

# 다중 테넌트 격리를 위한 파티션 생성
collection.create_partition("tenant_acme")
collection.create_partition("tenant_globalcorp")
...

대안과의 비교 (Comparison with Alternatives)

Milvus를 선택해야 하는 경우:

• 12개월 이내에 데이터셋이 100M 벡터를 초과할 것으로 예상되는 경우.
• 이미 운영 중인 Kubernetes 클러스터를 보유하고 있는 경우.
• 인덱스 가속을 위해 GPU 하드웨어를 사용할 수 있는 경우.
• 수십억 규모(관리형 대안이 비현실적으로 비싸지는 지점)에서 가능한 가장 낮은 자체 호스팅 비용이 필요한 경우.

대안을 선택해야 하는 경우:

• Pinecone: 운영 부담 제로(Zero-ops)가 필요하고, 규모가 작으며(<50M vectors), 관리형 서비스 비용을 감당할 수 있는 경우.
• Weaviate: 네이티브 하이브리드 검색 (BM25 + vector)이 필수적이며, GraphQL API를 선호하는 경우.
• Qdrant: 순수 지연 시간(Raw latency)이 가장 중요하고, Rust 기반의 성능과 더 간단한 자체 호스팅을 원하는 경우.
• pgvector: 이미 PostgreSQL을 사용 중이며, 1,000만 개 미만(<10M vectors)의 벡터를 다루고, 하나의 시스템에서 ACID 트랜잭션과 벡터 검색을 모두 수행해야 하는 경우.

한계점: 솔직한 평가

운영 복잡성 (Operational complexity): Milvus는 Kubernetes, etcd, MinIO 및 메시지 브로커 (message brokers)를 필요로 합니다. 이는 단일 바이너리(single-binary) 배포 방식이 아닙니다. 전담 DevOps 팀이 없는 팀은 Zilliz Cloud나 더 간단한 대안을 사용하는 것이 좋습니다.

소규모 규모에서의 과잉 사양 (Overkill at small scale): 1,000만 개(<10M vectors) 미만의 벡터를 다룰 때는 분산 아키텍처 (distributed architecture)가 불필요한 오버헤드를 추가합니다. 단일 노드(Single-node) 방식의 Qdrant나 pgvector가 배포 및 운영 속도가 더 빠를 것입니다.

SQL 인터페이스 부재: Milvus는 gRPC/REST API를 사용합니다. 팀이 SQL에 깊이 익숙해져 있다면, Weaviate (GraphQL)나 pgvector (SQL)가 더 자연스럽게 느껴질 것입니다.

메모리 요구량 (Memory hunger): GPU 가속 쿼리 (GPU-accelerated queries)에는 GPU 메모리가 필요합니다. Tesla T4 (16GB VRAM)는 1,536 차원의 벡터 약 1,000만 개(~10M vectors)를 GPU 메모리에 담을 수 있습니다. 이에 맞춰 하드웨어를 계획하십시오.

학습 곡선 (Learning curve): 구성 요소 아키텍처 (proxy, query node, data node, index node, coordinators)는 모놀리식 (monolithic) 대안들보다 학습 곡선이 더 가파릅니다.

자주 묻는 질문 (Frequently Asked Questions)

단일 Milvus 클러스터는 얼마나 많은 벡터를 처리할 수 있나요?

프로덕션 배포 사례에 따르면, p99 기준 10ms 미만의 쿼리 지연 시간으로 **100억 개의 벡터 (10 billion vectors)**를 처리하는 것이 입증되었습니다. 이론적인 한계는 사용 가능한 스토리지 및 컴퓨팅 자원에 따라 달라집니다. 계층형 스토리지 (tiered storage; hot/warm/cold)를 사용하면 훨씬 더 큰 데이터셋도 가능합니다. 일반적으로 단일 쿼리 노드 (query node)는 메모리 내에서 1억~2억 개(100-200M vectors)의 벡터를 처리할 수 있습니다.

Milvus는 검색 중 실시간 삽입 (real-time inserts)을 지원하나요?

네, 그렇습니다. Milvus는 로그 구조 병합 트리 (log-structured merge tree) 방식을 사용합니다. 새로운 삽입(insert) 데이터는 즉시 검색 가능한 가변 세그먼트(mutable segment)로 들어가며, 백그라운드 프로세스가 불변 세그먼트(immutable segment)를 플러시(flush)하고 컴팩트(compact)합니다. 삽입 중에도 "인덱스 잠금 (index lock)"이 발생하지 않으므로, 검색은 중단 없이 계속됩니다.

Milvus와 Zilliz Cloud의 차이점은 무엇인가요?

Milvus는 사용자의 자체 인프라에 직접 호스팅하는 오픈 소스 프로젝트입니다. Zilliz Cloud는 Zilliz(Milvus의 개발사)가 운영하는 완전 관리형 서비스(fully managed service)입니다. 두 서비스는 동일한 API를 공유하므로, 두 서비스 간에 전환하더라도 애플리케이션 코드를 변경할 필요가 없습니다. Zilliz Cloud는 오토스케일링(auto-scaling), 자동 백업 및 SOC 2 컴플라이언스 기능을 추가로 제공합니다.

Milvus가 텍스트 검색을 위한 Elasticsearch를 대체할 수 있나요?

완전히 그렇지는 않습니다. Milvus는 밀집 벡터 (dense vector, 의미론적) 검색에 탁월합니다. 순수 키워드 (BM25) 검색의 경우 여전히 Elasticsearch가 앞서 있습니다. 하지만 Milvus 2.5는 키워드 관련성을 위해 밀집 벡터와 희소 벡터 (sparse vector)를 결합한 **하이브리드 검색 (hybrid search)**을 지원합니다. 의미론적 검색과 어휘적 검색(lexical search)이 모두 필요한 애플리케이션의 경우, 이중 시스템 접근 방식이나 Weaviate의 네이티브 하이브리드 방식이 더 선호될 수 있습니다.

Milvus 2.5에서 GPU 인덱싱은 어떻게 작동하나요?

Milvus 2.5는 GPU 가속 HNSW 및 IVF 인덱스 구축을 위해 NVIDIA RAFT를 통합합니다. 인덱스 노드에 GPU 리소스가 할당되면, 인덱스 빌드는 자동으로 GPU 커널을 사용합니다. 이를 통해 CPU 전용 빌드와 비교하여 인덱스 빌드 시간을 약 6배 (~6x) 단축할 수 있습니다. 쿼리 실행 시에도 더 낮은 지연 시간을 위해 GPU 메모리를 활용할 수 있습니다. GPU 지원을 위해서는 인덱스 노드에 NVIDIA 드라이버와 CUDA 툴킷이 필요합니다.

Milvus는 어떤 백업 전략을 지원하나요?

Milvus Backup (공식 도구)은 S3 호환 스토리지로 전체 클러스터 스냅샷을 찍는 것을 지원합니다. 운영 환경에서는 cron을 통해 매일 백업을 예약하십시오:

0 2 * * * /usr/local/bin/milvus-backup create -n "auto_$(date +\%Y\%m\%d)"

운영 로그를 보관하는 메시지 브로커로 Pulsar를 사용하는 경우, 특정 시점 복구 (point-in-time recovery)가 가능합니다.

결론: 구축을 시작하세요

Milvus 2.5는 수십억 규모의 워크로드(workloads)를 처리할 수 있는 가장 강력한 오픈 소스 (open-source) 벡터 데이터베이스입니다. 만약 귀하의 AI 애플리케이션이 수억 개, 혹은 수십억 개의 임베딩 (embeddings)을 밀리초 단위의 지연 시간 (latency)으로 검색해야 한다면, Milvus가 바로 프로덕션 등급 (production-grade)의 선택지입니다. Kubernetes 네이티브 (Kubernetes-native) 아키텍처는 기존 인프라 전문 지식을 갖춘 팀에게 이점을 제공하며, Zilliz Cloud는 그 외 모든 사용자에게 운영 부담이 없는 (zero-ops) 경로를 제공합니다.

다음 단계:

1. 로컬 환경에 단독 (standalone) Docker 버전을 배포하세요 (<5분).
2. 첫 100만 개의 벡터를 로드하고 벤치마크 (benchmark) 쿼리를 실행하세요.
3. 프로덕션 환경을 위해 Helm 기반의 Kubernetes 배포로 전환하세요.
4. 운영 오버헤드 (operational overhead)가 우려된다면 Zilliz Cloud를 고려하세요.

Milvus 배포 경험을 공유하고 동료 엔지니어들로부터 도움을 받으려면 저희 Telegram 커뮤니티에 참여하세요.

출처 및 추가 읽을거리