[arXiv 2606.18947] Decoupled Search Grounding: 검색과 추론을 분리하는 LLM 에이전트 근거화 구조

Decoupling Search from Reasoning: A Vendor-Agnostic Grounding Architecture for LLM Agents

https://arxiv.org/abs/2606.18947

Emmanuel Aboah Boateng, Kyle MacDonald, Amardeep Kumar, Siddharth Kodwani, Sudeep Das | DoorDash, Inc. | arXiv:2606.18947 | 2026년 6월

---

1. 서론: 검색 기능이 모델 내부로 들어갈 때 생기는 운영 문제

생산 환경의 LLM 에이전트는 더 이상 단순한 질의응답 모델에 머물지 않는다. 사용자의 요청을 여러 단계로 나누고, 중간 상태를 유지하며, 필요한 순간 외부 도구를 호출하고, 최신 정보가 필요하면 검색 결과를 근거로 삼는다. 이 흐름에서 검색은 모델 성능을 조금 보태는 부가 기능을 넘어, 비용과 지연 시간, 장애 전파, 출력 형식, 개인정보와 출처 추적까지 함께 결정하는 시스템 경계가 된다.

이 논문이 겨냥하는 문제는 “검색을 쓰면 정확도가 오른다”라는 일반론보다 훨씬 운영적인 지점에 있다. Google Search grounding처럼 모델 제공자가 native search를 API 내부에 묶어 제공하면 통합은 편해진다. 하지만 어떤 provider가 선택됐는지, 검색 깊이가 얼마인지, 반복 질의가 캐시됐는지, 검색 결과가 어떤 형식으로 모델에 주입됐는지, 오류가 났을 때 어떤 fallback을 탔는지는 애플리케이션 바깥에서 관찰하기 어렵다.

논문은 이 결합을 native search grounding의 편의성과 위험으로 정리한다. native search는 모델 호출 하나 안에 retrieval policy, provider choice, evidence injection, cost, latency, generation behavior를 함께 숨긴다. 실험 결과 native search는 특히 최신성이 중요한 FreshQA에서 강했다. 그러나 SimpleQA와 DoorDash의 e-commerce Query Intent Understanding workload에서는 Decoupled Search Grounding, 줄여서 DSG가 native와 거의 같은 정확도를 훨씬 낮은 search-provider cost로 만든다.

핵심 제안은 검색을 reasoning model 내부 기능으로 취급하지 말고, MCP-compatible gateway가 관리하는 별도의 grounding layer로 분리하자는 것이다. 이 gateway는 provider registry, source-aware context rendering, exact cache, semantic cache, fallback chain, telemetry를 한 경계에 모은다. reasoning model은 GPT-4o, Gemini, Claude처럼 바뀔 수 있고, search provider도 BrightData, Serper, Firecrawl, Exa, Tavily처럼 바뀔 수 있지만, 애플리케이션이 보는 도구 인터페이스는 안정적으로 유지된다.

Figure 1: Decoupled Search Grounding은 검색을 모델 내장 기능에서 분리해 provider 선택, 캐시, 출력 제어를 명시적인 운영 경계로 만든다.

Figure 1은 논문의 문제 설정을 가장 압축적으로 보여 준다. 왼쪽의 native search는 검색과 생성을 한 provider boundary 안에 묶는 반면, 오른쪽의 DSG는 검색 provider와 reasoning model 사이에 명시적인 gateway를 둔다. 이 차이 때문에 비용 추적, provider 교체, 캐시 재사용, 출력 계약 보존이 모델 프롬프트의 암묵적 기대를 벗어나 운영 계층의 설정값으로 다뤄지고, 실험과 장애 분석의 단위도 더 선명해진다.

논문 초록은 이 경계 이동의 효과를 세 가지 수치로 요약한다. 첫째, SimpleQA에서 DSG+BrightData는 86.1% mean accuracy를 기록해 native search의 87.7%에 근접하면서 search-provider cost를 91% 낮춘다. 둘째, repeated-query replay에서 warm-cache hit rate가 99.4%에 도달하고 latency가 68% 감소한다. 셋째, production QIU workload에서는 native search와 비슷하거나 약간 높은 정확도를 유지하면서 search cost를 98% 넘게 줄인다.

여기서 중요한 대목은 논문이 native search를 폐기해야 한다고 주장하지 않는다는 점이다. FreshQA처럼 freshness가 핵심인 benchmark에서는 native search가 뚜렷하게 앞선다. 대신 논문은 검색의 위치를 선택 가능한 설계 변수로 만든다. 어떤 작업은 native search를 provider 중 하나로 쓰고, 어떤 작업은 Serper나 BrightData를 쓰며, 반복 질의가 많은 작업은 cache-gated path를 우선하는 식으로 grounding strategy를 application별로 조절할 수 있다.

2. 배경 및 관련 연구: RAG, 도구 사용, MCP가 만나는 지점

2.1 RAG에서 agentic search로 이동하는 경계

Retrieval-Augmented Generation은 외부 문서를 가져와 모델의 사실성을 보강하는 오래된 접근이다. DPR, FiD, RAG 계열은 주로 정적 말뭉치에서 passage를 가져오고, 생성 모델이 그 passage를 사용해 답을 만드는 구조였다. 이후 FLARE, Self-RAG, Adaptive-RAG, IRCoT 같은 흐름은 검색 시점과 검색 횟수, retrieval-reasoning loop를 더 동적으로 만들었다. DSG는 이 계열과 같은 문제를 보지만, novelty는 retrieval algorithm 자체보다 검색 인터페이스의 소유권에 있다.

도구 사용 연구도 비슷한 흐름을 만든다. Toolformer, ReAct, API-Bank, ToolLLM, WebGPT는 모델이 외부 도구와 상호작용할 수 있음을 보여 줬다. 하지만 실제 운영 환경에서는 “모델이 도구를 부를 수 있는가”만큼 “그 도구 호출이 어떤 provider 정책과 비용 모델, fallback 규칙, telemetry 체계로 둘러싸이는가”가 중요하다. 논문은 agent capability benchmark보다 배포 경계의 controllability에 초점을 둔다.

이전에 리뷰한 LongSeeker는 긴 검색 과제에서 context orchestration과 working memory를 다뤘고, ScoreGate는 RAG 입력 chunk 수를 점수 공간에서 적응적으로 고르는 문제를 다뤘다. DSG는 그보다 낮은 층에서 “검색이 모델 내부 기능인지, 외부 tool boundary인지”를 묻는다. 즉 retrieval policy를 고도화하기 전에 그 policy가 어디에 배치되고 어떻게 관찰되는지를 먼저 문제 삼는 논문이다.

2.2 Native search grounding의 장점과 잠금 효과

Native search grounding의 장점은 매우 현실적이다. 개발자는 별도의 검색 provider API를 붙이고, 응답 필드를 normalize하고, prompt에 context block을 넣고, 실패한 provider를 우회하는 코드를 직접 만들 필요가 없다. 모델 provider가 검색을 호출하고 근거를 생성 맥락에 넣어 주면, 애플리케이션은 한 번의 모델 API 호출만 관리하면 된다. 최신성 민감 질의에서 provider 내부의 indexing과 ranking이 강하면 정확도도 높다.

그러나 이 편의성은 model-provider lock-in과 함께 온다. 더 저렴한 검색 provider를 쓰고 싶거나, domain별 source filtering을 넣고 싶거나, 반복 질의 cache를 공유하고 싶거나, 새 reasoning model로 갈아타고 싶을 때 native integration은 내부 policy를 애플리케이션에 노출하지 않는다. 결과적으로 팀은 품질과 비용을 분해해 최적화하기보다 provider가 제공하는 통합 기능을 그대로 받아들이는 쪽으로 밀린다.

