멀티 에이전트 패턴

멀티 에이전트 아키텍처 패턴

멀티 에이전트 아키텍처는 각각 고유한 컨텍스트 윈도우를 가진 여러 언어 모델 인스턴스에 작업을 분산합니다. 잘 설계되면 이러한 분산은 단일 에이전트의 한계를 넘는 기능을 가능하게 합니다. 잘못 설계되면 이점을 상쇄하는 조정 오버헤드가 발생합니다. 핵심 통찰은 하위 에이전트가 주로 컨텍스트를 격리하기 위해 존재한다는 것이지, 역할 분할을 의인화하기 위한 것이 아니라는 점입니다.

활성화 시점

다음 상황에서 이 스킬을 활성화하세요:

• 단일 에이전트 컨텍스트 제한이 작업 복잡성을 제약할 때
• 작업이 자연스럽게 병렬 하위 작업으로 분해될 때
• 다른 하위 작업에 서로 다른 도구 세트나 시스템 프롬프트가 필요할 때
• 여러 도메인을 동시에 처리해야 하는 시스템을 구축할 때
• 에이전트 기능을 단일 컨텍스트 한계 이상으로 확장할 때
• 여러 특화 구성 요소를 가진 프로덕션 에이전트 시스템을 설계할 때

다른 스킬이 담당하는 인접 작업에는 이 스킬을 활성화하지 마세요:

• 토폴로지가 결정되기 전의 작업-모델 적합성, 파이프라인 형태, 또는 프로젝트 수준 비용 결정: project-development.
• 호스티드 샌드박스, 웜 풀, 원격 세션, 또는 백그라운드 런타임 인프라 설계: hosted-agents.
• 제어된 런타임에서 KV-캐시 압축을 통한 오케스트레이터 상태 공유: latent-briefing.
• 각 에이전트가 노출하는 도구 설계: tool-design.

핵심 개념

단일 에이전트의 컨텍스트 윈도우가 작업 관련 정보를 모두 담을 수 없을 때 멀티 에이전트 패턴을 사용하세요. 컨텍스트 격리가 주요 이점입니다. 각 에이전트는 다른 하위 작업의 누적된 노이즈 없이 깨끗한 컨텍스트에서 작동하여 반복된 요약을 통해 정보가 저하되는 전화 게임 문제를 방지합니다.

조직적 은유가 아닌 조정 필요성에 따라 세 가지 주요 패턴 중에서 선택하세요:

• 감독자/오케스트레이터 — 작업이 명확하게 분해되고 인간의 감독이 중요한 중앙 집중식 제어에 사용합니다. 단일 코디네이터가 전문가에게 위임하고 결과를 종합합니다.
• 피어투피어/스웜 — 경직된 계획이 역효과를 낳는 유연한 탐색에 사용합니다. 모든 에이전트가 명시적 핸드오프 메커니즘을 통해 다른 에이전트로 제어권을 전송할 수 있습니다.
• 계층 구조 — 계층적 추상화(전략, 계획, 실행)가 있는 대규모 프로젝트에 사용합니다. 각 계층은 고유한 컨텍스트 구조로 다른 세부 수준에서 작동합니다.

모든 멀티 에이전트 시스템을 명시적 조정 프로토콜, 아첨에 저항하는 합의 메커니즘, 그리고 오류 전파 연쇄를 방지하는 장애 처리 방식으로 설계하세요.

상세 주제

멀티 에이전트 아키텍처의 이유

컨텍스트 병목 누적된 기록, 검색된 문서, 도구 출력으로 단일 에이전트의 컨텍스트가 가득 차서 성능이 저하될 때 멀티 에이전트 아키텍처를 사용하세요. 세 가지 저하 신호를 인식하세요: 중간 손실 효과(중간 컨텍스트 콘텐츠에 대한 주의 약화), 주의 희소성(너무 많은 경쟁 항목), 컨텍스트 중독(관련 없는 콘텐츠가 유용한 콘텐츠를 대체).

각 에이전트가 하위 작업에 집중된 깨끗한 컨텍스트에서 작동하도록 여러 컨텍스트 윈도우에 작업을 분할하세요. 어떤 단일 컨텍스트도 전체 부담을 지지 않도록 조정 계층에서 결과를 집계하세요.

토큰 경제 현실 상당히 높은 토큰 비용을 예산에 포함하세요. 프로덕션 데이터에 따르면 멀티 에이전트 시스템은 단일 에이전트 채팅보다 훨씬 더 많은 토큰을 소모할 수 있습니다(claim-multi-agent-token-multiplier):

