[AI] 하네스 엔지니어링 — 같은 모델인데 왜 성능이 18%p나 달라질까?

rubrub 2026. 9. 3. 23:49

AI Agent 이야기를 하다 보면 결국 대화가 이쪽으로 흘러간다.

THE DEFAULT QUESTION

“그래서 어떤 모델이 제일 좋아요?”

GPT냐 Claude냐 Gemini냐. Benchmark 몇 점인지, reasoning이 얼마나 좋은지, coding 성능이 몇 퍼센트인지 비교한다.

물론 모델은 중요하다. 그런데 2026년 Agent 생태계를 보다 보면, 모델만 비교하는 순간 시스템의 절반을 놓치고 있다는 느낌이 든다.

대표적인 사례가 Terminal-Bench다.

SAME MODEL, DIFFERENT HARNESS

Claude Opus 4.6는 그대로인데
Agent Harness를 바꾸자 성능이 크게 달라졌다.

Addy Osmani는 한 팀이 Terminal-Bench 2.0에서 모델을 바꾸지 않고 Harness만 바꿔 Top 30권에서 Top 5권으로 올라간 사례를 소개한다.

공개된 Terminal-Bench 2.0 결과를 숫자로 보면 더 직관적이다. 같은 Claude Opus 4.6이 Claude Code에서는 58.0%, Terminus 2에서는 62.9%, 공개 Meta-Harness에서는 76.4%를 기록했다.

CLAUDE CODE

58.0%

TERMINUS 2

62.9%

META-HARNESS

76.4%

같은 weights인데 18.4%p가 벌어진다.

이 정도면 Harness를 “모델 주변의 부가 기능”이라고 부르기 어렵다.

TL;DR

Agent 성능은 모델의 함수가 아니라
Model × Harness × Environment의 함수에 가깝다.

01. Harness Engineering이 정확히 뭐지?

Addy Osmani가 정리한 표현은 아주 단순하다.

      Agent = Model + Harness
    

모델이 “두뇌”라면 Harness는 그 두뇌가 실제 세상에서 일을 할 수 있게 만드는 신경계 + 손발 + 작업환경 + 안전장치에 가깝다.

구체적으로는 이런 것들이 전부 Harness다.

System Prompt AGENTS.md Tools / MCP Filesystem / Git Sandbox Memory Context Policy Hooks Permissions Sub-agents Tracing / Eval Recovery Loop

즉 Harness Engineering은 단순히 prompt를 잘 쓰는 일이 아니다.

비결정적인 모델을 둘러싸고, 최대한 결정적인 실행 시스템을 설계하는 작업에 가깝다.

02. 내가 보는 Agent Harness의 구조

AGENT HARNESS ARCHITECTURE

Context
Prompt · Skills · Memory

Control
Plan · Loop · Routing

Policy
Hooks · Permission

↓

MODEL

Reason · Decide · Generate

↓

Action
Tools · Bash · MCP

State
Filesystem · Git

Runtime
Sandbox · Browser

↓

Feedback
Tests · Lint · Typecheck · Eval

Observation
Trace · Cost · Failure

좋은 Harness는 이 모든 레이어를 많이 넣는 Harness가 아니다.

모델이 혼자서 안정적으로 못 하는 행동만 정확하게 보완하는 Harness가 좋다.

03. 그런데 Benchmark 숫자는 조금 조심해서 봐야 한다

“같은 모델인데 18.4%p 차이”는 꽤 강한 신호지만, 이것을 완벽하게 통제된 A/B 실험으로 읽으면 안 된다.

Harness마다 prompt, token budget, tool strategy, 환경 bootstrap, iteration 수 등 여러 조건이 같이 달라질 수 있기 때문이다.

BENCHMARK CAVEAT

Terminal-Bench 팀은 이후 2.1에서 2.0의 89개 task 중 28개를 수정했다. 예를 들어 Claude Code + Opus 4.6은 2.0의 58.0%에서 2.1에서는 70.1%로 크게 변했다.

그래서 개별 “순위”보다 더 중요한 takeaway는 agent score가 model weights만의 속성이 아니라는 사실이다.

오히려 이 caveat 자체가 Harness Engineering의 중요성을 보여준다.

Agent benchmark에서는 모델뿐 아니라 환경, tool contract, scaffolding, verifier, runtime이 성능의 일부다.

04. ① Filesystem + Git — 가장 지루하고, 가장 중요한 State Layer

모델은 context window 안에 있는 정보만 직접 다룬다. 긴 작업에서 모든 중간 결과를 대화 context에 계속 들고 있는 건 비효율적이다.

