Multi-Agent Systems in Production: When One Agent Isn't Enough and How We Coordinate Them

개요

여러 에이전트가 협력하는 멀티 에이전트 시스템은 단일 에이전트의 한계를 극복하고 복잡한 작업을 수행하는 데 효과적이지만, 복잡성 증가와 조정 오버헤드라는 새로운 과제를 야기합니다.

주요 내용

* 단일 에이전트 vs. 멀티 에이전트:
* 단일 에이전트: 작업이 LLM 컨텍스트 창에 적합하고, 단계가 순차적이며, 정보 간의 긴밀한 추론이 필요할 때 적합합니다.
* 멀티 에이전트: 단일 에이전트의 컨텍스트 창이 부족하거나, 각 단계가 서로 다른 "페르소나" 또는 지침 집합을 요구하거나, 단계별 병렬 처리가 가능하고 지연 시간 단축이 중요하거나, 실패를 격리해야 할 때 필요합니다. "이것은 하나의 작업인가, 아니면 일련의 작업인가?"라는 질문으로 판단할 수 있습니다.
* 실제 사용되는 세 가지 패턴:
* Supervisor-Worker: 씬(thin) 오케스트레이터 에이전트가 작업을 분배하고 결과를 취합하는 방식으로, 가장 일반적인 패턴입니다.
* Sequential Pipeline: 각 에이전트의 출력이 다음 에이전트의 입력으로 사용되는 체인 형태입니다. 문서 처리 등에 활용됩니다.
* Event-Driven Agents: 에이전트가 직접 호출되는 대신 이벤트에 구독하는 방식으로, 비동기 처리가 필요한 경우에 사용됩니다.
* Django + Celery를 활용한 오케스트레이터 구현: Supervisor 패턴 구현 예시로, Celery 태스크를 통해 워크플로우를 관리하고 개별 에이전트 태스크가 LLM 호출을 담당합니다. 오케스트레이터는 데이터의 형태만 신경 쓰면 됩니다.
* 에이전트 간 상태 전달: 전체 출력을 직접 전달하는 대신, Pydantic 모델과 같은 구조화된 중간 형식을 사용하여 에이전트 간의 계약을 정의하고, 각 에이전트의 출력은 이 스키마에 따라 검증됩니다.
* 실패 처리:
* 각 단계마다 데이터베이스에 결과를 체크포인트하고, 실패 시 이전 단계의 저장된 출력부터 재시작할 수 있도록 합니다.
* 각 에이전트는 독립적으로 재시도를 수행하며, 오케스트레이터는 파이프라인 상태를 추적합니다.
* PipelineRun 모델을 통해 각 단계의 상태와 오류 정보를 관리하여 디버깅을 용이하게 합니다.
* 정직한 요약: 멀티 에이전트 아키텍처는 컨텍스트 오버플로우, 전문화, 병렬 처리, 실패 격리 등의 문제를 해결하지만, 조정 오버헤드를 추가하고 지연 시간을 증가시킵니다. 개별 에이전트의 프롬프트 디자인이나 작업 분해가 잘못된 경우를 해결해주지는 않습니다.

시사점

멀티 에이전트 시스템은 단일 에이전트의 복잡성을 해결하고 확장성과 복원력을 높일 수 있지만, 구현 및 관리에 대한 신중한 접근이 필요하며, 실제 필요성이 명확할 때 도입해야 합니다.