Harness Engineering — 4장: Harness의 다섯 구성요소

서로 다른 프레임워크는 같은 코끼리의 다른 부분을 만진다

OpenAI는 네 개의 동사로, Martin Fowler 진영은 세 개의 축으로, Anthropic은 다중 Agent 구조로 설명한다. 원문은 이 차이를 경쟁하는 정답으로 보지 않고, 동일한 Harness를 서로 다른 절단면에서 본 것으로 해석한다. 그 공통분모를 실무 관점에서 다섯 구성요소로 정리한다.

지시 · Instruction AI에게 무엇을 해야 하는지, 프로젝트가 어떤 구조인지, 어떤 규칙을 따라야 하는지 알려준다.

제약 · Constraint AI가 잘못된 행동을 선택하지 못하도록 프로그램 수준에서 경계를 만든다.

피드백 · Feedback AI가 스스로 “맞다고 생각하는 것”과 실제로 맞는 것을 구분하게 한다.

기억 · Memory 실수와 결정과 지식을 회차를 넘어 지속시켜 같은 설명과 같은 오류의 반복을 줄인다.

편성 · Orchestration 복잡한 문제에서 여러 Agent와 역할, 흐름, 컨텍스트를 하나의 협업 구조로 묶는다.

Harness의 핵심은 부품의 개수가 아니다. 중요한 것은 행동 이전, 행동 중, 시간 너머, 여러 주체 사이에 필요한 질서를 어디에 둘 것인가다.

다섯 가닥을 하나씩 풀어본다

각 구성요소는 독립된 기능처럼 보이지만 실제로는 다음 요소를 부른다. 지시는 제약을 필요로 하고, 제약은 검증을 요구하며, 검증의 결과는 기억이 되고, 축적된 기억은 더 복잡한 편성을 가능하게 한다.

Instruction · Tell the system what matters

지시 — 문서가 아니라 살아 있는 지도

Harness의 가장 기초적인 층이다. AI에게 “나는 누구인가, 프로젝트는 어떤 모양인가, 어떤 규칙은 반드시 지켜야 하는가”를 알려준다. 도구마다 이름은 다르다. Claude Code는 CLAUDE.md, Codex CLI는 AGENTS.md, Cursor는 .cursorrules, Windsurf는 .windsurfrules를 사용한다. 원문이 보는 본질은 동일하다. Markdown으로 인간의 의도를 AI가 읽을 수 있는 규칙으로 인코딩하는 일이다.

Boris Cherny — 약 100줄

많은 개발자가 500~1000줄 이상을 쓰지만 오히려 효과가 나빠질 수 있다고 본다. “이 줄을 지워도 Claude가 실수하지 않는가”가 삭제 기준이다.

OpenAI Codex 팀 — 지도, not 매뉴얼

AGENTS.md 약 100줄에 프로젝트 구조와 핵심 제약만 두고, 상세 문서는 포인터로 연결한다. 거대한 단일 문서는 효과가 좋지 않았다고 서술된다.

Mitchell Hashimoto — 실수 기반 성장

Ghostty의 각 규칙은 Agent가 실제로 저지른 과거의 실수와 연결된다. 규칙 파일은 상호작용 속에서 자라나는 살아 있는 공학 산출물이다.

공통 논리 — 복리 공학

지시는 한 번 작성하고 닫는 문서가 아니다. 경험을 제도화해 다음 실행의 품질을 누적시키는 장치다.

Rule of thumb → “이 줄을 지우면 Agent가 실제로 실수하는가?”

Constraint · Turn advice into law

제약 — 지시는 권고이고, 제약은 법이다

“코드 규칙을 지켜라”는 지시는 권고다. 규칙을 어기면 컴파일이나 CI가 통과하지 못하게 만드는 것은 제약이다. OpenAI는 이 층을 constrain과 correct로 표현한다. 하나는 사전에 막고, 다른 하나는 사후에 고친다.

Custom linter / 구조 테스트

OpenAI Codex 팀은 CI의 사용자 정의 ESLint 규칙과 구조 테스트로 나쁜 패턴을 정적 단계에서 차단한다. 그 linter 자체도 Codex가 작성한다.

Claude Code Hooks

PreToolUse에서 작업 전 검사 후 deny를 반환해 실행을 차단할 수 있다. lint, branch 검사처럼 프로그램 수준에서 강제한다.

Codex CLI Sandbox

기본적으로 작업공간 밖 쓰기와 네트워크 접근을 막고, .git/과 .codex/는 보호한다.

역설 — 자유를 줄여 자율성을 높인다

원문이 인용한 핵심은 “AI의 자율성을 높이려면 해 공간의 자유도를 줄여야 한다”는 관찰이다.

Types→ Config→ Repo→ Service→ Runtime→ UI

Agent-first 개발에서 구조적 제약은 대규모 조직의 사후 정비가 아니라 초기 조건이 된다. 원문은 제약 자체가 속도의 원천이 될 수 있다고 본다.

