멀티 에이전트 조율 패턴 5가지: 각 방식의 특징과 적합한 상황

이전 글에서는 멀티 에이전트 시스템이 실질적인 가치를 제공하는 경우와 단일 에이전트가 더 나은 선택인 경우를 살펴봤습니다. 이번 글은 멀티 에이전트 시스템을 도입하기로 결정한 팀을 위한 것으로, 문제에 맞는 조율 패턴을 어떻게 선택할지에 초점을 맞춥니다.

많은 팀이 실제 문제에 적합한 패턴보다 겉으로 정교해 보이는 패턴을 선택하는 경향이 있습니다. 저희는 작동 가능한 가장 단순한 패턴부터 시작해, 어디서 한계가 드러나는지 관찰하고, 그에 맞춰 발전시켜 나갈 것을 권장합니다. 이 글에서는 다섯 가지 패턴의 작동 원리와 한계를 살펴봅니다.

• Generator-verifier: 명확한 평가 기준이 있고 결과물의 품질이 중요한 경우
• Orchestrator-subagent: 태스크 분해가 명확하고 서브태스크의 범위가 한정된 경우
• Agent teams: 병렬로 독립적으로 처리 가능한 장시간 서브태스크가 있는 경우
• Message bus: 에이전트 생태계가 계속 확장되는 이벤트 기반 파이프라인의 경우
• Shared-state: 에이전트들이 서로의 발견을 기반으로 협업하는 경우

패턴 1: Generator-verifier

가장 단순한 멀티 에이전트 패턴이자 실제 배포 사례도 가장 많은 패턴입니다. 이전 글에서는 'verification subagent 패턴'으로 소개했지만, 이번 글에서는 보다 넓은 개념인 generator-verifier로 표현합니다. generator가 반드시 오케스트레이터일 필요는 없기 때문입니다.

작동 원리

‍

generator는 태스크를 받아 초기 결과물을 생성하고, 이를 verifier에 전달해 평가를 요청합니다. verifier는 결과물이 요구 기준을 충족하는지 검토한 후, 통과하면 완료로 처리하고 그렇지 않으면 피드백과 함께 반려합니다. 반려된 경우 피드백은 generator로 다시 전달되고, generator는 이를 바탕으로 수정된 결과물을 생성합니다. 이 루프는 verifier가 결과물을 수락하거나 최대 반복 횟수에 도달할 때까지 계속됩니다.

잘 작동하는 경우

고객 문의 티켓에 대한 이메일 응답을 자동 생성하는 고객 지원 시스템을 예로 들어 보겠습니다. generator는 제품 문서와 티켓 내용을 바탕으로 초안을 작성합니다. verifier는 지식 베이스를 기준으로 내용의 정확성을 확인하고, 브랜드 가이드라인에 따라 말투를 검토하며, 티켓에서 제기된 모든 문제가 응답에 포함됐는지 점검합니다. 검토를 통과하지 못하면 구체적인 문제점(예: 가격 티어 오기재, 미응답 이슈 등)을 명시한 피드백과 함께 generator로 반환됩니다.

결과물의 품질이 중요하고 평가 기준을 명확히 정의할 수 있을 때 이 패턴을 사용하세요. 코드 생성(한 에이전트가 코드를 작성하고 다른 에이전트가 테스트를 작성·실행), 팩트 체킹, 루브릭 기반 채점, 컴플라이언스 검증, 그리고 잘못된 결과물의 비용이 추가 생성 비용보다 큰 모든 영역에서 효과적입니다.

한계

verifier의 성능은 기준의 품질에 달려 있습니다. "결과물이 좋은지 확인하라"는 식의 모호한 지시만 받은 verifier는 generator의 결과물을 그냥 통과시킵니다. 많은 팀이 루프를 구현하면서도 '검증이 무엇을 의미하는지'를 정의하지 않는 실수를 범하는데, 이는 실질적인 품질 관리 없이 품질 관리가 되는 것처럼 보이는 착시를 만들어 냅니다. (이 '섣부른 성공' 문제는 이전 글에서 다뤘습니다.)

