Harness Engineering · Chapter 08

AI가 AI를
검증하게 하라

한 모델에게 만들고, 판단하고, 반박하고, 승인하는 일까지 모두 맡기면 같은 시선이 같은 실수를 감싼다. 이 장의 출발점은 단순하다. 생성의 능력과 비판의 능력을 분리하고, 그 사이에 계약과 검증의 구조를 둔다.

대상: 원문 §08 「Anthropic：让AI查AI」 범위: PDF 38–42쪽 외부 자료 미사용 원문의 수치·제품명·평가는 원문 기준
좋은 Harness는 한 Agent를 더 똑똑하게 만드는 장치라기보다, 서로 다른 역할이 서로의 약점을 드러내도록 만드는 구조에 가깝다.
01

세 Agent, 하나의 생산 라인

Anthropic이 공개한 구조의 목표는 수 시간 동안 자율적으로 코딩해 완성된 풀스택 애플리케이션을 만드는 것이다. 핵심은 한 Agent에게 모든 판단을 몰아주지 않는 데 있다. 기획, 구현, 평가를 역할로 분리하고 각 역할의 실패가 다음 역할에서 드러나게 한다.

Planner

계획자 — 짧은 요구를 제품 언어로 확장

1~4문장의 짧은 prompt를 완전한 제품 명세로 확장한다. 그러나 상세 기술 구현까지 미리 고정하지 않는다.

  • 제품 맥락과 고수준 설계에 집중
  • 지나치게 상세한 기술 지시는 피함
  • 기술적 세부는 하류의 Generator에게 남김
→
Generator

생성자 — Sprint 단위로 한 기능씩 구현

기능을 증분적으로 구현하고 QA 이전에 자체 점검을 수행한다. 다만 원문은 자기검증의 신뢰도가 제한적이라고 지적한다.

  • React + Vite
  • FastAPI
  • SQLite / PostgreSQL
  • Sprint마다 feature 하나에 집중
→
Evaluator

평가자 — 실제 시스템을 만지며 흠을 찾는다

Playwright MCP를 이용해 실행 중인 앱과 직접 상호작용하며 UI, API, 데이터베이스를 검사하고 버그를 Generator에게 되돌려 보낸다.

  • 디자인 품질
  • 독창성
  • 간격·타이포그래피·대비 같은 완성도
  • 사전 정의된 기준에 따른 채점

생성은 낙관적이다

Generator의 목표는 가능한 해를 만드는 것이다. 첫 번째로 그럴듯한 해법을 만들면 멈추기 쉽다.

평가는 의심에서 출발한다

Evaluator의 목표는 잘못을 찾는 것이다. 같은 결과를 보는 방향이 반대이기 때문에 대립적 긴장이 생긴다.

Generator “이 정도면 된다”를 만든다
↔
Evaluator “정말 되는가”를 증명하게 한다
원문이 끌어오는 직관은 GAN과 닮아 있다. 생성자에게 자기비판을 가르치는 것보다, 별도의 엄격한 평가자를 공학화하는 편이 쉽다. 같은 모델 계열이라도 역할을 분리하면 비판의 방향이 달라진다.
02

$9와 $200 사이 — 가격이 아니라 ‘쓸 수 있는가’를 비교한다

원문은 단일 Agent와 세 Agent 협업을 정면으로 비교한다. 비용 차이는 크다. 그러나 결과의 차이는 “조금 낫다”가 아니라 “사용 가능하다 / 사용 불가능하다”의 차이로 서술된다.

단일 Agent

$9
20분 낮은 비용 단일 역할
핵심 기능이 작동하지 않았고 게임 엔터티 입력 처리가 깨졌다고 원문은 설명한다.

세 Agent 협업

$200
6시간 20배 이상 비용 Planner + Generator + Evaluator
AI 기능을 통합한 완전한 사용 가능 애플리케이션을 만들었다고 원문은 서술한다.
“싸지만 조금 못한 것”과 “비싸지만 조금 나은 것”의 비교가 아니다. 원문이 강조하는 차이는 결과물이 실제로 쓸 수 있느냐는 경계다.
비용 최적화는 품질의 바깥에서 할 수 없다. 쓸 수 없는 결과의 낮은 비용은 절약이 아니라 실패 비용이다. Harness는 토큰 가격만이 아니라 결과의 효용까지 함께 계산해야 한다.
03