논문은 이 잠금 효과를 검색 기능의 일반적 단점으로 뭉뚱그리지 않는다. provider 선택, result normalization, cache policy, tool-output formatting, migration path가 감춰질 때 운영자가 잃는 제어 표면을 구체적으로 나열한다. 특히 에이전트가 중간 노드로 쓰이는 pipeline에서는 final answer가 사람에게 바로 보이지 않고 downstream parser, classifier, cache key, routing decision으로 이어지기 때문에 출력 형식의 작은 변화도 장애로 이어진다.

2.3 MCP-compatible gateway가 주는 실용적 의미

Model Context Protocol은 모델과 외부 도구, 데이터 소스를 연결하기 위한 실용 표준으로 빠르게 쓰이고 있다. DSG가 MCP-compatible gateway를 선택한 이유는 검색을 특정 model SDK의 옵션 대신 표준화된 tool interface로 표현하기 위해서다. agentic application은 search tool schema를 호출하고, gateway가 provider routing과 result normalization을 담당하면, 모델은 구조화된 도구 결과를 읽는 쪽에 집중한다.

이 구조는 연구 관점에서도 중요하다. 검색 provider를 바꿨을 때 정확도 변화가 provider quality 때문인지, 모델의 generation behavior 때문인지, context rendering 때문인지 분리해 보기 쉬워진다. native search에서는 검색 호출과 evidence injection, generation이 한 boundary 안에서 섞이므로 이런 attribution이 어렵다. DSG는 provider, cache, rendering, model output을 계층별로 기록해 원인 분석에 필요한 관측점을 늘린다.

3. 방법론: Decoupled Search Grounding의 경계 설계

3.1 Source-aware tool formatting

DSG의 첫 번째 구성 요소는 source-aware tool formatting이다. 검색 provider가 반환한 결과를 그대로 prompt에 붙이지 않고, title, URL, snippet 또는 content 같은 공통 필드를 가진 내부 evidence record로 normalize한다. 이후 model-facing rendering은 provider가 달라도 비슷한 구조로 유지된다. 모델은 “이 문장이 어디에서 왔는가”를 URL과 title 단위로 확인하고, 애플리케이션은 동일한 schema를 logging과 debugging에 사용한다.

이 방식은 출처를 단순히 citation decoration으로 붙이는 것보다 넓은 의미를 가진다. source URL은 source filtering, domain allowlist, safety policy, stale evidence pruning, fallback audit에 직접 쓰일 수 있다. native search가 provider 내부에서 context stream을 합쳐 보내면 이런 artifact가 모델 응답 바깥에 안정적으로 남지 않을 수 있다. DSG는 retrieval 결과를 discrete tool response로 보존해 retrieval-generation boundary를 유지한다.

Figure 3: DSG 아키텍처는 agentic application, interchangeable reasoning model, provider-agnostic search backend 사이에 MCP-compatible gateway를 둔다.

Figure 3은 DSG의 전체 제어 흐름을 보여 준다. agentic application은 모델과 검색 provider를 직접 묶지 않고 gateway의 stable tool interface를 호출한다. gateway 내부에는 provider abstraction, search intelligence layer, operational controls, normalized grounding context가 있고, 각 단계가 telemetry를 남긴다. 이 덕분에 같은 애플리케이션이 모델 교체와 provider 교체를 독립적으로 수행할 수 있다.

3.2 Provider abstraction과 fallback chain

두 번째 구성 요소는 provider abstraction이다. 논문은 Serper, BrightData, Firecrawl, Exa 같은 agnostic search provider를 동일한 gateway interface 뒤에 둔다. 표준 HTTP provider는 YAML adapter로 endpoint, method, headers, request template, response-field mapping, capability, cost metadata를 정의할 수 있고, 더 복잡한 provider는 dedicated adapter로 같은 인터페이스에 붙는다.

이때 fallback은 단순 예외 처리보다 정책에 가깝다. provider timeout이나 error response가 발생하면 gateway는 미리 설정된 provider chain의 다음 provider로 넘어간다. 애플리케이션 입장에서는 search tool 호출이 실패했는지, 어떤 provider가 최종적으로 결과를 냈는지, 비용이 얼마나 들었는지를 telemetry로 받을 수 있다. 특정 provider의 장애가 모델 호출 전체의 장애로 즉시 전파되지 않는다는 점도 운영상 중요하다.

3.3 Cache-gated provider execution

세 번째 구성 요소는 search intelligence layer다. 이 계층은 query가 들어오면 먼저 normalized query에 대한 exact cache를 확인하고, 없으면 embedding 기반 semantic cache에서 가장 가까운 query-result pair를 찾는다. similarity가 threshold 이상이면 semantic cache를 재사용하고, 그렇지 않으면 configured provider fallback chain을 실행한다. provider 결과는 다시 exact cache와 semantic cache에 저장된다.

논문이 제시하는 decision rule은 다음처럼 읽을 수 있다. 질의 $q$, 정규화된 질의 $\bar{q}$, provider별 semantic cache $\mathcal{C}=\{(q_i,R_i)\}$, embedding 함수 $e(\cdot)$, fallback chain $\mathbf{p}=(p_1,\ldots,p_k)$가 있을 때 gateway는 먼저 $j^*=\arg\max_j \cos(e(q),e(q_j))$를 찾고, exact hit, semantic hit, provider execution을 순서대로 선택한다. 여기서 threshold $ au$는 의미적으로 비슷한 질의를 어느 정도까지 같은 evidence로 볼지 결정한다.

중요한 점은 cache key가 provider-scoped라는 것이다. 한 provider에서 얻은 결과가 다른 provider의 결과를 조용히 대체하면 provider 비교와 비용 attribution이 깨진다. DSG는 exact와 semantic cache를 provider와 domain별 TTL 정책과 함께 저장해, static factoid query는 오래 재사용하고 recency-sensitive query는 빨리 만료할 수 있게 한다. FreshQA에서 native search가 앞선 결과를 보면, 이런 TTL 정책은 단순 비용 절감보다 신선도 손상을 막는 안전장치에 가깝다.

3.4 Telemetry와 governance layer로서의 DSG

DSG를 gateway로 두면 검색 호출은 단순한 외부 API 요청을 넘어 운영 telemetry event가 된다. 각 요청은 선택된 provider, fallback 여부, retrieval depth, exact cache hit, semantic cache hit, TTL, latency, provider-side cost, source URL 목록을 남길 수 있다. 이 정보가 모이면 팀은 “검색이 느리다”는 모호한 감각 대신 어떤 provider와 어떤 query class가 비용을 밀어 올리는지 확인할 수 있다.

이 telemetry는 모델 교체 실험에서도 중요하다. 같은 query set을 GPT-4o, Gemini, Claude에 넣어 비교할 때 검색 결과가 매번 다르면 model quality와 search quality가 섞인다. DSG는 동일한 provider output을 구조화해 rendering하고, cache를 통해 같은 evidence를 재사용할 수 있으므로 reasoning model 비교와 retrieval provider 비교를 더 깔끔하게 분리한다. 논문이 “interchangeable reasoning model”을 반복해서 강조하는 이유도 여기에 있다.

Governance 관점에서는 provider별 source policy를 중앙화할 수 있다. 예를 들어 특정 domain은 제외하고, 내부 정책상 cache가 금지된 source는 TTL을 0으로 두며, 가격이 일정 임계값을 넘는 provider는 fallback chain 뒤로 미루는 식이다. 이런 정책이 각 agent prompt와 application code에 흩어지면 audit가 어렵다. DSG처럼 grounding control plane으로 모으면 변경 지점이 줄고, 정책 변경이 여러 agent에 일관되게 적용된다.

다만 gateway는 새로운 single point of failure가 될 수 있다. provider 장애를 완충하려고 만든 계층이 자체적으로 느려지거나 잘못된 cache를 반환하면 모든 downstream agent가 영향을 받는다. 따라서 DSG를 실제로 배포하려면 gateway 자체의 health check, cache invalidation audit, provider fallback simulation, stale evidence detection이 함께 필요하다. 논문은 architecture와 evaluation을 제시하지만, 운영 자동화까지 완성하려면 이 governance 계층의 신뢰성 설계가 다음 단계로 붙어야 한다.