이 패턴은 생성과 검증이 분리 가능한 별개의 능력이라는 전제 위에 성립합니다. 창의적인 접근법을 평가하는 것이 생성하는 것만큼 어렵다면, verifier가 문제를 안정적으로 잡아낸다는 보장이 없습니다.

반복 루프가 교착 상태에 빠질 수도 있습니다. generator가 verifier의 피드백을 반영하지 못하면 수렴 없이 진동만 반복됩니다. 최대 반복 횟수 제한과 대체 전략(사람에게 에스컬레이션하거나 최선의 결과물을 주의사항과 함께 반환)을 함께 설정해야 무한 루프를 방지할 수 있습니다.

패턴 2: Orchestrator-subagent

위계 구조가 이 패턴의 핵심입니다. 한 에이전트가 팀 리더 역할을 맡아 작업을 계획하고, 태스크를 위임하며, 결과를 종합합니다. 서브에이전트들은 각자 맡은 역할을 수행하고 결과를 보고합니다.

작동 원리

리드 에이전트는 태스크를 받아 접근 방식을 결정합니다. 일부 서브태스크는 직접 처리하고, 나머지는 서브에이전트에 위임합니다. 서브에이전트는 작업을 완료하고 결과를 반환하며, 오케스트레이터는 이를 종합해 최종 결과물을 만듭니다.

Claude Code가 이 패턴을 사용합니다. 메인 에이전트는 코드 작성, 파일 편집, 명령 실행을 직접 수행하면서, 대규모 코드베이스 검색이나 독립적인 사안 조사가 필요할 때는 백그라운드에서 서브에이전트를 실행합니다. 이를 통해 결과가 돌아오는 동안에도 작업을 계속 진행할 수 있습니다. 각 서브에이전트는 독립된 컨텍스트 윈도우에서 동작하며 핵심 내용만 추려 반환합니다. 덕분에 오케스트레이터의 컨텍스트는 주요 태스크에 집중하면서, 탐색 작업은 병렬로 처리할 수 있습니다.

잘 작동하는 경우

자동화된 코드 리뷰 시스템을 예로 들어 보겠습니다. 풀 리퀘스트(PR)가 들어오면 보안 취약점 점검, 테스트 커버리지 확인, 코드 스타일 평가, 아키텍처 일관성 검토가 필요합니다. 각 항목은 서로 독립적이고, 서로 다른 컨텍스트를 요구하며, 명확한 결과물을 냅니다. 오케스트레이터는 각 항목을 전문 서브에이전트에 위임하고, 결과를 수집해 통합 리뷰를 작성합니다.

태스크 분해가 명확하고 서브태스크 간 의존성이 최소화된 경우에 이 패턴을 사용하세요. 오케스트레이터는 전체 목표에 대한 일관된 시각을 유지하고, 서브에이전트는 각자의 역할에 집중할 수 있습니다.

한계

오케스트레이터가 정보 병목이 될 수 있습니다. 한 서브에이전트가 다른 서브에이전트의 작업에 영향을 미치는 정보를 발견하더라도, 그 정보는 반드시 오케스트레이터를 거쳐야 전달됩니다. 예를 들어 보안 서브에이전트가 아키텍처 분석에 영향을 미치는 인증 결함을 발견했다면, 오케스트레이터가 이 의존 관계를 파악하고 정보를 적절히 전달해야 합니다. 이런 핸드오프가 여러 번 반복되다 보면 중요한 세부 정보가 유실되거나 요약 과정에서 사라지는 경우가 많습니다.

순차 실행도 처리 속도를 제한합니다. 명시적으로 병렬화하지 않으면 서브에이전트는 하나씩 순서대로 실행되므로, 속도 이점 없이 멀티 에이전트의 토큰 비용만 발생합니다.

패턴 3: Agent teams

작업이 오랜 시간 독립적으로 처리 가능한 병렬 서브태스크로 분해될 때, orchestrator-subagent 패턴은 불필요하게 제약적으로 느껴질 수 있습니다.

작동 원리

