DoorDash 검색 게이트웨이, LLM 웹 검색 요금 98% 절감이 성립한 조건

검색 요금 98% 이상 절감은 DoorDash 가 LLM API 에 딸린 웹 검색(이하 내장 검색)을 사내 게이트웨이 DSG(Decoupled Search Grounding)로 떼어 낸 뒤 검색어 의도 분류 작업에서 얻은 결과다. 정확도는 내장 검색과 같거나 조금 높았다. 다만 이 비율은 검색 업체 요금끼리만 견준 값이고, 모델 호출 요금은 양쪽에서 모두 뺐다. 최신 정보가 걸린 질문(FreshQA)에서는 평가한 다섯 모델 모두 내장 검색이 더 정확했다.

01 내장 검색은 켜기 쉽지만 검색 결정이 모델 API 안에 갇힌다

DoorDash 의 QIU(query intent understanding, 검색어 의도 이해)는 상품 카탈로그와 웹 근거를 같이 보고 모호한 검색어를 해석한다. GeekNews 가 옮긴 예를 보면, 검색 근거 없이 돌린 모델은 "450 north" 를 음식점으로 분류했다. 카탈로그와 웹 근거를 붙이자 수제 맥주 양조장이라는 게 드러났다. 이런 근거를 붙이는 가장 쉬운 길은 모델 API 의 검색 기능을 켜는 것이다. 하지만 DoorDash 는 이 방식으로는 세 가지가 어렵다고 봤다.

• 제어: 모델을 바꾸거나 요금 변화에 대응하려면 모델 연동부를 고쳐야 한다.
• 재사용: 두 에이전트가 같은 질문을 하면 검색 요금도 두 번 나간다.
• 관측과 출력 형식: 쿼리마다 검색에 든 돈과 시간이 안 보이고, 검색을 켜면 정해 둔 출력 형식이 깨질 수 있다.

마지막 문제에 연구진은 Search-Induced Verbosity(검색이 부르는 장황함)라는 이름을 붙였다. HotpotQA 에서 Claude Sonnet 4 의 답 길이 중앙값은 내장 검색으로 353자, DSG 로 13자였다. 내장 검색 답의 78.1%는 "Based on the search results" 같은 머리말로 시작했고, 정확 일치 채점에서 틀린 답 가운데 62.3%에는 정답 문자열이 들어 있었다. 분류 결과를 파서로 받는 파이프라인이라면 답이 맞아도 머리말 하나 때문에 실패한다.

이 글은 DSG 의 구조와 DoorDash 가 공개한 평가 방법·수치만 다룬다. 수치는 DoorDash 연구진이 2026년 6월 arXiv 에 올린 논문의 10월 개정판에서 가져왔다. 이 논문은 EMNLP 2026 Industry 트랙에 실렸다.

02 98%는 검색 업체 요금만, 모델 하나로 잰 값이다

평가에는 공개 벤치마크 셋과 DoorDash 자체 쿼리 두 묶음을 썼다.

다섯 모델은 GPT-4o, GPT-4o-mini, Gemini 2.5 Flash, Gemini 2.5 Pro, Claude Sonnet 4 다. SimpleQA·FreshQA 는 GPT-4.1 이 채점했고, HotpotQA 는 정확 일치와 F1 점수로 기계적으로 쟀다. SimpleQA 에서 판정 모델 셋을 함께 돌려 본 결과, 세 판정이 모두 같았던 비율은 평균 97.78%였다. 사람이 채점하지 않았다는 점은 논문이 한계로 적었다.

요금은 검색 업체에 내는 돈을 1,000쿼리당으로 환산했다. 98%가 나온 QIU 는 Gemini Flash 한 모델로만 돌렸고, 비교 대상은 같은 모델에 Google 검색 그라운딩을 켠 구성이다. DoorDash 는 DSG 를 파는 회사가 아니어서 판매용 벤치마크와는 사정이 다르다. 그래도 한 회사가 자기 시스템을 잰 사례이고, 이번에 찾은 출처에는 같은 조건을 바깥에서 재현한 결과가 없었다.