4. 실험 설정: 정확도보다 운영 경계를 함께 보는 평가

4.1 평가 benchmark와 workload

논문은 DSG를 단일 benchmark 정확도로만 평가하지 않는다. SimpleQA는 짧은 factoid question의 factuality를 보고, FreshQA는 최신성이 중요한 질문을 통해 검색 index의 freshness를 압박하며, HotpotQA는 multi-hop reasoning에서 검색이 얼마나 도움이 되는지 본다. 여기에 DoorDash의 proprietary e-commerce Query Intent Understanding, 즉 QIU workload를 넣어 실제 배포형 intent-routing 상황을 함께 평가한다.

데이터 크기도 명시되어 있다. SimpleQA는 임의 표본 1,000개, FreshQA는 500개, HotpotQA는 1,000개를 사용한다. QIU Retail은 일반 non-food retail query 7,988개, Tail synthetic은 rare long-tail query 2,335개다. 이 구성은 단일 공개 QA benchmark에서 보기 어려운 두 가지 축을 보완한다. 하나는 recency와 multi-hop의 난이도 차이이고, 다른 하나는 production workload에서 검색 비용과 accuracy가 동시에 어떻게 움직이는지다.

4.2 모델과 검색 provider

평가 모델은 GPT-4o, GPT-4o-mini, Gemini 2.5 Flash, Gemini 2.5 Pro, Claude Sonnet 4의 다섯 개 frontier model이다. 검색 설정은 No Search, Native Search, DSG+BrightData, DSG+Serper, DSG+Firecrawl, DSG+Exa, DSG+Tavily 등을 포함한다. QIU workload에서는 Gemini Flash가 native Google Search grounding을 지원하므로 native baseline으로 사용된다.

비용은 model inference cost를 제외한 search-provider cost per 1K queries로 보고한다. 이 분리 덕분에 “큰 모델을 써서 비싼가”와 “검색 provider가 비싼가”를 구분할 수 있다. latency 역시 benchmark evaluation output에서 측정된 median과 P95를 함께 제시한다. native search는 provider-managed latency라 세부 attribution이 제한적이고, DSG는 provider와 cache hit 여부를 telemetry로 남길 수 있다는 점이 비교의 핵심이다.

4.3 평가 방식과 judge 안정성

SimpleQA와 FreshQA는 GPT-4.1 judge를 사용해 평가하며, SimpleQA에 대해서는 3-judge majority validation ablation을 추가로 수행한다. 논문은 이 ablation에서 mean unanimous agreement가 97.78%였다고 보고한다. HotpotQA는 exact match와 F1을 deterministic하게 계산한다. prompt-compliance diagnostic은 headline accuracy와 분리해 보고되며, 특히 native search가 strict final-answer instruction을 얼마나 잘 지키는지 확인하는 별도 지표로 사용된다.

Task	Scope	No Search	Native	DSG+BrightData	DSG+Serper
SimpleQA	5-model mean	30.8%, 비용 0	87.7%, 비용 20.00	86.1%, 비용 1.80	83.3%, 비용 0.67
FreshQA	5-model mean	56.4%, 비용 0	72.6%, 비용 20.00	68.0%, 비용 1.86	67.3%, 비용 0.66
QIU Retail	Gemini Flash	91.10%, 비용 0	93.40%, 비용 7.90	93.81%, 비용 0.238	93.90%, 비용 0.110
QIU Tail Synthetic	Gemini Flash	83.08%, 비용 0	87.62%, 비용 10.37	86.61%, 비용 0.386	87.79%, 비용 0.146

Table 1은 논문의 main result를 리뷰용으로 재구성한 것이다. SimpleQA에서는 native가 87.7%로 가장 높지만 DSG+BrightData가 86.1%까지 따라오며 비용은 20.00에서 1.80으로 크게 줄어든다. FreshQA에서는 native 우위가 더 분명하다. 반대로 QIU workload에서는 DSG+Serper가 Retail 93.90%, Tail synthetic 87.79%로 native보다 약간 높은 정확도를 기록하면서 비용은 0.110과 0.146으로 낮다.

4.4 비용과 지연 시간을 해석할 때의 주의점

이 논문에서 비용은 model inference cost를 제외한 search-provider cost로 보고된다. 따라서 “DSG가 전체 시스템 비용을 98% 줄인다”로 직접 읽으면 과장될 수 있다. 모델 호출 비용이 큰 workload에서는 search cost 절감이 전체 비용에서 차지하는 비율이 낮을 수 있고, 반대로 작은 모델을 대량으로 호출하면서 검색 provider 비용이 누적되는 workload에서는 search cost 차이가 매우 크게 체감될 수 있다.

Latency 역시 provider-side search latency와 model generation latency가 합쳐진 값으로 읽어야 한다. DSG+BrightData가 SimpleQA에서 native보다 비용은 낮지만 median latency가 더 높은 행도 있다. 운영자는 accuracy와 cost만 보지 말고 P95 latency와 timeout behavior를 함께 봐야 한다. QIU처럼 production routing이 중요한 workload에서는 약간의 latency 증가가 허용될 수도 있고, 실시간 autocomplete 같은 workload에서는 같은 증가가 치명적일 수 있다.

FreshQA 결과는 freshness cost라는 별도 축도 보여 준다. native search가 높은 정확도를 기록한 이유가 최신 index와 provider 내부 ranking에 있다면, 외부 provider를 선택할 때 단순 가격 비교만으로는 부족하다. 최신성 요구가 높은 query class는 native 또는 freshness-specialized provider를 우선하고, 안정적인 factoid query나 반복 query는 cache-friendly provider를 쓰는 hybrid policy가 더 현실적이다.

따라서 DSG의 evaluation은 단일 평균 점수보다 frontier analysis로 읽어야 한다. 어떤 점은 최고 정확도를 제공하고, 어떤 점은 충분한 정확도와 낮은 비용을 제공하며, 어떤 점은 짧은 latency와 높은 cache hit를 제공한다. gateway가 제공하는 장점은 이 점들을 application policy로 선택할 수 있다는 데 있다. 모든 query를 하나의 provider로 보내는 방식보다, query type별 frontier를 학습하고 routing하는 방식이 더 자연스러운 후속 방향이다.

5. 주요 실험 결과: 비용-정확도 전선과 생산 워크로드 효과

5.1 SimpleQA: native 근접 정확도와 provider cost 감소

SimpleQA 결과는 DSG 논문의 가장 설득력 있는 출발점이다. 5개 모델 평균에서 native search는 87.74% mean accuracy를 기록하고, DSG+BrightData는 86.12%를 기록한다. 차이는 약 1.62 percentage point지만 비용 차이는 훨씬 크다. native는 1,000 queries당 20.00의 search-provider cost로 계산되고, DSG+BrightData는 1.80이다. 논문은 이를 약 11배 낮은 search cost로 native에 가까운 정확도를 얻는 Pareto point로 해석한다.

모델별로 보면 패턴이 더 흥미롭다. GPT-4o-mini에서는 DSG+BrightData가 86.4%로 native 85.6%보다 높게 나온다. Gemini 2.5 Pro와 Claude Sonnet 4에서는 native가 각각 88.7%, 90.5%로 가장 높지만 DSG+BrightData도 86.5%, 87.0%까지 접근한다. 이 차이는 “native search가 항상 우월하다”거나 “external provider가 항상 싸기만 하다”는 식의 단순 결론보다, model-provider-search 조합별 frontier를 따로 봐야 함을 보여 준다.

Figure 5: SimpleQA cost-accuracy frontier에서 DSG+BrightData는 native search에 가까운 정확도를 훨씬 낮은 search-provider cost로 달성한다.

