harness

Harness v2 — 에이전트 팀과 스킬 설계

프로젝트에 맞는 하네스를 설계한다. 각 에이전트의 역할을 정의하고, 에이전트가 작업할 때 따를 스킬을 만든다.

핵심 원칙

1. 에이전트 정의는 프로젝트/.claude/agents/에, 스킬은 프로젝트/.claude/skills/에 만든다. 에이전트에는 누가 일하는지를, 스킬에는 그 일을 어떻게 하는지를 적는다.
2. 작업 흐름에 따라 실행 모드를 고른다. 순서와 반복 조건을 코드로 정할 수 있으면 워크플로로 조율한다. 같은 전문가와 피드백을 주고받아야 하면 지속형 에이전트를 쓴다. 결과를 한 번만 받으면 되는 작업은 서브에이전트에 맡긴다. 자세한 선택 기준은 2단계에서 다룬다.
3. 업무의 복잡도, 작업 기간, 자율성, 응답 속도에 맞춰 모델을 고른다. 계획을 세워 장기간 자율적으로 실행해야 하는 최고 난도 업무에는 fable, 설계·코드 생성·복잡한 분석·교차 검증에는 opus, 로그 분석·형식 변환·단순 수집 같은 일상 업무에는 sonnet을 쓴다. 자세한 기준은 3단계에서 다룬다.
4. 새 세션에서도 오케스트레이터 스킬을 불러올 수 있도록 CLAUDE.md에 호출 조건과 변경 이력만 기록한다.
5. 실행 결과에서 배운 내용을 에이전트·스킬·CLAUDE.md에 계속 반영한다. 회고하고 변경 사항을 찾아내는 작업은 harness:evolve 스킬이 맡는다.
6. 생성하는 에이전트 정의, 스킬, 오케스트레이터, CLAUDE.md 기록은 사용자가 대화에 쓰는 언어로 작성한다. 이 스킬 문서와 references/의 템플릿이 한국어로 쓰였다는 이유로 산출물을 한국어로 쓰지 않는다. 템플릿의 제목과 예시 문구도 그 언어로 옮긴다. 사용자가 언어를 따로 정하면 그 언어를 따르고, 따로 정하지 않은 채 기존 하네스를 확장하면 기존 파일의 언어를 따른다.

진행 절차

0단계: 현재 상태 점검

하네스 스킬을 불러오면 기존 구성을 먼저 확인한다.

1. 프로젝트/.claude/agents/, 프로젝트/.claude/skills/, 프로젝트/CLAUDE.md를 읽는다.

2. 현재 상태에 따라 진행할 절차를 고른다.

   • 새로 구축: 에이전트나 스킬 디렉터리가 없거나 비어 있으면 1단계부터 모두 실행한다.
   • 기존 구성 확장: 기존 하네스에 에이전트나 스킬을 추가해야 하면 아래 표에서 필요한 단계만 실행한다.
   • 운영·유지 보수: 기존 하네스를 점검·수정·동기화해야 하면 7단계의 운영 절차로 이동한다.

   변경 내용	1단계	2단계	3단계	4단계	5단계	6단계
   에이전트 추가	생략하고 0단계 결과 사용	어떤 실행 모드에서 어느 팀과 단계에 둘지만 결정	필수	전용 스킬이 필요할 때	오케스트레이터 수정	필수
   스킬 추가·수정	생략	생략	생략	필수	연결이 바뀔 때	필수
   구조·실행 모드 변경	생략	필수	영향을 받는 에이전트만	영향을 받는 스킬만	필수	필수

3. 기존 오케스트레이터에 TeamCreate, TeamDelete, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS가 있으면 v1 산출물이다. 현재 실행 환경에서는 작동하지 않으므로 v2로 옮기자고 제안한다. 자세한 방법은 references/execution-modes.md의 「v1에서 v2로 전환」을 따른다.

4. 실제 에이전트·스킬 목록과 CLAUDE.md 기록을 대조해 불일치를 찾는다.

5. 점검 결과와 실행 계획을 사용자에게 알리고 확인받는다.

1단계: 분야와 작업 분석

1. 사용자 요청에서 프로젝트의 분야와 목표를 파악한다.
2. 생성, 검증, 편집, 분석처럼 필요한 작업의 종류를 나눈다.
3. 실행 모드를 고를 수 있도록 작업 흐름을 확인한다.
   • 처리할 목록을 미리 나열할 수 있는가? 예: 파일 N개를 옮기거나 관점 M개를 검토하는 작업
   • 산출물을 검증하고 다시 고치는 반복 절차가 필요한가?
   • 에이전트가 서로 의견을 주고받아야 결과가 좋아지는가?
   • 한 세션 안에서 같은 전문가와 계속 대화해야 하는가?