03 QIU 에서는 비기고 최신성 질문에서는 졌다

네 작업의 정확도와 1,000쿼리당 검색 요금을 나란히 놓으면 이렇다.

98%는 QIU 두 행에서 내장 검색과 DSG+Serper 를 비교한 값이다. 공개 벤치마크로 가면 절감 폭이 줄어든다. SimpleQA 에서 BrightData 는 내장 검색보다 정확도가 1.6%p 낮았고 요금은 약 11분의 1이었는데, 논문 초록은 이를 91% 절감이라고 적었다. FreshQA 에서는 다섯 모델 모두 내장 검색이 앞섰다. HotpotQA 는 어느 방식이든 검색을 붙여 얻는 이득이 작았고 모델마다 달랐다.

내장 검색 요금이 작업마다 다른 이유도 표에서 읽힌다. SimpleQA 의 20달러는 모델별 단가를 평균한 값이다. 논문 표에서 1,000건당 단가는 GPT-4o·Claude Sonnet 4 가 약 10달러, Gemini 2.5 두 모델이 35달러였다. QIU 는 에이전트가 필요할 때만 검색하는 구조라서 Retail 에서는 검색을 부른 쿼리가 22.5%에 그쳤다. 35달러에 이 비율을 곱하면 7.9달러쯤 되어 표의 값과 맞는다.

검색을 아예 끄는 길도 표에 있다. 검색 없이 돌리면 Retail 은 91.10%, Tail 은 83.08%였다. 요금은 0이 되지만 롱테일 검색어에서는 정확도가 4.5%p 남짓 떨어진다.

04 요청 하나는 정규화, 캐시 두 겹, 업체 체인 순으로 흐른다

DSG 는 에이전트와 추론 모델, 그리고 바꿔 끼울 수 있는 검색 업체 목록 사이에 놓인다. 에이전트가 보기에는 MCP(Model Context Protocol, 모델이 외부 도구를 부르는 표준)를 따르는 도구 하나일 뿐이다. 논문의 알고리즘대로 요청 하나를 따라가면 아래와 같다.

에이전트 → DSG: 검색 도구 호출
DSG: 쿼리 정규화
DSG: 정확 일치 캐시 → 적중이면 반환
DSG: 임베딩 → 의미 캐시(유사도 ≥ τ)
DSG → 업체 1: 검색
  시간 초과·오류 → 업체 2 → …
DSG: 제목·URL·본문으로 통일
DSG: 두 캐시에 저장
DSG → 모델: 번호 붙인 발췌 + 출처 URL

등록된 업체는 Serper, BrightData, Firecrawl, Exa, Tavily 다. 일반 HTTP API 는 YAML 어댑터 하나로 붙인다. 어댑터에는 엔드포인트·메서드·헤더·요청 템플릿·응답 필드 매핑·지원 기능·비용 정보를 적고, 응답이 복잡한 업체에는 전용 어댑터를 쓴다. 캐시는 업체별로 나누되 에이전트별로는 나누지 않으므로, 한 에이전트가 받아 둔 결과를 다른 에이전트도 쓸 수 있다. 업체가 시간 초과나 오류를 내면 다음 업체로 넘어가고, 어느 업체도 결과를 주지 않으면 근거 없이 빈 컨텍스트로 간다. 요청마다 업체·검색 깊이·캐시 결과·지연·요금이 기록에 남는다.

업체마다 시간 초과를 얼마로 둘지, 자꾸 실패하는 업체를 언제 잠시 뺄지는 서킷 브레이커 패턴: 언제 열리고 닫히나, 설정 값은 어떻게 고르나에서 다룬 고민과 이어진다. 시간 초과가 길면 대체 업체로 넘어가기 전에 체인 전체가 느려진다.

이 흐름의 갈림길은 코드가 아니라 설정으로 정한다. 하지만 논문은 각 설정의 이름만 밝혔고 값은 대부분 내놓지 않았다.