Figure 5의 frontier는 accuracy와 search cost를 같은 평면에 놓는다. No Search는 싸지만 정확도가 낮고, native는 정확도가 높지만 비용이 높다. DSG+BrightData는 native 바로 아래의 accuracy 영역에 위치하면서 비용을 크게 낮추고, DSG+Serper는 조금 더 낮은 accuracy를 받아들이는 대신 가장 저렴한 high-accuracy operating point를 제공한다. 운영자는 이 그림을 보고 “최고 정확도”와 “예산 내 충분한 정확도”를 분리해 선택할 수 있다.

Figure 6: SimpleQA 전체 모델-검색 조합 heatmap은 model별 최적 provider가 다르며 mean row에서는 native와 DSG 계열이 가까운 전선을 형성함을 보여 준다.

Figure 6은 SimpleQA의 model-provider matrix를 한눈에 보여 준다. 각 행에서 best configuration이 다르지만, 평균 행에서는 native와 DSG+BrightData가 인접하고 DSG+Serper가 낮은 비용 축에서 따라붙는다. heatmap은 provider 선택이 모델 선택만큼이나 중요한 설계 변수임을 보여 준다. 특히 작은 모델에서도 provider와 rendering을 잘 고르면 native와 비슷한 정확도를 만들 수 있다는 점이 deployment 관점에서 중요하다.

Model	No Search	Native	DSG+BrightData	DSG+Serper	핵심 해석
GPT-4o	35.0	88.0	85.4	82.0	native 최고, BrightData가 비용 절감형 근접점
GPT-4o-mini	9.7	85.6	86.4	81.9	BrightData가 native보다 높게 측정
Gemini 2.5 Flash	32.3	85.9	85.3	82.2	native와 BrightData가 매우 가까움
Gemini 2.5 Pro	54.9	88.7	86.5	84.2	큰 모델에서도 native 우위 유지
Claude Sonnet 4	22.2	90.5	87.0	86.4	native가 최고지만 DSG도 높은 영역

Table 2는 comprehensive SimpleQA table 중 핵심 provider를 뽑아 정리한 것이다. No Search가 모델별 base knowledge의 차이를 보여 준다면, search configuration은 같은 모델의 reachable accuracy를 크게 바꾼다. 비용이 표시되지 않은 이 표만 보면 native가 자연스러워 보이지만, 앞의 main result와 frontier를 함께 보면 BrightData와 Serper의 비용 장점이 커진다.

5.2 FreshQA: 최신성에서는 native search가 여전히 강하다

FreshQA는 DSG의 적용 범위가 task 성격에 따라 달라진다는 점을 분명하게 보여 준다. 5개 모델 평균에서 native search는 72.6%를 기록하고, DSG+BrightData는 68.0%, DSG+Serper는 67.3%다. 최신성 민감 질문에서는 provider 내부 index freshness, proprietary ranking, model-provider integration이 품질에 직접 영향을 준다. 외부 provider를 gateway로 통합해도 freshness 자체가 부족하면 정확도 우위를 만들기 어렵다.

Figure 7: FreshQA heatmap은 recency-sensitive 질의에서 native search가 모든 평가 모델에서 선두를 차지하는 패턴을 요약한다.

Figure 7은 FreshQA에서 native search가 모델 전반에 걸쳐 선두를 차지하는 모습을 보여 준다. 이 결과는 DSG의 논지를 약화하기보다 적용 범위를 더 정확히 정해 준다. 최신 이벤트와 빠르게 바뀌는 사실이 핵심이면 native provider의 검색 인프라가 유리할 수 있다. 따라서 DSG의 가치는 native를 배제하는 데 있지 않고, native와 외부 provider를 같은 정책 공간에서 비교하고 라우팅할 수 있게 하는 데 있다.

Model	No Search	Native	DSG+BrightData	DSG+Serper	관찰
GPT-4o	60.0	74.0	66.2	66.8	native가 큰 폭으로 앞섬
GPT-4o-mini	45.8	62.8	61.0	59.0	BrightData가 근접하지만 native 우위
Gemini 2.5 Flash	61.0	75.2	71.4	71.0	freshness 통합의 이점이 큼
Gemini 2.5 Pro	62.6	75.6	68.2	68.8	외부 provider와 격차가 유지
Claude Sonnet 4	52.6	75.2	73.0	70.8	BrightData가 비교적 근접

이 표에서 가장 중요한 해석은 benchmark 성격에 따른 routing이다. FreshQA처럼 질문 자체가 최신 사건을 묻는다면 native search를 provider chain의 상단에 놓는 것이 합리적일 수 있다. 반대로 질문이 비교적 안정적이고 반복 가능하며 비용 민감도가 높다면 BrightData나 Serper 같은 외부 provider와 cache layer가 더 낫다. DSG는 이 결정을 code fork 없이 configuration과 telemetry 기반으로 바꿀 수 있게 한다.

5.3 HotpotQA와 multi-hop reasoning: 검색 분리만으로는 충분하지 않은 영역

HotpotQA에서는 결과가 더 복합적이다. multi-hop question은 단일 검색 결과를 읽고 답하는 작업보다 retrieval planning과 reasoning coordination이 훨씬 중요하다. 논문은 DSG+BrightData가 여러 모델에서 competitive하거나 native보다 높게 나오는 경우를 보여 주지만, 전반적 gain은 SimpleQA만큼 단순하지 않다고 설명한다. 이는 search boundary를 분리하는 것만으로 multi-hop reasoning의 모든 문제가 풀리지 않음을 의미한다.

Model	No Search EM/F1	Native EM/F1	DSG+BrightData EM/F1	DSG+Serper EM/F1
GPT-4o	38.1 / 0.521	37.6 / 0.541	37.4 / 0.545	35.6 / 0.519
GPT-4o-mini	29.3 / 0.404	39.6 / 0.523	41.0 / 0.566	39.8 / 0.548
Gemini 2.5 Flash	41.1 / 0.537	42.0 / 0.578	44.7 / 0.591	44.2 / 0.582
Gemini 2.5 Pro	44.7 / 0.596	45.1 / 0.610	47.7 / 0.627	46.4 / 0.610
Claude Sonnet 4	33.1 / 0.442	32.6 / 0.444	43.3 / 0.581	43.3 / 0.571

Table 4를 보면 HotpotQA에서는 DSG+BrightData가 GPT-4o-mini, Gemini Flash, Gemini Pro, Claude Sonnet 4에서 강한 수치를 보인다. 그러나 이 결과만으로 multi-hop search가 해결됐다고 보기는 어렵다. 논문 자체도 HotpotQA에서는 단순 검색 보강보다 iterative retrieval, planning, reflection, repeated evidence acquisition이 필요할 수 있다고 한계 섹션에서 인정한다. DSG는 이런 반복 검색 루프를 붙일 수 있는 boundary를 제공하지만, 루프 자체를 학습하거나 설계하는 문제는 별도로 남는다.

5.4 QIU: production workload에서 드러난 비용 효과

QIU 결과는 이 논문이 연구 benchmark를 넘어 production system paper에 가깝다는 인상을 준다. QIU는 marketplace query를 catalog와 web evidence로 해석해 final intent를 분류하는 workload다. Retail dataset은 일반 non-food retail query를, Tail synthetic은 rare long-tail query를 다룬다. 여기서 DSG는 DoorDash 내부의 shared production grounding layer로 쓰이며, 여러 application과 interchangeable model이 같은 gateway를 통과하는 구조로 설명된다.

Figure 8: QIU Retail과 Tail synthetic workload에서 DSG provider들이 native search와 비슷하거나 더 높은 정확도를 낮은 비용으로 달성하는 비용-정확도 관계를 보여 준다.

Figure 8은 QIU workload의 비용-정확도 관계를 보여 준다. Retail과 Tail synthetic 모두에서 DSG+Serper는 native search보다 조금 높은 accuracy를 보이면서 비용은 현저히 낮다. QIU는 공개 benchmark와 달리 실제 e-commerce query intent를 다루므로, 반복 질의, provider routing, domain-specific cache가 생산 환경에서 어떤 의미를 갖는지 보여 주는 근거가 된다. 이 그림 때문에 DSG는 단순 benchmark trick보다 운영 architecture 제안으로 읽힌다.

