코딩 에이전트 하네스의 계획·행동 공간·컨텍스트 관리를 분리 측정한 실증 연구다.

무엇인가

코딩 에이전트의 성능은 모델 자체만으로 결정되지 않는다. 모델을 감싸 실행 루프, 도구 인터페이스, 컨텍스트 정책을 제공하는 소프트웨어 계층인 코딩 하네스가 장기 소프트웨어 엔지니어링 과제의 성과를 좌우한다. 그런데 기존 연구는 대부분 하네스를 하나의 완성된 시스템으로 평가해서, 성능 차이가 계획 때문인지 도구 설계 때문인지 컨텍스트 관리 때문인지 구분하지 못한다. 실제로 Cao 등(2026)의 하네스 간 비교에서는 Claude-Opus-4.5가 OpenHands에서, Claude-Sonnet-4.5가 SWE-Agent에서 가장 좋은 성적을 냈다. 같은 모델이라도 하네스 선호가 달라진다는 뜻이다. 이 논문은 그 원인을 구성요소 수준에서 분해하려 한다. 하네스 구성요소가 모든 상황에서 일반적으로 유용한가, 아니면 모델 능력과 과제 유형, 자원 예산에 따라 효과가 달라지는가가 연구 질문이다.

어떻게 동작하나

저자들은 실행 루프를 고정한 경량 하네스를 처음부터 만들어 계획, 행동 공간, 컨텍스트 관리 세 가지를 독립적으로 바꾼다. 루프는 ReAct 방식으로 매 턴 추론, 행동, 관찰로 구성된다. 계획은 모델이 update_plan 도구로 유지하는 명시적이고 지속적인 과제 진행 표현이며, 매 턴 대화 이력에 저장하지 않고 모델 입력에 덧붙인다. 계획을 끄면 지시문, 첫 턴 알림, 계획 주입, 도구를 모두 제거한다. 행동 공간은 read_file, write_file, edit_file, list_files, glob_files, grep_text, web_fetch, bash를 제공하는 사전 정의 도구 집합과 bash만 남기는 인터페이스 중 하나를 쓴다. 웹 검색은 SWE-Bench 과제가 공개 GitHub 이슈에서 나오므로 정답 패치가 노출될 수 있어 제외했다. 컨텍스트 관리는 세 메커니즘의 조합이다. M1 엘리전은 오래된 도구 관찰의 본문을 짧은 스텁으로 바꾸고, M2 리콜은 엘리전된 관찰을 파일 시스템에 저장해 recall_event 도구로 되읽게 하며, M3 요약은 오래된 메시지를 실행 중인 자연어 요약으로 접는다. 소프트 임계값 B1과 하드 임계값 B2를 두고, 시스템 프롬프트와 최근 창(최소 2턴)은 그대로 두고 중간 영역만 압축한다. T0은 관리 없음, T1은 엘리전만, T2는 엘리전과 리콜, T3은 요약만, T4는 엘리전을 먼저 적용한 뒤 요약하는 단계적 정책이다. T1~T3은 하드 임계값 B2에서만 작동하고 T4는 B1에서 엘리전, B2에서 요약을 한다. 작업공간 경로 탈출과 심링크를 막는 가드, 읽기 전 쓰기 금지 검사, allow/ask/deny 권한 계층, ruff와 pyflakes를 쓰는 편집 후 진단, 동일 도구 호출 5회 연속 시 경고하고 동일 실패 호출 8회 연속 시 종료하는 정체 감지는 모든 조건에서 고정한다.

무엇과 다른가

실험은 Nemotron-3 계열 30B, 120B, 550B와 다른 계열인 Mistral-Medium-3.5-128B 네 모델로 한다. 벤치마크는 실제 GitHub 이슈 500개를 담은 SWE-Bench Verified와 명령줄 환경의 종단 간 과제 89개로 구성된 Terminal-Bench 2.1이다. 지표는 과제 성공률과 과제당 평균 비용이다. 토큰 가격은 100만 입력/출력 토큰당 Nemotron-3-30B 0.05/0.20달러, 120B 0.08/0.45달러, 550B 0.50/2.20달러, Mistral-Medium-3.5 1.50/7.50달러다. 모델은 SGLang으로 BF16 정밀도로 로컬 서빙하고 온도 0, top-p 0.95, 턴당 출력 상한 16,384 토큰, 과제당 최대 300 스텝으로 실행한다. 컨텍스트 소프트·하드 임계값은 사용 가능 창의 0.6과 0.85, 최근 창은 0.3이고 최소 2턴, 도구 결과는 24k 문자로 자른다. 32k, 64k, 96k, 128k 네 예산에서 T0~T4를 평가하고 T4/128k를 기준으로 계획 끄기와 bash 전용 인터페이스를 각각 하나씩 비교해 모델·벤치마크 쌍당 22개, 총 176개 설정을 만든다. 성공률 비교는 과제 단위 짝지은 양측 정확 McNemar 검정을 쓰고 Benjamini-Hochberg로 거짓 발견률을 0.05로 통제한다.

