하네스 엔지니어링 (Harness Engineering)

TL;DR

미첼 하시모토가 명명한 개념으로, ‘에이전트가 실수할 때마다 그 실수가 다시 반복되지 않도록 하는’ 모델 가중치 외부의 모든 것(AGENTS.md·MCP/스킬·LLM 위키·자동화 테스트)을 설계하는 일.

미첼 하시모토는 하네스 엔지니어링을 ‘에이전트가 실수할 때마다 그 실수가 다시는 반복되지 않도록 하는 것’이자 ‘모델 가중치 외부의 모든 것’으로 정의한다 [1].
구성요소는 AGENTS.md(지침), MCP·스킬(도구), LLM 위키(도메인 지식), lint·자동화 테스트(검증 도구)이며, E2E 테스트는 이 중 ‘검증’ 슬롯을 채운다 [1].
검증이 코드 생성보다 새 병목이 되었고(Boris Cherny: ‘에이전트에게 자기 작업을 검증할 수단을 줘라’), 하네스는 그 수단을 제공하는 환경이다 [1].
하네스는 한 번 짜고 끝나는 게 아니라 모델·도메인이 진화하면 ‘모양을 바꾸며 함께 자라는’ 시스템이다 [1].

황민호(카카오 AI네이티브 전략팀 리더)는 하네스 엔지니어링을 프롬프트(어떻게 대화할까)→컨텍스트(무엇을 줄까) 다음 단계로, 모델 단일 성능이 아니라 모델을 둘러싼 환경·구조·사전 설계 전체를 최적화하는 패러다임으로 정의한다 [1].
앞 단계 기법은 폐기되지 않으며 하네스 안 에이전트 상호작용에 좋은 프롬프트·컨텍스트가 필수다; 초기 프롬프트 기법 일부는 모델 자체에 흡수됐다 [1].
하네스는 에이전트를 여럿 띄우는 것과 다르다 — 역할 비중복 구성 + 순차/병렬 흐름 사전 설계 + 흐름을 유지·스폰하는 오케스트레이터, 세 조건을 모두 요구한다 [1].
황민호는 개념에만 머물던 하네스에 실체를 부여하려 harness-100(10카테고리×100사례)을 오픈소스로 공개했고, 모든 하네스가 .claude/{CLAUDE.md, agents, skills} 단일 레이아웃을 공유한다 [2].

The report frames loop engineering as repetition over an existing harness: tests, build exit codes, lint, diff scripts, screenshots, context compaction, note-taking, and external memory are the parts a loop can observe and reuse [2].
Anthropic’s agent guidance reinforces the same dependency: agents need environmental ground truth during execution and stopping conditions such as iteration limits to remain controlled [7].
The Playwright E2E harness case shows how deterministic checks can replace or supplement LLM judges in evaluator-optimizer style loops [12].

리포트는 코딩 자동화 이후 하네스의 중심을 “테스트 먼저 → 실패 확인 → 수정 → 통과 확인 → 자동 리뷰 → 사람 리뷰” 같은 검증 루틴으로 잡아야 한다고 정리한다 [2].
도구 연결에서도 하네스 설계가 필요하다: 매일 쓰고 상호작용이 복잡한 도구는 MCP, 간헐적이고 예측 가능한 작업은 CLI로 나눠 컨텍스트 비용과 보안 노출을 관리한다 [3] [6].
안전 하네스는 permission gate, 패키지 allowlist, 위험 명령 승인, 비용 로그를 포함해야 하며, 금융 자동화처럼 실패 비용이 큰 영역은 generated code와 데이터 시점 검증을 별도 review target으로 분리해야 한다 [1] [6].