멀티 에이전트 시스템 구축: 사용해야 할 시점 및 사용 방법

멀티 에이전트 시스템은 여러 개의 LLM 인스턴스가 각각 분리된 대화 컨텍스트를 유지한 채 코드를 통해 조율되는 아키텍처입니다. 여러 개의 조율 패턴(예: 에이전트 스웜, 역량 기반 시스템, 메시지 버스 아키텍처)이 존재하지만, 이 글에서는 리드 에이전트가 특정 하위 작업을 위해 전문화된 서브에이전트를 생성하고 관리하는 계층형 모델인 오케스트레이터-서브에이전트 패턴에 중점을 두고 있습니다. 이 패턴은 비교적 간단한 조정 모델을 제공하며, 멀티 에이전트 시스템을 처음 도입하는 팀에게 좋은 출발점이 됩니다. 다른 패턴들은 다음 글에서 자세히 살펴보겠습니다.

오늘날 멀티 에이전트 시스템은 단일 에이전트가 더 나은 성능을 낼 수 있는 상황에도 자주 활용되지만, 모델 성능이 향상되면서 이러한 판단 기준은 계속 달라지고 있습니다. Anthropic에서는 일부 팀이 정교한 멀티 에이전트 아키텍처를 구축하는 데 몇 달을 투자했지만, 단일 에이전트의 프롬프트만 개선해도 동등한 결과를 달성한다는 사실을 확인했습니다.

멀티 에이전트 시스템을 구축하고, 이를 실제 프로덕션 환경에 배포하는 팀들과 협력한 결과, 여러 에이전트가 단일 에이전트보다 지속적으로 더 나은 성능을 보이는 세 가지 상황을 확인했습니다. 바로, 컨텍스트 오염으로 인해 성능이 저하되는 경우, 작업을 병렬로 실행할 수 있는 경우, 전문화로 도구 선택이나 작업 집중도가 향상되는 경우입니다. 이러한 경우가 아니라면, 일반적으로 조율 비용이 이점보다 커집니다.

이 글에서는 단일 에이전트의 한계를 인식하고, 멀티 에이전트 시스템이 강점을 발휘하는 세 가지 상황을 식별하며, 구현 과정에서 자주 발생하는 실수를 피하는 방법을 살펴봅니다.

단일 에이전트로 시작해야 하는 이유

적절한 도구를 갖춘 잘 설계된 단일 에이전트는 많은 개발자가 예상하는 것보다 훨씬 더 많은 작업을 수행할 수 있습니다.

멀티 에이전트 시스템은 추가적인 부담이 발생합니다. 에이전트가 추가될 때마다 잠재적인 실패 지점이 하나 더 생기고, 유지해야 할 프롬프트도 증가하며, 예상치 못한 동작이 발생할 가능성도 커집니다.

우리는 팀들이 계획, 실행, 검토, 반복을 위해 별도의 에이전트로 구성된 정교한 멀티 에이전트 시스템을 구축했지만, 결국 각 핸드오프 단계에서 컨텍스트가 손실되는 문제를 겪었고, 실행보다 조율에 더 많은 토큰을 사용했다는 사실을 발견했습니다. 테스트 결과, 같은 작업을 수행할 때 멀티 에이전트 구현이 단일 에이전트 방식보다 대체로 3~10배 더 많은 토큰을 사용하는 것으로 나타났습니다. 이러한 추가적인 부담은 에이전트 전반에 컨텍스트를 중복으로 전달해야 하고, 에이전트 간에 조율 메시지가 오가며, 핸드오프를 위해 결과를 요약하는 과정에서 발생합니다.

멀티 에이전트 시스템을 위한 의사 결정 프레임워크

멀티 에이전트 아키텍처는 단일 에이전트가 해결할 수 없는 구체적인 제약 조건을 해결할 때 가치를 제공합니다. 즉, 멀티 에이전트 아키텍처는 추가 비용을 감수할 만큼 명확한 이점을 제공하는 경우에만 적용해야 합니다.

아래의 패턴은 이러한 투자에서 지속적으로 긍정적인 수익을 확인한 사례들입니다.

컨텍스트 보호

대규모 언어 모델은 사용할 수 있는 컨텍스트 창이 제한되어 있어, 컨텍스트가 길어질수록 응답 품질이 저하될 수 있습니다. 에이전트의 컨텍스트에 어떤 하위 작업의 정보가 누적되고, 그 정보가 이후 하위 작업에 필요하지 않을 때 컨텍스트 오염이 발생합니다. 서브에이전트는 각각 특정 작업에만 집중하는 별도의 깨끗한 컨텍스트에서 작동하므로, 이러한 오염을 막는 데 도움이 됩니다.

