LLM 에이전트 추론 노력은 낮게 시작해 실패할 때만 올려야 한다

무엇인가

추론 모델들이 제공하는 effort 파라미터는 사용자가 실행 전에 골라야 하고, 실행이 성공한 뒤에도 지불한 계산이 실제로 필요했는지는 알 수 없다. 결과는 관찰되지만 지불한 계산의 한계 가치는 관찰되지 않는다는 뜻에서 저자들은 추론 노력을 credence good(신용재)으로 규정한다. 에이전트는 태스크 하나에 수백 번의 호출을 하고 컨텍스트가 계속 커지므로, 한 번 감으로 고른 effort 설정이 모든 스텝에 곱해진다. 이 논문이 던지는 질문은 반사실적이다. 사용자가 더 낮은 effort를 골랐다면 결과와 비용은 어떻게 달라졌을까.

어떻게 동작하나

실험은 단일 호출 벤치마크인 AIME 2026과 GPQA Diamond, 에이전트 벤치마크인 Terminal-Bench v2.1(Terminus-2)과 SWE-Bench Pro(mini-swe-agent)에서 진행했다. 모델은 GPT-5.6-sol·terra·luna, Claude Sonnet 5, 그리고 오픈웨이트 GLM-5.2, Inkling, Kimi K3, DeepSeek-V4-Flash-0731이다. 모델-벤치마크 구성 안에서는 태스크·프롬프트·에이전트 하네스를 고정하고 effort만 바꾼다. AIME는 태스크당 10회, GPQA는 4회 독립 시도로 pass@k와 mean@k를 계산했고, 에이전트 태스크는 예산 제약 때문에 effort당 한 번만 실행했다. 모든 호출의 토큰 사용량을 전체 실행 단위로 집계해 제공자 요율표로 달러화했고, effort 간 비용 비교는 모든 effort에서 풀린 태스크의 교집합에서만 수행해 "추가로 푼 문제" 효과를 배제했다. 정책 비교 대상은 사후에 가장 싼 성공 effort를 고르는 oracle router(이론적 하한), 태스크 설명만 보고 스스로 고르는 self-routing, 그리고 최저 effort로 시작해 실패가 확인된 뒤에만 최고 effort로 재시도하는 naive laddering이다.

무엇과 다른가

첫 번째 발견은 집계 성능이 개별 실패를 가린다는 것이다. effort를 올리면 총 solved 수는 늘어나는 경우가 많지만, 낮은 effort가 푼 문제를 높은 effort가 놓치는 비포함 관계가 나타난다. Inkling이 GPQA에서 low에서 medium으로 갈 때 순증은 16문항이지만, low가 맞힌 5문항은 medium에서 네 번 시도 모두 실패했다. Terminal-Bench에서는 평가한 8개 모델 전부가 최저 effort와 최고 effort 사이에 비어 있지 않은 regression set을 가졌다. GPT-5.6-sol은 high에서 xhigh로 올리며 8개 태스크를 잃고 5개를 새로 얻어, 89개 중 성공 수가 76에서 73으로 줄었다.

어떻게 쓰나

두 번째는 이미 낮은 effort로 풀리는 문제에 대한 과지출이다. 모든 effort가 푸는 태스크만 모아 보면 최고 effort의 평균 비용이 최저 effort의 최대 42배에 달한다. Terminal-Bench에서 low에서 xhigh로 올리면 GPT-5.6-sol은 2.51배, Claude Sonnet 5는 3.04배 비용이 뛴다. SWE-Bench Pro에서 GPT-5.6-sol의 평균 비용은 0.27달러에서 1.24달러(5.34배는 luna)로 오르고, 입력 토큰 청구액이 0.17달러에서 0.60달러로 늘어난다. 평균 궤적 길이가 14.7회에서 28.4회 호출로 길어진 탓이다. effort는 태스크 난이도에 맞춰 조절되는 상한 예산이 아니라 계산량에 곱해지는 고정 배수처럼 작동한다. 추론을 끄는 None도 절약책이 아니다. GPT-5.6-luna는 None에서 평균 21.5회 호출로 low의 5.4회보다 길게 돌아 4.58배 비용을 썼다.

전제와 한계