4. 0단계에서 확인한 기존 에이전트·스킬과 겹치거나 충돌하는 부분을 찾는다.
5. 코드베이스를 살펴 기술 스택, 데이터 모델, 주요 모듈을 파악한다.
6. 사용자가 쓰는 용어와 질문 수준을 보고 설명의 난이도를 맞춘다. 코딩 경험이 적은 사용자에게 검증 조건(assertion), JSON 스키마(JSON Schema) 같은 용어를 설명 없이 쓰지 않는다.

2단계: 실행 모드와 팀 구조 설계

2-1. 실행 모드 선택

Harness v2는 Claude Code의 멀티에이전트 기능 세 가지를 사용한다. 작업 흐름에 맞춰 다음 모드 가운데 하나를 고른다.

실행 모드	사용하는 기능	알맞은 작업
워크플로 조율	Workflow 스크립트의 agent(), pipeline(), parallel(), phase()	처리 목록, 검증 절차, 반복 횟수를 코드로 정할 수 있는 작업. 스키마에 맞춘 결과가 필요하거나 Agent를 수십 번 이상 호출해야 하는 작업
지속형 에이전트 협업	Agent(name:), SendMessage, TaskCreate, TaskUpdate	이름 있는 전문가가 대화 맥락을 유지하면서 피드백·협상·공동 편집을 반복해야 하는 작업
서브에이전트 위임	Agent 한 번 호출. 기본적으로 백그라운드에서 실행하며 병렬 호출 가능	에이전트끼리 대화할 필요가 없고 결과만 한 번 받으면 되는 작업

다음 순서로 결정한다.

1. 처리 목록, 검증 기준, 반복 조건을 미리 코드로 표현할 수 있으면 워크플로를 사용한다. 정해진 흐름을 모델의 그때그때 판단에 맡기지 않아야 같은 방식으로 다시 실행할 수 있다.
2. 코드로 정하기 어렵고, 에이전트끼리 대화하거나 이전 맥락을 기억해야 하면 지속형 에이전트를 사용한다.
3. 두 조건에 해당하지 않고 결과만 필요하면 서브에이전트에 맡긴다.
4. 단계마다 작업 성격이 다르면 혼합 모드로 구성한다. 오케스트레이터에 각 단계의 실행 모드를 적는다.

Workflow 도구를 쓰려면 사용자가 명시적으로 동의해야 한다. 사용자가 직접 워크플로 실행을 요청했거나, Workflow 호출을 지시하는 오케스트레이터 스킬을 사용자가 불러왔다면 동의한 것으로 본다. 기본 실행은 에이전트 몇 명으로 제한하고, 사용자가 "철저히", "전수"처럼 넓은 조사를 요구했을 때만 대규모로 늘린다.

실행 모드 비교와 동시 실행 상한, 스키마, 토큰 예산, 재개 조건은 references/execution-modes.md에서 확인한다.

2-2. 팀 구성 방식 선택

1. 작업을 전문 분야별로 나눈다.
2. 아래 여섯 가지 방식 가운데 작업에 맞는 구성을 고른다. 자세한 기준은 references/team-patterns.md에 있다.
   • 파이프라인: 앞 단계의 결과를 받아 순서대로 처리한다. pipeline()에 알맞다.
   • 분산·통합(팬아웃/팬인): 독립 작업을 병렬로 처리한 뒤 결과를 합친다. pipeline()과 필요할 때만 parallel()을 쓴다.
   • 전문가 풀: 입력에 맞는 전문가만 골라 호출한다. 서브에이전트나 지속형 에이전트에 알맞다.
   • 생성·검증: 한 에이전트가 만들고 다른 에이전트가 검토한다. 워크플로의 적대적 검증이나 지속형 에이전트 한 쌍을 쓴다.
   • 감독자: 중앙 에이전트가 진행 상황을 보고 작업을 다시 배분한다. 지속형 에이전트와 공유 작업 목록을 쓴다.
   • 계층형 위임: 상위 에이전트가 하위 에이전트에 다시 맡긴다. 두 단계 안에서만 사용하고, 워크플로 중첩은 한 단계로 제한한다.
