TL;DR
Anthropic의 엔지니어링 아티클 “Harness Design for Long-Running Application Development”에서 제시한 Planner → Generator → Evaluator 3-에이전트 Harness 패턴을 코드가 아닌 사업계획서 작성 도메인에 이식했다. 결과물은 Claude Code 스킬(business-plan-harness)로 패키징되어, “사업계획 써줘” 한 마디에 자동 발동된다.
1. 문제 인식 — AI 사업계획서의 한계
AI에게 “사업계획서 써줘”라고 하면 보통 이런 결과가 나온다:
┌──────────────────────────────────────────────────┐
│ 일반적인 AI 사업계획서 │
├──────────────────────────────────────────────────┤
│ ✗ 어떤 주제든 동일한 템플릿 구조 │
│ ✗ "시장 규모는 XX조 원" 류의 검증 불가 숫자 │
│ ✗ 경쟁사 분석이 표면적 나열에 그침 │
│ ✗ 실행 가능한 첫 번째 행동이 없음 │
│ ✗ 자기가 쓴 글을 자기가 "좋다"고 평가 │
└──────────────────────────────────────────────────┘이 현상의 근본 원인은 Anthropic 아티클이 코드 도메인에서 정확히 짚어낸 것과 동일하다:
자기 평가(self-evaluation)의 한계: 생성자가 자신의 결과물을 높게 평가하는 경향이 있으며, 주관적 품질 판단에서 이 편향이 극대화된다.
사업계획서는 코드보다 더 주관적이다. 컴파일 에러나 테스트 실패 같은 이진 검증이 없다. 그래서 생성과 평가를 분리하는 것이 더욱 절실하다.
2. 원천 — Anthropic Harness 설계 아티클
Prithvi Rajasekaran(Anthropic Labs)이 2026년 3월에 발표한 이 아티클의 핵심 구조:
┌─────────────┐
│ Planner │
│ (Spec 생성) │
└──────┬──────┘
│ spec.md
▼
┌─────────────────────────────┐
│ Sprint Loop │
│ │
│ ┌───────────┐ critique │
│ │ Generator │◄────────┐ │
│ │ (구현/작성)│ │ │
│ └─────┬─────┘ │ │
│ │ output │ │
│ ▼ │ │
│ ┌───────────┐ FAIL │ │
│ │ Evaluator │─────────┘ │
│ │ (검증/채점)│ │
│ └─────┬─────┘ │
│ │ PASS │
│ ▼ │
│ 다음 Sprint │
└─────────────────────────────┘
│
▼
최종 산출물이 구조에서 GAN(Generative Adversarial Network)의 영감이 보인다 — 생성자와 판별자가 서로 긴장 관계를 유지하며 품질을 끌어올린다.
아티클의 핵심 발견들
| 발견 | 코드 도메인 증거 | 사업계획 도메인 시사점 |
|---|---|---|
| 자기 평가의 실패 | Agent가 mediocre한 결과를 자신 있게 칭찬 | 사업계획도 “좋은 것 같습니다”로 끝나는 자기 검증 패턴 |
| Context anxiety | 긴 작업에서 조기 마무리하는 행동 | 사업계획서의 뒤쪽 섹션이 앞쪽보다 품질이 떨어지는 현상 |
| Context reset > Compaction | 문맥 압축보다 핸드오프 후 리셋이 효과적 | 각 Sprint마다 handoff.md를 쓰고 리셋 |
| Solo vs Harness | Solo: 20분/$9 → 게임 작동 불능 | 단일 프롬프트 사업계획서: 빠르지만 실행 불가 |
| Harness: 6시간/$200 → 16 feature 완성 | Harness 사업계획서: 느리지만 투자 검토용 품질 | |
| Evaluator 튜닝 | 기본 상태에서 Claude는 나쁜 QA 에이전트 | 관대한 평가 → 로그 리뷰 → 프롬프트 개선 루프 필요 |
3. 도메인 전환 — 코드에서 사업계획으로
4대 평가 기준의 매핑
원문의 프론트엔드 디자인 평가 기준 4개를 사업계획 도메인으로 1:1 전환했다:
코드/디자인 도메인 사업계획 도메인
┌─────────────────┐ ┌─────────────────────┐
│ Design Quality │ ──────► │ Strategic Coherence │
│ (디자인 품질) │ │ (전략적 일관성) │
│ │ │ 문제-솔루션-고객- │
│ │ │ 모델-GTM이 서로 강화 │
└─────────────────┘ └─────────────────────┘
┌─────────────────┐ ┌─────────────────────┐
│ Originality │ ──────► │ Originality & Insight│
│ (독창성) │ │ (독창성 & 통찰) │
│ AI 패턴/템플릿 │ │ 스타트업 상투어구 │
│ 사용 여부 체크 │ │ 사용 여부 체크 │
└─────────────────┘ └─────────────────────┘
┌─────────────────┐ ┌─────────────────────┐
│ Craft │ ──────► │ Craft & Rigor │
│ (기술적 완성도)│ │ (정밀성 & 엄밀성) │
│ 타이포/스페이싱│ │ 숫자 일관성/출처 │
└─────────────────┘ └─────────────────────┘
┌─────────────────┐ ┌─────────────────────┐
│ Functionality │ ──────► │ Executability │
│ (기능성) │ │ (실행 가능성) │
│ 사용자가 작업 │ │ 창업팀이 다음 주에 │
│ 완수 가능한가 │ │ 행동 가능한가 │
└─────────────────┘ └─────────────────────┘가중치도 원문을 따른다: Design Quality + Originality에 가중치를 둔 것처럼, 사업계획에서도 전략적 일관성 + 독창성을 Craft/Executability보다 우선한다. Claude는 기본적으로 형식적 완성도(Craft)와 기능적 체크리스트(Executability)를 잘 해내기 때문이다.
Sprint 시퀀스 전환
코드 도메인의 “한 기능씩 Sprint”가 사업계획에서는 8단계 주제별 Sprint가 된다:
Sprint 1 ┃ Discovery ┃ 문제, 고객, 고통 증거, 비교 대상
Sprint 2 ┃ Value & Positioning┃ 가치 제안, 차별화, 쐐기
Sprint 3 ┃ Business Model ┃ 가격, 단위경제학, 수익 모델
Sprint 4 ┃ GTM ┃ 획득 채널, 첫 100명 고객
Sprint 5 ┃ Operations & Team ┃ 빌드 vs 바이, 조직, 채용
Sprint 6 ┃ Financials ┃ 18개월 계획, 런웨이, KPI
Sprint 7 ┃ Risk & Kill-criteria┃ 중단 기준과 시점
Sprint 8 ┃ Consolidation ┃ final_plan.md 조립
┃ ┃
┃ 각 Sprint마다: ┃
┃ • 계약 → 작성 → ┃
┃ 평가 → 수정(~5회)┃
┃ • handoff.md 작성 ┃
┃ • context reset ┃4. 왜 이 접근이 강력한가 — 5가지 강점
강점 ① 자기 칭찬 차단
일반 AI Harness AI
───────── ──────────
Generator ──► "잘 됐습니다" Generator ──► output
│ │
▼ ▼
사용자에게 전달 Evaluator ──► "Sprint FAIL
│ 전략적 일관성 2/5:
│ GTM이 고객 정의와
│ 모순됨"
▼
Generator 수정Anthropic 아티클이 발견한 핵심 — “독립적인 evaluator를 회의적으로 튜닝하는 것이 generator를 자기비판적으로 만드는 것보다 쉽다” — 이 사업계획 도메인에서 더욱 유효하다. 사업계획은 코드와 달리 컴파일 에러 같은 객관적 실패 신호가 없기 때문이다.
강점 ② Context anxiety 방지
일반 AI의 사업계획서 품질 곡선
품질
▲
│ ████
│ ██████
│ ████████
│ ██████████
│ ████████████
│ ██████████████ ←── context anxiety 발동
│ ████████████████████▂▂▂▁▁ ←── 급격히 마무리
└──────────────────────────────► 섹션
시장 경쟁사 모델 GTM 재무 리스크
분석 분석 전략 계획 분석 Harness의 사업계획서 품질 곡선
품질
▲
│ ████ ████ ████ ████ ████ ████
│ ████ ████ ████ ████ ████ ████
│ ████ ████ ████ ████ ████ ████
└──────────────────────────────────────► Sprint
S1 S2 S3 S4 S5 S6
각 Sprint마다 context reset + handoff.md각 Sprint 경계에서 handoff.md를 작성하고 context를 리셋함으로써, 뒤쪽 섹션(재무, 리스크)의 품질이 앞쪽 섹션(시장 분석)과 동등하게 유지된다.
강점 ③ Sprint 계약 — “무엇이 완료인가”의 사전 합의
코드 도메인에서 Evaluator가 잡아낸 계약 위반 사례들:
| 계약 조건 | 판정 |
|---|---|
| “사각형 채우기 도구로 드래그하면 영역이 채워져야 함” | FAIL — 시작/끝 점에만 타일 배치 |
| “사용자가 엔티티 스폰 포인트를 선택/삭제할 수 있어야 함” | FAIL — delete 핸들러가 두 변수를 동시에 요구하나 클릭 시 하나만 설정 |
사업계획 도메인에서의 동등한 계약 예시:
| Sprint 계약 조건 | 평가 결과 |
|---|---|
| “단위경제학에서 CAC, LTV, Payback period가 서로 일관되어야 함” | FAIL — CAC $50인데 LTV 계산에 churn rate 미반영, 실제 LTV는 제시된 값의 1/3 |
| “GTM 전략의 첫 100명 고객 획득 방법이 구체적 채널과 비용을 포함해야 함” | FAIL — “소셜 미디어 마케팅”만 언급, 채널/예산/전환율 없음 |
| “경쟁사 분석에 named comparables 최소 3개와 차별화 축이 있어야 함” | PASS — 3개 비교 대상, 2축 포지셔닝 맵 포함 |
강점 ④ Solo vs Harness — 비용 대비 품질
원문의 RetroForge 게임 메이커 사례가 시사하는 바:
┌─────────────────────────────────────────────────────┐
│ Solo Run Full Harness │
│ ───────────────────── ─────────────────────── │
│ 시간: 20분 시간: 6시간 │
│ 비용: $9 비용: $200 (22×) │
│ 결과: 게임 작동 불능 결과: 16 feature 완성 │
│ 레이아웃 공간 낭비 전체 뷰포트 활용 │
│ 워크플로 경직 AI 스프라이트 생성 │
│ 엔티티 와이어링 끊김 물리엔진 기본 작동 │
└─────────────────────────────────────────────────────┘사업계획 도메인 예측:
┌─────────────────────────────────────────────────────┐
│ 단일 프롬프트 Harness 8-Sprint │
│ ───────────────────── ─────────────────────── │
│ • 2,000단어 일반 템플릿 • 10,000~15,000단어 │
│ • 검증 안 된 시장 규모 • 출처 표기 or ASSUMPTION │
│ • "다양한 채널 활용" • 채널별 CAC/전환율 추정 │
│ • 실행 로드맵 없음 • 주차별 첫 90일 계획 │
│ • 리스크 = "경쟁 심화" • Kill-criteria + 시점 │
└─────────────────────────────────────────────────────┘강점 ⑤ 모델 진화에 따른 Harness 적응
아티클의 핵심 교훈:
모델 성능 ──────────────────────────────────────►
Sonnet 4.5 Opus 4.5 Opus 4.6
┌────────┐ ┌────────┐ ┌────────┐
│Sprint별│ │Sprint별│ │Sprint │
│평가 필수│ │평가 유지│ │구조 제거│
│Context │ │Context │ │단일 패스│
│reset │ │anxiety │ │평가로 │
│필수 │ │감소 │ │전환 가능│
└────────┘ └────────┘ └────────┘
Harness 복잡도 ◄──────────────────────────────────이것이 의미하는 바: – Harness의 각 구성 요소는 “모델이 혼자서는 못하는 것”에 대한 가정을 인코딩한다. – 모델이 발전하면 그 가정을 재검증하고, 불필요한 구조를 제거해야 한다. – 사업계획 스킬도 마찬가지 — 모델이 개선되면 Sprint 수를 줄이거나, Evaluator를 최종 1회만 돌리는 것이 가능해진다. – Harness의 유용한 조합 공간은 모델이 발전할수록 줄지 않는다 — 이동할 뿐이다.
5. 스킬 제작 과정
전체 흐름
① URL 분석 ② 인벤토리 추출
┌─────────────┐ ┌──────────────────┐
│ Anthropic │ WebFetch │ 모든 사실 포인트 │
│ 아티클 URL │────────────►│ 개념, 숫자, 사례 │
│ │ │ 도구, 원칙, 교훈 │
└─────────────┘ └────────┬─────────┘
│
③ 도메인 전환 │
┌──────────────────┐ │
│ 코드 → 사업계획 │◄────────────────┘
│ 4기준 매핑 │
│ Sprint 시퀀스 설계 │
│ 파일 산출물 정의 │
└────────┬─────────┘
│
④ SKILL.md 작성 ⑤ 검증 & 보강
┌──────────────────┐ ┌──────────────────┐
│ Source Reference │ │ 누락 체크 │
│ (전체 인벤토리) │ │ 한글 트리거 확장 │
│ Operational │ │ 직접 인용 → 요약 │
│ Mapping (16행) │ │ Frontmatter 정비 │
│ Roles / Criteria │ │ │
│ Sprint Sequence │ │ │
│ Execution Proto │ │ │
└──────────────────┘ └──────────────────┘핵심 설계 결정들
결정 1: Source Reference를 SKILL.md 안에 포함
원문의 모든 사실을 SKILL.md 내부에 유지했다. 이유: – 스킬이 발동될 때 Claude가 원문의 맥락 전체를 참조할 수 있어야 한다. – 별도 references/ 파일로 분리하면 필요한 시점에 로드되지 않을 수 있다.
결정 2: Operational Mapping 표
원문의 코드 개념 ↔ 사업계획 개념을 16행 표로 1:1 매핑했다. 이 표가 없으면 Claude가 원문의 코드 예시를 “참고만 하고” 사업계획에는 적용하지 않는 경우가 생긴다.
결정 3: 한글 + 영문 듀얼 트리거
영문 트리거 (9개) 한글 트리거 (23개)
───────────────── ─────────────────────
business plan 사업계획 / 사업 계획서
startup plan 사업 기획 / 사업 기획서
venture plan 사업 전략 / 사업 제안서
GTM plan 창업 계획 / 창업 기획서
go-to-market strategy 비즈니스 플랜 / 비즈니스 모델
validate my business idea 스타트업 계획 / 스타트업 기획
business model canvas 시장 진입 전략 / GTM 전략
draft a business plan 사업 아이템 검증 / 사업 검증
plan for my business idea 사업 아이디어 평가 / 사업 주제 분석
사업계획서 작성 / 벤처 계획
창업 아이디어6. 산출물 구조
스킬이 완료되면 아래 파일들이 business-plan/ 디렉토리에 생성된다:
business-plan/
├── spec.md ← Planner가 작성한 전체 사양서
├── plan.md ← Sprint별 섹션이 누적된 본문
├── critique.md ← Evaluator의 평가 이력
├── handoff.md ← 각 Sprint 경계의 인수인계 문서
├── final_plan.md ← 통과한 Sprint들의 최종 조립본
└── assumptions_and_risks.md ← 검증되지 않은 모든 가정의 목록assumptions_and_risks.md가 특히 중요하다. 일반 AI 사업계획서에는 이 파일이 없다. 모든 숫자가 “사실”처럼 제시된다. Harness는 검증되지 않은 주장에 ASSUMPTION: 라벨을 강제하고, 최종 산출 시 이를 모아서 별도 파일로 분리한다.
7. 마무리 — Harness는 왜 사라지지 않는가
모델이 발전하면 Harness가 불필요해지지 않을까?
Anthropic 아티클의 답:
아니다. 모델이 강해지면 Harness 없이도 할 수 있는 범위가 넓어진다. 하지만 동시에, 더 강한 모델 위에 Harness를 얹으면 도달할 수 있는 복잡도의 천장도 함께 올라간다. Solo $9 게임이 작동하는 수준으로 모델이 발전해도, $200 Harness를 얹으면 그때는 더 복잡한 게임을 만들 수 있다.
사업계획도 마찬가지다. 모델이 발전하면 Sprint 8개가 5개로 줄어들 수 있다. Evaluator가 매 Sprint가 아닌 최종 1회만 필요할 수 있다. 하지만 생성과 평가의 분리, 계약 후 작업, 검증되지 않은 가정의 명시적 추적 — 이 원칙들은 모델 성능과 무관하게 사업계획의 품질을 결정하는 구조적 요인이다.
┌─────────────────────────────────────────────────┐
│ │
│ 유용한 Harness 조합의 공간은 │
│ 모델이 발전할수록 줄어들지 않는다. │
│ 이동할 뿐이다. │
│ │
│ — 이 스킬의 설계 철학 │
│ │
└─────────────────────────────────────────────────┘이 스킬은 business-plan-harness로 공개되어 있다. “사업계획 써줘”로 시작해보자.