검색형 AI 에이전트를 만들 때 거의 모두가 하는 실수가 있다. 메인 에이전트도 최신 대형 모델, 검색 서브도 같은 대형 모델. "둘 다 비싸니까 성능이 좋겠지"라는 직관이다. 2026년 7월 논문 Think Big, Search Small은 이 직관을 통제 실험으로 정면 반박한다. 결론이 제목에 다 있다. 생각(위임)은 크게, 검색(실행)은 작게.
원문: arXiv:2607.07548
문제: 용량을 어디에 써야 하나
계층형 검색 에이전트는 보통 이렇게 돈다. 메인이 복잡한 질문을 작은 서브쿼리로 쪼개고, 서브들이 각자 검색해서 보고서를 올린다. 그런데 예산(모델 크기)은 한정돼 있다. 메인에 몰까, 서브에 몰까? 아무도 진지하게 안 따져봤다는 게 이 논문의 출발점이다.
일상 비유로: 리서치 팀에 시니어 한 명 몫의 예산이 있다. 팀장을 시니어로 앉힐까, 조사원 중 한 명을 시니어로 앉힐까? 대부분 "조사를 잘해야지"라며 조사원에 투자한다. 논문의 답은 반대다.
실험 설계: 역할을 3개로 분해
깨끗한 비교를 위해 검색을 세 역할로 쪼개고, 답변기는 고정해 교란 변수를 없앴다.
- 위임(Delegation, 메인): 질문 q를 원자적 서브쿼리로 분해 → 보고서 통합 → 언제 멈출지 결정. 최종 답은 안 씀.
- 실행(Execution, 서브): 서브쿼리 하나만 들고 새 컨텍스트에서 ReAct 검색 루프(최대 K턴). 검색 문서에 근거한 짧은 보고서만 반환.
- 답변(Answer): 고정(Qwen3-32B). 질문 + (서브쿼리, 보고서) 묶음만 본다. 메인의 사고 과정도, 서브의 검색 문서도 안 본다.
답변기를 고정했기 때문에, 성능 차이는 오직 "위임 자리와 실행 자리에 어떤 모델을 넣었나"에서만 온다. 검색은 Qwen3-Embedding-8B가 담당한다. 5개 멀티홉 QA 벤치에서 각 설정을 4번 돌려 평균(mean@4)냈다.
발견 1: 나누기만 해도 이득
같은 모델을 (A) 혼자 다 하게 vs (B) 메인-서브로 나눠 쓰게 비교했다. 6개 모델 크기 전부에서 분리가 이겼다.
| 모델 | 단일 (EM/F1/Judge) | 메인-서브 (EM/F1/Judge) |
| Qwen3-1.7B | 20.24 / 28.38 / 32.64 | 27.86 / 37.54 / 41.50 |
| Qwen3-4B | 21.85 / 29.65 / 32.04 | 27.32 / 36.12 / 40.41 |
Qwen3-1.7B는 Judge 기준 32.64 → 41.50(+8.86). 같은 모델인데 역할만 나눴을 뿐이다. EM 기준 전체 4.5~8.6점 상승. 컨텍스트를 한 통에 다 담아 혼자 처리하는 것보다, 위임/실행을 나누면 각자 집중이 되기 때문이다.
발견 2: 키울 곳은 메인 (핵심)
이제 한쪽씩 모델을 키워봤다.
- 위임(메인) 모델을 키움 → EM 약 +11점
- 실행(서브) 모델을 키움 → EM 약 +2.6점
약 4배 차이다. 성능의 천장은 "검색 모델이 얼마나 똑똑한가"가 아니라 "질문을 얼마나 잘 쪼갰는가"가 결정한다. 논문 표현으로 분해 품질이 병목이다. 조사원을 아무리 업그레이드해도, 팀장이 엉뚱한 걸 조사시키면 소용없다.
발견 3: 작은 실행기도 훈련하면 프론티어급
그럼 서브는 그냥 싼 걸 쓰면 정확도가 떨어지지 않을까? 논문은 품질 필터 궤적 증류로 1.7B 실행기를 학습시켰다. 결과: 프론티어 서브와 정확도는 비슷한데 서브 토큰을 37% 덜 썼다. 게다가 서로 다른 두 백본에서 모두 통했다(일반화).
즉 "서브도 프론티어여야 한다"는 기본값이 틀렸다. 작게 만들고, 필요하면 살짝 훈련해서 Pareto 전선을 앞으로 민다.
그래서 비용은 이렇게 설계한다
| 자리 | 추천 | 근거 |
| 메인 / 위임 | 큰 모델 | 분해 품질이 성능 천장 (+11pt) |
| 검색 / 실행 서브 | 작거나 중간 | 스케일 이득 작음 (+2.6pt) |
| 최종 답변 | 목적 맞게 | 글 품질 중요하면 별도 강화 |
이건 Cursor 스웜(Planner 비싸게, Worker 싸게)과 정확히 같은 결론이다. SuperGrok Heavy를 "무조건" 올리기 전에, 지금 병목이 한도인지 질문 분해 품질인지 먼저 나눠 봐야 하는 이유이기도 하다.
내일 당장 할 진단
- 에이전트 실패 로그를 두 통으로 나눠라: "검색을 잘못했다" vs "질문을 잘못 쪼갰다".
- 후자가 많으면 → 메인(플래너) 모델을 한 단계 올려라.
- 전자가 많으면 → 서브 프롬프트·도구를 고쳐라. 모델을 키우는 건 나중.
- 서브 프롬프트에 고정: "메인 전체 대화 넣지 말 것 / 이 서브쿼리만 / 근거 문장 포함".
- opencodex를 쓰면 메인만 Sol급, 서브 후보엔 저가 모델을 넣어 A/B.
한계
- 멀티홉 검색/QA 중심 실험. 대규모 코드 리팩터·UI 구현에 그대로 적용된다고 보긴 어렵다.
- 답변 모델을 고정해 비교했으므로, 전체를 한 모델로 end-to-end 최적화한 제품과는 결과가 다를 수 있다.
- 벤치·LLM judge 설정에 의존.
참고: arXiv:2607.07548 · GitHub · 관련: Cursor 비용
댓글