멀티 에이전트 7가지 유형,
쓸모 있게 정리하기

SNS 타임라인에 자주 도는 "멀티 에이전트 7가지 패턴". 이름만 다르고 본질은 겹치는 것들이 많다. 실무에 쓸 수 있게 풀어 본다.

SNS에서 "멀티 에이전트 7가지 유형" 같은 카드가 심심하면 한 번씩 돕니다. 이름은 제각각이지만 한 걸음 뒤에서 보면 많은 유형이 겹쳐 있습니다. 이 글의 목적은 두 가지입니다. 첫째, 일곱 가지 이름을 한 번에 정리해서 다시는 단어만 보고 헷갈리지 않게 만드는 것. 둘째, 각 유형이 언제 쓸모 있고 언제 오히려 해가 되는지까지 풀어 두어서 실제로 프로젝트에 적용할 때 참고 가능한 지도가 되는 것입니다.

이 분류가 다루는 것은 "어떻게 여러 AI 에이전트를 하나의 일에 묶을 것인가"입니다. 하나의 에이전트로 다 하면 되는 경우도 많지만, 작업이 커지거나 품질 요구가 높아지면 에이전트를 여러 대 엮어 쓰는 순간이 옵니다. 그때 어떻게 엮느냐가 이 일곱 가지입니다.

01  /  뼈대본질은 두 축이다

본격적인 유형 설명에 들어가기 전에 뼈대부터 짚고 가는 편이 낫습니다. 일곱 가지라는 수에 속지 않으려면 이 두 축을 먼저 머리에 그려 두세요.

일곱 가지 유형은 실제로는 이 두 축의 조합과 변형입니다. 오케스트레이터형은 "위계 + 병렬", 파이프라인형은 "위계 + 순차", 피어 협업형은 "수평 + 병렬"에 가깝습니다. 나머지(토론, 라우팅, 계층, 자기성찰)는 이 조합을 약간 비튼 것이거나 특수 목적으로 특화한 변형입니다. 그래서 새 카드가 떠도 당황하지 말고 이게 어느 축의 조합인가만 물어보면 대부분의 안개가 걷힙니다.

02  /  유형 1오케스트레이터형 — 팀장이 일을 쪼개서 나눠 준다

한 에이전트가 "대장" 역할을 맡고, 작업을 잘게 쪼개서 여러 서브 에이전트에게 병렬로 분배합니다. 대장은 지시와 취합만 하고, 실제 수행은 서브들이 동시에 진행합니다.

오케스트레이터
  ├── 서브A: "1장을 써"
  ├── 서브B: "2장을 써"
  └── 서브C: "3장을 써"
           ↓
       결과 취합

직장 비유는 팀장이 회의록을 보면서 "너는 현황, 너는 문제점, 너는 제안"이라고 동료들에게 분배한 뒤 각자가 써 온 것을 합치는 모습입니다. 각자의 일이 서로 독립적이라면 병렬로 진행할 수 있어 시간이 크게 단축됩니다.

02  /  유형 2파이프라인형 — 공정 라인처럼 한 단계씩

A 에이전트의 출력이 B 에이전트의 입력이 되고, B의 출력이 C의 입력이 되는 순차 구조입니다. 각 단계는 앞 단계의 결과를 받아 다음 단계로 넘깁니다.

리서처 → 요약 → 작성 → 검토 → 최종 출력

직장 비유는 제조 공장의 컨베이어 벨트입니다. 조립 → 검사 → 포장 → 출하. 각 공정은 앞 공정의 결과물 위에서만 일을 합니다. 오케스트레이터형과의 결정적 차이는 동시에 일하느냐(오케스트레이터) 순서대로 일하느냐(파이프라인)입니다.

03  /  유형 3피어 협업형 — 동등한 전문가들의 회의

서로 다른 전문성을 가진 동등한 에이전트들이 같은 문제에 대해 각자 의견을 내고 교환하며 결론으로 수렴합니다. 대장 없이 수평 관계로 진행됩니다.

