멀티 에이전트 시스템, 언제 써야 할까? 컨텍스트, 병렬 처리, 전문화가 핵심!
단일 에이전트(Single Agent)의 한계점을 인지하고, 멀티 에이전트 시스템(Multi-agent System) 도입의 필요성을 강조
컨텍스트 오염(Context Pollution), 병렬 처리(Parallelization), 전문성(Specialization)을 위한 멀티 에이전트 시스템 활용 전략 제시
오케스트레이터-서브 에이전트(Orchestrator-Subagent) 패턴을 중심으로, 검증 서브 에이전트(Verification Subagent)의 역할과 구현 방법 설명
멀티 에이전트 시스템 도입 시 토큰 사용량 증가(Token Usage Increase), 조정 비용(Coordination Cost) 등 트레이드오프(Trade-off) 발생
단일 에이전트(Single Agent)의 성능 개선 가능성을 인지하고, 멀티 에이전트 시스템 도입 전 신중한 검토 필요
멀티 에이전트 시스템(Multi-agent System)의 기본 아키텍처
본문은 멀티 에이전트 시스템(Multi-agent System)을 여러 LLM 인스턴스(LLM Instances)가 코드(Code)를 통해 조정되는 아키텍처로 정의한다. 핵심 패턴은 오케스트레이터-서브 에이전트(Orchestrator-Subagent)로, 리드 에이전트(Lead Agent)가 특정 하위 작업을 위해 전문화된 서브 에이전트(Subagents)를 생성하고 관리한다.
장점: 단순한 조정 모델(Coordination Model) 제공 및 멀티 에이전트 시스템(Multi-agent System) 초보자에게 적합
단점: 단일 에이전트(Single Agent)로 충분한 경우, 불필요한 오버헤드(Overhead) 발생 가능성
대안: 에이전트 스웜(Agent Swarms), 기능 기반 시스템(Capability-based Systems), 메시지 버스 아키텍처(Message Bus Architectures) 등 다양한 조정 패턴 존재
단일 에이전트(Single Agent) vs 멀티 에이전트 시스템(Multi-agent System) 비교
글에 따르면, 단일 에이전트(Single Agent)는 적절한 도구(Tools)를 갖춘 경우, 예상보다 훨씬 많은 작업을 수행할 수 있다. 멀티 에이전트 시스템(Multi-agent System)은 추가적인 오버헤드(Overhead)를 발생시키며, 각 에이전트는 잠재적인 실패 지점(Failure Point)이 된다.
토큰 사용량(Token Usage): 멀티 에이전트 시스템(Multi-agent System)은 단일 에이전트(Single Agent) 방식보다 3~10배 더 많은 토큰(Tokens)을 사용
컨텍스트 중복(Context Duplication): 에이전트 간 컨텍스트 중복, 조정 메시지(Coordination Messages) 및 결과 요약(Summarizing Results)으로 인한 오버헤드 발생
핵심: 멀티 에이전트 시스템(Multi-agent System)은 단일 에이전트(Single Agent)가 극복할 수 없는 특정 제약 조건을 해결할 때 가치를 제공
멀티 에이전트 시스템(Multi-agent System)의 3가지 핵심 활용 시나리오
본문은 멀티 에이전트 시스템(Multi-agent System)이 단일 에이전트(Single Agent)보다 뛰어난 3가지 상황을 제시한다. 첫째, 컨텍스트 오염(Context Pollution)으로 성능이 저하될 때, 서브 에이전트(Subagents)를 통해 각 작업에 집중된 깨끗한 컨텍스트(Clean Context)를 유지한다.
예시: 주문 내역 조회와 기술 문제 진단을 동시에 수행하는 경우, 주문 내역이 컨텍스트를 오염시켜 문제 해결 능력 저하
둘째, 병렬 처리(Parallelization)를 통해 단일 에이전트(Single Agent)가 처리할 수 없는 더 넓은 검색 공간(Search Space)을 탐색한다.
예시: 연구(Research) 작업에서 여러 서브 에이전트(Subagents)가 병렬로 다양한 측면을 조사
셋째, 전문성(Specialization)을 통해 특정 도구(Tools) 선택 또는 작업 집중도를 향상시킨다.
검증 서브 에이전트(Verification Subagent) 패턴
글에서는 검증 서브 에이전트(Verification Subagent) 패턴을 효과적인 멀티 에이전트 시스템(Multi-agent System) 패턴으로 소개한다. 이 패턴은 메인 에이전트(Main Agent)의 작업을 테스트하거나 검증하는 전담 에이전트를 활용한다.
장점: 전화 게임 문제(Telephone Game Problem) 회피, 최소한의 컨텍스트 전송으로 작업 검증 가능
구현: 메인 에이전트(Main Agent)가 작업을 완료한 후, 검증 서브 에이전트(Verification Subagent)를 생성하여 검증 수행
핵심: 검증 서브 에이전트(Verification Subagent)는 작업 생성 과정에 대한 전체 컨텍스트 없이, 지정된 기준(Criteria) 충족 여부만 판단
주의사항: 검증 서브 에이전트(Verification Subagent)가 조기 성공 문제(Early Victory Problem)에 빠지지 않도록, 구체적인 기준(Concrete Criteria)과 포괄적인 검사(Comprehensive Checks)를 설정
멀티 에이전트 시스템(Multi-agent System) 설계 시 고려사항
본문은 멀티 에이전트 시스템(Multi-agent System)을 설계할 때, 작업 분할(Decomposition) 방식이 중요하다고 강조한다. 문제 중심 분할(Problem-centric Decomposition)은 종종 비효율적이며, 컨텍스트 중심 분할(Context-centric Decomposition)이 효과적이다.
문제 중심 분할(Problem-centric Decomposition): 작업 유형(Task Type)별 분할은 컨텍스트 손실(Context Loss) 및 조정 오버헤드(Coordination Overhead) 발생
컨텍스트 중심 분할(Context-centric Decomposition): 컨텍스트 경계(Context Boundaries)를 기준으로 분할, 각 에이전트가 필요한 컨텍스트를 최대한 유지
효과적인 분할 경계: 독립적인 연구 경로(Independent Research Paths), 명확한 인터페이스(Clean Interfaces)를 가진 개별 컴포넌트(Separate Components), 블랙박스 검증(Blackbox Verification)
피해야 할 분할 경계: 동일 작업의 순차적 단계(Sequential Phases), 밀접하게 결합된 컴포넌트(Tightly Coupled Components), 공유 상태(Shared State)가 필요한 작업