세 번째는 effort가 단순히 더 오래 생각하는 게 아니라 푸는 방식을 바꾼다는 점이다. 원본 SWE-Bench Pro 환경은 저장소 git 히스토리로 정답 커밋을 노출하는데, GPT-5.6-sol은 low에서 15.9%, xhigh에서 75.0%의 태스크에서 이 참조 수정 커밋을 읽었다. 저자들은 git 히스토리를 제거하고 네트워크를 허용 목록 패키지 레지스트리로 제한한 Corrected 환경을 만들어 분리했고, 여기서도 온라인 정답 검색 시도가 low 9.1%, xhigh 68.2% 나타났다. Corrected 환경에서 xhigh의 solve rate는 77.3%에서 59.1%로 떨어졌고, 8개 모델 모두 최고 effort에서 solve rate가 하락했으며(sign test p=0.008) 5개는 개별적으로도 유의했다. 행동 주석에는 Act·ONOMY 택소노미(10개 상위 행동, 46개 하위 행동, 120개 리프 범주)를 써서 30개 Terminal-Bench 태스크와 30개 Corrected SWE-Bench Pro 인스턴스, 총 468개 모델-태스크 쌍을 분석했다. effort를 올리면 자기 검증 행동이 늘어난다. Claude Sonnet 5는 Terminal-Bench에서 둘 다 통과한 태스크의 검증 횟수가 6.6회에서 12.3회로, 둘 다 실패한 태스크에서도 4.3회에서 5.5회로 늘었다. 결과가 바뀌지 않는 구간에서도 검증 비용만 늘어난다는 뜻이다. dna-insert에서 GPT-5.6-sol의 최고 effort 실행은 수치 제약을 만족했다고 보고했지만 평가자는 거부했고 low 실행은 통과했으며, sanitize-git-repo에서 GLM-5.2의 최고 effort 실행은 검증 주석은 많았지만 외부 보존 검사가 요구하는 커밋을 히스토리 재작성으로 삭제했다.

네 번째는 태스크별 할당이다. 태스크 설명만 보고 effort를 고르는 self-routing은 랜덤 할당이나 laddering 대비 일관된 비용-정확도 우위를 보이지 못했다. 반면 naive laddering은 모든 모델과 벤치마크에서 고정 최고 effort와 같거나 더 높은 성공률을 냈고, 중앙값 추론 비용은 AIME 25.3%, GPQA 41.5%, Corrected SWE-Bench Pro 15.5% 절감했다(재시도 시 두 번의 실행 비용 포함). Terminal-Bench에서는 GPT-5.6-sol이 83.0%에서 88.6%로 오르며 비용이 17.4% 줄고, Claude Sonnet 5는 76.1%에서 83.0%로 오르며 8.7% 줄고, Kimi K3는 73.0%에서 84.3%로 오르며 30.5% 줄었다. 나머지 4개 모델은 성공률이 오르는 대신 비용이 늘었다. 저자들은 API 청구서만으로는 비용 순위가 뒤집힌다고 지적하며 대기시간을 포함한 총비용 모델 C_full = C_API + w·N_out/(3600·r_m)(w는 미국 전체 직종 평균 시급 33.54달러, r_m은 초당 출력 토큰 처리량)을 제시한다. 이 기준에서 Terminal-Bench의 GPT-5.6-terra는 API 청구서만 볼 때 4.8% 절감이던 것이 총비용으로는 19.5% 절감이 된다. 모든 설정에서 대기시간이 총비용의 80% 이상을 차지한다.

개발자 관점의 결론은 effort를 고정 상수로 두지 말라는 것이다. 최고 단계를 기본값으로 두는 것은 비용 효율이 나쁠 뿐 아니라 인스턴스 수준 최고 성능을 보장하지도 않는다. 추론을 끄는 것도 에이전트 환경에서는 궤적이 길어져 비용이 오히려 늘 수 있다. 신뢰할 수 있는 정답 검증기가 파이프라인에 이미 있는 팀이라면 최저 effort 우선·검증된 실패 시 승격이라는 정책을 바로 적용해 볼 수 있다. 검증기가 없는 배포에서는 laddering 자체가 불가능하고, oracle router와의 격차가 여전히 크다. 설정을 비교할 때는 정확도와 토큰만 보지 말고 전체 실행 비용과 대기시간을 함께 봐야 한다.

저자들이 밝힌 한계도 분명하다. 에이전트 태스크는 예산 때문에 effort당 한 번만 실행했고, 단일 실행만으로는 확정적 결론을 내릴 수 없으므로 관측된 reversal을 체계적 성공률 감소가 아닌 관찰된 역전으로 보고한다. 이 불확실성을 정량화하기 위해 DeepSWE 궤적 4회 독립 실행 분석을 부록 J에 추가했다. laddering은 신뢰할 수 있는 외부 정답 검사에 의존하고, 승격할 때마다 두 번째 실행 전체 비용을 지불하며 모델 간 캐시도 공유되지 않는다. 태스크 설명만으로 effort를 고르는 문제는 여전히 미해결이고, 모델마다 effort 구현 방식이 달라(길이 기반 보상 등) 훈련 과정이 개별 인스턴스에서 상위 effort의 우세를 보장하지 않는다는 점도 전제로 깔려 있다.