Harness Agent Team Designer

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의 멀티에이전트 기능 세 가지를 사용한다. 작업 흐름에 맞춰 다음 모드 가운데 하나를 고른다.

다음 순서로 결정한다.

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를 쓴다. 예를 들어 논문 한 편을 깊이 비판하는 작업에는 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. 본문 작성 원칙

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

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

• 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번 병렬로 호출하고 완료 알림에서 결과를 모은다. 호출한 에이전트는 기본적으로 백그라운드에서 실행된다.

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