solo-agent-dispatch

에이전트 배치 스킬

이 스킬은 팀 에이전트들을 효율적으로 배치하여 프로젝트 작업을 병렬 또는 순차로 처리합니다. 각 에이전트는 명확한 목표를 가지고 독립적으로 작동합니다.

1. 유연한 팀 구조

1.1 고정 멤버

코드	이름	역할	설명
PL	준호	프로젝트 리드	모든 에이전트의 조율자, 최종 결정권 (Claude)
PM	민수님	프로젝트 매니저	구현 담당자 (사용자), 최종 산출물 소유자

1.2 에이전트 풀 (프로젝트 규모에 따라 선택)

역할	담당 업무	산출 위치	관련 스킬
리서처	기술/시장 조사, 요구사항 분석, 경쟁사 분석	docs/01_참고자료/	agent-dispatch
기획자	요구사항 명세, 사용자 흐름, 기능 설계	docs/02_기획/	agent-dispatch
디자이너	UI/UX 설계, 와이어프레임, 시각 설계	docs/03_설계/UI_와이어프레임/	agent-dispatch
아키텍트	기술 아키텍처, 시스템 설계, 인프라 설계	docs/03_설계/시스템아키텍처/	agent-dispatch
검증자	테스트 케이스 작성, QA, 버그 리포팅	docs/05_검증/	agent-dispatch
FE개발자	프론트엔드 구현, UI 컴포넌트	docs/04_개발/src/frontend/	agent-dispatch
BE개발자	백엔드 구현, API, 데이터 처리	docs/04_개발/src/backend/	agent-dispatch
DevOps	배포, 인프라, CI/CD, 모니터링	docs/04_개발/	agent-dispatch
데이터 분석가	데이터 모델, 성능 분석, 최적화	docs/01_참고자료/	agent-dispatch
테크라이터	기술 문서, API 문서, 사용자 매뉴얼	docs/06_산출물/	agent-dispatch

1.3 팀 규모 기준

🟢 소규모 (5-15 기능, 1-2개월):

• PL + PM + 2-3 에이전트
• 권장: 리서처, FE/BE개발자 (또는 풀스택 개발자)

🟡 중규모 (15-50 기능, 3-4개월):

• PL + PM + 4-5 에이전트
• 권장: 리서처, 기획자, 디자이너, FE개발자, BE개발자
• 선택: 아키텍트, 검증자

🔴 대규모 (50+ 기능, 6개월 이상):

• PL + PM + 5명 이상 에이전트
• 모든 역할 포함: 리서처, 기획자, 디자이너, 아키텍트, FE개발자, BE개발자, DevOps, 검증자, 데이터 분석가, 테크라이터

1.4 현재 팀 확인

CLAUDE.md - Section 2에서 팀 구성 확인

확인 내용:

• PL(준호) ✓
• PM(민수님) ✓
• 투입된 에이전트 이름과 역할 ✓
• 각 에이전트의 전문 분야 ✓

---

2. 배치 규칙 (a10-project 기반)

2.1 배치 원칙

원칙 1: 명확한 목표 하나

❌ "요구사항 분석과 기술 조사를 해줘" → 2개 목표 (분산)
✅ "요구사항 분석을 해줘" → 1개 목표 (명확)

원칙 2: 작업 분할

복잡한 큰 작업을 에이전트 수만큼 분할
예: "전체 API 설계" → 에이전트 A: 사용자 API, 에이전트 B: 데이터 API

원칙 3: 병렬화

독립적인 작업은 동시에 투입
예: 리서치와 기획은 병렬 가능, 개발과 테스트는 순차

원칙 4: 투입 체크리스트

• CLAUDE.md Section 2 (팀 구성) 확인
• 각 에이전트의 전문 분야 확인
• decision_log.md 최신 항목 추출
• 산출물 저장 위치 사전 확인
• "계획 수립이나 확인 요청 없이 바로 실행하세요" 포함

2.2 배치 우선순위 결정

1. 현재 Phase 확인: CLAUDE.md Section 8 (로드맵)
2. 팀 가용성 확인: 각 에이전트의 현재 상태
3. 의존성 확인: decision_log.md에서 선행 결정사항
4. 우선순위: 우선순위 높은 태스크부터 배치