Feedback · Give the agent eyes

피드백 — 가장 위험한 오류는 ‘틀렸는데 맞다고 생각하는 것’이다

LangChain은 Agent가 코드를 다시 읽고 “문제없어 보인다”고 판단한 뒤 테스트 없이 멈추는 실패를 자주 관찰했다. 첫 번째로 그럴듯한 해법에 만족하는 편향을 Harness가 외부 검증으로 깨야 한다. Anthropic은 Planner–Generator–Evaluator의 세 Agent를 분리해, 스스로를 평가하는 대신 독립된 평가자가 실제 애플리케이션을 시험하도록 했다.

Anthropic Evaluator

Planner가 명세를 확장하고 Generator가 Sprint 단위로 구현하며, Evaluator는 Playwright로 실제 UI와 시스템을 테스트한다.

독립 평가자의 이유

자기 작품을 비판하는 생성자보다, 엄격한 별도 평가자를 공학화하는 편이 쉽다는 관점이다. 역할 분리가 대립적 피드백을 만든다.

Boris Cherny의 제안

Claude에게 검증 수단을 주면 결과 품질이 2~3배 향상될 수 있다고 원문은 서술한다. UI 테스트, 테스트 스위트, 시뮬레이터가 예다.

Fowler의 Garbage Collection

기능 구현 대신 문서 모순과 아키텍처 위반을 주기적으로 찾는 전담 Agent를 피드백의 한 형태로 본다.

DOMChrome DevTools Protocol

Screenshot화면 상태 확인

Log / Metric관측성 데이터 조회

6h+원문이 서술한 장시간 단일 작업

다만 내부 품질을 검증하는 것과 사용자가 실제로 원하는 기능을 검증하는 것은 다르다. 원문은 OpenAI 사례가 기능적 정확성 검증에는 빈틈이 있다고 지적한다.

Memory · Carry experience across time

기억 — 경험이 세션을 건너가지 못하면 실수도 다시 돌아온다

원문은 기억 없는 Agent를 금붕어에 비유한다. 매 세션이 처음이라면 같은 설명과 같은 실수가 반복된다. 기억은 단일 기능이 아니라 여러 층으로 구성된다.

정적 기억

CLAUDE.md, AGENTS.md처럼 규칙 자체가 기억이 된다. Boris Cherny 팀은 PR의 @.claude 태그를 통해 규칙을 갱신한다.

동적 기억

Claude Code auto-memory, Windsurf Cascade Memories, Cline의 MCP 기반 Memory Bank처럼 유용한 관찰을 세션 간에 지속한다.

구조화된 노트

Anthropic은 컨텍스트 창 밖의 지속 메모를 압축 수단으로 활용했다. Pokemon 사례에서 1,234 step 같은 진행 상태를 기록해 리셋 후에도 이어간다.

OpenAI — inform

Google Docs의 계획 문서와 Slack 결정을 repo 안의 Markdown으로 옮기고, 자급적 설계 문서인 ExecPlan을 만든다.

Single Source of Truth

Agent가 볼 수 없는 정보는 없는 것과 같다는 전제 아래, 저장소가 진실의 단일 출처가 되어야 한다는 관점을 제시한다.

기억의 목적은 많이 저장하는 것이 아니다.
기대 결과의 가능성을 높이는 최소한의 고신호 token 집합을 유지하는 것이 중요하다. 컨텍스트는 자원이며, 과잉 정보는 실제 작업 공간을 잠식한다.

Orchestration · Coordinate across space

편성 — 한 Agent의 능력에서 여러 Agent의 관계로

앞의 네 구성요소는 한 Agent에게도 필요하다. 편성은 문제가 충분히 복잡해 여러 Agent가 역할을 나눠야 할 때 등장한다. 핵심은 단순 병렬 실행이 아니라, 역할·컨텍스트·완료 조건·소통 경로를 설계하는 일이다.

Anthropic · 3-Agent

Planner가 요구를 명세로 확장하고, Generator가 구현하며, Evaluator가 E2E 테스트를 수행한다.

Claude Code · 2 Modes

Subagents는 독립 컨텍스트에서 탐색 후 요약만 반환한다. Agent Teams는 여러 인스턴스가 lead와 teammate 관계로 협업하는 실험적 방식이다.

LangChain · Middleware

before_agent, before_model, wrap_model_call, wrap_tool_call, after_model, after_agent의 6개 hook으로 관심사를 분리한다.

Generator 제안→ Evaluator 검토→ 완료 정의 합의→ 구현 시작

편성은 거대한 플랫폼만을 뜻하지 않는다. Boris Cherny는 10~15개의 Claude Code 세션을 여러 terminal·browser·worktree에 병렬로 두고 사람이 직접 스케줄러 역할을 한다. 때로 가장 단순한 orchestration은 사람이다.

서로 다른 절단면, 같은 구조

