실행할 것인가, 실행하지 않을 것인가: LLM 기반 프로그램 수리에서 코드 실행의 비용 효율성 분석

초록

LLM 기반 프로그램 수리 에이전트는 점차 "생성-실행-수정" 패러다임 위에 구축되어, 패치를 평가하고 개선하기 위해 테스트를 반복적으로 실행한다. 이러한 실행 기반 접근 방식은 최신 시스템에서 표준 관행이 되었다. 그러나 실행은 시간과 비용이 많이 들 수 있음에도 불구하고, 에이전트에 미치는 영향은 아직 충분히 탐구되지 않았다. 본 논문에서는 LLM 기반 프로그램 수리의 실행 행동에 대한 2단계 실증 연구를 수행한다. 먼저 실행 행동을 대규모로 특성화하기 위해 SWE-bench 리더보드 제출물에서 7,745개의 에이전트 추적을 분석한다. 둘째, 200개의 SWE-bench 인스턴스와 3개의 에이전트(Claude Code, Codex, 오픈소스 OpenCode)에 걸쳐 3,000건의 종단 간 수리 시도를 4가지 실행 패러다임 하에서 평가하여, 성능과 비용에 대한 세분화된 비교를 가능하게 한다. 분석 결과 세 가지 주요 관찰 결과가 도출되었다: (1) 코드 실행은 분석된 모든 에이전트와 모델에서 사용되며, 작업당 평균 8.8회의 테스트 실행이 이루어진다. 실행 행동은 에이전트와 모델에 따라 상당히 다양하며, 빈도는 작업당 2회에서 19회까지 분포하고, 후기 실행이 초기 실행보다 일관되게 더 높은 성공률을 보인다. (2) 실행 제약은 수리 성공에 거의 영향을 미치지 않는다. SOTA 모델을 탑재한 상용 에이전트의 경우, 실행 금지 조건과 무제한 조건 간의 해결률 차이는 1.25%p에 불과하며 통계적으로 유의하지 않지만, 실행 금지는 상당한 토큰 및 실제 시간 비용을 절약한다. (3) 실행 이점은 균일하지 않고 집중되어 있다. 이러한 패턴은 현재 에이전트가 실행을 무차별적으로 적용하여, 이점이 거의 없는 인스턴스에서도 비용을 지불하고 있음을 시사한다. 따라서 실행은 기본 기능이 아닌, 명시적인 비용-편익 균형을 가진 자원으로 취급되어야 한다.

English

LLM-based agents for program repair are increasingly built on a "generate-run-revise" paradigm, iteratively executing tests to evaluate and refine patches. This execution-based approach has become standard practice in state-of-the-art systems. However, executions can be time-consuming and expensive, yet their impact on these agents remains underexplored. In this paper, we conduct a two-stage empirical study over execution behavior in LLM-based program repair. To characterize execution behavior at scale, we first analyze 7,745 agent traces from SWE-bench leaderboard submissions. Second, we evaluate 3,000 end-to-end repair attempts across 200 SWE-bench instances and three agents (Claude Code, Codex, and the open-source OpenCode) under four execution paradigms, which allows for a fine-grained comparison of performance and cost. Our analysis reveals three key observations: (1) Code execution is used across all agents and models analyzed, with an average of 8.8 test runs per task. Execution behavior varies substantially across agents and models, with frequency ranging from 2 to 19 per task, and late-stage executions consistently achieve higher success rates than early-stage ones. (2) Execution restrictions have little effect on repair success: on commercial agents with SOTA models the resolve-rate gap between Prohibited and Unrestricted is only 1.25 percentage points and not statistically significant, while Prohibited saves substantial token and wall-clock cost. (3) Execution benefit is concentrated rather than uniform. These patterns suggest that current agents apply execution indiscriminately, paying its cost on instances where it provides little benefit. Execution, therefore, should be treated as a resource with an explicit cost-benefit tradeoff, not a default capability.