검색은 파이프라인이 아니라 에이전트가 되었다 — Agentic Search 완전 해부 (RAG 특집 1편)

들어가며 — 8만 9천 쪽에서 열두 개의 숫자를 찾는 일

크게 보기

여기 질문이 하나 있다.

"1953년에 보고된 월별 값만 사용해서, 미국 국방비 지출의 연간 합계(백만 달러)를 구하라."

답은 미국 재무부가 매달 발행한 회보(Treasury Bulletin) 어딘가에 있다. 문제는 그 회보가 696권, 약 8만 9천 쪽이고, 전부 스캔된 PDF이며, 표가 페이지의 대부분을 차지한다는 것이다. 그리고 각 회보는 발행 시점까지의 몇 달치만 싣는다. 1953년 12개월이 한 표에 정리된 페이지는 1954년 초에 나온 회보의 15쪽에 있다.

이 질문을 표준적인 RAG에 던지면 어떻게 될까. 질문을 임베딩하고, 비슷한 청크 몇 개를 가져오고, 프롬프트에 넣고, 답하라고 한다. 걸리는 청크는 ‘1953년 국방비’와 비슷한 것들이다. 서로 다른 회보에서 온 부분 표가 섞여 들어온다. 모델은 손에 든 것으로 답해야 한다. 일곱 달치만 보이면 일곱 달을 더하거나, 빠진 달을 어림하거나, 자료가 부족하다고 말한다. 이 벤치마크(OfficeQA Pro)에서 GLM-5.2 모델의 one-shot RAG 정답률은 6.3%였다.

같은 모델, 같은 인덱스에 도구 다섯 개를 쥐여 주면 이야기가 달라진다. 모델은 먼저 검색하고, 결과가 부분적이라는 것을 알아보고, "연초 회보에는 전년 12개월치가 다 실린다"는 추론으로 검색어를 바꿔 다시 검색하고, 1954년 2월호 15쪽을 열어 표를 읽고, 열두 개 숫자를 더한다. 도구 호출 세 번. 정답률은 51.9%로 올랐다.

이것이 2026년 8월 20일 Mistral이 발표한 Agentic Search의 헤드라인이다. 그러나 이 글은 Mistral의 제품 소개가 아니다. 이 수치는 올해 상반기 학계에서 연달아 나온 세 갈래의 연구 — 검색 도구를 모델에게 직접 주는 A-RAG, 문서를 위키로 컴파일하는 LLM-Wiki, 인덱스 없이 grep으로 코퍼스를 뒤지는 DCI — 가 같은 방향을 가리키고 있었다는 것을 제품 형태로 확인해 준 사건에 가깝다.

그 방향을 한 문장으로 쓰면 이렇다.

이 글의 지도는 아래와 같다.

1. 2024~2025년의 RAG — 파이프라인이었다

크게 보기

먼저 우리가 무엇을 떠나고 있는지 정확히 그려 두자. 지난 2년간 ‘RAG’라고 불린 것의 뼈대는 다음 다섯 단계였다.

이 구조에는 중요한 특징이 하나 있다. 검색과 관련된 모든 결정이 모델 밖에서, 모델이 질문을 보기 전에, 사람이 미리 내려져 있다. 청크 크기, k값, 하이브리드 가중치, 리랭커 유무, 재작성 규칙 — 전부 파이프라인 설계자가 고정한다. 모델은 도착한 청크를 받아 답하는 마지막 부품이다. 우리는 이 블로그에서 이 파이프라인을 개선하는 기법 7가지를 따로 정리한 적이 있다. 청킹, 하이브리드, 리랭킹, 질의 확장 — 전부 파이프라인의 부품을 갈아 끼우는 개선이다.

오해하지 말아야 할 것은, 이 구조가 틀렸다는 게 아니라는 점이다. 이 구조가 여전히 최선인 질문이 아주 많다.

오른쪽 목록을 다시 보자. 여섯 항목에 공통점이 있다. 전부 첫 검색 결과를 보고 나서야 다음에 무엇을 해야 할지 알 수 있는 질문이다. 두 문서를 비교하려면 첫 문서를 읽은 뒤에 두 번째 문서에서 무엇을 찾을지 정해진다. 각주를 읽으려면 본문의 각주 번호를 본 뒤에 그 위치로 가야 한다. "제12조는 별표 2를 참조한다"는 문장은 별표 2를 열어야 한다는 뜻이다. 처음 검색이 불충분하다는 것은 결과를 본 뒤에야 안다.

파이프라인은 한 방향으로만 흐른다. 결과를 보고 되돌아가는 지점이 없다. 그래서 오른쪽 질문들에서 파이프라인은 청크를 더 잘 고르는 문제가 아니라 구조적으로 실패한다. k를 늘려도 12개월이 한 표에 모인 페이지가 들어오지 않으면 소용이 없고, 리랭커가 아무리 좋아도 "다시 검색하라"는 명령을 내릴 수 없다.

Mistral은 발표문 첫 단락에서 이 한계를 이렇게 적었다.

"One-shot RAG는 고정된 텍스트 청크 집합을 가져와 모델에게 한 번에 답하라고 한다. 답이 상위 결과 중 하나에 나타날 때는 잘 작동하지만, 모델이 긴 보고서를 헤쳐 가야 하거나, 참조를 따라가야 하거나, 여러 문서를 비교해야 하거나, 근거가 되는 증거를 검증해야 할 때 흔들린다."