3. 산출물의 정확성이 중요하면 다음 검증 방식을 조합한다.
   • 적대적 검증: 찾은 항목 한 건마다 N명의 적대적 검증 에이전트를 붙이고, 과반이 근거가 충분하다고 confirmed로 판정한 항목만 통과시킨다. refuted나 uncertain 판정은 통과로 세지 않는다.
   • 심사위원단: N개의 시안을 따로 만든 뒤 병렬로 심사하고, 가장 좋은 시안을 바탕으로 최종본을 만든다.
   • 새 항목이 없을 때까지 반복(Loop-until-dry): 새로 찾은 항목이 K회 연속 0건이 될 때까지 탐색한다.
   • 여러 기준으로 탐색: 컨테이너, 내용, 개체, 시간처럼 서로 다른 기준으로 병렬 조사한다.
   • 누락 검토자: 마지막 에이전트에는 빠진 내용만 찾게 한다.

2-3. 에이전트를 나누는 기준

필요한 전문 지식, 병렬 처리 가능 여부, 유지해야 할 대화 맥락, 다시 쓸 가능성을 기준으로 에이전트를 나눈다. 자세한 표는 references/team-patterns.md의 「에이전트 분리 기준」에서 확인한다.

3단계: 에이전트 정의 작성

여러 세션에서 재사용할 전문 에이전트는 프로젝트/.claude/agents/{name}.md 파일로 정의한다. 반복해서 사용할 역할을 Agent 도구의 prompt에만 직접 넣지 않는다.

• 파일로 정의해야 다음 세션에서도 재사용할 수 있다. Agent 도구에서는 subagent_type: "{name}", Workflow에서는 agentType: "{name}"으로 부른다.
• 에이전트가 주고받을 내용을 미리 정해야 협업 결과가 안정적이다.
• 에이전트에는 누가 일하는지를, 스킬에는 그 일을 어떻게 하는지를 적어 서로 섞이지 않게 한다.

재사용할 전문가 역할은 사용자 정의 유형으로 파일에 만들고, 호출할 때 그 파일의 이름을 subagent_type이나 agentType에 지정한다. general-purpose, Explore, Plan 같은 기본 제공 유형을 그대로 쓰는 단발 작업에는 별도 정의 파일을 만들지 않는다.

기존 에이전트와 겹치는지 확인

새 에이전트 파일을 만들기 전에 프로젝트/.claude/agents/의 기존 에이전트와 역할이 겹치는지 확인한다. 1단계를 생략하고 에이전트만 추가할 때도 이 확인은 건너뛰지 않는다. 하네스를 여러 번 구축하거나 확장하면 같은 역할의 에이전트가 이름만 달리해 쌓일 수 있기 때문이다. 겹치면 새 이름으로 만들지 말고 기존 에이전트를 그대로 쓰거나 확장한다. 판단 기준과 예외(도메인을 의도적으로 특화한 경우)는 references/team-patterns.md의 「에이전트 재사용 설계」에서 확인한다.

모델 선택 기준

업무의 복잡도, 작업 기간, 자율성, 응답 속도를 기준으로 에이전트마다 모델을 고른다. YAML 프론트매터(머리말)의 model:이나 호출 인자인 model, opts.model에 지정하고, 선택 이유를 에이전트 정의나 오케스트레이터에 주석으로 남긴다.

모델	선택 기준	대표 업무
fable	스스로 계획하고 여러 단계를 연결해 장기간 자율적으로 실행해야 하는 최고 난도 업무	에이전트 조율, 계획 수립과 장기 실행, 방대한 자료 통합, 막연한 아이디어 구체화
opus	범위는 분명하지만 깊은 추론과 분석이 필요한 전문 업무	설계·아키텍처, 코드 생성, 복잡한 분석, 교차 검증, 연구 방법 비판, 창작
sonnet	절차가 분명하고 빠른 처리가 중요한 일상 업무	로그 분석, 형식 변환, 정적 파일 검사, 배포 스크립트 실행, 단순 수집, 일반 글쓰기·요약

• 앞 단계의 결과에 따라 다음 계획을 바꾸며 장기간 자율적으로 실행해야 하면 fable을 쓴다. 범위가 정해진 문제 하나를 깊이 분석하면 opus를 쓴다. 예를 들어 논문 한 편을 깊이 비판하는 작업에는 opus, 논문 수십 편을 검토해 전략과 보고서까지 만드는 작업에는 fable이 알맞다.
• 판단이 애매한 일반 업무에는 sonnet을 기본값으로 쓴다.
• 에이전트가 중요하다는 이유만으로 모두 fable이나 opus로 지정하지 않는다. 모델은 에이전트의 위상이 아니라 실제 업무 성격으로 고른다.
• 계획과 조율을 맡는 상위 에이전트에 fable을 썼더라도, 하위 작업자는 각 업무에 맞는 모델을 따로 고른다.

모델별 자세한 기준은 references/model-selection-guide.md에서 확인한다.

정의 파일에 넣을 내용

