배경 및 맥락
지난 1년간 많은 팀이 enterprise search와 RAG를 빠르게 붙였지만, 실제 운영 단계에서 가장 큰 문제는 모델이 아니라 검색 인프라였다. ingestion 파이프라인, 인덱스 스키마, retriever 조합, relevance evaluation이 각기 다른 도구와 인터페이스에 흩어져 있어, 팀은 검색 품질 개선보다 plumbing 유지에 더 많은 시간을 쓰곤 했다.
agent 시스템이 늘어나면서 이 문제는 더 심각해졌다. agent는 자율적으로 retrieval을 반복 호출하므로, 검색 품질이 낮으면 잘못된 context가 전체 workflow를 연쇄적으로 오염시킨다. 그래서 search stack은 부가 기능이 아니라 agent reliability의 핵심 계층이 됐다.
핵심 내용
Mistral 발표에 따르면 Search Toolkit은 public preview 상태의 오픈소스 프레임워크로, ingestion, retrieval, evaluation을 하나의 공통 인터페이스로 제공한다. BM25 sparse retrieval, dense embedding retrieval, hybrid 구성을 지원하고, recall, precision, MRR, NDCG 같은 평가 지표를 내장해 retriever 품질을 generation과 분리해 측정할 수 있게 했다.
또한 enterprise 검색과 agent use case를 분리하지 않고 함께 다룬다. 검색이 필요한 대규모 corpus는 indexed semantic search로 처리하고, 최신 상태가 필요한 CRM, code repository, productivity tool 등은 MCP 기반 connector로 live data를 가져오는 구조를 제안한다. 즉 agent가 indexed corpus와 source-of-truth system을 언제 각각 호출해야 하는지 설계 패턴을 제품 수준에서 제시한 셈이다.
경쟁 구도 / 비교
기존 RAG 도구 다수는 벡터 검색이나 chunking 편의성에 집중했지만, Search Toolkit은 retrieval evaluation을 동등한 1급 구성요소로 올려놓았다는 점이 다르다. 이는 search infra 경쟁이 단순 embedding accuracy에서, 실제 도메인 데이터셋 위에서 얼마나 반복적으로 측정하고 개선할 수 있는가로 옮겨가고 있음을 보여준다.
또한 live connector와 indexed search를 나란히 둔 설계는 많은 agent 플랫폼이 아직 명확히 풀지 못한 문제를 정면으로 다룬다. 이는 검색이 더 이상 RAG 보조 모듈이 아니라 agent platform architecture의 중심부로 들어오고 있음을 시사한다.
의미
실무적으로는 enterprise agent를 만드는 팀이 prompt나 model routing보다 retrieval evaluation 체계를 먼저 가져가야 한다는 메시지가 강하다. search relevance를 별도로 측정하지 않으면, 모델을 바꾸고 프롬프트를 손대도 문제의 원인이 retrieval인지 generation인지 끝내 분리되지 않는다.
산업적으로는 open-source search infra가 agent 시대의 control plane 역할을 차지하려는 움직임으로 볼 수 있다. 앞으로 agent 성능 경쟁은 어떤 모델을 쓰는가 못지않게, 어떤 검색 파이프라인을 얼마나 측정 가능하게 운영하는가에서 갈릴 가능성이 높다.