🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

이 논문은 코딩 에이전트의 도구를 단일 `execute_code` 도구로 제한하는 것이 도구가 풍부한 환경을 사용하는 것만큼 효과적인 경우가 많으며 종종 더 저렴하다는 것을 입증하며, 이는 최적의 도구 표면이 어느 한 요인에 의해서가 아니라 작업 체제와 특정 에이전트 설계 사이의 상호작용에 의해 공동으로 결정된다는 점을 드러낸다.

원저자: Hong Yang, Qi Yu, Travis Desell

게시일 2026-07-14

📖 5 분 읽기🧠 심층 분석

CC BY 4.0

원저자: Hong Yang, Qi Yu, Travis Desell

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신에게 코드를 고치거나 수학 퍼즐을 푸는 것이 직업인 아주 똑똑한 로봇 비서가 있다고 상상해 보세요. 지금 기술 업계에서는 이 로봇이 업무를 수행하기 위해 컴퓨터와 어떻게 대화해야 하는지를 두고 거대한 논쟁이 벌어지고 있습니다.

어떤 이들은 이렇게 말합니다. "모든 작업을 위한 특수 버튼이 있는 풀 세트 도구 상자를 줘!" (화려한 IDE처럼).
다른 이들은 이렇게 말합니다. "그냥 커맨드 라인을 주고 쉘 명령어를 타이핑하게 해!" (영화 속 해커처럼).
세 번째 그룹은 이렇게 말합니다. "아니! 그냥 로봇이 파이썬 스크립트를 작성해서 한 번에 실행하게 해!" (execute_code 방식).

이 논문은 어떤 방식이 실제로 돈을 아껴주고 업무를 완수하는지 확인하기 위해 경주를 설정한 거대하고 공정한 심판과 같습니다. 그들은 단순히 추측만 한 것이 아니라, 동일한 로봇(두 가지 모델: Claude와 Codex)을 동일한 작업에 투입하되, 오직 허용된 도구만을 변경하여 실험을 진행했습니다.

다음은 이 결과를 쉬운 이야기로 풀어낸 내용입니다.

핵심 발견: 로봇과 작업에 따라 달라진다

가장 놀라운 점은 무엇일까요? 바로 "최고의 도구"라는 것은 단 하나 존재하지 않는다는 것입니다. 승자는 누가 로봇인지, 그리고 무엇을 하고 있는지에 따라 달라집니다.

이렇게 생각해보세요:

"수학 퍼즐" 작업 (Artifact Tasks): 만약 로봇이 계산이나 데이터 처리를 하고 있다면, "스크립트를 작성하고 실행하는" 방식(code_only)이 확실한 승자입니다. 이는 마치 완벽한 레시피를 하나 써서 한 번에 요리를 끝내는 셰프를 고용하는 것과 같습니다.
- Claude 로봇의 경우, 이 방식은 비용을 24.6% 절감했습니다.
- Codex 로봇의 경우, 약 **6.7%**를 절감했습니다 (다만 논문에서는 이 결과가 동전 던지기처럼 다소 불확실하다고 언급했습니다).
- 결론: 수학과 데이터 작업에는 스크립트 방식이 더 저렴하면서도 문제를 해결하는 데 성능이 뒤처지지 않습니다.
"엉망이 된 코드베이스 수정하기" 작업 (SWE-bench Tasks): 이 부분은 까다롭습니다. 이 작업들은 복잡한 프로젝트 내의 여러 파일을 편집하는 과정을 포함합니다.
- Codex 로봇을 사용할 경우: 스크립트 방식이 여전히 챔피언입니다! 비용을 19.9% 절감했습니다. 왜냐하면 스크립트 방식은 로봇이 많은 작은 요청들을 하나의 큰 패키지로 묶을 수 있게 해주기 때문입니다. 마치 사람이 50번을 왔다 갔다 하는 대신, 50개의 패키지를 실은 트럭 한 대를 보내는 것과 같습니다.
- Claude 로봇을 사용할 경우: 어라? 스크립트 방식이 오히려 더 비싸졌습니다 (14.4% 증가). 하지만 논문은 이것이 통계적으로 "증명된" 차이는 아니며, 강력한 경향성일 뿐이라고 언급했습니다. 왜 그럴까요? Claude에게 파일을 편집하기 위해 스크립트를 쓰는 것은, 타이어를 교체하기 위해 자동차를 새로 만드는 것과 같기 때문입니다. 편집 내용을 코드로 설명하는 데 너무 많은 단어(토큰)가 소모되어 "편집 마찰(edit friction)"이 발생합니다.