YAML 프론트매터에는 name과 description을 반드시 넣는다. 필요하면 사용할 도구를 제한하는 tools와 모델을 바꾸는 model을 추가한다. 읽기 전용 검토·분석 에이전트의 tools에서는 Edit와 Write를 빼서 파일을 바꾸지 못하게 한다.

반대로 산출물을 고치는 에이전트에는 Write와 함께 Edit도 준다. Edit가 없으면 한 줄을 고칠 때도 파일 전체를 다시 써야 하므로, 산출물이 크면 에이전트가 수정을 포기하고 우회한다. 또 tools에 적은 도구가 실행할 때 주어지지 않은 사례가 있으므로, 지속형 에이전트에게는 첫 보고에서 실제로 쓸 수 있는 도구 목록을 알리게 한다.

본문에는 핵심 역할, 작업 원칙, 입력·출력 규칙, 오류 처리, 협업 방법을 반드시 적는다. 지속형 에이전트에는 ## 통신 규칙을 추가해 SendMessage를 주고받을 대상과 공유 작업 목록 사용법을 정한다.

정의 템플릿, 전체 예시, tools를 제한할 때 주의할 점은 references/team-patterns.md의 「에이전트 정의 구조」에서 확인한다.

QA 에이전트를 둘 때

• QA 에이전트에는 모든 검증 도구를 쓸 수 있는 유형을 지정한다. Explore는 읽기 전용이라 검증 스크립트를 실행할 수 없다.
• 파일 존재 여부만 확인하지 않는다. API 응답과 프런트엔드 훅의 응답 구조를 대조한다.
• 전체 작업이 끝난 뒤 한 번만 검사하지 않는다. 모듈을 완성할 때마다 바로 검사한다.
• 자세한 방법은 references/qa-agent-guide.md를 따른다.

4단계: 스킬 작성

각 에이전트가 따를 스킬을 프로젝트/.claude/skills/{name}/SKILL.md에 만든다. 자세한 작성법은 references/skill-writing-guide.md를 따른다.

4-0. 기존 스킬과 겹치는지 확인

새 스킬을 만들기 전에 프로젝트/.claude/skills/의 기존 스킬과 기능이 겹치는지 확인한다. 겹치면 새 이름으로 만들지 말고 기존 스킬을 에이전트에 연결하거나 확장한다. 판단 기준과 예외(도메인을 의도적으로 특화한 경우), 어디까지 일반화할지는 references/skill-writing-guide.md의 「스킬 재사용 설계」에서 확인한다.

4-1. 디렉터리 구조

skill-name/
├── SKILL.md              # 필수
│   ├── YAML 프론트매터   # name과 description 필수
│   └── Markdown 본문
├── scripts/              # 선택: 반복하거나 결과가 항상 같아야 하는 작업의 실행 코드
├── references/           # 선택: 필요할 때만 읽는 참조 문서
└── assets/               # 선택: 템플릿, 이미지처럼 산출물에 쓰는 파일

4-2. description에 호출 조건 쓰기

Claude는 스킬의 name과 description을 보고 어떤 스킬을 불러올지 판단한다. 이 가운데 description에는 스킬이 하는 일과 사용해야 하는 상황을 구체적으로 적고, 비슷해 보이지만 사용하면 안 되는 경우도 구분한다.

나쁜 예: "PDF 문서를 처리하는 스킬"

좋은 예: "PDF 파일 읽기, 텍스트·표 추출, 병합, 분할, 회전, 워터마크, 암호화, OCR 등 PDF 작업을 수행한다. 사용자가 .pdf 파일을 언급하거나 PDF 산출물을 요청하면 반드시 사용한다."

4-3. 본문 작성 원칙

원칙	적용 방법
이유부터 설명한다	ALWAYS, NEVER만 나열하지 말고 왜 필요한 규칙인지 밝힌다. 이유를 알아야 예외 상황에서도 올바르게 판단할 수 있다.
간결하게 쓴다	SKILL.md는 500줄 미만으로 유지한다. 판단에 도움이 되지 않는 내용은 지우거나 references/로 옮긴다.
원리로 일반화한다	특정 예시에만 맞는 규칙을 만들지 않는다. 여러 입력에 적용할 수 있는 판단 기준을 적는다.
반복 코드는 미리 넣는다	테스트할 때 여러 에이전트가 같은 스크립트를 다시 작성한다면 scripts/에 넣는다.
지시문으로 쓴다	~한다나 ~하라 가운데 문서에 맞는 한 가지 어미를 골라 통일한다. 해야 할 행동이 분명하게 드러나야 한다.

4-4. 필요한 정보만 단계별로 불러오기