예를 들어, 기술적 문제를 진단하는 동시에, 주문 기록을 조회해야 하는 고객 지원 에이전트를 고려해 보세요. 주문 조회를 할 때마다, 컨텍스트에 수천 개의 토큰이 추가된다면, 에이전트가 기술적 문제를 추론하는 능력은 떨어지게 됩니다.

‍

단일 에이전트 접근 방식:

에이전트는 컨텍스트 내에 2,000개 이상의 관련 없는 주문 이력 토큰을 유지한 상태에서 기술적 문제를 추론해야 하므로, 집중력이 분산되고 응답 품질이 낮아집니다.

‍

멀티 에이전트 접근 방식:

주문 조회 에이전트는 전체 주문 이력을 처리하고, 요약본을 추출합니다. 메인 에이전트는 실제로 필요한 50~100토큰만 받으므로, 컨텍스트가 집중된 상태를 유지합니다.

컨텍스트 격리는 하위 작업이 많은 양의 컨텍스트(1000토큰 이상)를 생성하지만 그 대부분이 메인 작업과 관련이 없을 때, 추출해야 할 정보에 대한 기준이 분명한 잘 정의된 하위 작업일 때, 그리고 활용 전에 필터링이 필요한 조회나 검색 작업에 특히 효과적입니다.

병렬 처리

여러 에이전트를 병렬로 실행하면 단일 에이전트가 처리할 수 있는 것보다 더 넓은 탐색 공간을 살펴볼 수 있습니다. 이 패턴은 검색과 리서치 작업에서 특히 효과가 큰 것으로 확인되었습니다.

Anthropic의 리서치 기능은 이 접근 방식을 활용합니다. 리드 에이전트가 질의를 분석하고, 서로 다른 측면을 병렬로 조사할 수 있도록 다수의 서브에이전트를 생성합니다. 각 서브 에이전트는 독립적으로 검색을 수행한 다음, 정리된 핵심 결과를 반환합니다. 멀티 에이전트 검색은 더 넓은 정보 공간을 탐색할 수 있기 때문에, 단일 에이전트 방식에 비해 정확도가 크게 향상된 것으로 나타났습니다.

핵심 구현 방식은 질문을 독립적인 여러 측면으로 나누고, 서브 에이전트를 동시에 실행한 뒤, 결과를 종합합니다.

이렇게 탐색 범위가 넓어지면 비용이 따릅니다. 멀티 에이전트 시스템은 동일한 작업을 수행할 때, 단일 에이전트 접근 방식보다 3~10배 더 많은 토큰을 소비합니다. 이는 각 에이전트는 자체 컨텍스트가 필요하고, 에이전트 간 조율을 위해 메시지를 주고받아야 하며, 에이전트 간에 결과를 전달할 때 이를 요약해야 하기 때문입니다. 병렬 처리는 모든 작업을 순차적으로 실행할 때보다 총 실행 시간을 줄이는 데 도움이 되지만, 총 계산량 자체가 크게 증가하기 때문에 멀티 에이전트 시스템은 단일 에이전트 시스템보다 더 오래 걸리는 경우가 많습니다.

병렬 처리의 주요 이점은 속도가 아니라 탐색의 철저함입니다. 방대한 정보 공간을 검색하거나 복잡한 질문의 여러 측면을 조사해야 할 때, 병렬 에이전트는 컨텍스트 제한 내에서 작업하는 단일 에이전트보다 더 많은 범위를 처리할 수 있습니다. 그 대가로 토큰 사용량이 늘어나고, 전체 실행 시간이 더 길어지는 경우도 많지만, 대신 더 포괄적인 결과를 얻을 수 있습니다.

전문화

작업에 따라 적합한 도구 세트, 시스템 프롬프트 또는 전문 분야 지식이 달라질 수 있습니다. 단일 에이전트에 수십 개의 도구를 모두 제공하는 대신, 각 역할에 맞는 도구 세트에 집중한 전문화된 에이전트를 사용하는 것이 신뢰성을 높일 수 있습니다.

도구 세트 전문화

에이전트가 너무 많은 도구에 액세스할 수 있으면, 성능이 저하됩니다. 다음 3가지 신호가 있으면, 도구를 전문화하는 것이 도움이 됩니다.

