LLM에서 검색을 분리하는 DSG, DoorDash가 검색 비용을 90% 이상 절감한 방법

「최종적인 답변만 설명 없이 반환해」라고 프롬프트로 강조한다. 그런데 Web 검색 도구를 주는 순간, 모델은 「검색 결과에 따르면, 200 West Street는 749피트이고, 888 7th Avenue는 628피트이므로…」라고 말하기 시작하며, 원래 원했던 Yes 한 마디가 설명문의 바다 속으로 가라앉는다. 출력을 후속 단계에서 파싱(Parsing)하는 엔지니어라면 이것이 얼마나 골치 아픈 일인지 바로 알 수 있을 것이다.

DoorDash의 엔지니어 5명이 6월 17일에 arXiv에 발표한 논문 Decoupling Search from Reasoning은 이 「검색을 사용하게 하면 망가지는 출력 계약(Output Contract)」을 입구로 삼아, 더 큰 구조적 문제를 지적하고 있다. 그들은 이 현상을 Search-Induced Verbosity(검색 유발적 장황함)라고 명명했다. Claude Sonnet 4에 HotpotQA를 수행하게 한 실측 결과, 예측의 78.1%가 "Based on the search results…"로 시작되었으며, 완전 일치에 실패한 케이스의 62.3%는 정답이 답변 안에 문자열로서 포함되어 있었다. 모델은 답을 알고 있음에도 불구하고, 검색이 모델의 행동을 「추출(Extraction)」에서 「요약·설명(Summarization/Explanation)」으로 옮겨버리는 것이다.

원인은 기능이 아니라 구조에 있다는 것이 논문의 견해다. OpenAI나 Google이 제공하는 「native 검색」(모델 API 내부에서 검색까지 처리해 주는 방식)은 편리한 반면, retrieval(검색/회수) 방침, 검색 프로바이더 선택, 증거 삽입 방식, 비용, 레이턴시(Latency), 생성 시의 행동까지 모두 모델 프로바이더 한 회사의 경계 너머로 묶여 있다. 내부에서 무엇이 일어나는지 들여다볼 수 없고, 조정이나 재사용, 타 모델로의 이식도 불가능하다. 장황함은 그 밀결합(Tight Coupling)이 겉으로 드러난 하나의 증상에 불과하다.

이 지점이 본질이라고 생각한다. native 검색을 「모델에 따라오는 기능」으로 받아들이는 한, 검색의 질과 비용 모두 상대방에게 맡겨야 하는 블랙박스가 된다. 논문의 주장은 「실시간 grounding(근거 제시)은 고정된 기능이 아니라 최적화할 수 있는 인터페이스 경계로 다루어야 한다」는 한 점으로 귀결된다.

제안 기법인 Decoupled Search Grounding(DSG)은 검색을 모델 내부에서 떼어내어 MCP 호환 게이트웨이로 옮긴다. MCP(Model Context Protocol)는 Anthropic이 발표한 오픈 표준으로, AI 앱과 외부 데이터 및 도구를 연결하는 「AI의 USB-C」로 자주 설명된다. DSG는 검색을 하나의 표준 도구로서 모델 외곽으로 분리하여, 지금까지 모델 프로바이더가 쥐고 있던 제어권을 스스로 돌릴 수 있는 노브(Knob)로서 표면으로 끌어낸다.

끌어내어지는 주요 노브는 다음과 같다.

• 프로바이더 라우팅(Provider Routing). Serper, BrightData, Firecrawl, Exa와 같은 검색 프로바이더를 레지스트리에서 정규화한다. 새로운 HTTP 프로바이더는 엔드포인트, 헤더, 요청 템플릿, 응답 필드 대응, 비용 정보가 적힌 YAML 어댑터를 추가하는 것만으로 탑재할 수 있다.
• 소스를 유지하는 정형화. 검색 결과를 title / url / content의 구조화된 레코드로 정규화하여, 출처 URL이 포함된 번호 매겨진 스니펫(Snippet)으로서 모델에 전달한다. 취득한 텍스트를 불투명한 한 덩어리로 녹여내지 않는다.
• 폴백 체인(Fallback Chain). 프로바이더가 타임아웃이나 에러를 반환하면 설정된 폴백 대상으로 자동 전환한다. 일시적인 장애로 인해 grounding 문맥이 끊기지 않는다.
• 취득 깊이. 모델에 전달할 건수(max_results)를 2~15건 사이로 조정할 수 있다.
• 이중 캐시. 완전 일치 캐시와 의미(Semantic) 캐시를 중첩하여 사용한다(후술).

모델에 전달되는 정형화된 문맥은 다음과 같은 소박한 형태가 된다.