그래서 filesystem이 Agent에게 일종의 외부 작업 기억이 된다.

    context window

    ├── current task

    ├── relevant instructions

    └── recent observations

    filesystem

    ├── plan.md

    ├── investigation.md

    ├── generated artifacts

    ├── test output

    └── handoff.md

여기에 Git이 붙으면 더 강력해진다.

Diff
무엇을 바꿨나

Rollback
실패 전으로

Branch
병렬 실험

Multi-agent를 돌릴 때도 filesystem과 worktree는 각 Agent의 작업 범위를 격리하는 가장 실용적인 primitive 중 하나다.

05. ② Sandbox — Bash를 주려면 감옥부터 만들어야 한다

Coding Agent에게 bash는 굉장히 강력하다. 파일을 찾고, 패키지를 설치하고, 테스트를 실행하고, 필요한 작은 script를 그 자리에서 만들 수 있다.

반대로 말하면 굉장히 위험하다.

    rm -rf ...

    git push --force ...

    curl sensitive-data ...

    DROP TABLE ...

    pip install random-package ...

그래서 bash와 sandbox는 사실 한 세트로 봐야 한다.

Agent
↓
Permission Gate
↓
Isolated Sandbox
↓
Filesystem · Shell · Browser · Test Runner
↓
Disposable Environment

좋은 sandbox는 단순 Docker container가 아니라 network policy, command policy, credential boundary, resource limit, snapshot까지 포함한다.

06. ③ Memory보다 더 중요한 단어: Context Budget

많은 팀이 Agent에 memory를 붙이면 무조건 좋아질 거라고 생각한다.

실제로는 무엇을 기억시키느냐만큼 무엇을 context에서 빼느냐가 중요하다.

Addy Osmani가 정리한 대표적인 패턴은 세 가지다.

Compaction

오래된 context를 요약하고 핵심 state만 남긴다.

Tool-output Offloading

수천 줄 로그를 prompt에 넣지 않고 파일로 보낸다.

Progressive Disclosure

필요한 Skill과 instruction만 그때그때 로딩한다.

이걸 보면 Harness Engineering이 사실상 Context Engineering의 실행 계층이라는 말이 이해된다.

THE WRONG GOAL

“Agent에게 모든 정보를 주자” ✗

THE BETTER GOAL

“지금 필요한 정보만 정확히 주자” ✓

07. ④ AGENTS.md — 길게 쓰면 오히려 나빠질 수도 있다

이 부분은 2026년에 꽤 재미있는 연구 결과가 나왔다.

ETH Zürich 연구진은 repository-level context file이 실제 coding agent 성능을 높이는지 테스트했다. 결과는 예상보다 미묘했다.

LLM-GENERATED

≈ -3%

Task success

HUMAN-WRITTEN

≈ +4%

Task success

두 경우 모두 inference cost는 대략 20% 이상 증가했다.

핵심은 AGENTS.md가 무용지물이라는 뜻이 아니다.

Agent가 code에서 스스로 발견할 수 있는 repository overview까지 길게 설명하면 오히려 reasoning budget을 잡아먹는다는 뜻에 가깝다.

좋은 AGENTS.md에 남길 것

✓ 특이한 build / test command
✓ 절대 건드리면 안 되는 directory
✓ 조직 고유 security rule
✓ 자동으로 추론하기 어려운 architecture constraint
✓ 과거에 실제로 반복된 실패를 막는 규칙

HumanLayer가 AGENTS.md를 60줄 안팎으로 유지한다는 원칙도 이런 맥락이다.

Rulebook이지 Encyclopedia가 아니다.

08. ⑤ Hooks — “말해두기”와 “강제하기”의 차이

Harness에서 개인적으로 가장 중요한 요소 중 하나가 Hook이다.

Prompt에 이렇게 쓰는 것과,

    Never push directly to main.
  

시스템이 실제로 git push origin main을 차단하는 것은 완전히 다른 이야기다.

      python · deterministic hook
    

BLOCKED_PATTERNS = [
    "rm -rf",
    "git push --force",
    "git push origin main",
    "DROP TABLE",
]

def before_shell(command: str) -> None:
    if any(pattern in command for pattern in BLOCKED_PATTERNS):
        raise PermissionError(
            f"Blocked destructive command: {command}"
        )

실제로는 단순 문자열 match보다 command parser와 policy engine을 쓰는 편이 낫겠지만, 원칙은 같다.

HARNESS PRINCIPLE

Prompt는 요청한다.
Hook은 강제한다.

09. ⑥ Back-pressure — 성공은 조용하게, 실패는 시끄럽게

HumanLayer와 Addy가 공통적으로 강조한 표현 중 마음에 든 게 있다.

