Keystone Agent 위임 구조 비교 분석
Overview Archive
04 에이전트 Markdown

Agent 위임 구조 비교 분석

Agent Team vs Task(순차/병렬) vs TaskList — 3가지 위임 구조의 비용·통신·격리 트레이드오프 비교

Source
src/content/docs/agent-delegation-comparison.md
Order
57

한눈에 보기

오케스트레이터가 하위 에이전트에게 작업을 위임하는 3가지 구조를 토큰 비용, 통신, 컨텍스트 격리 관점에서 비교한 분석입니다.

1. 개요

Manager-Orchestrator가 하위 에이전트들에게 작업을 위임하는 3가지 구조를 분석합니다.

구조핵심 도구패턴
A. Task 순차/병렬Task()Manager가 직접 호출, 결과 대기
B. Agent TeamTeamCreate + SendMessage팀 구성 후 메시지 기반 조율
C. TaskList 독립TaskCreate + TaskUpdate작업 목록만 관리, 에이전트 없음

2. 구조별 상세 분석

A. Task 순차/병렬 호출 (현재 Manager-Orchestrator 방식)

Manager-Orchestrator
  ├── task(architect-designer)     ← 순차
  ├── task(supabase-specialist)    ← 순차
  ├── task(frontend-specialist) ─┐
  │                               ├─ 병렬 실행
  ├── task(backend-specialist)  ─┘
  ├── task(test-writer)            ← 순차
  └── task(code-reviewer)          ← 순차

실행 흐름:

  1. Manager가 task() 도구로 에이전트 직접 호출
  2. 독립적인 작업은 동시에 여러 task() 호출 (병렬)
  3. 의존성 있는 작업은 순차 실행
  4. 각 에이전트는 독립 컨텍스트에서 실행, Manager에게 결과 반환

장점:

  • ✅ 구현이 단순하고 직관적
  • ✅ Manager가 전체 흐름을 완전 제어
  • ✅ 에이전트 간 파일 충돌 위험 최소
  • ✅ 디버깅이 쉬움 (호출 순서가 명확)
  • ✅ 비용 예측 가능 (에이전트 수 × 작업 크기)

단점:

  • ❌ 에이전트 간 직접 통신 불가
  • ❌ Manager 컨텍스트에 결과가 누적됨 (컨텍스트 비대화)
  • ❌ 동적 작업 추가가 어려움
  • ❌ Manager가 병목 (모든 결과를 Manager가 해석)

B. Agent Team (TeamCreate + SendMessage)

TeamCreate("project-team")
  │
  ├── Teammate: architect (general-purpose)
  ├── Teammate: frontend-dev (general-purpose)
  ├── Teammate: backend-dev (general-purpose)
  ├── Teammate: tester (general-purpose)
  └── Leader: manager-orchestrator
       │
       ├── SendMessage → architect: "프로젝트 구조 설계해줘"
       ├── SendMessage → frontend-dev: "UI 구현해줘"
       ├── SendMessage → backend-dev: "API 구현해줘"
       └── SendMessage → tester: "테스트 작성해줘"

실행 흐름:

  1. TeamCreate로 팀 생성 (config.json 생성)
  2. Task() with team_name으로 팀원 스폰
  3. 공유 TaskList로 작업 할당/자가 클레임
  4. SendMessage로 peer-to-peer 통신
  5. 팀원은 idle 상태에서 메시지 대기
  6. shutdown_request로 종료

장점:

  • ✅ 에이전트 간 직접 통신 (peer-to-peer)
  • ✅ 동적 작업 할당 (자가 클레임)
  • ✅ 진정한 병렬 실행 (각 에이전트가 독립 프로세스)
  • ✅ 컨텍스트 분산 (Manager에 결과 누적 안됨)
  • ✅ 장기 실행 프로젝트에 적합 (에이전트 상태 유지)

단점:

  • ❌ 비용 폭발 (idle 에이전트도 컨텍스트 유지)
  • ❌ 복잡한 설정 (TeamCreate, config, members)
  • ❌ 파일 충돌 위험 (동시에 같은 파일 수정 가능)
  • ❌ 디버깅 어려움 (비동기 메시지 순서 추적)
  • ❌ 에이전트 간 컨텍스트 공유 제한적
  • ❌ 오케스트레이션 오버헤드 (idle 관리, 메시지 라우팅)

C. TaskList 독립 (TaskCreate + TaskUpdate)

TaskCreate("프로젝트 구조 설계")
TaskCreate("Supabase 스키마 생성")
TaskCreate("Frontend UI 구현")
TaskCreate("Backend API 구현")
TaskCreate("테스트 작성")
  │
  └── 사용자 또는 단일 에이전트가 순차적으로 처리

실행 흐름:

  1. TaskCreate로 작업 목록 생성
  2. TaskUpdate로 의존성(blockedBy) 설정
  3. 단일 에이전트(또는 사용자)가 순차 처리
  4. 하위 에이전트 스폰 없음

장점:

  • ✅ 가장 단순한 구조
  • ✅ 최소 비용 (에이전트 1개만 사용)
  • ✅ 파일 충돌 없음 (순차 실행)
  • ✅ 사용자가 진행 상황 직접 확인 가능
  • ✅ 작은 프로젝트에 최적

단점:

  • ❌ 병렬 실행 불가
  • ❌ 전문성 분리 불가 (하나의 에이전트가 모든 작업)
  • ❌ 컨텍스트 윈도우 한계 (모든 작업이 하나의 컨텍스트)
  • ❌ 대규모 프로젝트에 부적합

3. 비교 매트릭스

