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

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

출처: UMass Amherst · Emory University · UNC Charlotte · Zoom Video Communications — An Empirical Study of Harness Design for Coding Agents (arXiv:2609.20804) · GeekNews #33905 · Hacker News #49753878

---

1. 리더보드의 신기루: 모델이 뛰어난 것인가, 하네스가 영리한 것인가?

코딩 에이전트 벤치마크(SWE-Bench, Terminal-Bench 등)의 리더보드를 살펴볼 때마다 모든 AI 엔지니어는 필연적으로 동일한 의문에 직면합니다.

"OpenHands가 SWE-Agent보다 높은 점수를 기록한 것은 파운데이션 모델의 추론 능력이 앞서서인가, 아니면 모델 뒤편에서 턴을 조율하고 프롬프트를 깎아낸 '하네스(Harness)'의 설계 덕분인가?"

지금까지의 에이전트 평가는 모놀리식(Monolithic) 시스템 평가였습니다. 우리는 프롬프트 템플릿, 도구 정의, 오류 복구 로직, 컨텍스트 압축 기법이 한데 뒤엉킨 거대한 블랙박스 덩어리를 통째로 실행한 뒤 그 최종 점수만을 비교해 왔습니다. 이로 인해 리더보드 1위 프레임워크의 코드를 그대로 복제해 우리 회사 사내 모델에 붙였을 때, 기대했던 성능은커녕 비용만 수십 배로 치솟고 에이전트가 무한 루프에 빠지는 참사를 겪게 됩니다.

2026년 9월, UMass Amherst, Emory University, UNC Charlotte, 그리고 Zoom 연구팀이 이 질문에 가장 과학적이고 엄밀한 방식으로 답을 내놓았습니다.

연구팀은 ReAct 실행 루프와 환경 가드레일을 완전히 고정(Fixed)시킨 뒤, 에이전트 하네스를 지탱하는 3대 핵심 축인 컨텍스트 관리(Context Management)·계획(Planning)·행동 공간(Action Space)만을 철저히 분리하여 변인 통제 실험을 진행했습니다. 총 176가지 설정에서 수집된 방대한 데이터는 업계의 통념을 뒤흔드는 명확한 결론을 보여줍니다.

"하네스 설계는 단일 최적해가 존재하지 않는 '조건부 시스템(Conditional System)' 문제다. 모델 체급, 컨텍스트 예산, 작업 성격에 맞추지 않은 하네스는 모델에게 날개가 아니라 족쇄가 된다."

---

2. 실험 설계: 실행 루프를 동결하고 3대 축만 분리하다

하네스 실험에서 가장 흔히 발생하는 오류는 컴포넌트 간의 간섭입니다. 계획 로직을 바꾸면서 도구 호출 포맷까지 함께 바꾸면, 성능 변화의 원인이 어디에 있는지 추적할 수 없습니다. 연구팀은 이 간섭을 원천 차단하기 위해 실행 환경의 기본 뼈대를 완벽히 동결했습니다.

┌────────────────────────────────────────────────────────────────────────┐
│  [고정 불변 베이스라인: Execution Engine]                               │
│  ├─ 실행 루프: 표준 ReAct (Thought ──▶ Action ──▶ Observation)         │
│  ├─ 도구 안전 가드레일: 타입 검증, read-before-write 강제, SHA 해시 검사 │
│  ├─ 코드 진단: Python 파일 수정 즉시 ruff / pyflakes 정적 분석 자동 주입│
│  ├─ 교착 상태(Stuck) 감지: 동일 호출 5회 반복 / 동일 실패 8회 연속 시 중단│
│  └─ 오케스트레이션 인프라: LangGraph + Harbor 샌드박스, 작업당 최대 300스텝│
└────────────────────────────────────────────────────────────────────────┘
                                    │
       ┌────────────────────────────┼────────────────────────────┐
       ▼                            ▼                            ▼
[축 1: 컨텍스트 관리]         [축 2: 계획 장치]            [축 3: 행동 도구 공간]
T0 ~ T4 (5단계 계층화)       update_plan 적용 여부        사전 정의 8도구 vs bash-only

테스트베드 모델 및 벤치마크

