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`는 새 세션마다 읽히므로 자세한 실행 규칙을 반복해서 넣지 않는다. ````markdown ## 하네스: {도메인명} **목표:** {하네스의 핵심 목표 한 줄} **호출 조건:** {도메인} 관련 작업을 요청받으면 `{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`를 따른다.