1. 도구 수 과다: 에이전트가 사용할 수 있는 도구가 너무 많으면(보통 20개 이상) 적절한 도구를 선택하는 데 어려움을 겪습니다.
2. 작업 영역 혼선: 도구가 서로 관련 없는 작업 영역(데이터베이스 작업, API 호출, 파일 시스템 작업)에 걸쳐 있는 경우, 에이전트는 주어진 작업에 어떤 영역의 도구가 적합한지 혼란을 겪습니다.
3. 저하된 성능: 새로운 도구를 추가할수록 기존 작업의 성능이 저하된다면, 이는 에이전트가 도구를 관리할 수 있는 한계에 도달했음을 의미합니다.

시스템 프롬프트 전문화

작업에 따라 서로 다른 페르소나, 제약 또는 지침이 필요하며, 이를 결합하면 충돌이 발생할 수 있습니다. 고객 지원 에이전트는 공감 능력과 인내심을 갖춰야 하고, 코드 리뷰 에이전트는 정확하고 비판적이어야 합니다. 컴플라이언스 점검 에이전트는 규칙을 엄격히 준수해야 하고, 브레인스토밍 에이전트는 창의적인 유연성이 필요합니다. 단일 에이전트가 이렇게 충돌하는 행동 방식 사이를 계속 전환해야 한다면, 작업에 맞게 조정된 시스템 프롬프트를 적용한 전문화된 에이전트로 나누는 것이 더 일관된 결과를 제공합니다.

분야 전문성 특화

일부 작업은 범용 에이전트가 감당하기 어려울 정도로 깊이 있는 전문 분야 컨텍스트가 필요합니다. 법률 분석 에이전트는 판례와 규제 체계에 대한 광범위한 컨텍스트가 필요할 수 있고, 의료 리서치 에이전트는 임상 시험 방법론에 대한 전문 지식이 필요할 수 있습니다. 모든 도메인 컨텍스트를 단일 에이전트로 로드하는 대신, 전문 에이전트는 특정 책임과 관련된 집중된 전문 지식을 보유할 수 있습니다.

예: 멀티플랫폼 통합. 에이전트가 CRM, 마케팅 자동화, 메시징 플랫폼 전반에서 작업해야 하는 통합 시스템을 생각해 보세요. 각 플랫폼에는 관련 API 엔드포인트가 10~15개 있습니다. 40개가 넘는 도구가 있는 단일 에이전트는 올바른 선택을 어려워하는 경우가 많으며 플랫폼 간 유사한 작업을 혼동합니다. 집중된 도구 집합과 맞춤형 프롬프트를 갖춘 전문 에이전트로 분할하면 선택 오류가 해결됩니다.

이 패턴은 효율적이고 전문적인 협업을 미러링합니다. 역할에 맞는 도구를 갖춘 전문가는 모든 영역에서 전문성을 유지하려는 일반론자보다 더 효과적으로 협업합니다. 그러나 전문화는 라우팅을 복잡하게 만듭니다. 오케스트레이터는 요청을 정확하게 분류하고 적절한 에이전트에게 위임해야 하며, 잘못 라우팅하면 좋지 않은 결과로 이어집니다. 또한 전문 에이전트를 여러 개 유지하면 프롬프트 유지보수 오버헤드가 늘어납니다. 전문화는 도메인이 명확하게 분리될 수 있고, 라우팅 결정이 명확할 때 가장 잘 작동합니다.

단일 에이전트 아키텍처의 한계를 넘어서

일반적인 프레임워크 외에도 구체적인 특정 신호는 단일 에이전트 패턴이 한계에 도달했음을 시사합니다:

컨텍스트 한계에 접근하는 중.에이전트가 일상적으로 많은 양의 컨텍스트를 사용하고 성능이 저하되는 경우, 컨텍스트 압력이 병목이 될 수 있습니다. 최근 컨텍스트 관리의 발전(압축과 같은 기능)은 이러한 제한을 줄이고, 단일 에이전트가 훨씬 더 긴 기간에 걸쳐 효과적인 메모리를 유지할 수 있도록 합니다.

