벨만 언어 모델이 LLM 에이전트의 반복 결정을 한 번에 푼다
Bellman Language Models: Solving the Recurring Decisions of LLM Agents
무엇인가
이 논문은 제한된(bounded) 에이전트 워크플로에서 LLM이 매 턴 같은 결정을 처음부터 다시 계산하는 문제를 다룬다. 결정과 텍스트 생성을 분리하면 결정 공간은 포화되어 같은 상태가 반복되는데, LLM은 이를 최적화 문제로 보지 않고 프롬프트와 문맥에서 매번 재도출한다. 저자들은 이 때문에 비용과 지연이 반복되고, Opus 5.5는 흔한 고장보다 드문 고장을 먼저 묻고 Qwen3.8-27B는 시도할 점검이 남았는데도 사람에게 넘기는 식으로 결정 품질도 흔들린다고 관찰한다. 참 확률을 아는 시뮬레이션 코딩 과제에서는 LLM이 추정한 확률로 최적화한 결정이 참 확률을 쓴 것과 비슷했지만, LLM이 직접 고른 결정은 더 나빴다고 보고한다.
어떻게 동작하나
제안 방법은 Discretize, Then Decide다. 워크플로 로그나 LLM 에이전트 실행을 메시지와 도구 결과에 대한 단순 규칙으로 이산 상태로 읽고, 각 이동의 결과 확률과 비용을 추정하며, 새 상태가 나타나지 않고 확률이 안정될 때까지 실행을 추가한다. 그다음 관측 상태 x, 숨은 상태 h, 믿음 b, 이동 비용 c(x,h,a), 관측 확률 P(o|x,h,a)로 정의되는 MDP 또는 POMDP를 최소 기대 비용으로 한 번 푼다. 해는 상태별 최적 이동을 담은 solved policy이며, 배포자가 비용 단위를 정한다. 텔레콤은 고객 턴, CI는 달러, InventoryBench는 판매 마진에서 보관 비용을 뺀 보상, SymPy는 과금 토큰이다. 실행 시 컨트롤러가 모든 메시지와 도구 결과를 상태로 읽고, 상태가 도구 호출이나 템플릿 응답을 고정하면 모델 없이 보내며, 보지 못한 상태나 규칙이 읽지 못한 턴만 LLM에 넘긴다. 이렇게 실행한 LLM을 리처드 벨만의 상태별 최적 이동 방정식에서 이름 붙인 Bellman language model(BLM)이라 부른다. 컨트롤러는 LLM이 점검이 남았는데 사람에게 넘기려 하면 이를 막고 최대 세 번 다시 요청한다. 정책을 제안만 하는 것이 아니라 실행하는 것이 중요하다는 근거로, SymPy에서 중단 제안을 했을 때 코딩 에이전트가 6.5%만 따랐다고 밝힌다.
무엇과 다른가
텔레콤 실험은 τ²-bench telecom에서 진행됐다. 모델이 전혀 없는 컨트롤러만으로 79%의 과제를 해결했다. Qwen3.8-27B는 단독 29%에서 BLM으로 96%까지 오르면서 모델 호출이 93% 줄었다. 단독으로 96%를 푸는 Claude Opus 5.5는 BLM으로 호출과 과제당 비용을 약 98% 줄였고 과제를 2개 더 풀었다. 학습 중 한 번도 보지 못한 고장이 있는 과제 세트에서는 Qwen3.8-27B를 BLM으로 돌릴 때 세 번 시도 모두 거의 모든 과제를 풀었지만, 단독일 때는 절반 미만이었다. Opus 대화로 Qwen을 파인튜닝하면 114개 중 31개에서 100개까지 오르지만 대화당 17.6회 모델을 호출해 BLM의 1.5회보다 훨씬 비싸다. Opus를 쓴 test set 3에서 BLM은 대화당 0.48달러를 아껴 0.012달러 대 0.49달러였고, 구축비 B는 B/0.48 대화 후 회수되어 100달러면 약 210회, 1000달러면 2100회가 기준이다.
어떻게 쓰나
다른 도메인은 방법이 통하는 경계를 보여준다. InventoryBench에서는 모델을 전혀 호출하지 않는 solved policy가 모든 공개 방법을 이겼다. Mozilla CI 실패 작업 분류에서는 일부 로그를 읽는 데만 LLM을 쓰며 근거가 더 약하고, 실패한 테스트를 한 번 다시 돌린 뒤 에스컬레이션하는 고정 규칙과 비용이 비슷했다. SymPy 이슈 해결처럼 어려운 부분이 이동 선택이 아니라 내용 작성인 경우에는 상태가 고정할 수 있는 결정이 적어 BLM의 도움이 작았다. 초안 컨트롤러를 로그에 재생해 상태가 고정할 수 있는 턴 비율을 보면 텔레콤에서는 Opus 턴의 거의 전부였지만 SymPy 에이전트에서는 작은 비율이었다. 에이전트 단독으로 대부분을 푸는 두 소매 벤치마크에서는 컨트롤러가 이득을 내지 못했다.
전제와 한계
개발자 관점에서 이 논문은 에이전트 로그를 먼저 보고 반복 결정이 많은 워크플로에 정책 실행을 도입하라는 절차를 준다. 이동 목록을 나열할 수 있고, 결정에 필요한 결과를 관측할 수 있으며, 결정에 영향을 주는 소수의 사실로 상태가 반복되는지 확인해야 한다. 비용 단위를 먼저 정하고, 상태 설계가 지나치게 세밀하면 반복이 줄고 거칠면 다른 결정을 합칠 수 있음을 고려해야 한다. 파인튜닝과는 대체 관계가 아니라 보완 관계다. 파인튜닝은 매 턴 모델의 결정을 바꾸지만 BLM은 정책이 덮는 턴을 모델에서 제거하며, 파인튜닝 모델을 BLM의 폴백으로 쓸 수 있다. 저자들은 이를 인터프리터 대비 추적 JIT 컴파일러에 비유한다. 반복 경로만 컴파일하고 가드가 실패하면 LLM으로 되돌린다는 뜻이다.
한계도 분명하다. 가장 강한 증거는 τ²-bench telecom이라는 하나의 벤치마크 생성기에 집중되어 있고, 19개 고장 유형을 조합하며 고객을 LLM으로 시뮬레이션하므로 실제 고객보다 변동이 작을 수 있다. 컨트롤러를 동결한 뒤 무작위로 뽑은 테스트 세트는 컨트롤러에 유리한 과제 선택은 막지만 다른 생성기로의 일반화는 보장하지 않는다. InventoryBench는 전체 벤치마크 결과를 보면서 수요 예측과 롤아웃을 개발했고, 두 소매 벤치마크에서는 이득이 없었다. 컨트롤러는 저자들의 지시 아래 코딩 에이전트가 작성했으며, 논문의 레시피만으로 사람 개입 없이 만든 컨트롤러는 아직 시험하지 않았다. 상태 선택 자체가 별도의 최적화 문제라서 논문의 최적은 선택한 상태에 대한 최적일 뿐이다. 고정된 정책은 학습을 멈추고, 솔버는 누군가 나열한 이동 중에서만 고르며, 기대 비용 최소화는 다른 제약과 위험을 반영하지 않는다.
그럼에도 논문의 주장은 네 가지로 정리된다. 결정과 생성을 분리하면 제한된 워크플로의 상태는 포화되고 텍스트는 그렇지 않다. LLM 에이전트는 결정을 최적화하지 않으며, 확률을 주면 솔버가 더 잘 고른다. 해결된 결정을 실행하면 그 결정에 들 모델 호출이 사라져 비용과 대기 시간이 줄고 정확도와 일관성은 유지되거나 개선된다. 에이전트 로그가 어디서 이득이 날지 예측한다. 따라서 반복 결정이 많은 bounded 워크플로에서는 같은 상태에 대해 모델에 다시 비용을 지불하지 않는 설계가 합리적이다.