• 평가 모델군:
• Nemotron-3 계열: 30B (소형) / 120B (중형) / 550B (초대형 프론티어) — SGLang BF16 서빙
• Mistral-Medium-3.5: 128B — OpenRouter 추론
• 벤치마크 데이터셋:
• SWE-Bench Verified: 실제 GitHub 리포지토리의 이슈를 해결하는 500개 소프트웨어 엔지니어링 과제
• Terminal-Bench 2.1: 시스템 설정, 환경 디버깅, 도구 체인을 다루는 89개 복합 터미널 과제

이 엄밀한 통제 덕분에, 각 하네스 컴포넌트가 모델의 행동과 비용에 미치는 순수한 '인과관계'가 수면 위로 드러났습니다.

---

3. 핵심 발견 1: 컨텍스트 관리 — 'LLM 요약'의 환상과 '가지치기'의 진실

에이전트가 긴 호흡의 코딩 작업을 수행하다 보면 컨텍스트 윈도우는 순식간에 차오릅니다. 많은 엔지니어가 이 문제를 해결하기 위해 고비용의 LLM 요약 모듈을 탑재하곤 합니다. 연구팀은 컨텍스트 관리 전략을 5단계 티어(T0 ~ T4)로 세분화하여 그 실효성을 검증했습니다.

[T0: 무관리] ───────────────────────────▶ 윈도우 한도 초과 시 즉시 크래시 (런타임 에러)
[T1: 규칙 기반 생략 (M1)] ──────────────▶ 오래된 도구 실행 결과 본문을 [truncated] 스텁으로 치환
[T2: 생략 + 복구 (M1 + M2)] ────────────▶ 스텁화하되, 필요 시 recall_event 도구로 원문 복구 허용
[T3: 전역 LLM 요약 (M3)] ───────────────▶ 중간 대화 이력 전체를 별도 LLM 호출로 요약 압축
[T4: 단계형 하이브리드 (M1 + M2 + M3)] ─▶ 임계치 B1(60%)에서 M1 발동, B2(85%) 도달 시 M3 요약 트리거

실험 결과: 마법은 '사고력 향상'이 아닌 '조기 사망 방지'였다

비교 지표	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%	0.0%

이 수치는 매우 중대한 통찰을 던집니다. 32k 환경에서 T1~T4를 적용했을 때 얻은 35.7%p라는 경이로운 성능 향상은, 컨텍스트 관리가 에이전트의 지능을 높여주었기 때문이 아닙니다. T0 상태에서는 작업이 끝나기도 전에 10번 중 8번(78.7%)이 컨텍스트 초과 에러로 강제 사형 선고를 받았기 때문입니다. 에이전트의 행동 궤적(Trajectory) 자체는 T0나 T4나 크게 다르지 않았습니다.

복구 레이어(M2)의 역설: LLM은 뒤를 돌아보지 않는다

더 흥미로운 점은 recall_event(T2) 도구의 데이터입니다.
- 총 64개의 실험 조건 중 56.3%의 환경에서 에이전트는 recall_event를 단 한 번(0회)도 호출하지 않았습니다.
- 모델은 이미 지나간 도구의 장황한 원문 출력을 다시 찾아 읽을 필요를 거의 느끼지 못했습니다.
- 따라서 복구 레이어를 유지하는 인프라 비용과 도구 프롬프트 오버헤드는 실질적인 성능(ROI)으로 이어지지 못했습니다.

💡 실무 설계 원칙:
비싼 비용을 들여 LLM 요약(Summarizer) 파이프라인이나 복잡한 벡터 DB 복구 시스템을 구축하기 전에, "오래된 bash/grep 도구 출력을 규칙 기반으로 잘라내는 단순 생략(Elision, M1)"부터 도입하십시오. 이것만으로 컨텍스트 오버플로우 실패의 90% 이상을 틀어막을 수 있습니다.

---

4. 핵심 발견 2: 계획(Planning)의 역설 — 약자에겐 동아줄, 강자에겐 세금

연구팀은 대화 이력을 불필요하게 오염시키지 않고, 매 턴마다 시스템 프롬프트 영역에 에이전트의 현재 계획 상태를 갱신·주입하는 update_plan 도구의 효과를 측정했습니다.