Result 1
Title: Kulangsu, a Historic International Settlement
Source: https://whc.unesco.org/en/list/1541/
...

출처가 한 줄씩 명시되므로, 모델은 「검색 결과에 따르면~」과 같은 서두를 생성할 동기가 줄어든다. 검색을 구조화된 도구 응답으로서 안정적인 출력 경계 내부에 가둠으로써 출력 계약이 지켜지게 된다. 앞서 언급한 예시라면, native 출력의 245자가 DSG에서는 Yes 3자로 돌아온다.

비용 절감의 주역은 캐시(Cache)다. 게이트웨이는 쿼리(Query)가 들어오면 먼저 정규화(Normalization)를 거쳐 완전 일치 캐시를 조회한다. 일치하지 않으면 쿼리를 임베딩 벡터(Embedding Vector)로 변환하여 의미론적 캐시(Semantic Cache)의 최근접 이웃(Nearest Neighbor)을 찾고, 코사인 유사도(Cosine Similarity)가 임계값 $\tau$ 이상이면 해당 과거 결과를 재사용한다. 두 방식 모두 실패했을 때 비로소 실제 프로바이더(Provider)의 폴백(Fallback) 체인을 호출한다. 캐시에는 프로바이더 및 도메인별 TTL(Time-To-Live)이 부여되므로, 신선도가 중요한 검색은 즉시 만료되고 변하지 않는 사실은 오래 남는다.

효과는 극명하다. SimpleQA 쿼리를 두 번 실행하는 리플레이(Replay) 실험에서, 1회차(Cold)는 히트율(Hit Rate) 6.2%, 비용 $0.7385였으나, 2회차(Warm)는 히트율 99.4%, 비용 $0.0045까지 떨어졌으며 레이턴시(Latency) 또한 68% 감소했다. 동일한 검색을 두 번 구매하지 않는다는 단순한 원리지만, 에이전트(Agent)가 유사한 쿼리를 대량으로 던지는 실제 운영 환경에서는 그 효과가 매우 크다.

5개의 프론티어 모델(GPT-4o, GPT-4o-mini, Gemini 2.5 Flash, Gemini 2.5 Pro, Claude Sonnet 4)의 평균을 기준으로 한 SimpleQA 결과는 다음과 같다.

구성	정답률	검색 비용(1,000 쿼리)
검색 없음	30.8%	$0
...

native 방식과 거의 동일한 정답률을 유지하면서 검색 비용을 91% 절감했다. DoorDash 자체의 이커머스 쿼리 의도 이해(QIU) 워크로드에서는 더욱 극단적인 결과가 나타났다. native(Gemini Flash)가 93.40%, $7.90를 기록한 반면, DSG+Serper는 93.90%, $0.110를 기록했다. 정확도는 약간 더 높고, 비용은 98.6% 감소했다. 이를 공유된 운영 환경의 그라운딩(Grounding) 계층으로 사용하여 모델을 교체 가능한 상태로 운영하고 있다는 기술은, 이 연구가 단순한 연구로 끝나지 않았음을 증명한다.

단, 만능은 아니다. 신선도가 중요한 FreshQA에서는 native가 72.6%로 DSG(68.0%)를 앞질렀다. 프로바이더 측이 보유한 독자적인 신선도 파이프라인은 범용 검색 API와 캐시만으로는 완전히 재현할 수 없다. HotpotQA와 같은 다단계 추론(Multi-step Reasoning)에서도 검색을 추가하는 것이 단일 단계의 사실 검색만큼 효과적이지는 않다. 따라서 DSG의 결론은 "항상 승리한다"가 아니라, "제어가 필요한 상황에서는 native보다 더 넓은 프론티어 모델을 활용할 수 있다"라는 신중한 입장이다. 이러한 경계 설정의 정직함은 인상적이다.

LiteLLM과 같은 모델 게이트웨이를 통해 모델을 교체 가능한 경계로 만드는 것은 이제 당연한 설계가 되었다. DSG는 단지 그 작업을 검색에 대해서도 수행했을 뿐이라고 할 수 있다. 하지만 그 효용이 발생하는 지점은 결코 사소하지 않다. 검색 API 청구서, 프로바이더 락인(Lock-in), 그리고 에이전트에게 구조화된 출력(Structured Output)을 강제하기 위한 끝없는 싸움. 이 세 가지 문제에 직면해 있다면, 검색을 모델의 기능으로서 통째로 삼키는 대신, 자신이 제어하는 게이트웨이 뒤로 밀어내는 선택지를 한 번쯤 검토해 볼 가치가 있다. 코드는 아직 공개되지 않았지만, 설계의 골자(프로바이더의 YAML 추상화, 2층 캐시, 출처가 포함된 정형화)는 논문을 통해 충분히 파악할 수 있다.