아키텍처	토큰 승수	사용 사례
단일 에이전트 채팅	기준	간단한 질의
도구를 사용하는 단일 에이전트	기준보다 높음	도구 사용 작업
멀티 에이전트 시스템	기준보다 훨씬 높음	복잡한 연구/조정

브라우징 에이전트 평가 연구는 토큰 사용, 도구 호출, 모델 선택이 성능 변동성을 지배한다고 시사합니다(claim-evaluation-browsecomp-variance). 이는 추가 에이전트가 도움이 될 것이라고 가정하기보다 단일 에이전트 기준과 멀티 에이전트 설정을 측정하는 것을 지지합니다.

아키텍처 설계와 함께 모델 선택을 우선시하세요. 더 나은 모델로 업그레이드하는 것이 토큰 예산을 두 배로 늘리는 것보다 더 큰 성능 향상을 제공하는 경우가 많습니다. BrowseComp 데이터는 모델 품질 개선이 원시 토큰 증가를 능가하는 경우가 많음을 보여줍니다. 모델 선택과 멀티 에이전트 아키텍처를 상호 보완 전략으로 취급하세요.

병렬화 논거 병렬화 가능한 하위 작업을 단일 에이전트에서 순차적으로 처리하는 대신 전용 에이전트에 새 컨텍스트와 함께 할당하세요. 여러 독립 소스에 걸친 검색, 다른 문서 분석, 또는 경쟁 접근 방식 비교가 필요한 연구 작업은 병렬 실행의 이점을 누립니다. 실제 시간은 모든 하위 작업의 합이 아닌 가장 긴 하위 작업의 지속 시간에 가까워집니다.

전문화 논거 각 에이전트가 특정 하위 작업에 필요한 시스템 프롬프트, 도구, 컨텍스트만 갖도록 구성하세요. 범용 에이전트는 가능한 모든 구성을 컨텍스트에 담아야 하므로 주의력이 분산됩니다. 특화된 에이전트는 필요한 것만 담아 해당 도메인에 최적화된 간결한 컨텍스트로 작동합니다. 조정자로부터 특화 에이전트로 라우팅하여 조합 폭발 없이 전문화를 달성하세요.

아키텍처 패턴

패턴 1: 감독자/오케스트레이터 전역 상태와 궤적을 유지하고, 사용자 목표를 하위 작업으로 분해하며, 적절한 작업자로 라우팅하는 중앙 에이전트를 배포합니다.

사용자 질의 -> 감독자 -> [전문가, 전문가, 전문가] -> 집계 -> 최종 출력

다음 경우 이 패턴을 선택하세요: 작업이 명확하게 분해될 때, 도메인 간 조정이 필요할 때, 또는 인간의 감독이 중요할 때.

다음과 같은 트레이드오프를 예상하세요: 엄격한 워크플로 제어와 더 쉬운 인간-인-더-루프 개입이 가능하지만, 감독자 컨텍스트가 병목이 되고, 감독자 오류가 모든 작업자로 연쇄되며, 감독자가 하위 에이전트 응답을 잘못 요약하는 "전화 게임" 문제가 발생합니다.

전화 게임 문제와 해결책 전화 게임 문제로 인해 감독자 아키텍처가 최적화된 버전보다 초기에 약 50% 더 나쁜 성능을 보일 것으로 예상하세요(LangGraph 벤치마크). 감독자가 하위 에이전트 응답을 요약하면서 매 단계마다 충실도가 손실됩니다.

하위 에이전트가 감독자 합성 없이 사용자에게 직접 응답을 전달할 수 있는 forward_message 도구를 구현하여 이를 해결하세요:

def forward_message(message: str, to_user: bool = True):
    """
    감독자 합성 없이 하위 에이전트 응답을 사용자에게 직접 전달합니다.

    다음 경우에 사용:
    - 하위 에이전트 응답이 최종적이고 완전할 때
    - 감독자 합성이 중요한 세부 정보를 잃을 때
    - 응답 형식을 정확히 보존해야 할 때
    """
    if to_user:
        return {"type": "direct_response", "content": message}
    return {"type": "supervisor_input", "content": message}

하위 에이전트가 사용자에게 직접 응답할 수 있을 때는 감독자보다 스웜 아키텍처를 선호하세요. 이는 번역 오류를 완전히 제거합니다.

