Choosing the Right Multi-Agent Architecture
Video

Choosing the Right Multi-Agent Architecture

LangChain
2026.01.17
·YouTube·by 이호민
#Multi-Agent#Agent Architecture#LLM#System Design

핵심 포인트

  • 1Lingchain은 불필요한 multi-agent architecture 사용에 주의하며, 복잡한 task에 대한 아키텍처 선택 가이드라인을 제시합니다.
  • 2Sub-agents, Handoffs, Skills, Router의 네 가지 주요 아키텍처를 Distributed Development, Parallelization, Multihop Conversational Support, Direct User Interaction 네 가지 기준으로 평가합니다.
  • 3각 아키텍처는 특정 기준에서 강점과 약점을 가지므로, 시스템의 복잡성과 요구되는 기능에 맞춰 가장 적합한 multi-agent architecture를 선택해야 합니다.

Lingchain의 Sydney는 다중 에이전트(multi-agent) 아키텍처 선택에 대한 가이드를 제시합니다. 먼저, 모든 태스크에 다중 에이전트 패턴이 필요한 것은 아니며, 많은 에이전트 태스크(agentic tasks)는 잘 설계된 도구(tools)를 가진 단일 에이전트(single agent)로 처리하는 것이 가장 좋다고 경고합니다. 하지만 태스크가 점점 더 복잡해질수록 다중 에이전트가 적합할 수 있습니다.

이 문서는 다중 에이전트 아키텍처를 평가하는 네 가지 기준을 제시합니다:

  1. Distributed Development (분산 개발): 서로 다른 팀이 전문 분야에 따라 다른 컴포넌트(components) 또는 에이전트를 독립적으로 유지 관리할 수 있는지 여부.
  2. Parallelization (병렬 처리): 여러 에이전트를 동시에 실행할 수 있는지 여부.
  3. Multihop Conversational Support (멀티홉 대화 지원): 이전 호출의 컨텍스트(context)를 사용하여 여러 서브 에이전트(sub-agents)를 연속적으로 호출하는 것을 아키텍처가 지원하는지 여부.
  4. Direct User Interaction (사용자 직접 상호작용): 서브 에이전트가 사용자와 직접 대화할 수 있는지 여부.

이러한 기준에 따라 네 가지 아키텍처 패턴을 평가합니다:

  1. Sub-agents (Supervisor Pattern):
    • 설명: 메인 슈퍼바이저 에이전트(main supervisor agent)가 서브 에이전트들을 도구(tools)로 조정합니다. 모든 메시지 라우팅(message routing)은 메인 에이전트를 통해 이루어지며, 메인 에이전트가 각 서브 에이전트를 언제 어떻게 호출할지 결정합니다.
    • 평가:
      • Distributed Development: 5/5 (다른 팀이 서브 에이전트/도구를 관리하는 데 매우 적합).
      • Parallelization: 5/5 (병렬 도구 호출을 지원).
      • Multihop Conversational Support: 5/5 (모델과 도구 호출 루프의 여러 사이클로 쉽게 구성 가능).
      • Direct User Interaction: 1/5 (사용자와 서브 에이전트의 직접적인 상호작용이 어렵다. LangChain 아키텍처에서는 인터럽트(interrupts)를 통해 기술적으로 가능하지만 쉽지 않다).
  1. Handoffs Pattern:
    • 설명: 에이전트가 도구 호출을 사용하여 다른 에이전트에게 제어권(control)을 넘겨줄 수 있습니다. 사용자 요청은 진입점 에이전트(entry point agent)로 전송되며, 모든 에이전트(A, B, C 등)는 서로에게 제어권을 넘겨주고 최종 응답을 생성할 수 있습니다.
    • 평가:
      • Distributed Development: 약점 (서로에게 제어권을 넘겨야 하는 에이전트를 독립적으로 개발하기 어렵다).
      • Parallelization: 약점 (특화된 분야가 아니다).
      • Multihop Conversational Support: 5/5 (이 두 가지 기능(multihop, direct user interaction)을 원한다면 가장 좋은 아키텍처).
      • Direct User Interaction: 5/5 (Handoffs 패턴과 Multihop Conversational Support는 이 아키텍처의 강점).
  1. Skills (준 다중 에이전트 아키텍처):
    • 설명: 전문화된 프롬프트(prompts)와 지식(knowledge)을 온디맨드(on demand)로 로드(load)합니다. 단일 에이전트가 제어권을 유지하면서 필요에 따라 스킬(skills)에서 컨텍스트를 로드하는 '점진적 공개(progressive disclosure)' 방식을 사용합니다.
    • 평가:
      • Distributed Development: 5/5 (다른 팀이 다른 스킬을 관리할 수 있어 점수가 매우 높다).
      • Parallelization: 3/5 (여러 스킬을 병렬로 로드하고 호출할 수 있지만, 두 단계 프로세스이므로 최고점은 아니다).
      • Multihop Conversational Support: 5/5 (서브 에이전트(스킬)에 대한 여러 직렬 호출이 가능하다).
      • Direct User Interaction: 5/5 (사용자가 직접 상호작용할 수 있는 핵심 에이전트가 하나만 존재).
  1. Router Architecture:
    • 설명: 라우팅(routing) 단계가 입력을 분류하고 하나 이상의 전문화된 에이전트로 지시하며, 결과는 합성(synthesize)되어 결합된 응답으로 제공됩니다. 라우터와 신시사이저(synthesizer) 단계는 에이전트적(agentic)일 수도 있고, 더 결정적(deterministic)일 수도 있습니다.
    • 평가:
      • Distributed Development: 3/5 (서브 에이전트나 스킬처럼 표준 프로토콜이 없기 때문에 표준화하기가 다소 어렵다. 분산 개발은 가능하지만 쉽지는 않다).
      • Parallelization: 5/5 (라우터가 여러 서브 에이전트를 병렬로 또는 한 번에 하나씩 호출할 수 있다).
      • Multihop Conversational Support: 0/5 (에이전트의 여러 직렬 호출이 이 아키텍처에서는 그다지 실현 가능하지 않다. 상태 저장 라우터(stateful routers)는 관리하기 훨씬 더 어렵다).
      • Direct User Interaction: 3/5 (에이전트 호출 양쪽에 라우터와 신시사이저 단계가 있어서 다른 아키텍처만큼 직접적이지 않다).

결론적으로, 이 문서는 다양한 다중 에이전트 아키텍처의 장단점을 평가 기준에 따라 분석하고, 문제의 복잡성에 따라 단일 에이전트부터 시작하여 점진적으로 확장할 것을 권장합니다.