이 논문이 부정하는 것들

이 논문은 하나의 도구 표면이 모두에게 항상 더 낫다는 아이디어에 명시적으로 반대합니다.

부정된 내용: "특수 IDE 버튼이 항상 필요하다." (Codex가 스크립트 방식에서 승리했기 때문입니다).
부정된 내용: "Bash 명령어만으로 항상 충분하다." (수학 작업에서 스크립트 방식이 더 저렴했기 때문입니다).
부정된 내용: "코드 실행이 항상 가장 저렴하다." (복잡한 코드 수정 작업에서 Claude에게 더 비쌌기 때문입니다).

저자들은 매우 분명하게 말합니다. 도구 자체만 보고 도구를 선택해서는 안 됩니다. 반드시 로봇의 두뇌와 작업의 유형 간의 조합을 살펴봐야 합니다.

"통과율(Pass Rate)"의 반전

여기서 가장 중요한 부분이 나옵니다. 비용은 변했지만, 성공률은 변하지 않았습니다.

두 명의 러너를 상상해 보세요. 한 명은 무거운 부츠를 신고 달리고, 다른 한 명은 운동화를 신고 달립니다. 논문은 두 러너 모두 정확히 같은 속도로 결승선을 통과했다는 것을 발견했습니다.

로봇이 화려한 도구 상자를 사용하든, Bash 명령어를 사용하든, 혹은 스크립트 방식을 사용하든, 문제를 올바르게 해결한 작업의 비율은 거의 동일했습니다 (차이는 3 퍼센트 포인트 이내).
"스크립트" 방식은 로봇을 더 똑똑하게 만들거나 멍청하게 만든 것이 아닙니다. 단지 결승선까지 가는 방법을 바꾼 것뿐입니다. 때로는 그 걸음걸이가 질주(저렴함)였고, 때로는 비틀거림(비쌈)이었습니다.

왜 비용이 변했을까?

논문은 스크립트 방식이 왜 더 저렴하거나 더 비쌌는지 그 이유를 파헤칩니다.

"편집 마찰" 세금 (Claude의 경우): Claude가 파일을 수정하기 위해 스크립트를 사용해야 할 때, "5번 줄을 바꿔라"라고 말하기 위해 긴 파이썬 스크립트를 작성해야 했습니다. 이는 로봇이 타이핑해야 하는 "출력 토큰(단어)"을 많이 소모했습니다. 이는 페이지를 넘길 때마다 통행료를 내는 것과 같았습니다. 이 현상은 주로 로봇이 실패하거나 어려움을 겪는 작업에서 발생했으며, 이 특정 실행들을 매우 비싸게 만들었습니다.
"배칭(Batching)" 보너스 (Codex의 경우): Codex가 스크립트 방식을 사용할 때, 여러 작은 명령들을 하나의 스크립트에 담을 수 있었습니다. 컴퓨터에게 "파일 A를 읽어줘", 그다음 "파일 B를 읽어줘", 그다음 "파일 C를 읽어줘"라고 세 번 따로 요청하는 대신, "A, B, C를 한꺼번에 읽어줘"라고 요청했습니다. 이는 "입력 토큰(읽어야 하는 단어)"을 엄청나게 아껴주었습니다.
"실패한 실행(Doomed Run)" 효과: Claude의 코드 수정 작업에서 발생한 추가 비용은 대부분 로봇이 이미 실패할 운명이었을 때 발생했습니다. 이는 마치 차가 제자리에서 뱅글뱅글 돌면서 연료가 떨어지는 것과 같았습니다. 스크립트 방식이 실패를 유발한 것이 아니라, 실패한 시도를 더 비싸게 만들었을 뿐입니다.