스킬은 필요한 정보와 실행 코드를 다음 시점에 불러온다.

정보	불러오는 시점	권장 분량
메타데이터(name, description)	항상	약 100단어
SKILL.md 본문	스킬을 불러올 때	500줄 미만
references/	해당 자료가 필요할 때	제한 없음
scripts/	반복 작업이나 결과가 항상 같아야 하는 작업을 실행할 때	제한 없음. 내용을 읽지 않고 바로 실행할 수 있음

• SKILL.md가 500줄에 가까워지면 세부 내용을 references/로 옮기고, 본문에는 언제 어떤 파일을 읽을지 적는다.
• 참조 문서가 300줄을 넘으면 문서 위쪽에 목차를 넣는다.
• 분야나 프레임워크마다 지침이 다르면 참조 문서를 나눠 필요한 파일만 읽게 한다.

4-5. 에이전트와 스킬 연결

• 에이전트 한 명이 스킬 한 개 이상을 사용할 수 있다.
• 여러 에이전트가 같은 스킬을 공유할 수 있다.
• 스킬에는 일하는 방법을, 에이전트에는 그 일을 맡는 역할을 적는다.

5단계: 통합하고 실행 순서 정하기

오케스트레이터도 스킬이다. 개별 에이전트와 스킬을 하나의 작업 흐름으로 묶고, 누가 언제 어떤 순서로 협업하는지 정한다. 모드별 전체 템플릿은 references/orchestrator-template.md, 워크플로 스크립트 예시는 references/workflow-recipes.md에 있다.

기존 하네스를 확장할 때는 오케스트레이터를 새로 만들지 말고 기존 파일을 고친다. 에이전트를 추가하면 구성, 작업 배정, 데이터 전달 순서에 반영하고 description에도 새 호출 조건을 넣는다.

5-0. 실행 모드별 오케스트레이터

A. 워크플로 조율

오케스트레이터 스킬에 Workflow 스크립트를 정의한다. 스크립트는 meta, phase(), pipeline(), parallel(), agent()로 구성한다. 사용자 정의 유형은 agentType으로 지정하고, 스키마에 맞춘 결과는 schema로 받는다.

[오케스트레이터 스킬] → Workflow(script)
    ├── phase('수집'): pipeline(items, ...)   ← 미리 정한 목록을 분산 처리
    ├── phase('검증'): 적대적 검증 또는 심사위원단
    └── return 구조화된 결과 → 메인이 종합 보고서 작성

B. 지속형 에이전트 협업

이름 있는 에이전트를 실행한 뒤 공유 작업 목록과 SendMessage로 조율한다. TeamCreate와 TeamDelete는 더 이상 없다. 명시적인 팀 객체를 만들지 않으며, 세션에서 이름을 붙여 실행한 에이전트는 자동으로 구성되는 하나의 협업 그룹에 속한다. 해당 에이전트에는 이전 대화 맥락을 유지한 채 다시 메시지를 보낼 수 있다.

[메인 에이전트(리더)]
    ├── Agent(name: "researcher", ...) / Agent(name: "critic", ...)  ← 병렬 실행
    ├── TaskCreate(작업 + 의존 관계)
    ├── SendMessage({to: "critic"}, "researcher의 초안을 검토하라")
    └── 결과 수집 및 종합

C. 서브에이전트 위임

메시지 한 번에 Agent 도구를 N번 병렬로 호출하고 완료 알림에서 결과를 모은다. 호출한 에이전트는 기본적으로 백그라운드에서 실행된다.

단계마다 작업 성격이 다르면 혼합 모드로 구성할 수 있다. 예를 들어 워크플로로 자료를 모은 뒤 지속형 에이전트가 합의해 통합하거나, 지속형 에이전트가 만든 결과를 워크플로로 적대적 검증할 수 있다. 각 단계 위에 **실행 모드:**를 적는다.

5-1. 데이터 전달 방법

방법	구현	알맞은 실행 모드	사용할 때
구조화된 반환값	Workflow의 agent(prompt, {schema})가 검증된 JSON 반환	워크플로 조율	다음 단계가 결과를 코드로 처리해야 할 때
일반 반환값	Agent 도구의 반환 메시지	서브에이전트	메인이 요약 결과를 직접 모을 때
메시지	SendMessage로 에이전트끼리 직접 전달	지속형 에이전트	실시간 조율과 피드백이 필요할 때
공유 작업 목록	TaskCreate, TaskUpdate로 상태 공유	지속형 에이전트	진행 상황, 의존 관계, 동적 배정을 관리할 때
파일	정해 둔 경로에 쓰고 읽기	모든 모드	데이터가 크거나 나중에 작업 과정을 확인해야 할 때

