복잡한 리서치를 AI에게 통째로 맡기려 할 때, 가장 먼저 정해야 하는 게 있다. 계획을 어디까지 미리 짜 둘 것인가.
여기서 딥리서치란 수십에서 수백 개의 출처를 넘나들며 증거를 모아 복잡한 질문을 푸는 AI 작업을 말한다. 최근 공개된 딥리서치 에이전트 DAGent의 답은 뜻밖이었다. 미리 다 짜지 않는다. 전체 계획을 처음에 확정하는 대신, 방금 끝낸 작업이 얼마나 확실한지, 무엇이 아직 불확실한지를 확인한 뒤에야 다음 할 일을 덧붙인다. 이 방식에 저자들은 Evaluate-then-Grow, 곧 '평가하고 나서 키운다'는 이름을 붙였다.
결과부터 말하자. 같은 모델과 같은 도구로 조건을 똑같이 맞춰 기존 방식과 맞붙였을 때, DAGent는 정확도가 더 높으면서도 과제 하나를 푸는 데 쓴 토큰과 도구 호출, 단계 수는 더 적었다. 보통 이 둘은 맞바꾼다. 정확도를 올리려면 계산을 더 쏟아야 하고, 아끼려면 정확도를 내준다. DAGent는 둘을 함께 가져갔다.
딥리서치는 평범한 검색과 다르다. 질문 하나를 놓고 출처 수백 개를 뒤져야 한다. 이런 일에는 작업을 잘게 쪼갠 뒤 '이게 끝나야 저걸 한다'는 선후 관계로 엮는 방식이 잘 맞는다. 이렇게 짠 작업 지도를 DAG라 부른다. 화살표가 한 방향으로만 흐르고 되돌아오지 않는 그래프라는 뜻이다. 서로 기대지 않는 가지는 동시에 돌릴 수 있고, 각 작업자는 전체 이력이 아니라 자기가 딛고 선 작업들만 들여다보면 된다. 여기까지는 이미 자리 잡은 설계다.
갈리는 지점은 '계획을 언제 정하느냐'다. 기존 DAG 에이전트는 대개 일을 시작하기 전에 과제 전체를 덮는 계획을 한 번에 세운다. 그리고 실행 도중 실패나 증거 부족이 드러나면 그제야 그래프를 고친다. 논문은 이 패턴을 Plan-then-Patch, '먼저 계획하고 나중에 땜질한다'고 부른다.
여기 구조적인 함정이 있다. 시스템은 문제를 가장 모를 때, 손에 쥔 증거가 가장 빈약한 그 순간에 가장 큰 계획을 확정한다.
산에 빗대면 분명해진다. 정상까지 가는 길 전체를 출발 전에 지도에 다 그려 놓고, 오르다 길이 막힐 때마다 지웠다 다시 그리는 것이 Plan-then-Patch다. 시야가 가장 안 트인 산 아래에서 가장 많은 선을 긋는 셈이다. Evaluate-then-Grow는 순서를 뒤집는다. 한 구간을 올라 시야가 트인 곳에서, 그제야 다음 구간만 정한다.
이렇게 DAGent는 '시작할 때 모든 것을 확정해야 한다'는 기존의 전제를 깼다. 완료된 하위 작업의 결과와 근거, 신뢰도 요약에 각 계획 결정을 묶은 첫 딥리서치 에이전트라는 게 저자들의 설명이다.
무엇을 이겼는지부터 정확히 하자. DAGent는 한 강자를 이긴 게 아니다. 세 벤치마크는 성격이 저마다 달라서, 1위를 지키던 방식도 벤치마크마다 달랐다. DAGent는 그 서로 다른 1위를 세 곳 모두에서 앞섰다. 학습을 전혀 붙이지 않고, 가장 큰 기반 모델을 올린 설정에서다. 여기서 기반 모델이란 에이전트의 두뇌 역할을 하는 LLM(대규모 언어모델)으로, 백본이라고도 부른다. 점수는 Pass@1, 한 번 실행해 정답을 맞히는지 보는 '첫 시도 합격률'의 평균이다.
| 벤치마크 | 그 벤치마크의 기존 1위 | DAGent | 차이 |
|---|---|---|---|
| BrowseComp-Plus | 56.0 (이력 요약 방식) | 61.3 | +5.3 |
| GAIA | 57.3 (맥락 창 109K ReAct) | 63.1 | +5.8 |
| xbench-DeepSearch | 70.0 (Flash-Searcher) | 72.0 | +2.0 |
(학습 없음 · 백본 Qwen3-235B-A22B · 모두 Pass@1 평균)
괄호 안은 각 벤치마크에서 1위였던 기존 방식의 이름이니, 낯설어도 그냥 넘어가도 된다. 참고로 '맥락 창'은 AI가 한 번에 머릿속에 담아 두고 보는 글의 양을 말한다.
한 모델에서 어쩌다 나온 결과도 아니다. Qwen3-8B부터 235B까지 규모를 가로질러, 네 개 벤더의 오픈소스 기반 모델에서도 같은 패턴이 반복됐다. 여기에 GPT-5를 맥락 327K까지 키운 설정으로 비교했을 때도, 최신 에이전트 시스템들과 겨룰 만했다.
학습을 붙이면 격차가 더 벌어진다. Qwen3-8B에 DAGRPO라는 강화학습을 적용하자, 같은 계산 예산을 쓴 '결과만 보는' 기존 강화학습보다 평균 Pass@1이 3.0점 올랐다. 다만 이 이득이 설정값과 무관한 것은 아니다. 핵심 설정값 하나(논문에서 α)를 바꿔 가며 돌린 민감도 분석 — 설정을 흔들었을 때 성능이 어떻게 달라지는지 보는 검사 — 을 보면, α를 0.25·0.75로 두었을 때 평균 성능이 최적 설정보다 각각 1.2점·1.4점 낮았고, α를 0으로 두자 '결과만 보는' 기존 강화학습 기준선보다도 낮아졌다. 이득을 제대로 누리려면 이 설정값을 적절히 맞춰야 한다는 뜻이다. (표 3) (DAGRPO가 무엇인지는 뒤에서 따로 본다.)
비용 이야기는 가장 깨끗한 비교에서 또렷하게 드러난다. 다른 조건은 전부 그대로 두고, 계획 방식만 Evaluate-then-Grow와 Plan-then-Patch로 바꿔 맞붙이는 실험이다. 모델도 도구도 구조도 똑같으니, 차이가 난다면 그건 계획 방식 때문이다. 결과는 분명했다. 증거를 보고 넓히는 쪽이 과제당 토큰과 도구 호출, 단계를 더 적게 쓰고도 정확도가 높았다. 그 폭은 부록 표 10에 수치로 박혀 있다. BrowseComp-Plus에서 Plan-then-Patch 대비 DAGent는 토큰을 168만에서 120만으로, 도구 호출을 87.9회에서 67.6회로, 단계를 54.8에서 42.7로 줄였다. 변수를 단 하나로 묶은 이 비교는 '더 정확하면서 더 싸다'는 주장의 가장 강력한 증거다.
실험 자체는 꼼꼼하다. Qwen3 세 종에 다른 벤더 셋, 그리고 GPT-5까지 일곱 종의 기반 모델과 세 벤치마크를 넘나들고, 모든 방법이 같은 검색 백엔드 — 실제로 자료를 찾아오는 검색 엔진·도구 — 를 공유하도록 조건을 고정했다. 세부 설계는 원문에 있다.
그러면 '증거를 보고 키운다'를 기계는 어떻게 해내는가. 작동 원리는 역할 분리 하나로 요약된다. '지휘자'와 '작업자'를 나누고, 둘 사이에 분명한 신호가 흐르게 한 것이다.
지휘자(Orchestrator)는 지금까지 끝난 작업을 보고 그래프에 다음 작업 묶음, 곧 한 배치를 덧붙인다. 작업자(ReAct Executor)는 '생각하고, 도구를 쓰고, 결과를 본다'를 반복하는 실행 에이전트다. 새로 붙은 작업들은 서로 기대지 않는 한 나란히 돌아간다.
핵심은 작업자가 지휘자에게 무엇을 넘기느냐에 있다. 작업 하나가 끝나면 두 벌의 기록이 남는다. 하나는 실행 과정을 통째로 담은 상세 기록이고, 다른 하나는 그걸 한 장으로 압축한 요약 카드, 이름하여 QueryDoc다.
이 카드에는 다섯 가지가 담긴다. 하위 작업의 답, 그 답에 대한 짧은 설명, 핵심 실행 단계 요약 — 여기까지가 '무엇을 알아냈나'다. 그리고 실행자가 스스로 매긴 확신도, 아직 더 확인해야 할 불확실성 목록 — 이 둘이 '그게 얼마나 믿을 만하고, 무엇이 더 궁금한가'다. 작업자는 답만 툭 던지지 않는다. 자기가 낸 결과에 스스로 점수를 매겨 함께 올린다. 그래서 지휘자가 들여다보는 것은 길고 긴 실행 과정 전체가 아니라, 답과 그 신뢰도까지 한 장에 담은 이 요약 카드다.
바로 이 카드가 다음 수를 정한다. 지휘자는 방금 끝난 배치의 작업마다 상태를 붙인다. 확실한 증거를 잡았으면 Success, 더 검증이 필요하면 Uncertain, 멀쩡히 돌았지만 쓸 증거가 없으면 Not Found. Uncertain이나 Not Found가 붙은 작업은 다른 검색 전략으로 같은 일을 다시 해 보는 refine 작업을 낳는다. 단, 한 줄기당 세 번까지다. 처음 한 번에 보강 두 번, 거기서 끊어 무한 재시도를 막는다. 그렇게 넓혀 가다가 지휘자가 흩어진 증거를 모아 최종 답을 짜는 answer 작업을 세우면 끝이다. 이 작업은 반드시 자기 배치에 혼자 있어야 한다. 그래야 위에서 내려온 증거 전부에 닿아 답을 지을 수 있다.
긴 리서치에서 실행 기록은 끝없이 길어진다. 그런데 아래쪽 작업이 필요로 하는 건 보통 위쪽의 '결론'뿐이다. 그래서 기본적으로는 요약 카드만 다음 작업으로 넘긴다. 각 작업은 자기가 직접 딛고 선 작업들의 요약만 받는다. 논문은 이를 선별 전파라 부른다. 덕분에 한 작업이 짊어지는 맥락의 크기는 '그래프 전체'가 아니라 '나한테 직접 들어오는 선후 관계의 수'로만 묶인다. 요약으로 모자랄 때 — 원문의 정확한 표현이 필요한 경우처럼 — 만 작업자가 상세 기록에서 필요한 조각을 꺼내 온다. 어디까지나 예외다.
이 모두를 떠받치는 성질이 하나 있다. append-only, 한 번 붙인 작업은 지우지도 다시 잇지도 않고 쌓기만 한다는 규칙이다. 그래서 '어떤 작업이 실행될 때 실제로 봤던 맥락'이 '완성된 그래프에서 그 작업보다 위에 놓인 작업들'과 정확히 일치한다. 사소해 보이는 이 성질이 바로 다음 이야기의 열쇠가 된다.
DAGent를 한 단계 더 끌어올리는 장치가 DAGRPO다. 출발점은 상식적인 불만 하나다. 하나의 그래프 안에서도 어떤 실행은 최종 답으로 이어진 핵심 경로 위에 있고, 어떤 실행은 끝내 쓰이지 않은 막다른 탐색이다. 그런데 기존 강화학습은 이 둘을 구분하지 않는다. 여기서 기존 방식이란 GRPO로, 같은 문제를 여러 번 실행해 본 뒤 평균보다 잘한 쪽에 힘을 실어 주는 방법이다. 이 방식은 최종 성공 여부만 본다.
문제는 학습 신호가 뭉개진다는 데 있다. 정답에 이른 실행이든 한참 헤매다 버려진 실행이든 똑같은 점수를 받으면, 모델은 '어떤 선택이 실제로 답에 보탬이 됐는지'를 끝내 가려낼 수 없다.
DAGRPO가 하는 일이 이 점을 바로잡는 것이다. 최종 답과, 거기까지 실제로 이어진 모든 윗작업을 묶어 '답에 기여한 집합'으로 본다. 이 집합 안에서 일한 작업자는 보상을 온전히 받고, 집합 바깥에서 헛돈 작업자는 보상이 깎인다. 만약 답으로 이어진 사슬이 아예 안 만들어졌다면 깎지 않고 원래 방식으로 되돌아간다. 억지로 벌주지는 않는다.
이 기여도 추적이 가능한 건 오직 앞서 말한 append-only 덕분이다. '답에 기여한 집합'은 다시 실행해 볼 것도 없이, 쌓이기만 한 그래프 구조를 거슬러 읽기만 하면 그대로 나온다. 계획을 세웠다 지웠다 다시 잇는 Plan-then-Patch에서는 최종 구조와 실제로 참고한 내용이 어긋날 수 있어, 이런 신호를 애초에 정의할 수조차 없다. 말하자면 계획 방식의 선택이 학습 방식의 혁신을 공짜로 가져다준 셈이다.
이 방법이 만병통치약은 아니다. 저자들이 스스로 그어 둔 한계선이 오히려 솔직하다.
먼저 '답에 기여한 집합'은 인과가 아니라 구조로 대신 재는 지표다. '최종 답으로 이어진 사슬 위에 있었다'는 사실이 '그 작업이 정답을 만들어 냈다'와 같은 말은 아니다. 방법 전체가 append-only라는 전제에 묶여 있다는 점도 짚어 둘 만하다. 그래프를 지우고 다시 잇는 설계로 넘어가는 순간, DAGRPO의 성과 배분 신호는 그대로 쓸 수 없다.
더 묵직한 건 따로 있다. 가장 어려운 문제는 여전히 대체로 안 풀린다. BrowseComp-Plus의 어려운 문제 묶음에서 DAGent의 점수는 Qwen3-8B 기준 6.0, 가장 큰 235B에서도 22.0에 그쳤다. 세 벤치마크를 가로지른 우위와는 별개로, 딥리서치의 진짜 난제는 아직 큰 숙제로 남아 있다는 신호다.
읽을 때 늘 염두에 둘 조건도 있다. 성적은 Pass@1과 LLM 심판에 기댄다. 한 번 돌려 맞혔는지만 보고, 정답 판정도 사람이 아니라 다른 LLM이 매긴다. 심판이 틀리면 점수도 틀린다. DAGRPO의 학습 이득은 Qwen3-8B 규모에서 확인됐을 뿐, 더 큰 모델에서도 유지되는지는 이 논문의 범위 밖이다. 벤치마크마다 검색 백엔드가 고정돼 있으니, 다른 도구 스택이나 다른 분야로 옮겼을 때의 일반화도 더 봐야 한다.
첨단 AI 에이전트가 계산을 아끼려고 찾아낸 이 규율은, 사실 우리가 일하는 방식에도 그대로 맞닿아 있다. 온틀에서 AI PM을 설계하며 우리가 부딪힌 지점이기도 하다.
장면 하나를 보자. 고객이 "경쟁사 대비 우리 가격과 리뷰 경쟁력을 분석해 달라"고 요청했다. 미리 다 짜는 PM이라면 접수 당일, 아직 아무것도 들여다보기 전에 조사 계획 전체를 못 박는다. 경쟁사 목록 확정, 가격 수집, 리뷰 분석, 종합까지. 그런데 막상 가격을 모으려니 경쟁사 둘이 가격을 비공개로 둔다. 그 아래 매달아 둔 '가격 비교' 가지가 통째로 헛계획이 되고, 지웠다 다시 그린다. 고객이 요청을 가장 모호하게 던진 바로 그 순간에, 계획을 가장 많이 확정해 둔 탓이다.
온틀에서 프로젝트를 하위 작업으로 잘게 쪼개 가지를 치는 방식이 바로 앞서 본 작업 그래프와 같다. 지금도 작업은 이렇게 가지 형태로 관리된다. 여기에 Evaluate-then-Grow의 순서를 얹는 것이 우리가 그리는 다음 그림이다. AI PM이 첫 배치로 '경쟁사 식별'과 '가격 공개 여부 확인'만 돌려 보고, 각 작업이 남긴 확신도·불확실성을 확인한 뒤에야 다음 배치를 짜는 식이다. "다섯 곳 중 셋은 가격 공개, 확신 높음. 나머지 둘은 추가 소스 필요, 불확실." 이 신호를 받고서야 다음 수를 정하고, '불확실'로 찍힌 곳이 오래 풀리지 않으면 온틀 고객 화면의 '결정 기다리는 중' 상태로 올려 사람의 판단을 부른다.
보고 방식도 같은 틀에서 나온다. '결론과 근거, 확신도, 아직 불확실한 것'으로 압축한 요약 카드는 그대로 AI PM이 고객에게 올리는 중간 보고의 모양이고, 상세 실행 기록은 "그 수치 출처가 정확히 뭐냐"는 물음이 올 때만 꺼낸다. 첨단 연구가 비용을 아끼려고 도달한 원리가, 좋은 PM이 늘 지켜 온 상식과 같은 곳에서 만나는 셈이다.
드물다. RecallTool은 요약 카드로 모자랄 때만 상세 기록을 꺼내 오는 예외 경로다. Qwen3-32B 실행 기준으로 BrowseComp-Plus·GAIA·xbench-DeepSearch에서 각각 전체 과제의 22.0 / 13.6 / 11.0%에서만 쓰였다.
두 가지를 갈라 봐야 한다. 본문 표의 '세 곳 모두 앞섰다'는 성적은 아예 학습을 붙이지 않은 설정이다. 한편 DAGRPO로 학습한 버전을 볼 때는, BrowseComp-Plus 한 곳에서만 학습한 체크포인트를 나머지 두 벤치마크에 그대로 가져와 평가했다. 이렇게 '그 과제로 따로 학습하지 않은 채 평가하는 것'을 제로샷이라 한다. 즉 벤치마크마다 새로 학습시킨 게 아니다.
저자들은 '답에 기여한 집합'이 다시 실행할 것 없이 기록된 그래프에서 읽히는 구조적 대리 지표이며, 학습 중 의존 관계를 부풀리는 방식으로는 악용되지 않는다고 부록에서 설명한다.
코드는 깃허브(github.com/hanwenliu6825/DAGent)에 공개돼 있다고 논문에 적혀 있다. 평가에 쓴 세 벤치마크는 BrowseComp-Plus·GAIA·xbench-DeepSearch다.