무엇인가
UMass Amherst·Zoom·Emory·UNC Charlotte 연구진이 2026년 9월 17일 arXiv에 올린 「An Empirical Study of Harness Design for Coding Agents」(Fan 외)입니다. 하니스는 언어 모델을 코딩 에이전트로 바꾸는 소프트웨어 층, 곧 제어 루프·도구 인터페이스·맥락 관리를 말합니다.
기존 비교는 대개 OpenHands 대 SWE-agent처럼 완성된 하니스를 통째로 맞붙였습니다. 그러면 점수 차가 계획 덕인지, 도구 덕인지, 맥락 처리 덕인지 알 수 없습니다. 이 논문은 실행 루프를 고정한 가벼운 하니스를 새로 만들고, 계획·행동 공간·맥락 관리 세 부품만 하나씩 바꿨습니다. 4개 모델(Nemotron-3 30B·120B·550B, Mistral Medium 3.5 128B) × 2개 벤치마크(SWE-Bench Verified, Terminal-Bench 2.1) × 22개 설정 = 176개 설정입니다.
글머리 숫자가 요점을 보여 줍니다. Nemotron-3 550B는 32k 창에서 맥락 관리 없이 SWE-Bench Verified 6.4%였는데, 모델은 그대로 두고 요약 기반 관리만 켜자 58.4%가 됐습니다. 공식 코드 저장소는 2026-10-24 기준 확인되지 않습니다.
어떻게 동작하나
실험용 하니스는 LangGraph 위의 ReAct 루프입니다. 매 턴 입력을 조립하고, 도구 호출을 컨테이너에서 실행하고, 관찰을 히스토리에 붙입니다. 이 루프와 안전장치(작업 공간 가드, 읽기 전 쓰기 금지, 편집 후 ruff·pyflakes 진단, 같은 호출 5회 반복 시 경고·같은 실패 8회 시 종료)는 모든 실험에서 같습니다. 바뀌는 것은 세 레버뿐입니다.
update_plan 도구와 계획 지시를 켜고 끈다. 저장된 최신 계획 하나가 매 턴 입력에 다시 붙는다. Claude Code의 TodoWrite와 같은 모양이다.bash 하나. 도구를 빼면 읽기 전 쓰기 검사·상태 추적·편집 후 진단도 함께 빠지므로 '인터페이스 전체'의 비교다.recall_event로 되찾기), M3 요약(같은 모델로 구조화 요약)을 조합한 T0~T4 다섯 등급.기본 설정 T4는 두 단계로 움직입니다. 히스토리가 창의 60%(소프트 임계)를 넘으면 중간 구역의 큰 도구 출력을 스텁으로 바꾸고, 85%(하드 임계)를 넘으면 가장 오래된 중간 이벤트를 요약합니다. 시스템 프롬프트·과제 설명(서문)과 최근 30% 구간(최소 2턴)은 건드리지 않습니다.
네 가지 발견은 이렇습니다.
| 부품 | 발견 | 근거 수치 |
|---|---|---|
| 맥락 관리 | 창이 좁을수록 값지다. 이득의 대부분은 창 초과로 인한 조기 종료를 막는 데서 나온다 | 관리 효과(SWE): 32k 35.7pp → 128k 2.7pp. 관리를 켠 설정의 창 초과 실패 0건 |
| 등급 선택 | 규칙 생략을 먼저, LLM 요약은 나중에(T4)가 가장 싸다 | 8개 패널 중 7개에서 T4 비용 최저 |
| 회수(M2) | 되찾기 도구는 거의 쓰이지 않고 정확도 이득도 없다 | T2·T4 64개 설정 중 36개에서 호출 0회. T2 대 T1 평균 −0.36pp |
| 계획 | 약한 모델에겐 정확도 비계, 강한 모델에겐 비용 절감 장치 | 30B SWE 13.6% → 25.2%. 550B는 정확도 비슷, 비용 −30%. Mistral −32% |
| 행동 공간 | bash에 서툰 모델은 도구 세트가 살리고, bash에 능한 모델은 bash 단독이 더 싸다 | 30B bash 단독 −15.0pp. 550B +3.6pp·비용 −53%. Mistral은 SWE −23.2pp, TB +6.7pp |
궤적 분석은 세 부품이 서로 다른 면을 건드린다고 정리합니다. 맥락 관리는 행동을 바꾸지 않고 궤적을 늘리고, 계획은 궤적이 멈추는 곳을 옮기고(약한 모델은 덜 포기하고, 강한 모델은 검증 반복을 줄인다), 행동 공간은 코드를 쓰는 단위를 바꿉니다.
빠른 시작
논문 하니스를 내려받아 쓰는 것이 아니라, 자기 하니스에 결론을 옮기는 순서로 읽습니다. 논문의 네 발견을 코어닷투데이가 실무 규칙으로 정리한 것입니다.
- 실패 궤적이 어디서 죽었는지 센다. 창을 넘겨 죽으면 맥락 관리, 편집도 못 하고 끝나면 계획(약한 모델)이나 도구 세트, 편집 후 검증만 반복하다 예산을 다 쓰면 계획(강한 모델)을 손본다.
- 맥락 관리를 단계화한다. 60%에서 오래된 큰 도구 출력을 스텁으로(규칙, 무료), 85%에서 구조화 요약으로(LLM, 유료). 회수 도구는 호출 로그가 쓸모를 증명하기 전에는 넣지 않는다.
- 모델을 바꾸면 계획·도구 기본값을 다시 잰다. 같은 bash 단독 설정이 550B에게는 최고 성적, Mistral에게는 SWE-Bench −23pp였다.
스텁에는 다시 얻는 방법을 적어 둡니다. 논문 하니스의 문구입니다.
[tool output elided: 412 lines / 18,300 chars. Re-read or re-run to get it again.]
요약 프롬프트(논문 Figure 18)는 일곱 제목 아래 구조화 요약을 쓰게 하고, 이전 요약이 있으면 아직 참인 사실은 유지하고 낡은 것은 버리며 새 이벤트를 합쳐 갱신하라고 지시합니다.
## Goal
## Files touched
## Done
## Pending
## Errors & fixes
## Current state
## Next step
Anthropic API를 쓴다면 오래된 도구 결과를 지우는 clear_tool_uses_20250919가 M1에 해당하는 기능입니다.
언제 쓰고, 언제 피하나
| 상황 | 이 논문의 결론이 크게 작용한다 | 효과가 작아진다 |
|---|---|---|
| 모델 | 오픈·소형 모델, 온프레미스 | 프런티어 모델(하니스 차이가 1pp 안팎이라는 동시기 연구도 있다) |
| 맥락 창 | 32k~64k로 좁다 | 128k 이상, 궤적이 창 안에 들어온다 |
| 목표 | 성패를 가르는 정확도, 또는 강한 모델의 비용 절감 | 이미 넉넉한 창에서 정확도 몇 점 더 |
| 과제 | 셸 중심 과제인지 저장소 편집 과제인지 구분할 수 있다 | 과제 유형이 섞여 있다 — 같은 모델의 선호 인터페이스가 뒤집힌다 |
한계와 주의
- 특정 구현의 효과다. 계획은 프롬프트 하나와 갱신 장치 하나, 맥락 관리는 임계값 정책 하나(0.6/0.85, 최근 창 0.3)로 구현했다. 다른 방식이면 결과가 다를 수 있다.
- 계획과 행동 공간은 T4/128k에서만 절제했다. 다른 창 크기에서도 같은지는 열려 있다.
- 설정마다 과제당 1회 실행이다. Terminal-Bench는 89개 과제라 많은 비교가 통계적으로 유의하지 않고, 결론은 방향의 일관성에 기댄다.
- 모델은 Nemotron-3 세 크기와 Mistral 하나다. 모델 크기는 능력의 불완전한 대리 변수이고, SWE-Bench Verified는 파이썬 전용이다. 논문 스스로 "교차점은 다른 모델·하니스·과제로 옮기기 전에 검증하라"고 적었다.
- 120B는 계획을 끈 셀(46.6%)이 켠 셀(44.0%)보다 높았다. 논문은 "일관된 이득 없음"으로 처리했다.