파일로 전달할 때는 다음 규칙을 지킨다.

• 작업 디렉터리 아래 _workspace/에 중간 산출물을 저장한다.
• 파일 이름은 {phase}_{agent}_{artifact}.{ext} 형식을 쓴다. 예: 01_analyst_requirements.md
• 최종 산출물만 사용자가 지정한 경로에 저장한다. _workspace/는 사후 검증을 위해 남긴다.

5-2. 오류 처리

오케스트레이터에 오류 처리 방침을 넣는다.

• 한 번 다시 시도하고 또 실패하면 해당 결과 없이 진행하되, 최종 보고서에 누락 사실을 적는다. 서로 충돌하는 데이터는 지우지 말고 출처와 함께 남긴다.
• 다만 사용량 한도 소진, 인증 만료, 권한 거부처럼 다시 시도해도 결과가 같은 실패는 다시 시도하지 않는다. 다시 시도하면 남은 한도만 쓴다. 부분 산출물을 직접 열어 실제로 어디까지 진행됐는지 확인하고, 누락 내용을 파일로 기록한 뒤 사용자에게 보고한다. 사용량 한도라면 한도가 풀리는 시각도 함께 알린다.
• 멈춘 에이전트가 남긴 빈 곳을 오케스트레이터가 메울 때는 직접 확인한 사실만 대신 반영한다. 에이전트의 판단(예: 어떤 자료를 왜 제외했는지)은 추측해 채우지 않는다. 추측으로 채우면 사후 검증에 쓸 기록을 위조하는 셈이다.
• 워크플로에서 실패하거나 건너뛴 agent()는 null을 반환하고 parallel()은 실패를 예외로 던지지 않는다. 결과 배열에 .filter(Boolean)을 적용하고 빠진 항목 수를 log()로 알려야 한다.
• 지속형 에이전트가 응답하지 않으면 SendMessage로 상태를 확인하고 다시 지시한다. 그래도 실패하면 같은 사용자 정의 유형을 새 이름으로 실행하고, 필요한 작업 맥락을 프롬프트로 넘긴다.

오류 유형별 대응 방법은 references/orchestrator-template.md에서 해당 실행 모드 템플릿의 「오류 처리」를 확인한다.

5-3. 작업 규모

작업 규모	지속형 에이전트 수	워크플로의 Agent 호출 규모
소규모: 작업 10개 미만	2~3명	2~5건
중규모: 작업 10~20개	3~5명	약 10건. 동시 실행 상한을 넘으면 자동 대기
대규모: 작업 20개 초과	감독자 + 작업자 3~5명	수십~수백 건. 전체 상한 1,000건

• 에이전트가 많아질수록 관리 비용도 늘어난다. 기본 규모를 작게 유지한다.
• 사용자가 +500k처럼 토큰 예산을 지정하면 워크플로 스크립트에서 budget.remaining()을 확인해 실행 규모를 조절한다.

5-4. CLAUDE.md에 하네스 연결 정보 기록

구성을 마치면 프로젝트의 CLAUDE.md에 하네스가 있다는 사실과 호출 조건을 기록한다. CLAUDE.md는 새 세션마다 읽히므로 자세한 실행 규칙을 반복해서 넣지 않는다.

## 하네스: {도메인명}

**목표:** {하네스의 핵심 목표 한 줄}

**호출 조건:** {도메인} 관련 작업을 요청받으면 `{orchestrator-skill-name}` 스킬을 사용한다. 단순 질문에는 직접 답해도 된다.

**변경 이력:**
| 날짜 | 변경 내용 | 대상 | 사유 |
| --- | --- | --- | --- |
| {YYYY-MM-DD} | Harness v2로 처음 구성 | 전체 | - |

에이전트·스킬 목록, 디렉터리 구조, 자세한 실행 규칙은 넣지 않는다. 이 정보는 오케스트레이터 스킬과 .claude/agents/, .claude/skills/에서 관리한다. CLAUDE.md에는 호출 조건과 변경 이력만 둔다.

5-5. 후속 요청 처리

오케스트레이터는 처음 실행할 때뿐 아니라 결과를 다시 고칠 때도 작동해야 한다.

