코딩 에이전트 하네스 설계 실증 연구: 176회 실험으로 밝혀진 컨텍스트·계획·도구의 진실

코딩 에이전트 하네스 설계 실증 연구: 176회 실험으로 밝혀진 컨텍스트·계획·도구의 진실

출처: arXiv 2609.20804 · GeekNews · Hacker News

왜 이 연구가 중요한가

코딩 에이전트 벤치마크 리더보드를 보면 늘 같은 질문이 떠오른다. "OpenHands가 SWE-Agent보다 나은 건 모델 때문인가, 아니면 하네스 설계 때문인가?"

UMass·Emory·Zoom 연구팀이 이 질문에 정면으로 답했다. ReAct 실행 루프를 완전히 고정한 채, 계획(Planning)·행동 인터페이스(Action Space)·컨텍스트 관리(Context Management) 세 축만 분리 ablation하는 방식으로 176가지 실험 설정을 돌렸다. 결론부터 말하면:

"하네스 설계는 조건부 시스템 문제다. 어떤 단일 설정도 모든 모델·작업·예산에서 최선이 아니다."

---

실험 설계: 무엇을 고정하고 무엇을 바꿨나

┌─────────────────────────────────────────────────────────────┐
│  고정 (Fixed)                                                │
│  ├─ ReAct 실행 루프                                          │
│  ├─ 권한 처리 (permission handling)                          │
│  ├─ Python 수정 후 ruff/pyflakes 자동 진단                   │
│  ├─ 동일 호출 5회 / 동일 실패 8회 → stuck 감지              │
│  └─ LangGraph + Harbor 인프라, 작업당 최대 300스텝           │
├─────────────────────────────────────────────────────────────┤
│  변경 (Ablated)                                              │
│  ├─ Planning: update_plan 사용 여부                          │
│  ├─ Action Space: 사전 정의 8도구 vs bash-only               │
│  └─ Context Management: T0 ~ T4 5단계                        │
└─────────────────────────────────────────────────────────────┘

모델 & 벤치마크

모델	규모	추론 방식
Nemotron-3	30B / 120B / 550B	SGLang BF16
Mistral-Medium-3.5	128B	OpenRouter

• SWE-Bench Verified: 500개 실제 GitHub 이슈 해결 과제
• Terminal-Bench 2.1: 89개 터미널 중심 엔지니어링 과제
• 계획·도구 ablation은 T4/128k 예산에서만 수행 (다른 예산으로 일반화 주장 없음)

---

핵심 발견 1: 컨텍스트 관리 — 창이 좁을 때 생존의 열쇠

5단계 컨텍스트 관리 티어

T0: 관리 없음 ──────────────→ 창 초과 시 오류 종료 ❌
T1: [생략 M1] ───────────────→ 오래된 도구 출력 stub, 원문 삭제
T2: [생략 M1 + 복구 M2] ─────→ stub + recall_event로 원문 복구 가능
T3: [요약 M3] ───────────────→ 중간 이력 전체 LLM 요약
T4: [생략 M1 + 복구 M2 + 요약 M3] → 단계형: B1(60%)에서 생략, B2(85%)에서 요약

T4 세부 임계값:
- Soft 임계 B1 = 창 60% → 오래된 도구 출력 생략 시작
- Hard 임계 B2 = 85% → LLM 요약 트리거
- 보존 구역: preamble + 최근 2턴 + 최근 30% 예산은 항상 원문 유지

실험 결과

비교	SWE-Bench 32k	SWE-Bench 128k
T1-T4 vs T0 성공률 차	+35.7%p	+2.7%p
T0 창 초과 실패율	78.7%	8.7%
T1-T4 창 초과 실패	0건	0건

핵심 인사이트: 컨텍스트 관리의 이득 대부분은 행동 패턴 변화가 아니라 overflow 조기 종료 방지에서 온다. 에이전트는 관리 여부와 무관하게 비슷하게 행동하지만, T0는 작업 완료 전에 강제 종료된다.

또한 M2 recall_event: 64개 설정 중 56.3%가 0회 호출 → 복구 레이어의 실질적 ROI는 낮다. T4가 T2보다 비용이 낮은 이유도 여기에 있다 — 규칙 기반 생략(M1)이 요약 필요 자체를 줄인다.

---

핵심 발견 2: Planning — 약한 모델의 생존 장치, 강한 모델의 비용 절감기

Planning은 update_plan 도구를 통해 대화 이력에 넣지 않고 매 턴 모델 입력에 주입하는 방식이다. "plan-and-execute" 전체가 아니라, 지속적 명시 계획 장치의 효과만 측정한 것이 포인트다.

모델	Planning 효과	비고
Nemotron-3 30B	SWE 13.6% → 25.2% (+11.6%p), 비용·턴↑	조기 포기 방지, 실행 연장
Nemotron-3 120B	작업 유형별 상쇄	중간 지점
Nemotron-3 550B	성공률 소폭↓, SWE 비용 ~30%↓	과잉 검증·반복 축소
Mistral-Medium-3.5	성공률 소폭↓, 비용↓	강한 모델과 유사 패턴

