왜 저는 Claude Code의 Grep 전용 검색에 반대할까요? 토큰을 너무 많이 태워버리기 때문입니다
AI 코딩 어시스턴트가 폭발적으로 성장하고 있습니다. 불과 지난 2년 사이에 Cursor, Claude Code, Gemini CLI, Qwen Code 같은 도구들은 신기한 존재에서 수백만 개발자들의 일상적인 동반자로 자리 잡았습니다. 하지만 이 빠른 성장 뒤에는 겉보기엔 단순해 보이는 문제를 둘러싼 싸움이 무르익고 있습니다: AI 코딩 어시스턴트는 실제로 컨텍스트를 찾기 위해 여러분의 코드베이스를 어떻게 검색해야 할까요?
현재 두 가지 접근 방식이 있습니다:
벡터 검색 기반 RAG(시맨틱 검색).
grep을 이용한 키워드 검색(문자열 리터럴 매칭).
Claude Code와 Gemini는 후자를 선택했습니다. 실제로 한 Claude 엔지니어는 Hacker News에서 Claude Code가 RAG를 전혀 사용하지 않는다고 공개적으로 인정했습니다. 대신 저장소를 한 줄씩 grep으로 훑을 뿐입니다(그들이 “에이전트식 검색”이라고 부르는 방식)—의미론도, 구조도 없이, 그저 원시 문자열 매칭입니다.
그 폭로는 커뮤니티를 갈라놓았습니다:
지지자들은 grep의 단순성을 옹호합니다. 빠르고, 정확하며, 무엇보다도 예측 가능합니다. 그들은 프로그래밍에서는 정밀도가 전부이며, 오늘날의 임베딩은 아직 신뢰하기엔 너무 모호하다고 주장합니다.
비판자들은 grep을 막다른 길로 봅니다. 관련 없는 매칭 결과에 파묻히게 만들고, 토큰을 낭비하며, 워크플로를 멈춰 세웁니다. 의미론적 이해 없이는 AI에게 눈을 가리고 디버깅하라고 요청하는 것과 같습니다.
양쪽 모두 일리가 있습니다. 그리고 제가 직접 솔루션을 만들고 테스트해 본 뒤 이렇게 말할 수 있습니다: 벡터 검색 기반 RAG 접근 방식은 판도를 바꿉니다. 검색을 훨씬 더 빠르고 정확하게 만들 뿐만 아니라, 토큰 사용량도 40% 이상 줄여줍니다. (제 접근 방식은 Claude Context 부분으로 건너뛰세요)
그렇다면 왜 grep은 그렇게 제한적일까요? 그리고 벡터 검색은 실제로 어떻게 더 나은 결과를 제공할 수 있을까요? 하나씩 살펴보겠습니다.
Claude Code의 Grep 전용 코드 검색에는 무엇이 문제인가?
저는 까다로운 문제를 디버깅하던 중 이 문제에 부딪혔습니다. Claude Code는 제 저장소 전체에 grep 쿼리를 날리며, 관련 없는 거대한 텍스트 덩어리를 제게 쏟아냈습니다. 1분이 지났는데도 여전히 관련 파일을 찾지 못했습니다. 5분 뒤에야 마침내 필요한 10줄을 찾았지만—그것들은 500줄의 잡음 속에 묻혀 있었습니다.
이건 예외적인 사례가 아닙니다. Claude Code의 GitHub 이슈를 훑어보면 같은 벽에 부딪힌 좌절한 개발자들이 많이 보입니다:
issue1: https://github.com/anthropics/claude-code/issues/1315
issue2: https://github.com/anthropics/claude-code/issues/4556
커뮤니티의 불만은 세 가지 고충으로 요약됩니다:
토큰 팽창. grep 덤프가 매번 엄청난 양의 관련 없는 코드를 LLM에 밀어 넣어, 저장소 규모가 커질수록 감당하기 어려운 비용을 끌어올립니다.
시간 비용. AI가 여러분의 코드베이스를 상대로 스무고개를 하는 동안 기다려야 하며, 집중과 흐름이 깨집니다.
컨텍스트 제로. Grep은 문자열 리터럴을 매칭합니다. 의미나 관계에 대한 감각이 없기 때문에, 사실상 눈을 감고 검색하는 셈입니다.
그래서 이 논쟁이 중요합니다: grep은 그저 “올드스쿨”인 것이 아니라, AI 보조 프로그래밍을 적극적으로 가로막고 있습니다.
Claude Code vs Cursor: 왜 후자가 더 나은 코드 컨텍스트를 가지는가
코드 컨텍스트에 관해서라면 Cursor가 더 잘해 왔습니다. 처음부터 Cursor는 코드베이스 인덱싱에 집중했습니다: 저장소를 의미 있는 청크로 나누고, 그 청크들을 벡터로 임베딩한 다음, AI가 컨텍스트를 필요로 할 때마다 의미론적으로 검색합니다. 이는 코드에 적용된 교과서적인 검색 증강 생성(Retrieval-Augmented Generation, RAG)이며, 결과는 이를 입증합니다: 더 촘촘한 컨텍스트, 더 적은 토큰 낭비, 더 빠른 검색.
Claude Code는 이와 대조적으로 단순함에 더욱 집중해 왔습니다. 인덱스도, 임베딩도 없고—그저 grep뿐입니다. 이는 모든 검색이 구조나 의미에 대한 이해 없이 리터럴 문자열 매칭으로만 이루어진다는 뜻입니다. 이론적으로는 빠르지만, 실제로 개발자들은 자신에게 정말 필요한 바늘 하나를 찾기 전에 관련 없는 매치라는 건초더미를 뒤지는 경우가 많습니다.
| Claude Code | Cursor | |
|---|---|---|
| Search Accuracy | 정확히 일치하는 항목만 보여줌—다르게 명명된 것은 놓칩니다. | 키워드가 정확히 일치하지 않아도 의미적으로 관련 있는 코드를 찾습니다. |
| Efficiency | Grep이 방대한 코드 덩어리를 모델에 쏟아부어 토큰 비용을 증가시킵니다. | 더 작고 신호가 높은 청크로 토큰 부하를 30–40% 줄입니다. |
| Scalability | 매번 repo를 다시 grep하므로 프로젝트가 커질수록 느려집니다. | 한 번 인덱싱한 뒤 최소한의 지연으로 규모에 맞게 검색합니다. |
| Philosophy | 최소한으로 유지—추가 인프라 없음. | 모든 것을 인덱싱하고, 지능적으로 검색합니다. |
그렇다면 왜 Claude(또는 Gemini나 Cline)는 Cursor의 선례를 따르지 않았을까요? 그 이유는 부분적으로는 기술적이고, 부분적으로는 문화적입니다. 벡터 검색은 사소하지 않습니다—청킹, 증분 업데이트, 대규모 인덱싱을 해결해야 합니다. 하지만 더 중요한 것은 Claude Code가 미니멀리즘을 중심으로 만들어졌다는 점입니다: 서버도, 인덱스도 없이, 깔끔한 CLI만 있습니다. 임베딩과 벡터 DB는 그런 설계 철학에 맞지 않습니다.
그 단순함은 매력적입니다—하지만 Claude Code가 제공할 수 있는 한계도 정해 버립니다. Cursor가 실제 인덱싱 인프라에 기꺼이 투자했기 때문에 오늘날 더 강력하게 느껴지는 것입니다.
Claude Context: Claude Code에 의미 기반 코드 검색을 추가하기 위한 오픈소스 프로젝트
Claude Code는 강력한 도구이지만—코드 컨텍스트는 부족합니다. Cursor는 코드베이스 인덱싱으로 이 문제를 해결했지만, Cursor는 비공개 소스이고, 구독 뒤에 잠겨 있으며, 개인이나 소규모 팀에게는 비쌉니다.
그 격차 때문에 우리는 자체 오픈소스 솔루션을 만들기 시작했습니다: Claude Context.
Claude Context는 Claude Code(및 MCP를 사용하는 다른 모든 AI 코딩 에이전트)에 의미 기반 코드 검색을 제공하는 오픈소스 MCP 플러그인입니다. grep으로 repo를 무차별 검색하는 대신, 벡터 데이터베이스와 임베딩 모델을 통합해 LLM에 전체 코드베이스에서 가져온 깊고, 목표 지향적인 컨텍스트를 제공합니다. 그 결과: 더 예리한 검색, 더 적은 토큰 낭비, 훨씬 더 나은 개발자 경험을 얻을 수 있습니다.
우리는 이렇게 만들었습니다:
우리가 사용하는 기술
🔌 인터페이스 레이어: 범용 커넥터로서의 MCP
우리는 이것이 Claude뿐만 아니라 어디서나 작동하길 원했습니다. MCP(Model Context Protocol)는 LLM을 위한 USB 표준처럼 작동하여, 외부 도구가 원활하게 연결되도록 합니다. Claude Context를 MCP 서버로 패키징함으로써, Claude Code뿐만 아니라 Gemini CLI, Qwen Code, Cline, 심지어 Cursor에서도 작동합니다.
🗄️ 벡터 데이터베이스: Zilliz Cloud
백본으로는 Zilliz Cloud(Milvus 기반의 완전 관리형 서비스)를 선택했습니다. 고성능, 클라우드 네이티브, 탄력적이며 코드베이스 인덱싱 같은 AI 워크로드를 위해 설계되었습니다. 이는 낮은 지연 시간의 검색, 거의 무한한 확장성, 그리고 견고한 신뢰성을 의미합니다.
🧩 임베딩 모델: 유연성을 염두에 둔 설계팀마다 필요한 것이 다르기 때문에, Claude Context는 기본적으로 여러 임베딩 제공자를 지원합니다:
OpenAI embeddings 안정성과 폭넓은 채택을 위해.
Voyage embeddings 코드 특화 성능을 위해.
Ollama 프라이버시 우선의 로컬 배포를 위해.
요구사항이 발전함에 따라 추가 모델을 끼워 넣을 수 있습니다.
💻 언어 선택: TypeScript
우리는 Python과 TypeScript를 두고 논의했습니다. TypeScript가 선택되었습니다. 애플리케이션 수준의 호환성(VSCode 플러그인, 웹 툴링) 때문만이 아니라, Claude Code와 Gemini CLI 자체가 TypeScript 기반이기 때문이기도 합니다. 덕분에 통합이 매끄럽고 생태계의 일관성이 유지됩니다.
시스템 아키텍처
Claude Context는 깔끔한 계층형 설계를 따릅니다:
핵심 모듈은 코드 파싱, 청킹, 인덱싱, 검색, 동기화 같은 무거운 작업을 처리합니다.
사용자 인터페이스는 MCP 서버, VSCode 플러그인 또는 기타 어댑터와 같은 통합을 처리합니다.
이러한 분리는 핵심 엔진을 다양한 환경에서 재사용할 수 있게 하면서, 새로운 AI 코딩 어시스턴트가 등장함에 따라 통합 기능이 빠르게 발전할 수 있도록 합니다.
핵심 모듈 구현
핵심 모듈은 전체 시스템의 기반을 이룹니다. 이들은 벡터 데이터베이스, 임베딩 모델 및 기타 구성 요소를 조합 가능한 모듈로 추상화하여 Context 객체를 생성하고, 다양한 시나리오에 맞게 서로 다른 벡터 데이터베이스와 임베딩 모델을 사용할 수 있게 합니다.
import { Context, MilvusVectorDatabase, OpenAIEmbedding } from '@zilliz/claude-context-core';
// Initialize embedding provider
const embedding = new OpenAIEmbedding(...);
// Initialize vector database
const vectorDatabase = new MilvusVectorDatabase(...);
// Create context instance
const context = new Context({embedding, vectorDatabase});
// Index your codebase with progress tracking
const stats = await context.indexCodebase('./your-project');
// Perform semantic search
const results = await context.semanticSearch('./your-project', 'vector database operations');
주요 기술적 과제 해결
Claude Context를 구축하는 일은 단순히 임베딩과 벡터 DB를 연결하는 것만이 아니었습니다. 실제 작업은 대규모 코드 인덱싱의 성패를 좌우하는 어려운 문제들을 해결하는 데 있었습니다. 우리가 세 가지 가장 큰 과제에 접근한 방식은 다음과 같습니다:
과제 1: 지능형 코드 청킹
코드는 단순히 줄이나 문자 단위로 나눌 수 없습니다. 그렇게 하면 지저분하고 불완전한 조각이 생기고, 코드를 이해 가능하게 만드는 논리가 사라집니다.
우리는 이를 두 가지 상호 보완적인 전략으로 해결했습니다:
AST 기반 청킹(기본 전략)
이는 기본 접근 방식으로, tree-sitter 파서를 사용해 코드 구문 구조를 이해하고 의미적 경계, 즉 함수, 클래스, 메서드를 기준으로 분할합니다. 이를 통해 다음을 제공합니다:
구문적 완전성 – 잘려 나간 함수나 깨진 선언이 없습니다.
논리적 일관성 – 관련 로직이 함께 유지되어 더 나은 의미 기반 검색이 가능합니다.
다중 언어 지원 – tree-sitter 문법을 통해 JS, Python, Java, Go 등 여러 언어에서 작동합니다.
LangChain 텍스트 분할(대체 전략)
AST가 파싱할 수 없는 언어이거나 파싱에 실패한 경우, LangChain의 RecursiveCharacterTextSplitter가 신뢰할 수 있는 백업을 제공합니다.
// Use recursive character splitting to maintain code structure
const splitter = RecursiveCharacterTextSplitter.fromLanguage(language, {
chunkSize: 1000,
chunkOverlap: 200,
});
AST만큼 “지능적”이지는 않지만 매우 신뢰할 수 있어, 개발자가 난감한 상황에 놓이지 않도록 보장합니다. 이 두 전략을 함께 사용하면 의미적 풍부함과 보편적 적용 가능성 사이의 균형을 이룰 수 있습니다.
과제 2: 코드 변경 사항을 효율적으로 처리하기
코드 변경 사항 관리는 코드 인덱싱 시스템에서 가장 큰 과제 중 하나입니다. 사소한 파일 수정 때문에 전체 프로젝트를 다시 인덱싱하는 것은 완전히 비현실적입니다.
이 문제를 해결하기 위해 우리는 Merkle Tree 기반 동기화 메커니즘을 구축했습니다.
Merkle Tree: 변경 감지의 기반
Merkle Tree는 계층적 “지문” 시스템을 생성합니다. 각 파일은 자체 해시 지문을 가지고, 폴더는 그 내용에 기반한 지문을 가지며, 모든 것은 전체 코드베이스에 대한 고유한 루트 노드 지문으로 귀결됩니다.
파일 내용이 변경되면 해시 지문이 각 계층을 통해 루트 노드까지 위로 연쇄적으로 전파됩니다. 이를 통해 루트에서 아래로 계층별로 해시 지문을 비교하여 빠른 변경 감지가 가능해지며, 전체 프로젝트 재인덱싱 없이도 파일 수정 사항을 신속하게 식별하고 위치를 특정할 수 있습니다.
시스템은 간소화된 3단계 프로세스를 사용하여 5분마다 핸드셰이크 동기화 검사를 수행합니다:
Phase 1: 초고속 감지는 전체 코드베이스의 Merkle 루트 해시를 계산하고 이를 이전 스냅샷과 비교합니다. 루트 해시가 동일하면 변경 사항이 없다는 의미이며, 시스템은 모든 처리를 밀리초 단위로 건너뜁니다.
Phase 2: 정밀 비교는 루트 해시가 다를 때 트리거되며, 정확히 어떤 파일이 추가, 삭제 또는 수정되었는지 식별하기 위해 상세한 파일 수준 분석을 수행합니다.
Phase 3: 증분 업데이트는 변경된 파일에 대해서만 벡터를 재계산하고 그에 따라 벡터 데이터베이스를 업데이트하여 효율성을 극대화합니다.
로컬 스냅샷 관리
모든 동기화 상태는 사용자의 ~/.context/merkle/ 디렉터리에 로컬로 유지됩니다. 각 코드베이스는 파일 해시 테이블과 직렬화된 Merkle 트리 데이터를 포함하는 자체 독립 스냅샷 파일을 유지하여, 프로그램 재시작 후에도 정확한 상태 복구를 보장합니다.
이 설계는 명확한 이점을 제공합니다: 변경 사항이 없을 때 대부분의 검사는 밀리초 단위로 완료되고, 실제로 수정된 파일만 재처리를 트리거하며(막대한 계산 낭비 방지), 프로그램 세션 간에도 상태 복구가 완벽하게 작동합니다.
사용자 경험 관점에서, 단일 함수를 수정하면 전체 프로젝트가 아니라 해당 파일에 대해서만 재인덱싱이 트리거되어 개발 효율성이 크게 향상됩니다.
Challenge 3: MCP 인터페이스 설계
가장 똑똑한 인덱싱 엔진도 깔끔한 개발자 대상 인터페이스가 없다면 쓸모가 없습니다. MCP는 명백한 선택이었지만, 고유한 과제를 가져왔습니다:
🔹 도구 설계: 단순하게 유지하기
MCP 모듈은 사용자 대면 인터페이스 역할을 하므로, 사용자 경험이 최우선입니다.
도구 설계는 표준 코드베이스 인덱싱 및 검색 작업을 두 가지 핵심 도구로 추상화하는 것에서 시작합니다: 코드베이스 인덱싱을 위한 index_codebase와 코드 검색을 위한 search_code.
이는 중요한 질문을 제기합니다: 어떤 추가 도구가 필요할까요?
도구 수는 신중한 균형이 필요합니다. 도구가 너무 많으면 인지적 부담이 생기고 LLM의 도구 선택이 혼란스러워지는 반면, 너무 적으면 필수 기능을 놓칠 수 있습니다.
실제 사용 사례에서 거꾸로 추론하면 이 질문에 답하는 데 도움이 됩니다.
백그라운드 처리 과제 해결
대규모 코드베이스는 인덱싱에 상당한 시간이 걸릴 수 있습니다. 완료될 때까지 동기적으로 기다리는 순진한 접근 방식은 사용자가 몇 분 동안 기다리게 만들며, 이는 결코 받아들일 수 없습니다. 비동기 백그라운드 처리가 필수적이지만, MCP는 이 패턴을 기본적으로 지원하지 않습니다.
8.png
우리 MCP 서버는 MCP 서버 내부에서 백그라운드 프로세스를 실행하여 인덱싱을 처리하는 동시에 사용자에게 시작 메시지를 즉시 반환함으로써, 사용자가 계속 작업할 수 있게 합니다.
9.png
이는 새로운 과제를 만듭니다: 사용자는 인덱싱 진행 상황을 어떻게 추적할까요?
인덱싱 진행 상황이나 상태를 조회하기 위한 전용 도구가 이를 우아하게 해결합니다. 백그라운드 인덱싱 프로세스는 진행 정보를 비동기적으로 캐시하여, 사용자가 언제든지 완료율, 성공 상태 또는 실패 조건을 확인할 수 있게 합니다. 또한 수동 인덱스 삭제 도구는 사용자가 부정확한 인덱스를 재설정하거나 인덱싱 프로세스를 다시 시작해야 하는 상황을 처리합니다.
최종 도구 설계:
index_codebase - 코드베이스 인덱싱
search_code - 코드 검색
get_indexing_status - 인덱싱 상태 조회
clear_index - 인덱스 삭제
단순성과 기능성 사이에서 완벽한 균형을 이루는 네 가지 도구입니다.
🔹 환경 변수 관리
환경 변수 관리는 사용자 경험에 상당한 영향을 미치는데도 종종 간과됩니다. 모든 MCP Client마다 별도의 API 키 구성을 요구하면 사용자가 Claude Code와 Gemini CLI 사이를 전환할 때 자격 증명을 여러 번 구성해야 합니다.
전역 구성 접근 방식은 사용자의 홈 디렉터리에 ~/.context/.env 파일을 생성하여 이러한 마찰을 제거합니다:
# ~/.context/.env
OPENAI_API_KEY=your-api-key-here
MILVUS_TOKEN=your-milvus-token
이 접근 방식은 명확한 이점을 제공합니다: 사용자는 한 번만 구성하면 모든 MCP 클라이언트에서 어디서나 사용할 수 있고, 모든 구성이 유지 관리를 쉽게 할 수 있도록 단일 위치에 중앙화되며, 민감한 API 키가 여러 구성 파일에 흩어지지 않습니다.
또한 3단계 우선순위 계층을 구현합니다: 프로세스 환경 변수가 가장 높은 우선순위를 가지며, 전역 구성 파일은 중간 우선순위를 가지고, 기본값은 폴백으로 사용됩니다.
이 설계는 엄청난 유연성을 제공합니다: 개발자는 임시 테스트 오버라이드에 환경 변수를 사용할 수 있고, 프로덕션 환경은 보안을 강화하기 위해 시스템 환경 변수를 통해 민감한 구성을 주입할 수 있으며, 사용자는 한 번만 구성하면 Claude Code, Gemini CLI 및 기타 도구 전반에서 원활하게 작업할 수 있습니다.
이 시점에서 MCP 서버의 핵심 아키텍처는 코드 파싱과 벡터 저장부터 지능형 검색 및 구성 관리에 이르기까지 완성되었습니다. 모든 구성 요소는 강력하면서도 사용자 친화적인 시스템을 만들기 위해 신중하게 설계되고 최적화되었습니다.
실전 테스트
그렇다면 Claude Context는 실제로 얼마나 잘 작동할까요? 저는 처음에 저를 좌절시켰던 바로 그 버그 찾기 시나리오로 테스트해 보았습니다.
Claude Code를 실행하기 전 설치는 단 한 줄의 명령이면 충분했습니다:
claude mcp add claude-context -e OPENAI_API_KEY=your-openai-api-key -e MILVUS_TOKEN=your-zilliz-cloud-api-key -- npx @zilliz/claude-context-mcp@latest
코드베이스가 인덱싱되자, 저는 이전에 Claude Code가 5분 동안 grep에 의존한 헛수고를 하게 만들었던 것과 같은 버그 설명을 제공했습니다. 이번에는 claude-context MCP 호출을 통해 즉시 정확한 파일과 줄 번호를 찾아냈고, 문제에 대한 설명까지 함께 제공했습니다.
그 차이는 미묘한 수준이 아니었습니다—그야말로 천지 차이였습니다.
그리고 버그 찾기에만 그치지 않았습니다. Claude Context가 통합되자 Claude Code는 다음 전반에서 일관되게 더 높은 품질의 결과를 만들어냈습니다:
이슈 해결
코드 리팩터링
중복 코드 감지
포괄적인 테스트
성능 향상은 수치에서도 드러납니다. 나란히 비교한 테스트에서:
토큰 사용량은 리콜 손실 없이 40% 이상 감소했습니다.
이는 곧바로 더 낮은 API 비용과 더 빠른 응답으로 이어집니다.
또는 동일한 예산으로 Claude Context는 훨씬 더 정확한 검색 결과를 제공했습니다.
저희는 GitHub에 Claude Context를 오픈소스로 공개했으며, 이미 2.6K+개의 스타를 받았습니다. 여러분의 지원과 좋아요에 감사드립니다.
직접 사용해 보실 수 있습니다:
자세한 벤치마크와 테스트 방법론은 리포지토리에서 확인할 수 있습니다—여러분의 피드백을 기다립니다.
앞으로의 방향
Claude Code에서 grep에 느꼈던 좌절감에서 시작된 것이 이제는 견고한 솔루션으로 성장했습니다: Claude Context—Claude Code와 기타 코딩 어시스턴트에 시맨틱한 벡터 기반 검색을 제공하는 오픈소스 MCP 플러그인입니다. 메시지는 간단합니다: 개발자는 비효율적인 AI 도구에 만족할 필요가 없습니다. RAG와 벡터 검색을 활용하면 더 빠르게 디버깅하고, 토큰 비용을 40% 절감하며, 마침내 코드베이스를 진정으로 이해하는 AI 지원을 받을 수 있습니다.
그리고 이는 Claude Code에만 국한되지 않습니다. Claude Context는 개방형 표준을 기반으로 구축되었기 때문에, 동일한 접근 방식이 Gemini CLI, Qwen Code, Cursor, Cline 등에서도 원활하게 작동합니다. 더 이상 성능보다 단순성을 우선시하는 벤더의 트레이드오프에 얽매일 필요가 없습니다.
여러분이 그 미래의 일부가 되어 주시길 바랍니다:
Claude Context를 사용해 보세요: 오픈소스이며 완전히 무료입니다
개발에 기여하세요
또는 직접 솔루션을 구축하세요 Claude Context를 사용하여
👉 피드백을 공유하거나, 질문하거나, 도움을 받으려면 Discord 커뮤니티에 참여하세요.
계속 읽기
3 Easiest Ways to Use Claude Code on Your Mobile Phone
Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.
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).
Why AI Databases Don't Need SQL
Whether you like it or not, here's the truth: SQL is destined for decline in the era of AI.