LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering

TL;DR

코딩 에이전트가 긴 과제에 실패했을 때, 그것을 몰고 가는 루프가 잘못 안내한 것인지 에이전트가 잘못 수행한 것인지 알려주는 것이 아무것도 없다. LoopArena는 코딩 에이전트를 Worker로 고정하고 그것에 지시하는 모델(Controller)을 평가함으로써 둘을 분리한다. 전체 과제에서 관측된 최고 **Strict Success Rate는 24.69%**다 (source).

저자와 소속

읽은 어떤 자료에도 공개되어 있지 않다. HuggingFace Daily Papers 스냅샷은 제목과 초록을 담고 있으나 저자 목록은 없고, arxiv.org는 이 실행의 샌드박스에서 EGRESS_BLOCKED로 응답한다. 따라서 저자와 소속은 추측하지 않고 기록하지 않는다. 공개된 코드는 초록이 밝힌 대로 https://github.com/AMAP-ML/LoopArena에 있으나, 저장소는 읽지 않았고 조직 이름으로부터 소속을 추론하지 않는다. HuggingFace Daily Papers, 2026-09-01, 82 upvotes; arXiv 게재일 2026-08-28 (source).

방법

논문은 자신이 측정하는 관행에 이름을 붙인다: Loop Engineering — 프롬프트를 하나씩 손으로 쓰는 대신 "진행을 감시하고, 작업을 배정하고, 검사를 돌리고, 에이전트가 다음에 무엇을 할지 결정하는" 루프를 설계해 코딩 에이전트를 중심으로 개발 작업을 조직하는 것.

그런 루프의 실패 양상으로 명시된 것들: 낡은 진행 메모를 신뢰하거나, 필요한 검증을 건너뛰거나, 예산을 잘못된 방향에 쓰거나, 제출해도 안전한 상태가 되기 전에 멈추는 것.

측정 문제가 이 논문의 전제다: "단일 종단 간 실행의 최종 결과는 성공이나 실패가 루프의 안내를 반영하는지 코딩 에이전트의 수행 능력을 반영하는지 알려주지 못한다."

분리는 이렇다:

역할	지위
Controller	평가 대상 모델
Worker	분리되어 고정된 코딩 에이전트
각 코딩 라운드가 끝나면 Controller는 실행에 대한 구조화된 요약을 받고 Worker에게 다음에
무엇을 하거나 검증할지 지시하거나, 멈출지 결정한다.

실행 범위와 비용이 다른 세 가지 평가 유형:

유형	무엇을 실행하는가
Type I	실행으로 검증된 질문을 통해 다음 단계 Loop Contract 선택을 채점하며, 평가 시점에 Worker 를 돌리지 않는다
Type II	전체 과제에서 선택된 한 조각에 대해 반복 제어를 실행한다
Type III	짝지은 전체 과제를 원 상태에서 평가한다

결과

주장	수치
전체 과제에서 관측된 최고 Strict Success Rate	24.69%
Controller 전반, 추정 추론 비용의 평균 짝지은 절감	64.4%
Type II 대 주 Core 기준, 순위 일치도	Spearman's ρ = 0.9747
벤치마크 데이터와 평가 코드가 공개되었다.

초록 어디에도 모델 이름이 없다 — 최고 Controller도, 고정된 Worker도, 비교 대상 집합도. 따라서 24.69%는 귀속시킬 수 없고, 이 페이지는 누구에게도 귀속시키지 않는다. "Strict Success Rate"와 "Core"는 읽은 자료 어디에도 정의되어 있지 않다.

ρ = 0.9747은 이 논문 자신의 효율 논거다: Type II가 Type III의 순서를 재현한다는 것이며, 그것이 이 벤치마크를 실행 가능하게 만드는 지점이다. 이는 순위에 대한 주장이지 점수에 대한 주장이 아니며, Type II 수치를 Type III 수치로 인용하는 것을 허락하지 않는다.

의의

이것은 하네스 대 모델의 교란 문제를, 단서가 아니라 벤치마크로 만든 것이다. Eval Harness Configuration이 이 위키에 존재하는 이유는 벤더들이 어떤 스캐폴드가 그 수치를 냈는지 밝히지 않고 에이전트 수치를 보고하기 때문이다 — 그 페이지는 GLM-5.3의 모델 카드가 거의 모든 행에 하네스를 명시한 것을 그 페이지 자신의 처방이 채택된 사례로 기록하고, 비교 가능성이 턴 상한·타임아웃·도구 가용성에 달린 Terminal-Bench 수치들을 기록한다. 그 모든 사례는 하네스를 공개해야 할 성가신 변수로 다룬다. LoopArena는 그것을 시험 대상으로 만들고 대신 모델을 고정한다 — 정확한 반전이며, 여기서 그렇게 한 첫 벤치마크다.

하네스 민감도에 교란당하는 대신 그것을 직접 측정한 이 무리의 두 번째 논문이기도 하다: Training Agents to Evolve with Their Harness: TaoLive Digital Avatar Agent Technical Report (arXiv:2608.15763)는 에이전트를 하네스와 함께 진화하도록 학습시킨다. LoopArena는 하네스의 제어자를 그것을 몰고 가는 모델의 역량으로 채점한다. 둘은 같은 변수에 정반대 끝에서 접근하며 어느 쪽도 서로를 인용하지 않는다.

24.69%라는 천장이 핵심을 떠받치는 수치다. 살아 있는 실행을 재지시하거나 중단시키는 감독자로 Terminal-Bench 2.0에서 최대 9.8점, 출력 토큰 42.9%/47.4% 절감을 얻은 PILOT in the Loop: Live Self-Improvement for Long-Horizon Agents (arXiv:2608.26530)과 나란히 놓으면, 둘은 런타임 제어가 실제 점수 값을 하고 현재 모델들이 그것을 잘 못한다는 데 동의한다. PILOT은 잘 감독했을 때의 상방을 보여주고, LoopArena는 프런티어가 그 "잘"로부터 얼마나 멀리 있는지를 측정한다.

평균 64.4% 비용 절감은 이 틀에서 가장 예측되지 않은 결과다: 더 나은 루프 제어가 단지 더 정확한 것이 아니라 더 싸다고 보고되는 것이며, 이는 PILOT이 보고한 것과 같은 방향이자 이 무리에서 여전히 드문 방향이다.

열린 질문

• 어떤 모델들이 평가되었는가. 모델 이름이 없으므로 24.69%는 정체불명 시스템에 관한 수치이며 릴리스를 가로질러 추적할 수 없다 — 벤치마크가 존재하는 단 하나의 이유가 그것이다.
• 고정된 Worker가 무엇인지, 그리고 Controller 순위가 그것에 얼마나 의존하는지. 한 Worker의 실패 양상에 맞춰진 Controller는 전이되지 않을 수 있는데, 이 설계는 바로 그것을 드러낼 변수를 고정한다.
• "Strict"가 비-strict 대비 무엇을 배제하는지, 보고되지 않았다.
• Type I의 실행 검증 질문이 런타임 역량 없이도 공략 가능한지 — Worker를 전혀 돌리지 않기 때문이다.
• Controller와 Worker가 같은 모델일 때 무엇이 달라지는지 — 실무 배치의 경우이며, 읽은 자료에서 다뤄지지 않는다.
• 오염(contamination). 언급이 없다.

인용

LoopArena: Benchmarking Models as Runtime Controllers for Loop Engineering.
arXiv:2608.28281 (2026).

• HuggingFace Daily Papers, 2026-09-01
• arXiv:2608.28281
• github.com/AMAP-ML/LoopArena