2. 무엇이 바뀌었나 — 알고리즘이 아니라 "누가 결정하는가"

2026년 상반기의 변화를 한 축으로 정리하면 이렇다. 검색 알고리즘이 바뀐 것이 아니다. BM25도 벡터 검색도 그대로 있다. 바뀐 것은 검색과 관련된 결정을 누가, 언제 내리는가다.

이 표의 첫 줄이 이 글의 주제다. 나머지 일곱 줄은 첫 줄의 결과이거나 첫 줄과 함께 움직이는 변화들이고, 시리즈의 다음 편들에서 하나씩 다룬다.

첫 줄을 조금 더 풀어 보자. "에이전트가 검색·열기·이동·읽기·재검색"한다는 것은 다음 세 가지가 동시에 바뀐다는 뜻이다.

이 셋을 관통하는 말이 이 특집의 부제다. 검색기를 만드는 것이 아니라, 검색하는 사람을 만든다. 사람 사서는 색인 카드 다섯 장을 뽑아 손님에게 건네고 끝내지 않는다. 카드를 보고 서가로 가서 책을 꺼내 목차를 보고 해당 쪽을 펼쳐 표를 확인하고, 없으면 옆 책을 꺼낸다. 2026년의 RAG는 그 사서를 소프트웨어로 만드는 일이 되었다.

3. 연구 ① A-RAG — 검색 도구를 모델 손에

크게 보기

2026년 2월, 중국과학기술대학(USTC) 연구진이 arXiv에 올린 「A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces」는 이 변화를 가장 깨끗한 형태로 보여 준다. 논문의 진단은 한 문장이다.

"기존 RAG 시스템은 단일 샷으로 문단을 가져오거나 워크플로를 미리 정의하는 방식에 의존하는데, 어느 쪽도 모델이 검색 결정에 참여하도록 허용하지 않으며, 이 때문에 모델이 향상되어도 그에 맞춰 효율적으로 확장되지 못한다."

3.1 세 개의 도구

A-RAG의 처방은 검색 알고리즘을 바꾸는 것이 아니라 인터페이스를 바꾸는 것이다. 모델에게 세 개의 도구를 주고 ReAct 방식으로 반복하게 한다.

설계의 요체는 세 번째 열에 있다. 두 검색 도구는 전문을 돌려주지 않는다. ID와 짧은 스니펫만 준다. 전문은 모델이 chunk_read로 명시적으로 요청할 때만 들어온다. 논문은 이를 ‘계층적(hierarchical)’ 인터페이스라고 부르는데, 검색 결과의 해상도를 단계적으로 올려 가는 구조다. 한 번 읽은 청크를 다시 읽으려 하면 "이 청크는 이미 읽었다"는 메시지만 돌아오고 토큰을 쓰지 않는다.

루프는 단순하다. 모델은 매 스텝에 도구 하나를 부르거나 최종 답을 낸다. 도구 결과는 대화 이력에 붙고 다음 스텝의 입력이 된다. 스텝 예산이 다 떨어지면 지금까지 모은 것으로 답을 합성하라는 프롬프트가 들어간다. 저자들은 병렬 도구 호출 같은 정교한 장치를 의도적으로 뺐다고 적었다. 인터페이스의 효과만 깨끗하게 관찰하기 위해서다.

3.2 결과 — 그리고 ‘Naive’라는 대조군

논문의 결과표에는 비교 대상이 하나 더 있다. A-RAG (Naive). 도구가 하나뿐인 에이전트다 — naive_embedding_search 하나로 임베딩 유사도 상위 청크의 전문을 돌려받는다. 즉 "에이전트가 반복 검색한다"는 점은 같지만 인터페이스가 계층적이지 않다. 이 대조군이 있어서 논문은 "반복이 이득인가, 계층적 인터페이스가 이득인가"를 분리해 볼 수 있다.

위젯의 네 탭을 순서대로 보면 논문의 논지가 그대로 드러난다.

① 정확도. GPT-5-mini 백본에서 A-RAG (Full)은 세 다중 홉 데이터셋 모두 1위다. 가장 어려운 MuSiQue에서 Naive RAG 52.8 → 74.1. 그래프를 미리 짓는 HippoRAG2(61.7)·LinearRAG(62.4)보다 높다. 그런데 백본을 GPT-4o-mini로 바꾸면 2Wiki에서 HippoRAG2가 A-RAG를 앞선다. 도구를 쥐여 주는 방식은 모델이 도구를 잘 다룰 때만 이득이 커진다.

② 검색 토큰. 이 탭이 이 논문에서 가장 중요한 표다. 질문당 평균 검색 토큰이 Naive RAG 약 5,300, A-RAG (Naive) 22,000~56,000, A-RAG (Full) 2,700~7,700이다. 도구를 하나만 준 에이전트는 토큰을 4~10배 폭발시킨다. 검색 결과가 전문으로 들어오니 "일단 더 찍어 보자"를 반복할수록 컨텍스트가 무관한 내용으로 차오른다. 세 도구로 나누면 검색은 가볍게, 읽기는 골라서 하게 되어 Naive RAG와 비슷하거나 더 적은 토큰으로 더 높은 정확도를 낸다. 논문은 이를 “점진적 공개(progressive disclosure)”라 부르고, 이렇게 적었다.