---

3. 표준 투입 프롬프트 템플릿

3.1 프롬프트 기본 구조

당신은 프로젝트의 {역할}({에이전트이름})입니다.
계획 수립이나 확인 요청 없이 바로 실행하세요.

## 프로젝트 배경

{프로젝트명}: {간단한 설명}
- 목표: {프로젝트 목표}
- 기술 스택: {기술 스택}
- 현재 Phase: {현재 Phase}
- 팀 구성: PL(준호), PM(민수님), {다른 에이전트들}

## 최신 의사결정 (반드시 반영하세요)

{decision_log.md에서 추출한 최신 5개 항목}

예시:
- D-03: 프론트엔드 프레임워크 → React 결정 (PL 판단, 2026-03-23)
- D-04: API 문서 형식 → OpenAPI 3.0 결정 (PL 판단, 2026-03-23)
- D-05: 데이터베이스 선택 → PostgreSQL (🔴 PM 확인 대기 중)

## 임무

{구체적이고 명확한 업무 설명}

### 타겟 사용자
{이 산출물의 사용자가 누구인지}

### 성공 기준
- 기준 1: {명확한 기준}
- 기준 2: {명확한 기준}
- 기준 3: {명확한 기준}

## 출력

**저장 위치**: {절대 경로}
**파일명**: {파일명}_{버전}.md
**형식**: Markdown

### 산출물 체크리스트
- [ ] {항목 1}이 포함되었는가?
- [ ] {항목 2}이 포함되었는가?
- [ ] {항목 3}이 포함되었는가?

## 참고

{관련 문서, 링크, 참고 자료}

3.2 역할별 투입 템플릿

리서처 투입 템플릿

당신은 프로젝트의 리서처(지은)입니다.
계획 수립이나 확인 요청 없이 바로 실행하세요.

## 프로젝트 배경
{기본 정보}

## 최신 의사결정
{의사결정 내용}

## 임무: {기술/시장/요구사항} 조사

### 조사 범위
- 범위 1
- 범위 2
- 범위 3

### 가설
- 가설 1
- 가설 2

### 결과물
- 기술 비교 표
- 장단점 분석
- 권장안

## 출력
저장: docs/01_참고자료/{조사주제}/조사_결과_{버전}.md

기획자 투입 템플릿

당신은 프로젝트의 기획자(한결)입니다.
계획 수립이나 확인 요청 없이 바로 실행하세요.

## 프로젝트 배경
{기본 정보}

## 최신 의사결정
{의사결정 내용}

## 임무: 요구사항 명세 작성

### 범위
- 범위 1
- 범위 2

### 제약 조건
- 제약 1
- 제약 2

## 결과물 구성
1. 개요 (목표, 스코프, 가정사항)
2. 기능 목록 (우선순위)
3. 사용자 흐름 (다이어그램)
4. 상세 요구사항 (기능별)
5. 비기능 요구사항 (성능, 보안 등)

## 출력
저장: docs/02_기획/요구사항_{버전}.md

개발자 (FE/BE) 투입 템플릿

당신은 프로젝트의 {FE/BE}개발자({이름})입니다.
계획 수립이나 확인 요청 없이 바로 실행하세요.

## 프로젝트 배경
{기본 정보}

## 최신 의사결정
{의사결정 내용, 특히 기술 스택과 아키텍처}

## 임무: {구체적 구현 업무}

### 구현 범위
- 모듈 1
- 모듈 2
- 모듈 3

### 기술 스택
{기술 선택 근거 포함}

### 코드 스타일
{프로젝트의 코드 스타일 지침}

## 출력
저장: docs/04_개발/src/{frontend|backend}/{모듈}/
파일: {모듈}_구현.md (또는 코드 파일)

검증자 투입 템플릿

당신은 프로젝트의 검증자(지호)입니다.
계획 수립이나 확인 요청 없이 바로 실행하세요.

## 프로젝트 배경
{기본 정보}

## 최신 의사결정
{의사결정 내용}

## 임무: 테스트 계획 및 케이스 작성

### 테스트 범위
- 범위 1
- 범위 2

### 테스트 유형
- 단위 테스트
- 통합 테스트
- 사용자 수용 테스트 (UAT)