많은 도구 관리. 에이전트에게 도구가 15~20개 이상 있으면 모델은 이러한 도구 옵션을 파악하는 데 상당한 컨텍스트와 주의를 기울입니다. 멀티 에이전트 아키텍처를 채택하기 전에, Claude가 모든 정의를 미리 로드하지 않고도 온디맨드 방식으로 동적으로 도구를 검색할 수 있도록 도와주는 도구 검색 도구의 사용을 고려해 보세요. 이를 통해 도구 선택 정확도를 향상시키는 동시에 토큰 사용량을 최대 85%까지 줄일 수 있습니다.

병렬화 가능한 하위 작업. 작업이 자연스럽게 독립적인 조각으로 분해될 때(여러 소스 전반의 리서치, 여러 컴포넌트의 테스트), 병렬 서브 에이전트는 속도를 상당히 높일 수 있습니다.

모델이 개선됨에 따라 이러한 임계값은 변화합니다. 현재 제한은 기본적인 제약이 아닌 실용적인 가이드라인입니다.

컨텍스트 중심 분해

멀티 에이전트 아키텍처를 도입할 때, 가장 중요한 디자인 결정은 에이전트 간에 작업을 분할하는 방식입니다. 우리는 팀에서 작업 분할 방식을 잘못 선택하는 일이 빈번하며, 이는 멀티 에이전트 설계의 이점을 없애는 조정 오버헤드로 이어지는 경우가 많다는 점을 관찰했습니다.

핵심 인사이트는 작업을 분해할 때 문제 중심의 관점이 아니라 컨텍스트 중심의 관점을 채택하는 것입니다.

문제 중심 분해(일반적으로 비생산적). 작업 유형별로 나누면(에이전트 하나는 기능 작성 담당, 다른 에이전트는 테스트 작성 담당, 세 번째 에이전트는 코드 검토 담당) 지속적으로 조정 오버헤드가 발생합니다. 핸드오프할 때마다 컨텍스트가 손실됩니다. 테스트 작성 에이전트는 특정 구현 결정이 내려진 이유에 대한 지식이 부족하고 코드 검토자는 탐색과 반복 작업의 컨텍스트가 부족합니다.

컨텍스트 중심 분해(일반적으로 효과적). 컨텍스트 경계로 나누는 것은 기능을 처리하는 에이전트가 이미 필요한 컨텍스트를 가지고 있기 때문에 테스트도 처리해야 한다는 것을 의미합니다. 컨텍스트를 진정으로 격리할 수 있는 경우에만 작업을 분할해야 합니다.

이 원리는 멀티 에이전트 시스템에서 실패 모드를 관찰한 결과 도출되었습니다. 에이전트가 문제 유형으로 분류되면, 각 핸드오프마다 정보를 앞뒤로 전달하는 '전화 게임'에 참여하게 되어 정보의 충실도가 떨어집니다. 소프트웨어 개발 역할(플래너, 구현자, 테스터, 검토자)별로 전문화된 에이전트를 사용하는 한 실험에서, 서브 에이전트는 실제 작업보다 조정에 더 많은 토큰을 사용했습니다.

효과적인 분해 경계는 다음과 같습니다.

• 독립적인 리서치 경로. '아시아의 시장 동향' 조사와 '유럽의 시장 동향' 조사는 공유 컨텍스트 없이 병렬로 진행할 수 있습니다.
• 깔끔한 인터페이스를 갖춘 별도의 컴포넌트. 명확하게 정의된 API 계약을 통해 프런트엔드와 백엔드 작업이 병렬로 진행될 수 있습니다.
• 블랙박스 검증. 테스트를 실행하고 결과를 보고하기만 하면 되는 검증자는 구현 컨텍스트가 필요하지 않습니다.

문제가 되는 분해 경계는 다음과 같습니다.

• 동일한 작업의 순차적 단계. 동일한 기능의 계획, 구현, 테스트는 너무 많은 컨텍스트를 공유합니다.
• 긴밀하게 결합된 컴포넌트. 지속적으로 주고받기가 필요한 컴포넌트는 동일한 에이전트에 속해야 합니다.
• 공유 상태가 필요한 작업. 이해를 자주 동기화해야 하는 에이전트는 함께 유지해야 합니다.

검증 서브 에이전트 패턴

도메인 전반에서 일관되게 잘 작동하는 멀티 에이전트 패턴 중 하나는 검증 서브 에이전트입니다. 이는 메인 에이전트의 작업을 테스트하거나 검증하는 것을 전적으로 책임지는 전담 에이전트입니다.