얼마나 확신할 수 있는가?

저자들은 수학 작업과 Codex 로봇 결과에 대해 매우 확신하고 있습니다. 그들은 이 테스트를 93개의 수학 작업과 100개의 코드 수정 작업에 대해 수행했으며, 결과가 운이 아니라는 것을 확인하기 위해 각 작업에 대해 세 가지 "시드(무작위 시작점)"를 사용했습니다. 코드 수정 작업에서 Codex가 보여준 비용 절감은 통계적으로 유의미했습니다 (p-값이 2.0 × 10⁻⁹로, 거의 0에 가까운 확률로 우연이 아님을 뜻합니다).

하지만 코드 수정 작업에서의 Claude 로봇 결과는 조금 더 모호합니다. 비용이 14.4% 증가했지만, 통계 테스트 결과 이것이 "완벽한 증명"은 아니라고 나왔습니다 (p-값 0.12). 저자들은 이를 "방향성(directional)"이 있다고 표현했는데, 이는 경향성은 존재하지만, 이것이 단순한 착시가 아님을 100% 확신하려면 더 많은 테스트가 필요하다는 의미입니다.

결론

만약 당신이 코딩 에이전트를 구축하고 있다면:

추측하지 마세요. 최고의 도구는 당신의 특정 로봇과 특정 작업에 따라 다릅니다.
수학/데이터의 경우: "스크립트 작성" 방식을 시도해 보세요. 더 저렴하고 성능도 동일합니다.
코드 수정의 경우: 상황에 따라 다릅니다. 만약 Codex를 사용한다면 스크립트 방식이 훌륭합니다. 만약 Claude를 사용한다면, 표준 편집 도구를 계속 사용하는 것이 좋을 수 있습니다. 특히 어려운 문제의 경우, 스크립트 방식은 "편집 마찰" 때문에 늪에 빠질 수 있기 때문입니다.
지능에 대해 걱정하지 마세요: 도구를 바꾼다고 해서 로봇이 더 똑똑해지거나 멍청해지지는 않습니다. 단지 여정의 가격표가 바뀔 뿐입니다.

이 논문은 "가장 저렴한" 방식으로 에이전트를 실행하는 법은 보편적인 규칙이 아니라고 결론짓습니다. 그것은 도구를 로봇 및 작업과 일치시켜야 하는 하나의 퍼즐입니다.

기술 요약: 코딩 에이전트를 `execute_code`로 제한하는 것이 언제 도움이 되는가?

문제 정의

코딩 에이전트 분야는 현재 최적의 "도구 표면(tool surface, 에이전트에 노출된 인터페이스 세트)"에 관한 세 가지 상충하는 주장을 바탕으로 운영되고 있습니다:

특화된 IDE 프리미티브가 필수적이다: SWE-agent가 주장하듯, 구조화된 인터페이스(예: Agent-Computer Interface 또는 ACI)는 가공되지 않은 쉘 접근 방식보다 성능이 현저히 뛰어납니다.
Bash만으로 충분하다: 최소한의 bash 전용 스캐폴드(scaffold)만으로도 IDE 프리미티브 없이 소프트웨어 엔지니어링 벤치마크에서 경쟁력 있는 성능을 달-성할 수 있습니다.
코드 실행(Code Execution)이 최적이다: (Model Context Protocol, MCP를 통해) 에이전트의 동작을 단일 execute_code 도구로 라우팅하면, 네이티브 도구를 직접 호출하는 것에 비해 토큰 사용량을 획기적으로 줄일 수 있습니다.

기존 연구들은 특정 변수(예: 특정 모델에 대한 ACI vs. shell 비교)만을 고정하고 태스크 레짐(task regime)(연산 vs. 코드 수정)과 에이전트 설계(서로 다른 모델 제품군)를 교차 검증하지 못했기 때문에 이러한 모순을 해결하는 데 실패했습니다. 결과적으로, 업계는 어떤 조건에서 어떤 도구 표면이 유리한지에 대한 통합된 이해가 부족한 상태입니다.

방법론