어떻게 쓰나

컨텍스트 관리의 가치는 창 예산이 좁을수록 커진다. 관리 조건(T1~T4)과 무관리(T0)의 성공률 격차를 모델 평균으로 보면 SWE-Bench에서 32k 35.7%p, 64k 15.9%p, 96k 5.5%p, 128k 2.7%p로 줄고, Terminal-Bench에서 9.5%p, 7.5%p, 4.8%p, 2.8%p로 줄어든다. 같은 구간에서 T0의 창 초과 실패율은 SWE-Bench 78.7%에서 8.7%로, Terminal-Bench 61.0%에서 12.1%로 떨어지고 관리 조건은 전 구간에서 초과 실패가 0이다. 즉 이득의 대부분은 창이 꽉 찰 때 실행이 조기 종료되는 것을 막는 데서 나온다. 다섯 전략 중에서는 T4가 정확도는 T1~T3와 비슷하면서 8개 모델·벤치마크 조합 중 7개에서 비용이 가장 낮았다. T4는 네 예산 모두에서 평균 피크 컨텍스트 비율이 가장 낮고, 32k와 64k에서 T1·T2보다 엘리전을 덜 부르며 모든 예산에서 T3보다 요약 호출이 적다. 값싼 엘리전이 먼저 많은 경우를 처리해 비싼 LLM 요약 호출을 줄인다는 설명이다. 반면 엘리전을 되돌릴 수 있게 하는 리콜(M2)은 거의 쓰이지 않는다. T1과 T2는 M2 유무만 다른데, 32개 모델·벤치마크·창 비교에서 T2가 15개에서 앞서고 14개에서 뒤지고 3개에서 동률이며 등가중 평균 차이는 −0.36%p(SWE-Bench +0.40, Terminal-Bench −1.12)다. T2와 T4 설정 64개 중 36개(56.3%)는 recall_event를 한 번도 호출하지 않았고 호출률 중앙값은 0이며 과제당 평균 호출은 32k 0.540회에서 64k 0.069, 96k 0.011, 128k 0.007로 떨어진다. 가장 많이 쓴 조건인 Nemotron-3 30B의 Terminal-Bench 32k T2도 과제당 4.326회에 그쳤고 성공률은 T1보다 3.37%p 낮았다.

전제와 한계

계획은 모델이 약할 때는 정확도 발판, 강할 때는 비용 절감 장치로 역할이 바뀐다. T4/128k와 전체 도구 집합에서 계획을 켜면 Nemotron-3 30B는 SWE-Bench 11.6%p, Terminal-Bench 4.5%p 성공률이 오르지만 비용도 늘어난다. 120B는 일관된 성공률 이득이 없고 SWE-Bench에서는 비용이 오르고 Terminal-Bench에서는 줄어든다. 550B와 Mistral은 두 벤치마크 모두에서 비용이 줄고 성공률은 소폭 떨어진다. SWE-Bench에서 비용이 각각 약 30%와 32% 줄 때 성공률은 2.0%p와 0.4%p만 내려간다. 행동 공간에서는 사전 정의 도구가 bash가 약한 모델을 받쳐 준다. 30B는 사전 정의 도구로 SWE-Bench 15.0%, Terminal-Bench 10.1% 성공률이 오르는데, bash 전용에서는 인터페이스에 없는 도구 호출을 내보내고 Terminal-Bench 궤적의 66%가 그 지점에서 끝나 평균 길이가 71턴에서 15턴으로 줄어든다. 120B는 이득이 1.6%와 4.5%로 줄지만 실행은 더 효율적이 되어 평균 길이가 SWE-Bench 101턴에서 77턴, Terminal-Bench 96턴에서 70턴으로 짧아진다. 550B는 반대로 bash 전용이 SWE-Bench 3.6%p, Terminal-Bench 5.6%p 성공률을 올리면서 비용을 53%와 30% 줄이고 호출 수를 32%와 24% 줄인다. Mistral은 과제 유형에 따라 갈린다. 전체 도구 집합은 SWE-Bench에서 23.2%p를 더하고 bash 전용은 Terminal-Bench에서 6.7%p를 더한다. 전체 도구가 있을 때 Mistral은 Terminal-Bench 작업공간 행동의 71.9%를 bash로 처리하지만 SWE-Bench에서는 40.4%에 그치고, 사전 정의 도구 사용은 과제당 31.4회에서 13.1회로 줄어든다. bash 전용 SWE-Bench 실행의 32.8%는 파일을 편집하지도 못하고 끝나는데 전체 도구 집합에서는 1.2%다.