1. description에 다시 실행, 재실행, 업데이트, 수정, 보완, {도메인}의 {부분 작업}만 다시, 이전 결과를 바탕으로, 결과 개선 같은 표현을 넣는다.
2. 오케스트레이터의 0단계에서 기존 작업 맥락을 확인한다.
   • _workspace/가 있고 일부만 고쳐 달라는 요청이면 해당 단계나 에이전트만 다시 실행한다.
   • _workspace/가 있고 새 입력을 받았으면 기존 디렉터리를 타임스탬프가 붙은 디렉터리로 옮긴 뒤 새로 실행한다.
   • _workspace/가 없으면 처음부터 실행한다.
   • 워크플로의 직전 runId가 있으면 resumeFromRunId로 재개할 수 있다. 바뀌지 않은 agent() 호출은 캐시 결과를 사용한다.
3. 에이전트 정의에 재호출 방법을 적는다. 이전 결과 파일이 있으면 읽고, 사용자 피드백이 있으면 해당 부분만 고친다.

6단계: 검증과 테스트

생성한 하네스를 검증한다. 자세한 방법은 references/skill-testing-guide.md를 따른다.

6-1. 파일과 참조 검증

• 모든 에이전트 파일이 올바른 위치에 있는지 확인한다.
• 스킬의 YAML 프론트매터에 name과 description이 있는지 확인한다.
• 에이전트끼리 서로 참조하는 이름이 일치하는지 확인한다.
• .claude/commands/에 명령 파일을 만들지 않았는지 확인한다.
• 산출물에 v1 방식인 TeamCreate, TeamDelete, team_name, 실험 기능 플래그가 남지 않았는지 확인한다.

6-2. 실행 모드별 검증

• 워크플로 조율: meta가 값만 담은 리터럴인지, Date.now()와 Math.random()을 쓰지 않았는지, 전체 결과를 기다려야 할 때만 parallel()을 썼는지, .filter(Boolean)이 빠지지 않았는지, phase() 제목이 meta.phases와 일치하는지 확인한다.
• 지속형 에이전트 협업: SendMessage의 발신·수신 경로, 작업 의존 관계, 에이전트 수를 확인한다.
• 서브에이전트 위임: 각 에이전트의 입력과 출력이 이어지는지, 병렬 호출을 메시지 한 번에 묶었는지, 결과를 빠짐없이 모으는지 확인한다.
• 혼합 모드: 각 단계에 실행 모드를 적었는지, 단계가 바뀔 때 데이터가 끊기지 않는지 확인한다.

6-3. 스킬 실행 테스트

1. 스킬마다 실제 사용자가 입력할 법한 구체적인 테스트 요청을 2~3개 만든다.
2. 스킬 적용 실행(With-skill)과 기준 실행(Baseline)을 병렬로 수행해 스킬이 결과를 얼마나 개선하는지 비교한다. 반복해야 하면 A/B 비교 자체를 워크플로로 만들 수 있다.
3. 사용자가 직접 검토하는 정성 평가와 검증 조건(assertion)을 사용하는 정량 평가를 함께 쓴다. 객관적인 조건을 만들 수 없으면 사용자 판단을 따른다.
4. 문제가 나오면 특정 예시만 막는 규칙을 넣지 말고 여러 상황에 적용할 수 있는 원리로 고친다. 다시 테스트하고, 더 고쳐도 얻는 효과가 거의 없을 때까지 반복한다.
5. 여러 에이전트가 같은 코드를 반복해서 만들면 scripts/에 넣는다.

6-4. 호출 조건 검증

1. 스킬을 불러와야 하는 요청을 서로 다른 말투와 명시 수준으로 10개 만든다.
2. 표현은 비슷하지만 다른 스킬이나 도구를 써야 하는 경계 사례도 10개 만든다.

명백히 무관한 요청은 경계를 검증하지 못한다. 예를 들어 이미지 생성 스킬을 시험할 때 피보나치 함수 작성보다 이 엑셀 파일의 차트를 PNG로 추출해 줘가 더 좋은 경계 사례다. 결과는 이미지지만 실제로는 스프레드시트 도구가 더 알맞기 때문이다. 기존 스킬과 호출 조건이 겹치는지도 확인한다.

6-5. 모의 실행

• 오케스트레이터의 단계 순서가 논리적인지 확인한다.
• 데이터 전달 경로가 중간에 끊기지 않는지 확인한다.
• 모든 에이전트의 입력이 앞 단계의 출력과 맞는지 확인한다.
• 오류가 났을 때 대체 절차를 실제로 실행할 수 있는지 확인한다.

6-6. 테스트 시나리오 기록

오케스트레이터 스킬에 ## 테스트 시나리오를 만들고 정상 흐름 한 가지와 오류 흐름 한 가지 이상을 적는다.

7단계: 운영·유지 보수와 개선

하네스는 한 번 만들고 끝나는 산출물이 아니다.