Success is silent.
Failures are verbose.

예를 들어 Agent가 파일을 수정할 때마다 typecheck를 돌린다고 해보자.

    File Edit

    ↓

    typecheck

    ├── PASS → 아무 메시지 없음

    └── FAIL → error text를 Agent context로 주입

            ↓

          Agent self-corrects

중요한 건 “Agent가 테스트해야 한다는 걸 기억하길 기대하는 것”이 아니다.

Harness가 Agent의 행동 결과에 deterministic feedback을 주는 것이다.

이 feedback loop가 좋아질수록 모델의 self-correction 능력을 훨씬 잘 끌어낼 수 있다.

10. ⑦ Permission — 똑똑함과 권한은 별개의 축이다

모델이 아무리 똑똑해져도, production Agent에게 모든 권한을 주는 건 좋은 설계가 아니다.

Action	Default	Harness Control
Read source code	Allow	Workspace scope
Run unit tests	Allow	Sandbox only
Install package	Conditional	Registry allowlist
Network access	Conditional	Domain policy
Merge / deploy / DB write	Deny / HITL	Explicit approval + audit

특히 금융권에서는 destructive / external-side-effect action을 Harness의 permission gate 뒤에 두는 게 자연스럽다.

모델이 “이 작업은 안전합니다”라고 판단했다고 해서 permission이 생기는 구조는 피해야 한다.

11. ⑧ Tool Design — 도구가 많다고 Agent가 강해지는 건 아니다

Agent에게 Tool을 붙이기 시작하면 욕심이 난다.

    Jira Tool

    GitHub Tool

    Slack Tool

    Search Tool

    Database Tool

    Browser Tool

    Internal API Tool

    ...

    MCP Server 12개

그런데 Tool의 name, description, schema도 결국 context에 들어간다.

HumanLayer는 이 관점에서 “10개의 집중된 Tool이 50개의 겹치는 Tool보다 낫다”고 정리한다.

MCP도 Supply Chain이다

MCP server의 tool description과 결과는 Agent context에 들어간다. 따라서 “편하니까 일단 연결”이 아니라 package dependency처럼 신뢰 경계를 관리해야 한다.

특히 third-party skill / MCP는 prompt injection + arbitrary code execution의 공급망이 될 수도 있다.

12. ⑨ Long-horizon Agent — Planner와 Evaluator를 분리한다

복잡한 작업에서 Agent가 흔히 실패하는 패턴은 두 가지다.

EARLY STOP

아직 안 끝났는데 끝났다고 함

SELF-BIAS

자기가 만든 결과를 자기가 후하게 평가

그래서 Harness에서 역할을 분리하는 패턴이 나온다.

Planner
task decomposition / done criteria
↓
Executor
implement / search / tool use
↓
Evaluator
test / review / verify
↓
PASS ? Finish : Re-plan ↺

모델 하나를 세 번 부르는 게 항상 정답은 아니지만, 생성 책임과 검증 책임을 분리한다는 아이디어는 production Agent에서도 유효하다.

13. “Skill Issue” — 실패를 모델 탓으로 끝내지 않는 방법

HumanLayer가 Harness Engineering을 설명하면서 사용하는 framing이 재미있다.

OLD RESPONSE

“모델이 아직 별로네. 다음 버전을 기다리자.”

HARNESS RESPONSE

“왜 실패했지? 이 실패를 다시 못 하게 무엇을 시스템화하지?”

이 관점에서 실패는 bug report가 아니라 Harness 요구사항이 된다.

Observed Failure	Harness Fix
테스트를 주석 처리하고 완료	AGENTS.md rule + diff hook + reviewer check
위험한 bash 실행	Pre-tool policy / permission gate
최신 API를 몰라 오래된 코드 생성	Docs search / MCP / curated skill
복잡한 작업 중 조기 종료	Plan file + done criteria + evaluator loop
긴 로그 때문에 context 오염	Tool-output offloading + summary

14. 좋은 Harness는 한 번 설계하는 게 아니라 “Ratchet”처럼 자란다

Harness Engineering에서 가장 마음에 드는 개념은 이 부분이다.

Production Failure
↓
Root Cause
↓
Rule / Hook / Tool / Context Fix
↓
Regression Eval
↓
Harness vNext
↺

즉 “좋은 Harness”는 인터넷에서 복사해 오는 완제품이 아니다.

우리 codebase와 우리 조직이 실제로 겪은 실패 이력의 압축본에 가깝다.

그래서 모든 규칙을 처음부터 상상해서 넣으면 오히려 noise가 된다.

Harness Ratchet Principle

