핵심 요약
최근 Swarms 팀이 발표한 GraphWorkflow는 다중 에이전트(Agent) 작업의 스케줄링 속도를 향상시켰지만, 이 논문의 진정한 가치는 “62.5%의 속도 향상”이라는 숫자 그 자체에 있지 않습니다. 이 논문은 중요한 시사점을 제시합니다: 다중 에이전트 시스템(일반적으로 “벌집”이라고 불림)이 이제 “모델의 지능”을 경쟁하는 단계에서 “조직적 협업 능력”을 강화하는 단계로 진화했음을 보여줍니다. 벌집의 성능은 단순히 에이전트의 수가 많은 것에 달려있지 않으며, “어떻게 지능적인 에이전트들이 서로의 시간을 낭비하지 않고, 집단적으로 오류를 범하지 않으며, 안정적으로 작업을 완수할 수 있을지”에 달려 있습니다.
1. “벌집”이라고 해서 모두가 같은 것은 아닙니다
많은 제품들이 “여러 에이전트가 동시에 작동하는 것”을 벌집이라고 부르지만, 엄밀히 말해 진정한 벌집은 “중앙 집중식 제어가 없이, 각 에이전트가 자신의 정보에 기반해 행동하며 전체가 집단적인 행동을 형성하는” 것입니다(예: 개미가 길을 찾는 과정). 현재 실제로 사용 가능한 다중 에이전트 시스템들은 더 많은 경우 “임시 프로젝트 팀”에 가깝습니다:
- 단일 에이전트: 혼자 일하는 숙련된 직원처럼, 선형적이고 짧은 작업에 적합합니다(예: 이메일 작성);
- Supervisor/Worker: 프로젝트 매니저가 몇 명의 조수를 이끄는 경우(예: Anthropic의 시스템에서는 주 에이전트가 작업을 분담하고 부 에이전트가 자료를 조사함);
- Graph Workflow: 고정된 프로세스의 흐름(예: 규정 준수 검토, 대량 테스트)에 사용되며, GraphWorkflow와 LangGraph도 이 범주에 속함;
- 동적 벌집: 작업 중에 어떻게 분담할지, 어떤 동료와 협력할지를 스스로 결정하는 경우(예: Kimi Agent Swarm은 300개의 부 에이전트를 동적으로 조정할 수 있음);
- 완전히 분산된 벌집: 아직 실험실 단계에 있으며(예: 새떼의 움직임을 모방한 것), 실제 사용에는 멀었습니다.
따라서 벌집의 본질은 “조직적 문제”입니다: 어떻게 여러 에이전트가 분업, 커뮤니케이션, 상태 공유를 통해 단일 에이전트로는 해결할 수 없는 작업을 완수할 수 있을지입니다.
2. 왜 다중 에이전트가 필요한가? 단일 에이전트로는 해결할 수 없는 작업들
개별 모델들은 점점 더 지능적으로 발전하고 있지만, 모든 작업이 “더 많은 시간을 주면” 해결되는 것은 아닙니다:
- 작업 범위가 너무 넓음: 예를 들어 100개의 보고서에서 상호 확인할 수 있는 사실을 찾아야 하는 경우, 단일 에이전트는 하나하나 확인해야 하므로 막힐 수 있습니다; 다중 에이전트는 다른 방향으로 동시에 조사할 수 있습니다(예: 여러 사람이 다른 자료를 검토하는 것처럼).
- 단일 사고의 한계: 단일 에이전트는 한 가지 방향에만 집중하면 다른 경로를 무시할 수 있습니다; 다중 에이전트는 여러 경로를 동시에 탐색할 수 있습니다(예: 누군가는 공개 자료를 검토하고, 누군가는 원본 문서를 검토하며, 누군가는 반증을 제시함).
Anthropic의 예시는 이를 잘 보여줍니다: 주 에이전트가 전반적인 계획을 세우고 부 에이전트가 작업을 수행할 때, 단일 최강 모델을 사용하는 것보다 90% 더 좋은 결과를 얻을 수 있지만, 토큰 비용(비용)은 15배나 높습니다! 모든 작업에 이 방법이 적합한 것은 아닙니다! 예를 들어 프로그래밍 작업에서는 병렬로 수행할 수 있는 부분이 적으므로, 다중 에이전트는 오히려 작업의 전달 과정에서 손실을 증가시킬 수 있습니다.
3. 스케줄링 속도 향상의 이면: 조직적 측면이 계산 자원을 더 많이 소비하기 시작함
GraphWorkflow의 속도 향상은 “작업 스케줄링”을 최적화한 결과입니다: 고정된 작업 흐름도를 미리 컴파일한 후 반복적으로 실행함으로써 “누가 누구를 기다리고, 누가 결과를 전달할지”에 걸리는 시간을 줄였습니다. 하지만 이는 단일 컴퓨터에서의 정적인 작업 스케줄링 비용만 측정한 것이며, 모델 자체의 속도는 측정하지 않았습니다. 모델 호출에는 수백 밀리초가 소요되므로, 스케줄링 최적화가 미치는 영향은 크지 않습니다.
하지만 이는 중요한 문제를 시사합니다: 에이전트의 수가 수십 개에서 수백 개로 증가하면 “조직적 비용”이 큰 비중을 차지하기 시작합니다. 마치 회사의 직원이 많아지면 누가 무엇을 할지, 누가 누구를 기다릴지, 누가 오류가 발생했을 때 어떻게 재시도할지를 조정하는 데 시간이 필요한 것처럼, 이러한 스케줄링 작업은 더 이상 “부가적인 기능”이 아니라 시스템이 안정적으로 작동할 수 있는지를 결정하는 핵심 요소가 됩니다. 이제 사람들이 벌집에 대해 논의할 때 “워크플로우, 스케줄러, 상태 통합”과 같은 엔지니어링 용어들을 더 많이 사용하는 이유도 바로 이 때문입니다.
4. 벌집의 세 가지 어려운 문제: 작업 분담, 정보 기억, 오류 검증
작업을 여러 에이전트에게 분담하는 것은 관리처럼 보이지만, 실제로는 기술적으로 어려운 문제입니다:
1. 임무 할당: 어떤 작업을 어떻게 분담할지? 누구에게 할당할지? 언제 스스로 처리하지 않고 다른 에이전트에게 할당할지? 예를 들어 SearchSwarm은 주 에이전트가 “임무를 할당할지”를 학습하도록 하고, 부 에이전트는 압축된 결과만 전달하여 상황 정보의 낭비를 방지합니다.
2. 기억: “사용자의 선호도를 기억하는” 것이 아니라 “작업의 증거 체인”을 기억하는 것입니다. 누가 어떤 작업을 책임지는지? 결론은 어떤 자료에서 나온 것인지? 어떤 가정이 반박되었는지? 모든 에이전트가 긴 대화 내용을 전달한다면 시스템은 노이즈에 의해 압도될 것입니다.
3. 검증: 다중 에이전트가 반드시 더 신뢰할 수 있는 것은 아니며, 오히려 집단적으로 오류를 범할 수도 있습니다(예: 모두가 동일한 자료를 사용하여 편견을 강화하는 경우). 실험에 따르면 중앙 집중식 검증 기능이 있는 아키텍처의 오류 확률은 4.4배로, 검증 기능이 없는 경우의 17.2배보다 훨씬 낮습니다. 미래에 가장 부족해질 역할은 “작업을 하는 Worker”가 아니라 “오류를 검증하는 Verifier”(품질 관리자)입니다.
5. 미래의 벌집: “소규모 회사”가 아니라 임시 팀
미래의 벌집은 “소규모 회사”가 아니라 특정 작업을 위한 임시 팀으로 발전할 것입니다. 예를 들어 대규모 프로젝트에서는 여러 팀이 협력하여 작업을 완수할 수 있으며, 프로젝트가 끝나면 각 팀은 해체될 수 있습니다. 이러한 방식은 민첩성과 효율성을 높일 수 있으며, 변화하는 환경에 더 잘 적응할 수 있습니다.
결론
다중 에이전트와 분산된 시스템은 미래의 기술 발전 방향입니다. 이러한 기술은 우리가 직면하는 복잡한 문제들을 해결하는 데 도움을 줄 수 있으며, 새로운 기회를 창출할 수 있습니다. 하지만 동시에 조직적인 관리와 기술적인 도전도 필요합니다. 우리는 이러한 변화에 대비하여 적절한 전략과 기술을 준비해야 합니다.