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

LLM 기반 코드 에이전트들이 패치 생성과 테스트 실행을 반복하는 generate-run-revise 패러다임을 널리 사용하고 있으나, 테스트 실행은 토큰·대기시간·환경 유지에 큰 비용을 초래한다. 이 논문은 실행만을 독립 변수로 통제한 최초의 대규모 실험을 통해 실행이 실제로 수리 성과에 기여하는 정도와 비용 대비 효과를 정량화했다. 결과는 많은 실제 인스턴스에서 실행을 제한해도 해결률은 거의 줄지 않는 반면 리소스 소비는 대폭 감소함을 보여 배포와 비용 전략에 직접적인 영향을 미친다.

문제의 출발점은 LLM 기반 에이전트가 프로그램 수리에서 테스트 실행을 반복적으로 사용하며 이 피드백을 통해 패치를 개선한다는 점이다. 테스트 실행은 스택 트레이스, 실패한 테스트 이름 같은 구체적 신호를 제공해 국소화와 검증에 기여하지만, 이러한 실행은 토큰 비용, 대기 시간, 그리고 각 리포지토리별 환경 유지 비용을 크게 증가시킨다. 따라서 실행을 기본 기능으로 항상 허용하는 것이 비용 대비 최선의 선택인지 검증할 필요가 있었다.

논문은 실행의 기여를 분리해 측정하기 위해 동일한 에이전트 스캐폴드에서 실행 접근만을 제어하는 네 가지 패러다임(Prohibited, Quota-Limited K=1, Quota-Limited K=3, Budget-Guided, Unrestricted)을 도입했다. 이 접근은 실행으로 발생하는 토큰·시간 소비와 실제 resolve-rate 변화를 직접 비교할 수 있게 해주며, 실행이 제공하는 정보 신호(actionable feedback) 비율과 타이밍(대화 초기/중간/후기 단계)을 함께 측정해 언제 실행이 유효한지 판단할 수 있게 했다. 실험 설계는 쌍비교 및 통계적 검증(McNemar, TOST)을 통해 우연성을 통제했다.

핵심적으로 관찰된 변화는 두 갈래로 요약된다. 하나는 대부분의 인스턴스에서 실행을 금지해도 해결률이 거의 유지된다는 실험적 사실이다. 다른 하나는 실행이 도움을 주는 경우가 존재하지만 그 이득은 특정 케이스에 집중되어 있고, 많은 경우 실행이 환경 오류나 불충분한 피드백으로 비용만 발생시키는 형태로 드러난다는 점이다. 이로부터 실행을 '자원'으로 취급해 비용-편익을 계산한 뒤 선택적으로 할당하는 전략이 더 합리적이라는 직관이 도출된다.

전체 연구는 두 단계 설계로 수행되었다. 첫 단계에서는 SWE-bench 리더보드에 공개된 7,745개의 에이전트 트레이스를 수집해 에이전트·모델별로 테스트 실행 빈도, 실행 타이밍(대화 비율 기준 Early/Middle/Late), 실행 성공률을 대규모로 통계화했다. 두 번째 단계에서는 Claude Code, Codex, OpenCode 세 에이전트를 고정 스캐폴드로 삼아 200개의 SWE-bench 인스턴스에 대해 다섯 가지 실행 설정을 적용해 총 3,000회의 종단간 수리 실험을 수행했다. 모든 모드에서 동일한 하드웨어와 컨테이너 환경을 사용해 wall-clock 시간 비교의 공정성을 확보했다.

실험은 실행의 실제 제공 정도를 세분화해 기록했다. Attempted(시도한 실행), Env-Err(의존성 오류로 중단된 시도), Completed(테스트 단계에 도달한 실행), Actionable(구체적 pass/fail 신호를 제공한 실행)로 구분해 '의도'와 '유효한 피드백'을 구별했다. 또한 각 실행이 대화의 어느 단계에서 발생했는지 정규화 위치로 기록해 Late-stage 실행의 성공률이 더 높다는 패턴을 확인했다. 제약 모드 중 Prohibited는 프롬프트 수준의 제한으로 설계되었으며, 이를 보완하기 위해 일부 케이스에 대해 CLI 수준의 hard-sandbox 재검증을 수행했다.

성능 평가는 resolve-rate(공식 SWE-bench 평가를 통과한 비율)를 주지표로 사용했고 토큰 소비(입력·출력 합), wall-clock 시간, 그리고 로컬라이제이션 지표(Hit, Recall) 및 편집 패턴(단일 편집 비율, 실행 이후 수정 비율)을 보조 지표로 삼았다. 통계적 검정은 McNemar 검정과 TOST(δ=5pp)를 사용해 Prohibited와 Unrestricted 간 동등성 여부를 평가했으며, 신뢰구간은 Wilson 95%를 보고했다.

