모델은 똑똑한데
왜 Agent는 자꾸 이상한 짓을 할까?
Google이 2026년 다시 꺼낸 Harness Engineering.
Prompt보다 Tool, State, Permission, Eval, Runtime이 중요해지는 이유를 최신 논문과 함께 뜯어본다.
이런 문제를 보면 우리는 먼저 Prompt를 고친다. “반드시 테스트를 실행하세요.” 그래도 또 빠뜨리면 대문자로 쓴다. “IMPORTANT: 반드시 테스트!”
그런데 여기서 문제가 하나 생긴다. 테스트 실행이 정말 반드시 지켜야 할 규칙이라면, 왜 그 규칙의 집행을 확률적으로 말을 듣는 LLM에게 맡기고 있을까?
“그 모델이 어떤 실행 환경 안에서 행동하게 만드느냐”로 이동하고 있다.
Harness는 Prompt를 감싸는 포장지가 아니다
가장 직관적인 정의는 간단하다.
모델은 다음 토큰을 생성한다. 하지만 실제 Agent는 그것만으로 움직이지 않는다. 어떤 tool을 쓸 수 있는지, tool 호출 결과를 어떻게 다시 context에 넣는지, 실패했을 때 재시도할지 중단할지, 명령어 실행 전에 승인을 받을지, context가 길어지면 무엇을 버릴지, 완료 조건을 어떻게 검증할지를 누군가 결정해야 한다. 그 “누군가”가 Harness다.
Chatbot은 틀리면 답만 틀렸다. Agent는 버튼을 누른다
Chatbot 시절에는 모델이 틀리면 “답변 품질” 문제로 끝나는 경우가 많았다. Agent는 다르다. 파일을 수정하고, DB를 조회하고, 코드를 실행하고, API를 호출하고, 때로는 결제·배포·승인 같은 실제 업무를 수행한다.
여기서부터는 모델의 평균 지능보다 실행 경로의 통제 가능성이 중요해진다. 같은 prompt를 주더라도 실행 순서가 달라지고, 어떤 run에서는 검증을 하고 어떤 run에서는 건너뛸 수 있다. Production에서는 이 변동성이 곧 장애·보안·감사 문제다.
| 문제 | Prompt만으로 해결? | Harness에서 다룰 것 |
|---|---|---|
| 잘못된 Tool 호출 | 부분적으로 가능 | Tool allowlist, schema, permission |
| 검증 없이 완료 선언 | 쉽게 회귀 | verify-on-stop, completion gate |
| Context 폭주 | 어려움 | compaction, memory policy, token budget |
| 권한 없는 데이터 접근 | 불가 | Authorization, tool-side filter, policy enforcement |
| 모델 교체 시 행동 변화 | 예측 어려움 | behavioral eval, trace regression test |
Google의 포인트: “점수 몇 점?”보다 “도중에 뭘 했는데?”
2026년 9월 9일 Google Developers Blog의 The Anatomy of Harness Engineering은 Harness Engineering을 특히 behavioral evaluation 관점에서 설명한다.
흔히 Agent를 평가할 때 “SWE-Bench 몇 점”, “Terminal-Bench 몇 점”처럼 최종 성공률을 본다. 물론 중요하다. 하지만 점수가 떨어졌을 때 원인은 알기 어렵다. 모델이 애매한 요청에서 추측했는지, 테스트를 안 돌렸는지, 존재하지 않는 CLI 옵션을 만들어냈는지 최종 pass/fail만으로는 분해가 안 된다.
이 관점은 꽤 중요하다. Agent는 계산기처럼 같은 입력에 늘 같은 경로를 밟는 프로그램이 아니다. 그래서 모든 trajectory를 정확히 고정하려 들면 정상적인 다른 해결 경로까지 막을 수 있다. 단순한 행동은 strict assertion으로 검사하고, 복잡한 작업은 outcome-based check나 judge를 섞어야 한다.
# 나쁜 평가: 마지막 답변 문자열만 비교
assert response.text == "done"
# 더 나은 behavioral eval
trace = run_agent(task)
assert trace.used_tool("unit_test")
assert trace.modified_only(allowed_paths)
assert trace.exit_reason == "verified"
assert trace.policy_violations == 0Google 글의 또 다른 포인트는 dogfooding → behavioral eval → macro benchmark의 순서다. 초기부터 거대한 eval framework를 만들기보다 먼저 Agent가 자기 코드베이스에서 실제 일을 하게 만들고, 반복되는 실패 패턴이 보이기 시작하면 그 실패를 작은 regression test로 고정한다. 이후 큰 benchmark는 전체 목적지의 품질을 확인하는 용도로 사용한다.
2026년, Harness가 하나의 연구 분야가 되기 시작했다
1. Harness Engineering: 실제 제품 코드를 뜯어보니
2026년 7월의 Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents는 Claude Code, Codex CLI, Gemini CLI, Mistral Vibe, OpenHands, Aider 등 11개 coding harness를 source-code 수준에서 비교했다.
이 논문의 여기서 꽤 재밌는 부분은 “Agent를 어떻게 만들어야 한다”는 개념도를 그린 것이 아니라, 실제 production system이 어디에 코드를 많이 쓰고 어떤 방식으로 수렴하는지를 봤다는 점이다. 연구진은 공통 구조를 Agent loop, tool execution, context/memory, safety, orchestration, extensibility 등의 subsystem으로 분해하고 29개의 반복 패턴을 정리한다.
연구 대상 약 400만 라인의 코드에서 일반-purpose agent framework를 runtime dependency로 쓰는 경우가 없었고, code retrieval에 embedding 기반 RAG를 쓰는 harness도 없었다고 보고한다. 실제 제품은 생각보다 “거대한 agent framework”보다 hand-rolled loop, deterministic file/search primitives, 세밀한 permission과 context 관리에 가까웠다.
이 결과를 “LangChain이나 vector search가 쓸모없다”로 읽으면 안 된다. 연구 범위가 coding harness이고, repository 탐색은 symbol/path/grep처럼 강한 deterministic signal을 갖는다. 다만 한 가지는 분명하다. Agent가 복잡해질수록 abstraction을 많이 쌓는 것이 자동으로 좋은 architecture가 되는 것은 아니다.
2. AHE: Harness도 스스로 개선할 수 있을까?
4월 공개된 Agentic Harness Engineering은 Harness 개선을 사람이 prompt를 조금씩 고치는 작업이 아니라 관측 가능한 closed loop 최적화 문제로 바꾼다.
핵심은 세 가지 observability다. 무엇을 수정했는지 추적하는 component observability, 긴 trajectory에서 실패 원인을 압축해주는 experience observability, 그리고 “이 수정이 어떤 결과를 낼 것이라고 예상했는가”를 기록하는 decision observability다.
논문 보고값 기준으로 10회의 개선 iteration 뒤 Terminal-Bench 2 pass@1이 69.7%에서 77.0%로 상승했고, frozen harness를 다른 model family에 적용했을 때도 +5.1~10.1 percentage point의 개선을 보고했다. Ablation에서는 system prompt보다 tools, middleware, long-term memory 쪽 변경이 더 중요한 성능 기여를 보였다.
3. HarnessDev: AI가 자기 Harness를 직접 만들면 인간을 이길까?
2026년 9월의 HarnessDev는 질문을 더 밀어붙인다. LLM에게 주어진 Harness 안에서 문제를 풀게 하지 않고, Harness 자체를 만들고 고치게 한다.
결과는 낭만적이지만은 않다. 생성된 Harness는 coding과 search/research 영역에서 성숙한 human-engineered reference보다 아직 크게 뒤처졌고, writing과 일부 ML experimentation에서는 비슷하거나 더 높은 결과도 보였다. Evolution 단계의 개선 역시 불안정했고, 다른 runtime model로 바꾸면 이득이 잘 전달되지 않았다.
즉 “Agent가 자기 Agent runtime까지 알아서 최적화하는 시대”는 방향으로는 흥미롭지만, 현재 Production에서 완전히 맡겨도 된다는 증거는 아니다. 특히 금융권에서는 self-evolving harness보다 human-gated harness evolution이 현실적이다.
4. Predictable Agentic Systems: 결정성을 높이면 무조건 좋아질까?
8월 논문은 finance·legal synthetic task와 두 open-weight model을 대상으로 finite-state control, forced tool selection, output validation, bounded retry 같은 deterministic constraint를 실험했다.
첫 번째 결과는 의외다. 단순히 constraint를 넣는다고 항상 좋아지지 않았다. 어떤 조합에서는 reproducibility가 오히려 악화됐다. 원인을 추적하니 free-text planning이 새로운 variance source가 되고 있었다. 이후 plan을 fixed schema로 검증하는 Structured Planning을 추가하자 4개 cell 중 3개에서 reproducibility 지표가 1.000에 도달했고, 3개 cell에서 task success가 100%가 됐다.
하지만 latency는 model에 따라 반대 방향으로 움직였다. 이 부분이 중요하다. Harness의 통제 강화는 공짜가 아니다. Reliability, token cost, latency를 같이 측정해야 한다.
5. 최신 보안 연구: 이제 Harness 자체가 Supply Chain이다
9월 7일 공개된 Scanning the Harness는 3,171개 공개 GitHub repository의 coding-agent configuration을 분석했다. 연구 대상은 instruction file, skill, hook, MCP server declaration, subagent 설정 등 우리가 흔히 “Agent 설정”이라고 가볍게 보는 artifact들이다.
논문은 검증된 기준으로 전체 setup의 16.0%에서 security defect를 보고했다. 예를 들어 MCP server가 version pin 없이 설치되거나, 겉보기에는 제한적으로 보이는 permission이 사실상 arbitrary execution을 허용하거나, 배포되는 skill 자체가 shell 실행을 사전 승인하는 경우가 있었다.
Prompt를 더 세게 쓰는 것과 Harness는 완전히 다르다
| 구분 | Prompt Engineering | Agent Framework | Harness Engineering |
|---|---|---|---|
| 주요 대상 | 모델 입력 | 개발 abstraction | 실행 runtime 전체 |
| 핵심 질문 | 어떻게 지시할까? | 어떻게 조립할까? | 어떻게 안전하고 반복 가능하게 실행할까? |
| 실패 대응 | 문구 수정 | node/graph 수정 | policy·tool·state·validator·eval 수정 |
| 보장 수준 | 확률적 지시 | 구조 제공 | 코드·schema·policy로 enforce 가능 |
셋은 경쟁 관계가 아니다. Prompt는 Harness의 한 구성요소일 수 있고, LangGraph·AutoGen 같은 framework를 이용해 Harness를 구현할 수도 있다. 중요한 차이는 관심의 초점이다. Harness Engineering은 “모델에게 무엇을 말할까?”보다 “모델이 어떤 조건에서 무엇을 할 수 있고, 실패했을 때 시스템이 무엇을 보장할까?”에 더 가깝다.
“반드시”라는 단어가 나오면 Prompt 밖으로 꺼내라
금융권 관점에서 가장 중요한 관련 논문은 7월의 From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents다. 이 논문의 메시지는 단순하다.
이 연구는 세 hosted model에 대해 270회의 composition-boundary run을 수행했고, Harness가 강제하는 source grounding, routing, trace, output hygiene 등의 contract는 유지되었다고 보고한다. 반면 prompt-only 조건에서는 recommendation wording과 internal trace leakage 위반이 사용자에게 도달했다. 외부 guardrail을 덧붙이면 차단은 가능했지만 과도한 refusal로 utility가 감소했다.
이 결과 하나로 모든 Enterprise Agent가 같은 설계를 써야 한다는 뜻은 아니다. 하지만 “must” 조건은 자연어가 아니라 executable contract로 옮겨야 한다는 방향은 매우 실무적이다.
금융권에서는 Harness가 곧 실행 통제선이다
1. Tool마다 권한 모델이 있어야 한다
Agent에게 “DB tool” 하나를 주는 대신 read-only query, customer lookup, policy retrieval처럼 권한 범위를 작은 capability로 나누는 편이 좋다. shell이나 arbitrary SQL 같은 범용 tool은 가장 높은 risk tier로 관리해야 한다.
2. State transition을 명시한다
상담 Agent가 조회에서 바로 계약 변경으로 넘어가서는 안 된다.
예를 들어 IDENTIFY → ELIGIBILITY_CHECK → RETRIEVE → PROPOSE → APPROVE → EXECUTE처럼
상태 전이를 코드로 정의하면 “모델이 알아서 순서를 지키겠지”에 의존하지 않게 된다.
3. Output은 자연어가 아니라 Contract다
고객에게 보여줄 답변이 citation, disclaimer, confidence, action type을 반드시 포함해야 한다면 JSON schema 또는 typed model로 검증해야 한다. validation 실패 시 재생성·fallback·human handoff를 명시한다.
class Claim(BaseModel):
text: str
source_id: str
page: int
class AgentOutput(BaseModel):
answer: str
claims: list[Claim]
action: Literal["answer", "ask", "handoff"]
risk_level: Literal["low", "medium", "high"]
result = model.invoke(context)
validated = AgentOutput.model_validate_json(result)
if validated.risk_level == "high":
return require_human_approval(validated)4. Trace는 운영 로그가 아니라 평가 데이터다
좋은 Harness는 단순히 “에러가 났다”를 남기지 않는다. 어떤 model version이 어떤 tool을 왜 선택했고, policy check가 무엇을 통과·거절했고, retry가 몇 번 일어났으며, 최종 답변이 어떤 source를 사용했는지 재현할 수 있어야 한다.
Agent에게도 회귀 테스트가 필요하다
Harness Engineering의 가장 실용적인 출발점은 거대한 Agent platform을 새로 만드는 것이 아니다. 지금 운영 중인 Agent의 반복 실패를 테스트로 고정하는 것이다.
Schema / unit
Behavioral eval
Trajectory judge
End-to-end benchmark
Shadow / canary
모든 PR에서 거대한 benchmark를 돌리면 비용과 시간이 너무 크다. 반대로 unit test만으로는 LLM의 trajectory 회귀를 잡을 수 없다. 따라서 빠른 deterministic check → 행동 eval → 제한된 judge → batch benchmark → production canary로 층을 나누는 편이 현실적이다.
# CI 예시
on_pull_request:
- schema_tests
- tool_permission_tests
- behavioral_suite_50_cases
nightly:
- trajectory_eval_500_cases
- model_version_A_B
- cost_latency_regression
before_release:
- full_e2e_benchmark
- red_team_suite
- shadow_traffic
production:
- canary_5_percent
- p95_latency / tool_error / policy_violation
- rollback_on_thresholdAI Gateway와 Harness는 같은 계층이 아니다
Enterprise architecture에서 자주 섞이는 개념이 하나 있다. AI Gateway와 Agent Harness다.
AI Gateway는 model endpoint 접근을 통제하고 routing, rate limit, quota, logging, provider abstraction을 담당하는 인프라 계층에 가깝다. 반면 Agent Harness는 task를 어떤 단계로 수행하고 어떤 tool을 어떤 조건에서 호출하며 어떤 검증을 통과해야 종료되는지를 관리한다.
둘은 겹치지만 동일하지 않다. 하나의 Harness가 여러 model을 Gateway를 통해 호출할 수 있고, 하나의 Gateway를 여러 Agent Harness가 공유할 수 있다.
| Layer | 주요 책임 | 대표 지표 |
|---|---|---|
| AI Gateway | Model routing, quota, auth, fallback | TPS, latency, error, cost |
| Agent Harness | Loop, state, tool, context, validation | task success, policy violation, retries |
| Tool Gateway | Enterprise API exposure, scope, audit | tool error, denied calls, side effects |
| Eval Platform | Regression, benchmark, judge, trace analysis | pass rate, stability, cost/quality |
MCP가 100개가 되는 순간, Tool 목록은 생태계가 아니라 공격면이다
Tool ecosystem이 커질수록 Agent가 강해지지만, 동시에 선택과 권한 문제가 커진다. 최신 Harness 연구가 MCP, Skill, plugin, subagent를 단순 extension이 아니라 Harness의 핵심 surface로 보는 이유다.
수백 개 tool schema를 prompt에 전부 넣으면 context가 커지고 tool selection이 어려워진다. 그래서 2026년 9월의 HEART 연구처럼 tool catalogue를 동적으로 retrieval하고, Planner·Router·Verifier를 두는 구조가 등장한다. 다만 이런 연구의 성능 수치는 특정 benchmark와 구현에 의존하므로 그대로 production 효과로 환산하면 안 된다.
MCP server를 연결했다는 것은 단순히 “LLM에게 도구 설명을 추가했다”는 뜻이 아니다. 실제 credential, network, filesystem, external API 권한까지 연결될 수 있다. 따라서 Tool discovery와 Tool authorization은 분리해야 한다.
PoC에서는 안 보이다가 Production에서 터지는 5가지
1. Model upgrade regression
모델이 더 좋아졌는데 Agent 성공률이 떨어질 수 있다. Tool selection 스타일, verbosity, planning 습관이 달라지면 Harness와의 궁합이 변한다. 그래서 model version 교체는 library upgrade가 아니라 runtime behavior change로 테스트해야 한다.
2. Retry loop가 비용 폭탄이 된다
“실패하면 다시 해”만 넣으면 transient error를 복구하는 대신 같은 잘못된 계획을 반복할 수 있다. retry budget, backoff, failure class, alternate tool, human handoff를 구분해야 한다.
3. Context compaction이 사실을 삭제한다
long-running Agent는 context를 계속 유지할 수 없다. 그러나 summary-based compaction이 계약번호, 파일 경로, 승인 조건 같은 결정적 상태를 잃으면 뒤 단계가 완전히 잘못될 수 있다. durable state와 conversational summary를 분리하는 편이 좋다.
4. Tool 성공과 Task 성공은 다르다
API가 200을 반환했다고 업무가 끝난 것이 아니다. 실제 업무 규칙 검증, 결과 확인, idempotency, side-effect 확인까지 완료 조건에 포함해야 한다.
5. Observability가 너무 많아도 운영이 안 된다
모든 token과 모든 intermediate thought를 저장하는 것은 비용과 개인정보 측면에서 위험하다. raw trace, structured event, audit log, eval artifact의 보존 정책을 분리해야 한다.
처음부터 거대한 Agent Platform을 만들 필요는 없다
대부분의 Enterprise 팀이라면 Level 4보다 Level 1~3을 제대로 만드는 쪽이 우선이다. self-evolving agent가 멋있어 보여도, tool permission과 behavioral regression suite가 없다면 운영 기반부터 부족한 상태다.
무엇을 측정해야 하나
Harness의 품질을 task success 하나로 평가하면 다시 원점으로 돌아간다. 최소한 다음 네 축을 나눠 보는 편이 좋다.
| 축 | 예시 지표 | 왜 필요한가 |
|---|---|---|
| Capability | Task success, exact business outcome | 실제로 일을 끝냈는가 |
| Reliability | Run-to-run variance, retry, failure class | 같은 조건에서 얼마나 일관적인가 |
| Safety | Denied tool call, policy violation, leakage | 하면 안 되는 행동을 막았는가 |
| Efficiency | Tokens, tool calls, P95 latency, cost/task | 운영 가능한 경제성인가 |
내일 출근해서 가장 먼저 할 일
그리고 각각을 prompt 수정으로 덮지 말고, tool policy · state transition · validation · behavioral eval 중 어디에서 보장해야 하는지 분류하라.
Harness Engineering의 핵심은 새로운 framework 이름을 배우는 것이 아니다. 모델 밖으로 시스템의 책임을 다시 꺼내오는 일이다.
“모델이 알아서 잘하겠지”라고 남겨둔 부분을 코드, policy, schema, eval, trace로 하나씩 바꾸는 것. 그 과정에서 Agent는 덜 자유로워질 수 있지만, Production system은 더 예측 가능하고 교체 가능하며 감사 가능해진다.
한 줄 평
개인적으로 2026년 Harness Engineering 흐름에서 가장 중요한 변화는 “Agent 성능”을 더 이상 모델 점수 하나로 보지 않는다는 점이라고 생각한다. 같은 모델도 Harness에 따라 전혀 다른 제품이 된다. 반대로 Harness가 충분히 잘 설계되면 model upgrade와 vendor change를 훨씬 낮은 위험으로 받아들일 수 있다.
금융권에서는 특히 그렇다. Model Risk, Data Access, Tool Permission, Audit, Change Management를 prompt 속 문장으로 유지할 수는 없다. 그 규칙들이 executable contract와 regression test로 내려오는 순간, Harness Engineering은 새로운 유행어가 아니라 Agent Production Engineering의 이름이 된다.
References
- Google Developers Blog — The Anatomy of Harness Engineering: How to Evaluate, Iterate, and Guard AI Coding Agents (2026-09-09)
- Google Research — Industrial Agentic Engineering (2026)
- Barbaste et al. — Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents (2026)
- Lin et al. — Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses (2026)
- Ahn & Kim — From Prompts to Contracts: Harness Engineering for Auditable Enterprise LLM Agents (2026)
- Dhage — Harness Engineering for Predictable Agentic Systems (2026)
- Wu et al. — HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness? (2026)
- Jin et al. — Harness Engineering in LLM Tool Use via Agent-Native Reusable Tool Primitives (2026)
- Kapner et al. — Scanning the Harness: An Empirical Study of Supply-Chain Defects in AI Coding-Agent Configurations (2026)