Sprint Contract — 코드를 쓰기 전에 ‘완료’부터 합의한다

세 Agent 구조에서 가장 공학적인 장치는 구현 전에 Generator와 Evaluator가 성공 기준을 협상하는 절차다. 코드보다 먼저 검증 가능성을 만든다.

Definition of Done을 AI끼리 먼저 합의한다

Generator가 구현안과 성공 기준을 제시하고, Evaluator가 그 기준이 실제로 테스트 가능한지 검토한다. 양측이 수정과 합의를 반복한 뒤에야 코딩을 시작한다.

구현안 제안Generator
→
성공 기준 제시Generator
→
테스트 가능성 검토Evaluator
→
합의 후 구현Sprint 시작
사람의 기술 리뷰와 닮은 이유가 있다. 구현을 시작하기 전에 무엇을 성공으로 부를지 합의하면, 검증은 사후 감상이 아니라 사전 계약이 된다.
04

Context Anxiety — 긴 작업은 모델의 심리까지 Harness의 문제가 된다

장시간 Agent 시스템을 만들며 Anthropic이 관찰한 흥미로운 실패 모드는 모델이 자신의 컨텍스트 한계를 의식하는 듯 행동한다는 점이다. 원문은 Sonnet 4.5에서 이를 ‘context anxiety’로 설명한다.

Sonnet 4.5의 조급함

남은 token을 거의 정확하게 계산하는 듯하지만 실제 추정은 틀리고, 한계가 가까워졌다고 느끼면 진행 상황을 미리 요약하고 버그 수정도 더 급하게 마무리하려는 행동이 나타났다고 서술된다.

① 컨텍스트 한계 인식
② 성급한 요약
③ 수정 작업의 조급화
④ 장기 작업 품질 저하

Compaction만으로 부족했다

단순히 대화를 압축하는 것으로는 장기 작업 성능을 유지하기 어려워 컨텍스트를 완전히 비우고 구조화된 handoff 상태로 새 Agent를 시작하는 context reset을 도입했다고 원문은 설명한다.

Sonnet 4.5

context reset 필요. 긴 작업을 Harness가 보조해야 했다.

→
Opus 4.5

해당 행동이 사라져 reset 장치를 Harness에서 제거할 수 있었다.

좋은 Harness는 고정된 건축물이 아니다. 모델의 약점을 보완하다가, 모델이 강해지면 스스로 얇아져야 하는 가변 구조다. Evaluator 역시 항상 필요한 부품이 아니라, 현재 모델이 독립적으로 신뢰할 수 있는 범위를 넘을 때 투자할 장치다.
05

Boris Cherny — 짧은 규칙, 많은 병렬성, 강한 검증

원문은 Claude Code를 만든 Anthropic Staff Engineer Boris Cherny의 작업 방식을 “Harness는 커야 한다”는 직관의 반례로 제시한다. 규칙은 짧고, 세션은 많고, 검증은 강하다.

CLAUDE.md는 약 100줄

500~1000줄을 넘기는 규칙 파일보다 짧은 파일을 선호한다. 각 줄에 “이 줄을 지우면 Claude가 실제로 실수하는가”를 묻고, 그렇지 않다면 삭제한다.

≈100

동시에 10~15개 세션

터미널 5개, 브라우저 5~10개, 모바일 세션까지 병렬로 운용한다. 3~5개의 git worktree를 독립 실행하고 za, zb, zc 같은 shell alias로 전환한다.

10–15

#1 Tip — 검증 수단을 제공하라

Web은 Chrome 기반 UI 검증, CLI는 테스트 스위트, 인프라는 시뮬레이터처럼 결과를 스스로 확인할 방법을 준다. 원문은 피드백 루프가 최종 품질을 2~3배 높일 수 있다고 서술한다.