Dataset	Configuration	Accuracy	Delta vs No Search	Search Usage	Cache	Cost per 1K
Tail Synthetic	No Search	83.08	--	0.0	0.0	0.000
Tail Synthetic	Google Native	87.62	+4.54pp	29.6	0.0	10.373
Tail Synthetic	DSG+Serper	87.79	+4.71pp	29.8	1.73	0.146
Tail Synthetic	DSG+BrightData	86.61	+3.53pp	26.9	3.19	0.386
Retail	No Search	91.10	--	0.0	0.0	0.000
Retail	Google Native	93.40	+2.30pp	22.5	0.0	7.900
Retail	DSG+Serper	93.90	+2.80pp	26.9	14.9	0.110
Retail	DSG+BrightData	93.81	+2.71pp	23.2	25.53	0.238

Table 5에서 가장 눈에 띄는 행은 DSG+Serper다. Tail synthetic에서는 87.79%로 Google native 87.62%를 약간 넘고, cost per 1K는 10.373에서 0.146으로 내려간다. Retail에서도 93.90%로 native 93.40%를 넘고 비용은 7.900에서 0.110으로 내려간다. search usage는 native보다 약간 높지만, provider cost가 낮고 cache가 일부 작동해 전체 frontier가 훨씬 유리해진다.

5.5 결과를 production decision으로 바꾸는 방법

실제 팀이 이 결과를 적용한다면 먼저 query class를 나눠야 한다. 상품명 정규화, 브랜드 disambiguation, category intent처럼 비교적 반복되는 query는 cache와 low-cost provider의 이점이 크다. 반면 최신 뉴스, 실시간 재고, 가격 변동처럼 recency-sensitive한 query는 native search나 freshness가 강한 provider를 우선해야 한다. DSG는 이 분류를 gateway policy로 표현할 수 있게 한다.

두 번째는 output contract의 엄격도를 기록하는 것이다. 어떤 노드는 사용자가 읽는 자연어 답변을 만들고, 어떤 노드는 다음 system이 읽을 entity, JSON, boolean, enum을 만든다. 후자의 경우 native search가 더 많은 evidence를 가져와도 설명형 output을 내면 전체 pipeline은 실패한다. 이 논문이 제시한 Search-Induced Verbosity diagnostic은 이런 schema-critical node를 별도로 관리해야 함을 보여 준다.

세 번째는 provider별 실패 비용을 측정하는 것이다. 검색 provider가 timeout을 내면 fallback으로 넘어갈 수 있지만, fallback provider가 더 비싸거나 coverage가 낮을 수 있다. gateway telemetry가 충분하면 “provider A 장애 시 provider B로 넘어갔을 때 accuracy와 cost가 얼마나 변하는가”를 simulation할 수 있다. native search만 쓰는 구조에서는 이런 장애 모드가 provider boundary 안에 가려져 사후 분석이 늦어진다.

네 번째는 cache hit를 quality metric과 분리해 보는 것이다. hit rate가 높다고 항상 좋은 것은 아니다. stale query가 cache를 타면 latency와 비용은 좋아지지만 correctness가 떨어질 수 있다. DSG는 provider-scoped key와 TTL을 지원하므로 cache policy를 세밀하게 조절할 수 있지만, 실제 정책은 dataset마다 검증해야 한다. 특히 FreshQA류 query는 high hit rate보다 freshness-preserving invalidation이 더 중요하다.

마지막으로, 이 논문의 QIU 결과는 “검색 비용을 낮춘다”보다 “검색 boundary를 공유한다”에 더 큰 의미가 있다. 같은 gateway가 여러 agent와 application에 쓰이면, 한 workload에서 검색된 evidence나 provider health 정보가 다른 workload의 policy 개선에 간접적으로 도움을 준다. 이런 compounding effect는 단일 benchmark table에는 잘 드러나지 않지만, 생산 시스템에서는 장기적으로 중요한 차이를 만든다.

6. 추가 분석 및 Ablation Study: 캐시, 검색 깊이, 포맷 준수성

6.1 Retrieval depth를 운영 knob로 만들기

DSG의 장점은 정확도 수치와 함께 retrieval depth를 budget knob로 바꾼다는 점이다. Appendix ablation은 DSG+BrightData에서 max_results를 2, 4, 6, 10, 15로 바꿔 SimpleQA accuracy를 비교한다. GPT-4o는 2개 결과에서 76.8%, 4개에서 82.2%, 6개에서 82.4%, 10개에서 84.8%까지 오르다가 15개에서 83.2%로 내려간다. GPT-4o-mini와 Claude Sonnet 4도 4~10개 부근에서 포화되는 패턴을 보인다.

Figure 4: 검색 깊이 조정과 semantic cache replay가 비용과 지연 시간을 어떻게 낮추는지 요약한 operational controls 그림이다.

Figure 4는 max_results sweep과 semantic cache replay를 함께 보여 준다. retrieval depth를 늘리면 초반에는 정확도가 빠르게 오르지만 일정 지점 이후에는 포화되거나 소폭 흔들린다. cache replay에서는 cold pass의 hit rate가 6.2%였지만 warm pass에서는 99.4%로 올라가고 latency가 4,570ms에서 1,465ms로 내려간다. 이 그림은 DSG의 제어 표면이 단순한 provider 선택을 넘어 반복 실행 비용까지 다룬다는 점을 보여 준다.

Ablation	Setting A	Setting B	Setting C	Setting D	Setting E
max_results, GPT-4o	2: 76.8%	4: 82.2%	6: 82.4%	10: 84.8%	15: 83.2%
max_results, GPT-4o-mini	2: 76.8%	4: 81.8%	6: 84.8%	10: 85.8%	15: 86.6%
max_results, Claude S4	2: 82.4%	4: 86.4%	6: 87.4%	10: 85.8%	15: 86.8%
cache replay, Cold	31 hits	6.2% hit	cost 0.7385	latency 4,570ms	N=500
cache replay, Warm	497 hits	99.4% hit	cost 0.0045	latency 1,465ms	N=500

이 ablation은 운영자가 “검색 결과를 많이 넣으면 항상 좋다”는 직관을 조심해야 함을 보여 준다. max_results가 너무 작으면 evidence coverage가 부족하고, 너무 크면 noise와 latency가 늘 수 있다. DSG에서는 이 값을 provider별, application별, query type별로 기록하고 조절할 수 있다. native search에서는 내부 ranking과 retrieval depth가 provider boundary 안에 있어 같은 실험을 반복하기 어렵다.

6.2 Search-Induced Verbosity와 output contract

논문의 가장 실무적인 진단은 Search-Induced Verbosity다. production pipeline에서 모델 output은 사용자가 읽는 최종 문장일 수도 있지만, 많은 경우 JSON, boolean, entity string, category label처럼 downstream service가 바로 파싱하는 중간 산출물이다. 이때 정확한 답이 문장 안에 들어 있어도, 출력 계약이 “final answer entity only”라면 설명형 문장은 실패로 처리될 수 있다.

Figure 2: HotpotQA prompt-compliance 진단은 native search가 간결한 정답 추출을 설명형 출력으로 바꿀 수 있음을 보여 준다.

Figure 2는 native search가 prompt-compliance를 흔드는 사례를 시각화한다. HotpotQA에서 Claude Sonnet 4 native-search run은 strict answer-only instruction에도 “Based on the search results...”로 시작하는 설명형 답변을 자주 냈다. DSG는 검색 결과를 별도 tool response로 주고 final output boundary를 유지해 median output length를 13 characters 수준으로 보존한다. 이는 사람이 보기 좋은 답보다 parser가 신뢰할 수 있는 답이 중요한 workflow에서 특히 중요하다.