7,745개 공개 트레이스 분석에서 에이전트들은 인스턴스당 평균 8.8회의 테스트 실행을 수행했고 에이전트·모델별로 2회에서 19회까지 폭넓은 차이를 보였다. 실행 시점별로는 Late-stage(대화의 66–100%) 실행이 일관되게 높은 성공률을 보였고 전체 평균 실행 성공률은 약 57.9%로 측정되었다. 이러한 대규모 관측은 에이전트들이 대화가 진행될수록 보다 표적화된 테스트를 실행하는 경향이 있음을 시사했다.

통제 실험(3,000회)에서 Prohibited와 Unrestricted의 resolve-rate 차이는 상업적 에이전트 평균으로 약 1.25 percentage point에 불과했고 통계적으로 유의하지 않았다(p>0.05). 오픈소스 OpenCode에서도 Prohibited와 Unrestricted의 격차는 거의 0pp로 관찰되어 훈련 데이터 누수로는 본 결과를 충분히 설명할 수 없었다. 반면 리소스 측면에서는 Claude Code에서 Prohibited가 토큰을 56–62% 절감하고 wall-clock 시간을 48–54% 단축하는 큰 이득을 보였다. Codex의 경우 Quota-1 모드가 비용 대비 가장 유리한 트레이드오프를 보였다.

실험 내 세부 분석은 실행의 정보 신호 품질이 낮음을 드러냈다. 재현 실행 중 actionable로 분류되는 비율은 절반 수준에 그쳤고, 검증 실행의 상당 부분은 환경 오류나 자체 검증과 공식 검증의 불일치로 이어졌다. 더구나 상업용 에이전트에서는 54–66%가 단일 편집으로 완료되어 반복 실행이 불필요한 경우가 많았다. 이러한 결과는 실행의 이득이 일부 인스턴스에 국한되어 있으며 전수적 실행은 비용 낭비로 이어질 수 있음을 보여주었다.

전체 아키텍처는 세 가지 에이전트 스캐폴드(Claude Code, Codex, OpenCode)를 동일한 리포지토리 컨테이너 환경에서 실행하는 방식으로 통일되었다. 각 에이전트는 리드온리 파일 탐색, 패치 생성(편집), 그리고 선택적 테스트 실행 사이를 오가며 수리 루프를 수행했고 실험은 실행 접근만 달리해 수행되었다. 테스트 실행으로 취급한 명령은 pytest, python -m unittest, python script.py 등 런타임과 테스트 프레임워크를 실제로 구동하는 명령들이었다.

수집된 로그는 각 실행의 정규화된 대화 위치(0.0~1.0), 시도 여부, 환경 오류 여부, 완료 여부 및 actionable 여부로 세분화되어 저장되었다. actionable은 패치 국소화에 기여할 수 있는 파일 경로·라인·스택트레이스 같은 구체적 신호를 포함한 출력을 의미한다. 실험은 동일 인스턴스에 대해 모든 실행 모드를 병렬로 배치해 wall-clock 비교의 외생 변수를 통제했고 통계적 검정은 McNemar와 TOST(δ=5pp)를 병행 사용해 동등성 판정과 우연성 통제를 수행했다.

구현 세부사항으로 OpenCode는 Qwen2.5-Coder-32B-Instruct를 vLLM으로 서빙했고 Claude Code와 Codex는 각각 상업용 CLI 버전을 사용해 접근했다. Quota-Limited 모드는 프롬프트 수준에서 포인트 비용 표를 제공해 자율적 비용 추정과 결정을 유도했으며 Prohibited는 프로젝트 종속성을 설치하지 않는 '읽기 전용' 환경을 모사했다. 모드별 실제 실행 발생은 Attempted/Env-Err/Completed/Actionable로 집계되어 프롬프트 무시와 환경 차이에 따른 '의도'와 '실제 피드백'의 차이를 정량화했다.

논문이 명시한 주요 한계는 실험 범위가 SWE-bench 스타일의 리포지토리 기반 버그 수정에 한정된다는 점이다. 결과는 Claude Code, Codex, OpenCode 세 에이전트와 선정된 200개 인스턴스에 대해서만 검증되었으므로 다른 종류의 버그(성능·보안·동적 상호작용을 요구하는 문제)에는 다른 패턴이 나타날 수 있다. 또한 Quota-Limited와 Prohibited의 초기 구현은 대부분 프롬프트 수준의 제어였고, 이를 보완하기 위해 일부 케이스에서 도구 수준의 샌드박스 검증을 수행했으나 완전한 하드웨어·환경 다양성까지 포괄하지는 못했다.