AI 에이전트를 만들 때 가장 먼저 마주하는 질문이 있습니다. “에이전트를 몇 개나 만들어야 할까?” 답은 간단해 보이지만, 실제로는 비용과 성능, 복잡도 사이의 미묘한 균형을 요구합니다.

LangChain이 멀티에이전트 아키텍처 선택 가이드를 공개했습니다. 4가지 주요 패턴을 실제 성능 데이터와 함께 비교 분석하고, 요구사항별로 어떤 아키텍처를 선택해야 하는지 명확한 기준을 제시합니다.

출처: Choosing the Right Multi-Agent Architecture – LangChain Blog

싱글에이전트로 충분한 경우

먼저 중요한 원칙부터 짚고 넘어가야 합니다. 대부분의 작업은 싱글에이전트로 해결 가능합니다. 좋은 LLM과 잘 설계된 도구, 명확한 프롬프트만 있다면 굳이 복잡한 멀티에이전트 시스템을 만들 필요가 없죠.

코드 생성, 고객 지원 챗봇, 문서 요약 같은 작업은 싱글에이전트만으로 충분합니다. 하지만 애플리케이션이 확장되면서 두 가지 제약이 나타납니다. 각 기능에 필요한 전문 지식이 하나의 프롬프트에 들어가지 않는 컨텍스트 관리 문제, 그리고 서로 다른 팀이 각 기능을 독립적으로 개발해야 하는 분산 개발 문제죠. 이 지점에서 멀티에이전트 아키텍처가 필요해집니다.

멀티에이전트 4가지 핵심 패턴

1. Subagents: 중앙 집중식 오케스트레이션

슈퍼바이저 에이전트가 전문화된 서브에이전트들을 도구처럼 호출합니다. 메인 에이전트가 대화 컨텍스트를 유지하고, 서브에이전트들은 상태를 저장하지 않아 강력한 컨텍스트 격리를 제공합니다.

적합한 경우: 캘린더, 이메일, CRM 같은 여러 개별 도메인을 조정하는 개인 비서나, 전문 도메인 전문가에게 위임하는 리서치 시스템입니다.

트레이드오프: 결과가 메인 에이전트를 거쳐야 해서 상호작용마다 모델 호출이 하나 더 추가되지만, 중앙 집중식 제어와 컨텍스트 격리를 제공합니다.

2. Skills: 점진적 공개

에이전트가 필요에 따라 전문화된 프롬프트와 지식을 동적으로 로드합니다. 시작할 때는 스킬 이름만 알고 있다가, 특정 스킬이 관련되면 전체 컨텍스트를 로드하죠.

적합한 경우: 많은 가능한 전문화가 있는 싱글에이전트, 또는 다른 팀이 다른 스킬을 유지보수하는 상황입니다. 코딩 에이전트나 크리에이티브 어시스턴트가 대표적이에요.

트레이드오프: 스킬이 로드되면서 대화 히스토리에 컨텍스트가 누적되어 토큰이 증가할 수 있지만, 단순성과 사용자와의 직접적인 상호작용을 제공합니다.

3. Handoffs: 상태 기반 전환

대화 컨텍스트에 따라 활성 에이전트가 동적으로 변경됩니다. 에이전트가 도구 호출을 통해 다른 에이전트로 전환하며, 상태는 대화 턴 전체에서 유지됩니다.

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

트레이드오프: 신중한 상태 관리가 필요하지만, 컨텍스트가 단계 간에 자연스럽게 전달되는 유연한 다중 턴 대화를 가능하게 합니다.

4. Router: 병렬 디스패치와 합성

라우터가 입력을 분류하고 전문화된 에이전트들을 병렬로 호출한 뒤, 결과를 일관된 응답으로 합성합니다. 일반적으로 상태가 없어서 각 요청을 독립적으로 처리하죠.

적합한 경우: 개별 지식 도메인이 있는 엔터프라이즈 지식 베이스나, 여러 소스를 병렬로 쿼리해야 하는 다중 버티컬 고객 지원 어시스턴트입니다.

트레이드오ff: 상태가 없는 설계로 요청당 일관된 성능을 제공하지만, 대화 히스토리가 필요하면 반복적인 라우팅 오버헤드가 발생합니다.

실제 성능 비교에서 드러난 것

LangChain은 세 가지 시나리오를 분석했습니다. 원샷 요청에서는 Handoffs, Skills, Router가 3번의 모델 호출로 가장 효율적이었고, Subagents는 중앙 집중식 제어를 위해 4번이 필요했습니다.

반복 요청에서는 상태를 유지하는 패턴(Handoffs, Skills)이 두 번째 요청에서 40%의 호출을 절약했습니다. 반면 Subagents는 요청당 일관된 비용을 유지하며 강력한 컨텍스트 격리를 제공했죠.

가장 흥미로운 건 다중 도메인 쿼리입니다. “웹 개발을 위한 Python, JavaScript, Rust를 비교해줘”같은 질문에서 Subagents는 컨텍스트 격리 덕분에 Skills보다 전체적으로 67% 적은 토큰을 처리했습니다. 각 서브에이전트가 관련 컨텍스트만 가지고 작업해서, 여러 스킬을 하나의 대화에 로드할 때 누적되는 토큰 증가를 피했기 때문이에요.

요구사항에 맞는 패턴 선택하기

최적의 패턴은 워크로드에 따라 다릅니다. 단일 요청에는 Skills, Handoffs, Router가 효율적입니다. 반복 요청에는 상태를 유지하는 패턴이 40-50%의 호출을 절약하죠. 병렬 실행과 대규모 컨텍스트 도메인에는 Subagents와 Router가 가장 적합합니다.

복잡도를 감수할 가치

Anthropic의 연구는 멀티에이전트 시스템이 이런 상황에서 더 나은 성능을 발휘한다는 것을 보여줍니다. Claude Opus 4를 리드 에이전트로, Claude Sonnet 4를 서브에이전트로 사용한 아키텍처가 내부 리서치 평가에서 싱글에이전트보다 90.2% 더 나은 성과를 냈죠. 별도의 컨텍스트 윈도우를 가진 에이전트들에게 작업을 분산하는 능력이 싱글에이전트로는 달성할 수 없는 병렬 추론을 가능하게 했습니다.

하지만 중요한 원칙은 변하지 않습니다. 싱글에이전트와 좋은 프롬프트 엔지니어링으로 시작하세요. 에이전트를 추가하기 전에 도구를 추가하세요. 명확한 한계에 부딪힐 때만 멀티에이전트 패턴으로 발전시키세요.

참고자료:

• Single-Agent vs Multi-Agent Systems – Analytics Vidhya
• Building effective agents – Anthropic