법무 에이전트 ↔ 기술 에이전트 ↔ 마케팅 에이전트
        (서로 의견 교환 → 충돌 → 수렴 → 결론)

직장 비유는 부서 간 협의회입니다. 새 제품 출시를 앞두고 법무팀·기술팀·마케팅팀이 한 자리에 모여 각자 관점에서 검토 의견을 내고 그것들을 엮어 통합 결론을 만듭니다. 한 사람이 혼자 쓴 보고서보다 각 관점이 충돌하고 수렴한 결과가 품질이 높을 때가 있습니다.

04  /  유형 4토론·검증형 — 변호사 vs 변호사 vs 판사

피어 협업의 특수 변형입니다. 한 에이전트가 초안이나 주장을 내면, 다른 에이전트가 그것을 공격합니다. 반론이 돌아오고, 또 재반론이 이어집니다. 마지막에 심판 역할의 에이전트가 양쪽을 보고 최종 결론을 내립니다.

에이전트A: 초안 작성
에이전트B: "이 부분은 틀렸어, 왜냐면..."
에이전트A: "그 반론에 대한 재반박은..."
에이전트C (심판): 최종 판단

직장 비유는 법정의 변호사·검사·판사 구도, 또는 학술 논문의 동료 심사(peer review) 과정입니다. 일부러 의견을 맞세워서 약점을 찾아내는 구조입니다. 피어 협업형과의 차이는 "협력적 토론"이 아니라 "적대적 검증"이라는 점입니다.

05  /  유형 5전문가 라우팅형 — 콜센터 교환원

한 라우터 에이전트가 먼저 입력을 분석해 적합한 전문 에이전트에게 전달합니다. 각 전문 에이전트는 자기 영역만 다루고, 서로 상호작용하지 않습니다.

라우터 에이전트
  ├── "법무 질문"  → 법무 전문 에이전트
  ├── "코드 질문"  → 코딩 전문 에이전트
  └── "디자인 질문" → 디자인 전문 에이전트

직장 비유는 콜센터 교환원입니다. 고객이 전화를 걸면 교환원이 "아 이건 기술 지원 건이네요, 2번 누르시면 연결됩니다"라고 담당 부서로 연결해 줍니다. 교환원 자신은 기술 지원을 하지 않습니다. 연결만 합니다. 재밌는 점은 이 구조가 대형 LLM 내부의 MoE(Mixture of Experts) 아키텍처와 개념이 같다는 것입니다. 거대 모델이 내부적으로 하는 일을 에이전트 레벨에서 재현한 셈입니다.

06  /  유형 6계층형 — 조직도를 그대로 AI로 옮기다

오케스트레이터 위에 또 오케스트레이터가 있는 구조입니다. 최상위가 중간 오케스트레이터들에게 대분류 작업을 맡기고, 중간들이 다시 각자의 서브 에이전트들에게 세부 작업을 분배합니다.

최상위 오케스트레이터
  ├── 중간 오케스트레이터 A
  │     ├── 서브 A1
  │     └── 서브 A2
  └── 중간 오케스트레이터 B
        ├── 서브 B1
        └── 서브 B2

직장 비유는 대기업 본사·지사·팀 체계를 그대로 옮긴 모습입니다. 복잡해 보이지만 실체는 "본사가 지사에게 지시 → 지사가 팀에 지시 → 팀원이 실제 작업"이라는 익숙한 보고 체계입니다.

07  /  유형 7자기성찰형 — 작가의 퇴고 루프

엄밀히 말하면 "멀티 에이전트"가 아니라 단일 에이전트의 반복 루프이지만, SNS에서는 보통 함께 묶입니다. 한 에이전트가 초안을 만들고, 같은 에이전트(혹은 비평 모드로 전환된 동일 에이전트)가 자기 작업을 비판한 뒤, 그 피드백을 반영해 다시 개선합니다.