Mode	Median Length	Starts Based 비율	Extractable Failure 비율	해석
No Search	13	0.0%	--	짧은 entity output 유지
DSG	13	0.0%	--	검색을 사용해도 answer-only boundary 유지
Native	353	78.1%	62.3%	정답 포함 가능성이 있어도 설명형 출력으로 exact contract 실패

논문은 이 현상을 headline accuracy와 분리한다. native search가 정답을 더 잘 찾을 수 있어도, search evidence가 모델 내부 context로 주입되는 방식이 final response style을 바꿀 수 있다. DSG는 retrieval을 structured tool response로 유지하므로, 검색 결과는 근거로 쓰이되 final answer instruction과 tool context가 덜 섞인다. 이 점은 agent orchestration에서 각 node의 output schema를 엄격히 관리해야 하는 팀에 큰 의미가 있다.

6.3 Source-aware context와 provenance

Appendix의 source-aware context example은 DSG가 모델에 어떤 단서를 주는지 보여 준다. 예를 들어 Gulangyu와 Asante Traditional Buildings의 크기를 비교하는 질문에서 gateway는 UNESCO source URL과 title을 가진 두 evidence record를 번호가 붙은 snippet으로 렌더링한다. 모델은 출처별 evidence를 분리해 읽고, 애플리케이션은 어떤 source가 사용됐는지 log로 남길 수 있다.

이 provenance는 단순 출처 표시를 넘어 evaluation과 debugging에 쓰인다. 특정 provider가 stale page를 자주 반환하는지, 특정 domain이 hallucination을 유발하는지, cache reuse가 freshness를 훼손하는지, fallback chain이 기대 순서대로 작동하는지를 확인할 수 있다. DSG가 “검색을 분리한다”는 말은 결국 evidence artifact를 시스템이 다시 다룰 수 있는 형태로 보존한다는 뜻이다.

6.4 Cache safety와 contract validator를 함께 설계하기

Semantic cache는 DSG의 강력한 장점이지만, 유사한 query가 항상 같은 evidence를 써도 된다는 뜻은 아니다. “가장 최근 우승자”, “오늘 영업 여부”, “현재 가격”처럼 시간 의존성이 강한 질의는 embedding similarity가 높아도 cache reuse가 위험하다. 따라서 gateway는 similarity threshold만 보지 말고 query class, source domain, timestamp, provider freshness guarantee를 함께 사용해야 한다. 이것이 논문에서 provider와 domain-specific TTL을 언급한 이유다.

Cache entry에는 결과 본문만 저장하는 것보다 source metadata를 함께 남기는 편이 안전하다. source URL, retrieval time, provider name, normalized query, semantic similarity, TTL expiry를 같이 보관하면 stale evidence가 문제를 일으켰을 때 원인을 추적할 수 있다. 또한 provider 약관상 저장이 허용된 content인지 확인해야 하므로, cache governance는 기술 성능과 법적 제약을 동시에 다루는 계층이 된다.

Output contract 관점에서는 gateway 뒤에 contract validator를 붙이는 설계가 가능하다. 예를 들어 answer-only node라면 final output이 entity string인지 검사하고, JSON node라면 schema validation을 수행한다. 실패하면 모델에 repair prompt를 보내거나, retrieval context를 줄이거나, native search 대신 DSG path를 선택하는 routing rule을 적용할 수 있다. 논문은 이 validator를 직접 구현한 것은 아니지만, Search-Induced Verbosity 진단은 그런 확장의 필요성을 잘 보여 준다.

Figure 2의 예시처럼 native search output에 정답이 포함되어도 “Based on the search results...”로 시작하면 exact-match와 parser 단계에서 실패한다. 이 문제는 사람이 직접 읽는 QA 서비스보다 machine-to-machine workflow에서 더 치명적이다. agent가 다른 agent에게 짧은 label을 넘겨야 하는 구조라면, semantic correctness와 format correctness를 같은 지표로 합치지 말고 분리해서 기록해야 한다.

DSG는 format correctness를 높이는 직접 학습 알고리즘은 아니다. 그러나 retrieval result를 model context에 섞는 방식을 표준화하고, source-aware tool response로 분리하며, final answer instruction을 더 안정적으로 유지할 수 있는 환경을 만든다. 따라서 후속 시스템은 DSG telemetry와 contract validator를 함께 사용해 “어떤 provider와 rendering style이 어떤 schema에서 실패를 많이 만드는가”를 학습할 수 있다.

7. 한계점 및 향후 연구 방향: 벤더 의존성과 다중 홉 검색의 과제

7.1 Third-party provider 의존성

DSG는 native provider lock-in을 줄이지만, 외부 검색 provider 의존성을 없애지는 못한다. Serper, BrightData, Firecrawl, Exa, Tavily 같은 provider의 가격 정책, rate limit, index 품질, API 안정성은 언제든 바뀔 수 있다. 논문도 reported provider cost가 evaluation period의 가격에 의존한다고 명시한다. 따라서 DSG의 진짜 기여는 특정 provider가 지금 싸다는 결론보다, provider 변화가 생겼을 때 policy와 telemetry로 조정할 수 있는 control plane을 제공한다는 점에 있다.

운영 환경에서는 이 한계가 더 복잡해진다. provider 약관에 따라 retrieved content를 cache할 수 있는 범위가 다르고, domain별로 freshness expectation도 다르다. news, product availability, pricing처럼 빠르게 변하는 정보는 TTL을 짧게 가져가야 하고, static encyclopedic fact는 longer TTL이 가능하다. DSG가 이런 정책을 표현할 수 있어도, 어떤 TTL과 similarity threshold가 안전한지는 domain-specific evaluation이 필요하다.

7.2 Multi-hop reasoning은 boundary보다 loop 설계가 중요하다

HotpotQA 결과는 검색과 추론의 경계를 분리하는 일이 multi-hop reasoning 자체의 답이 되지는 않음을 보여 준다. multi-hop question은 첫 검색 결과에서 바로 답이 나오지 않고, 중간 entity를 찾아 다음 검색을 해야 하거나, 서로 다른 출처의 evidence를 연결해야 한다. 이 경우 단일 query를 gateway에 보내는 DSG path만으로는 IRCoT나 Self-RAG류의 iterative retrieval-reasoning loop를 대체하기 어렵다.

따라서 후속 연구는 DSG 위에 planner를 붙이는 방향이 자연스럽다. 예를 들어 첫 검색 결과의 coverage가 낮거나 answer confidence가 낮으면 gateway가 다음 query candidate를 제안하고, 각 step의 provider, cache hit, retrieved source, intermediate answer를 trace로 남기는 구조다. 이렇게 하면 LongSeeker식 long-horizon search orchestration과 DSG식 provider control plane이 결합될 수 있다.

7.3 평가 방법과 LLM-as-judge bias

SimpleQA와 FreshQA는 GPT-4.1 judge를 사용하므로 evaluation bias 가능성이 남는다. 논문은 SimpleQA에서 3-judge majority ablation을 수행했고 mean unanimous agreement 97.78%를 보고해 안정성을 보강한다. 그래도 formatting sensitivity와 judge preference가 남을 수 있다. 특히 Search-Induced Verbosity는 exact output contract와 semantic correctness가 갈라지는 문제라서, 사람이 보기에는 맞는 답이 pipeline에서는 실패인 상황을 별도 metric으로 다뤄야 한다.

향후 평가에서는 task-level accuracy, output contract compliance, source faithfulness, provider freshness, cache safety를 함께 보는 dashboard가 필요하다. DSG는 이 metric들을 기록할 수 있는 boundary를 제공하지만, 어떤 metric에 가중치를 둘지는 application마다 다르다. 의료, 금융, 법률처럼 근거와 형식이 엄격한 영역에서는 native accuracy보다 provenance와 parser reliability가 더 중요할 수 있다.

7.4 후속 연구: adaptive routing과 공개 재현성