임베딩 모델과 MCP 도구 스키마도 논문에 없다. 논문이 공개한다고 밝힌 것은 공개 벤치마크 출력·집계 표·그림이고, 게이트웨이 코드를 공개하는지는 적지 않았다. 이번에 찾은 출처에서도 DSG 코드 저장소는 확인하지 못했다. 그러니 내려받아 쓰는 도구라기보다, 구조를 보고 직접 짜야 하는 설계로 보는 편이 맞다.

05 캐시 99.4%는 같은 질문을 다시 돌린 상한이다

캐시 효과는 SimpleQA 500문항을 GPT-4o 와 DSG+BrightData 로 두 번 돌려서 쟀다.

두 번째 회차는 지연이 68% 줄었고 검색 요금은 거의 0이었다. 다만 똑같은 질문을 되풀이한 실험이라 상한으로 봐야 한다. 실제 QIU 실행에서 DSG+Serper 의 캐시 비율은 Retail 14.9%, Tail 1.73%였다. Tail 은 캐시가 거의 맞지 않았는데도 요금이 98% 넘게 줄었으니, QIU 의 절감은 대부분 업체 단가 차이에서 나왔다고 보는 편이 맞다. 캐시 효과는 여러 에이전트가 비슷한 질문을 던질수록 커진다.

결과 수(검색 깊이)는 정확도를 움직인다. 논문은 BrightData 로 GPT-4o·GPT-4o-mini·Claude Sonnet 4 를 돌려 결과 수를 바꿔 봤다. 아래는 세 모델 정확도의 평균이다.

2개에서 6개 사이에서는 크게 오르고, 그 뒤로는 거의 평평하다. Claude Sonnet 4 는 6개에서 가장 높았고 10개에서는 오히려 떨어졌다. 결과 수가 늘면 입력 토큰도 늘어나므로 4~6개에서 시작하는 편이 낫다.

06 한국 팀에게는 자기 단가와 검색 비율이 먼저다

이 사례는 에이전트나 RAG 서비스에서 모델 API 의 검색 기능을 켜 둔 팀에 해당한다. 분류·추출처럼 정해진 형식으로 답을 받는 작업이라면 요금보다 장황함 문제가 먼저 생긴다.

내장 검색을 그대로 쓰는 팀이 많은 데도 이유가 있다. 도구 정의 한 줄이면 켜지고, 검색 업체와 따로 계약하거나 키를 관리할 일이 없다. 최신 정보 질문에서 실제로 더 정확하다는 점도 이번 논문이 보여 줬다.

98%를 우리 숫자로 바꾸려면 기준 단가부터 갈아 넣어야 한다. DoorDash 의 기준선은 Gemini 2.5 의 1,000건당 35달러였다. 2026년 11월 공식 문서 기준 단가는 아래와 같다.

그 기준선마저 곧 바뀐다. Google 요금 문서는 Gemini 2.5 를 지원 종료 대상으로 표시했다. 2026년 12월 1일부터는 gemini-2.5-flash 요청을 Gemini 3.5 Flash-Lite 로, gemini-2.5-pro 요청을 Gemini 3.8 Flash 로 넘기고 그 모델 요금으로 청구한다고 공지했다. Gemini 를 쓰는 팀이라면 35달러가 아니라 Gemini 3 이후 단가로 계산을 다시 하는 편이 맞다.

Gemini 3 이후 요금표의 각주를 보면, 요청 하나에서 검색이 여러 번 일어나면 검색마다 요금을 센다. 실제 과금 단위는 청구서로 확인하는 편이 낫다. 기준 단가가 낮으면 같은 구조를 지어도 절감 비율이 줄어든다. 모델 요금도 그대로 남고, DSG 가 가져온 발췌도 컨텍스트에 들어가 입력 토큰이 된다. 그래서 청구서 전체로 보면 줄어드는 비율은 모델 요금이 차지하는 몫만큼 작아진다.