코디네이터는 여러 워커 에이전트를 독립 프로세스로 실행합니다. 팀원(teammate) 에이전트들은 공유 큐에서 태스크를 가져와 자율적으로 여러 단계를 거쳐 처리하고, 완료 신호를 보냅니다.

orchestrator-subagent 패턴과의 차이는 워커의 지속성에 있습니다. orchestrator-subagent에서는 오케스트레이터가 서브에이전트를 단일 서브태스크에 한해 실행하고, 서브에이전트는 결과를 반환한 후 종료됩니다. 반면 팀원 에이전트는 여러 태스크에 걸쳐 살아있으면서 컨텍스트와 도메인 전문성을 축적하고, 이를 통해 시간이 지날수록 성능이 향상됩니다. 코디네이터는 작업을 할당하고 결과를 수집하지만, 태스크 사이에 워커를 초기화하지 않습니다.

잘 작동하는 경우

대규모 코드베이스를 다른 프레임워크로 마이그레이션하는 경우를 예로 들어 보겠습니다. 각 팀원 에이전트는 독립적으로 서비스를 마이그레이션하며, 자체 의존성, 테스트 스위트, 배포 설정을 처리합니다. 코디네이터는 각 서비스를 팀원에게 배정하고, 팀원은 자율적으로 마이그레이션을 진행합니다. 의존성 업데이트, 코드 변경, 테스트 수정, 검증을 모두 스스로 처리하는 방식입니다. 코디네이터는 완료된 마이그레이션을 수집하고 전체 시스템에 대한 통합 테스트를 실행합니다.

서브태스크가 독립적이고 지속적인 다단계 작업의 이점을 살릴 수 있을 때 이 패턴을 사용하세요. 각 팀원은 매번 새로 시작하는 대신 담당 도메인에 대한 컨텍스트를 축적합니다.

한계

독립성이 핵심 전제 조건입니다. orchestrator-subagent에서는 오케스트레이터가 서브에이전트 사이의 중재자 역할을 하며 정보를 전달할 수 있지만, 팀원 에이전트는 자율적으로 동작하기 때문에 중간 결과를 쉽게 공유하지 못합니다. 한 팀원의 작업이 다른 팀원의 작업에 영향을 미쳐도 서로 알 수 없고, 결과물이 충돌할 수 있습니다.

완료 감지도 까다롭습니다. 팀원들은 각기 다른 시간 동안 자율적으로 작업하기 때문에, 코디네이터는 한 팀원이 2분 만에 끝나고 다른 팀원이 20분이 걸리는 상황처럼 부분 완료 상태를 처리해야 합니다.

공유 리소스는 두 문제를 더욱 악화시킵니다. 여러 팀원이 동일한 코드베이스, 데이터베이스, 파일 시스템을 사용할 경우 같은 파일을 동시에 수정하거나 서로 양립할 수 없는 변경을 가할 수 있습니다. 이 패턴을 적용하려면 태스크 분할과 충돌 해결 메커니즘을 신중하게 설계해야 합니다.

패턴 4: Message bus

에이전트 수가 늘어나고 상호작용 패턴이 복잡해질수록 직접 조율 방식은 관리하기 어려워집니다. Message bus는 에이전트들이 이벤트를 발행(publish)하고 구독(subscribe)할 수 있는 공유 통신 레이어를 도입합니다.

작동 원리

에이전트는 publish와 subscribe라는 두 가지 기본 동작으로 상호작용합니다. 에이전트는 관심 있는 토픽을 구독하고, 라우터는 일치하는 메시지를 해당 에이전트에 전달합니다. 새로운 기능을 가진 에이전트가 추가되더라도 기존 연결을 변경하지 않고 관련 작업을 받기 시작할 수 있습니다.

잘 작동하는 경우

보안 운영 자동화 시스템이 이 패턴의 장점을 잘 보여주는 사례입니다. 여러 소스에서 알림이 들어오면 트리아지(triage) 에이전트가 심각도와 유형별로 분류합니다. 심각도가 높은 네트워크 알림은 네트워크 조사 에이전트로, 자격 증명 관련 알림은 신원 분석 에이전트로 라우팅됩니다. 각 조사 에이전트는 컨텍스트 수집 에이전트에 보강 요청을 발행할 수 있습니다. 수집된 결과는 대응 조율 에이전트로 전달되어 적절한 조치가 결정됩니다.