그 결과는 모델의 파라미터 체급에 따라 정반대의 양상으로 나타났습니다.

[소형 모델 (Nemotron-3 30B)]
Planning 활성화 ──▶ SWE-Bench 성공률: 13.6% ──▶ 25.2% (+11.6%p 폭등!)
원인: 실패 시 조기 포기(Early Quitting)를 막고 끝까지 수정을 시도하도록 실행 동기 유지

[초대형 모델 (Nemotron-3 550B)]
Planning 활성화 ──▶ SWE-Bench 성공률: 미세 감소 또는 정체 / 토큰 비용: 약 30% 급감 ($2.33 ──▶ $1.11)
원인: 내부 잠재 공간에서 이미 계획을 세우므로, 불필요한 과잉 검증(Over-verification) 루프 축소

소형 모델: 조기 포기를 막는 '외골격'

30B 수준의 소형 모델은 복잡한 다단계 버그를 만났을 때, 몇 번의 시도가 실패하면 에이전트 루프를 스스로 종료해 버리는 조기 포기 성향을 보입니다. 그러나 눈앞에 명시적인 update_plan 체크리스트를 들이밀어 주면, 모델은 계획 항목을 완수하기 위해 집요하게 코드 수정을 이어가며 성공률을 두 배 가까이 끌어올렸습니다.

초대형 프론티어 모델: 외부 플래너의 인지적 간섭

반면 550B 모델이나 Mistral-Medium(128B) 같은 고성능 모델에게 외부 계획 도구는 성공률 관점에서 아무런 플러스가 되지 못했습니다. 이들 모델은 이미 프롬프트와 컨텍스트를 읽는 과정에서 내재적 계획(Latent Planning)을 수립하기 때문입니다.

오히려 외부에서 계획 작성을 강제하면, 이미 해결된 코드에 대해 불필요하게 검증 단계를 다시 밟는 등 비효율이 발생했습니다. 다만, 이 과잉 행동이 역으로 제어되면서 전체 소모 토큰과 비용이 30%가량 절감되는 '비용 최적화' 효과로 변모했습니다.

💡 현실 프로덕트와의 연결:
Anthropic이 Claude 3.5/3.7 기반 에이전트 환경에서 과거 필수처럼 여겨지던 TodoWrite나 세부 작업 분해 도구를 기본 비활성화(Opt-out)하는 방향으로 선회한 이유가 바로 여기에 있습니다. 프론티어 모델에게 외부 계획 도구는 지능을 돕는 도구가 아니라, 비용과 컨텍스트를 갉아먹는 '세금'에 가깝습니다.

---

5. 핵심 발견 3: 행동 공간(Action Space) — Claude Code가 'bash-first'를 택한 이유

가장 첨예한 논쟁거리였던 도구 인터페이스 비교입니다.
- 사전 정의 도구 세트 (8종): read_file, write_file, edit_file, list_files, glob_files, grep_text, web_fetch, bash (타입 스키마 강제, 자동 린팅 연동)
- bash-only: 전용 파일·검색 도구를 일체 배제하고, 순수 bash 셸 하나만 제공

[Action Space 체급별 성능 대결]

Nemotron-3 30B (소형):
  사전 정의 8도구: ████████████████ 25.2%  (승)
  bash-only:      ██████████ 10.2%        (-15.0%p 폭락)

Nemotron-3 550B (대형):
  사전 정의 8도구: ████████████████████████████████ 65.8% (턴당 $2.33)
  bash-only:      ██████████████████████████████████ 69.4% (턴당 $1.11, 승!)

왜 똑똑한 모델은 bash 하나만 쥐여줄 때 더 강해지는가?

사전 정의된 구조화 도구 환경에서 에이전트는 다음과 같이 행동합니다.
1. list_files 호출 (1턴 소모, LLM 입출력 대기)
2. grep_text 호출 (2턴 소모)
3. read_file 호출 (3턴 소모)
4. edit_file 호출 (4턴 소모)
5. bash로 테스트 실행 (5턴 소모)

하지만 리눅스 명령줄과 파이프라인에 통달한 프론티어 모델에게 bash-only 환경을 제공하면 경이로운 최적화가 일어납니다.