### 테스트 환경
{환경 정보}

## 출력
저장: docs/05_검증/테스트계획/테스트_{버전}.md
산출물:
- 테스트 계획 (목표, 범위, 일정)
- 테스트 케이스 (각 기능별)
- 테스트 데이터 (샘플 데이터)

---

4. 역할별 산출 위치 규칙

역할	산출 폴더	파일명 패턴	예시
리서처	docs/01_참고자료/	조사_{주제}_{v}.md	조사_기술스택_v1.md
기획자	docs/02_기획/	요구사항_{v}.md	요구사항_v1.md
디자이너	docs/03_설계/UI_와이어프레임/	와이어프레임_{v}.md	와이어프레임_v1.md
아키텍트	docs/03_설계/시스템아키텍처/	아키텍처_{v}.md	아키텍처_v1.md
FE개발자	docs/04_개발/src/frontend/	{모듈}.tsx/jsx	Button.tsx
BE개발자	docs/04_개발/src/backend/	{모듈}.py/js	user_api.py
DevOps	docs/04_개발/	배포_{v}.md	배포_가이드_v1.md
검증자	docs/05_검증/	테스트_{v}.md	테스트계획_v1.md
데이터 분석가	docs/01_참고자료/	분석_{주제}_{v}.md	분석_성능_v1.md
테크라이터	docs/06_산출물/	문서_{주제}_{v}.md	문서_API_v1.md

---

5. 병렬 투입 예시

예시 1: 요구사항 분석 (2명 병렬)

동시 투입:
- 리서처: 기술 스택 조사
- 기획자: 사용자 흐름 및 요구사항 명세

독립적이므로 병렬 가능
각각 다른 산출물 (docs/01, docs/02)

예시 2: 시스템 설계 (2명 병렬)

동시 투입:
- 아키텍트: 시스템 아키텍처
- 디자이너: UI/UX 설계

독립적이므로 병렬 가능
각각 다른 산출물 (docs/03_설계)

예시 3: 개발 (2명 병렬)

동시 투입:
- FE개발자: 프론트엔드 구현
- BE개발자: 백엔드 API 구현

독립적이므로 병렬 가능
각각 다른 코드 폴더 (docs/04_개발/src/frontend, backend)

협력 포인트: API 계약 (decision_log.md D-XX 참고)

---

6. 순차 투입 예시

예시 1: 요구사항 → 설계 → 개발

Step 1: 기획자 투입 → 요구사항 명세 완료
Step 2: 아키텍트 투입 → 요구사항 기반 설계 진행
Step 3: 개발자 투입 → 설계 기반 구현 진행

동기화 포인트: decision_log.md

• 기획자 완료 후 D-XX (요구사항 확정)
• 아키텍트 완료 후 D-YY (기술 결정)
• 개발자 투입 시 위 결정사항 참고

예시 2: 개발 → 테스트 → 배포

Step 1: 개발자 투입 → 코드 구현 및 커밋
Step 2: 검증자 투입 → 테스트 및 버그 리포팅
Step 3: DevOps 투입 → 배포 준비 및 배포

동기화 포인트: 코드 커밋, 테스트 결과 문서

---

7. 에이전트 투입 체크리스트

투입 전 항상 확인:

[ ] CLAUDE.md Section 2 (팀 구성) 읽음
[ ] 해당 에이전트의 전문 분야 확인
[ ] decision_log.md에서 관련 최신 결정사항 5개 추출
[ ] 산출물 저장 위치 사전 준비
[ ] 프롬프트에 "계획 수립이나 확인 요청 없이 바로 실행하세요" 포함
[ ] 성공 기준이 명확한지 확인
[ ] 유사 산출물 있으면 버전 번호 매기기

---

8. 에이전트 결과 수집 및 보고

8.1 결과 수집

각 에이전트가 산출물 생성 후:

1. 산출물 확인: 지정된 위치에 저장되었는지 확인
2. 품질 검수: 성공 기준 충족 확인
3. 메타데이터: 파일명, 경로, 버전 확인
4. 의존성 확인: 다음 에이전트가 참고할 부분 체크

8.2 PL(준호) 통합

모든 에이전트의 결과를 수집 후:

1. 결과 통합: 산출물들 간 일관성 확인
2. 의사결정 필요 여부: 새로운 결정사항 필요하면 decision-tracker 호출
3. PM 보고 준비: 세션 종료 보고용 정보 정리

8.3 PM 보고 형식

PM, 에이전트 배치 결과를 정리했습니다.

## 완료된 산출물

**[리서처(지은)] 기술 조사**
- 파일: docs/01_참고자료/기술조사/조사_프레임워크_v1.md
- 주요 내용: React vs Vue 비교, 권장안 React
- 의사결정: D-03 (기술 선택)

**[기획자(한결)] 요구사항 명세**
- 파일: docs/02_기획/요구사항_v1.md
- 주요 내용: 30개 기능, 3개 Phase
- 의사결정: D-04 (스코프 확정)

## 새로운 의사결정 필요

🔴 API 인증 방식 (JWT vs OAuth)
- 배경: BE 구현 시작 전 결정 필요
- 선택지: A) JWT, B) OAuth2.0
- PL 의견: JWT (단순하고 빠름)

## 다음 단계
1. 위 의사결정 PM 확인
2. 아키텍트에게 API 설계 투입
3. 개발자에게 구현 투입

---

9. 트러블슈팅

상황 1: 에이전트가 계획 수립을 요청함

문제: 에이전트가 "계획을 먼저 수립해도 될까요?" 라고 요청

해결:
1. 프롬프트를 다시 읽고 "계획 수립이나 확인 요청 없이 바로 실행하세요" 강조
2. 명확한 성공 기준 추가
3. 필요하면 세부 지침 추가
4. 재투입: "다음과 같이 정정하여 바로 진행하세요"

상황 2: 에이전트의 산출물이 기대 이하

문제: 요구사항 명세가 너무 간단하거나 누락이 많음

해결:
1. 문제 부분 구체적으로 지적
2. 세부 지침 추가 (예: "각 기능마다 성공 조건 포함")
3. 참고 자료 제공 (유사 문서)
4. 재투입: "다음 부분을 추가/개선해주세요"

상황 3: 병렬 투입한 에이전트들의 산출물이 불일치

문제: 기획자와 아키텍트의 결과가 상충

해결:
1. 두 에이전트를 불러 협의 유도
2. decision-tracker로 최종 결정
3. 결정 결과를 decision_log.md에 기록
4. 양쪽 에이전트에 반영 요청

상황 4: 에이전트가 decision_log.md를 무시

문제: 이미 결정된 기술을 다시 제안함

해결:
1. 해당 D-번호를 명시적으로 지적
2. "이 결정은 이미 D-XX에서 확정되었습니다" 강조
3. decision_log.md 내용을 프롬프트에 다시 포함
4. 재투입

---

10. 에이전트 관리 팁

팁 1: 한 번에 하나의 명확한 목표

• "API 설계 및 구현" ❌
• "API 설계" ✅

팁 2: decision_log.md는 항상 최신

• 투입 전 2-3번 읽기
• 상충하는 결정이 없는지 확인

팁 3: 산출물 버전 관리

• v1, v1.1, v2 형식
• 이전 버전도 보관 (히스토리)

팁 4: 병렬 투입할 때 협력 포인트 명시

• "API 계약은 decision_log.md D-XX 참고"
• 두 에이전트가 같은 자료 참고하도록

팁 5: 에이전트 간 순서 의존성 명확히

• "기획자 완료 후에 투입하세요" (순차)
• "동시 진행 가능합니다" (병렬)

---

11. 배치 활동 기록

모든 에이전트 배치는 세션 로그에 기록:

### 에이전트 배치 기록

**시간**: 14:30
**배치 유형**: 병렬

| 에이전트 | 역할 | 임무 | 산출 위치 | 상태 |
|---------|------|------|---------|------|
| 지은 | 리서처 | 기술 스택 조사 | docs/01/.../조사_v1.md | ✅ 완료 |
| 한결 | 기획자 | 요구사항 명세 | docs/02_기획/요구사항_v1.md | ✅ 완료 |
| 수진 | 아키텍트 | API 설계 | docs/03_설계/API설계/api_v1.md | 🔄 진행 중 |

---

관련 스킬: session-protocol (세션 기록), decision-tracker (의사결정 추적)