후속 연구에서 가장 먼저 필요한 것은 adaptive grounding router다. 현재 논문은 provider별 frontier를 보여 주지만, 실제 운영자는 query마다 어떤 provider와 cache policy를 쓸지 자동으로 결정해야 한다. query freshness, ambiguity, output schema, expected traffic repetition, provider health, budget limit을 feature로 삼아 routing policy를 학습하면 DSG는 단순 gateway에서 adaptive control layer로 확장된다.

두 번째는 공개 재현성이다. QIU 결과가 매우 흥미롭지만 proprietary workload라 외부에서 완전히 검증하기 어렵다. 공개 benchmark에서 비슷한 production-like workload를 구성하려면 e-commerce query intent, product taxonomy, web evidence, catalog evidence, long-tail synthetic query를 함께 담은 dataset이 필요하다. 이런 dataset이 있으면 DSG 같은 architecture paper가 단순 내부 사례를 넘어 더 넓은 연구 커뮤니티에서 비교될 수 있다.

세 번째는 privacy와 compliance 평가다. 검색 gateway가 여러 application의 evidence를 공유하려면 어떤 source를 저장할 수 있는지, user query가 cache key로 남아도 되는지, provider result를 재사용할 수 있는지 명확한 정책이 필요하다. 논문은 윤리 섹션에서 provider-permitted context만 cache한다고 설명하지만, 실제 배포에서는 data-use agreement와 retention policy가 gateway 설계의 일부가 된다.

네 번째는 long-horizon agent와의 결합이다. LongSeeker처럼 여러 단계의 검색과 reasoning을 수행하는 agent는 매 단계마다 query reformulation, evidence filtering, memory update를 수행한다. DSG가 이런 agent의 하부 검색 계층이 되면, 각 step의 provider choice와 cache outcome이 trace로 남는다. 이는 agent debugging과 cost attribution에 큰 도움이 되며, 검색 실패가 planning 실패인지 provider 실패인지 분리하는 데도 유용하다.

8. 내 해석: DSG를 운영 인터페이스로 볼 때 남는 약점과 확장

나는 이 논문을 RAG 성능 개선 논문보다 검색 운영 인터페이스 논문으로 읽는 편이 맞다고 본다. 이전에 리뷰한 ScoreGate가 “검색된 chunk 중 무엇을 넣을 것인가”를 점수 공간에서 다뤘고, MASS-RAG가 다중 에이전트가 source를 어떻게 나눠 검토할지 다뤘다면, DSG는 그보다 먼저 “검색 provider와 모델을 어디에서 분리할 것인가”를 묻는다. 이 관점은 실제 서비스를 만드는 팀에 꽤 현실적이다. 모델을 바꿀 때마다 검색 통합도 다시 만들고, provider 장애가 났을 때 prompt와 application code가 동시에 흔들리는 구조는 유지보수 비용이 크기 때문이다.

다만 약점도 있다. 논문은 QIU workload를 강한 production evidence로 제시하지만, 해당 데이터는 proprietary라 외부 연구자가 같은 조건을 재현하기 어렵다. 공개 benchmark에서는 SimpleQA와 FreshQA, HotpotQA가 쓰였지만, DSG의 가장 큰 장점인 provider routing, cache reuse, source filtering, output contract reliability는 실제 traffic distribution과 반복 질의 패턴에 크게 의존한다. 특히 cache hit 99.4% replay는 반복 질의가 있는 상황의 상한에 가깝게 읽어야 하며, 처음 보는 long-tail query가 계속 들어오는 서비스에서는 같은 폭의 latency와 cost 절감이 나오지 않을 수 있다.

내가 이 연구를 확장한다면, 먼저 contract-aware routing benchmark를 붙여 보고 싶다. 질문마다 freshness requirement, output schema strictness, cache safety, source trust requirement를 annotation하고, DSG가 native search, BrightData, Serper, no-search, cached evidence 중 무엇을 선택해야 하는지 정책 학습 문제로 만드는 것이다. 이렇게 하면 DSG가 단순히 provider를 추상화하는 gateway를 넘어, query property에 따라 grounding path를 자동 선택하는 control layer로 발전할 수 있다.

또 하나는 Search-Induced Verbosity를 더 직접적으로 계측하는 것이다. 논문은 Claude Sonnet 4와 Gemini Flash 예시를 제시하지만, native provider 내부에서 어떤 evidence injection 방식이 style drift를 유발하는지는 알 수 없다. provider-side telemetry가 없으면 완전한 원인 분석은 어렵다. 그래도 DSG boundary에서는 final output validator를 붙여 “정답이 포함됐지만 schema가 깨진 실패”를 자동으로 탐지하고, 필요하면 answer extraction repair step을 실행하는 식의 후처리 설계를 할 수 있다. 이 부분이 실제 agent pipeline에서는 accuracy 개선만큼 큰 가치가 있을 것이다.

9. 결론: 모델 기능을 넘어 시스템 경계로 보는 실시간 근거화

이 논문의 결론은 명확하다. 실시간 검색 근거화는 모델 provider가 제공하는 convenience feature로만 볼 수 없고, 애플리케이션 팀이 직접 최적화해야 하는 interface boundary로 봐야 한다. Native search는 편하고 FreshQA처럼 최신성이 중요한 task에서 강하지만, provider choice, cost, cache reuse, source inspectability, output contract control을 숨긴다. DSG는 이 숨은 선택지를 gateway 바깥으로 꺼내고, reasoning model과 search provider를 독립적으로 교체할 수 있게 한다.

실험 결과도 이 해석을 뒷받침한다. SimpleQA에서는 DSG+BrightData가 native search에 가까운 정확도를 훨씬 낮은 비용으로 달성하고, QIU workload에서는 DSG+Serper가 native보다 약간 높은 accuracy를 매우 낮은 cost로 기록한다. 반복 질의에서는 semantic cache warm pass가 99.4% hit rate를 만들며 latency와 marginal search cost를 크게 낮춘다. 반면 FreshQA에서는 native search가 여전히 선두라서, DSG의 결론은 단일 승자 선언보다 task-aware routing에 가깝다.

가장 실용적인 메시지는 출력 계약이다. 에이전트 pipeline에서 모델의 답은 사람에게 보여 주는 문장보다 다음 node가 읽는 structured output일 때가 많다. Native search가 설명형 답변을 유도해 strict entity output을 깨뜨리면, 의미상 맞는 답도 시스템상 실패가 된다. DSG는 검색 결과를 구조화된 tool response로 보존하면서 final answer boundary를 더 안정적으로 유지한다. 이 문제의식은 앞으로 agentic workflow가 많아질수록 더 중요해질 가능성이 높다.

9.1 에이전트 시스템을 만드는 독자가 가져갈 실무 포인트

첫 번째 실무 포인트는 검색 기능을 모델 옵션으로만 관리하지 말라는 것이다. 모델 SDK의 search flag를 켜는 순간 빠르게 demo를 만들 수는 있지만, production에서는 provider cost, latency tail, evidence logging, source policy, output schema가 모두 함께 따라온다. DSG는 이 요소들을 application configuration과 gateway policy로 분리해, 모델 prompt를 계속 수정하지 않고도 검색 운영 조건을 바꿀 수 있게 한다.

두 번째는 benchmark 설계를 바꾸는 것이다. 검색 기능을 평가할 때 accuracy 하나만 보면 native search가 가장 좋은 선택처럼 보일 수 있다. 그러나 search cost per 1K, P95 latency, exact output compliance, cache hit safety, source provenance를 함께 보면 의사결정이 달라진다. 이 논문의 table과 figure는 바로 그 다차원 평가의 예시다. 특히 agent pipeline에서는 parser failure가 사용자에게 보이는 오답만큼 큰 운영 장애가 될 수 있다.