2–3×

첫 답을 받아들이지 않는다

평범한 해법이 나오면 이미 가진 정보를 모두 바탕으로 그 안을 버리고 더 우아한 구현을 다시 내놓으라고 요구한다. Agent의 첫 번째 만족점을 인간의 판단으로 넘어선다.

2nd
엔지니어의 핵심 기여는 코드의 양이 아니라 판단력에 있다. 무엇을 만들지, 어떻게 검증할지, 언제 결과를 믿을지, 언제 반박할지를 결정하는 일이 중심이 된다.
Boris가 말하는 ‘복리 공학’은 작은 실패를 규칙으로 축적하는 방식이다. PR의 @.claude 업데이트는 실수를 조직의 기억으로 바꾸고, 반복되는 오류를 다음 실행의 출발점에서 미리 제거한다.
06

Claude Code Harness의 여섯 메커니즘

원문은 Boris와 Anthropic 팀의 실천에서 Claude Code Harness를 여섯 개의 메커니즘으로 추출한다. 지속 기억, 결정론적 제약, 필요 시 지식 로딩, 외부 세계 연결, 세션 간 기억, 탐색 격리가 각각 다른 역할을 맡는다.

Persistent Instructions

CLAUDE.md

전역 ~/.claude/CLAUDE.md, 프로젝트 ./CLAUDE.md, 하위 디렉터리 단위의 계층 구조를 가진다. 세션 시작 시 자동으로 불러오는 지속 규칙과 기억의 층이다.

Deterministic Behavior

Hooks

CLAUDE.md가 권고라면 Hook은 행동을 보장하는 장치다. “규칙을 지켜라”가 아니라 해당 동작이 반드시 실행되게 만든다.

SessionStart PreToolUse PostToolUse PermissionRequest Stop PostCompact
On-demand Knowledge

Skills

.claude/skills/에 두고 SKILL.md로 정의한다. CLAUDE.md처럼 매번 로드하지 않고 필요할 때 자동 또는 /skill-name으로 호출한다.

External Integration

MCP

Model Context Protocol을 통해 데이터베이스 조회, 모니터링 분석, Figma 디자인 불러오기 등 외부 서비스와 Agent를 연결한다.

Cross-session Knowledge

Memory

파일 기반의 세션 간 지식 저장소다. Pokemon 사례처럼 정확한 step 수와 상태를 노트에 남기고, 컨텍스트가 초기화된 뒤에도 다시 읽어 장기 작업을 잇는다.

Isolation

Subagents

독립 컨텍스트에서 탐색성 작업을 수행하고, 메인 Agent에는 약 1,000~2,000 token의 압축 요약만 돌려준다. 핵심은 탐색 과정이 주 대화를 오염시키지 않게 하는 데 있다.

여섯 장치는 모두 같은 질문에 답한다. 무엇을 항상 기억하게 할 것인가, 무엇을 반드시 실행하게 할 것인가, 무엇을 필요할 때만 불러올 것인가, 무엇을 주 컨텍스트에서 격리할 것인가. Harness는 지식의 양보다 지식과 행동의 배치를 설계한다.
07

팀마다 Claude Code를 쓰는 방식은 달랐다

원문은 Anthropic 내부 여섯 팀의 활용을 언급하고, 그중 안전 엔지니어링·데이터 인프라·법무 팀의 사례를 구체적으로 소개한다. 공통점은 코드 생성 자체보다 문제를 이해하고 검증하는 도구로 사용했다는 점이다.

Security Engineering

제어 흐름을 빠르게 추적한다

stack trace와 문서를 함께 주고 코드베이스의 흐름을 따라가게 한다. Terraform plan 분석, 보안 검토, 병목 제거에 사용한다.

≈3×

원문: 10~15분 걸리던 수동 탐색이 약 3배 빨라짐.

Data Infrastructure

로그가 아니라 스크린샷으로도 진단한다

Kubernetes가 pod scheduling을 멈춘 상황에서 오류 화면 캡처를 입력으로 주고, Claude Code가 화면의 내용을 읽어 IP 주소 고갈을 원인으로 판단해 실행 가능한 수정 명령을 제시했다고 서술한다.

