Team Control
경로: 좌측 사이드바 상단 ⋯ 메뉴 → Team Control
Team Control 은 여러 역할의 Worker 와 Supervisor 를 하나의 팀 으로 묶어, 주어진 목표(Goal)를 자동 계획·실행·검증 하는 멀티 에이전트 오케스트레이션 기능입니다. 단일 에이전트가 처리하기 복잡한 업무(코드 품질 개선, 장애 분석, 보고서 생성 등)를 여러 전문 Worker 가 분담해 수행합니다.
탭 구성
| 탭 | 용도 |
|---|
| Setup | 신규 팀 구성 — Goal·Acceptance Criteria·Autonomy·Supervisor/Worker 정의 |
| Active | 현재 실행 중 팀의 실시간 대시보드 — 진행 태스크·이벤트 스트림·승인 요청 |
| History | 과거 실행 이력 — 완료/실패/취소 팀의 결과·평가 |
핵심 개념
| 개념 | 설명 |
|---|
| Goal | 팀이 달성해야 할 목표 (자연어) |
| Acceptance Criteria | Supervisor 가 목표 달성 여부를 측정 하는 조건 |
| Supervisor | 계획 수립·태스크 분배·검증 담당 LLM |
| Worker | 실제 도구 호출·파일 작성·테스트 실행 등 작업 수행. 역할(role)·할당 LLM·허용 도구 지정 |
| Verification Tools | Supervisor 가 결과를 직접 검증할 때 호출하는 도구 (lint·test 실행 등) |
| Autonomy Level | 팀 자율성 — Notify / Approve / Autonomous 3 단계 |
| Cycle | 계획 → 실행 → 평가 1 회 반복 |
Verification Tools 가 중요한 이유: Supervisor 가 Worker 의 보고만 믿으면 false positive 가 생깁니다 (“완료했다고 주장하지만 실제로는 실패”). Verification Tools 를 통해 Supervisor 가 직접 lint/test 결과를 확인하도록 설계되어 있습니다.
Setup 탭 — 팀 구성
1. 기본 정보
| 필드 | 설명 | 예시 |
|---|
Team Name* | 팀 식별자 | Optimize API Performance |
| Goal | 무엇을 달성할지 (자연어) | API 응답 시간을 평균 300 ms 이하로 개선 |
| Acceptance Criteria | Supervisor 가 평가할 측정 조건 | p95 latency < 300ms, 모든 테스트 통과, 커버리지 80%+ |
**Acceptance Criteria 는 측정 가능(measurable)**해야 합니다. “좋게 만들기” 같은 모호한 기준은 Supervisor 가 판단할 수 없어 팀이 무한 반복할 수 있습니다.
2. Autonomy Level
| 값 | 동작 | 적합 상황 |
|---|
| Notify | Worker 가 자율 실행, 주요 단계마다 사용자에게 알림만 | 검증된 반복 작업 |
| Approve (기본) | 계획·평가 단계에서 사용자 승인 필요 후 진행 | 운영 중 변경·민감 작업 |
| Autonomous | 완전 자율 — 목표 달성까지 사용자 개입 없음 | 샌드박스·테스트 환경 |
3. Team Configuration
프리셋 활용
시작 시 제공되는 프리셋:
| 프리셋 | 용도 | Verification Tools |
|---|
| Code Quality | 코드 린팅·테스트·커버리지 | run_linter · run_tests · run_coverage |
| DevOps | K8s 모니터링·배포·DB 관리 | inspect_system |
| Custom | 완전 자유 구성 | — |
Supervisor
| 필드 | 설명 |
|---|
| LLM | Supervisor 가 사용할 모델 (예: anthropic/claude-opus-4.5). 판단·계획 품질 중요 — 고성능 모델 권장 |
| Persona*(선택)* | Supervisor 시스템 프롬프트 보완 |
| Verification Tools | Supervisor 가 직접 호출하는 검증 도구 |
Workers
Add Worker 로 여러 Worker 추가. 각 Worker:
| 필드 | 설명 | 예시 |
|---|
| worker_id | 내부 식별자 | worker-code · worker-test |
| role | Worker 역할 설명 — Supervisor 가 태스크 분배에 사용 | Code Engineer — fix code and lint issues |
| LLM | Worker 전용 LLM | anthropic/claude-opus-4.5 (비용 민감하면 gpt-oss-120b) |
| Allowed Tools | 이 Worker 가 호출 가능한 도구 (카테고리별 체크) | 6 / 47 selected |
| max_iterations | 단일 태스크 내 LLM 호출 반복 한도 | 25 (기본) |
| 카테고리 | 개수 | 예시 도구 |
|---|
| analytics | 11 | 데이터 분석·집계 |
| docx | 8 | Word 문서 생성·읽기 |
| pptx | 8 | PowerPoint 생성 |
| image-gen | 3 | 이미지 생성 |
| memory | 2 | 세션 메모리 |
| subagent | 1 | 서브 에이전트 호출 |
| temp-files | 12 | 임시 파일 조작 |
| web-search | 2 | 웹 검색 |
Worker 별 도구 제한 은 보안·비용 모두에 중요합니다. 예: 코드 수정 Worker 에는 write_file·patch_file 만, 테스트 Worker 에는 run_tests 만 허용해 역할 분리 를 강제하세요.
4. Advanced Settings
| 필드 | 기본 | 설명 |
|---|
| max_plan_tasks | | 한 계획 라운드에 생성 가능한 최대 태스크 수 |
| stuck_threshold_cycles | | 진행 정체로 판단할 Cycle 수 |
| check_interval | | Supervisor 의 태스크 상태 폴링 간격 (초) |
| worker_context_limit | | Worker 컨텍스트 토큰 상한 |
| approval_timeout | | 승인 대기 타임아웃 (초) |
| max_eval_rounds | | Goal 미달 시 최대 평가 재시도 횟수 |
| max_cycles | | 팀 전체 최대 Cycle 수 — 무한 루프 방지 |
5. Save Draft / Start Team
- Save Draft — 팀 구성을 저장만 (실행 X)
- Start Team — 저장 + 즉시 실행 → Active 탭 자동 이동
Active 탭 — 실행 중 대시보드
팀이 RUNNING / PAUSED 상태이면 자동으로 이 탭이 열리며, 5 초 간격으로 폴링 됩니다.
| 영역 | 내용 |
|---|
| 실시간 이벤트 스트림 | Supervisor·Worker 의 로그·Tool 호출·평가 결과 |
| 현재 태스크 목록 | PROPOSED / PENDING / IN_PROGRESS / DONE / STUCK / CANCELLED |
| Cycle / Eval Round | 진행 상황 카운터 |
| 승인 요청 카드 | Approve 모드일 때 계획·평가 시점마다 나타남. Approve / Reject / Edit |
| Pause / Cancel 버튼 | 일시정지·중단 |
Task 상태
| 상태 | 의미 |
|---|
| PROPOSED | Supervisor 가 계획했지만 승인 대기 |
| PENDING | 승인 완료, 할당된 Worker 대기 |
| IN_PROGRESS | 실행 중 |
| DONE | 완료 — Supervisor 가 검증 가능 |
| STUCK | Worker 가 스스로 해결 못함 — Supervisor 개입 필요 |
| CANCELLED | 취소 |
History 탭 — 이력
완료·실패·취소된 팀의 이력. 각 항목 클릭 시 당시의 태스크·평가·결과 미리보기 확인.
사용 시나리오
| 시나리오 | 구성 |
|---|
| 코드 품질 개선 | Code Quality 프리셋 — Code Engineer + Test Engineer |
| DevOps 자동화 | DevOps 프리셋 — Infra + DB Admin |
| 시장 조사 → 보고서 | Custom — Researcher(web-search) + Writer(docx) + Editor |
| 고객 이슈 트리아지 | Custom — Collector(Slack 검색) + Analyzer(LLM) + Filer(Jira 생성) |
| 장애 1 차 분석 | Custom — Logs 수집 + SQL 분석 + 요약 |
운영 주의
- Autonomous 모드 는 사용자 개입 없이 실행됩니다. 쓰기 권한·외부 호출 도구 를 가진 Worker 를 Autonomous 로 돌리면 의도치 않은 변경·비용 폭증 위험. 초기에는 Approve 로 관찰 후 점진적 자율화.
- max_cycles 필수 — 모호한 Goal + 무한 Cycle 조합은 비용을 폭증시킵니다. 한도·요금은 Billing 참고.
- Worker 별 도구 제한 으로 역할 분리 — 예: 테스트 Worker 에
write_file 주지 않기.
- 공유 자원 조작 (DB, 운영 코드 리포 등) 하는 팀은 실행 환경 격리 (브랜치·스테이징 DB) 필수.
- Stuck 반복 — Worker 가 막히면 Supervisor 가 재계획하는데, 같은 실패가 반복되면
stuck_threshold_cycles 에 따라 팀이 실패 종료됩니다.
- Acceptance Criteria 가 모호하면 Supervisor 가 무한히 “부족한 것 같다” 로 재시도하니 측정 가능한 조건만 작성.
- Verification Tools 없음 → Supervisor 가 Worker 보고만 믿게 됨. 가능한 한 직접 검증 도구 지정.
관련 문서