"에이전트는 필요에 따라 점진적으로 정보를 가져올 수 있어, 컨텍스트 부담을 최소화하면서도 필요할 때는 포괄적인 증거를 모을 유연성을 유지한다."

③ 도구 제거. 어느 도구를 빼도 떨어지지만 폭이 다르다. semantic_search를 빼면 MuSiQue에서 −4.7로 가장 크다. 홉이 많은 질문은 정확한 단어를 모르는 상태에서 다음 문서를 찾아야 하기 때문이다. keyword_search는 엔티티 이름을 아는 순간에 강하고, chunk_read는 점수보다 토큰 절약에 기여한다. 세 도구는 대체재가 아니라 서로 다른 순간에 쓰는 도구다.

④ 더 생각하게 하면. 최대 스텝을 5에서 20으로 올리면 GPT-5-mini는 약 +8%, GPT-4o-mini는 약 +4%. 추론 강도(reasoning effort)를 minimal에서 high로 올리면 약 +25%. 같은 도구, 같은 예산에서 모델이 좋아질수록 이득이 커진다. 파이프라인 RAG에는 이 이득을 받을 자리가 없다.

3.3 병목이 옮겨 갔다

논문 뒷부분의 실패 분석은 이 변화의 성격을 잘 보여 준다. Naive RAG(GPT-4o-mini)의 실패 원인은 ‘모델 이해 부족’ 35~36%, ‘다중 홉 검색 실패’ 27~36% — 즉 문서를 못 찾은 것이 큰 몫이다. A-RAG(GPT-5-mini)의 실패는 ‘추론 사슬 오류’ 45~82%, ‘포기’ 3~33% — 문서는 찾았는데 잘못 추론한 것이 대부분이다.

저자들은 한계도 분명히 적었다. 도구 설계의 가능한 조합을 전부 비교하지 않았고, 계산 자원 제약으로 GPT-5나 Gemini-3 같은 더 큰 모델에서는 검증하지 못했으며, 사실 검증·대화·장문 생성 같은 다른 지식 집약 과제로의 일반화는 추가 연구가 필요하다.

4. 연구 ② LLM-Wiki — 문서를 위키로 컴파일하고 실수를 기록한다

크게 보기

A-RAG가 인터페이스를 바꿨다면, 2026년 5월 Tencent WeChat 연구진의 「Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki」는 인덱스의 형태를 바꿨다. 청크의 평면 집합 대신, 문서를 서로 링크된 위키 페이지로 컴파일한다.

4.1 컴파일

컴파일은 문단 단위로 진행된다. 각 원문 문단에 대해 (1) 관련된 기존 위키 페이지를 고르고(SelectPages), (2) 별칭·태그·사실·출처 참조 메타데이터와 양방향 위키링크를 가진 마크다운 페이지를 생성·갱신하고(CompileWikiPages), (3) 구조 검증(링크 유효성·형식)과 내용 검증(원문 근거·페이지 간 일관성)을 거친다. 새 문서가 들어오면 전체를 다시 짓지 않고 배치 단위로 페이지를 진화시킨다. 결과물은 디렉터리 색인, 구조화된 마크다운 페이지, 원문 아카이브의 세 층이다.

에이전트에게 주는 도구는 둘이다. wiki_search(query)는 페이지 이름·별칭·태그·설명을 먼저 보고 그다음 본문으로 내려가며 후보 페이지를 돌려주고, wiki_read(paths)는 디렉터리 색인이나 페이지 전체를 읽는다. 읽은 페이지 안의 링크가 다음 홉으로 가는 손잡이가 된다. 아는 엔티티는 바로 열고, 브릿지 질문은 링크를 따라가고, 열린 질문은 색인을 훑는 식으로 모델이 전략을 고른다.

4.2 Error Book — 실수를 규칙으로 바꾼다

이 논문의 가장 독특한 장치는 Error Book이다. 컴파일 과정에서 발견된 오류를 기록해 두고, 그 원인을 자연어 제약 규칙으로 바꿔 다음 배치의 컴파일 프롬프트에 주입한다.

오류의 분포도 공개했다. 끊어진 링크(dangling link)가 검출 오류의 29.1~63.8%, 잘못된 참조가 18.9~28.5%. 수리는 두 층으로 한다 — 코드가 매 배치 뒤 구조 오류를 결정론적으로 고치고, N개 문서마다 LLM이 의미 수준 문제를 처리한다. 2장 변화 요약표의 네 번째 줄, “검색 실패를 진단해 인덱스를 수정하는 연구”가 가리키는 것이 바로 이 장치다. 이 주제는 시리즈 4편에서 더 깊이 다룬다.

4.3 결과 — 정확도보다 지연시간을 보라

500문항씩 세 벤치마크에서 LLM-Wiki의 F1은 HotpotQA 0.839, MuSiQue 0.739, 2WikiMHQA 0.911. 가장 강한 기준선 LightRAG(0.819 / 0.659 / 0.847)보다 2.0~8.1점 높고, HippoRAG 2·GraphRAG보다도 높다. 홉이 늘수록 격차가 벌어져 2Wiki 4홉 문제에서는 0.983에 이른다. 다문서 구조 질의(AuthTrace)에서는 문서 수가 많을수록 HippoRAG 2와의 격차가 커진다(다문서 비중이 높은 질의에서 55.4% vs 46.5%).

