요즘 AI 코딩은 “모델 성능”보다 “운영 구조”에서 차이가 더 크게 난다.
단일 터미널에서 에이전트 한 명 돌리는 건 쉽다. 하지만 이슈가 10개, 브랜치가 10개, PR 리뷰가 10개가 되면 이야기가 달라진다.
ComposioHQ/agent-orchestrator는 바로 그 지점을 해결하려는 프로젝트다.
- 에이전트를 병렬로 띄우고
- 각자 독립된 worktree에서 작업하게 하고
- CI 실패/리뷰 코멘트 대응을 자동 라우팅한다.
즉, 도구라기보다 운영 계층(Orchestration Layer) 에 가깝다.
1) 문제 정의가 정확하다: “코딩”이 아니라 “조율”이 병목
README의 핵심 메시지는 단순하다.
- 에이전트 1개 실행은 쉽다.
- 에이전트 30개를 동시에 관리하는 건 조율 문제다.
사람이 직접 하려면 아래를 반복해야 한다.
- 브랜치 생성
- 세션 추적
- CI 로그 확인
- 리뷰 코멘트 전달
- 머지 타이밍 판단
Agent Orchestrator는 이 반복을 ao spawn 중심 흐름으로 자동화한다.
2) 기술적으로 중요한 포인트
A. Worktree 기반 격리
각 에이전트가 독립된 git worktree를 쓰기 때문에 충돌/오염 위험이 줄어든다.
B. 플러그인 슬롯 아키텍처
런타임, 에이전트, 워크스페이스, 트래커, 노티파이어 등을 슬롯으로 분리했다.
- Agent: claude-code / codex / aider / opencode
- Runtime: tmux / docker / process
- Tracker: github / linear
이 구조는 특정 벤더 종속을 줄이고, 팀 환경에 맞춘 확장을 쉽게 만든다.
C. 반응형 자동화(Reactions)
CI 실패/변경요청/승인 상태에 따라 자동 액션을 정의할 수 있다.
즉, 이벤트 기반으로 에이전트를 재투입하는 운영 모델이다.
3) v0.2.0에서 보인 성숙도
릴리즈 노트를 보면 단순 기능 추가가 아니라 운영 품질 개선이 눈에 띈다.
- 대시보드 실시간 SSE 업데이트
- 대시보드 로딩 성능 대폭 개선
- 웹 터미널 재연결 안정화
- 런타임 종속성이 낮은 활동 감지 방식 도입
이런 개선은 “데모”를 “운영 가능한 제품”으로 바꾸는 지점이다.
4) 이 프로젝트가 주는 실무적 의미
-
병렬 처리의 현실화
- 단순 병렬 실행이 아니라 상태 추적과 피드백 루프까지 포함
-
인간 개입의 위치 재정의
- 사람이 모든 작업을 수행하는 대신, 판단/승인/리뷰에 집중
-
에이전트 운영 표준화
- 팀 단위로 세션/브랜치/리액션 정책을 공통화 가능
-
멀티 에이전트 스택의 기반층
- 앞으로 에이전트 수가 늘수록 오케스트레이터의 가치는 더 커질 가능성
마치며
Agent Orchestrator는 “AI가 코드를 짜준다” 단계에서 한 발 더 나아간다.
핵심은 코딩 자체보다, 다수 에이전트를 운영 가능한 시스템으로 만드는 것이다.
결국 팀 생산성의 상한은 모델이 아니라 운영 구조가 결정한다.
그 관점에서 Composio의 이 프로젝트는 꽤 선명한 방향을 제시한다.