원문 23쪽은 다섯 구성요소를 OpenAI의 네 동사, Fowler의 세 축, 그리고 대표 구현과 나란히 놓는다. 대응은 완전히 일대일이 아니며, 그 불일치 자체가 각 프레임워크의 관심사를 드러낸다.

다섯 구성요소 모델	OpenAI 네 동사	Fowler 세 축	대표 구현
지시	inform	Context Engineering	CLAUDE.md / AGENTS.md / .cursorrules
제약	constrain	Architecture Constraints	Hooks / Linter / Sandbox / CI
피드백	verify	Garbage Collection	Evaluator Agent / 테스트 / 관측성
기억	inform	Context Engineering	지식베이스 / auto-memory / ExecPlan
편성	correct에 일부 접점	명시적 대응 없음	Multi-Agent / Pipeline / Middleware

왜 지시와 기억을 나누는가

OpenAI의 inform은 둘을 함께 다루지만, 실무에서 규칙 파일과 knowledge base는 관리 방식이 다르므로 분리하는 편이 유용하다는 것이 원문의 판단이다.

왜 Feedback과 Garbage Collection은 같은 듯 다른가

Fowler는 코드베이스의 엔트로피, 문서 노후화, 아키텍처 위반을 본다. Anthropic Evaluator는 기능 정확성을 본다. 둘 다 피드백이지만 층위가 다르다.

왜 편성이 빠져 있는가

원문은 2026년 초에도 Multi-Agent orchestration이 여전히 실험적이며 주류 프레임워크가 완전히 흡수하지 못한 영역이라고 본다.

다섯 구성요소는 평행하지 않다

원문의 핵심 도식은 다섯 요소를 순서와 역할의 층으로 본다. 무엇을 하라고 말하고, 잘못을 막고, 맞게 했는지 검사하고, 배운 것을 남기고, 마지막으로 여러 Agent가 함께 일하게 한다.

지시무엇을 할지 알려준다

→

제약잘못된 행동을 막는다

→

피드백정말 맞게 했는지 본다

→

기억같은 실수를 반복하지 않는다

→

편성여러 Agent를 함께 움직인다

BEFORE 행동 이전

지시와 제약은 Agent가 움직이기 전에 방향과 경계를 놓는다.

DURING 행동 중

피드백은 실행 중·직후에 품질을 확인하고 잘못된 확신을 깨뜨린다.

ACROSS TIME 시간을 가로질러

기억은 한 세션의 경험을 다음 세션으로 옮겨 시행착오를 자산으로 만든다.

ACROSS SPACE 공간을 가로질러

편성은 여러 Agent의 역할과 컨텍스트를 동시 협업 구조로 묶는다.

이 구조에서 시간은 중요한 축이다. Harness는 현재의 명령만 다루지 않는다. 과거의 실패를 기억하고, 현재의 행동을 검증하며, 미래의 협업 방식을 준비한다.

처음부터 다섯 개를 모두 만들 필요는 없다

원문은 Harness를 완성품으로 설치하는 사고를 경계한다. 실무에서는 필요한 요소가 문제를 따라 순차적으로 자라난다.

지시 + 기본 피드백부터

처음에는 CLAUDE.md를 만들고, Agent가 테스트를 실제로 실행하게 하는 정도면 충분하다.

반복되는 실수에 제약을 추가

“또 같은 문제인가”라는 순간이 오면 linter, hook, sandbox처럼 강제 가능한 경계를 만든다.

반복 설명이 지치면 기억을 만든다

세션마다 같은 맥락을 다시 설명하는 비용이 커질 때 지식과 규칙을 지속 가능한 형태로 저장한다.

한 Agent가 벅찰 때 편성한다

복잡성이 실제로 단일 Agent의 범위를 넘을 때에만 multi-Agent와 pipeline을 도입한다.

원문이 마지막에 남기는 문장은 가장 실무적이다. Harness는 설계해서 완성하는 것이 아니라, 문제와 실패를 먹고 자란다. Agent가 실수할 때마다 하나의 해결책을 공학화하면, 시간이 지난 뒤 그 축적 자체가 Harness가 된다.

좋은 고삐는 힘을 없애지 않는다.
힘이 길을 잃지 않게 한다.

지시는 방향을 만들고,
제약은 경계를 만들며,
피드백은 눈을 만들고,
기억은 시간을 잇고,
편성은 관계를 만든다.

Harness는 결국 다섯 개의 기능이 아니라,
AI가 일할 수 있도록 만든 하나의 질서다.

이 웹페이지는 첨부 문서 《Harness Engineering》의 §04 「Harness的五个组件 / Five Components of a Harness」(PDF 19–24쪽)에만 근거해 재구성했다. 원문의 사례, 제품명, 수치, 비교 프레임, 평가와 한계를 보존했으며 외부 자료를 이용한 추가 검증·수정·확장은 수행하지 않았다.