그러나 이 논문에서 실무자가 가장 눌러 봐야 할 표는 지연시간이다.

에이전트가 검색·읽기·링크 따라가기를 반복하는데도 지연시간이 한 번 검색하는 Dense RAG와 같다. HotpotQA(14.9초)와 2Wiki(15.9초)에서는 오히려 빠르다. 이유는 링크가 미리 컴파일되어 있어서 질의 시점에 LLM 호출이 적기 때문이다. 에이전트는 질문당 평균 2.5~3.9쪽만 읽는다. 그래프 기반 방법들(LightRAG 39.7~51.3초, HippoRAG 2 32.4~38.2초)이 느린 것은 질의 시점에 그래프 탐색과 요약을 하기 때문이다.

제거 실험은 무엇이 이득의 원천인지 알려 준다. 위키 구조를 빼면 6.1~7.0점, 진행형 탐색(링크 따라가기)을 빼면 11.7~13.8점, Error Book을 빼면 3.4~4.0점 떨어진다. 컴파일된 구조는 에이전트가 능동적으로 탐색할 때 가장 쓸모 있다 — 3장 A-RAG와 같은 결론이다.

한계는 저자들이 먼저 적었다. 컴파일 비용이 청크-임베딩보다 크다(문단마다 SelectPages와 CompileWikiPages가 돈다). 위키가 수만 쪽으로 커지면 디렉터리 색인이 비대해지고 페이지 선택이 나빠질 수 있다. 자주 바뀌는 웹 규모 코퍼스에는 계층 색인·샤딩·낡은 사실 처리가 따로 필요하다. 백본은 GLM-5.1, 임베딩은 Qwen3-Embedding-8B이며, 답변 모델을 GPT-4o로 바꿔도 Dense RAG 대비 5.1~16.9점 우위가 유지됐다 — 이득이 특정 모델이 아니라 지식의 조직 방식에서 온다는 증거다. 그리고 아직 사전 공개(preprint) 단계이므로 독립 재현 전까지는 그 수치로 읽어야 한다.

5. 연구 ③ DCI — 인덱스를 아예 없애면

크게 보기

세 번째 갈래는 가장 과격하다. 인덱스를 없앤다.

2026년 5월 Texas A&M·Waterloo·UCSD·Stanford 등 연합 연구진의 「Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction」은 에이전트에게 임베딩 모델도 벡터 인덱스도 검색 API도 주지 않는다. 대신 셸을 준다. grep과 rg로 어휘 매칭을, find와 glob으로 파일을 찾고, 파일을 읽는다. 저자들은 이를 Direct Corpus Interaction(DCI)이라 부른다.

논지는 이렇다. 전통 검색기는 — 희소든 밀집이든 — 코퍼스 접근을 단일 top-k 단계로 압축한다. 그 압축이 에이전트가 다단계 추론을 하고, 약한 단서들을 조합하고, 가설을 반복 수정하는 것을 막는다. 그래서 검색 품질은 추론 능력뿐 아니라 모델이 코퍼스와 상호작용하는 인터페이스의 해상도에 달려 있다.

"검색 품질은 추론 능력뿐 아니라 모델이 코퍼스와 상호작용하는 인터페이스의 해상도에도 달려 있으며, DCI는 이로써 에이전트 검색을 위한 더 넓은 인터페이스 설계 공간을 연다."

결과는 놀랍다. 추론이 필요한 검색 벤치마크 BRIGHT에서 BM25는 nDCG@10 20.3, 최고 리랭커(ReasonRank-32B)는 47.0인데, Claude Sonnet 4.6을 쓴 DCI-Agent는 68.5다. BrowseComp-Plus에서는 정확도가 69.0%에서 80.0%로 오르면서 비용은 1,440달러에서 1,016달러로 줄었다. 다중 홉 QA 평균 83.0%는 가장 강한 기준선보다 30.7점 높다.

그러나 이 논문에서 가장 정직한 표는 코퍼스 규모 실험이다.

위젯의 네 번째 카드를 누르고 슬라이더를 밀어 보면 알 수 있다. 문서 10만 건에서 20만 건으로 늘리면 정확도가 13.6점 떨어지고, 40만 건에서는 37.5%로 무너진다. grep은 좁은 범위의 정밀 검사에는 대단히 강하지만, "수십만 문서 중 어느 것이 유망한가"를 고르는 일에는 약하다. 그 일이 바로 인덱스가 잘하는 일이다. 저자들의 표현으로, DCI는 "정답 사슬을 더 많이 복원해서가 아니라, 표면에 드러난 증거를 더 가치 있는 국소 검사로 전환해서" 이긴다. 비용도 만만치 않다 — 경량 에이전트가 질문당 평균 35회 도구를 호출해 약 0.10달러, 검색 기준선은 약 0.05달러다.

비슷한 시기 AWS 연구진의 「Keyword search is all you need」(arXiv:2602.23368)도 같은 방향을 가리킨다. 벡터 DB 없이 키워드 검색 도구만 준 에이전트가 전통 RAG 성능의 90% 이상에 도달했다는 보고다. 지식 베이스가 자주 바뀌는 환경에서 특히 유용하다고 적었는데, 인덱스가 없으면 갱신 즉시 반영되기 때문이다.

