Zilliz가 GTC 2026에서 NVIDIA의 비정형 데이터 이야기의 중심에 서게 된 이유
올해 NVIDIA GTC에서, 칩, 시스템, 인프라에 대한 평소와 같은 주장의 홍수 속에서 Jensen Huang은 다른 이유로 중요한 슬라이드를 띄웠습니다.
그것은 다음 GPU에 관한 것이 아니었습니다. 모델 크기에 관한 것도 아니었습니다. 사실 추론에 관한 것도 아니었습니다.
그것은 데이터에 관한 것이었습니다.
한 슬라이드는 구조화 데이터의 세계를 그려냈습니다: Spark, Presto, DuckDB, Polars, Snowflake, Databricks, BigQuery, 수십 년 동안 분석과 데이터 엔지니어링을 구동해 온 익숙한 장치들입니다.
또 다른 슬라이드는 비정형 데이터를 위한 새롭게 부상하는 스택을 그려냈습니다. 그리고 그 두 번째 그림의 한가운데에는 오픈 소스의 Milvus와 엔터프라이즈 데이터베이스 계층의 Zilliz Cloud가 자리하고 있었습니다.
슬라이드의 제목이 모든 것을 말해 주었습니다: 비정형 데이터는 AI의 컨텍스트입니다.
그 문장에는 쉽게 고개를 끄덕이게 됩니다. 물론 AI에는 컨텍스트가 필요합니다. 물론 대부분의 엔터프라이즈 데이터는 비정형입니다. 물론 텍스트, 이미지, 비디오, 오디오, 로그, PDF, 그리고 그 밖의 모든 것이 이제 그 어느 때보다 중요합니다. 하지만 슬로건을 지나고 나면 더 어려운 질문이 나타납니다: 비정형 데이터가 AI 시스템의 진정한 기반이 되어 가고 있다면, 그 세계를 위한 인프라는 실제로 어떤 모습이어야 할까요?
그것이 더 흥미로운 이야기입니다. 그리고 Milvus가 전문화된 벡터 데이터베이스에서 AI 스택에서 훨씬 더 전략적인 위치로 이동한 이유이기도 합니다.
Zilliz(Milvus)가 계속 등장하는 이유
Zilliz가 GTC에 등장한 것은 이번이 처음이 아니었고, 아마 마지막도 아닐 것입니다.
벡터 데이터베이스가 현대 AI 시스템의 기본 구성 요소가 되기 오래전부터, Milvus는 유사도 검색이 전통적인 데이터베이스와는 매우 다른 규모에서 작동해야 한다는 생각을 중심으로 구축되었습니다. GPU 가속은 나중에 덧붙인 것이 아니었습니다. 처음부터 설계 논리의 일부였습니다.
AI가 연구의 이야기를 넘어 인프라의 이야기가 되었을 때, 그것은 중요해졌습니다.
GTC 2023에서 Jensen Huang은 이미 NVIDIA의 가속 라이브러리와 FAISS, Redis, Milvus 같은 시스템 간의 더 깊은 통합을 언급하고 있었습니다. 1년 뒤 GTC 2024에서, 그 관계는 Milvus 2.4와 함께 더 구체화되었고, NVIDIA GPU와 RAPIDS cuVS의 CAGRA를 결합해 벡터 인덱싱과 검색에 완전한 GPU 가속을 도입했습니다. 그 결과는 겉보기식 속도 향상이 아니었습니다. 일부 벤치마크 환경에서는 검색 성능이 HNSW 대비 최대 50배 향상되었습니다.
Milvus 2.6이 등장했을 때쯤, 논의는 다시 진화했습니다. 질문은 더 이상 GPU 가속이 중요한지 여부가 아니었습니다. 그것을 어떻게 비용 효율적으로 사용할 것인가였습니다. Milvus 2.6은 GPU를 그래프 구축에 사용하고 CPU를 검색에 사용하는 하이브리드 GPU-CPU 아키텍처를 포함해, CAGRA를 위한 더 유연한 배포 패턴을 도입했습니다. 이것이 중요한 이유는 대부분의 엔터프라이즈가 어떤 비용을 치르더라도 가능한 한 가장 빠른 시스템을 원하는 것이 아니기 때문입니다. 그들은 경제적으로 합리적인 상태를 유지하면서 충분히 빠른 시스템을 원합니다.
이 세부 사항은 잠시 멈춰 볼 가치가 있습니다. Milvus가 왜 중요해졌는지에 대해 더 큰 무언가를 말해 주기 때문입니다. 이것은 단지 벡터 검색 성능에 관한 이야기가 아닙니다. 벡터 검색이 실험적 기능을 멈추고 프로덕션 인프라의 일부가 될 때 무슨 일이 일어나는지에 관한 이야기입니다.
프로덕션에서 벡터 검색이 작동하게 하려면 필요한 것
속도만으로는 더 이상 이야기가 되지 않습니다.
하지만 벡터 검색이 데모를 벗어나 실제 시스템으로 들어가는 순간, 속도만으로는 더 이상 이야기가 되지 않습니다.
더 어려운 질문은 취약한 파이프라인, 높은 메모리 압박, 증가하는 인프라 비용으로 주변 스택을 엉망으로 만들지 않으면서, 엔터프라이즈 규모에서 검색을 실용적으로 만들려면 무엇이 필요한가입니다.
그 과제의 일부는 업스트림에서 시작됩니다. 기존 모델에서는 PDF, 이미지 또는 문서를 검색 가능한 형태로 바꾸려면 보통 별도의 파싱 계층, 청킹 로직, 임베딩 서비스, 데이터베이스 쓰기를 서로 이어 붙여야 했습니다. 검색 시스템은 긴 전처리 체인이 이미 작업을 완료한 뒤에야 작동하기 시작했습니다. Milvus 2.6은 Data-in, Data-out 접근 방식을 통해 그 경계를 허물기 시작했으며, 원본 콘텐츠를 시스템에 직접 쓰고 데이터베이스 내부에서 임베딩할 수 있게 했습니다.
그 일부는 검색 계층 내부에 있습니다. 서로 다른 워크로드에는 서로 다른 트레이드오프가 필요하므로, 모든 사용 사례에 단일 검색 전략을 강요하기보다 여러 인덱스 유형을 지원해야 합니다. 압축도 이 방정식의 일부가 됩니다. Int8 및 RaBitQ와 같은 기능은 화려한 추가 기능은 아니지만, 더 중요한 목표를 다룹니다. 즉, 검색 품질을 희생하지 않으면서 메모리 압박과 비용을 줄이는 것입니다.
그리고 그 일부는 단순히 운영의 문제입니다. Milvus는 Kafka와 Pulsar를 스택에서 제거할 수 있는 재설계된 write-ahead logging 아키텍처를 도입해 복잡성과 오버헤드를 모두 줄였습니다. 그런 종류의 엔지니어링은 좀처럼 헤드라인을 장식하지 않지만, 인프라가 이론상으로만 흥미로운 상태에 머무를지 실제로 사용할 수 있는 상태가 될지를 결정하는 것은 바로 그런 엔지니어링입니다.
스토리지는 또 다른 단층선으로 드러납니다.
AI 시스템이 성장함에 따라, 모든 데이터를 항상 같은 방식으로 다뤄야 한다고 가장하는 비용도 커집니다. 대규모 멀티테넌트 플랫폼에서는 특정한 날에 실제로 활성 상태인 데이터가 아주 일부에 불과할 수 있습니다. 대부분은 콜드 상태로 남아 있습니다. 그러나 전통적인 전체 로드 아키텍처는 여전히 모든 것이 동일한 로컬 상주성, 동일한 성능 자세, 동일한 비용 발자국을 가져야 하는 것처럼 취급합니다.
소규모에서는 그것이 비효율적으로 보입니다. 엔터프라이즈 규모에서는 정당화하기 어려워집니다.
Milvus 2.6은 계층형 스토리지로 이를 해결했습니다. 핫 데이터는 지연 시간이 중요한 로컬에 유지됩니다. 콜드 데이터는 더 저렴한 객체 스토리지에서 온디맨드로 로드됩니다. 그리고 둘 사이의 경계는 시스템이 실제로 사용되는 방식에 따라 동적으로 이동합니다. 이는 소박한 시스템 최적화처럼 들립니다. 실제로는 검색의 경제성을 바꿉니다. 적절한 데이터가 적절한 계층에 있을 때, 스토리지 비용은 70% 이상 줄어들 수 있습니다.
이 중 특별히 화려한 것은 없습니다. 하지만 인프라가 성숙하는 방식은 보통 그렇습니다. 단 하나의 극적인 돌파구가 아니라, 시스템을 더 빠르고, 더 저렴하며, 함께 운용하기 더 쉽게 만드는 일련의 설계 결정들을 통해서입니다.
그리고 이 모든 기능은 Milvus의 완전 관리형 서비스인 Zilliz Cloud에서 제공되어 왔습니다.
비정형 데이터의 진짜 문제
하지만 더 큰 변화는 사실 Milvus만의 문제가 아닙니다. 이는 오늘날 AI 시스템이 의존하는 데이터의 종류에 관한 문제입니다.
정형 데이터는 길고 질서 있는 방식으로 발전했습니다. 행, 열, 스키마, 인덱스, 웨어하우스, 쿼리 엔진. 도구는 수십 년에 걸쳐 성숙했는데, 이는 데이터 자체가 그러한 시스템이 구축된 가정에 부합했기 때문입니다. 레코드가 어떻게 생겼는지 알고 있었습니다. 어떤 필드를 쿼리해야 하는지 알고 있었습니다. 그것들을 어떻게 인덱싱해야 하는지도 알고 있었습니다.
비정형 데이터는 그 모델을 깨뜨립니다.
계약서는 행이 아니다. 의료 이미지, 지원 상담 기록, 코드 저장소, 감시 피드도 마찬가지다. 이러한 객체들은 저장될 수 있지만, 저장은 쉬운 부분이다. 어려운 부분은 정확한 필드 일치가 아니라 의미를 이해하는 방식으로 검색 가능하게 만드는 것이다.
이것이 임베딩이 모든 것을 바꾼 이유다. 텍스트, 이미지, 오디오 및 기타 형태의 콘텐츠가 고차원 벡터 공간에 매핑될 수 있게 되자, 검색은 더 이상 정확한 기호적 매칭에 의존할 필요가 없었다. 시스템은 유사성, 의도, 맥락을 기준으로 검색할 수 있게 되었다.
그것이 돌파구였다.
동시에 그것은 새로운 인프라 문제의 시작이기도 했다.
비정형 데이터가 쿼리 가능해지는 순간, 기업은 곧바로 규모의 경제 문제에 직면한다. 수백만 개의 문서는 수억 개의 임베딩이 된다. 모델 업그레이드는 과거 코퍼스를 다시 임베딩해야 한다는 뜻이다. 검색 품질은 인덱스 품질에 달려 있다. 프로덕션에서는 지연 시간이 중요하다. 스토리지 비용도 중요하다. 이 모든 것을 동기화 상태로 유지하는 운영 부담도 중요하다.
다시 말해, 의미 기반 검색은 접근 문제를 해결했지만, 시스템 문제를 드러냈다.
이것이 Milvus가 의미를 갖는 맥락이다.
벡터 데이터베이스만으로는 충분하지 않았던 이유
AI-native 기업의 첫 번째 물결에서 답은 명확했다. 벡터 데이터베이스를 검색 계층으로 사용하고, 이를 모델에 연결한 다음, 그 위에서 애플리케이션을 구축하는 것이었다. 그 모델은 작동했고, 지금도 작동한다. 특히 의미 기반 검색이 제품의 핵심일 때 그렇다.
하지만 대기업은 다른 벽에 부딪히는 경우가 많다.
문제는 벡터 검색을 작동하게 만들 수 있느냐가 아니다. 문제는 그 이후에 무슨 일이 일어나느냐이다.
원본 파일은 오브젝트 스토리지나 데이터 레이크에 있다. 임베딩은 벡터 데이터베이스에 있다. 메타데이터는 관계형 시스템에 있다. 오프라인 처리는 다른 곳에서 일어난다. 검색 로그는 또 다른 파이프라인에 쌓인다. 그러다 임베딩 모델이 바뀌거나, 랭킹 로직이 바뀌거나, 지식 베이스에 큐레이션이 필요해지거나, 누군가 검색 시스템이 엣지 케이스에서 계속 실패하는 이유를 추적하고 싶어 한다. 갑자기 시스템은 더 이상 하나의 시스템이 아니다. 그것은 짜깁기된 구조가 된다.
그 짜깁기 구조는 익숙한 세 가지 문제를 만들어낸다.
- 첫 번째는 데이터 사일로다. 하나의 AI 기능을 실행하는 데 필요한 데이터가 여러 시스템에 흩어져 있으며, 각 시스템은 고유한 형식, 수명주기, 운영 모델을 갖고 있다.
- 두 번째는 반복 비용이다. 임베딩 모델이 바뀌면, 재작성은 기본적으로 점진적이지 않다. 수개월에 걸친 재인덱싱 및 마이그레이션 작업이 될 수 있다.
- 세 번째는 온라인 서빙과 오프라인 개선 사이의 끊어진 루프다. 시스템은 프로덕션에서 쿼리를 처리하지만, 이를 더 좋게 만들 수 있는 신호들, 즉 중복 제거 결과, 클러스터링 라벨, 품질 점수, 실패 분석은 종종 별도의 환경에 존재하며 검색 계층으로 깔끔하게 되돌아오지 못한다.
바로 이 지점에서 벡터 데이터베이스를 구매하는 것은 답처럼 느껴지기를 멈추고, 더 큰 아키텍처 질문의 시작처럼 느껴지기 시작한다.
진짜 문제가 규모 있는 지속적 개선이라면, 아키텍처는 바뀌어야 한다.
벡터 데이터베이스에서 AI Lakebase로
AI 붐 이전에 Databricks는 데이터 레이크와 데이터 웨어하우스 사이의 어색한 분리를 무너뜨리며 Lakehouse 모델을 대중화하는 데 기여했다. 스토리지, 분석, 대규모 처리를 위해 별도의 시스템을 유지하는 대신, 기업은 더 통합된 기반에서 작업할 수 있었다.
AI 시대는 비슷한 재고를 강요하고 있지만, 그 대상은 비정형 데이터다.
Jensen Huang이 사용해 온 인프라 다이어그램을 자세히 보면, 무게중심이 이동하고 있다. 정형 데이터 시대에는 Spark 같은 프레임워크가 파이프라인의 중심에 있었다. 비정형 데이터 시대에는 Milvus 같은 벡터 인프라가 그 역할을 채우기 시작하고 있다. 벡터 검색만이 중요한 유일한 것이어서가 아니라, 그것이 점점 원시 데이터, 임베딩, 인덱스, 애플리케이션 검색 사이의 접점에 자리 잡고 있기 때문이다.
이는 더 큰 가능성을 열어줍니다. 벡터 검색을 스택 한쪽에 덧붙인 별도의 서빙 계층으로 취급하지 않는다면 어떨까요? 엔터프라이즈 데이터 레이크 및 주변 데이터 워크플로와 직접 통합된다면 어떨까요?
AI Lakebase 아키텍처
그것이 바로 AI Lakebase의 아이디어입니다.
AI Lakebase의 핵심은 이미 혼잡한 시장에 또 하나의 제품 카테고리를 추가하는 것이 아닙니다. 핵심은 파편화된 패턴을 더 일관된 패턴으로 대체하는 것입니다.
- 맨 아래에는 통합 스토리지 계층이 있습니다. 그 데이터 중 일부는 고성능 벡터 검색에 최적화된 Zilliz 네이티브 컬렉션에 존재합니다. 일부는 엔터프라이즈가 이미 사용하고 있는 오픈 포맷, Iceberg, Lance, Paimon, 그리고 객체 스토리지의 원시 파일로 남아 있습니다. 중요한 점은 데이터를 사용 가능하게 만들기 위해 다섯 개의 서로 다른 시스템으로 복사할 필요가 없다는 것입니다.
- 그 위에는 실시간 검색을 위해 구축된 프로덕션 서빙 계층이 있습니다. Zilliz Cloud에서는 밀리초 수준의 지연 시간에 최적화된 Cardinal 기반 서빙 클러스터를 의미하며, 성능, 용량, 계층형 핫-콜드 데이터 배치를 위한 다양한 모드를 갖습니다. 실제로 이는 자주 액세스되는 데이터는 로컬에 유지되고 콜드 데이터는 더 저렴한 스토리지에서 필요할 때 로드된다는 뜻입니다. 그 결과는 단지 더 나은 시스템 설계가 아닙니다. 비용 통제입니다.
- 그다음에는 탄력적 컴퓨트 계층이 있습니다: ETL, 중복 제거, 클러스터링, 데이터 품질 분석, 재임베딩, 평가, 대화형 조사를 위한 온디맨드 클러스터입니다. 이것들은 나중에 덧붙인 보조 시스템이 아닙니다. 같은 기반의 일부입니다.
세 계층 모두 여러 개의 단절된 복사본을 유지하는 대신 동일한 데이터를 공유합니다.
이는 아키텍처 정리 이야기처럼 들리고, 실제로 그렇습니다. 하지만 그 이상입니다.
하지만 더 중요한 점은 그 아키텍처가 무엇을 가능하게 하느냐입니다.
AI Lakebase는 단순한 아키텍처 정리 그 이상입니다
오늘날 대부분의 AI 시스템은 서빙할 수 있습니다. 체계적으로 개선할 수 있는 시스템은 훨씬 적습니다.
그 이유는 보통 모델이 틀렸기 때문이 아닙니다. 그 주변 인프라가 피드백을 비싸게 만들기 때문입니다.
프로덕션 시스템은 끊임없이 신호를 생성합니다. 모든 쿼리는 무언가를 알려줍니다. 모든 실패한 검색은 무언가를 알려줍니다. 모든 저품질 답변, 모든 반복 결과, 모든 막다른 상호작용, 유사 문서의 모든 클러스터, 코퍼스의 모든 노이즈가 많은 청크, 이 모두는 시스템을 개선하는 데 사용할 수 있는 정보입니다.
하지만 대부분의 스택에서 이러한 신호는 서빙 로그, 오프라인 파이프라인, 노트북, 대시보드, 일회성 스크립트 전반에 흩어져 있습니다. 시스템은 실행되지만, 자기 경험으로부터 실제로 학습하지는 않습니다.
이를 해결하기 위한 AI Lakebase의 프레이밍은 Continuous Serving/Continuous Discovery (AI CS/CD)입니다.
- Continuous Serving은 명확한 부분입니다: 라이브 시스템이 프로덕션에서 검색과 생성을 처리합니다.
- Continuous Discovery 는 덜 명확한 부분입니다: 시스템이 축적한 것, 즉 커버리지 격차, 실패 모드, 클러스터 구조, 데이터 품질 문제를 지속적으로 분석하고, 그 결과로 나온 개선 사항을 동일한 운영 환경에 다시 반영합니다.
이것이 중요한 이유는 서빙과 디스커버리가 동일한 데이터 기반을 공유하게 되면, 개선이 마이그레이션처럼 보이지 않고 반복처럼 보이기 시작하기 때문입니다. 중복 제거 결과는 라이브 검색으로 다시 흘러갈 수 있습니다. 품질 점수는 프로덕션 랭킹에 영향을 줄 수 있습니다. 클러스터 라벨은 검색 신호가 될 수 있습니다. 재임베딩은 거대한 일괄 이벤트가 아니라 탄력적 컴퓨트를 통해 점진적으로 일어날 수 있습니다.
아키텍처는 정적인 데이터베이스라기보다 살아 있는 개선 루프처럼 동작하기 시작합니다.
이는 “벡터 데이터베이스, 하지만 더 빠른” 것보다 훨씬 더 중대한 변화입니다.
AI Lakebase로 빠르게 확장하고 빠르게 반복하기
많은 인프라 기업이 규모를 주장할 수 있습니다. 많은 기업이 속도를 주장할 수 있습니다. 같은 시스템 안에서 규모와 지속적인 반복을 둘 다 그럴듯하게 주장할 수 있는 곳은 더 적습니다.
Zilliz는 엔터프라이즈 AI 인프라의 다음 단계에는 두 가지가 모두 필요하다고 주장합니다.
- Scale Fast 는 벤치마크 실행이나 데모 환경에 그치지 않고, 매우 큰 규모의 프로덕션 워크로드를 지원할 수 있는 멀티 리전, 멀티 클라우드 인프라를 의미합니다.
- Iterate Fast 는 오프라인 발견과 온라인 서빙이 동일한 운영 루프의 일부가 되도록 시스템이 설계되었음을 의미합니다. 개선은 덧붙이는 것이 아니라 내장되어 있습니다.
이 구분이 중요한 이유는 프로덕션 AI가 서로 반대되는 두 가지 방식으로 실패하기 때문입니다. 어떤 시스템은 확장되지만 정체됩니다. 규모가 커지고 비용이 많이 들며, 개선하기가 점점 더 어려워집니다. 또 다른 시스템은 작은 환경에서는 빠르게 반복하지만, 결코 견고한 프로덕션 시스템이 되지 못합니다. 진짜 목표는 둘 중 어느 것도 아닙니다. 동시에 성장하고 학습할 수 있는 시스템입니다.
이것이 바로 벡터 데이터베이스에서 AI Lakebase로의 전환 뒤에 있는 약속입니다.
그 전환에서 벡터 데이터베이스가 사라지는 것은 아닙니다. 여전히 중요합니다. 여전히 실시간 검색을 위한 서빙 엔진입니다. 하지만 아키텍처의 종착점이 되는 것을 멈춥니다. Lakehouse 세계에서도 관계형 데이터베이스가 여전히 존재하지만 전체 아키텍처를 스스로 정의하지는 않는 것처럼, 더 넓은 시스템의 한 계층이 됩니다.
그리고 이것이 GTC에서 나온 Jensen Huang의 말을 읽는 가장 유용한 방식일 수 있습니다.
비정형 데이터가 AI의 컨텍스트라면, AI 애플리케이션의 한계는 모델뿐만 아니라 비정형 데이터를 위한 인프라가 얼마나 성숙해지는지에 의해 결정될 것입니다.
그 인프라는 아직 완성되지 않았습니다. 시장도 아직 초기 단계입니다. 하지만 윤곽이 보이기 시작하고 있습니다.
그리고 점점 더 Milvus가 그 한가운데에 자리하고 있습니다.
계속 지켜봐 주세요!
AI Lakebase는 Milvus 3.0의 기반이 되는 아키텍처 업그레이드이자 Zilliz Cloud의 주요 진화가 될 것입니다. 이것이 어디로 향하고 있는지 미리 살펴보고 싶다면, 얼리 액세스를 위해 문의해 주세요.
계속 읽기
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Migrating from S3 Vectors to Zilliz Cloud: Unlocking the Power of Tiered Storage
Learn how Zilliz Cloud bridges cost and performance with tiered storage and enterprise-grade features, and how to migrate data from AWS S3 Vectors to Zilliz Cloud.