# bash-capable 모델이 단 1턴 만에 실행하는 복합 파이프라인
git diff main...HEAD --name-only | xargs grep -n "handle_auth" && \
sed -i 's/old_token/new_token/g' src/auth.py && \
pytest tests/test_auth.py

탐색, 검사, 수정, 단위 테스트까지의 과정을 단 한 번의 bash 호출에 파이프라인(|, &&)으로 묶어 실행해 버립니다. 그 결과 턴 수가 획기적으로 줄어들고, 입출력 토큰 비용은 $2.33에서 $1.11로 절반 이상(52%) 폭락하며 성공률까지 소폭 상승합니다.

이것이 바로 2026년 현재 가장 뛰어난 CLI 에이전트로 평가받는 Anthropic의 Claude Code가 수십 개의 복잡한 MCP 도구 대신 로컬 bash 셸 중심의 가벼운 인터페이스를 핵심 철학으로 채택한 근거입니다.

엔터프라이즈의 반론: 그래도 MCP를 버릴 수 없는 이유

그렇다면 엔터프라이즈 환경에서도 모든 도구를 걷어내고 bash만 주면 될까요? Hacker News 토론에서 지적되었듯 현실은 그렇지 않습니다.
- 감사 추적(Audit Trail): 어떤 파일의 몇 번째 줄을 왜 수정했는지 엄격히 기록해야 하는 금융·의료 소프트웨어 환경
- 최소 권한 원칙(Principle of Least Privilege): 프로덕션 DB나 내부 네트워크로의 임의 명령 실행 방지
- OAuth 인증 및 시크릿 격리: API 키를 셸 환경 변수에 노출하지 않고 안전하게 주입

이러한 규제 준수(Compliance) 환경에서는 여전히 엄격한 스키마를 가진 도구와 MCP(Model Context Protocol) 레이어가 필수적입니다. 즉, bash-only는 '성능과 비용의 극대화'를 위한 최적해이며, 구조화 도구는 '통제와 안전'을 위한 필수 타협점입니다.

---

6. 하네스 아키텍처 의사결정 프레임워크

이 모든 실증 연구의 결과를 단 하나의 수식으로 요약하면 다음과 같습니다.

$$\text{하네스 최적 설계} = f(\text{모델의 지능 체급}, \text{컨텍스트 예산}, \text{보안 규제 수준})$$

사내 혹은 개인 프로젝트에서 코딩 에이전트를 구축할 때 참고할 수 있는 아키텍처 의사결정 트리입니다.

flowchart TD
    Start["코딩 에이전트 하네스 설계 시작"] --> Q1{"사용 모델 체급이<br/>프론티어(70B+ / Claude / GPT)급인가?"}

    Q1 -- "아니오 (30B 이하 소형 모델)" --> WeakPath["[소형 모델 최적화]"]
    WeakPath --> W_Plan["Planning: update_plan 필수 활성화<br/>(조기 포기 방지 및 완주율 보장)"]
    W_Plan --> W_Tool["Action Space: 엄격한 8종 전용 도구 세트<br/>(bash 단독 사용 금지, 문법 오류 방지)"]
    W_Tool --> W_Ctx["Context: T4 하이브리드 필수<br/>(60% 생략 + 85% LLM 요약)"]

    Q1 -- "예 (프론티어 / 대형 모델)" --> StrongPath["[대형 모델 최적화]"]
    StrongPath --> Q2{"엔터프라이즈 감사 로그 및<br/>엄격한 시크릿 격리가 필수인가?"}

    Q2 -- "예 (엔터프라이즈 규제 환경)" --> EntMode["Action Space: MCP / 구조화 도구 강제<br/>+ 감사 추적 로거 탑재"]
    Q2 -- "아니오 (개발자 개인 / 로컬 CLI)" --> CliMode["Action Space: bash-first 극단적 단순화<br/>(다단계 파이프라인 허용)"]

    EntMode --> S_Plan["Planning: 상위 목표만 주입<br/>(세부 Todo 강제 비활성화하여 오버헤드 축소)"]
    CliMode --> S_Plan

    S_Plan --> Q3{"컨텍스트 윈도우 크기는?"}
    Q3 -- "32k ~ 64k (로컬/경량)" --> S_CtxNarrow["Context: T1 규칙 기반 도구 출력 생략(M1)<br/>(LLM 요약 불필요, 스텁 치환만으로 충분)"]
    Q3 -- "128k 이상 (롱컨텍스트)" --> S_CtxWide["Context: 최소한의 슬라이딩 윈도우<br/>(하네스 개입 최소화, 턴 보존)"]

