서브 에이전트는 필요 없습니다
대부분의 사람들은 에이전트 아키텍처를 조직도처럼 그립니다.
맨 위에 오케스트레이터(Orchestrator)를 둡니다. 그리고 리서처(Researcher), 코더(Coder), 테스터(Tester)로 선을 긋습니다. 깔끔하고 전문적으로 보입니다.
하지만 이는 실수입니다.
1975년, 프레드 브룩스(Fred Brooks)는 지연된 소프트웨어 프로젝트에 인력을 더 투입하면 프로젝트가 더 지연된다고 썼습니다. 이는 업무가 진행되는 속도보다 커뮤니케이션 비용이 더 빠르게 증가하기 때문입니다.
에이전트 군집(swarm of agents)을 구축할 때, 여러분은 이 실수를 반복하게 됩니다.
오케스트레이터는 하위 작업(subtasks)을 관리하는 데 모든 시간을 허비합니다. 이는 엄청난 오버헤드를 발생시킵니다. 여러분은 아키텍처를 구축하는 것이 아니라, 배관(plumbing)을 만들고 있는 것입니다.
서브 에이전트가 실패하는 이유는 다음과 같습니다:
- 컨텍스트 손실(Context loss): 서브 에이전트는 자신만의 창에서 실행됩니다. 자신의 전체 추론 과정을 부모 에이전트에게 전달할 수 없으며, 요약본만 보낼 수 있습니다.
- 비용이 많이 드는 우회 방법: 부모 에이전트가 발생한 일을 읽을 수 있도록 에이전트에게 파일이나 git에 기록하도록 강제합니다. 이는 공유 메모리를 재발명하는 격이지만, 속도는 더 느려집니다.
- 토큰 낭비: 모든 경계를 넘나들며 컨텍스트를 전달하는 데 비용을 지불해야 합니다. N개의 에이전트로 구성된 군집은 N+1만큼의 토큰 비용이 발생합니다.
- 충돌하는 결정: 병렬로 작동하는 에이전트들은 서로 다른 가정을 합니다. 두 에이전트가 동일한 것을 만들더라도, 종종 서로 다른 스타일이나 로직을 사용하게 됩니다.
연구에 따르면 멀티 에이전트 프레임워크의 실패율은 41%에서 87% 사이입니다. 이러한 실패는 에이전트들이 서로 엇갈린 대화를 하기 때문에 발생합니다. 더 나은 모델을 쓴다고 해서 해결될 문제가 아닙니다. 이것은 모델의 문제가 아니라 조정(coordination)의 문제입니다.
그렇다면 대신 어떻게 구축해야 할까요?
다음 두 가지 규칙을 따르십시오:
- 작업이 독립적이라면, 별도의 루프(loop)로 실행하십시오. 두 개의 별도 프로그램을 사용하십시오. 이것은 병렬 처리(parallel processing)이지, 멀티 에이전트 시스템이 아닙니다.
- 작업에 단일한 사고 흐름(single train of thought)이 필요하다면, 하나의 루프만 사용하십시오.
단일 루프는 모든 컨텍스트를 한곳에 유지합니다. 스스로 쉽게 교정(self-correct)할 수 있습니다. 지저분한 단체 채팅방 대신 깔끔한 히스토리를 남깁니다.
메쉬(mesh)를 만드는 것을 멈추고, 루프(loop)를 만들기 시작하십시오.
Source: https://dev.to/tony__vi/you-dont-need-sub-agents-1eh7
Optional learning community: https://t.me/GyaanSetuAi