Amazon S3 Vectors는 벡터 데이터베이스를 죽일 것인가—아니면 구할 것인가?
얼마 전, AWS가 새로운 것을 내놓았습니다: S3 Vectors. 이는 Amazon S3 안에서 바로 시맨틱 검색을 위한 벡터 임베딩을 저장하고 쿼리할 수 있게 해주는, AWS의 첫 벡터 스토리지 솔루션 시도입니다.
한눈에 보기에는 저비용 객체 스토리지 위에서 실행되는 가벼운 벡터 데이터베이스처럼 보입니다—많은 전용 벡터 데이터베이스 솔루션과 비교했을 때 분명히 매력적인 가격대로 말이죠.
amazon s3 vectors.png
당연히, 이는 많은 뜨거운 반응을 불러일으켰습니다. 소셜 미디어와 엔지니어링 커뮤니티에서 이것이 Milvus, Pinecone, Qdrant 등을 포함한 목적 특화 벡터 데이터베이스의 종말이 될 수 있다고 말하는 사람들을 봤습니다. 대담한 주장이지 않나요?
Milvus의 엔지니어링 아키텍트이자 벡터 검색에 대해 너무 많은 밤을 새워 고민해 온 사람으로서, 저는 인정해야 합니다: S3 Vectors는 특히 비용과 AWS 생태계 내 통합 측면에서 흥미로운 무언가를 제시합니다. 하지만 벡터 데이터베이스를 “죽이는” 대신, 저는 이것이 생태계 안에서 보완적인 요소로 자리 잡을 것이라고 봅니다. 사실, 이것의 진짜 미래는 전문 벡터 데이터베이스를 대체하는 것이 아니라, 그것들과 함께 작동하는 데 있을 가능성이 큽니다.
이 글에서는 제가 왜 그렇게 생각하는지—기술 자체, 할 수 있는 것과 할 수 없는 것, 그리고 시장에 의미하는 바라는 세 가지 관점에서 살펴보겠습니다.
놀라운 사실: 벡터 스토리지는 LLM 호출보다 더 비쌀 수 있다
벡터 검색은 강력하지만, 심각한 함정이 있습니다: 비싸다는 것입니다. 컴퓨팅 요구량은 일반적인 NoSQL 데이터베이스에서 볼 수 있는 것보다 한두 자릿수 더 높은 경우가 많습니다. 그 격차는 단지 이론적인 것이 아니라—실제 청구서에 나타납니다.
최근 저는 한 인기 AI 노트 작성 앱의 CTO와 이야기를 나눴는데, 그는 놀라운 사실을 말해주었습니다: 그들은 OpenAI API 호출에 쓰는 비용보다 벡터 검색에 두 배 더 많은 비용을 지출한다고 합니다. 잠시 생각해 보세요. 검색 계층을 운영하는 비용이 LLM 자체에 지불하는 비용보다 더 많이 드는 것입니다. 이는 일반적인 가정을 완전히 뒤집습니다.
2022년 ChatGPT 붐은 이를 더욱 분명하게 만들었습니다. 갑자기 임베딩이 어디에나 있게 되었고, 벡터 데이터는 퍼블릭 클라우드에서 가장 빠르게 성장하는 데이터 유형이 되었습니다. Retrieval-Augmented Generation (RAG)가 그 동력이었고—그와 함께 Milvus 같은 벡터 데이터베이스가 해야 할 일을 재편한 세 가지 과제가 등장했습니다:
대규모 데이터 폭증: 워크로드가 거의 하룻밤 사이에 수천만 개 벡터에서 수백억 개 벡터로 뛰어올랐습니다. 이는 선형 성장이 아니라 양자 도약이며, 기존의 데이터 처리 방식을 무너뜨렸습니다.
지연 시간 허용 범위의 변화: 어차피 LLM이 응답을 생성하는 데 시간이 걸리기 때문에, 사용자들은 약간 느린 검색에 더 관대해졌습니다. “어떤 대가를 치르더라도 10ms 미만의 recall”이라는 사고방식은 갑자기 덜 중요해졌습니다.
비용 민감도 급상승: 데이터 볼륨이 두 배, 세 배로 늘어나는 것은 단순한 스토리지 문제가 아니었습니다; 전통적인 컴퓨팅 중심 설계로 확장하려 하면 재정적 위기가 되었습니다.
요컨대: 벡터 데이터베이스는 빠르게 진화해야 했습니다. 기술이 작동하지 않았기 때문이 아니라, 검색의 경제성이 갑자기 핵심 문제로 떠올랐기 때문입니다.
벡터 스토리지의 진화: 메모리에서 디스크로, 그리고 이제 객체 스토리지로
비용과 규모에 대한 압박은 하나의 결론을 강제했습니다: 벡터 데이터베이스는 영원히 메모리 전용으로 남을 수 없었습니다. 진화해야 했습니다—처음에는 디스크로, 그리고 이제는 S3 같은 객체 스토리지로 말입니다. 이는 선택이 아니라 업계의 필연이었습니다. 그리고 이 분야를 지켜봐 왔다면, 지난 몇 년 동안 저와 같은 흐름을 눈치챘을 것입니다.
저는 벡터 데이터베이스가 세 가지 뚜렷한 단계를 거치는 것을 봐왔습니다:
1단계(2018–2022): 순수 메모리 시대: Milvus 초기에는 HNSW와 IVF 같은 메모리 인덱스에 의존했습니다. 성능과 리콜은 훌륭했지만 비용은 혹독했습니다. 메모리는 저렴하게 확장되지 않으며, 클라우드 요금을 내는 모든 사람이 이를 알고 있었습니다.
2단계(2022–2024): 디스크 인덱스 혁명: 메모리 병목을 깨기 위해, 우리는 DiskANN과 독점 Cardinal 인덱스(Zilliz Cloud, 관리형 Milvus 전용)를 사용하는 디스크 기반 접근 방식을 개척했습니다. 비동기 I/O(AIO)와 io_uring 같은 기법으로 디스크에서 실제 성능을 끌어낼 수 있었습니다. 그 결과는? 3–5배의 비용 절감이었습니다. 용량 최적화 컴퓨트 유닛(CU)은 Zilliz Cloud에서 빠르게 베스트셀러가 되었습니다.
3단계(2024– ): 계층형 스토리지 시대: 다음 단계는 분명했습니다. 벡터 인덱스를 저렴한 객체 스토리지로 밀어 넣는 것이었습니다. TurboPuffer 같은 새로운 플레이어들은 S3에 올인하며 스토리지 비용을 ~$0.33/GB/month까지 낮췄습니다. 이는 10배 절감입니다. 하지만 트레이드오프도 그만큼 명확했습니다. 콜드 쿼리 지연 시간이 500ms–1s 범위이고, 리콜 정밀도는 더 약했습니다.
Zilliz에서는 한동안 계층형 스토리지에 대해 작업해 왔지만, 콜드 쿼리 성능을 제어할 수 있을 때까지 출시를 보류했습니다. 다음 달, Zilliz Cloud에서 진정한 핫/콜드 분리를 갖춘 업그레이드된 확장 용량 CU를 출시할 예정입니다. 이는 안정적인 500ms 미만의 콜드 쿼리 지연 시간과 핫 쿼리를 위한 초고 QPS가 결합됨을 의미합니다. 다시 말해, 두 세계의 장점을 모두 갖춘 것입니다.
Amazon S3 Vectors, 때맞춰 등장하다
계층형 스토리지가 이미 그 가치를 입증하고 있는 상황에서, AWS가 S3 Vectors로 뛰어든 것은 놀랄 일이 아닙니다. 사실 이번 출시는 업계 전반에서 이미 진행되고 있던 흐름의 자연스러운 확장처럼 느껴집니다. Amazon은 S3 Tables 같은 기능으로 S3의 역할을 확장하며, 이를 “단순한 객체 스토리지”에서 멀티모달 콜드 스토리지 백본으로 발전시켜 왔습니다. 벡터는 그 진화의 다음 모달리티일 뿐이며, 아마 거기서 멈추지 않을 것입니다. 그래프, 키-값, 시계열 데이터도 모두 같은 길을 따를 수 있습니다.
그리고 Amazon은 세 가지 부정할 수 없는 장점을 제공합니다:
더 낮은 비용: 업계 최저 수준의 스토리지 가격.
대규모 확장성: AWS의 머신 풀은 거의 어떤 쿼리 부하도 흡수할 수 있습니다.
마이크로서비스 네이티브 아키텍처: 벡터 인덱싱의 쓰기–빌드–쿼리 워크플로와 완벽하게 정렬됩니다.
이들을 종합하면, S3 Vectors는 벡터를 위한 초저비용, 고확장성 콜드 스토리지 솔루션이 될 자질을 갖추고 있습니다.
S3 Vectors는 진정한 가격 파괴자이지만, 명확한 한계가 있다
S3 Vectors가 발표되자마자, 우리 팀은 이를 포괄적으로 테스트했습니다. 결과는 놀라웠습니다. 단지 얼마나 저렴한지뿐 아니라, 어디에서 균열이 보이기 시작하는지도 드러났기 때문입니다.
S3 Vectors는 진정한 가격 파괴자다
부인할 수 없습니다. S3 Vectors는 놀라울 만큼 비용 효율적입니다.
스토리지는 단 $0.06/GB로 운영되며, 대부분의 서버리스 벡터 솔루션보다 대략 5배 저렴합니다. 대표적인 워크로드—예를 들어 월 4억 개의 벡터와 1,000만 건의 쿼리—의 경우, 청구액은 약 $1,217/month로 나옵니다. 이는 기존 벡터 데이터베이스와 비교해 10배 이상의 절감입니다. 낮은 QPS와 지연 시간에 관대한 워크로드에는 거의 이길 수 없는 수준입니다.
하지만 성능에는 실제 제약이 있다
컬렉션 크기 제한: 각 S3 테이블은 최대 5천만 개의 벡터까지만 지원하며, 최대 10,000개의 테이블만 생성할 수 있습니다.
콜드 쿼리: 지연 시간은 100만 개 벡터에서 약 500ms, 1천만 개 벡터에서 약 700ms입니다.
핫 쿼리: 지연 시간은 200 QPS에서 200ms 미만으로 유지되지만, 그 200 QPS 한계를 넘어서기는 어렵습니다.
쓰기 성능: 2MB/s 미만으로 제한됩니다. 이는 Milvus(GB/s를 처리)보다 몇 자릿수나 낮지만, 장점으로는 쓰기가 쿼리 성능을 저하시키지 않는다는 점입니다. 해석하자면, 대규모로 자주 변경되는 데이터셋이 있는 시나리오용으로 설계된 것은 아닙니다.
정밀도와 기능성의 트레이드오프
정밀도 측면은 상황이 복잡해지는 지점입니다. Recall은 85~90% 수준에 머물며, 이를 더 높게 조정할 수 있는 손잡이는 제공되지 않습니다. 여기에 필터를 더하면 recall은 50% 미만으로 떨어질 수 있습니다. 데이터의 50%를 삭제한 한 테스트에서는 TopK 쿼리가 20개의 결과를 요청했지만 15개만 반환할 수 있었습니다.
기능성도 간소화되어 있습니다. TopK 쿼리는 최대 30개로 제한됩니다. 레코드당 메타데이터에는 엄격한 크기 제한이 있습니다. 그리고 hybrid search, multi-tenancy, advanced filtering 같은 기능은 찾아볼 수 없습니다. 이들은 많은 프로덕션 애플리케이션에서 필수적인 기능입니다.
S3 Vectors 해부: 가능성 높은 아키텍처
테스트를 실행하고 이를 익숙한 AWS 설계 패턴과 대조해 본 결과, 우리는 S3 Vectors가 내부적으로 어떻게 작동하는지에 대해 꽤 그럴듯한 가설을 세웠습니다. Amazon이 전체 세부 사항을 공개하지는 않았지만, 성능 특성은 다섯 가지 핵심 기술을 가리킵니다:
SPFresh 동적 인덱싱: 각 쓰기 후 전체 인덱스를 다시 빌드하는 대신, S3 Vectors는 영향을 받는 부분만 업데이트하는 것으로 보입니다. 이 설계는 쓰기 비용을 낮게 유지하고 가용성을 높게 유지하지만, 대가가 따릅니다. 업데이트 후 recall 비율이 몇 퍼센트포인트 떨어집니다.
Deep Quantization(4-bit PQ): S3의 I/O 오버헤드를 줄이기 위해 임베딩은 4-bit product quantization을 사용해 압축되는 것으로 보입니다.
장점: 스토리지가 저렴하고 쿼리는 빠르게 유지됩니다.
단점: recall은 약 85% 수준에서 정체되며, 개발자가 이를 더 높게 조정할 수 있는 손잡이가 없습니다.
Post-Filter 메커니즘: 필터링은 대략적인 검색 후 적용되는 것으로 보입니다. 이렇게 하면 인덱스가 통합되고 단순하게 유지되지만, 복잡한 조건에는 어려움을 겪습니다. 테스트에서 데이터의 50%를 삭제했을 때, 20개의 결과를 요청한 TopK 쿼리는 15개만 반환했습니다. 이는 post-filter 파이프라인의 전형적인 징후입니다. 이는 또한 Amazon이 처음부터 맞춤형 인덱스를 구축하기보다는 기존 오픈 소스 인덱스 설계에 크게 의존했음을 시사합니다.
Multi-Tier Caching: 핫 쿼리는 훨씬 빠르게 동작하는데, 아마도 S3 앞단에 있는 SSD/NVMe 캐시 덕분일 가능성이 큽니다. 하지만 쿼리가 캐시를 놓치면 지연 시간이 크게 증가합니다. 이 패턴은 객체 스토리지의 본질적인 느림을 가리기 위해 구축된 multi-tier cache 계층 구조와 일치합니다.
대규모 분산 스케줄링: AWS에는 머신 풀이 부족하지 않습니다. S3 Vectors는 워크로드를 마이크로서비스 전반에 분산하고 read → decompress → search 흐름을 파이프라인화하는 것으로 보입니다. 그 결과는 테스트에서 관찰한 바와 같습니다. 높은 부하에서도 놀라울 만큼 안정적인 지연 시간 분포입니다.
S3 Vectors가 맞는 곳: 특정 작업에 적합한 도구
S3 Vectors를 철저히 테스트해 본 결과, 어떤 시나리오에서는 빛을 발하고 다른 시나리오에서는 한계가 분명하다는 점이 명확해졌습니다. 대부분의 인프라 도구와 마찬가지로, 만능 솔루션은 아닙니다. 적재적소에 쓰이는 도구입니다.
잘 작동하는 경우
콜드 데이터 아카이빙: 거의 접근되지 않는 히스토리 데이터셋을 저장하는 데 완벽합니다. 500ms 이상의 쿼리 시간을 감수할 수 있다면, 비용 절감 효과는 타의 추종을 불허합니다.
저QPS RAG 쿼리: 하루에 수십 건의 쿼리만 실행하고 100 QPS 미만을 유지하는 소규모 내부 도구나 챗봇을 떠올리면 됩니다. 이러한 사용 사례에서는 지연 시간이 결정적인 문제가 아닙니다.
저비용 프로토타이핑: 인프라에 많은 비용을 쓰지 않고 아이디어를 테스트하는 것이 목표인 개념 증명 프로젝트에 좋습니다.
어려움을 겪는 경우
고성능 검색 및 추천: 애플리케이션에 50ms 미만의 지연 시간이 필요하다면, S3 Vectors는 애초에 그 용도로 만들어진 것이 아닙니다.
대량 쓰기 또는 잦은 업데이트: 성능이 빠르게 저하되고, 많은 변동이 발생하면 recall 정밀도가 눈에 띄게 떨어집니다.
복잡한 쿼리 워크로드: 하이브리드 검색, 집계 또는 기타 고급 쿼리 기능을 지원하지 않습니다.
멀티테넌트 프로덕션 앱: 10,000개 버킷이라는 엄격한 상한이 있어, 대규모 멀티테넌트 배포를 위해 설계된 것이 아닙니다.
다시 말해, S3 Vectors는 콜드, 저비용, 저QPS 시나리오에는 탁월하지만, 추천 시스템, 실시간 검색 앱 또는 대규모 프로덕션 시스템을 구동하고 싶은 엔진은 아닙니다.
미래는 계층형 벡터 스토리지입니다
S3 Vectors는 벡터 데이터베이스의 종말을 의미하지 않습니다. 오히려 우리 중 많은 이들이 한동안 보아 온 사실을 확인해 줍니다. 미래는 계층형 스토리지라는 것입니다. 모든 벡터를 비싼 메모리나 빠른 디스크에 보관하는 대신, 워크로드는 접근 빈도와 애플리케이션이 허용할 수 있는 지연 시간의 종류에 따라 자연스럽게 핫, 웜, 콜드 계층으로 분산될 것입니다.
실제로는 다음과 같은 모습입니다:
핫 데이터 레이어(<50ms) – 실시간 검색, 추천, 타깃 광고가 여기에 해당합니다. 지연 시간은 50ms 미만이어야 하므로, 특화된 벡터 데이터베이스가 여전히 최선의 선택입니다. 이들은 눈부신 속도와 높은 쿼리 처리량 모두에 최적화되어 있습니다.
웜 데이터 레이어(50–500ms) – 많은 RAG 기반 애플리케이션과 멀티테넌트 공유 서비스가 여기에 속합니다. 이러한 워크로드는 초저지연을 필요로 하지는 않지만, 더 낮은 비용으로 예측 가능한 성능이 필요합니다. S3 Vectors와 Milvus의 계층형 스토리지 인스턴스가 이 중간 지대에 적합합니다.
콜드 데이터 레이어(>500ms) – 히스토리 아카이브와 오프라인 분석은 실시간 응답을 요구하지 않으므로, 수백 밀리초의 지연 시간도 허용됩니다. 여기서 중요한 것은 막대한 규모에서의 비용 효율성입니다. S3 + Spark/Daft 또는 Milvus 벡터 데이터 레이크와 같은 솔루션이 빛을 발하는 영역입니다.
핫–웜–콜드 분리는 지연 시간, 비용, 규모의 균형을 맞춰 주며, 어떤 단일 스토리지 계층도 혼자서는 이를 모두 커버할 수 없습니다. 이는 관계형 데이터베이스, 데이터 웨어하우스, 심지어 CDN에서도 이전에 보아 온 패턴이며, 이제 벡터 스토리지도 같은 궤적을 따르고 있습니다. 이 3계층 아키텍처는 우리가 Milvus와 Zilliz Cloud를 위해 구축해 온 로드맵과도 긴밀하게 맞아떨어집니다.
1. 통합 온라인 + 오프라인 처리 아키텍처
AI 애플리케이션은 “온라인”과 “오프라인”이라는 별개의 세계에 깔끔하게 나뉘어 존재하지 않습니다. 실제로 데이터는 두 영역 사이를 끊임없이 이동합니다. 그래서 곧 출시될 Milvus 3.0,에서는 동일한 데이터셋에서 실시간 검색과 오프라인 처리를 모두 지원하도록 설계된 벡터 데이터 레이크를 도입할 예정입니다.
실제로 이는 하나의 데이터셋이 라이브 RAG와 검색 쿼리를 구동하는 동시에, Spark 기반 오프라인 분석에도 공급될 수 있음을 의미합니다. 예를 들어 LLM을 위한 학습 데이터를 큐레이션하는 경우가 그렇습니다. 중복도 없고, 서로 다른 두 파이프라인을 번갈아 다룰 필요도 없습니다.
또한 벡터 데이터 레이크를 위한 StorageV2 format도 출시할 예정이며, 이는 경제성을 한 단계 더 끌어올립니다:
콜드 데이터 스토리지 비용을 최대 100배 더 저렴하게.
핫 데이터에서 brute-force Spark 쿼리보다 최대 100배 더 빠르게.
그 결과 중복을 최소화하고, 비용을 통제하며, 벡터 데이터 작업을 훨씬 덜 고통스럽게 만드는 통합 시스템이 됩니다.
2. AI 개발자에게 실제로 필요한 기능 구축
지난 2년 동안 AI 애플리케이션은 빠르게 발전해 왔고, 그 뒤를 받치는 인프라에 대한 요구사항도 마찬가지로 빠르게 변화해 왔습니다. Zilliz에서는 이러한 요구에 발맞춰 Milvus를 발전시켜 왔으며, BM25 + 벡터 하이브리드 검색, 멀티테넌트 격리, 핫–콜드 계층형 스토리지, MinHash 중복 제거 같은 기능과 더불어 개발자 중심의 긴 개선 사항 목록을 제공해 왔습니다.
우리의 철학은 단순했습니다. 비즈니스 사용 사례에 대한 깊은 이해와 최신 기술을 결합하면 완전히 새로운 인프라 가능성을 열 수 있다는 것입니다. 바로 이러한 사고방식이 Milvus 3.0을 형성하고 있으며, Milvus 3.0은 실제 애플리케이션을 위해 직접 설계된 새로운 AI 네이티브 기능의 물결을 가져올 것입니다. 그중에는 다음이 포함됩니다.
검색에서 키워드 가중치 적용 – “red phone” 같은 쿼리에서 red를 적절히 우선순위에 둘 수 있도록 합니다.
지리적 위치 지원 – “find nearby coffee shops.” 같은 프롬프트를 처리하기 위해 위치 인식 벡터를 저장하고 쿼리합니다.
RAG를 위한 멀티벡터 지원 – 각 텍스트에 여러 임베딩을 연결하여 복잡한 검색 작업에서 재현율과 정확도를 향상합니다.
유연한 UDF 처리 – 더 풍부하고 사용자 지정 가능한 데이터 처리를 위한 사용자 정의 함수입니다.
시각적 분석 도구 – 대규모에서 더 깊이 있는 오프라인 마이닝과 데이터 탐색을 제공합니다.
그리고 이것은 시작에 불과합니다. 더 중요한 점은 Milvus가 효율적이고 확장 가능한 시스템일 뿐만 아니라, 그 핵심부터 AI 네이티브인 시스템으로 진화하고 있다는 것입니다. 즉, 현대 애플리케이션이 실제로 작동하는 방식에 맞게 목적에 맞춰 구축된 시스템입니다.
3. 비용 부담 없이 규모를 위한 엔지니어링
Zilliz에서 우리는 이렇게 믿습니다. 10배의 비용 절감은 100배 더 많은 애플리케이션 사용 사례의 문을 엽니다. 이 원칙은 Milvus의 모든 중요한 이정표를 이끌어 왔습니다. 2022년 이후 우리는 디스크 기반 인덱스, GPU 가속, RabitQ 양자화를 도입했으며, 이 모두는 비용을 낮추는 동시에 쿼리 성능을 몇 자릿수나 끌어올렸습니다.
앞으로 우리의 초점은 스택에서 훨씬 더 많은 효율성을 끌어내는 데 있습니다.
더 깊은 하드웨어 최적화 – 원시 컴퓨팅 파워와 IOPS 성능에 맞춰 튜닝합니다.
더 스마트한 압축 및 양자화 – 정확도를 포기하지 않고 벡터를 더 가볍게 만듭니다.
인덱스 쿼리를 위한 조기 종료 – 확신할 수 있는 결과를 얻는 즉시 낭비되는 연산을 중단합니다.
정교해진 계층형 인덱싱 – 콜드 데이터에 더 빠르게 접근할 수 있도록 캐시 활용도를 개선합니다.
최종 목표는 변하지 않았습니다. 바로 즉시 사용할 수 있고, 수요에 따라 확장되며, 빠르면서도 경제적인 인프라를 구축하는 것입니다.
S3 Vectors의 등장이 모두에게 좋은 소식인 이유
많은 사람들이 S3 Vectors가 기존 벡터 데이터베이스를 쓸모없게 만들 것이라고 걱정합니다. 제 생각은 정반대입니다. S3 Vectors의 출시는 전체 업계에 좋은 소식입니다. 사실 저는 세 가지 큰 이점이 있다고 봅니다.
수요를 검증합니다. 이제 아무도 벡터가 단순한 유행일 뿐이라고 주장할 수 없습니다. AWS가 이를 중심으로 제품을 만들고 있다면, 그것은 벡터 스토리지가 실제로 필요한 것이라는 확실한 증거입니다. 단순히 “데이터베이스로 감싼 인덱스”가 아닙니다.
시장을 교육합니다. AWS의 영향력으로 더 많은 기업이 이제 벡터 데이터베이스를 인식하게 되었고, 이는 어떤 애플리케이션을 구축할 수 있는지의 경계를 확장합니다.
혁신을 촉진합니다. 경쟁은 Milvus를 포함한 우리 모두가 더 강하게 최적화하고, 비용을 더 낮추며, 차별화된 강점을 찾도록 밀어붙입니다.
포지셔닝 관점에서 보면, S3 Vectors는 완전한 벡터 데이터베이스라기보다 벡터 스토리지의 콜드 티어에 더 가까워 보입니다. 낮은 비용 덕분에 이전에는 비용 때문에 접근하기 어려웠던 시나리오, 즉 RAG 앱을 구축하는 소규모 팀, 실험하는 개인 개발자, 또는 기본적인 검색 요구만 있는 방대한 데이터셋을 인덱싱하는 조직에 특히 매력적입니다. 이는 생태계에 실질적인 잠금 해제를 가져옵니다.
개인적으로는 AWS 엔지니어링 팀도 인정하고 싶습니다. 그들은 Lambda 디버깅부터 콜드 스타트 성능에 이르기까지 플랫폼을 꾸준히 개선해 왔으며, S3 Vectors는 신중한 제품 혁신의 또 다른 사례입니다. 경제성이 이렇게 유리해진 지금 개발자들이 무엇을 만들지 진심으로 궁금합니다.
그러니 벡터 데이터베이스 시장은 붕괴되고 있는 것이 아니라, 다양한 솔루션이 서로 다른 성능 및 비용 요구를 충족하는 계층형 생태계로 성숙해 가고 있습니다. 이는 기업에도 좋고, 개발자에게도 좋으며, 전체 AI 인프라 스택에도 좋습니다.
벡터 데이터베이스의 황금기는 끝난 것이 아니라 이제 막 시작되고 있습니다.
계속 읽기
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
Creating Collections in Zilliz Cloud Just Got Way Easier
We've enhanced the entire collection creation experience to bring advanced capabilities directly into the interface, making it faster and easier to build production-ready schemas without switching tools.