이 파이프라인이 message bus에 적합한 이유는 이벤트가 단계별로 흘러가고, 위협 유형이 진화함에 따라 새로운 에이전트 유형을 추가하기 쉬우며, 에이전트를 독립적으로 개발·배포할 수 있기 때문입니다.

워크플로가 사전에 정해진 순서가 아닌 이벤트로부터 자연스럽게 형성되는 이벤트 기반 파이프라인에, 그리고 에이전트 생태계가 계속 성장할 가능성이 있는 상황에 이 패턴을 사용하세요.

한계

이벤트 기반 통신의 유연성은 추적을 어렵게 만듭니다. 알림 하나가 다섯 에이전트에 걸친 이벤트 연쇄를 일으킬 경우, 무슨 일이 있었는지 파악하려면 세밀한 로깅과 상관관계 분석이 필요합니다. 오케스트레이터의 순차적 결정을 따라가는 것보다 디버깅이 훨씬 어렵습니다.

라우팅 정확도도 중요합니다. 라우터가 이벤트를 잘못 분류하거나 누락시키면 시스템은 조용히 실패합니다. 아무것도 처리하지 않지만 에러도 발생하지 않는 것입니다. LLM 기반 라우터는 의미론적 유연성을 제공하지만, 그 자체의 실패 모드를 수반합니다.

패턴 5: Shared state

앞서 소개한 패턴들의 오케스트레이터, 팀 리더, 메시지 라우터는 모두 정보 흐름을 중앙에서 관리합니다. Shared state는 이 중간자를 없애고, 에이전트들이 모두 읽고 쓸 수 있는 영속적인 저장소를 통해 직접 조율하게 합니다.

작동 원리

에이전트들은 자율적으로 공유 데이터베이스, 파일 시스템, 또는 문서를 읽고 씁니다. 중앙 코디네이터는 없습니다. 에이전트들은 저장소에서 관련 정보를 확인하고, 발견한 것을 바탕으로 행동하며, 결과를 다시 저장소에 기록합니다. 작업은 보통 초기화 단계에서 저장소에 질문이나 데이터셋을 심는 것으로 시작되고, 종료 조건(시간 제한, 수렴 임계값, 또는 지정 에이전트가 충분한 답이 모였다고 판단하는 시점)이 충족되면 끝납니다.

잘 작동하는 경우

복잡한 질문의 여러 측면을 여러 에이전트가 분담해 조사하는 리서치 종합 시스템을 예로 들어 보겠습니다. 한 에이전트는 학술 문헌을 탐색하고, 다른 에이전트는 업계 보고서를 분석하며, 세 번째 에이전트는 특허 출원을 검토하고, 네 번째는 뉴스 보도를 모니터링합니다. 각 에이전트의 발견은 다른 에이전트의 조사 방향에 영향을 줄 수 있습니다. 예를 들어 학술 문헌 에이전트가 핵심 연구자를 발견하면, 업계 에이전트가 그 연구자의 회사를 더 면밀히 조사할 수 있습니다.

Shared state에서는 발견한 내용이 곧바로 저장소에 기록됩니다. 업계 에이전트는 코디네이터의 중계를 기다리지 않고 학술 에이전트의 발견을 즉시 확인할 수 있습니다. 에이전트들은 서로의 작업 위에 계속 쌓아 나가고, 공유 저장소는 진화하는 지식 베이스가 됩니다.

Shared state는 코디네이터라는 단일 장애점도 제거합니다. 에이전트 하나가 멈춰도 나머지는 저장소를 계속 읽고 씁니다. 오케스트레이터나 메시지 버스 시스템에서는 코디네이터나 라우터가 실패하면 전체가 멈춥니다.

한계