실행 결과를 회고하고 피드백을 반영하는 작업은 harness:evolve 스킬이 맡는다. 사용자가 하네스 회고, 하네스 진화, 피드백 반영해줘라고 요청하면 harness:evolve를 사용한다. 이 스킬은 처음 구성과 현재 상태의 차이를 분석하고, 여러 상황에 적용할 수 있도록 피드백을 정리해 에이전트·스킬·오케스트레이터에 반영한다. CLAUDE.md 변경 이력도 갱신한다.

이 harness 스킬은 기존 하네스를 운영하고 유지 보수하는 다음 절차를 직접 처리한다.

1. 현재 상태 점검: .claude/agents/, .claude/skills/, 오케스트레이터 구성을 비교해 불일치 목록을 만들고 사용자에게 알린다.
2. 조금씩 추가·수정: 한 번에 한 항목만 바꾸고 곧바로 다음 검증을 실행한다.
3. 변경 이력 기록: CLAUDE.md에 날짜, 변경 내용, 대상, 사유를 적는다.
4. 변경 검증: 파일 구조를 확인한다. 호출 조건에 영향을 주면 호출 테스트도 한다. 변경 범위가 크면 실행 테스트와 모의 실행까지 한 뒤 CLAUDE.md와 실제 파일이 일치하는지 마지막으로 확인한다.

다음 상황에서는 harness:evolve로 개선하자고 제안한다.

• 같은 종류의 피드백이 두 번 이상 나왔다.
• 에이전트가 같은 원인으로 반복해서 실패한다.
• 사용자가 오케스트레이터를 거치지 않고 같은 작업을 계속 수동으로 처리한다.

산출물 점검표

• 프로젝트/.claude/agents/에 재사용할 모든 사용자 정의 유형의 파일을 만들었다. 단발 작업에 기본 제공 유형을 그대로 쓰는 경우는 제외했다.
• 프로젝트/.claude/skills/에 필요한 SKILL.md와 참조 문서를 만들었다.
• 오케스트레이터 스킬 한 개에 데이터 전달 방법, 오류 처리, 테스트 시나리오를 넣었다.
• 워크플로 조율, 지속형 에이전트, 서브에이전트 가운데 사용할 실행 모드를 적었다. 혼합 모드라면 단계마다 표시했다.
• 에이전트별 model:을 복잡도, 작업 기간, 자율성, 응답 속도에 따라 골랐고 이유를 주석으로 남겼다. 모든 에이전트에 같은 고성능 모델을 일괄 지정하지 않았다.
• 산출물에 TeamCreate, TeamDelete, 실험 기능 플래그 같은 v1 방식이 남지 않았다.
• 워크플로 스크립트에 .filter(Boolean)을 넣고 meta에는 리터럴만 썼다. 꼭 필요할 때만 parallel()로 전체 결과를 기다린다.
• .claude/commands/에 파일을 만들지 않았다.
• 새 에이전트·스킬을 만들기 전에 기존 것과 역할이 겹치는지 확인했다. 도메인을 의도적으로 특화한 경우가 아니면 겹치는 것은 기존 것을 쓰거나 확장했고, 이름이나 역할이 충돌하지 않는다.
• 에이전트 정의, 스킬, 오케스트레이터, CLAUDE.md 기록을 사용자가 대화에 쓰는 언어로 작성했다. 사용자가 따로 정한 언어나 기존 하네스 파일의 언어가 있으면 그 언어를 따랐다.
• 스킬 description에 해야 할 일과 호출 조건을 구체적으로 적고 후속 요청 표현도 넣었다.
• SKILL.md 본문이 500줄 미만이다. 500줄 이상이면 세부 내용을 references/로 옮겼다.
• 실제 요청과 비슷한 테스트 문장 2~3개로 실행했다.
• 스킬을 불러와야 하는 요청과 불러오면 안 되는 경계 사례로 호출 조건을 검증했다.
• CLAUDE.md에 호출 조건과 변경 이력만 기록했다.
• 오케스트레이터의 0단계에서 처음 실행, 후속 실행, 일부 재실행을 구분한다. 워크플로는 재개 옵션도 다룬다.

참고 문서

• 실행 모드 상세: references/execution-modes.md
• 모델 선택 가이드: references/model-selection-guide.md
• 팀 구성 방식과 에이전트 정의: references/team-patterns.md
• 실전 팀 구성 예시: references/team-examples.md
• 워크플로 스크립트 예시와 주의 사항: references/workflow-recipes.md
• 오케스트레이터 템플릿: references/orchestrator-template.md
• 스킬 작성 가이드: references/skill-writing-guide.md
• 스킬 테스트 가이드: references/skill-testing-guide.md
• QA 에이전트 가이드: references/qa-agent-guide.md