저자들은 무결성이 보장된 3개 암(arm) 추상화 연구를 통해 "누락된 교차 비교(missing crossed comparison)"를 수행합니다. 실험 설계는 $3 \times 2 \times 2$ 요인 설계 구조를 따릅니다:

세 가지 도구 표면:
- Baseline: 에이전트의 기본 도구 표면 (예: Read, Grep, Edit, Write, Bash).
- Bash_Only: 네이티브 bash와 읽기 전용 브라우징(Read, Glob, Grep)으로 제한됨; 모든 파일 편집 프리미티브(Edit, Write)는 제거됨.
- Code_Only: 전체 네이티브 표면이 지속적인 Python+Bash REPL을 실행하는 단일 MCP 도구(mcp__codebox__execute_code)로 대체됨. 모든 네이티브 내장 기능은 허용되지 않음.
두 종류의 에이전트: Claude Code (모델 claude-sonnet-4-6) 및 OpenAI Codex CLI (모델 gpt-5.5).
두 가지 태스크 레짐:
- Computation (연산): 워크스페이스, 숨겨진 채점기, 참조 출력을 포함하는 자립형 태스크들로 구성된 새로운 "Artifact" 스위트 ( $n=93$ ).
- Modification (수정): 큐레이션된 저장소 수정 태스크들의 하위 집합인 SWE-bench Mini ( $n=100$ ).

실험 제어:

무결성: 하네스는 에이전트가 종료된 후에 테스트 패치가 적용되는 엄격한 SWE-bench 프로토콜을 강제합니다. 파일 시스템 상태는 교차 오염을 방지하기 위해 fuse-overlayfs를 사용하여 각 암(arm) 간에 격리됩니다.
비용 회계: 서버 측 프롬프트 캐싱의 가변성을 해결하기 위해, 저자들은 "캐시 조정 비용(cache-adjusted cost)" 지표를 사용합니다. 이는 첫 번째 턴의 입력 토큰에 중간값 하한 조정을 적용하여, 완전한 캐시 격리를 주장하지 않으면서도 "warm/cold" 캐시 로또 문제를 정규화합니다.
통계적 엄밀성: 추론 단위는 시드(seed)가 아닌 태스크입니다. 결과는 세 개의 독립적인 시드에 걸친 태스크별 차이에 대해 대응 표본 윌콕슨 부호 순위 검정(paired Wilcoxon signed-rank tests)을 사용하여 분석됩니다.

주요 기여

1. 4개 셀로 구성된 에이전트 조건부 비용 구조

본 연구는 execute_code로 에이전트를 제한하는 것의 비용 효율성이 보편적인 것이 아니라, 태스크 레짐과 에이전트 설계에 의해 공동으로 결정된다는 것을 밝혀냈습니다.

4개 셀 중 3개는 code_only에 유리함:
- Artifact/Claude: 유의미한 비용 감소 ( $-24.6\%$ , $p=7.4 \times 10^{-14}$ ).
- Artifact/Codex: 방향성 있는 비용 감소 ( $-6.7\%$ , 유의미하지 않음).
- SWE-bench/Codex: 유의미한 비용 감소 ( $-19.9\%$ , $p=2.0 \times 10^{-9}$ ).
한 개 셀은 추세가 역전됨:
- SWE-bench/Claude: code_only가 방향성 있게 더 비쌈 ( $+14.4\%$ , 유의미하지 않음).

이 발견은 기존 문헌의 세 가지 주장이 모순되는 것이 아니라, 특정 (레짐, 에이전트) 조합 하에서만 참임을 보여줍니다.

2. 세 가지 메커니즘의 인과적 분해

저자들은 관찰된 비용 차이를 세 가지 뚜렷한 메커니즘으로 분해합니다:

