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

왜 중요한가

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

핵심 기여

실행 접근권만을 변수로 둔 대규모 통제 실험을 수행

연구는 에이전트 스캐폴드를 고정하고 실행 접근만 네 가지 패러다임으로 바꾼 통제된 디자인을 제시했다. 이 디자인은 7,745개의 공개 트레이스 분석과 SWE-bench의 200개 인스턴스에서 3,000번의 종단간 수리 시도를 포함해 실행의 한계효과를 통계적으로 검증할 수 있게 했다. 동일한 인스턴스에 대해 서로 다른 실행 정책을 쌍비교함으로써 실행의 순수한 한계효과를 측정했다.

실행의 마진 이익이 평균적으로 매우 작음을 실험적 수치로 제시

상업용 에이전트 집단에서 Prohibited(실행 금지)와 Unrestricted(무제한) 사이의 평균 resolve-rate 차이는 약 1.25 percentage point로 통계적으로 유의하지 않았다. 동일한 패턴은 오픈소스 OpenCode(Qwen2.5-Coder-32B)에서도 유사하게 관찰되어 데이터 누수 가능성만으로는 설명되지 않았다. 이 결과는 많은 버그에 대해 반복 실행이 비용을 정당화하지 못함을 수치로 뒷받침한다.

실행 제한이 리소스 소비를 크게 줄임을 정량화

Claude Code의 경우 Prohibited 모드는 Unrestricted 대비 56–62% 토큰 절감과 48–54%의 wall-clock 시간 절약을 달성했다. Codex에서는 Quota-1 모드가 토큰을 21–25% 절감하면서 유사한 해결률을 유지했다. 에이전트별로 실행이 맥락창과 대화 길이에 미치는 영향이 달라 비용 효과성 최적화 전략이 에이전트별로 달라야 함을 보여주었다.

실행의 이득이 일부 인스턴스에 집중됨을 규명

분석은 재현 실행이 파일 국소화에 일관된 이득을 제공하지 못하고 검증 실행은 환경 오류나 자체 검증과 공식 평가의 불일치로 정보 신호가 약함을 보여주었다. 다수의 상업용 케이스에서 단일 편집만으로 해결이 완료되거나 에이전트 자체 테스트는 통과하나 공식 검증은 실패하는 패턴이 발견되었다. 이 결과는 실행을 무조건 허용하기보다 기대 정보량이 높은 경우에만 전략적으로 할당할 필요가 있음을 시사한다.

핵심 아이디어 이해하기

문제의 출발점은 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의 초기 구현은 대부분 프롬프트 수준의 제어였고, 이를 보완하기 위해 일부 케이스에서 도구 수준의 샌드박스 검증을 수행했으나 완전한 하드웨어·환경 다양성까지 포괄하지는 못했다.

실무 활용

실무 관점에서 본 논문 결과는 코드 에이전트 배포에서 실행 권한을 전략적으로 제한하는 것이 비용 효율적일 수 있음을 시사한다. 특히 대규모 배포 환경에서는 리포지토리별 테스트 환경 유지 비용과 API 토큰 비용을 줄이면서 유사한 해결률을 유지할 수 있다. 또한 실행을 요청하기 전 예상 정보 이득(expected information gain)을 평가하는 비용-인지(agent-side cost-awareness) 정책을 도입하면 자원 할당을 최적화할 여지가 있다.

대규모 CI/CD 파이프라인에서 에이전트가 자동 수리를 수행할 때 기본적으로 실행을 금지하고 실패가 의심되는 경우에만 실행을 허용하는 비용-민감 배포 전략
리소스 제약(토큰 예산, 대기시간)에 민감한 SaaS 서비스에서 Quota-Limited(K=1) 같은 소량 실행 예산을 적용해 비용을 제어하면서 성능 저하를 최소화하는 운영 모드
에이전트가 실행을 요청하기 전에 자체적으로 재현 가능성·로컬라이제이션 신뢰도를 평가해 기대 정보량이 높은 경우에만 실행을 수행하는 적응형 실행 결정 로직

코드 공개 여부: 공개

코드 저장소 보기

키워드

generate-run-revise(생성-실행-수정 패러다임)execution-based approach(실행 기반 접근)SWE-bench(프로그램 수리 벤치마크)resolve-rate(해결률)token cost(토큰 비용)validation execution(검증 실행)

용어 해설

생성-실행-수정 패러다임(Generate-Run-Revise Paradigm): — LLM 기반 코드 에이전트가 패치 생성 후 테스트를 실행해 결과를 관찰하고 그 피드백을 바탕으로 패치를 수정하는 반복적 상호작용 방식이다. 이 패러다임은 테스트 결과를 주요 신호로 활용해 해결 품질을 개선하되, 잦은 실행이 토큰·대기시간·환경유지 비용을 유발한다. 본 논문은 이 패러다임에서 '실행'만을 독립 변수로 분리해 비용 대비 효과를 정량화한다.
SWE-bench: — 실제 GitHub 저장소와 이슈·테스트를 포함하는 자동화된 프로그램 수리 벤치마크로서, 각 인스턴스는 리포지토리 스냅샷·문제 설명·공식 테스트 평가를 제공한다. 에이전트의 패치가 공식 테스트를 통과하면 resolve로 판정되며, 본 연구의 핵심 실험 데이터셋으로 사용되었다. 데이터셋 버전으로 Lite와 Verified 변형이 연구에 활용되었다.
쿼터 제한 실행 모드(Quota-Limited): — 에이전트가 실행을 수행할 때 사전 할당된 포인트 예산을 소진하는 방식으로, 각 테스트 실행에 비용을 부여해 실행 횟수를 자율적으로 절약하도록 유도하는 실행 제어 패턴이다. 논문에서는 K=1 및 K=3 두 수준으로 실험하여 부분적 실행 허용이 성능과 비용에 미치는 영향을 비교했다. Quota-Limited은 완전 금지와 완전 허용 가운데 중간 지점을 제공한다.
재현 실행(Reproduction Execution): — 첫 코드 수정 이전에 버그를 재현하거나 로컬에서 테스트를 돌려 문제 위치를 파악하려는 목적으로 수행하는 테스트 실행이다. 재현 실행은 스택 트레이스나 실패한 테스트 이름 같은 국소화 신호를 생성할 수 있으나 환경 오류나 무의미한 출력으로 이어질 가능성도 있다. 본 연구는 재현 실행의 비율과 'actionable' 여부를 평가해 국소화 기여도를 측정했다.
검증 실행(Validation Execution): — 첫 코드 수정 이후 패치의 유효성을 확인하려고 수행하는 테스트 실행으로, 패치가 공식 테스트를 통과하는지를 확인하는 용도로 사용된다. 에이전트 내부에서 '자체 검증'으로 통과되는 경우가 있으나 공식 SWE-bench 평가와 불일치하는 사례가 빈번했다. 논문은 검증 실행이 실패 상황을 고치는데 실제로 얼마나 기여하는지를 분석했다.

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

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 피드

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 피드