AI 코딩 에이전트에게 “이 앱 만들어줘”라고 맡기면 처음 20분은 인상적이다. 파일이 생기고, 서버가 뜨고, UI가 나타난다. 그런데 1시간쯤 지나면 이상한 일이 벌어진다.
- 핵심 기능이 고장 난 채로 “완성됐습니다!”라고 선언한다.
- 디자인이 어디서 본 듯한 보라색 그라디언트 템플릿이다.
- 컨텍스트가 길어지면 갑자기 서둘러 마무리 짓는다.
Anthropic은 이 문제를 정면으로 다룬 엔지니어링 블로그 Harness Design for Long-Running Application Development를 발표했다. 나는 이 글의 핵심을 Claude Code에서 바로 실행 가능한 스킬로 만들었다. 그 과정을 공유한다.
원인 진단: 두 가지 구조적 실패
Anthropic이 밝힌 근본 원인은 두 가지다.
Solo Agent 실제 결과 (Retro Game Maker)
- Solo: 20분, ~$9 → 핵심 기능 고장난 채 배포
- Full Harness: 6시간, ~$200 → 완성도 높은 기능적 애플리케이션
이것은 모델의 지능 문제가 아니다. 아키텍처의 문제다.
해법: GAN에서 영감받은 3-에이전트 분리
Anthropic의 핵심 통찰은 GAN(Generative Adversarial Network)에서 왔다. 생성자와 판별자를 분리하듯, 코드를 만드는 놈과 평가하는 놈을 물리적으로 분리한다.
에이전트 간 대화 내용을 전달하지 않는다. 오직 파일만 전달한다. 이것이 “context reset”을 가능하게 한다. Compaction(요약)은 불안 신호를 그대로 가지고 가지만, 새 세션 + 파일 읽기는 완전한 fresh start를 준다.
핵심 패턴 요약
| 패턴 | 역할 |
|---|---|
| Context Resets | 에이전트마다 새 세션. Compaction 대신 완전한 fresh start |
| 파일 기반 핸드오프 | spec.md, sprint_contract.md, generator_report.md, critique.md |
| Sprint Contract | 코딩 전에 Generator와 Evaluator가 검증 기준을 합의 |
| 적대적 평가 | Evaluator는 Generator의 적. 증거 필수 |
| 7-criteria 루브릭 | Design Quality, Originality, Craft, Functionality + Correctness, Robustness, Usability |
| 5-15회 반복 | 디자인 슬라이스당. 적으면 부족, 많으면 thrash |
왜 “스킬”로 만들었는가
| 선택지 | 문제 |
|---|---|
| 매번 블로그를 다시 읽고 프롬프트를 손으로 작성 | 느리고 일관성 없음 |
| 한 번 작성한 프롬프트를 텍스트 파일로 보관 | Claude Code가 자동으로 발견 못함 |
| Claude Code 스킬로 패키징 | “하네스 프롬프트” 한마디에 자동 로드 |
스킬로 만들면 세 가지 이점이 있다.
- 자동 발견 — “앱 만들 때 프롬프트 필요해”라고 말하면 description 매칭으로 스킬이 활성화된다.
- 원칙 + 프롬프트 동시 로드 — 단순 프롬프트 복붙이 아니라, 왜 이렇게 해야 하는지(원칙)와 어떻게 하는지(프롬프트)가 함께 들어온다.
- 다른 하네스의 참조 구현 —
app-build-harness,business-plan-harness같은 실행형 스킬을 만들 때 이 스킬의 프롬프트를 그대로 가져다 쓸 수 있다.
제작 과정: 분석 → 프롬프트화 → 누락 검증 → 스킬 패키징
STEP 3: 교차 검증에서 발견한 누락 항목
처음 작성한 스킬에서 원문 대비 누락된 것들이 있었다.
| 원문 포인트 | 처음 스킬 상태 |
|---|---|
| GAN-inspired 프레이밍 | ❌ 누락 |
| 4-criteria 디자인 루브릭 | ⚠️ 5-criteria로 변형 |
| 5-15회 반복 가이드 | ❌ cap 5로 축소 |
| Evaluator 튜닝 워크플로우 | ⚠️ 1줄만 언급 |
| 모델별 가이드 (Sonnet/Opus) | ❌ 누락 |
| 케이스 스터디 수치 | ❌ 누락 |
| “Harness shifts, not diminishes” | ⚠️ 약한 표현 |
의역하거나 축약하면 원문의 의도가 왜곡된다. 원문 포인트 18개를 하나씩 스킬 내 위치에 매핑하는 표를 만들어 전수 검증했다.
Sprint Contract — 코딩 전 합의
대부분의 에이전트 루프에서 빠져 있는 것이 이것이다. 코드를 쓰기 전에 “무엇을 만들고, 어떻게 성공을 확인할지”를 합의한다. 이 단계가 없으면 Evaluator의 기준이 모호해지고, Generator는 “되긴 되는데…” 수준에서 멈춘다.
Evaluator는 적(敵)이다
칭찬은 없다. 증거가 있다. 루브릭 점수가 있다. 재현 단계가 있다. 이것이 “self-evaluation bias”를 구조적으로 제거하는 방법이다.
Evaluator의 태도
❌ “전반적으로 잘 만들어졌습니다.”
❌ “약간의 개선이 필요합니다.”
❌ “UI가 깔끔해 보입니다.”
✅ “Correctness 2/5: spec.md §3.2의 ‘빈 카트 상태에서 메시지 표시’가 미구현. 스크린샷 evidence_04.png 참조.”
✅ “Robustness 1/5: 한글 입력 시 500 에러. curl -X POST … 응답 본문 첨부.”
✅ “VERDICT: FAIL. Blocking issues: 4건.“
스킬의 구조: 5개 프롬프트 + 6개 가이드 섹션
| 컴포넌트 | 설명 |
|---|---|
| PROMPT 1 — Planner | 1-4줄 아이디어 → spec.md (제품 수준, 구현 X) |
| PROMPT 2 — Generator | spec.md 읽고 → sprint_contract.md 협상 → 코드 구현 |
| PROMPT 3 — Evaluator | Playwright 실측 → 4+3 루브릭 채점 → critique.md |
| PROMPT 4 — Orchestrator | 컨텍스트 리셋 기반 루프 제어 |
| PROMPT 5 — Simplified | 단일 세션에서 전체 discipline 유지 (Opus 4.5/4.6용) |
| Evaluator tuning | 로그 읽기 → 판단 괴리 식별 → 프롬프트 수정 반복 |
| Reference stack | React/Vite + FastAPI + SQLite (원문 측정 기준) |
| Model-specific guidance | Sonnet 4.5: 무거운 하네스 / Opus 4.5-4.6: 경량화 가능 |
| Case studies | Retro Game Maker ($9 vs $200) / DAW ($124.70) |
| Harness shifts | 복잡도는 사라지는 게 아니라 이동한다. |
모델이 좋아지면 하네스가 필요 없어질까?
아니다. 이것이 원문의 가장 중요한 통찰이다.
모델이 좋아지면 일부 스캐폴딩이 불필요해진다. 예를 들어 Opus 4.6에서는 sprint decomposition을 제거하고도 DAW를 3시간 50분/$124.70에 빌드했다. 하지만 동시에 새로운 조합의 가능성이 열린다 — 병렬 서브에이전트, 더 긴 자율 세션, 더 복잡한 도구 그래프, 더 야심찬 태스크.
핵심 원칙
복잡도는 “줄어드는” 게 아니라 “이동”한다. 하네스의 각 구성 요소가 여전히 load-bearing인지 주기적으로 재검토하라. 불필요해진 부분은 제거하되, 그 여유를 더 어려운 태스크에 투자하라.
실용적 사용법
| 비교 | 풀 하네스 (PROMPT 1-4) | 간이 하네스 (PROMPT 5) |
|---|---|---|
| 적합한 상황 | 모델 solo 범위를 넘는 복잡한 앱 | Opus 4.5/4.6, 빠른 프로토타이핑 |
| 디자인 중요도 | ✅ 높음 — 5-15회 반복 | 자기 루브릭으로 discipline 유지 |
| 권장 모델 | Sonnet 급 | Opus 급 |
| 비용 참고 | ~$200 (Retro Game Maker) | ~$124 (DAW) |
Claude Code에서 다음과 같은 키워드로 자동 활성화된다.
"하네스 프롬프트"
"앱 만들 때 프롬프트"
"코딩 에이전트 루프 설계"
"harness design prompts"
"planner generator evaluator loop"또는 직접 호출: /harness-driven-dev
마무리: 엔지니어링 블로그를 “실행 가능한 지식”으로
좋은 엔지니어링 블로그 글을 읽으면 “아, 그렇구나” 하고 끝나기 쉽다. 이 글의 통찰들 — context reset, sprint contract, adversarial evaluation, file-based handoff — 은 읽어서 아는 것과 실제로 프롬프트에 녹여 쓰는 것 사이에 큰 간극이 있다.
스킬은 그 간극을 메운다. “하네스 프롬프트” 한마디에 원문의 18개 포인트가 모두 반영된 5개의 system prompt와 10개의 운영 원칙이 로드된다. 매번 블로그를 다시 읽을 필요 없이, “앱 만들어줘”라는 요청이 구조적으로 더 나은 결과를 내게 하는 장치가 되는 것이다.
GitHub: greeun/harness-driven-dev
원문: Harness Design for Long-Running Application Development — Anthropic Engineering Blog