1. 실제 failure를 관측한다.
2. 재현 가능한 원인을 찾는다.
3. 가장 작은 deterministic control을 추가한다.
4. benchmark / regression으로 효과를 확인한다.
5. 효과 없으면 제거한다.

15. 금융권 Agent에서는 Harness가 사실상 Risk Control Layer다

Coding Agent에서는 잘못된 command가 문제지만, 금융 업무 Agent에서는 잘못된 business action이 문제가 된다.

예를 들어 보험 업무 Agent가 있다고 해보자.

FINANCIAL AGENT HARNESS

User / Employee / Business System

↓

Identity
Who?

Scope
Which Customer?

Policy
Which Action?

↓

Agent / Model
Reason · Retrieve · Plan

↓

Tool Guardrail / Approval Gate
Read ✓ · Recommend ✓ · Update ? · Pay ✗/HITL

↓

Internal APIs
Least Privilege

RAG / DB
Versioned Context

↓

Audit / Trace

Budget / Loop Limit

Kill Switch

여기서 핵심은 모델 prompt에 “조심해”라고 쓰는 것이 Risk Control이 아니라는 것이다.

Permission, audit, data scope, network, tool side effect는 Harness에서 결정적으로 강제해야 한다.

16. Harness-as-a-SDK는 이미 진행 중이다

그래서 요즘 Agent SDK들을 보면 결국 같은 primitive들이 빠르게 들어오고 있다.

Primitive	왜 필요한가
Agent Loop	Tool 결과를 다시 모델에 넣고 완료까지 반복
Sessions / State	장기 작업과 대화 상태 유지
Handoffs / Sub-agents	전문 역할 분리와 context isolation
Guardrails	Input / output / tool 실행 전후 검증
Sandbox	Shell / filesystem 작업을 격리
Tracing	Agent trajectory와 failure 관측

예를 들어 OpenAI Agents SDK도 현재 agent loop, tools, handoffs, guardrails, sessions, HITL, tracing, sandbox agent 같은 primitive를 제공한다.

이 방향을 보면 앞으로 팀이 모든 Harness를 밑바닥부터 직접 짜기보다는, SDK/runtime이 공통 primitive를 제공하고 조직은 context · tool · policy · eval을 커스터마이징하는 쪽으로 갈 가능성이 높다.

하지만 Vendor SDK = 완성된 Harness는 아니다

SDK가 loop와 guardrail primitive를 제공해도, 우리 조직의 failure history, permission model, business policy, test criteria까지 대신 만들어주지는 않는다.

진짜 경쟁력은 여전히 이 조직-specific layer에 남는다.

17. 사내 Agent를 만든다면 나는 이 순서로 Harness를 만든다

Workspace / State부터 만든다

Filesystem, Git, task state, resumability.

Tool surface를 최소화한다

처음부터 MCP 20개를 연결하지 않는다.

Permission / Sandbox를 먼저 설계한다

Agent가 잘못해도 blast radius가 작도록.

Feedback Hook을 붙인다

Tests, lint, schema validation, policy check.

실패한 것만 AGENTS.md에 올린다

Rule은 brainstorm이 아니라 incident에서 파생한다.

Trace + Eval로 Harness 자체를 평가한다

느낌이 아니라 task success / cost / latency로 비교.

18. 모델이 좋아질수록 Harness는 없어질까?

얼핏 생각하면 그렇다.

모델이 planning을 더 잘하면 planner가 필요 없어지고, 긴 context를 더 잘 다루면 compaction이 덜 필요해질 수 있다.

실제로 Harness의 일부 component는 모델이 좋아지면 사라질 것이다.

그런데 재미있는 건 Harness 자체가 없어지는 게 아니라 역할이 이동한다는 점이다.

    Better planning model

    → planning scaffold ↓

    Longer context

    → compaction pressure ↓

    More capable agent

    → harder tasks ↑

    → longer horizon ↑

    → more permissions ↑

    → more verification ↑

    → new harness requirements ↑

모델의 ceiling이 올라가면 우리가 Agent에게 맡기려는 업무의 ceiling도 같이 올라간다.

그래서 Harness Engineering은 “약한 모델을 보완하는 임시 기술”이라기보다, Agent capability를 production reliability로 변환하는 시스템 엔지니어링에 더 가깝다고 본다.

MY TAKE

좋은 모델은 Agent의 가능성을 높인다.
좋은 Harness는 그 가능성을 재현 가능한 성능으로 바꾼다.

이제 “어떤 모델을 쓸까?”와 함께 하나를 더 물어야 한다.

“그 모델이 실패했을 때, 우리 시스템은 무엇을 배우는가?”

그 질문에 답하는 게 Harness Engineering인 것 같다.