다중 에이전트 아키텍처 선택하기

https://www.blog.langchain.com/choosing-the-right-multi-agent-architecture/

이 글에서는 다중 에이전트 아키텍처가 필요해지는 시점, 우리가 관찰한 네 가지 주요 패턴, 그리고 LangChain이 다중 에이전트 시스템을 효과적으로 구축하도록 어떻게 지원하는지 살펴봅니다.

많은 에이전트 작업은 잘 설계된 도구를 갖춘 단일 에이전트가 가장 적합합니다. 여기서 시작하는 것이 좋습니다—단일 에이전트는 구축, 추론, 디버깅이 더 간단합니다. 그러나 애플리케이션이 확장되면, 팀들은 단일 일관된 인터페이스로 결합하고 싶은 방대한 에이전트 기능을 결합하려는 공통의 과제에 직면합니다. 결합하려는 기능 수가 증가함에 따라 두 가지 주요 제약이 나타납니다:

컨텍스트 관리: 각 기능에 대한 전문 지식은 단일 프롬프트에 편안히 담기 어렵습니다. 컨텍스트 윈도우가 무한하고 지연이 0이라면 모든 관련 정보를 처음부터 포함할 수 있겠지만, 실제로는 에이전트가 작업하는 동안 선별적으로 정보를 표면화하는 전략이 필요합니다.

분산 개발: 서로 다른 팀이 각 기능을 독립적으로 개발 및 유지 관리하며, 명확한 경계와 소유권을 가집니다. 단일 모놀리식 에이전트 프롬프트는 팀 경계를 넘나들며 관리하기 어려워집니다.

이러한 제약은 광범위한 도메인 지식을 관리하고, 팀 간 조정을 수행하거나, 진정으로 복잡한 작업을 다룰 때 중요해집니다. 이러한 경우에 다중 에이전트 아키텍처가 올바른 선택이 될 수 있습니다.

최근 연구는 이러한 상황에서 다중 에이전트 시스템이 더 나은 성능을 낸다는 것을 보여줍니다. Anthropic의 다중 에이전트 연구 시스템에서, 리드 에이전트로 Claude Opus 4, 서브에이전트로 Claude Sonnet 4를 둔 다중 에이전트 아키텍처는 내부 연구 평가에서 단일 에이전트 Claude Opus 4 대비 90.2% 더 우수한 성능을 보였습니다. 별도의 컨텍스트 윈도우를 가진 에이전트들에 작업을 분산하는 아키텍처의 능력은 단일 에이전트가 달성할 수 없었던 병렬 추론을 가능하게 했습니다.

다중 에이전트 아키텍처

대부분의 다중 에이전트 애플리케이션의 기초를 이루는 네 가지 아키텍처 패턴은 서브에이전트, 스킬, 핸드오프, 라우터입니다. 각 패턴은 작업 조정, 상태 관리, 순차적 잠금 해제에 대해 서로 다른 접근을 취합니다. 아래에서는 가장 중요한 제약을 가장 잘 해결하는 아키텍처를 선택하기 위한 프레임워크를 제시합니다.

서브에이전트: 중앙 집중식 오케스트레이션

서브에이전트 패턴에서는 감독자(supervisor) 에이전트가 특화된 서브에이전트를 도구처럼 호출하여 조정합니다. 메인 에이전트는 대화 컨텍스트를 유지하는 반면 서브에이전트는 상태 없이 작동하여 강한 컨텍스트 분리를 제공합니다.

동작 방식: 메인 에이전트가 어떤 서브에이전트를 호출할지, 어떤 입력을 제공할지, 결과를 어떻게 결합할지 결정합니다. 서브에이전트는 과거 상호작용을 기억하지 않습니다. 이 아키텍처는 모든 라우팅이 메인 에이전트를 통해 지나가는 중앙 집중식 제어를 제공하며, 메인 에이전트가 여러 서브에이전트를 병렬로 호출할 수 있습니다.

적합한 경우: 여러 개별 도메인이 있고 중앙 집중식 워크플로우 제어가 필요하며 서브에이전트가 사용자와 직접 대화할 필요가 없는 애플리케이션. 예로는 캘린더, 이메일, CRM 작업을 조정하는 개인 비서나, 특화된 도메인 전문가에게 위임하는 연구 시스템이 있습니다.

핵심 트레이드오프: 결과가 메인 에이전트를 통해 다시 흐르기 때문에 상호작용당 모델 호출이 하나 더 추가됩니다. 이 오버헤드는 중앙 집중식 제어와 컨텍스트 분리를 제공하지만 지연과 토큰 비용을 증가시킵니다.