세 번째는 provider를 고정하지 않는 adapter discipline이다. 초기에 Serper 하나로 붙인 검색 코드가 application 곳곳에 퍼지면, 나중에 BrightData나 Firecrawl을 실험하려고 할 때 변경 범위가 커진다. DSG의 provider registry는 endpoint와 response mapping을 gateway 뒤에 숨겨, provider experiment를 application code 변경이 아닌 configuration change로 바꾼다. 이 구조는 작은 팀에서도 반복 실험 비용을 줄일 수 있다.

네 번째는 cache를 cost optimization으로만 보지 않는 것이다. 반복 질의가 많은 서비스에서는 cache가 지연 시간과 비용을 크게 낮추지만, wrong cache reuse는 조용한 품질 저하를 만든다. 따라서 cache entry마다 provider, source, timestamp, TTL, semantic similarity를 저장하고, query class별로 reuse permission을 다르게 둬야 한다. 이 논문이 provider-scoped key와 domain-specific TTL을 강조한 점은 실제 운영에서 매우 현실적인 조언이다.

다섯 번째는 native search를 경쟁자로만 보지 않는 것이다. DSG의 관점에서는 native search도 하나의 provider path가 될 수 있다. FreshQA처럼 최신성이 중요한 질의는 native path를 우선하고, stable factoid나 QIU처럼 비용과 반복성이 중요한 질의는 external provider와 cache를 우선할 수 있다. 이런 hybrid routing은 특정 논문 수치보다 오래 살아남을 가능성이 높다.

여섯 번째는 logging의 단위를 response에서 grounding decision으로 확장하는 것이다. 모델이 어떤 답을 냈는지만 저장하면 왜 비용이 올랐는지, 왜 schema가 깨졌는지, 왜 특정 provider에서 accuracy가 떨어졌는지 파악하기 어렵다. provider 선택, fallback, cache hit, rendered context, final output contract result를 한 event로 묶어 기록하면, 운영자는 검색 경계에서 일어난 일을 재현할 수 있다.

일곱 번째는 multi-hop agent를 위한 기반 계층으로 DSG를 보는 것이다. 복잡한 web research agent는 query를 여러 번 만들고, 검색 결과를 비교하고, 다음 검색을 계획한다. 이때 각 검색 step이 서로 다른 provider와 cache policy를 탔다면 전체 trace를 관리하기 어렵다. DSG gateway가 하부 검색을 통일하면, planner와 memory module은 검색 운영 세부사항 대신 task decomposition과 evidence synthesis에 집중할 수 있다.

마지막으로, 이 논문은 에이전트 연구가 모델 내부 추론 능력만으로 설명되지 않는다는 점을 다시 확인시킨다. 실제 서비스에서는 근거를 어디서 가져오고, 어떻게 정규화하고, 어떤 비용으로 호출하고, 어떤 형식으로 다음 단계에 넘기는지가 성능을 좌우한다. DSG는 그 문제를 하나의 architecture boundary로 이름 붙였고, 실험을 통해 그 boundary가 accuracy, cost, latency, compliance를 동시에 움직인다는 점을 보여 준다.

운영자가 바로 실험할 수 있는 첫 단계는 현재 agent workflow의 검색 호출을 inventory로 만드는 것이다. 어떤 노드가 검색을 쓰는지, 같은 query가 얼마나 반복되는지, output schema가 얼마나 엄격한지, provider 장애가 발생했을 때 fallback이 있는지 표로 정리하면 DSG가 필요한 지점이 드러난다. 이 표는 논문이 제시한 accuracy table보다 더 현장에 가까운 설계 문서가 된다.

두 번째 단계는 작은 proxy gateway를 붙여 A/B traffic을 나눠 보는 것이다. 전체 검색을 한 번에 바꾸기보다, 일부 query class만 DSG path로 보내고 native path와 동일한 question set에서 accuracy, latency, cost, schema failure를 비교한다. 이때 source-aware rendering을 켜 두면 provider별로 어떤 URL과 snippet이 답변을 흔드는지 추적할 수 있다.

세 번째 단계는 cache를 읽기 전용 shadow mode로 관찰하는 것이다. 실제 답변에는 cache result를 쓰지 않고, gateway가 “이 query라면 cache hit였을 것”을 기록하게 하면 stale risk를 안전하게 측정할 수 있다. shadow hit rate와 human 또는 judge accuracy를 함께 보면 semantic threshold를 어느 정도로 둘지, 어떤 domain은 cache reuse를 막아야 할지 결정하기 쉽다.

네 번째 단계는 output contract failure를 명시적으로 저장하는 것이다. JSON parse error, enum mismatch, entity-only violation, answer-too-long 같은 실패 유형을 ground truth accuracy와 분리해 모으면 native search와 DSG path의 차이가 선명해진다. 특히 Figure 2의 verbosity 현상은 일반 QA metric보다 parser-level metric에서 더 잘 드러난다.

이런 절차를 거치면 DSG는 거대한 재작성 프로젝트로 시작할 필요 없이 점진적 관측 계층으로 도입할 수 있다. 먼저 검색 호출을 gateway에 통과시키고, telemetry를 모으고, 일부 provider와 cache policy를 실험한 뒤, 효과가 확인된 query class부터 production routing에 반영하는 방식이다. 논문이 제안한 구조가 실용적인 이유도 이처럼 기존 agent를 한 번에 버리지 않고 경계를 조금씩 옮길 수 있기 때문이다.

마지막으로 이 구조는 비용 최적화 프로젝트와 연구 실험을 연결한다. 비용을 줄이는 설정이 정확도를 얼마나 잃는지, 정확도를 높이는 설정이 출력 계약을 얼마나 흔드는지, 캐시가 latency를 얼마나 낮추는지를 같은 로그에서 보면 제품팀과 연구팀이 같은 수치로 대화할 수 있다. DSG는 그 공통 언어를 제공하는 얇지만 중요한 계층으로 볼 수 있다.

그 관점에서 이 논문은 특정 검색 provider의 승패보다 검색을 측정 가능한 경계로 끌어낸 점이 더 오래 남는다.

이는 이후 에이전트 검색 평가의 기준선을 더 세밀하게 만들 수 있다.

특히 여러 모델과 여러 검색 provider를 동시에 운영하는 팀이라면, DSG의 장점은 새 모델을 도입할 때마다 검색 통합을 다시 짜지 않아도 된다는 데 있다. 모델은 reasoning quality를 기준으로 교체하고, provider는 freshness와 비용을 기준으로 교체하며, gateway는 두 실험의 접점을 기록한다.

10. 요약 정리

• DSG는 native search grounding을 모델 내부 기능으로 두지 않고 MCP-compatible gateway 기반의 별도 grounding layer로 분리한다.
• 핵심 구성은 source-aware tool formatting, provider abstraction, fallback chain, exact cache, semantic cache, telemetry control plane이다.
• SimpleQA에서는 DSG+BrightData가 86.1%로 native 87.7%에 근접하면서 search-provider cost를 20.00에서 1.80으로 낮춘다.
• FreshQA에서는 native search가 72.6%로 DSG 계열보다 높아, 최신성 민감 질의에서는 provider-native integration의 장점이 남아 있음을 보여 준다.
• QIU Retail과 Tail synthetic에서는 DSG+Serper가 native와 비슷하거나 더 높은 정확도를 보이면서 비용을 98% 이상 낮춘다.
• Search-Induced Verbosity 진단은 native search가 strict answer-only instruction을 설명형 출력으로 바꿔 downstream parser를 깨뜨릴 수 있음을 보여 준다.
• 검색 깊이 ablation은 max_results가 4~10 부근에서 포화되는 경향을 보이며, retrieval depth를 운영 knob로 관리해야 함을 시사한다.
• Semantic cache replay는 warm pass에서 99.4% hit rate와 68% latency reduction을 보여 주지만, 실제 효과는 traffic 반복성과 TTL 정책에 의존한다.
• 논문의 가장 큰 의의는 검색 알고리즘 하나를 제안한 데 있지 않고, LLM 에이전트의 실시간 근거화를 관찰 가능하고 교체 가능한 시스템 경계로 재정의한 데 있다.