스텝마다 얼마나 생각할지 고르기 — Ares의 적응형 추론 노력 라우팅

들어가며 — 추론 노력이라는 비용 레버
스텝마다 노력을 고르는 라우터
숫자, 그리고 그 숫자를 읽는 법
솔직한 트레이드오프 — 라우터 오버헤드와 과소 사고
마치며 — 오늘 쓸 수 있는 아이디어
참고 자료

들어가며 — 추론 노력이라는 비용 레버

생각하는 LLM(thinking LLM)으로 만든 에이전트는 긴 사고 사슬(chain-of-thought)로 높은 정확도를 얻지만, 그 대가로 추론 비용이 크게 붙습니다. 요즘 모델 상당수는 추론 레벨을 high·medium·low처럼 설정할 수 있게 열어 두었는데, 진짜 문제는 이 레버를 어떻게 당길지입니다.

Ares 논문(2026년 3월 프리프린트)의 관찰은 단순하지만 설득력 있습니다. 고정 전략은 잘 안 통한다는 것. 모든 스텝을 low로 돌리면 성능이 눈에 띄게 떨어지고, 레벨을 무작위로 섞으면 정확도도 못 지키고 비용도 의미 있게 못 줄입니다. 더 정확한 그림은 이렇습니다 — 복잡한 웹사이트 구조를 헤쳐 나가는 스텝에는 높은 노력이 필요하지만, 목표 URL을 여는 것 같은 단순한 스텝은 낮은 노력으로 충분합니다. 즉 노력은 태스크 단위가 아니라 스텝 단위로 배분되어야 합니다.

스텝마다 노력을 고르는 라우터

Ares(Adaptive Reasoning Effort Selection)의 핵심은 가벼운 라우터 하나입니다. 매 스텝마다, 지금까지의 상호작용 이력을 보고 그 스텝에 필요한 가장 낮은 적절한 추론 레벨을 예측합니다. 요지는 "이 스텝이 어려운가?"를 미리 값싸게 판단해, 어려울 때만 비싼 사고를 켜는 것입니다.

라우터는 어떻게 학습시키나. 논문은 데이터 생성 파이프라인으로 각 스텝이 성공하는 데 필요한 최소 추론 노력을 찾아내고, 그 라벨로 라우터를 파인튜닝합니다. 결과물은 특정 모델에 종속되지 않는 플러그앤플레이 방식이라, 기존 LLM 앞단에 끼워 넣는 형태로 설계됐습니다.

동작을 개념적으로 그리면 이렇습니다.

매 LLM 호출 직전에:
  1. 지금까지의 상호작용 이력을 라우터에 넘긴다
  2. 라우터가 이 스텝의 최소 추론 레벨을 예측한다   (high / medium / low)
  3. 예측된 레벨로 본체 모델을 호출한다
  4. 도구 결과를 이력에 더하고 다음 스텝으로

포인트는 라우터가 본체 모델보다 훨씬 싸고, 판단이 스텝 단위라는 점입니다. 한 태스크 안에서도 스텝마다 노력이 오르내립니다.

숫자, 그리고 그 숫자를 읽는 법

논문이 보고하는 수치부터. 세 벤치마크 — 도구 사용 에이전트용 TAU-Bench, 딥리서치 에이전트용 BrowseComp-Plus, 웹 에이전트용 WebArena — 에서, 항상 high로 돌리는 고정 전략 대비 추론 토큰을 최대 52.7%까지 줄였다고 합니다. 그러면서 태스크 성공률 저하는 미미했다고 보고합니다.

읽는 법. 두 가지를 분명히 해 둡니다. 첫째, 이건 저자들이 보고한 프리프린트 수치이며 독립적으로 검증되지 않았습니다. 둘째, "최대(up to)"는 상한값입니다 — 벤치마크마다 다를 수 있고, 모든 상황의 평균이 아니라 가장 잘 나온 조건의 수치로 읽는 편이 안전합니다. 그래도 방향성은 분명합니다. 대부분의 에이전트 스텝은 최대 사고를 필요로 하지 않는다는 것.

솔직한 트레이드오프 — 라우터 오버헤드와 과소 사고

공짜 점심은 없습니다. 이 접근의 대가를 정직하게 적습니다.

라우터 자체가 비용이다. 라우터는 매 스텝 돕니다. 절약분을 갉아먹지 않을 만큼 충분히 가벼워야 합니다. 아낀 사고 토큰보다 라우터 호출이 비싸면 의미가 없습니다.
과소 사고(under-thinking) 리스크. 라우터가 어려운 스텝을 쉽다고 오판해 너무 낮은 레벨을 고르면 그 스텝은 실패합니다. 그리고 에이전트에서 한 스텝의 실패는 종종 전체 궤적을 망치거나 재시도를 부릅니다 — 아낀 사고보다 더 비싼 값을 치를 수 있습니다. 그래서 실무에서는 라우터를 "많이 생각하는 쪽"으로 살짝 편향시키는 보정이 대체로 안전합니다.
분포 이동(distribution shift). 라우터는 특정 에이전트·태스크 분포에서 학습됩니다. 다른 도메인의 에이전트에 그대로 옮기면 판단이 어긋날 수 있습니다. 옮길 때마다 다시 재보는 게 맞습니다.
정확도-비용 곡선을 직접 재라. "최대 52.7%"가 당신 워크로드에서 재현된다는 보장은 없습니다. 당신의 태스크에서 성공률과 토큰을 함께 측정해, 절약이 정확도 손실을 정당화하는지 스스로 확인해야 합니다.

마치며 — 오늘 쓸 수 있는 아이디어

Ares가 매력적인 이유는 특정 라우터 구현이 아니라 원리입니다. 추론 노력을 태스크 전체에 균일하게 걸지 말고, 스텝 단위로 필요한 만큼만 배분하라는 것. 이 아이디어는 완성된 라우터 가중치가 없어도 오늘 당장 근사할 수 있습니다 — 스텝 종류(단순 조회 대 복잡한 계획)에 따라 휴리스틱으로 레벨을 정하거나, 실패했을 때만 노력을 올리는 폴백을 두는 식으로요.

물론 이건 아직 프리프린트이고, 수치는 저자 보고치입니다. 하지만 "모든 스텝을 최대로 생각하게 하는 것은 낭비"라는 명제는 직관적으로도, 비용 청구서로도 맞는 말입니다. 에이전트를 운영하는 사람이라면 추론 노력을 하나의 튜닝 가능한 레버로 보기 시작할 이유가 충분합니다.