멀티 에이전트 워크플로우는 어느 시점에 중간 관리자가 되는가?
At what point does a multi-agent workflow become middle management?
핵심 요약
멀티 에이전트 시스템에서 에이전트 수보다 중요한 것은 효율적인 작업 분해와 검증 방식임을 논의합니다.
- 작업 분해 — 에이전트 수 증가보다 독립적인 작업 단위로 나누는 것이 성능에 더 중요함
- 검증 비용 — 에이전트 결과물을 사람이 직접 확인해야 한다면 오히려 관리 비용이 증가함
- 아키텍처 설계 — 프롬프트 최적화보다 작업 격리 및 명시적 핸드오프 구조가 실패를 줄임
- 중간 관리자 함정 — 에이전트 간 조율에 시간을 쏟는 것은 소프트웨어로 기업 계층 구조를 만드는 것과 같음
나는 여러 코딩 에이전트를 병렬로 실행해왔는데, 최근 들어 이들이 내 일을 줄여주는 건지 아니면 그냥 내 직함만 바꾸고 있는 건지 의문이 든다.
연구 결과는 놀라울 정도로 엇갈린다.
CooperBench는 두 개의 코딩 에이전트가 같은 작업량을 처리할 때 한 개의 에이전트보다 성능이 약 50% 떨어진다는 것을 발견했다. 구글은 180개의 에이전트 구성을 테스트하여 병렬 작업에서는 큰 이득을 보았지만, 순차 작업에서는 39%에서 70%까지 성능이 저하되는 것을 확인했다.
반면, 중앙 코디네이터, 격리된 git 워크트리, 의존성 인식 작업, 엄격한 병합 검증을 사용하여 강력한 개선을 이뤄낸 연구도 있다.
즉, “더 많은 에이전트”가 분명한 장점은 아니다. 좋은 작업 분해가 핵심이다.
작업이 독립적이라면 병렬 에이전트가 실질적인 시간을 절약해 줄 수 있다. 하지만 그들이 컨텍스트를 공유하거나 같은 코드를 건드린다면, 결국 나는 스코프를 작성하고, 계획을 확인하고, 핸드오프를 검토하고, 충돌을 해결하고, 모두가 같은 문제를 해결했는지 검증하느라 시간을 다 쓰게 된다.
그 시점에서 나는 개발 팀을 사용하고 있는 것인가, 아니면 단순히 무작위로 할당된 직원들의 중간 관리자가 된 것인가?
두 가지 접근 방식을 모두 사용해 본 사람들에게 묻는다: 유능한 에이전트 한 명에게 전체 작업을 맡기는 것보다 실제로 더 빨라진 작업은 무엇인가?