세 연구를 위젯의 스펙트럼 위에 놓으면 그림이 정리된다. 인터페이스의 해상도를 올릴수록 정밀도와 유연성은 오르고, 광역 탐색 능력과 비용 예측 가능성은 떨어진다. 실무 답은 어느 한 끝이 아니라 인덱스로 후보를 좁히고, 그 안에서 고해상도 도구를 쓰는 조합이다. 그리고 정확히 그 조합이 3개월 뒤 제품으로 나왔다.

6. 제품화 — Mistral Agentic Search의 다섯 도구

크게 보기

2026년 8월 20일 Mistral이 발표한 Agentic Search는 기존 인덱스 위에 다섯 개의 도구를 얹는다.

발표문은 다섯 도구를 이렇게 요약한다. search는 "기존 인덱스를 사용해 코퍼스 전체에서 관련 문서를 찾고", open은 "특정 문서를 열고", navigate는 "그 안의 페이지·절·영역으로 이동하고", read는 "그 위치의 내용을 가져오고", grep은 "열린 문서 안에서 패턴을 찾는다".

구조의 핵심은 역할 분담이다. 인덱스는 "어느 문서가 유망한가"를 찾는다. 에이전트는 "그 문서의 어느 페이지와 어느 표를 실제로 확인해야 하는가"를 결정한다. 5장 DCI의 약점(광역 탐색)은 인덱스가 메우고, 1장 파이프라인의 약점(문서 내부 이동·재검색)은 에이전트가 메운다. 기술적으로는 인덱스가 청크의 오프셋을 추적해야 하므로(공식 문서의 NavigableIndex + DOCUMENT_PER_CHUNK 모드) 기존 인덱스를 그대로 쓸 수는 없지만, 임베딩 모델이나 검색 알고리즘을 바꾸는 일은 아니다.

6.1 실제 예시를 따라가 보자

발표문에 실린 OfficeQA Pro 예시 — 이 글의 첫 문단의 그 질문 — 를 한 단계씩 따라가 보자.

세 번의 도구 호출이 전부다. 그런데 그 세 번 사이에 파이프라인에는 없는 것이 두 번 일어난다. 첫 검색의 결과를 보고 두 번째 검색어를 만들었다("연초 회보에는 전년 12개월치가 실린다"). 두 번째 검색의 결과를 보고 어디를 읽을지 정했다(1954년 2월호 15쪽). 도구가 다섯 개라는 사실은 이 두 번의 관찰-결정을 가능하게 하는 조건일 뿐이다.

6.2 세 계단 — 어디서 점프가 일어나나

Mistral은 두 벤치마크, 두 모델에서 세 단계를 비교했다. one-shot RAG, search만 반복하는 루프, 그리고 open·navigate·read·grep을 더한 전체 루프.

읽어 낼 것이 셋이다.

첫째, 가장 큰 점프는 첫 계단에서 난다. FinanceBench에서 one-shot 26.7%가 search-only 루프만으로 Mistral Medium 3.5는 +47.3pp, GLM-5.2는 +52.6pp 오른다. 발표문의 표현으로 "약 3배". 문서 내부 이동 도구가 하나도 없어도, 다시 검색할 수 있다는 것 자체가 이만큼이다. 3장 A-RAG의 결론과 같다.

둘째, 두 번째 계단은 정확도를 더 올리면서 토큰을 줄인다. navigation 도구를 더하면 +8.7pp / +6.7pp 추가 상승. 그런데 토큰은 search-only 대비 −23.9% / −33.7%, p90 지연시간은 255초에서 154초로 39.6% 감소. 도구가 늘었는데 비용이 준다 — 7장에서 따로 본다.

셋째, 어려운 벤치마크에서 이득이 더 크다. 스캔·표·숫자 위주인 OfficeQA Pro에서 GLM-5.2는 6.3% → 51.9%. Mistral은 "개선 폭은 더 어려운 벤치마크에서 비례적으로 더 크다"고 적었다.

여기에 흥미로운 각주가 하나 붙어 있다. Kimi 측 연구에 따르면 같은 GLM-5.2가 Claude Code 하네스에서는 OfficeQA Pro 41.4%였고, Mistral 하네스에서는 51.9%였다. 같은 모델에서 +10.5pp. Mistral은 이를 검색 도구 스택(하네스)의 차이로 해석한다. 이것이 사실이라면, 모델이 아니라 도구 설계가 두 자리 수 차이를 만든다는 뜻이다.

6.3 공급사 측 결과라는 것

여기서 반드시 붙여야 할 단서가 있다. 이 수치는 Mistral이 고른 모델, 자체 검색 스택, 자체 하네스에서 나온 공급사 측 결과다. 발표문도 "이 결과는 천장이 아니라 바닥(floors, not ceilings)"이라며 사용 사례별 튜닝으로 더 오를 수 있다고 적었지만, 그 말은 동시에 이 실험 조건이 Mistral의 통제 아래 있었다는 뜻이다. 독립적인 일반화 결과로 읽어서는 안 된다. 다만 방향은 3~5장의 학계 연구와 정확히 일치하므로, 방향은 믿고 크기는 우리 데이터로 다시 재는 태도가 적절하다.

