Column
코딩 에이전트 하네스의 계획·도구·컨텍스트 관리는 언제 도움이 되는가
코딩 에이전트 하네스의 계획, 도구, 컨텍스트 관리를 176개 설정으로 측정한 arXiv 논문(2609.20804)을 실측 수치 중심으로 정리합니다.
핵심 요약
- arXiv 2609.20804(2026-09-17)는 코딩 에이전트 하네스의 계획, 도구 인터페이스, 컨텍스트 관리를 실행 루프 고정 아래 176개 설정으로 분리 측정했습니다.
- 컨텍스트 관리의 성공률 기여는 윈도가 좁을수록 커졌습니다. 관리 계층과 무관리(T0)의 성공률 격차는 SWE-Bench에서 32K 35.7%p에서 128K 2.7%p로 줄었습니다.
- 규칙 기반 제거(elision)를 LLM 요약보다 먼저 적용한 T4가 8개 모델·벤치마크 패널 중 7개에서 최저 비용을 기록했습니다.
- 제거한 내용을 되살리는 recall 기능은 T2·T4 64개 설정 중 36개(56.3%)에서 한 번도 호출되지 않았고, 정확도 이득도 없었습니다.
- 계획은 약한 모델에는 정확도(+11.6%p)를, 강한 모델에는 비용 절감(약 30~32%)을 가져왔습니다.
- 사전 정의 도구는 bash가 약한 모델을 돕고, bash를 잘 쓰는 모델에는 bash-only가 더 싸고 정확했습니다.
코딩 하네스는 모델과 작업 환경 사이의 소프트웨어 계층입니다
코딩 하네스(coding harness)는 모델과 작업 환경 사이에 놓인 소프트웨어 계층입니다. 모델을 호출하는 실행 루프, 모델이 쓸 수 있는 도구 집합, 행동을 형성하는 지시문, 그리고 대화 이력이 길어질 때 무엇을 남길지 결정하는 정책을 모두 포함합니다. Claude Code, Codex, OpenHands, SWE-Agent 같은 도구는 모두 자기만의 하네스를 갖고 있습니다.
같은 모델을 써도 하네스를 바꾸면 성능이 크게 달라진다는 관찰은 이미 여러 차례 보고되었습니다. 어려운 점은 어느 부품이 그 차이를 만드는지 알 수 없다는 것입니다. 완성된 하네스 두 개를 비교하면 계획, 도구 설계, 컨텍스트 정책이 한꺼번에 섞여서 이득이 어디서 왔는지 분리할 수 없습니다.
arXiv 2609.20804는 이 지점을 정면으로 다룹니다. 실행 루프를 고정하고 세 부품만 하나씩 바꾸는 방식으로 조건부 효과를 측정한 실증 연구입니다. 2026-09-17에 제출되었고 UMass Amherst, Emory, UNC Charlotte, Zoom 연구진이 참여했으며 분량은 43페이지입니다.
176개 설정으로 부품을 하나씩 분리한 실험
실험은 모델 4종과 벤치마크 2종을 조합합니다. Nemotron-3 30B, 120B, 550B와 Mistral-Medium-3.5-128B를 SGLang으로 로컬 서빙했고, SWE-Bench Verified(사람이 검증한 GitHub 이슈 500개)와 Terminal-Bench 2.1(커맨드라인 과제 89개)에서 평가했습니다. 컨텍스트 관리 5단계와 윈도 예산 4종을 곱해 과제당 22개 설정, 총 176개 설정을 만들었습니다.
컨텍스트 관리 5단계는 관리 강도를 단계적으로 올린 구성입니다. T0는 관리 없이 윈도를 넘으면 종료하고, T1은 오래된 도구 관찰을 제거(elision)합니다. T2는 제거한 내용을 외부에 저장해 되살리는 recall_event를 더하고, T3은 LLM 요약만 씁니다. T4는 제거를 먼저 하고 요약을 나중에 하는 단계적 정책으로 세 기법을 모두 씁니다.
통계 처리는 task-paired 양측 exact McNemar 검정에 Benjamini–Hochberg 절차를 적용해 거짓 발견율을 0.05로 통제했습니다. 하네스는 LangGraph 위에 구현했고 과제 컨테이너와 검증기는 Harbor가 소유합니다. 토큰 단가는 OpenRouter 2026년 8월 기준을 적용했습니다. Nemotron-3 30B는 100만 토큰당 입력 0.05달러와 출력 0.20달러, 550B는 0.50달러와 2.20달러, Mistral-Medium-3.5는 1.50달러와 7.50달러입니다.
컨텍스트 관리의 가치는 윈도가 좁을수록 커집니다
가장 큰 효과는 컨텍스트 관리에서 나왔습니다. 관리 계층(T1~T4)과 무관리(T0)의 성공률 격차를 모델 평균으로 보면 SWE-Bench에서 32K 35.7%p, 64K 15.9%p, 96K 5.5%p, 128K 2.7%p로 단조 감소했습니다. Terminal-Bench에서도 32K 9.5%p에서 128K 2.8%p로 줄었습니다.
이 감소는 윈도 초과 실패율과 정확히 맞물립니다. T0의 윈도 초과 실패율은 SWE-Bench 78.7%에서 8.7%로, Terminal-Bench 61.0%에서 12.1%로 떨어졌습니다. 관리 계층은 네 예산 전부에서 초과 실패가 0건이었습니다. 컨텍스트 관리의 값어치는 대부분 조기 절단을 막는 데서 나옵니다.
정책별 정확도는 비슷했지만 비용은 갈렸습니다. 규칙 기반 제거를 요약보다 먼저 하는 T4가 8개 패널 중 7개에서 최저 평균 비용을 기록했습니다. 싼 제거가 다수 케이스를 먼저 처리하니 비싼 LLM 요약 호출이 줄어드는 구조입니다. 32K에서 T1과 T2는 윈도 끝까지 차오르지만 T3과 T4는 최대 컨텍스트를 크게 낮게 유지했습니다.
되살리기(recall)는 거의 호출되지 않았습니다
정교한 기능이 오히려 쓰이지 않는 역설도 나왔습니다. T2는 제거한 관찰을 되살리는 recall을 추가한 단계인데, T1과 T2는 recall 가용성만 다르므로 직접 비교가 됩니다. 32개 모델·벤치마크·윈도 조합에서 T2가 앞선 경우는 15개, 뒤진 경우는 14개, 동률 3개였고 평균 차이는 −0.36%p였습니다.
호출률 자체가 낮았습니다. T2·T4 64개 설정 중 36개(56.3%)는 recall_event를 한 번도 부르지 않았고 중앙값은 0회였습니다. 평균 호출은 32K 0.540회에서 64K 0.069회, 96K 0.011회, 128K 0.007회로 급감했습니다. recall을 가장 많이 쓴 설정(Nemotron-3 30B, Terminal-Bench 32K, T2)조차 과제당 4.326회였고 T1보다 3.37%p 낮았습니다.
저자들은 손실 없는 저장과 복구가 대부분 모델에 쓰이지 않는 기계장치이며 되살린 관찰이 과제 완료로 이어지지 않는다고 정리합니다. 기능을 더하는 일과 그 기능이 실제로 쓰이는 일은 별개입니다.
계획은 약한 모델의 정확도, 강한 모델의 비용을 바꿉니다
계획(planning)의 효과는 모델 능력에 따라 뒤집혔습니다. T4·128K·풀 도구 설정에서 Nemotron-3 30B는 계획을 켜면 SWE-Bench +11.6%p, Terminal-Bench +4.5%p 올랐고 비용도 늘었습니다. 반대로 Nemotron-3 550B와 Mistral-Medium-3.5-128B는 SWE-Bench 비용이 각각 약 30%와 32% 줄었고 성공률은 2.0%p와 0.4%p만 내렸습니다.
궤적 분석이 이유를 설명합니다. 계획을 끄면 Nemotron-3 30B의 SWE-Bench 실행 중 68.6%가 편집 없이 끝났고 58.4%는 위치 파악 단계에서 정체했습니다. 계획을 켜면 이 비율이 27.8%와 10.4%로 줄어 편집 시도까지 도달하는 실행이 늘었습니다. 실행 통계로는 턴이 293.2%, 도구 호출이 474.0%, 평균 입력 토큰이 104.1% 늘었습니다.
강한 모델에서는 방향이 반대였습니다. 계획이 편집 뒤 반복 검증을 줄여 median 궤적을 108턴에서 74턴으로 단축했습니다. 정확도 스캐폴드가 비용 절감 장치로 역할이 바뀌는 지점입니다.
| 모델 | 계획 켠 뒤 성공률 변화 | 계획 켠 뒤 비용 변화 |
|---|---|---|
| Nemotron-3 30B | SWE-Bench +11.6%p | 증가 |
| Nemotron-3 550B | SWE-Bench −2.0%p | 약 −30% |
| Mistral-Medium-3.5-128B | SWE-Bench −0.4%p | 약 −32% |
도구 인터페이스는 모델의 bash 숙련도에 따라 갈립니다
도구 인터페이스도 조건부였습니다. 사전 정의 도구 집합은 bash가 약한 Nemotron-3 30B를 크게 도왔습니다. SWE-Bench +15.0%, Terminal-Bench +10.1%였습니다. bash-only로 두면 Terminal-Bench 궤적의 66%가 인터페이스 밖 도구 호출 뒤 종료됐고 평균 궤적은 71턴에서 15턴으로 줄었습니다. 학습된 행동 어휘와 하네스 인터페이스가 어긋난 결과입니다.
bash를 잘 다루는 모델에서는 판단이 달라졌습니다. Nemotron-3 550B는 bash-only가 SWE-Bench +3.6%, Terminal-Bench +5.6%면서 비용은 53%와 30% 줄었고 호출도 32%와 24% 줄었습니다. 사전 정의 도구가 오히려 선택과 상호작용의 오버헤드로 작용한 셈입니다.
교차점은 과제 유형에도 달렸습니다. Mistral-Medium-3.5-128B는 SWE-Bench에서 풀 도구가 +23.2%로 앞섰지만 Terminal-Bench에서는 bash-only가 +6.7%로 앞섰습니다. Terminal-Bench에서 이 모델은 작업 행동의 71.9%를 bash로 내지만 SWE-Bench에서는 40.4%에 그쳤습니다. 셸 중심 과제에서는 경쟁 도구를 빼는 편이 모델의 선호 행동과 맞습니다.
판단과 실무 적용
이 논문의 기여는 무엇이 최적인가가 아니라 무엇이 언제 유효한가를 분리해 측정한 데 있습니다. 하네스 부품은 기본값으로 켜 두는 스위치가 아니라 대상 모델과 과제 유형과 자원 예산에 맞춰 고르는 조건부 선택값입니다. 궤적 라벨은 GPT-5.5 판정기로 붙였고 사람 주석자 3명이 200개 궤적과 15,610개 라벨 단위로 교차 검증해 raw agreement 약 94.2%, 가중 평균 Cohen's κ 0.929를 기록했습니다. 실측의 신뢰도는 이 부분에서 확보됩니다.
한계도 분명합니다. 계획과 도구 인터페이스는 계산 자원 때문에 T4·128K 설정에서만 분리 측정했고 각 설정은 과제당 한 번만 실행했습니다. 도구 인터페이스는 프롬프트와 파일 상태 추적까지 묶인 변경이라 도구 개수만의 효과는 분리되지 않습니다. 특정 구현의 조건부 효과이며 보편 최적 하네스를 찾은 결과는 아닙니다.
실무 적용은 이렇게 정리할 수 있습니다. 작은 모델이나 로컬 모델을 돌린다면 계획 스캐폴드와 사전 정의 도구를 먼저 켜고, 성능 좋은 코딩 특화 모델을 쓴다면 bash-only 인터페이스로 비용을 확인하라. 컨텍스트 윈도가 좁다면 관리 정책을 최우선으로 조정하고 제거를 요약보다 먼저 적용한 뒤에 요약을 붙여라. recall처럼 정교한 기능을 더할 때는 배포 전에 실제 호출률을 계측해 쓰이지 않는 기계장치를 걷어내라. 하네스 변경은 조건을 명시한 소규모 실험으로 검증하고, 결과를 모델과 과제별로 나눠 기록하길 권한다.