환경별 추천 하네스 스펙 매트릭스

하네스 레이어	온프레미스 경량 환경 (30B급, 32k)	엔터프라이즈 환경 (프론티어 모델)	개발자 CLI 샌드박스 (Claude Code 스타일)
Context Management	T4 (60% 생략 + 85% 요약)	T1 (도구 출력 규칙 기반 생략)	T1 (장황한 stdout/stderr 스텁화)
Planning Layer	On (update_plan 필수 주입)	Minimal (고수준 마일스톤만)	Off (모델 내재적 계획에 위임)
Action Space	구조화 전용 도구 (8종 스키마)	MCP / 구조화 도구 (권한 통제)	bash-only / bash-first (파이프라인)
설계 핵심 목표	작업 완주율 (생존율)	보안, 감사 추적, 재현성	턴 수 단축 및 토큰 비용 극소화

---

7. 한계와 남겨진 과제

이 연구가 하네스 엔지니어링에 던진 빛은 거대하지만, 해석 시 주의해야 할 경계선도 존재합니다.

1. 독점 프론티어 모델의 부재: 실험이 Nemotron-3와 Mistral 계열 오픈 가중치 모델 중심으로 진행되어, OpenAI o-시리즈(o1/o3)나 Anthropic Claude 3.7 Sonnet의 Thought Chain 내부 동작과의 직접 비교는 다루지 못했습니다.
2. "bash-capable" 지표의 모호성: 어떤 모델이 bash-only를 감당할 수 있는지에 대한 사전 정량화 기준(Pre-qualification)이 없어, 엔지니어가 직접 벤치마크를 돌려보며 판별해야 합니다.
3. 블라인드 평가의 부재: 에이전트가 스스로 작성한 테스트 코드 통과 여부에 의존하는 벤치마크 특성상, 실제 인간 시니어 개발자가 체감하는 코드 아키텍처 품질과의 괴리가 존재할 수 있습니다.

---

8. 결론: 똑똑해진 모델에게 가장 좋은 하네스는 '가장 얇은 하네스'다

초기 AI 에이전트 개발 시절, 우리는 멍청한 LLM을 어떻게든 일하게 만들기 위해 온갖 복잡한 장치를 덧대었습니다. 수백 줄짜리 프롬프트 템플릿, 엄격한 JSON 스키마, 자기 반성(Self-Reflection) 루프, 강제된 Todo 리스트까지.

하지만 UMass와 Zoom의 이번 연구가 우리에게 던지는 최종 교훈은 매우 명확합니다.

"모델이 진화할수록 하네스는 두꺼워지는 것이 아니라, 더 얇고 투명해져야(Thinner Harness) 한다."

모델의 추론 역량이 충분하다면, 하네스가 해야 할 일은 그 앞길을 사사건건 가로막으며 계획을 검사하는 것이 아닙니다.
- 컨텍스트 오버플로우로 작업이 터지지 않도록 오래된 도구 출력을 조용히 쳐내주고(M1),
- 리눅스 셸이라는 가장 원초적이고 강력한 무기를 쥐여준 뒤,
- 모델이 온전히 자신의 추론 능력으로 코드를 작성하고 검증할 수 있도록 방해하지 않는 것입니다.

에이전트의 성능이 나오지 않아 고민하고 계신가요? 프롬프트에 새로운 지침을 추가하고 복잡한 LangGraph 노드를 늘리기 전에, 여러분의 하네스가 똑똑해진 모델의 발목을 잡고 있는 것은 아닌지 가장 먼저 점검해 보시기 바랍니다.

---

관련 글:
- 프롬프트는 실재하지 않는다: 프로덕션 AI 에이전트와 자기 교정 하네스 아키텍처
- 하네스 엔지니어링 — 모델 환경과 제어 구조 설계