배포 형태는 둘이다. 자체 에이전트에 붙이는 Mistral Search Toolkit(클라우드·온프레미스), 그리고 Studio와 Vibe에 내장된 Libraries. 로컬에서 코퍼스를 색인해 볼 수 있는 search-starter-app(MIT)이 GitHub에 있고, Vespa 인덱스와 MCP 서버, 도구 7종(검색 5 + ingest·delete)을 포함한다.

7. 왜 도구가 늘었는데 토큰이 줄었나

크게 보기

6.2절의 두 번째 계단은 직관에 어긋난다. 도구가 다섯 개면 호출도 많아지고 컨텍스트도 늘어야 하지 않나. 그런데 줄었다. 이유를 정리해 두는 것이 이 특집에서 가장 실용적인 부분일 것이다.

한 줄로 압축하면 이렇다. 무작정 broad search를 반복하는 대신, 유망한 문서를 열고 특정 페이지로 이동하면 불필요한 검색과 입력 토큰이 줄어든다. 이것은 Mistral 고유의 현상이 아니다. 3장의 A-RAG (Naive) 22,000~56,000 토큰 대 A-RAG (Full) 2,700~7,700 토큰이 같은 현상이고, 4장의 LLM-Wiki가 반복 탐색을 하면서도 Dense RAG와 같은 지연시간을 내는 것도 같은 원리다(링크가 미리 있어 광역 검색 대신 국소 이동을 한다).

여기서 얻는 설계 원칙은 하나다. 에이전트에게 검색 도구를 줄 때 검색 도구 하나만 주는 것이 최악이다. 반복은 가능해지는데 해상도가 없어서 매번 코퍼스 전체를 통째로 들여온다. 도구를 주려면 가벼운 검색 + 위치 이동 + 선택적 읽기를 세트로 줘야 한다.

8. 실무 판단 — 어느 질의를 어느 경로로

크게 보기

이제 가장 중요한 실무 결론이다. Agentic Search를 전체 질의에 적용하면 안 된다.

이유는 두 가지다. 첫째, 1장에서 본 것처럼 파이프라인 RAG가 여전히 최선인 질문이 많다. Mistral 자신도 발표문에서 one-shot RAG가 여전히 적합한 경우를 셋 명시했다 — "짧고 깨끗한 문서에서 답이 상위 청크에 나타날 직접 조회", "추론이나 이동 없이 관련 문단을 돌려주면 되는 대량 검색", "답의 출처와 위치가 미리 알려진 단순하고 예측 가능한 질문". 둘째, 에이전트 루프는 지연시간과 비용이 질의마다 다르고 상한이 있다. 초당 수십 건의 FAQ에 3~8회 도구 호출을 붙일 이유가 없다.

따라서 구조는 라우팅이 된다.

위젯의 판정 규칙은 단순하지만, 실제 시스템에서 이 판정은 사람이 아니라 라우터가 질의마다 내린다. 라우터는 작은 분류 모델일 수도 있고, 첫 검색 결과의 점수 분포를 보는 규칙일 수도 있고, 답변 모델 자신의 “증거가 충분한가” 판정일 수도 있다. 어느 쪽이든 두 가지 설계 원칙이 있다.

기본 경로는 ①이고, 상위 경로는 승격이다. 모든 질의를 먼저 ①로 보내고, ①의 결과가 불충분하다고 판정되면 ②로 올린다. Agentic Search는 기본 RAG를 대체하는 것이 아니라 기본 RAG가 해결하지 못한 질문을 처리하는 상위 경로다. 이렇게 하면 비용의 대부분이 싼 경로에서 소화되고, 어려운 질문만 비싼 경로로 간다. 9장의 위젯에서 승격 비율을 움직여 보면 이 구조의 비용 민감도가 보인다.

경로는 조합된다. 여러 문서를 비교하는 질문(③)이라도 각 문서 안에서는 ②의 도구로 원문을 확인한다. 스캔 문서(⑤)라도 ②로 페이지를 찾은 뒤 그 페이지 이미지만 VLM에 넘기면 수십 쪽을 통째로 넣는 것보다 훨씬 싸다. 관계 질문(④)이라도 그래프가 준 시드 문서 안에서는 ②가 필요하다. 다섯 경로는 배타적 선택지가 아니라 조합 가능한 부품이다.

이 라우팅과 동적 선택의 문제 — 질문별로 검색기·생성기·예산을 고르는 일 — 는 시리즈 3편의 주제다. 여기서는 “전부 켜지 마라”만 확실히 해 두자.

9. 비용·예산·중단 규칙

크게 보기

에이전트 검색을 운영하는 팀이 처음 마주치는 질문은 “켤까”가 아니라 “몇 스텝에서 끊을까”다. 파이프라인은 비용이 상수였다. 에이전트는 비용이 변수이고 상한이 없다. 그래서 다음 셋이 시스템의 필수 부품이 된다.

위젯은 절대 금액을 맞추기 위한 것이 아니다(단가·스텝당 토큰은 가정값이다). 보라고 만든 것은 민감도다. 승격 비율을 20%에서 40%로 올리면 Agentic 경로의 비용 비중이 어떻게 뛰는지, 스텝 예산을 8에서 15로 올리면 정확도 이득(A-RAG 보간)에 비해 비용이 어떻게 느는지. 둘을 번갈아 움직여 보면 결론이 나온다 — 스텝 예산보다 라우팅 정밀도가 청구서를 좌우한다. 승격 비율이 40%를 넘으면 라우터가 헐거운 것이고, 스텝을 늘리기 전에 라우터를 고쳐야 한다.