한국어 질의는 직접 재야 한다. 논문에는 한국어 질의 결과가 없고, 업체 순위도 작업마다 바뀌었다. SimpleQA 에서는 업체만 바꿔도 같은 모델의 정확도가 10%p 넘게 차이 났지만, QIU Retail 에서는 Tavily 와 Serper 의 차이가 0.1%p였다.

상황별로 정리하면 다음과 같다.

되돌리기는 쉬운 편이다. 외부 검색을 도구 하나로 두고 작업 하나에만 붙이면, 도구를 빼고 내장 검색을 다시 켜는 것으로 돌아갈 수 있다. GeekNews 가 옮긴 DoorDash 글에 따르면 내장 검색도 같은 인터페이스 뒤에 업체 하나로 둘 수 있어서, 최신성 질문만 내장 검색으로 보내는 식의 나눔도 가능하다. 대신 검색 업체 API 키가 업체 수만큼 늘고, 업체 가격 변동과 캐시 저장소도 지켜봐야 한다. 논문도 외부 업체의 안정성·지연·데이터 품질에 기대야 하고, 가격이나 속도 제한이 바뀌면 비용과 정확도의 균형이 흔들릴 수 있다고 한계로 적었다. 캐시에 결과를 쌓을 생각이라면 업체 약관이 저장을 허용하는지도 확인해야 한다. 논문은 업체가 허용한 콘텐츠만 캐시한다고 적었다.

07 할 일: 검색 호출부터 세고, 작업 하나에서 시험한다

1. 지금 검색에 드는 돈을 쿼리 단위로 뽑는다. Claude API 라면 응답의 usage.server_tool_use.web_search_requests 를 모으면 된다.

{
  "usage": {
    "input_tokens": 105,
    "output_tokens": 6039,
    "server_tool_use": { "web_search_requests": 1 }
  }
}

2. 작업을 최신성 기준으로 나눈다. 뉴스·가격·재고처럼 어제 답이 오늘 틀리는 작업은 내장 검색에 남긴다.
3. 출력 형식이 엄격한 작업 하나를 고른다. 장황함 문제가 가장 먼저 드러나는 곳이다.
4. 같은 평가셋에서 검색 없음·내장 검색·외부 검색 API 세 구성을 비교한다. QIU 처럼 검색 없이도 90%를 넘는 작업이라면 검색으로 얻는 몫부터 확인한다.
5. 결과 수는 4~6개로 시작해 정확도가 더 오르지 않는 지점을 찾는다.
6. 캐시는 정확 일치부터 붙인다. 의미 캐시 임계값과 TTL 은 논문에 값이 없으니 자기 데이터로 정한다.
7. 업체 하나가 멈출 때를 대비해 시간 초과 값과 두 번째 업체를 정해 둔다.

작은 팀이라면 DSG 를 통째로 따라 지을 필요는 없다. 외부 검색 API 하나를 도구로 붙여 한 작업에서 정확도와 요금을 재 보고, 그 차이가 청구서에서 보일 만큼 크면 그때 캐시와 대체 업체를 더하면 된다. 이 순서가 되돌리기도 쉽다.

08 자주 묻는 질문

청구서 전체로는 얼마나 줄어드나?

논문에는 그 값이 없다. 검색 업체 요금끼리만 비교했으므로, 지금 청구서에서 검색 요금이 차지하는 몫이 줄일 수 있는 최대치다.

캐시 적중률은 얼마로 잡고 계산하나?

실서비스 쪽 참고값은 QIU 의 14.9%(Retail)·1.73%(Tail)다. 99.4%는 같은 질문을 되풀이한 상한이라 비용 추정의 기준으로 쓰기 어렵다.

DSG 를 내려받아 바로 쓸 수 있나?

아니오, 이번에 확인한 출처 기준으로는 그렇다. 논문이 공개 대상으로 밝힌 것은 벤치마크 출력과 집계 표이고, 의미 캐시 임계값·TTL 값도 없어 직접 정해야 한다.