Orchestrator 진화 히스토리

2025.10 ~ 2026.03 | Manager-Orchestrator에서 Team-Orchestrator까지

5
개월
40
커밋
5
Era
508
최종 코드 줄

진화 한눈에 보기

v1
탄생
2025.10
v1.3
에이전트 팽창
6→35개
2025.12
v2
기반 재설계
외부 의존 제거
2026.02
v3
Team 분기
5-Phase
2026.02
v4
대청소
37→12개
2026.03
v5
QA 혁명
계약 기반
2026.03
1
탄생기
2025.10 ~ 12
28c4e5dc 2025.10.22 탄생
초기 커밋: Claude Code user scope 설정 추가
  • 159줄의 최초 manager-orchestrator.md
  • Manager 모델: sonnet (현재 opus)
  • 외부 의존: Context7(MCP) + TaskManager(MCP)
  • 에이전트 6종: architect, bug-fixer, reviewer, test-writer, performance, specialist
  • Phase 구분 없음 — 단순 순차 실행
b0db3d30 2025.12.07
문서화 정책 강화 — Specialist에게 경로 명시 필수
6ec297d8 2025.12.15 정점 35개
에이전트 35개 — 역대 최대
security, performance, devops, documentation, ui-ux-designer, product-specifier 등 무분별하게 추가
62cbed83 2025.12.16 첫 정리
에이전트 35→21개 — 첫 번째 대량 정리 (-14개)
2
기반 재설계
2026.01 ~ 02.12
552a2674 2026.01.30 사고
동기화 중 manager-orchestrator 실수로 삭제
2/10 (ec829df7)에 복원. 이 사건이 "파일 시스템 = Single Source of Truth" 원칙 확립의 계기.
8f0aa592 2026.02.11 패러다임 전환
워크플로우 재설계: Context7/TaskManager → claude-mem/내장 Tasks
외부 MCP 서버 의존 완전 제거. 파일 시스템을 유일한 진실의 원천으로 확립.
3997522e 2026.02.11 단순화
모델 전략: opus/sonnet/haiku 3단 → opus/sonnet 2단
29f692b0 2026.02.11 핵심 원칙
컨텍스트 전달 전략 — Specialist 간 정보 단절 해결
파일 시스템 = Single Source of Truth
Context7 경유 대신 파일에서 직접 읽어서 전달 (cat migrations/*.sql → 정확한 스키마)
247949a1 2026.02.11
Phase 1~4 대규모 개선 완료
6312307d 2026.02.11 QA 루프
QA 피드백 루프 완성 — Finding→Specialist 매핑 + 자동 수정
307e983c 2026.02.12
보안 QA + changelog + 병렬 디스패치 규칙 통합
같은 날 GitHub README 공개 — jung-wan-kim/manager-orchestrator (700줄 구조도)
3
team-orchestrator 탄생
2026.02.18 ~ 02.24
71e9d8e2 2026.02.18
브라우저 테스트 도구: superpowers-chrome → agent-browser 교체
5d86a6cd 2026.02.24 신규 에이전트
team-orchestrator 에이전트 구현
  • Team API 기반 (spawn/shutdown/SendMessage)
  • 8-Phase → 5-Phase 간소화
  • 최대 5명 제한 (team-lead + 4)
  • Skill() 호출 금지 (2,000t 절약)
  • manager(소규모) + team(대규모) 2트랙 체제 시작
4
대청소 + 통합
2026.03.04 ~ 03.06
51d3dd0b 2026.03.04 대청소
Agent-Orchestrator 대청소
  • 에이전트 37→12개 (-68%)
  • 훅 15→7개 (-53%)
  • settings.json 754→143줄 (-81%)
de5dcd84 2026.03.06 병렬
team-orchestrator에 병렬 실행 패턴 추가
frontend + backend 동시 spawn, run_in_background, worktree 격리
715bf4e2 2026.03.06 격리
멀티 프로젝트 격리 — team_name으로 프로젝트 분리
5
QA 혁명
2026.03.10 ~ 03.12
1464d935 2026.03.10 강제
QA 브라우저 테스트 강제
.qa-evidence.json에 browser_test.executed: true 필수. 빌드만 통과로 PASS 처리는 "거짓 보고"로 간주.
9fe13788 2026.03.11 패러다임 전환
Phase 2.5 도입 — 구현 전 QA 시나리오 확정
가장 중요한 변화.
  • docs/qa-test-plan.md 미생성 시 Phase 3 진입 금지
  • 시나리오는 요구사항에서 파생 (코드 기반 생성 금지)
  • 시나리오 = 코드가 통과해야 할 "계약"
466f7d82 2026.03.11 수정 루프
QA 실패 리포트 기반 수정 루프 추가 (Phase 3/4)
실패 → 리포트 추출 → specialist에게 전달 (시나리오 ID + 실패 횟수 + 예상/실제 결과) → 수정 → 재QA
71fceacc 2026.03.11 세밀화
에스컬레이션 기준: 전체 3회 → 동일 시나리오 3회
하나의 어려운 버그 때문에 전체 프로젝트가 멈추는 문제 해결. 해당 시나리오만 에스컬레이션, 나머지는 수정 루프 계속.
e88d9808 2026.03.12 연동
qa-orchestrator 독립 QA 파이프라인 연동
Phase 5 완료 후 "qa-orchestrator 추가 실행?" 질문 필수 추가. Y 시 독립 검증 실행.

아키텍처 비교: v1 vs v5

v1 (2025.10)

Manager (sonnet)
↓ task()
Specialist × 6~35
↓ Write/Edit
Hook × 4~15
Context7 + TaskManager (외부 MCP)

v5 (2026.03)

Team-Lead (opus)
↓ Team API (spawn/msg/shutdown)
Specialist × 4 (최대)
Phase 2.5: QA 시나리오 계약
micro-QA → full-QA (.qa-evidence.json)
파일 시스템 + 내장 Tasks (외부 의존 없음)

에이전트 수 변화

v1 (10/22)
6
6
v1.1 (12/11)
31
31
v1.3 (12/15)
35 (정점)
35
정리 (12/16)
21
21
v2 (02/11)
12
12
대청소 (03/04)
12
12
v5 현재
12 (안정)
12

v1 → v5 핵심 지표 비교

구조

Phase 수8개5개 (+2.5)
에이전트 수6~35개12개 (5명 상한)
훅 수4~15개1개
코드 줄 수159줄508줄

기술

Manager 모델sonnetopus
외부 의존Context7+TaskManager없음
병렬 방식Promise.allTeam API
테스트 도구혼재agent-browser

QA

QA 방식후행적선행적 (계약)
QA 증거없음.qa-evidence.json
에스컬레이션전체 3회시나리오별 3회
브라우저 테스트선택필수

5개월간의 교훈

📉
팽창 → 정리
에이전트 35개까지 늘렸다가 12개로. 적은 수가 더 많은 책임을 가지는 것이 효율적.
📁
파일 = 진실
외부 MCP 의존 제거. 파일 시스템이 가장 안정적이고 디버깅 가능한 데이터 저장소.
📋
계약 먼저
"만들고 테스트"에서 "계약 확정 → 계약 이행"으로. QA 시나리오가 코드보다 먼저.
🎯
세밀한 에스컬레이션
전체 중단 대신 시나리오별 추적. 고칠 수 있는 건 계속 고치고, 정말 못 고치는 건만 사람에게.