명시적인 조율이 없으면 에이전트들이 같은 작업을 중복하거나 서로 상충되는 방식으로 접근할 수 있습니다. 두 에이전트가 독립적으로 동일한 단서를 조사하는 경우가 생길 수 있습니다. 에이전트 간 상호작용에서 시스템 동작이 발생하기 때문에, 결과를 예측하기 어렵습니다.

더 심각한 실패 유형은 반응 루프입니다. 예를 들어 에이전트 A가 발견을 기록하고, 에이전트 B가 그것을 읽어 후속 내용을 쓰고, 에이전트 A가 후속 내용을 보고 다시 응답하는 식으로 계속되는 것입니다. 시스템이 수렴하지 않는 작업에 토큰을 계속 소모하게 됩니다. 중복 작업이나 동시 쓰기는 잠금(locking), 버전 관리, 파티셔닝 같은 공학적 해법이 있습니다. 반응 루프는 동작 차원의 문제이므로, 종료 조건을 명시적으로 설계해야 합니다. 즉, 시간 예산, 수렴 임계값(N 사이클 동안 새로운 발견 없음), 또는 저장소에 충분한 답이 모였는지 판단하는 전담 에이전트가 필요합니다. 종료 조건을 후순위로 미룬 시스템은 무한히 반복되거나, 한 에이전트의 컨텍스트가 가득 찼을 때 임의로 멈추는 경향이 있습니다.

패턴 선택과 전환

적합한 패턴은 시스템의 구조적 특성에 달려 있습니다. 이전 글에서 저희는 에이전트가 수행하는 작업 유형이 아니라 각 에이전트에 필요한 컨텍스트를 기준으로 작업을 분해하는 '컨텍스트 중심 분해'를 제안한 바 있습니다. 이 원칙은 여기서도 동일하게 적용됩니다. 각 패턴의 차이는 컨텍스트 경계와 정보 흐름을 어떻게 관리하느냐에 있습니다.

Orchestrator-subagent vs. agent teams

두 패턴 모두 코디네이터가 다른 에이전트에 작업을 위임하는 구조입니다. 핵심 질문은 워커가 얼마나 오래 컨텍스트를 유지해야 하는가입니다.

• Orchestrator-subagent를 선택하세요: 서브태스크가 짧고 집중적이며 명확한 결과물을 내는 경우입니다. 코드 리뷰 시스템이 여기에 적합한데, 각 검토 항목이 분석을 실행하고 보고서를 생성한 후 단일 실행 범위 안에서 반환되기 때문입니다. 서브에이전트가 여러 사이클에 걸쳐 컨텍스트를 유지할 필요가 없습니다.
• Agent teams를 선택하세요: 서브태스크가 지속적인 다단계 작업의 이점을 살릴 수 있는 경우입니다. 코드베이스 마이그레이션이 여기에 적합한데, 각 팀원이 담당 서비스(의존성 그래프, 테스트 패턴, 배포 설정)에 대한 실질적인 친숙도를 쌓기 때문입니다. 이렇게 축적된 컨텍스트는 단발성 위임으로는 재현할 수 없는 성능 향상을 가져옵니다.

서브에이전트가 실행 사이에 상태를 유지해야 한다면 agent teams가 더 적합합니다.

Orchestrator-subagent vs. message bus

두 패턴 모두 다단계 워크플로를 처리할 수 있습니다. 핵심 질문은 워크플로 구조가 얼마나 예측 가능한가입니다.

• Orchestrator-subagent를 선택하세요: 단계의 순서가 사전에 정해져 있는 경우입니다. 코드 리뷰 시스템은 PR 수신 → 검토 실행 → 결과 종합이라는 고정된 파이프라인을 따릅니다.
• Message bus를 선택하세요: 워크플로가 이벤트로부터 자연스럽게 형성되고 발견 내용에 따라 달라질 수 있는 경우입니다. 보안 운영 시스템은 어떤 알림이 들어올지, 어떤 조사 경로가 필요할지 예측하기 어렵습니다. 새로운 알림 유형이 나타나면 새로운 처리 방식도 필요해집니다. Message bus는 사전에 정해진 순서 대신 이벤트를 처리 가능한 에이전트에 라우팅함으로써 이런 다양성을 수용합니다.

