Milvus는 어떤 RAG 상황에서 실제로 이득을 보는가?

결론부터 쓰면, Milvus는 데이터 규모가 작고 구조가 단순한 RAG에서는 이점이 잘 드러나지 않고, 데이터가 수백만~수십억 건으로 커지거나 필터링·하이브리드 검색이 섞일 때 강점이 눈에 보이는 벡터DB다. 공개된 사례에서 Read AI는 수십억 건 규모의 기록을 다루면서도 20~50ms대 retrieval latency를 유지했다고 밝혔다 Milvus 사용 사례. 반대로 문서 수가 몇 만 건대인 프로토타입이라면 이 정도 규모의 최적화가 체감되기 어렵다.

  • Milvus는 대규모·하이브리드 검색 RAG에서 이득이 커지는 구조다.
  • 소규모 프로토타입에는 설정 복잡도만 추가될 수 있다.
  • 실측 오버헤드는 20~40ms 수준으로 임베딩 API 호출 시간보다 작다.
  • 인덱스 종류(HNSW/IVF/DiskANN 등)가 많은 만큼 선택과 튜닝 책임도 따라온다.
  • 버전업(예: Milvus 3.0 예고)에 따라 수치 해석이 달라질 수 있다.

흔히 빠지는 함정은 이거다. "Milvus가 대규모에서 빠르다더라"는 문장만 보고 문서 1만 건짜리 사내 챗봇 RAG에 클러스터형 Milvus를 바로 얹는 경우다. 이런 규모에서는 단일 인스턴스형 벡터DB로도 충분한 경우가 많고, Milvus의 인덱스 선택·클러스터 구성 옵션은 오히려 초기 설정 시간만 늘린다. 운영 인력이 없는 팀이라면 "규모가 커지면 이득이 커진다"는 전제 자체를 먼저 자기 프로젝트에 대입해보는 게 먼저다.

대규모 데이터셋에서 Milvus의 지연시간과 QPS는 실제로 얼마나 나오나?

수치로 보면 Milvus는 규모가 커질수록 지연시간이 극단적으로 나빠지지 않는 편이지만, QPS를 올리면 p99 지연이 눈에 띄게 벌어진다. 2026년 7월 공개된 벤치마크에서 Milvus v2.6.0 기준 단일 프로세스 피크 QPS는 930, 32개 프로세스 기준 피크 QPS는 5063까지 올라갔고, 이때 피크 p99는 202ms였다 벤치마크 기사. 반대로 p99를 100ms 이하로 묶는 예산을 잡으면 QPS는 4725 수준까지 떨어졌다. 즉 "최대 QPS"와 "안정적인 지연시간을 유지하는 QPS"는 다른 숫자라는 점을 구분해서 봐야 한다.

Milvus 공식 벤치마크 문서인 VDBBench 1.0은 합성 벡터가 아니라 Wikipedia 1M/10M, BioASQ 1M/10M, C4 500K/5M, MSMarco V2 1M/10M/138M 같은 실사용 코퍼스를 기준으로 설계됐다 VDBBench 문서. 이는 일반 지식 기반, 바이오메디컬, 웹 규모 텍스트, 대규모 검색이라는 서로 다른 RAG 용도별 비교에 바로 인용할 수 있는 조건이라는 점에서 유용하지만, 자신의 실제 데이터 분포(문서 길이, 중복도, 임베딩 차원)와 얼마나 비슷한지는 별도로 확인해야 한다. 벤치마크 코퍼스와 자기 서비스의 데이터가 다르면 같은 QPS·지연 수치가 그대로 재현되지 않는다.

임베딩 단계와 Milvus 자체 오버헤드, 뭐가 진짜 병목인가?

실측상 병목은 Milvus 자체보다 임베딩 생성 단계인 경우가 많다. 2025년 5월 공개 테스트에서 20개 이상의 임베딩 API를 Milvus와 함께 측정했을 때, Milvus 쪽 오버헤드는 총 20~40ms에 그쳤지만 임베딩 API 호출 자체는 수백 ms에서 수 초까지 걸렸다 Milvus 임베딩 벤치마크. 전체 작업 시간 대비 Milvus가 차지하는 비중은 5% 미만으로 나타났다는 점에서, "검색이 느리다"는 불만이 실제로는 임베딩 모델 선택이나 API 지연 때문인 경우가 적지 않다.

같은 테스트에서 TextEmbedding Function을 사용했을 때도 Milvus가 추가하는 지연은 미미하다고 정리됐다. 실무적으로는 RAG 파이프라인이 느리다고 느껴질 때 벡터DB 교체부터 검토하기보다, 임베딩 모델 호출 구간(배치 크기, 동시 요청 수, 모델 자체의 응답 시간)을 먼저 측정하는 순서가 비용 대비 효율적이다. 벡터DB를 바꾸는 작업은 인덱스 재구축·마이그레이션 비용이 따르지만, 임베딩 호출 방식 개선은 상대적으로 되돌리기 쉽다.

인덱스 종류가 많다는 게 장점일까 관리 부담일까?