Claude Opus 4.5와 같은 더 뛰어난 오케스트레이터 모델은 별도의 검증 단계 없이도 서브 에이전트 작업을 직접 평가하는 능력이 점점 더 향상된다는 점은 주목할 만합니다. 하지만 역량이 떨어지는 오케스트레이터를 사용하거나, 검증에 전문 도구가 필요하거나, 워크플로우에서 명시적인 검증 체크포인트를 적용하려는 경우에 검증 서브 에이전트는 여전히 가치가 있습니다.

검증 서브 에이전트는 전화 게임 문제를 회피하기 때문에 성공합니다. 검증은 본질적으로 최소한의 컨텍스트 전송만 필요하므로, 검증자는 시스템이 빌드된 방식에 대한 전체 기록을 보지 않고 블랙박스 방식으로 시스템을 테스트할 수 있습니다.

구현

메인 에이전트는 작업 단위를 완료합니다. 작업을 진행하기 전에 검증할 아티팩트, 명확한 성공 기준, 검증을 수행할 도구를 갖춘 검증 서브에이전트를 생성합니다.

검증자는 아티팩트가 왜 그대로 빌드되었는지 이해할 필요가 없습니다. 아티팩트가 지정된 기준을 충족하는지 판단하기만 하면 됩니다.

애플리케이션

검증 서브 에이전트는 다음과 같은 경우에 효과적입니다.

• 품질 보증. 테스트 스위트를 실행하고 코드를 린팅하며 스키마와 비교해 출력을 검증합니다.
• 규정 준수 확인. 문서가 정책 요구 사항을 충족하는지 검증하고, 규칙에 따라 출력을 확인합니다.
• 출력 검증. 전달하기 전에 생성된 콘텐츠가 사양을 충족하는지 확인합니다.
• 사실 검증. 별도의 에이전트가 생성된 콘텐츠의 주장이나 인용을 검증하도록 합니다.

성급한 승리 문제

검증 서브 에이전트의 가장 심각한 실패 모드는 철저한 테스트 없이 결과물을 통과로 표시하는 것입니다. 검증자는 테스트를 1~2개 실행하고 통과를 관찰한 뒤 성공을 선언합니다.

완화 전략은 다음과 같습니다.

• 구체적인 기준. '제대로 작동하는지 확인하세요'라고 지정하지 말고 '전체 테스트 스위트를 실행하고 모든 실패를 보고하세요'라고 지정합니다.
• 종합적인 검사. 검증자가 여러 시나리오와 에지 케이스를 테스트하도록 요구합니다.
• 네거티브 테스트. 검증자가 실패해야 하는 입력을 시도하도록 하고 실제로 실패하는지 확인하도록 지시합니다.
• 명시적인 지침. "통과로 표시하기 전에 반드시 전체 테스트 스위트를 실행해야 합니다"라는 지침은 필수입니다. 포괄적인 검증에 대한 명시적인 요구 사항이 없으면, 검증 에이전트는 쉬운 길을 택하는 경향을 보입니다.

앞으로 나아가기

멀티 에이전트 시스템은 강력하지만 보편적으로 적절한 것은 아닙니다. 여러 조정된 에이전트의 복잡성을 추가하기 전에 다음 사항을 확인하세요.

1. 컨텍스트 제한, 병렬화 기회, 전문화 필요성 등 멀티 에이전트가 해결하는 실제 제약이 존재합니다.
2. 분해는 문제 유형이 아닌 컨텍스트를 따릅니다. 작업 종류가 아닌 필요한 컨텍스트로 작업을 그룹화합니다.
3. 서브 에이전트가 전체 컨텍스트 없이도 작업을 검증할 수 있는 명확한 검증 지점이 있습니다.

권장 지침: 가장 간단하게 작동하는 접근 방식으로 시작하고 증거가 뒷받침할 때만 복잡성을 추가하세요.

이는 멀티 에이전트 시스템에 대한 일련의 게시물 중 첫 번째 게시물입니다. 단일 에이전트 패턴에 대한 자세한 내용은 효과적인 에이전트 구축을 참조하세요. 컨텍스트 관리 전략은 AI 에이전트를 위한 효과적인 컨텍스트 엔지니어링을 참조하세요. 멀티 에이전트 리서치 시스템을 구축한 방법에 대해 자세히 알아보려면 멀티 에이전트 리서치 시스템을 구축한 방법에서 확인하세요.

감사의 말

‍

Cara Phillips가 작성했으며, Paul Chen, Andy Schumeister, Brad Abrams 그리고 Theo Chu가 기여했습니다.