경로 비용 (편집 마찰 - Edit Friction): SWE-bench에서의 Claude의 경우, code_only는 모든 파일 편집을 파이썬 스크립트로 표현하도록 강제합니다. 이는 편집량에 따라 출력 토큰이 증가하게 만들며 (Spearman $\rho=0.488$ ), 고빈도 편집 태스크에 "세금"을 부과합니다.
실패 비용 (Failure-Cost): Claude의 SWE-bench 비용 초과는 "실패한 실행(doomed-run)" 궤적(모든 암이 실패하는 사례)에 국한됩니다. 만장일치 통과 사례의 하위 집합에서는 비용 격차가 $+14.4\%$ 에서 $+4.1\%$ 로 좁혀집니다 (유의미하지 않음).
가격 비대칭성 (배칭 - Batching): Codex의 SWE-bench에서 code_only는 주로 입력 토큰 감소( $-24.8\%$ )를 통해 유의미한 절감( $-19.9\%$ )을 달성합니다. 이는 도구 호출 배칭(하나의 파이썬 스크립트가 여러 네이티브 도구 호출을 대체)과 프로그램적 출력 억제(에이전트가 출력량을 제한하여 네이티브 도구의 엄격한 출력 캡을 회피)에 의해 구동됩니다.

3. 능력 불변성 (Capability Invariance)

네 개 셀과 세 가지 도구 표면 전체에 걸쳐, 통과율(pass rates)은 통계적으로 동일합니다 (차이 $<3$ 퍼센트 포인트, 모두 유의미하지 않음).

합의 행렬(agreement matrix)은 대다수의 사례( $\ge 91\%$ 다수결 기준)에서 모든 암이 함께 통과하거나 함께 실패함을 보여줍니다.
이는 도구 표면의 선택이 태스크를 해결하는 경로와 비용을 바꿀 수는 있지만, 이를 해결하는 능력 자체를 바꾸지는 않는다는 것을 확인시켜 주며, 이는 "능력 중첩 원리(Capability Overlap Principle)"와 일치합니다.

결과 요약

본 논문은 code_only가 언제 유익한지에 대한 "한눈에 보는" 지도를 제공합니다:

연산 태스크 (Artifact): execute_code로 제한하는 것이 두 에이전트 모두에게 더 저렴하며, 특히 Claude에서 유의미한 이득이 있습니다.
수정 태스크 (SWE-bench) + Codex: 입력 토큰 배칭과 출력 제어를 통해 execute_code로 제한하는 것이 훨씬 저렴합니다.
수정 태스크 (SWE-bench) + Claude: execute_only로 제한하는 것이 방향성 있게 더 비쌉니다. 이는 성공적인 편집에 대한 페널티가 아니라, "편집 마찰"(편집을 위한 높은 출력 토큰)과 "실패 비용"(비싼 실패 궤적)에 의해 발생합니다.

의의 및 주장

본 논문은 단일 도구 표면이 모든 맥락에서 최적은 아니라는 것을 입증함으로써, 해당 분야의 "세 가지 상충하는 주장"을 해결한다고 주장합니다.

비용 vs. 능력: 도구 표면 선택의 핵심 신호는 능력이 아니라 비용입니다. 통과율은 불변하므로, 도구 표면의 선택은 능력 향상이 아닌 비용 공학적 결정입니다.
공동 결정: 최적의 표면은 태스크 레짐(연산 vs. 수정)과 특정 에이전트의 구현(배칭, 출력 캡, 편집 프리미티브 처리 방식)의 교차점에 의해 결정됩니다.
경험적 수령 (Empirical Receipt): 본 연구는 코딩 에이전트의 "도구 사용 세금(tool-use tax)" 불평등에 대한 첫 번째 경험적 증거를 제공합니다. 즉, 도구 표면은 그 정의에 따른 호출당 비용이 태스크 특화 능력 이득을 초과할 때만 순이익을 제공합니다.

저자들은 자신들의 발견이 비용 공학적 주장이지 능력에 대한 주장이 아님을 명시적으로 밝힙니다. 이들은 code_only가 보편적으로 우월하다고 제안하지 않으며, 추가 검증 없이 자신의 결과가 모든 모델이나 외부 MCP 도구에 일반화될 수 있다고 주장하지 않습니다. 의의는 에이전트 설계와 레짐 효과를 명확히 구분할 수 있는 방법론적 프레임워크를 제공함으로써, 분야를 일화적인 산업 보고서에서 통제된 교차 추상화 연구로 격상시킨 데 있습니다.