궤적 수준 분석은 각 효과가 어떤 행동 변화에서 오는지 보여 준다. 컨텍스트 관리는 행동을 크게 바꾸지 않고 실행 궤적을 늘린다. 32k에서 관리가 없으면 SWE-Bench 실행의 중앙 길이가 20~30턴이고 대부분 Localize 단계에서 끝나 Verify에 거의 도달하지 못하는데, 관리 조건에서는 중앙값이 약 50~180턴으로 늘어 검증까지 간다. 128k에서는 조건 간 차이가 줄어 30B는 39~42턴, 550B는 70~74턴이 된다. 계획은 가장 약한 모델의 궤적을 편집 시도까지 유지한다. 계획을 끄면 30B의 SWE-Bench 중앙 궤적이 40턴에서 5턴으로 줄고, 편집 없이 끝나는 비율이 68.6%, Localize에서 끝나는 비율이 58.4%가 되는데 계획을 켜면 각각 27.8%와 10.4%다. 강한 모델에서는 반대로 중앙 궤적이 550B 108턴에서 74턴, Mistral 68턴에서 53턴으로 줄고, 줄어든 부분은 대부분 편집 후 검증이다. Terminal-Bench에서 계획의 비용 효과는 궤적 길이 분포를 어떻게 바꾸는지에 달려 120B는 비용이 약 26%, Mistral은 약 40% 줄지만 30B는 조기 종료를 막느라 75% 늘어난다. bash 전용은 더 큰 코드 작성 행동을 가능하게 한다. 550B의 Terminal-Bench에서 중앙 궤적이 47개 행동에서 31개로 줄면서 Write-code 비중이 16%에서 27%로 오르고, 이미 편집한 파일을 다시 패치하는 횟수는 30B 3.3에서 0.4, 120B 2.8에서 2.2, 550B 4.6에서 1.5, Mistral 3.0에서 1.3으로 줄며, Terminal-Bench의 파일 쓰기는 생성 또는 교체 형태가 30B 28%에서 64%, 120B 39%에서 76%, 550B 51%에서 76%, Mistral 28%에서 57%로 늘어난다.

실무적으로 이 논문은 하네스를 하나의 고정된 선택지로 보지 말고 모델과 예산에 맞춰 조립하라고 말한다. 컨텍스트 창이 좁거나 긴 궤적이 강제되는 환경이라면 컨텍스트 관리를 먼저 켜고, 값싼 규칙 기반 엘리전을 요약 앞에 두는 T4 구성을 기본값으로 검토할 만하다. 리콜처럼 되돌릴 수 있는 저장 장치는 대부분의 모델이 호출하지 않으므로 유지보수 부담만 늘릴 수 있다. 계획은 약한 모델에서는 성공률을 올리는 대신 비용을 늘리고 강한 모델에서는 검증 루프를 줄여 비용을 아끼므로, 모델 세대를 올릴 때 계획 프롬프트를 그대로 두지 말고 비용과 정확도를 다시 재야 한다. 도구 인터페이스도 마찬가지다. bash를 능숙하게 다루는 모델에는 사전 정의 도구가 선택과 상호작용 오버헤드로 작용할 수 있고, 명령줄 중심 과제에서는 bash 전용이 더 싸고 정확할 수 있다. 반대로 bash 호출을 안정적으로 만들지 못하는 모델에는 사전 정의 도구가 사실상 필수다. 다만 이 논문의 교차점은 특정 모델과 구현에서 측정한 값이므로, 자신의 모델과 과제 유형에서 같은 방향이 나오는지 확인해야 한다.

저자들이 밝힌 한계는 분명하다. 결과는 여기서 구현한 특정 하네스 구성요소의 조건부 효과이지 보편적으로 최적의 하네스를 찾은 것이 아니다. 계획은 하나의 프롬프트와 업데이트 메커니즘으로, 컨텍스트 관리는 고정된 압축 설정을 가진 하나의 임계값 정책으로 구현됐다. 행동 공간 실험은 도구 가용성, 인터페이스별 프롬프트, 파일 상태 추적, 편집 후 자동 진단을 한꺼번에 바꾸는 묶음 개입이라 도구 개수나 행동 입자성만의 효과를 분리하지 못한다. 계산 자원 제약으로 계획과 행동 공간은 T4/128k 조합에서만 소거 실험을 했고, 다른 조합에서도 효과가 유지되는지는 완전 요인 설계가 필요하다. 각 설정은 과제당 한 번만 실행했고 Terminal-Bench는 과제가 89개뿐이라 많은 대비가 짝지은 McNemar 검정에서 유의성에 도달하지 못한다. Terminal-Bench에 대한 결론은 개별 셀의 유의성보다 모델과 예산 전반에서 일관된 방향에 기대고 있다. 외적 타당성도 Nemotron-3 세 크기와 Mistral-Medium-3.5-128B, 그리고 SWE-Bench Verified가 파이썬 전용이라는 점에 묶여 있다. 모델 크기는 능력의 불완전한 대리 변수이고, 학습 차이와 도구 인터페이스 사전 노출, 네이티브 셸 숙련도도 관찰된 경향에 기여할 수 있다. 여기서 보고한 교차점은 다른 모델 계열이나 하네스 구현, 소프트웨어 공학 밖의 과제로 옮기기 전에 검증해야 한다.