Mistral 공식 문서가 지연시간·토큰 관리를 위해 권하는 항목도 옮겨 둔다. 후속 검색에 항상 exclude_ids를 쓸 것, 문서 제목이나 source_id를 검색어에 넣어 범위를 좁힐 것, 용어를 알 때는 광역 재검색 전에 grep을 먼저 쓸 것, 홉마다 top_k를 따로 튠할 것, 유사 질의에 시맨틱 캐시를 둘 것, 루프 반복 수를 제한할 것. 전부 7장의 원리 — 광역 검색을 국소 이동으로 바꾸라 — 의 구체적 표현이다.

10. 우리 시스템에 넣는 순서

이 특집을 읽고 “우리도 해 보자”고 결정한 팀을 위해, 순서를 정리한다. 기존 파이프라인 RAG가 돌고 있다는 전제다.

마지막 항목이 2편의 주제다. 여기서는 “측정 없이 켜지 말라”만 적어 둔다.

11. 한계와 반론

11.1 논문과 발표문이 스스로 밝힌 것

• A-RAG는 도구 조합을 전부 비교하지 않았고, GPT-5·Gemini-3급 모델에서 검증하지 못했으며, 다중 홉 QA 밖의 과제로의 일반화는 미확인이다. GPT-4o-mini에서는 그래프 기반 방법에 지는 데이터셋이 있다.
• LLM-Wiki는 컴파일 비용이 크고, 수만 쪽 규모에서 색인이 비대해질 수 있으며, 자주 바뀌는 코퍼스에는 추가 장치가 필요하다. 사전 공개 단계다.
• DCI는 코퍼스가 20만 문서를 넘으면 급격히 무너지고, 질문당 도구 호출 35회·비용 2배다.
• Mistral의 수치는 공급사 측 결과다. 두 모델, 두 벤치마크, 자체 하네스. FinanceBench의 one-shot 기준값 26.7%는 Mistral의 검색 스택에서 나온 것으로, 잘 튠된 하이브리드+리랭커 파이프라인의 기준값은 이보다 높을 수 있다 — 즉 “3배”의 분모가 낮게 잡혔을 가능성을 배제할 수 없다.

11.2 이 특집이 덧붙이는 반론

지연시간의 분포. 평균과 p90이 줄었다는 것은 사실이지만, 에이전트 루프의 지연시간은 파이프라인보다 분산이 크다. FinanceBench에서 평균 71초, p90 154초는 대화형 인터페이스에는 여전히 긴 시간이다. Agentic 경로는 “기다릴 가치가 있는 질문”에만 붙여야 하고, 사용자 인터페이스는 중간 진행(“1954년 2월호를 열고 있습니다”)을 보여 주도록 설계해야 한다.

모델 의존성. 3장에서 본 것처럼 이득은 모델의 도구 사용 능력에 비례한다. 소형 오픈 모델로 온프레미스에서 돌리는 팀은 A-RAG의 GPT-4o-mini 결과를 먼저 보아야 한다. 그 조건에서는 잘 만든 파이프라인이나 그래프 방법이 여전히 앞설 수 있다.

평가의 공백. 이 글의 모든 수치는 최종 답의 정확도다. 에이전트가 어떤 증거를 모았고 무엇을 놓쳤는지를 재는 지표는 아직 표준이 없다. 정답을 맞혔지만 증거가 틀린 경우, 증거는 다 모았지만 추론이 틀린 경우(A-RAG의 주된 실패)가 정확도 하나에 뭉쳐 있다. 2편에서 다룰 문제다.

공격 표면의 확대. 에이전트가 문서를 열고 읽고 그 내용으로 다음 검색어를 만든다는 것은, 문서 안의 문장이 에이전트의 다음 행동을 조종할 수 있다는 뜻이다. 파이프라인에서는 청크가 답변에만 영향을 줬다. 에이전트 검색에서는 청크가 검색 경로에도 영향을 준다. 단일 문서 오염, 여러 문서에 분산된 다중 홉 오염, 코드 예제 오염 같은 새 공격이 나오는 배경이 이것이다. 관련성 점수와 출처 신뢰도를 분리해야 한다는 요구가 여기서 나온다. 8편의 주제다.

“RAG는 죽었다”는 과장. 이 글을 “벡터 검색은 끝났다”로 읽으면 5장의 DCI 코퍼스 규모 실험을 잊은 것이다. 인덱스는 후보를 좁히는 일에 여전히 가장 싸고 빠르다. 바뀐 것은 인덱스가 마지막 단계에서 첫 단계로 옮겨 갔다는 것이다. 우리 블로그가 RAG는 생각보다 단순합니다에서 말한 “검색기 하나와 프롬프트 한 장으로 시작하라”는 조언은 여전히 유효하다. 다만 그 검색기의 결과를 받아 다음 행동을 정하는 것이 이제 사람의 파이프라인이 아니라 모델이 될 수 있다는 것이 달라졌다.

마무리 — 검색기가 아니라 검색하는 사람을 만든다