이 패턴을 최소한의 설정으로 사용하고 싶은 개발자를 위해, Deep Agents는 몇 줄의 코드만으로 서브에이전트를 추가하는 즉시 사용 가능한 구현을 제공합니다.

더 알아보기: 서브에이전트 문서 | 튜토리얼: 서브에이전트로 개인 비서 구축

스킬: 점진적 공개

스킬 패턴에서는 에이전트가 필요할 때 특화된 프롬프트와 지식을 로드합니다. 에이전트 기능에 대한 점진적 공개로 생각할 수 있습니다.

스킬 아키텍처는 기술적으로 단일 에이전트를 사용하지만, 해당 에이전트가 동적으로 특화된 페르소나를 채택하도록 해 다중 에이전트 시스템과 유사한 특성을 공유합니다. 이 접근은 다중 에이전트 패턴과 유사한 이점(예: 분산 개발, 세밀한 컨텍스트 제어)을 제공하지만, 여러 에이전트 인스턴스를 관리하는 대신 프롬프트 중심의 더 가벼운 방식으로 이를 달성합니다. 그래서, 다소 논쟁의 여지가 있지만, 우리는 스킬을 준(quasi) 다중 에이전트 아키텍처로 간주합니다.

동작 방식: 스킬은 지시문, 스크립트, 리소스를 포함하는 디렉터리로 패키징된 프롬프트 중심의 특수화입니다. 시작 시 에이전트는 스킬 이름과 설명만 압니다. 스킬이 관련될 때 에이전트는 그 전체 컨텍스트를 로드합니다. 스킬 내 추가 파일들은 에이전트가 필요할 때만 발견하는 세 번째 수준의 세부 정보를 제공합니다.

적합한 경우: 가능한 특수화가 많은 단일 에이전트, 기능 간 제약을 적용할 필요가 없는 상황, 또는 서로 다른 팀이 서로 다른 스킬을 유지 관리하는 팀 분산. 일반적인 예로는 코딩 에이전트나 크리에이티브 어시스턴트가 있습니다.

핵심 트레이드오프: 스킬이 로드됨에 따라 대화 기록에 컨텍스트가 누적되어 이후 호출에서 토큰 팽창을 초래할 수 있습니다. 그러나 이 패턴은 단순성과 사용자와의 직접 상호작용을 전 과정에서 제공합니다.

더 알아보기: 스킬 문서 | 튜토리얼: 온디맨드 스킬로 SQL 어시스턴트 구축

핸드오프: 상태 기반 전환

핸드오프 패턴에서는 활성 에이전트가 대화 컨텍스트에 따라 동적으로 변경됩니다. 각 에이전트는 도구 호출을 통해 다른 에이전트로 전환할 수 있습니다.

동작 방식: 에이전트가 핸드오프 도구를 호출하면 다음에 활성화될 에이전트를 결정하는 상태를 업데이트합니다. 이는 다른 에이전트로 전환하거나 현재 에이전트의 시스템 프롬프트 및 사용 가능한 도구를 변경하는 것을 의미할 수 있습니다. 상태는 대화 턴 간에 지속되어 순차적 워크플로우를 가능하게 합니다.

적합한 경우: 단계적으로 정보를 수집하는 고객 지원 플로우, 다단계 대화형 경험, 또는 전제조건이 충족된 후에만 기능이 잠금 해제되는 순차적 제약이 필요한 시나리오.

핵심 트레이드오프: 다른 패턴보다 상태성이 더 강해 신중한 상태 관리가 필요합니다. 그러나 이를 통해 컨텍스트가 단계 간 자연스럽게 이어지는 유연한 다중 턴 대화를 구현할 수 있습니다.

더 알아보기: 핸드오프 문서 | 튜토리얼: 핸드오프로 고객 지원 구축

라우터: 병렬 디스패치와 합성

라우터 패턴에서는 라우팅 단계가 입력을 분류하고 이를 특화된 에이전트에 전달하여, 쿼리를 병렬로 실행하고 결과를 합성합니다.

동작 방식: 라우터는 쿼리를 분해하고 특화된 에이전트를 0개 이상 병렬로 호출한 뒤 결과를 일관된 응답으로 합성합니다. 라우터는 일반적으로 상태가 없으며 각 요청을 독립적으로 처리합니다.

적합한 경우: 개별 지식 도메인이 분명한 애플리케이션(독립된 버티컬), 여러 소스에 대한 병렬 쿼리가 필요한 시나리오, 또는 여러 에이전트의 결과를 합성해야 하는 상황. 예로는 엔터프라이즈 지식 베이스와 다중 버티컬 고객 지원 어시스턴트가 있습니다.

