An Empirical Study of Harness Design for Coding Agents
- 게시일: 2026-09-20
- arXiv: 2609.20804v1 · PDF
- 저자: Run-Ze Fan, Zihao Zhang, Simin Ma, Yebowen Hu, Shouju Wang, Kaiqiang Song, Fei Liu, Hamed Zamani, Xiaoyang Wang
- 분야: cs.AI, cs.CL, cs.LG, cs.SE
- 선정 점수: 4.29
- 선정 이유: 최근성 0.5, 인용 영향 0.0 (인용 0회), 저자 영향 0.0 (최고 h-index 0), AI 주제 적합성 3.0, 개발자 관심 0.5, 학술 신호 0.3, 오픈 웨이트·주요 연구조직 신호 0.0
← 2026-09-20 목록으로 돌아가기
한 문장 요약
코딩 하니스의 실행 루프를 고정하고 계획(planning), 액션 스페이스(action space), 문맥 관리(context management) 세 컴포넌트를 독립적으로 조절해 모델·버짓·작업별로 각 컴포넌트의 기여를 176가지 설정에서 실증적으로 분석했다.
해결하려는 문제
기존 연구들은 코딩 하니스를 전체 시스템 단위로 평가해 어떤 하니스 구성 요소가 성능 차이에 기여했는지 불명확하다. 따라서 개별 컴포넌트(계획, 액션 인터페이스, 문맥 관리)가 모델 능력, 작업 유형, 컨텍스트 윈도 버짓에 따라 언제 유효한지, 비용·정확도 균형에 어떤 영향을 주는지를 규명하는 문제가 있다.
핵심 기여
- 모듈식 경량 코딩 하니스를 설계해 실행 루프는 고정하고 계획, 액션 스페이스, 문맥 관리만 독립적으로 조절할 수 있게 함으로써 컴포넌트 수준의 비교를 가능하게 했다.
- 문맥 관리 정책(T0–T4)과 컨텍스트 윈도(32k, 64k, 96k, 128k)를 체계적으로 교차하여 176개의 매칭된 실험 설정(4개 모델 × 2개 벤치마크 등)을 평가하고, 성공률·비용·궤적(trajectory) 분석을 제시했다.
- 문맥 관리, 계획, 액션 스페이스가 모델 능력과 컨텍스트 예산에 따라 조건부로 다른 역할을 한다는 핵심 발견(예: 문맥 관리는 윈도 제약 시 결정적, T4가 비용 효율 최고, 리콜은 거의 사용되지 않음 등)을 정량적으로 제시했다.
- 실험 재현을 위해 상세한 하니스 구성(도구 스키마, 계획 프로토콜, 문맥 관리 알고리즘, 안전/진단/스턱 감지 정책), 통계 검정(McNemar, Benjamini–Hochberg)과 비용 산정 방식(토큰 단가)을 함께 공개했다.
접근 방법
- 하니스는 ReAct 루프(각 턴: 사고·액션·관찰)를 고정된 실행 루프 위에 구현하고 세 컴포넌트만 변형했다.
- (1) 계획(planning): 지속적인 작업 계획을 주입하고 update_plan 도구로 갱신·주입하는 스캐폴드로, 플래닝 온/오프를 대비하였다.
- (2) 액션 스페이스: predefined-tool(typed schemas: read_file, write_file, edit_file, list_files, glob_files, grep_text, web_fetch, bash 등)과 bash-only 인터페이스를 비교하였고, predefined 도구는 읽기 전 쓰기 금지·상태 추적·자동 진단을 포함한다.
- (3) 문맥 관리: 세 메커니즘(elision M1, recall M2, summarization M3)을 조합한 5개 티어(T0: 없음, T1: elision, T2: elision+recall, T3: summarization, T4: staged elision→recall→summarization)를 정의하고 소프트/하드 임계치(B1,B2)에 따라 중간 영역을 압축했다.
- 실험은 Nemotron-3(30B,120B,550B)과 Mistral-Medium-3.5-128B를 사용해 SWE-Bench Verified(500 이슈)와 Terminal-Bench 2.1(89 터미널 과제)에서 수행했다.
- 문맥 윈도는 32k/64k/96k/128k 토큰을 사용했으며 T4/128k를 기준으로 계획·액션 스페이스를 추가로 제거해 총 176 설정을 평가했다.
- 각 설정에서 성공률과 평균 비용(토큰 가격 기준)을 측정했고, 궤적 수준(labeling) 분석을 위해 턴별 목적 분류 및 종료 단계 진단을 수행했다.
- 모델 서빙은 BF16, 온도 0, top-p 0.95, 턴 출력 상한 16,384 tokens, 각 작업 최대 300스텝 등의 공통 실행 파라미터를 고정했다.
주요 결과
- 실험은 176 설정(4개 모델 × 2개 벤치마크 × 문맥·계획·액션 변형)을 포함했다(문맥 티어 5종 × 윈도 4종 + 계획/액션 추가 ablation).
- 문맥 관리의 가치(관리된 티어 T1–T4 vs T0)는 윈도 제약이 강할수록 커졌다. SWE-Bench에서 관리–T0 성공률 격차는 윈도 32k→64k→96k→128k에서 평균 35.7 → 15.9 → 5.5 → 2.7 퍼센트포인트로 감소했고, Terminal-Bench에서는 9.5 → 7.5 → 4.8 → 2.8 퍼센트포인트로 감소했다(본문).
- 문맥 오버플로우 방지 효과가 주된 이득이다. T0의 모델-평균 오버플로우율은 SWE-Bench에서 78.7% → 8.7%(32k→128k), Terminal-Bench에서 61.0% → 12.1%로 감소했으며, 모든 관리 티어는 모든 버짓에서 오버플로우 실패 0을 기록했다(본문).
- T4(사전 elision 후 요약)의 비용-효율이 가장 우수했다. T4는 다른 관리 전략과 유사한 성공률을 유지하면서 평균 피크 컨텍스트 비율을 낮추고 요약 호출 빈도를 줄여(요약은 비용이 크다) 평균 비용이 가장 낮았다(본문·그림).
- 리콜(M2)은 거의 사용되지 않았고 정확도 향상을 제공하지 않았다. T2–T1 비교에서 평균 차이는 −0.36 pp이며(상세: SWE +0.40, Terminal −1.12), T2/T4 설정 중 56.3%의 설정이 recall_event를 전혀 호출하지 않았고 중앙값 호출률은 0이다(표 13). 예외적으로 Nemotron-3 30B의 Terminal 32k에서 가장 높은 평균 호출률(4.326회/과제)이 관찰되었으나 정확도 향상으로 이어지지 않았다(본문).」「계획의 효과는 모델 능력에 따라 전이된다. Nemotron-3 30B(약한 모델)에서는 T4/128k·전체 도구 기준으로 계획이 SWE-Bench에서 성공률을 11.6 pp, Terminal에서 4.5 pp 증가시켰으나 비용도 증가했다. 반면 Nemotron-3 550B와 Mistral은 계획이 비용을 약 30% 절감(예: SWE-Bench)하면서 성공률은 소폭(각각 약 −2.0 pp, −0.4 pp) 감소하는 경향을 보였다(본문·표).」「액션 스페이스의 교차효과: predefined 도구는 bash 사용 능력이 약한 모델을 크게 도왔고(예: Nemotron-3 30B에서 SWE +15.0 pp, Terminal +10.1 pp), bash-capable한 강한 모델은 bash-only로 비용을 크게 낮추며 경우에 따라 성공률도 개선했다(예: Nemotron-3 550B에서 SWE +3.6 pp, Terminal +5.6 pp; 비용은 SWE −53%, Terminal −30% 감소). Mistral은 작업 유형에 따라 교차(터미널 중심 작업에서 bash 선호)하는 경향을 보였다(본문·그림·표).」「통계 검정: 설정 간 성공률 비교는 이슈-페어드(two-sided exact McNemar) 테스트와 Benjamini–Hochberg FDR 0.05 보정으로 수행했다(본문).
한계
- 저자가 직접 명시한 제한: 사용한 모델들을 ‘능력·상호작용 스타일을 탐색하기 위한 프로브’로 사용했으며(영구 최적화 대상 아님), 본 연구는 계획·액션 스페이스·문맥 관리 세 컴포넌트에 초점을 맞추고 다른 운영 메커니즘(권한 처리, 포스트-에디트 진단, 스턱 감지 등)은 고정했다(본문).
- 실험 범위·일반화 관련 제약(본문에서 합리적으로 확인되는 한계): 실험은 Nemotron-3 계열 3종과 Mistral-Medium-3.5-128B에 국한되므로 다른 아키텍처·대형 모델·미세 조정/강화학습 기반 에이전트에 대한 일반화는 추가 검증이 필요하다. 벤치마크도 SWE-Bench Verified와 Terminal-Bench 2.1으로 제한되어 다른 코드 수리·데브옵스 작업군에서의 결과 전이는 불확실하다. 또한 문맥 관리·요약은 동일 평가 모델을 사용한 요약 호출로 구현했으며(본문·부록), 요약 모델이나 비용 구조가 달라지면 비용-효율 분석이 달라질 수 있다. 또한 리콜이 거의 호출되지 않았으나 특정 극한 상황에서 유용할 가능성은 남아있다.
개발자 관점
- 문맥 윈도 예산이 타이트한 환경에서는 반드시 문맥 관리(T1–T4)를 도입해 오버플로우로 인한 조기 종료를 방지하라. 특히 32k 수준에서는 관리의 효과가 매우 크다.
- 비용-효율 목표라면 T4(사전 룰 기반 elision 후 필요시 LLM 요약)를 기본으로 고려하라. 조기 elision으로 요약 호출을 줄여 비용을 절감하면서 성공률을 유지한다.
- 외부 스토리지+recall(손실 없음) 메커니즘은 구현·운영 복잡도를 추가하므로 실제로 모델이 recall_event를 호출하는지 로그로 확인하지 않는다면 우선 도입을 보류해도 된다(실험에서는 대부분 호출하지 않음).
- 계획은 모델 능력에 따라 다른 목적을 달성한다. 약한 모델에는 정확도(수정 시도 유도)를 위해 켜고, 강한 모델에는 비용 절감을 위해 켜는 것이 유리하다(운영 시 모델별 A/B 테스트 권장).
- 액션 인터페이스는 모델 능력·작업 유형에 맞춰 설계하라. bash-숙련 모델·터미널 중심 작업에서는 bash-only가 비용을 크게 낮추고(더 큰 합성 명령 사용), 약한 모델에는 predefined 파일·검색·편집 도구가 작업 성공률을 높인다. 따라서 배포 전 모델·작업별 인터페이스 선택 실험을 권장한다.
근거 범위: 이 분석은 제공된 논문 PDF 본문(본문, 표, 그림, 부록 포함) 텍스트를 기반으로 작성되었다. 본문에 명시된 수치(표·그림·본문의 숫자)와 저자 언급을 우선으로 했으며, PDF 추출 과정에서 일부 부가적 세부(예: promp t 문자열의 전체 텍스트)가 누락되었을 가능성은 있다. 제시한 한계와 수치는 본문에서 직접 확인된 내용에 근거하며, 추가 구현 세부사항(코드·서버 설정 등)은 본문에 명시된 범위를 넘어선 것은 포함하지 않았다.