멀티 에이전트
멀티 에이전트 (Multi-agent)
멀티 에이전트 시스템은 전문화된 컴포넌트들을 조율해서 복잡한 워크플로를 다뤄요. 다만 모든 복잡한 작업에 이 접근이 필요한 건 아닙니다. 적절한(때로는 동적인) 도구와 프롬프트를 갖춘 단일 에이전트로도 비슷한 결과를 얻을 수 있는 경우가 많아요. 내장 멀티 에이전트 지원이 필요하다면, 서브에이전트·스킬·플래닝·가상 파일시스템·컨텍스트 관리를 제공하는 상위 레벨 하니스인 Deep Agents를 사용하세요.
왜 멀티 에이전트인가요? (Why multi-agent?)
개발자들이 "멀티 에이전트"가 필요하다고 말할 때, 보통 다음 능력 중 하나 이상을 원하는 경우가 많아요.
- 컨텍스트 관리 (Context management): 모델의 컨텍스트 윈도우를 압도하지 않으면서 전문화된 지식을 제공합니다. 컨텍스트가 무한하고 지연이 0이라면 모든 지식을 단일 프롬프트에 쏟아부을 수 있겠지만, 현실은 아니죠. 그래서 관련 정보를 선택적으로 표면화하는 패턴이 필요한 겁니다.
- 분산 개발 (Distributed development): 서로 다른 팀이 명확한 경계를 가진 더 큰 시스템으로 합성되는 기능을 독립적으로 개발하고 유지할 수 있게 합니다.
- 병렬화 (Parallelization): 하위 작업을 위한 전문화된 워커를 만들어 동시에 실행함으로써 더 빠른 결과를 얻습니다.
단일 에이전트가 도구가 너무 많아 어떤 걸 쓸지 잘못 결정하거나, 광범위한 컨텍스트(긴 프롬프트와 도메인 특화 도구)가 필요한 전문화된 지식을 요구하거나, 특정 조건이 충족된 후에만 능력을 여는 순차 제약을 강제해야 할 때, 멀티 에이전트 패턴이 특히 가치 있어요.
멀티 에이전트 설계의 중심에는 컨텍스트 엔지니어링(context engineering) — 각 에이전트가 어떤 정보를 보는지 결정하는 것 — 이 자리 잡고 있습니다. 각 에이전트가 자신의 작업에 맞는 올바른 데이터에 접근하도록 보장하는 것이 시스템 품질의 핵심이에요.
패턴 (Patterns)
멀티 에이전트 시스템을 구축하는 주요 패턴들입니다. 각 패턴이 쓰임새가 달라요.
| 패턴 | 동작 방식 |
|---|---|
| Subagents | 메인 에이전트가 서브에이전트를 도구로 조율합니다. 모든 라우팅이 메인 에이전트를 거치며, 언제 어떻게 각 서브에이전트를 호출할지 결정하죠. |
| Handoffs | 상태에 따라 동작이 동적으로 변합니다. 도구 호출이 라우팅·구성 변경을 트리거하는 상태 변수를 업데이트해서, 에이전트를 전환하거나 현재 에이전트의 도구와 프롬프트를 조정합니다. |
| Skills | 전문화된 프롬프트와 지식을 온디맨드로 로드합니다. 단일 에이전트가 제어를 유지하면서 필요할 때 스킬에서 컨텍스트를 불러옵니다. |
| Router | 라우팅 단계가 입력을 분류하고 하나 이상의 전문화된 에이전트로 보냅니다. 결과는 결합된 응답으로 합성됩니다. |
| Custom workflow | LangGraph로 맞춤형 실행 흐름을 만듭니다. 결정적 로직과 에이전트적 동작을 섞고, 다른 패턴을 워크플로의 노드로 내장합니다. |
패턴 고르기 (Choosing a pattern)
요구사항에 맞는 패턴을 고르는 표는 다음과 같은 축을 기준으로 비교합니다: 분산 개발(Distributed development), 병렬화(Parallelization), 다중 홉(Multi-hop), 직접 사용자 상호작용(Direct user interaction), 순차 제약(Sequential constraints), 부하(overhead). 각 패턴은 특성에 따라 이 축들에서 장단점이 다르므로, 자신의 사용 사례에 어떤 축이 중요한지 먼저 정리한 뒤 패턴을 고르는 걸 추천해요.