둘 다 맞다. Milvus는 HNSW, IVF, DiskANN을 포함해 10종 이상의 인덱스 타입을 지원한다고 소개되며, 이는 정확도·지연·메모리 사용량 사이에서 용도별로 조정할 여지를 준다는 뜻이다 AWS Marketplace 소개. 최근에는 CAGRA와 Vamana를 결합해 인덱스는 GPU로 빌드하고 질의는 CPU로 처리하는 하이브리드 모드도 소개됐는데, 이 방식이 배포 비용 절감에 도움이 된다는 설명이 붙어 있다 Milvus 3.0 관련 공지.

문제는 선택지가 많을수록 "어떤 인덱스를 쓸지"를 결정하는 작업 자체가 실무 비용이 된다는 점이다. HNSW는 빠른 근사 검색에 유리하지만 메모리 사용량이 크고, IVF는 메모리 효율이 좋은 대신 파라미터 튜닝이 필요하며, DiskANN은 디스크 기반이라 대용량에는 맞지만 지연 특성이 다르다. GPU 하이브리드 모드도 GPU 자원이 이미 있는 팀에는 비용 절감이지만, GPU가 없는 팀이 이걸 위해 인프라를 새로 들이면 오히려 비용이 늘어난다. "인덱스가 다양하다"는 문장은 장점이면서 동시에 "누군가 튜닝을 담당해야 한다"는 숨은 비용이기도 하다.

Milvus를 쓰면 자동으로 검색이 빨라진다는 말, 맞을까?

정확히는 아니다. 앞서 본 20~50ms대 검색 사례, 5~10배 워크플로우 개선 같은 수치는 특정 사용 사례(대규모 문서·이벤트, 에이전트 검색)에서 나온 결과이지, Milvus를 도입하는 것만으로 자동 적용되는 성능이 아니다 Milvus 요약 자료. Read AI 사례에서 강조된 것도 지연시간 자체보다 에이전트 검색 워크플로우 속도가 5배 개선됐다는 점인데, 이는 검색 latency 하나만이 아니라 파이프라인 전체 구조(캐싱, 재시도 로직, 병렬 호출)가 함께 최적화된 결과로 읽는 게 맞다.

또 하나 자주 생기는 오해는 "Milvus 성능 수치가 모든 인덱스·모든 하드웨어에서 동일하게 나온다"는 가정이다. 벤치마크 수치(QPS 930~5063, p99 202ms 등)는 특정 버전(v2.6.0)과 특정 프로세스 수 조건에서 나온 값이고, 인덱스 타입과 하드웨어 구성을 바꾸면 그대로 재현되지 않는다. Milvus 3.0(Lake-Native Vector Search)이 예고되어 있다는 점도 감안하면, 지금 인용하는 수치가 다음 버전에서도 유지된다고 단정하기는 이르다.

실제 운영 비용과 설정 부담은 어느 정도로 봐야 하나?

비용은 두 갈래로 봐야 한다. 하나는 인프라 비용, 다른 하나는 운영·튜닝 인력 비용이다. AWS Marketplace에 노출된 예시 인스턴스 비용은 t3.medium·t3.large·m5.large·r5.large가 시간당 0.01달러 수준, t3.micro는 사실상 0에 가까운 수준으로 표시되어 있어 소규모 테스트 자체의 진입 비용은 크지 않다 AWS Marketplace 가격. 단일 노드에서 초당 최대 300만 벡터 수집이 가능하다는 수치도 함께 제시되는데, 이는 ingest 성능 상한이지 실제 서비스에서 지속 가능한 처리량과는 다르다는 점을 구분해야 한다.

더 큰 비용은 클러스터 구성, 인덱스 선택, 벤치마크 재현 작업에 들어가는 시간이다. 표로 정리하면 아래와 같다.

항목 소규모 RAG 대규모 RAG
인프라 비용 낮음 (단일 노드, 시간당 0.01달러대 인스턴스로 시작 가능) 클러스터 구성 시 증가
튜닝 부담 낮음 (기본 인덱스로 충분한 경우 많음) 인덱스·프로세스 수 조정 필요
체감 이득 크지 않음 지연시간·QPS 개선이 뚜렷

2026년 기준으로 보면, Milvus를 도입하기 전에 "우리 데이터 규모가 벤치마크 조건(수백만~수십억 건)에 가까운가", "필터링·하이브리드 검색이 실제로 필요한가"를 먼저 점검하는 게 비용 대비 합리적인 순서다.

핵심 정리

  • Milvus는 대규모·하이브리드 RAG에서 20~50ms대 검색, 5~10배 워크플로우 개선 사례가 확인되지만 소규모 RAG에서는 이득이 뚜렷하지 않다.
  • 벤치마크상 Milvus 자체 오버헤드는 20~40ms로 낮고, 병목은 대체로 임베딩 API 호출(수백 ms~수 초) 쪽에 있다.
  • QPS를 올릴수록 p99 지연이 벌어지므로(예: 5063 QPS에서 p99 202ms), "최대 QPS"와 "안정적 QPS"를 구분해서 봐야 한다.
  • HNSW/IVF/DiskANN 등 10종 이상의 인덱스와 GPU 하이브리드 모드는 유연성이자 동시에 튜닝 인력 비용이다.
  • 인프라 진입 비용(시간당 0.01달러대 인스턴스)은 낮지만, 실제 비용은 운영·설정 인력에서 발생한다.