고삐는 한 가닥의 줄이 아니라 다섯 가닥이다. 각자의 역할이 있으며 하나라도 빠지면 안 된다. Part 2는 하네스의 완전한 구조를 해부하고, 이어서 이 책에서 가장 반직관적인 명제 — 「하네스는 클수록 좋은 것이 아니다」 — 를 데이터로 논증한다.
하네스가 무엇이고 왜 중요한지는 확인했다. 그러나 지금 당장 만들려 하면 문제가 생긴다 — 어디서부터 손을 대는가. OpenAI는 네 개의 동사로, Martin Fowler는 세 개의 블록으로, Anthropic은 멀티 Agent 노선으로 답했다. 서로 다른 말을 하는 듯하지만 자세히 비교하면 같은 코끼리의 다른 부위를 묘사하고 있다. 이 장은 이들 프레임을 통합해 다섯 개의 구성 요소로 추출한다. 다섯이 셋이나 넷보다 옳다는 뜻이 아니라, 이 입도(粒度)가 실전에 가장 적합하다.
AI에게 「나는 누구인지, 프로젝트가 어떻게 생겼는지, 반드시 지켜야 할 규칙이 무엇인지」를 알린다.
도구마다 이름이 다르다 — Claude Code는 CLAUDE.md, Codex CLI는 AGENTS.md,
Cursor는 .cursorrules, Windsurf는 .windsurfrules. 본질은 같다:
Markdown 파일로 의도를 AI가 읽을 수 있는 규칙으로 인코딩한다.
차이는 이렇다. 지시는 「코드 규범에 유의하라」고 말하고, 제약은 코드가 규범에 맞지 않으면 컴파일이 통과되지 않게 만든다. OpenAI는 이 층을 두 개의 동사 — constrain(사전 차단)과 correct(사후 수정) — 로 요약한다.
.git/과 .codex/는 전권 모드에서도 보호된다.Types → Config → Repo → Service → Runtime → UI. 코드는 고정된 방향으로만 의존할 수 있다. 통상 엔지니어 수백 명 규모에서나 설계하는 아키텍처지만, agent 코딩 시대에는 초기 전제 조건이 되었다.LangChain이 Terminal Bench 2.0 테스트에서 발견한 가장 흔한 실패 모드: agent가 해법을 작성한 뒤 자기 코드를 다시 읽고, 보기에 문제없다고 판단하고 멈춘다. 테스트를 돌리지 않고 경계 조건도 검증하지 않는다. 모델은 자신의 첫 번째 그럴듯한 해법을 선천적으로 선호한다 — 더 잘할 수 없어서가 아니라 「보기에 괜찮음」에 너무 쉽게 만족한다.
대화마다 처음부터 다시 시작하고 같은 실수를 두 번, 세 번 반복한다. 기억은 몇 개의 층으로 나뉜다.
@.claude 태그로 CLAUDE.md를 갱신하며, 추가되는 모든 규칙은 agent의 과거 실수에 대한 제도화된 기록이다.앞의 네 요소는 단일 agent의 하네스다. 과제가 충분히 복잡해 여러 agent의 협업이 필요할 때 편성(orchestration)이 다섯 번째 구성 요소가 된다.
| 5-요소 모델 | OpenAI 4동사 | Fowler 3블록 | 대표 구현 |
|---|---|---|---|
| 지시 | inform (고지) | 컨텍스트 엔지니어링 | CLAUDE.md / AGENTS.md / .cursorrules |
| 제약 | constrain (제약) | 아키텍처 제약 | Hooks / Linter / Sandbox / CI |
| 피드백 | verify (검증) | 가비지 컬렉션 | Evaluator Agent / 테스트 / 관측성 |
| 기억 | inform (고지) | 컨텍스트 엔지니어링 | 지식 베이스 / auto-memory / ExecPlan |
| 편성 | correct (교정) | — (미포함) | 멀티 Agent / Pipeline / Middleware |
대응 관계 몇 가지가 짚어 볼 만하다. OpenAI의 inform은 지시와 기억을 동시에 덮는다 — 그들의 프레임에서는 규칙이든 지식이든 「agent가 못 보는 것은 없는 것」이라는 한 문장으로 통합된다. 그러나 실무에서 CLAUDE.md와 knowledge base의 관리 논리는 완전히 다르므로 분리하는 편이 낫다. Fowler의 가비지 컬렉션은 피드백에 대응하지만 의미가 좁다 — Fowler는 코드베이스 층위의 엔트로피 증가(문서 낙후, 아키텍처 위반 누적)를 보고, Anthropic의 Evaluator는 기능 층위의 정확성을 본다. 둘 다 피드백이되 층위가 다르다. 편성은 어느 쪽도 명시적으로 다루지 않는다 — 멀티 Agent 편성이 2026년 초 현재도 실험 단계이며 주류 프레임이 아직 흡수하지 못했음을 반영한다.
다섯 요소는 평행하지 않고 층위가 있다. 지시와 제약은 입력단으로 agent가 행동하기 전에 자리 잡는다. 피드백은 과정 중의 품질 검사이고, 기억은 시간을 가로질러 경험을 세션 사이에 지속시키며, 편성은 공간을 가로질러 여러 agent를 동시에 협업시킨다.
다섯을 동시에 올릴 필요가 없다. 처음에는 지시(CLAUDE.md 하나)와 기본 피드백(AI에게 테스트 실행)만으로 충분하다. 제약은 agent에게 시달린 뒤 자연스럽게 추가된다. 기억은 규칙을 매번 반복 설명하는 데 지친 뒤 자연스럽게 구축된다. 편성은 과제가 정말로 단일 agent가 감당 못 할 만큼 복잡할 때 마지막에 필요하다. 하네스는 설계되는 것이 아니라 자라나는 것이다. Mitchell Hashimoto의 말을 다시 새길 만하다 — agent가 실수할 때마다 해법을 엔지니어링하라. 3개월 뒤 그 파일이 곧 당신의 하네스다.
앞 장을 읽고 나면 자연스러운 반응이 나온다 — 다섯 요소를 전부 극한까지 하면 최고 아닌가. 아니다. 정반대다. 복수의 독립된 팀이 서로 다른 장면에서 같은 사실을 발견했다: 과도하게 공학화된 하네스는 하네스가 없는 것보다 나쁘다. 철학적 견해가 아니라 데이터가 있다.
Anthropic은 장기 실행 agent를 개발하며 아무도 주목하지 않았던 현상을 발견했다. Claude Sonnet 4.5는 「자신의 컨텍스트 윈도를 인식한」 최초의 모델이다. 좋은 일처럼 들리지만 아니다. 이 자기 인식은 부작용을 낳았다 — 모델이 컨텍스트 한계에 가까워졌다고 판단하면 조기에 마무리 작업을 시작한다. Anthropic은 이를 컨텍스트 불안(context anxiety)이라 명명했다. 잔여 토큰에 대한 모델의 추정은 「매우 정밀하지만 틀렸다」. 진행 상황을 능동적으로 요약하고 수정을 더 성급하게 밀어붙인다. 겉보기에는 효율이 오른 듯하지만 실제로는 서두르는 것이다.
Sonnet 4.5의 컨텍스트 불안은 압축(compaction)만으로는 부족할 정도로 심각했다. Anthropic은 하네스에 컨텍스트 리셋(context reset) — 윈도를 완전히 비우고 구조화된 인계 상태로 새 Agent를 기동하는 메커니즘 — 을 추가해야 했다. Opus 4.5에 이르러서야 이 행동은 저절로 사라졌다.
이 발견의 의미는 단일 모델을 넘어선다. 더 보편적인 법칙을 드러낸다 — 컨텍스트는 공짜 자원이 아니며 부작용이 있다. 집어넣는 정보가 많을수록 모델이 개별 정보를 정확히 상기하는 능력은 떨어진다. Anthropic의 엔지니어링 문서는 기술적으로 얼마나 큰 윈도를 지원하든 약 100만 토큰 지점에서 뚜렷한 성능 천장이 있고 그 이후 성능이 유의미하게 하락한다고 명시한다. Claude Code 공식 베스트 프랙티스 문서도 첫머리에 밝힌다 — 「대부분의 베스트 프랙티스는 한 가지 제약에 기초한다: Claude의 컨텍스트 윈도는 빠르게 차고, 차면 성능이 떨어진다.」
| 안티패턴 | 내용 |
|---|---|
| Kitchen Sink Session | 하나의 세션에 무관한 과제들을 뒤섞는다 |
| 반복 수정 | 실패한 해법으로 컨텍스트가 오염된 상태에서 계속 고친다 |
| 과잉 명세된 CLAUDE.md | 너무 길어서 규칙이 무시된다 |
| 무경계 탐색 | 범위를 한정하지 않은 조사가 컨텍스트를 가득 채운다 |
네 항목 모두 같은 결론을 가리킨다 — 少即是多(적을수록 많다).
1000줄도, 500줄도 아닌 100줄. OpenAI는 반대쪽 극단도 시도했다 — 모든 규칙·컨벤션·아키텍처 결정을 하나의 초대형 AGENTS.md에 몰아넣었고, 결과는 나빴다. 이유는 어렵지 않다. 포괄적 지시 파일은 과제 컨텍스트와 관련 코드의 공간을 잠식한다. Agent는 작고 안정적인 진입점 + 전문화된 지식을 가리키는 구조에서 가장 잘 동작한다.
Boris Cherny의 CLAUDE.md도 약 100줄로, 많은 개발자의 500–1000줄보다 훨씬 짧다. 그의 경험 — 비대한 CLAUDE.md는 Claude가 정작 중요한 지시를 무시하게 만든다. 규칙이 너무 많으면 규칙이 없는 것과 같다. 인간 팀 관리와 통하는 이치다. 300쪽 매뉴얼은 아무도 읽지 않지만 A4 한 장의 행동 목록은 모두가 기억한다. 올바른 방법은 계층화다 — 얇은 진입 파일 하나를 지도로 삼아 더 깊은 전문 문서를 가리킨다. API 설계 규범이 필요하면 길만 알려 준다. 전부 한 파일에 펼쳐 놓지 않는다.
컨텍스트의 「少即是多」가 그나마 이해하기 쉽다면, LangChain의 이 발견은 진짜 반직관적이다. Terminal Bench 2.0에서 추론 예산 배분 전략별 결과는 다음과 같다.
| 추론 구성 | 점수 | 비고 |
|---|---|---|
| 전 구간 xhigh최고 추론 | 53.9% | 대량의 과제가 타임아웃 |
| 전 구간 high | 63.6% | 안정적이나 부족 |
| Reasoning Sandwichxhigh → high → xhigh | 66.5% | 최종 채택안 |
전 구간 최고 추론이 가장 낮은 점수를 냈다. 이유는 추론 능력 부족이 아니라 타임아웃이다 — 필요 없는 곳에서 자원이 낭비되어 정작 필요할 때 모자랐다. 최적 전략인 추론 샌드위치는 시작 단계(계획)에 최고 추론, 중간 구현 단계(이미 계획된 코드를 쓰는 기계적 작업)에는 추론을 낮춰 토큰과 시간을 절약, 마지막 검증 단계에 다시 최고 추론을 투입한다.
자원 배분이 자원 총량보다 중요하다. 이 결론은 컨텍스트 관리, 추론 예산, 심지어 팀의 시간 배분에서도 성립한다.
「少即是多」를 이해한 뒤 실전에서 가장 어려운 질문 — 그 「적음」의 경계는 어디인가. Mitchell Hashimoto의 방법은 순수 귀납법이다: agent가 실수했을 때만 규칙을 더한다. 빈 파일에서 시작해 실수 하나마다 한 줄. 모든 규칙이 실제 문제에 대응함이 보장되고 「혹시 몰라서」식 잉여가 없다. 그러나 규칙은 누적된다. 3개월 뒤 파일이 비대해지면 감법이 필요하다. 잘라야 한다는 신호는 다음과 같다.
감법은 지시 파일뿐 아니라 하네스 아키텍처 자체에도 적용된다. Anthropic은 Sonnet 4.5 → Opus 4.6 업그레이드 과정에서 일련의 감법을 수행했다 — Sprint 메커니즘 제거, 컨텍스트 리셋 제거, Evaluator를 매 Sprint 평가에서 전 과정 종료 후 1회 평가로 축소.
Evaluator는 유/무의 고정된 결정이 아니다. 과제가 현재 모델이 신뢰성 있게 독립 완수할 수 있는 범위를 넘어설 때에만 비용을 투입할 가치가 있다. 하네스 설계는 모델 능력에 따라 동적으로 조정되어야 한다.
하네스는 한 번 만들면 끝나는 것이 아니다. 모델이 강해지면 하네스는 얇아져야 한다. 오늘 필요한 비계(飛階)가 내일은 군더더기 무게가 될 수 있다. LangChain의 공식으로 돌아가면 — Agent = Model + Harness. Model이 강해질수록 Harness에 필요한 것은 줄어든다. 다만 「더 적음」이 「없음」은 아니다. 가장 강한 모델도 지시·제약·피드백은 여전히 필요하며, 규모와 복잡도를 낮출 수 있을 뿐이다.
이것이 하네스 엔지니어링에서 판단력이 가장 필요한 지점이다. 규칙을 더하기는 쉽고 자르기는 어렵다. 규칙 하나를 잘랐다가 문제가 생기면 후회하지만, 쓸모없는 규칙 하나를 남겨 두면 그 비용은 감지되지 않는다. 그러나 비용은 실재한다 — 잉여 규칙 하나하나가 정말 중요한 규칙의 가중치를 희석하고 있다.
좋은 하네스는 규칙이 가장 많은 것이 아니라, 모든 규칙이 일하고 있는 것이다.