패턴 2: 피어투피어/스웜 중앙 제어를 제거하고 사전 정의된 프로토콜을 기반으로 에이전트가 직접 통신하도록 합니다. 모든 에이전트가 명시적 핸드오프 메커니즘을 통해 다른 에이전트로 제어권을 전송할 수 있습니다.

def transfer_to_agent_b():
    return agent_b  # 함수 반환을 통한 핸드오프

agent_a = Agent(
    name="Agent A",
    functions=[transfer_to_agent_b]
)

다음 경우 이 패턴을 선택하세요: 작업이 유연한 탐색을 필요로 할 때, 경직된 계획이 역효과를 낼 때, 또는 요구사항이 동적으로 발생하고 사전 분해를 거부할 때.

다음과 같은 트레이드오프를 예상하세요: 단일 실패 지점이 없고 효과적인 너비 우선 확장이 가능하지만, 에이전트 수가 증가함에 따라 조정 복잡성이 증가하고, 중앙 상태 유지자가 없으면 발산 위험이 높아지며, 강력한 수렴 제약 조건이 필수적입니다.

상태 전달이 있는 명시적 핸드오프 프로토콜을 정의하세요. 에이전트가 자신의 컨텍스트 요구 사항을 수신 에이전트에게 전달하도록 보장하세요.

패턴 3: 계층 구조 에이전트를 추상화 계층으로 구성합니다: 전략(목표 정의), 계획(작업 분해), 실행(원자적 작업).

전략 계층 (목표 정의) -> 계획 계층 (작업 분해) -> 실행 계층 (원자적 작업)

다음 경우 이 패턴을 선택하세요: 프로젝트에 명확한 계층 구조가 있을 때, 워크플로에 관리 계층이 포함될 때, 또는 작업이 높은 수준의 계획과 세부 실행을 모두 필요로 할 때.

다음과 같은 트레이드오프를 예상하세요: 명확한 관심사 분리와 다양한 수준에서 다른 컨텍스트 구조 지원이 가능하지만, 계층 간 조정 오버헤드, 잠재적 전략-실행 불일치, 복잡한 오류 전파 경로가 발생합니다.

설계 원칙으로서의 컨텍스트 격리

컨텍스트 격리를 멀티 에이전트 아키텍처의 주요 목적으로 취급하세요. 각 하위 에이전트는 다른 하위 작업의 누적된 컨텍스트를 전달하지 않고 자신의 하위 작업에 집중된 깨끗한 컨텍스트 윈도우에서 작동해야 합니다.

격리 메커니즘 각 하위 작업에 적합한 격리 메커니즘을 선택하세요:

• 전체 컨텍스트 위임 — 플래너의 전체 컨텍스트를 하위 에이전트와 공유합니다. 하위 에이전트가 완전한 이해가 필요한 복잡한 작업에 사용합니다. 하위 에이전트는 자체 도구와 지침을 가지지만 결정을 위해 전체 컨텍스트를 받습니다. 참고: 이는 컨텍스트 격리의 목적을 부분적으로 무효화합니다.
• 지침 전달 — 함수 호출을 통해 지침을 생성합니다. 하위 에이전트는 필요한 것만 받습니다. 간단하고 잘 정의된 하위 작업에 사용합니다. 격리를 유지하지만 하위 에이전트 유연성을 제한합니다.
• 파일 시스템 메모리 — 에이전트가 지속적 저장소를 읽고 씁니다. 공유 상태가 필요한 복잡한 작업에 사용합니다. 파일 시스템이 조정 메커니즘 역할을 하여 공유 상태 전달로 인한 컨텍스트 팽창을 방지합니다. 지연 시간과 일관성 문제를 유발하지만 메시지 전달보다 확장성이 좋습니다.

작업 복잡성, 조정 요구 사항, 허용 가능한 지연 시간에 따라 선택하세요. 기본값은 지침 전달이고, 공유 상태가 필요할 때 파일 시스템 메모리로 확장하세요. 하위 작업이 진정으로 필요하지 않는 한 전체 컨텍스트 위임을 피하세요.

합의와 조정

투표 문제 단순 다수결 투표를 피하세요. 이는 약한 모델의 환각을 강한 모델의 추론과 동등하게 취급합니다. 개입 없이 멀티 에이전트 토론은 동의에 대한 본질적 편향으로 인해 거짓 전제에 대한 합의로 변질됩니다.