오케스트레이터에 점점 더 많은 조건 로직이 쌓여 다양한 케이스를 처리하게 된다면, message bus가 그 라우팅을 명시적이고 확장 가능하게 만들어 줍니다.

Agent teams vs. shared state

두 패턴 모두 에이전트가 자율적으로 작업합니다. 핵심 질문은 에이전트들이 서로의 발견을 필요로 하는가입니다.

• Agent teams를 선택하세요: 에이전트들이 상호작용하지 않는 별도의 파티션을 담당하는 경우입니다. 코드베이스 마이그레이션이 여기에 적합한데, 각 팀원이 담당 서비스를 처리하고 코디네이터가 마지막에 결과를 합치는 구조입니다.
• Shared state를 선택하세요: 에이전트의 작업이 협업적이고 발견 내용이 실시간으로 흘러야 하는 경우입니다. 리서치 종합 시스템이 더 잘 맞는데, 학술 에이전트가 핵심 연구자를 발견하는 즉시 업계 에이전트의 조사에 반영될 수 있기 때문입니다.

팀원 에이전트들이 최종 결과만 공유하는 것을 넘어 서로 소통해야 한다면, shared state가 더 자연스러운 선택입니다.

Message bus vs. shared state

두 패턴 모두 복잡한 멀티 에이전트 조율을 지원합니다. 핵심 질문은 작업이 개별 이벤트로 흐르는가, 아니면 공유 지식 베이스에 누적되는가입니다.

• Message bus를 선택하세요: 에이전트들이 파이프라인에서 이벤트에 반응하는 경우입니다. 보안 운영 시스템은 알림을 단계별로 처리하며, 각 이벤트가 완료되기 전에 다음 이벤트를 트리거합니다. 이 패턴은 이벤트를 처리 가능한 에이전트에 효율적으로 라우팅합니다.
• Shared state를 선택하세요: 에이전트들이 시간이 지나면서 축적된 발견을 기반으로 작업을 쌓아 나가는 경우입니다. 리서치 종합 시스템은 지식을 지속적으로 수집합니다. 에이전트들은 저장소를 반복적으로 참조하면서 다른 에이전트의 발견을 확인하고 조사 방향을 조정합니다.

Message bus에는 여전히 라우터라는 중앙 컴포넌트가 존재해 이벤트의 행선지를 결정합니다. Shared state는 탈중앙화 구조입니다. 단일 장애점 제거가 우선순위라면 shared state가 그 목표를 더 완전하게 달성합니다.

Message bus 시스템에서 에이전트들이 행동을 트리거하는 것이 아니라 발견을 공유하기 위해 이벤트를 발행하고 있다면, shared state가 더 적합한 선택입니다.

시작하기

실제 프로덕션 시스템은 여러 패턴을 결합하는 경우가 많습니다. 대표적인 혼합 방식으로는 전체 워크플로에 orchestrator-subagent를 적용하면서 협업이 집중적인 서브태스크에는 shared state를 사용하는 것이 있습니다. 또 다른 방식은 이벤트 라우팅에 message bus를 쓰면서 각 이벤트 유형을 agent teams 방식의 워커가 처리하도록 하는 것입니다. 이 패턴들은 상호 배타적인 선택지가 아니라 조합 가능한 빌딩 블록입니다.

아래 표는 각 패턴이 적합한 상황을 정리한 것입니다.

대부분의 사용 사례에서는 orchestrator-subagent부터 시작할 것을 권장합니다. 조율 오버헤드를 최소화하면서 가장 넓은 범위의 문제를 처리할 수 있는 패턴입니다. 어디서 한계가 드러나는지 관찰하고, 구체적인 필요가 명확해지면 그에 맞는 다른 패턴으로 전환하세요.

‍앞으로 이어질 글에서는 각 패턴을 실제 프로덕션 구현 사례와 함께 심층적으로 살펴볼 예정입니다. 멀티 에이전트 시스템이 투자할 만한 가치가 있는지에 대한 배경 지식은 멀티 에이전트 시스템 구축: 언제, 어떻게 활용할 것인가를 참고하세요.