도구 한계 안에서 추론도 제한적…
ReAct형(추론과 행동을 번갈아 수행하는 방식) 에이전트는 ‘행동 선택 → 도구 실행 → 결과 확인 → 다음 행동 선택’의 순환을 반복한다. 보험 지식 그래프를 다룬 데이터 분석 전문 매체 Towards Data Science의 사례는 이 순환 구조를 유지한 채, 에이전트에게 제공하는 도구만 달리했다. 검색 도구 하나만 받은 에이전트는 검색어를 바꾸며 비슷한 문서를 반복해서 찾았다. 반면 엔티티(개체) 식별, 관계 탐색, 사건의 시간순 정리, 변경 사항 비교, 모순 확인처럼 용도가 명확한 도구를 받은 에이전트는 각 단계에서 관계와 날짜, 정보의 충돌 여부를 검증할 수 있었다. 이 사례는 에이전트의 추론 범위가 도구가 표현할 수 있는 개념과 행동의 범위를 넘기 어렵다는 점을 보여준다.
웹에서도 마찬가지다. 클릭과 키 입력에 의존하는 방식은 화면이 조금만 바뀌어도 쉽게 실패하며, 무엇을 실행했고 그 결과가 올바른지 확인하기도 어렵다. 머신러닝 학회 ICML 2026의 포지션 페이퍼가 제안한 ‘Web Verbs’는 웹사이트의 기능을 구조화된 함수로 제공한다. 각 함수에는 명확한 입력과 출력, 실행 전후에 충족해야 할 조건, 정책 태그, 실행 기록이 포함된다. 여러 행동을 안정적으로 조합하고 결과를 감사하려면, 에이전트가 몇 번 반복하느냐보다 각 행동의 의미와 실행 조건을 먼저 명확히 정의해야 한다.
한번이면 될 일을 스무번 돌렸다
단일 홉(한 번의 검색으로 답이 나오는) 문제에서는 에이전트보다 고정형 파이프라인이 더 정확하고 효율적이었다.
GPT-5-mini로 동일한 15개 문항을 풀게 한 결과, 검색 결과를 한 번에 합치는 고정형 융합 파이프라인의 점수는 0.95였다. 검색박스형 에이전트는 0.78, 여러 타입의 도구를 사용하는 에이전트는 0.70에 그쳤다.
특히 타입 도구형 에이전트는 문항당 평균 5.1회 도구를 호출하고 약 1만 1,400토큰을 사용했다. 그럼에도 대상을 잘못 식별하거나 답할 수 있는 질문에 불필요하게 답변을 거부했다. 결국 한 번의 검색과 합성만으로 해결할 수 있는 문제에서는 에이전트의 반복 행동이 성능을 높이기보다 오류가 발생할 경로만 늘렸다.
생산 환경의 RAG 평가에서도 비슷한 결과가 나타났다. 지식베이스 검색을 ReAct 에이전트에 맡기자 문항별 모델 호출 횟수가 2회에서 25회까지 벌어졌고, p95 지연 시간(가장 느린 상위 5%를 제외한 최대 응답 시간)은 수 분에 달했다. 반면 ‘계획 1회, 답변 합성 1회’로 실행 과정을 고정한 방식은 21개 문항 평가에서 1.43점을 기록해 에이전트형의 1.29점을 앞섰다.
반복 검색의 이점은 멀티 홉(여러 단계를 거쳐야 답이 나오는) 문제에서만 확인됐다. 멀티 홉 평가 점수는 검색박스형이 1.00, 타입 도구형이 0.92, 고정형이 0.83이었다. 다만 검색박스형의 우위는 주의해서 해석해야 한다. 이 방식은 답변에 긴 증거 묶음을 그대로 포함했고, 평가 지표인 키워드 포함률이 이를 유리하게 반영했다. 정작 엔티티 간 관계를 추적하거나 특정 시점의 정보와 상충하는 내용을 직접 조회하는 능력은 부족해, 정밀한 답변에는 한계가 있었다.
예를 들어 2월의 청구 내용과 3월부터 적용된 H3의 15년 기준을 비교한다고 하자. 먼저 청구 대상을 확정한 뒤, 그 대상과 H3 기준의 관계를 조회해야 한다. 관계 조회에 실패하면 기준 문서와 청구 파일을 차례로 다시 검색해야 한다. 이 과정에서는 중간 검색의 성공과 실패에 따라 다음 검색 대상과 검색어가 달라진다.
이것이 멀티 홉에서 필요한 반복이다. 처음 만든 검색 계획을 단순히 여러 번 수정하는 것이 아니라, 앞 단계에서 얻은 결과를 바탕으로 다음 단계를 결정하는 연쇄적 탐색이다. 따라서 단일 홉에는 고정형 파이프라인이 적합하고, 에이전트의 반복 탐색은 중간 결과가 다음 검색을 실제로 바꾸는 멀티 홉 문제에 한해 사용하는 편이 효과적이다.
루프보다 중요한 것은 도구 계약
운영 경로는 기본적으로 ‘고정 융합’을 사용한다. 다만 질문이 앞선 결과에 순차적으로 의존하거나 중간 결과만으로 답하기 어려운 경우, 여러 유효 기간을 비교해야 하거나 근거 사이에 모순이 발견된 경우, 또는 사용자가 심층 조사를 요청한 경우에는 타입 도구 에이전트로 전환한다.
라운드 수, 토큰 수, 경과 시간 같은 실행 제한은 모델 외부에서 관리한다. 한도에 도달하면 그때까지의 실행 기록을 바탕으로 답을 작성하고, 조사가 중단되었다는 사실도 사용자에게 알린다. 에이전트 루프 자체는 약 80줄에 불과하다. 시스템의 핵심 가치는 루프보다 지식 계층의 도구 계약에 있다.
모순 처리 역시 에이전트가 스스로 모순 조회 도구를 호출하는지에 의존하지 않는다. 답변을 작성하는 컴포저(합성 모듈)가 실행 중 접근한 엔티티를 다시 조회해 상충하는 양쪽 근거를 함께 제시하고, 어느 한쪽을 임의로 선택하지 못하도록 강제한다.
실험에서는 프롬프트만으로도 네 모델 모두 쟁점이 있다는 사실을 알렸다. 하지만 이는 단 한 차례의 관측 결과일 뿐이다. 실제로 고정형 시스템은 고객의 일상적인 표현에서 쟁점에 해당하는 개념을 찾지 못해 빈 답을 내놓았다. 반면 모순 조회 도구를 선택할 수 있는 에이전트는 해당 요청을 처리했다. 이는 ‘필요한 능력을 제공하는 것’과 ‘정책을 반드시 지키게 하는 것’을 서로 다른 코드 경로로 구현해야 한다는 점을 보여준다.
검색 지연을 줄인 다른 운영 사례에서도 같은 원칙이 적용됐다. 문서 유형을 식별할 수 있으면 먼저 메타데이터 필터를 사용하고, 관련 결과가 나온 뒤에는 광범위한 키워드 검색을 금지했다. 충분한 근거를 확보하는 즉시 검색을 종료하라는 조건도 도구 설명에 명시했다.
핵심은 재시도 횟수를 늘리는 데 있지 않다. 무엇을 먼저 호출하고 어떤 조건에서 종료할지를 도구 계약으로 명확히 정하는 데 있다.
출처
- Stop Giving Your AI Agent a Search Box and Start Giving It Typed Tools, Hard Bounds, and a Gate It Cannot Talk Past — Towards Data Science
- Position: Web Agents Should Use Typed Actions Instead of Click-Based Browsing — Microsoft Research
- One Shot, Every Answer: How Lyzr Rebuilt Multi-Knowledge-Base RAG Around a Single Retrieval Pass — Lyzr
- Latency Lessons From Building a ReAct AI Agent for Agentic Search — Egnyte