해석: 약한 모델은 명시적 계획이 없으면 수정 시도 전에 일찍 포기한다. 강한 모델은 이미 내부적으로 계획을 세우므로, 외부 planning 레이어가 중복이 되어 오히려 과잉 검증을 유발한다.

Anthropic이 Opus 4.8+ 이후 TodoWrite/Task 도구를 기본 비활성한 결정과 정확히 맞닿아 있다 — 강한 모델에게 외부 계획 도구는 짐이 될 수 있다.

---

핵심 발견 3: Action Space — bash 역량이 분기점

두 가지 행동 인터페이스

사전 정의 도구 세트 (8종)

read_file, write_file, edit_file,
list_files, glob_files, grep_text,
web_fetch, bash

• 타입 지정 스키마 + read-before-write 강제
• 파일 해시로 외부 변경 감지
• Python 수정 후 자동 ruff/pyflakes 진단
• 읽기 전용 도구는 턴 내 최대 8개 병렬

bash-only
- 파일·검색·웹 도구 제거, bash만 유지
- 여러 작업을 한 셸 호출로 묶기 가능

결과

모델	bash-only vs 사전 정의 도구	SWE-Bench	비용
Nemotron-3 30B	사전 정의 도구 우위	+15.0%p	-
Nemotron-3 550B	bash-only 우위	65.8% → 69.4%	$2.33 → $1.11
Mistral	작업 유형별 역전	SWE↓·TB↑	-

bash-capable 모델이 bash-only를 쓰면: 여러 파일 수정·검색·검증을 단일 셸 호출로 묶어 턴 수와 토큰 비용을 동시에 절감한다.

HN 논쟁: "bash-capable + bash-only > 구조화 도구"를 MCP 무용론으로 읽는 댓글이 달렸으나, 엔터프라이즈 OAuth·감사 목적 MCP는 별개의 문제라는 반론(CharlieDigital)도 설득력 있다.

---

핵심 발견 4: 컴포넌트 효과는 조건부다

이 연구의 가장 중요한 메시지:

하네스 컴포넌트 효과 = f(모델 역량, 컨텍스트 예산, 작업 유형)

완성형 하네스(OpenHands vs SWE-Agent) 비교로는 이 조건부 관계를 알 수 없다. 리더보드 숫자 하나로 설계 근거를 삼는 것은 위험하다.

---

실무 시사점 (2026-09 기준)

컨텍스트 예산별 전략

32k–64k급 (로컬·저가 API 환경)
- T4형 단계 생략+요약이 ROI 최고
- recall_event 복구 레이어는 우선순위 낮음
- context 관리 없이는 78%가 overflow 종료

128k+ 환경 (강한 모델)
- context 관리 마진 대폭 축소
- planning은 성공률 도구가 아닌 비용 튜닝 도구로 전환
- bash-only로 비용 절감 고려

도구 설계 원칙

1. 모델이 bash를 잘 다루면 → MCP/파일 도구 오버헤드 재검토
2. 모델 업그레이드 시 → 반드시 각 컴포넌트 재검증 (이전 최적 설정이 새 모델에선 독이 될 수 있음)
3. 엔터프라이즈 시크릿·감사 요건 → bash-only로 전환 불가, MCP 유지 필요

실무 데이터 포인트: rahulmax의 PROGRESS.md 체크포인트(창 25-30% 사용)가 32k +35.7%p 수치와 일치한다.

---

한계와 비판

• 모델군 편향: Nemotron + Mistral만 포함 — Claude/GPT/Qwen 프론티어 모델 직접 포함 안 됨
• "bash-capable" 미정의: 모델별 사전 판별 기준 없음
• mini-swe-agent (lieret): 극단적으로 단순한 하네스가 복잡한 하네스를 이기는 내부 벤치마크 사례 존재
• 검증 축 분리 부재: 실행용 planning/tooling과 블라인드 사용자 검증이 분리되지 않음

---

결론: 하네스는 조건부 시스템 문제다

이 연구가 던지는 핵심 메시지는 명확하다:

"기본값(defaults)을 그대로 채택하지 마라. 모델·작업·예산 조합에 맞게 컴포넌트를 on/off하라."

특히 컨텍스트 관리는 이미 검증된 투자다. 32k 환경에서 T4 없이 에이전트를 돌리면 10번 중 8번은 작업 완료 전에 에이전트가 멈춘다. 반면 계획과 도구 선택은 모델 역량을 먼저 파악한 뒤 결정해야 한다.

코딩 에이전트를 프로덕션에 올리기 전, 이 세 축의 ablation을 직접 해보는 것이 가장 확실한 하네스 엔지니어링의 시작점이다.

---

관련 글: 하네스 엔지니어링 — 모델 환경과 제어 구조 설계