에이전트 카탈로그 (32개)
핵심 오케스트레이터
| 에이전트 | 역할 | 소환 조건 |
|---|
| planner | 작업 분해 + 계획 수립 | 모든 작업 시작 시 (항상) |
| manager-orchestrator | 중규모 프로젝트 조율 | specialist 2개 이하 |
| team-orchestrator | 대규모 프로젝트 병렬 조율 | specialist 3개+ 동시 필요 |
구현 전문가
| 에이전트 | 전문 영역 |
|---|
| frontend-specialist | React, TypeScript, Vite |
| backend-specialist | Spring Boot, NestJS, FastAPI |
| flutter-developer | Dart, Flutter, Riverpod |
| architect-designer | 프로젝트 구조 설계 |
| supabase-specialist | DB 설계, RLS, Edge Functions |
| devops-specialist | Docker, K8s, CI/CD |
품질 보증
| 에이전트 | 역할 |
|---|
| code-reviewer | 코드 품질, 중복, 보안 검증 |
| bug-fixer | 자동 에러 수정 (4단계 로테이션) |
| investigator | 동일 에러 2회 시 원인 분석 |
| security-specialist | 인증/결제/권한 변경 검증 |
| test-writer | 단위/통합/E2E 테스트 작성 |
| mobile-qa-tester | 모바일 앱 QA |
| pagespeed-analyzer | 웹 성능 분석 |
특수 목적
| 에이전트 | 역할 |
|---|
| user-proxy | 사용자 역할 대리 (QA, 의사결정) |
| harsh-critic | 사용자 관점 비판 에이전트 |
| hugh-clone | 사용자 기준 체화 Chief Agent |
| figma-designer | Figma → 코드 변환 |
| documentation-specialist | 문서 자동 생성 |
| telegram-notifier | 작업 완료 알림 |
자동 위임 전략
사용자가 개발 요청을 하면 규모를 자동 판단하고 적절한 오케스트레이터를 선택합니다:
flowchart TD
A["개발 요청"]
B{"작업 규모"}
C["직접 처리<br/>파일 1~2개, 단일 기술"]
D["manager-orchestrator<br/>파일 5~20개, 2~3 기술"]
E["team-orchestrator<br/>파일 20개 이상, 다중 기술"]
A --> B
B --> C
B --> D
B --> E
키워드 기반 specialist 자동 매칭:
- “React”, “컴포넌트”, “UI” → frontend-specialist
- “API”, “서버”, “엔드포인트” → backend-specialist
- “Flutter”, “모바일” → flutter-developer
- “테이블”, “RLS”, “Supabase” → supabase-specialist
에러 복구 4단계 로테이션
bug-fixer가 4회까지 다른 전략으로 재시도합니다:
flowchart LR
A["1차<br/>직접 수정"]
B["2차<br/>구조 변경"]
C["3차<br/>Codex rescue"]
D["4차<br/>리셋 후 재시도"]
E["실패<br/>사용자 에스컬레이션"]
A --> B --> C --> D --> E
에이전트 소환 순서
flowchart LR
A["planner"]
B["builder"]
C["investigator<br/>조건부"]
D["qa<br/>조건부"]
E["spec-reviewer"]
F["code-reviewer"]
G["security<br/>조건부"]
A --> B --> C --> D --> E --> F --> G
planner는 항상 먼저 (계획 없이 구현 금지)investigator는 동일 에러 2회 시에만security는 인증/결제/권한 변경 시에만