에이전트 → 초안 생성
       ↓
에이전트 (비평 모드) → "이 초안의 문제점:"
       ↓
에이전트 (개선 모드) → 수정본
       ↓ (n회 반복)
최종 결과물

직장 비유는 작가의 퇴고 과정입니다. 쓰고 → 다시 읽고 → 고치기를 반복합니다. 혹은 코드 리뷰 문화 중 "셀프 리뷰"가 여기에 해당합니다. 개념적 뿌리는 2023년의 Reflexion 논문과 Self-Refine 기법입니다.

08  /  고르기어떤 때 어떤 유형을 쓰나

실무에서 유형 선택은 "있어 보이는 걸 쓰고 싶다"로 가서는 안 됩니다. 문제의 모양이 먼저고, 유형은 그 모양을 담는 그릇입니다. 다음 질문을 차례로 던져 보면 대체로 답이 나옵니다.

• 작업이 서로 독립적으로 쪼개지는가? → 오케스트레이터형
• 앞 단계 결과가 다음 단계 입력으로 반드시 필요한가? → 파이프라인형
• 정답이 없고 다관점 검토가 필요한가? → 피어 협업형
• 환각 방지와 팩트체크가 절대적으로 중요한가? → 토론·검증형
• 입력의 종류가 다양하고 각각 전문 처리가 필요한가? → 전문가 라우팅형
• 프로젝트가 초대형이고 조직 구조를 반영해야 하는가? → 계층형
• 단일 에이전트의 품질을 한 단계 더 올리고 싶은가? → 자기성찰형

처음 시작하는 분께 권하는 것은 오케스트레이터형과 파이프라인형입니다. 구조가 단순해서 실패 지점이 명확하고, 디버깅이 쉽습니다. 나머지는 이 두 가지로 해결되지 않는 고유한 문제가 있을 때 선택하는 특수 도구에 가깝습니다.

09  /  프레임워크어떤 프레임워크가 어떤 유형에 강한가

유형을 고르고 나면 어떤 프레임워크로 만들지 결정하게 됩니다. 각 프레임워크는 특정 유형에 자연스럽게 맞도록 설계되어 있어서, 강점을 알고 고르는 편이 편합니다.

주의할 점 하나. 프레임워크에 매몰되지 마세요. 문제의 모양에 맞는 유형을 먼저 고르고, 그에 자연스러운 프레임워크를 따라가는 순서가 맞습니다. 유행하는 프레임워크로 시작해 억지로 유형을 맞추면 비용만 늘고 품질은 안 오릅니다.

10  /  맺음결국 본질은 두 축이다

정리하면, 일곱 개 유형은 "있어 보이게" 세분한 측면이 있습니다. 본질은 두 축, 통제 구조(위계 vs 수평)와 실행 순서(병렬 vs 순차)로 충분히 설명됩니다. 나머지는 이 두 축의 변형과 조합입니다.

유형이 먼저가 아니라 문제가 먼저다. 패턴은 이름이 아니라 그릇일 뿐이고, 그릇은 담을 것이 있어야 의미가 있다.

CDSA 전문인재 과정에서도 이 분류를 가르칠 때 우리는 늘 두 축으로 먼저 내립니다. 그다음에 일곱 가지 이름을 붙여 주면 수강생들이 훨씬 덜 헷갈립니다. 현장에서 에이전트 아키텍처를 설계할 때도 같은 순서입니다. 문제의 모양부터 보고, 축을 정하고, 유형을 고르고, 프레임워크를 따라갑니다. 그 반대로 하면 대개 비용만 늘어납니다.

다음 글에서는 이 일곱 가지 중 가장 기본인 오케스트레이터형과 파이프라인형을 Claude Code와 파이썬 수준에서 아주 작게 만들어 보는 실습 루틴을 정리해 보겠습니다. 읽는 것만으로는 한계가 있으니, 한 번쯤 직접 돌려 보는 경험이 필요합니다.