항목A. Task 순차/병렬B. Agent TeamC. TaskList 독립
병렬 실행⭐⭐⭐ 부분적⭐⭐⭐⭐⭐ 완전⭐ 불가
에이전트 간 통신⭐ 불가⭐⭐⭐⭐⭐ P2P⭐ 불가
컨텍스트 격리⭐⭐⭐⭐ 좋음⭐⭐⭐⭐⭐ 완전⭐ 공유
비용 효율⭐⭐⭐⭐⭐⭐ 높음⭐⭐⭐⭐⭐
설정 복잡도⭐⭐⭐ 중간⭐ 복잡⭐⭐⭐⭐⭐ 단순
디버깅 용이성⭐⭐⭐⭐⭐⭐ 어려움⭐⭐⭐⭐⭐
파일 충돌 위험⭐⭐⭐⭐ 낮음⭐⭐ 높음⭐⭐⭐⭐⭐ 없음
동적 작업 할당⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
확장성⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
장기 프로젝트⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

4. 실행 흐름 비교: Todo 앱 구현 예시

A. Task 방식 (현재)

시간  Manager          architect    frontend   backend    tester
─────────────────────────────────────────────────────────────────
t0    분석/계획          -            -          -          -
t1    task(architect)→  [구조설계]    -          -          -
t2    결과확인           완료          -          -          -
t3    task(frontend)→   -           [UI구현]    -          -
      task(backend)→    -            -         [API구현]   -
t4    결과확인           -            완료       완료        -
t5    task(tester)→     -            -          -         [테스트]
t6    결과확인           -            -          -          완료
t7    커밋/알림

총 에이전트 활성 시간: Manager(전체) + 각 specialist(해당 작업만)

B. Agent Team 방식

시간  Leader           architect    frontend   backend    tester
─────────────────────────────────────────────────────────────────
t0    팀생성/계획        대기(idle)   대기(idle)  대기(idle)  대기(idle)
t1    msg→architect    [구조설계]    대기         대기        대기
t2    msg→front,back   완료→idle   [UI구현]    [API구현]   대기
t3    대기              idle        구현중      구현중      대기
t4    msg→tester       idle        완료→idle   완료→idle  [테스트]
t5    shutdown_all     종료         종료        종료       완료→종료
t6    커밋/알림

총 에이전트 활성 시간: 전원이 t0~t6 동안 컨텍스트 유지 (idle 포함)

C. TaskList 방식

시간  단일 에이전트
─────────────────
t0    계획 + 구조설계
t1    스키마 생성
t2    Frontend UI
t3    Backend API
t4    테스트
t5    커밋/알림

총 에이전트 활성 시간: 1개 에이전트 × 전체 시간

5. 비용 시뮬레이션 (Todo 앱 기준)

구조에이전트 수추정 토큰상대 비용
A. Task1 + 5(순차 스폰)~150K1x
B. Agent Team5(상시)~400K2.7x
C. TaskList1~200K1.3x

비용 차이의 핵심: Agent Team은 idle 에이전트도 컨텍스트를 유지하므로 메시지당 비용 발생

6. Agent Team만의 고유 기능

Agent Team으로만 가능한 것:

  1. Peer-to-peer 통신: frontend ↔ backend 직접 메시지
  2. 자가 클레임: 에이전트가 TaskList에서 자발적으로 작업 선택
  3. 영속 상태: 에이전트가 이전 작업 결과를 기억하고 다음 작업에 활용
  4. 동적 역할 변경: 진행 중 에이전트 역할 재배치
  5. 팀 규모 조정: 필요에 따라 에이전트 추가/제거

7. Agent Team 사용 시 주의사항

  1. 비용 폭발: idle 에이전트 관리 필수 (불필요하면 즉시 shutdown)
  2. 파일 충돌: 작업 영역을 명확히 분리 (디렉토리 경계 설정)
  3. 디버깅: 메시지 로그 활성화, 단계별 검증 포인트 설정
  4. 설정 복잡도: config.json, members 관리, 메시지 라우팅
  5. 컨텍스트 제한: 각 에이전트가 전체 프로젝트 상태를 모르므로 충분한 컨텍스트 전달 필요

8. 권장 전략: 하이브리드 접근

프로젝트 규모별 선택

소규모 (단일 기능, 파일 1~3개)
  → C. TaskList 독립
  → 단일 에이전트로 충분

중규모 (기능 2~5개, 파일 5~20개)
  → A. Task 순차/병렬 (현재 방식)
  → Manager가 specialist 호출

대규모 (기능 10+, 파일 20+, 멀티 도메인)
  → B. Agent Team
  → 장기 프로젝트, 팀 간 통신 필요

결정 플로우차트

작업이 1개인가?
  └── YES → C. TaskList
  └── NO ↓

에이전트 간 통신이 필요한가?
  └── NO → A. Task 순차/병렬 ← 대부분의 경우
  └── YES ↓

장기 프로젝트인가? (2시간+)
  └── NO → A. Task 순차/병렬 (충분)
  └── YES → B. Agent Team

9. 결론

구조최적 사용처핵심 키워드
A. Task일반적인 프로젝트단순, 제어, 예측 가능
B. Agent Team대규모/장기 프로젝트협업, 자율, 확장
C. TaskList단순 작업최소비용, 순차, 추적

현재 Manager-Orchestrator의 A 구조는 대부분의 프로젝트에 적합합니다. Agent Team(B)은 대규모 프로젝트에서 진정한 병렬 협업이 필요할 때만 사용하는 것이 비용 대비 효율적입니다.

Source Notes

이 문서는 초기 에이전트 위임 구조 실험(2026-02, Hue reference upstream 시기의 설정 동기화 프로젝트)에서 작성된 분석을 공개용으로 정리한 것입니다. Provenance: keystone-native.