핵심 트레이드오프: 상태가 없다는 설계는 요청당 일관된 성능을 보장하지만, 대화 기록이 필요하다면 반복적인 라우팅 오버헤드가 발생합니다. 이는 라우터를 상태가 있는 대화형 에이전트 내의 도구로 래핑하여 완화할 수 있습니다.

더 알아보기: Router 문서 | 튜토리얼: 라우팅으로 다중 소스 지식 베이스 구축

요구사항과 패턴 매칭

다중 에이전트 시스템을 구현하기 전에, 귀하의 요구사항이 다음 네 가지 패턴 중 하나와 맞는지 고려하세요:

아래의 표는 각 패턴이 일반적인 다중 에이전트 요구사항을 어떻게 지원하는지 보여줍니다:

• 분산 개발: 서로 다른 팀이 구성 요소를 독립적으로 유지 관리할 수 있는가?
• 병렬화: 여러 에이전트가 동시에 실행할 수 있는가?
• 멀티-홉: 패턴이 연속적으로 여러 서브에이전트를 호출하는 것을 지원하는가?
• 사용자 직접 상호작용: 서브에이전트가 사용자와 직접 대화할 수 있는가?

성능 특성

아키텍처 선택은 지연, 비용, 사용자 경험에 직접적인 영향을 미칩니다. 우리는 실제 조건에서 서로 다른 패턴이 어떻게 성능을 발휘하는지 이해하기 위해 세 가지 대표적 시나리오를 분석했습니다.

전체 성능 분석(각 아키텍처에 대한 mermaid 다이어그램 포함)은 새로 공개된 다중 에이전트 성능 문서에서 확인할 수 있습니다.

시나리오 1: 원샷 요청

사용자가 단일 요청을 합니다: “커피를 사줘.” 특화된 에이전트가 ⁠buy_coffee⁠ 도구를 호출할 수 있습니다.

핵심 인사이트: 핸드오프, 스킬, 라우터는 단일 작업에 가장 효율적입니다(각각 3회 호출). 서브에이전트는 결과가 메인 에이전트를 통해 되돌아오기 때문에 한 번의 추가 호출이 발생합니다. 이 오버헤드는 아래에서 보듯 중앙 집중식 제어를 제공합니다.

시나리오 2: 반복 요청

사용자가 같은 요청을 대화에서 두 번 합니다:

• 턴 1: “커피를 사줘”
• 턴 2: “다시 커피를 사줘”

핵심 인사이트: 상태를 유지하는 패턴(핸드오프, 스킬)은 컨텍스트를 유지함으로써 반복 요청에서 40-50%의 호출을 절약합니다. 서브에이전트는 상태가 없기 때문에 요청당 일정한 비용을 유지하며, 컨텍스트 분리를 제공하는 대신 반복적인 모델 호출 비용을 부담합니다.

시나리오 3: 다중 도메인 질의

사용자가 질문합니다: “웹 개발에서 Python, JavaScript, Rust를 비교해줘.” 각 언어 에이전트는 약 2000 토큰의 문서를 포함합니다. 모든 패턴은 병렬 도구 호출을 수행할 수 있습니다.

핵심 인사이트: 다중 도메인 작업에서는 병렬 실행이 가능한 패턴(서브에이전트, 라우터)이 가장 효율적입니다. 스킬은 호출 수는 적지만 컨텍스트 누적으로 인해 토큰 사용량이 높습니다. 핸드오프는 반드시 순차적으로 실행해야 하므로 여러 도메인을 동시에 조회하는 병렬 도구 호출을 활용할 수 없습니다.

이 시나리오에서 서브에이전트는 컨텍스트 분리 덕분에 스킬 대비 전체 토큰을 67% 적게 처리합니다. 각 서브에이전트는 관련 컨텍스트로만 작업하여, 여러 스킬을 단일 대화에 로드할 때 발생하는 토큰 팽창을 피합니다.

성능 요약

최적의 패턴은 워크로드 특성에 따라 달라집니다:

시작하기

다중 에이전트 시스템은 복잡한 워크플로우를 해결하기 위해 특화된 구성 요소를 조정합니다. 다중 에이전트 기능이 필요할 때는 위의 의사결정 프레임워크에 요구사항을 매칭하세요. 빠르게 시작하려는 팀을 위해 Deep Agents는 복잡한 작업 계획을 위해 서브에이전트와 스킬을 결합한 즉시 사용 가능한 구현을 제공합니다.

그러나 많은 경우 더 단순한 아키텍처로 충분합니다. 단일 에이전트와 좋은 프롬프트 엔지니어링으로 시작하세요. 에이전트를 추가하기 전에 도구를 추가하세요. 명확한 한계에 도달할 때에만 다중 에이전트 패턴으로 발전하세요.