가중 투표 에이전트 투표에 신뢰도나 전문성을 가중치로 부여합니다. 신뢰도나 도메인 전문성이 높은 에이전트는 최종 결정에서 더 많은 비중을 가져야 합니다.

토론 프로토콜 에이전트가 여러 라운드에 걸쳐 서로의 출력을 비판하도록 구조화하세요. 적대적 비판은 종종 협력적 합의보다 복잡한 추론에서 더 높은 정확도를 산출합니다. 옳기보다는 좋게 보이기 위해 동의하는 아첨 수렴을 방지하세요.

트리거 기반 개입 행동 마커에 대해 멀티 에이전트 상호 작용을 모니터링하세요. 논의가 진전되지 않을 때 정체 트리거를 활성화하세요. 에이전트가 고유한 추론 없이 서로의 답변을 모방할 때 아첨 트리거를 감지하세요.

프레임워크 고려 사항

다른 프레임워크는 다른 철학으로 이러한 패턴을 구현합니다. LangGraph는 명시적 노드와 엣지가 있는 그래프 기반 상태 머신을 사용합니다. AutoGen은 GroupChat과 함께 대화형/이벤트 기반 패턴을 사용합니다. CrewAI는 계층적 승무원 구조와 함께 역할 기반 프로세스 흐름을 사용합니다.

실용적 지침

실패 모드와 완화

실패: 감독자 병목 감독자가 모든 작업자의 컨텍스트를 축적하여 포화와 저하에 취약해집니다.

작업자가 요약된 결과만 반환하도록 작업자 출력 스키마를 제한하여 완화하세요. 체크포인트를 사용하여 전체 기록을 컨텍스트에 유지하지 않고 감독자 상태를 지속화하세요.

실패: 조정 오버헤드 에이전트 통신이 토큰을 소모하고 지연 시간을 유발합니다. 복잡한 조정은 병렬화 이점을 무효화할 수 있습니다.

명확한 핸드오프 프로토콜을 통해 통신을 최소화하여 완화하세요. 가능하면 결과를 배치 처리하세요. 비동기 통신 패턴을 사용하세요. 멀티 에이전트 조정이 더 긴 컨텍스트의 단일 에이전트보다 실제로 시간을 절약하는지 측정하세요.

실패: 발산 중앙 조정 없이 다른 목표를 추구하는 에이전트가 의도된 목표에서 벗어납니다.

각 에이전트에 대한 명확한 목표 경계를 정의하여 완화하세요. 공유 목표를 향한 진행 상황을 확인하는 수렴 검사를 구현하세요. 무제한 탐색을 방지하기 위해 에이전트 실행에 TTL(Time-To-Live) 제한을 설정하세요.

실패: 오류 전파 한 에이전트 출력의 오류가 해당 출력을 소비하는 다운스트림 에이전트로 전파되어 점점 더 잘못된 결과로 이어집니다.

소비자에게 전달하기 전에 에이전트 출력의 유효성을 검사하여 완화하세요. 회로 차단기가 있는 재시도 로직을 구현하세요. 가능하면 멱등적 작업을 사용하세요. 중요한 출력이 파이프라인에 진입하기 전에 교차 확인하는 검증 에이전트 추가를 고려하세요.

예제

예제 1: 연구팀 아키텍처

감독자
├── 연구자 (웹 검색, 문서 검색)
├── 분석가 (데이터 분석, 통계)
├── 사실 확인자 (검증, 확인)
└── 작가 (보고서 생성, 형식 지정)

예제 2: 핸드오프 프로토콜

def handle_customer_request(request):
    if request.type == "billing":
        return transfer_to(billing_agent)
    elif request.type == "technical":
        return transfer_to(technical_agent)
    elif request.type == "sales":
        return transfer_to(sales_agent)
    else:
        return handle_general(request)

지침

1. 컨텍스트 격리를 멀티 에이전트 시스템의 주요 이점으로 설계하세요
2. 조직적 은유가 아닌 조정 필요성에 따라 아키텍처 패턴을 선택하세요
3. 상태 전달이 있는 명시적 핸드오프 프로토콜을 구현하세요
4. 합의를 위해 가중 투표 또는 토론 프로토콜을 사용하세요
5. 감독자 병목을 모니터링하고 체크포인트를 구현하세요
6. 에이전트 간 전달 전에 출력의 유효성을 검사하세요
7. 무한 루프를 방지하기 위해 TTL(Time-To-Live) 제한을 설정하세요
8. 실패 시나리오를 명시적으로 테스트하세요

주의사항

1. 감독자 병목