이 글은 8만 9천 쪽에서 열두 개의 숫자를 찾는 질문으로 시작했다. 파이프라인은 6.3%를 맞혔고, 같은 모델에 다섯 도구를 준 에이전트는 51.9%를 맞혔다. 그 차이를 만든 것은 더 좋은 임베딩이 아니었다. 첫 검색의 결과를 보고 두 번째 검색어를 바꿀 수 있었다는 것, 두 번째 결과를 보고 어디를 읽을지 정할 수 있었다는 것, 그리고 읽은 뒤 충분하다고 판단해 멈출 수 있었다는 것이다.

2026년 상반기의 세 연구는 이 능력을 각기 다른 각도에서 확인했다. A-RAG는 도구를 계층적으로 나누면 반복 검색이 토큰을 폭발시키지 않고 오히려 줄인다는 것을, LLM-Wiki는 구조를 미리 컴파일해 두면 반복 탐색이 한 번 검색과 같은 속도로 돈다는 것을, DCI는 인터페이스의 해상도가 추론 능력만큼 중요하다는 것을 — 그리고 해상도만으로는 광역 탐색을 대신할 수 없다는 것을. 8월의 Mistral은 이 셋을 하나의 제품 구조로 묶었다. 인덱스가 문서를 찾고, 에이전트가 페이지를 찾는다.

그래서 2026년 9월의 RAG 설계는 질문이 바뀐다. “어떤 임베딩과 어떤 k를 쓸 것인가”에서 “어느 질의를 어느 경로로 보내고, 무엇을 충분하다고 판정하고, 몇 스텝에서 멈출 것인가”로. 검색 파이프라인을 만드는 일이 검색하는 에이전트와 증거 관리 시스템을 만드는 일이 되었다.

이 시리즈의 나머지 일곱 편은 이 문장의 각 부분을 하나씩 열어 볼 것이다. 다음 편은 “무엇을 충분하다고 판정하는가” — 검색의 목표가 청크의 관련성에서 최소 충분 증거 집합으로 옮겨 갈 때 평가 지표는 어떻게 달라져야 하는지다.

참고자료

연구 논문

• Du, M., Xu, B., Zhu, C., Wang, S., Wang, P., Wang, X. & Mao, Z. A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces. arXiv:2602.03442 (2026년 2월) · 코드: github.com/Ayanami0730/arag
• Ming, H., Li, F., Wu, X. & Que, W. Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki. arXiv:2605.25480 (2026년 5월, Tencent WeChat)
• Li, Z., Zhang, H., Wei, C., Lu, P. et al. Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction. arXiv:2605.05242 (2026년 5월)
• Subramanian, S., Akinfaderin, A., Zhang, Y. et al. Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use. arXiv:2602.23368

Mistral Agentic Search

• Mistral AI. Introducing Agentic Search. mistral.ai/news/agentic-search (2026년 8월 20일) — 벤치마크 수치·예시·one-shot RAG가 적합한 경우
• Mistral Docs. Agentic Search. docs.mistral.ai/studio/search/agentic-search — 도구 시그니처·NavigableIndex·성능 가이드
• github.com/mistralai/search-starter-app (MIT) — Vespa 인덱스 + MCP 서버 + Vibe 연동 템플릿

벤치마크

• Islam, P. et al. FinanceBench: A New Benchmark for Financial Question Answering. arXiv:2311.11944 (2023) — SEC 공시 368건
• OfficeQA Pro — 미국 재무부 회보(Treasury Bulletin) 696권 기반 수치 벤치마크 (Mistral 발표문 인용)
• HotpotQA · 2WikiMultiHopQA · MuSiQue — 다중 홉 QA 표준 벤치마크 · BRIGHT · BEIR · BrowseComp-Plus — 추론 기반 검색 벤치마크

비교 대상 시스템

• Gutiérrez, B. J. et al. From RAG to Memory (HippoRAG 2), arXiv:2502.14802 (2025)
• Guo, Z. et al. LightRAG: Simple and Fast Retrieval-Augmented Generation, arXiv:2410.05779 (2024)
• Edge, D. et al. From Local to Global: A Graph RAG Approach, arXiv:2404.16130 (2024)
• Yao, S. et al. ReAct: Synergizing Reasoning and Acting in Language Models, arXiv:2210.03629 (2022) — A-RAG 루프의 원형

함께 읽으면 좋은 코어닷투데이 글

• RAG는 생각보다 단순합니다 — 벡터 DB 없이 시작하는 6단계 레시피 — 이 글의 출발점인 파이프라인 RAG 입문
• Advanced RAG: 기본 RAG의 한계를 넘는 실전 개선 기법 7가지 — 파이프라인의 부품을 개선하는 기법들
• AI 사서 7명이 협업한다 — Google의 Agentic RAG — 충분성 검증 에이전트와 ReAct부터의 역사
• GraphRAG는 정말 효과적인가? — ICLR 2026 논문이 밝힌 9가지 진실 — 5편(GraphRAG 다변화)의 배경
• From RAG to Memory: HippoRAG 2 완전 해부 — 이 글의 기준선 중 하나
• 사건은 문서가 아니라 궤적이다 — Microsoft RAFT — “현재 상태를 보고 검색한다”의 다른 구현
• 긴 맥락이 독이 된다: Context Rot와 컨텍스트 엔지니어링 — 7장 “토큰이 줄어든 이유”의 배경