2026-07-05에 The Decoder에서 DiscoBench에 관한 기사를 읽었다. 211개의 태스크, 463개의 모호한 포인트(ambiguous points)를 넣은 검색 에이전트 평가에서, 톱 모델조차 end-to-end accuracy가 43.1%에 불과했다. 게다가 단순히 "검색을 늘리는 것"만으로는 개선되지 않으며, 모호한 상태로 몇 번이고 검색을 반복하다가 결국 마지막에 틀린다는 내용이었다.

이 내용은 검색 에이전트를 만들고 있다면 은근히 뼈아프게 다가온다.

나 자신도 오늘 손에 쥐고 있는 작은 검색 래퍼(search wrapper)를 만지면서, "OpenAI API 요금" 같은 입력을 그대로 검색에 던지는 습관이 아직 남아 있었다. 요금은 날짜에 따라 변하고, 비교 계열의 질문은 기준이 빠져 있다. 그런데 검색 API에 전달하면 깔끔한 쿼리 문자열(query string)이 되어 버린다. 겉보기에는 진전된 것처럼 보이지만, 내용은 어긋나 있다.

여기서 필요한 것은 똑똑한 검색이 아니라, 검색 전의 발목 잡기(stop)다.

나는 여기서 검색 API 바로 앞에 작은 clarify gate를 두기로 했다.

하는 일은 단순하며, 입력을 딱 3가지 종류만 확인한다.

• 엔티티(Entity)가 모호한가
• 비교 기준이 빠져 있는가
• 요금이나 API 제한처럼 날짜나 버전이 필요한가

LLM에게 판단시키기 전에, 저렴한 규칙(rule)으로 차단한다. 모든 것을 구제할 생각은 없다. 오히려 대충 해도 좋다. 검색을 한 번 더 늘리는 것보다, 질문을 한 번 되돌려주는 것이 사고를 줄일 수 있는 케이스를 잡아내기 위한 문지기 역할이다.

Python 3.11로 구동한 코드다. 외부 API는 사용하지 않았다.

from dataclasses import dataclass
import re
import unittest
...

내 환경에서는 다음과 같이 통과했다.

.
----------------------------------------------------------------------
Ran 1 test in 0.000s
...

검색 에이전트의 실패는 마지막 요약(summary)만 보면 파악하기 어렵다. 검색 결과는 나열되고 인용(citation)도 붙는다. 로그만 보면 그럴싸해 보인다.

하지만 첫 번째 분기에서 "어떤 Mercury인지", "무엇을 빠르다고 하는지", "언제 시점의 요금인지"를 놓치면, 그 이후의 검색은 전부 깔끔하게 틀려버린다. 이는 버그로서 까다로운데, 검색 API의 품질 문제처럼 보이거나 RAG의 랭킹(ranking) 문제처럼 보이기 때문이다. 실제로는 입구의 사양(specification)이 부족할 뿐이다.

그래서 검색 도구를 호출하기 직전에 Decision("ask", ...)

을 반환할 수 있는 곳을 만든다. 이곳을 모델의 프롬프트(prompt)에만 맡기면, "모호하면 확인해줘"라고 적혀 있어도 모델은 검색을 시작해버리기 일쑤다. DiscoBench 기사에서도 모호함 감지는 올라가도 태스크 성공률은 그렇게까지 늘어나지 않는다는 관찰 결과가 있었다. 인지하는 것과 사용자에게 되돌려주는 것은 별개의 기술인 듯하다.

내 견해로는 검색 에이전트 구현은 이 순서가 다루기 쉽다.

• 규칙으로 명확한 모호함을 차단한다
• 차단한 이유를 로그에 남긴다
• 사용자 답변을 받아 검색 쿼리를 만든다
• 검색 후 요약에서 인용과 날짜를 확인한다

1번이 없으면 4번에서 아무리 노력해도 되돌릴 수 없다. 검색 후에 "혹시 다른 의미였나요?"라고 묻는 것은 사용자 경험(UX) 측면에서도 꽤 고통스럽다.

위의 코드는 거칠기 때문에, 그대로 실무에 적용하려면 추가할 것들이 있다.

먼저, 모호한 단어의 사전은 프로덕트마다 별도로 가져야 한다. 사내 검색이라면 부서명, 고객명, 약칭, 구 서비스명. 기술 조사라면 모델명, SDK명, 클라우드 서비스명. 이 부분은 일반 사전보다 자신들의 검색 로그를 바탕으로 만드는 것이 더 강력하다.

다음으로, ask의 수를 메트릭(metric)으로 만든다. 모호한 쿼리율이 높은 화면은 UI 측의 입력 예시가 나쁠 가능성이 있다. 사용자가 잘못된 게 아니라, 질문을 유도하지 못하고 있을 뿐이라는 것이다.

그리고 은근히 중요한 것이 질문문을 짧게 만드는 것이다. 긴 확인 문구는 읽히지 않는다. "어떤 Mercury인가요?" 정도로 충분하다. 여기서 너무 정중한 문장을 내보내면 에이전트가 갑자기 상담 채팅처럼 변한다.

검색 에이전트는 검색을 잘하는 것만으로는 부족하다. 모호한 입력을 발견한 순간, 일단 멈출 수 있는 쪽이 실무에서는 강력하다.

이번에 만든 작은 게이트는 검색 품질을 높이는 마법이 아니다. 다만 잘못된 외길로 들어서기 전에 브레이크를 밟을 수 있게 해준다. RAG나 브라우징을 만들면서 "검색 횟수는 많은데 답이 어긋난다"면, 먼저 검색 전의 clarify gate를 의심해 볼 가치가 있다고 생각한다.