Legal

비개발 부서도 내부 도구를 만든다

법무팀이 전통적인 개발 리소스나 외부 벤더 없이 적절한 변호사를 찾도록 돕는 프로토타입 전화 트리 시스템을 직접 만들었다는 사례다.

가장 성공적인 팀은 Claude Code를 코드 생성기라기보다 생각을 확장하고 검증하는 동료로 사용했다는 것이 원문의 결론이다.

기능이 많아서 좋은 Harness가 되는 것은 아니다. Boris의 짧은 CLAUDE.md와 모델 업그레이드 후 단순화된 세 Agent 구조가 보여주듯, 좋은 Harness는 좋은 코드처럼 불필요한 한 줄을 줄이고, 남은 한 줄의 역할을 선명하게 만든다.
08

뜻밖의 투시 — 소스 유출이 보여준 Harness의 실제 모습

원문 후반은 2026년 3월 31일의 패키징 사고를 다룬다. 여기서 중요한 것은 유출 자체의 선정성이 아니라, 고도화된 AI 시스템도 가장 기초적인 배포 설정 한 줄에 의해 흔들릴 수 있다는 공학적 역설이다.

2026 · 03 · 31

.npmignore 한 줄의 부재

원문은 정상 npm 배포에 source map이 함께 포함되면서 Claude Code의 대규모 TypeScript 소스가 공개됐다고 설명한다.

59.8 MB 원문이 언급한 source map 크기
512K 노출된 TypeScript 소스 라인 수
50K 원문: clean-room 재구현 저장소가 2시간 내 얻은 별 수
8K+ → 96 원문이 서술한 저작권 삭제 요청 규모 변화

코드 안에서 보였다고 원문이 소개하는 두 이름

원문은 유출된 코드에서 아직 공개되지 않은 기능과 내부 이름을 확인할 수 있었다고 설명한다. 여기서는 해당 내용을 원문 수준의 개념 설명으로만 요약한다.

KAIROS

150회 이상 등장한 것으로 서술되는 always-on 자율 데몬 모드. 필요할 때만 부르는 도구가 아니라 배경에서 계속 실행되는 Agent 개념으로 설명된다.

Capybara

원문이 Claude 4.6 계열 변형의 내부 코드명으로 소개하는 이름이다.

원문은 이 사고를 “AI Harness 설계에서 앞선 조직도 가장 기초적인 패키징 설정으로 무너질 수 있다”는 사례로 읽는다. Harness Engineering은 모델 바깥의 사소한 배포 설정까지 포함하는 공학 문제라는 뜻이다.
아이러니하게도 사고는 또 다른 사실을 비췄다. 원문은 공개 문서보다 더 깊은 CLAUDE.md 상속 구조, Hooks, 네 종류의 Memory, 아홉 단계의 컨텍스트 압축 메커니즘이 실제 생산 코드에 존재했음을 커뮤니티가 확인할 수 있었다고 서술한다. Harness는 선언이 아니라 실제로 돌아가는 코드와 설정의 총합이라는 사실이 드러난 셈이다.

혼자 만드는 능력보다 중요한 것은
서로 다른 눈으로 서로를 보게 하는 구조다.

Planner는 방향을 만들고,
Generator는 형태를 만들며,
Evaluator는 의심을 만든다.

그리고 그 사이의 계약과 피드백이
“만들었다”를 “쓸 수 있다”로 바꾼다.

Harness의 힘은 Agent 하나의 천재성보다 역할 사이의 관계에서 나온다.

이 웹페이지는 첨부 문서 《Harness Engineering》의 §08 「Anthropic：让AI查AI / Anthropic: Let AI Review AI」(PDF 38–42쪽)에만 근거해 재구성했다. 원문의 실험 수치, 제품·기능명, 모델 버전, 팀 사례, 소스 유출 관련 서술과 평가를 원문 맥락 안에서 요약했으며, 외부 자료를 통한 검증·정정·확장은 수행하지 않았다.