코디네이터 모드

코디네이터 모드 개요

단순한 서브에이전트 스폰을 넘어, 코디네이터 모드 는 여러 전문 에이전트가 협력하여 복잡한 목표를 달성하는 고수준 오케스트레이션 패턴입니다.

코디네이터는 작업을 전문가들에게 분배하고, 결과를 수집하며, 충돌을 해결하고, 최종 산출물을 통합합니다.

[사용자 요청]
      ↓
[코디네이터 에이전트]
  ├── 작업 분석 및 계획
  ├── 전문 에이전트에 작업 위임
  ├── 진행 상황 모니터링
  ├── 결과 수집 및 충돌 해결
  └── 최종 통합 및 보고
      ↓
[최종 결과]

팀 오케스트레이션

팀(Teams) 패턴에서는 코디네이터가 명시적으로 역할이 정의된 전문 에이전트 들을 조율합니다.

팀 구성 예시: 기능 개발 팀

// 코디네이터가 세 전문 에이전트를 순서대로 조율
const team = {
  coordinator: "전체 기능 구현 계획 수립 및 조율",
  members: [
    {
      role: "architect",
      prompt: `다음 기능의 아키텍처를 설계하세요:
        - 사용자 프로필 편집 API
        - 필요한 엔드포인트, 데이터 모델, 유효성 검사 규칙 정의
        - OpenAPI 스펙 형식으로 출력`
    },
    {
      role: "executor",
      prompt: `architect가 설계한 스펙을 구현하세요:
        {architect_output}
        - TypeScript + Express 사용
        - 단위 테스트 포함`
    },
    {
      role: "reviewer",
      prompt: `executor가 구현한 코드를 검토하세요:
        {executor_output}
        - 보안 취약점 확인
        - 성능 이슈 확인
        - 코딩 스타일 확인`
    }
  ]
}

팀 실행 흐름

코디네이터
    ↓ architect에게 설계 위임
architect → 아키텍처 문서 반환
    ↓ 설계 결과를 executor에게 전달
executor → 구현 코드 반환
    ↓ 구현 결과를 reviewer에게 전달
reviewer → 검토 보고서 반환
    ↓ 모든 결과 통합
코디네이터 → 사용자에게 최종 보고

스웜 패턴

스웜(Swarm) 패턴에서는 에이전트들이 중앙 코디네이터 없이 자율적으로 협업 합니다. 각 에이전트가 공유 상태(파일, 데이터베이스)를 통해 간접적으로 통신합니다.

에이전트 A          에이전트 B          에이전트 C
    |                   |                   |
    ↓                   ↓                   ↓
[공유 작업 큐 / 파일 시스템 / 상태 파일]
    ↑                   ↑                   ↑
    |                   |                   |
  결과 기록           결과 기록           결과 기록

스웜 vs 팀 비교

항목	팀 오케스트레이션	스웜 패턴
조율 방식	중앙 코디네이터	분산 자율
적합한 작업	순서가 중요한 작업	병렬 독립 작업
복잡도	상대적으로 단순	설계 복잡
장애 대응	코디네이터 단일 장애점	분산으로 내결함성 높음
예시	기능 개발 파이프라인	대규모 코드베이스 분석

워크트리 기반 격리와 병합

팀 작업에서 여러 에이전트가 같은 파일을 수정하면 충돌이 발생합니다. 워크트리 격리 로 이를 방지합니다.

// 각 에이전트가 독립 워크트리에서 작업
Task({
  description: "기능 A 구현",
  prompt: "...",
  isolation: "worktree"  // 독립 Git worktree 생성
})

Task({
  description: "기능 B 구현",
  prompt: "...",
  isolation: "worktree"  // 별도 독립 Git worktree 생성
})

워크트리 라이프사이클

WorktreeCreate 이벤트
    ↓
기본 브랜치에서 새 worktree 생성
    ↓
에이전트가 독립적으로 작업
(변경사항이 메인 저장소와 격리됨)
    ↓
작업 완료 → 코디네이터가 검토
    ↓
병합 전략 결정:
  ├── 자동 병합 (충돌 없음)
  ├── 수동 검토 후 병합
  └── 거부 (작업 폐기)
    ↓
WorktreeRemove 이벤트 (worktree 정리)

병합 전략

전략	사용 시점	방법
자동 병합	파일 겹침 없음	git merge --no-ff
순차 적용	동일 파일 수정	하나씩 검토 후 cherry-pick
수동 해결	충돌 발생	코디네이터가 직접 해결

실제 팀 구성 예시

사용자: "전체 API를 OpenAPI 3.0으로 문서화하고 SDK를 생성해줘"

코디네이터 계획:
  1. explorer 에이전트 → 모든 API 엔드포인트 탐색
  2. documenter 에이전트 (병렬 × 5) → 각 모듈별 OpenAPI 스펙 작성
  3. merger 에이전트 → 스펙 통합 및 충돌 해결
  4. sdk-generator 에이전트 → TypeScript SDK 생성
  5. validator 에이전트 → SDK와 API 일치성 검증

코디네이터 모드는 수백 개의 파일에 걸친 대규모 작업을 체계적으로 처리하는 데 특히 강력합니다.