에이전트를 어떻게 조직하는가 — Hierarchy·Graph·Swarm·Routing과 회의론

쪼갠 에이전트를 어떻게 조직할 것인가. 네 가지 구조를 살펴보면서 'LLM 스웜은 사실 스웜이 아니다'라는 회의적 논문 한 편을 함께 본다. 결국 구조 선택은 가격에 끌려간다는 게 결론. 시리즈 2편.

조직 방식은 쪼개기 방식을 따라간다

시리즈 1편에서 무엇을 쪼갤 것인지를 다뤘다. Role·Skill·Time·Judge·Planner-Executor. 이번 편은 그다음 질문이다. 쪼갠 단위들을 어떻게 조직할 것인가.

쪼개기 축이 다섯이었다면 조직 구조는 네 가지다. Hierarchy(계층), Graph(그래프), Swarm(스웜), Routing(라우팅). 2026년 2분기 논문들이 이 네 구조 각각을 새로 다듬거나, 비판하거나, 새 버전을 내놓는다.

그리고 이 네 구조 위에 세 가지 관찰이 얹힌다. 더 좋은 모델을 쓸수록 시스템이 더 복잡해진다는 흐름, “LLM 스웜”은 스웜이 아니라는 회의론, 그리고 구조 선택은 독립 변수가 아니라 가격·능력의 종속 변수라는 관찰이다. 3편 앵커에서 던진 “Advisor는 건축이 아니라 가격표다”라는 주장과 2편의 마지막 관찰은 같은 방향을 가리킨다.

네 가지 구조 개요

구조	조직 원리	대표 논문·문서	전제 조건
Hierarchy	상위가 하위를 감독·위임	A Taxonomy of Hierarchical MAS (arxiv 2508.12683)	명확한 감독 체계
Graph (DAG)	미리 정의된 노드·엣지 흐름	From Agent Loops to Structured Graphs (arxiv 2604.11378)	태스크 분해 가능성
Swarm	분산·창발·확장	LLM-Powered Swarms: A New Frontier or a Conceptual Stretch? (arxiv 2506.14496)	세 원리 충족 여부는 논란
Routing / MoE	쿼리별 최적 모델 선택	xRouter (arxiv 2510.08439)	비용-성능 차가 큰 모델 풀

네 구조는 서로 배타적이지 않다. 하나의 production 시스템이 최상위는 Hierarchy, 중간은 Graph, 말단은 Routing 같은 식의 하이브리드를 구성하는 경우가 많다.

Hierarchy — 감독·위임 체계

A Taxonomy of Hierarchical Multi-Agent Systems(arxiv 2508.12683)는 계층형 MAS의 분류학 논문이다. 누가 누구를 감독하는지, 위임은 어느 방향으로 흐르는지, 에스컬레이션은 어떻게 처리되는지를 체계적으로 정리한다.

Hierarchy의 핵심은 상위 에이전트가 하위 에이전트에게 태스크를 할당하고 결과를 검수하는 구조다. AutoGen·MetaGPT에서 익숙한 패턴이다. Role 기반 쪼개기와 가장 잘 맞는 조직 방식이다.

장점은 해석 가능성이다. 조직도를 그리면 누가 책임자인지 명확해진다. 엔터프라이즈 도입에서 감사·규제 요구사항을 맞추기 쉽다. 한계는 상위 에이전트에 병목이 집중된다는 점이다. 상위가 처리하지 못하면 하위 전체가 대기한다. 또한 병렬화가 어렵다. Hierarchy는 본질적으로 동기적 감독 구조에 가깝기 때문이다.

이 한계를 피하려는 시도가 다음 구조다.

Graph — DAG로 조직한다

From Agent Loops to Structured Graphs(arxiv 2604.11378)는 2026년 4월의 가장 최신 관점을 보여준다. 에이전트 실행을 반복 루프가 아니라 구조화된 그래프 위의 스케줄링으로 재정의한다.

이 접근의 전환점은 명확하다. 에이전트가 다음에 무엇을 할지를 매번 프롬프트로 물어 결정하는 loop 구조에서, 미리 정의된 노드·엣지를 따라 흐르는 DAG 구조로 이동한다. LangGraph가 이미 2024년부터 production에서 보여준 방식의 이론적 정리에 가깝다.

Graph 구조가 2026년에 주류가 된 이유는 단순하다. Loop는 디버깅이 어렵다. 매번 다른 경로를 탈 수 있어 동일 입력에 대한 재현 가능성이 낮다. DAG는 경로가 유한하므로 로그로 재현 가능하다.

엔터프라이즈 도입 관점에서 이 차이는 결정적이다. 규제가 필요한 도메인(금융·의료)에서 “왜 이 결정이 나왔는가”를 설명해야 할 때, DAG는 가능하지만 Loop는 거의 불가능하다.

한계는 Graph를 미리 정의해야 한다는 점이다. 새 태스크가 오면 새 Graph가 필요하다. Graph 설계 비용이 누적된다.

Swarm — 분산과 창발, 그리고 회의론

LLM-Powered Swarms: A New Frontier or a Conceptual Stretch?(arxiv 2506.14496)는 이 시리즈에서 가장 도발적인 논문이다. 제목 자체가 질문이다. LLM 스웜은 새 지평인가, 개념의 늘어뜨림인가.

저자들은 고전적 스웜 지능의 세 원리를 기준으로 제시한다.

원리	정의	LLM 스웜 충족도
Decentralization	중앙 통제 없이 개별 에이전트가 국소 정보로 결정	대부분 실패(중앙 coordinator 필요)
Emergence	개별 수준에서 프로그램되지 않은 전체 행동이 발현	대부분 실패(출력은 결정적)
Scalability	수백·수천 에이전트로 자연스럽게 확장	대부분 실패(통신·토큰 비용이 곱으로 증가)

저자들의 결론은 분명하다. 현재 “LLM 스웜”이라 불리는 시스템 대부분은 세 원리를 모두 만족시키지 못한다. 그저 여러 에이전트를 동시에 돌리는 시스템에 스웜이라는 레이블을 붙인 것에 가깝다.

이 논문이 중요한 이유는 결론보다 방법론에 있다. AI 분야에서 “스웜”이라는 단어는 대부분 마케팅 맥락에서 소비돼 왔다. 개념이 느슨해지면 판단 기준이 사라진다. 이 논문은 기준을 다시 세우는 작업이다. X는 스웜인가를 판정할 세 질문을 제공한다. 중앙 coordinator 없이 작동하는가. 개별 수준에서 프로그램되지 않은 전체 행동이 발현되는가. 수백 규모로 확장 가능한가.

2026년 이후 “AI swarm”이라는 단어가 포함된 제안서·제품 설명을 만나면 이 세 질문으로 검증할 수 있다. 대부분 통과하지 못한다.

스웜 개념이 실제로 성립하는 드문 사례는 임베디드 환경이다. Online Automatic Code Generation for Robot Swarms(arxiv 2510.04774, 2025-10)는 수십 대의 로봇이 LLM이 생성한 코드를 자율 실행하며 스웜 동작을 보이는 사례를 기록한다. 물리적으로 분산된 하드웨어가 있을 때 비로소 스웜 원리가 성립한다. LLM 텍스트 agent는 스웜의 세 원리를 충족하기 어렵다는 점이 다시 확인된다.

Routing — 쿼리별로 모델을 고른다

xRouter(arxiv 2510.08439)는 비용 인식 라우팅을 강화학습으로 학습시킨다. 들어오는 쿼리의 특성에 따라 모델 풀(작은 모델부터 큰 모델까지)에서 최적 모델을 선택한다.

이 구조의 조직 원리는 MoE(Mixture of Experts)에서 차용한 것이다. 하나의 큰 모델을 쓰는 대신 여러 전문화된 모델 중 상황에 맞는 것을 고른다. 차이점은 여기서 “전문화”가 모델 크기·가격·도메인에서 온다는 점이다.

라우팅이 2025–2026년에 부상한 이유는 모델 간 가격 차가 커졌기 때문이다. Opus와 Haiku의 가격 비율이 약 19배. 이 격차가 작으면 라우팅은 큰 레버가 아니다. 격차가 크면 라우팅이 가장 강력한 비용 최적화 수단이 된다.

2022–2023년의 모델들은 가격대가 비슷했다. 라우팅할 이유가 약했다. 2025년 이후 모델 라인업이 가격대별로 분화되면서 라우팅의 경제학이 성립했다.

라우팅의 한계는 메타 결정 비용이다. 어느 모델을 쓸까를 판단하는 라우터 자체가 모델이다. 라우터가 너무 똑똑하면 비용 레버가 사라지고, 너무 단순하면 오판이 잦다. 이 균형점을 찾는 것이 xRouter 같은 연구의 본질이다.

네 구조를 한 장면에

flowchart TB
    QUERY["쿼리 / 태스크"]
    QUERY --> H["Hierarchy: 상위가 감독"]
    QUERY --> G["Graph: 사전 정의 DAG"]
    QUERY --> S["Swarm: 분산·창발"]
    QUERY --> R["Routing: 쿼리별 모델 선택"]
    H --> H1["장점: 설명 가능"]
    H --> H2["한계: 병목 집중"]
    G --> G1["장점: 재현 가능"]
    G --> G2["한계: 사전 설계 필요"]
    S --> S1["장점: 확장 가능성"]
    S --> S2["한계: 세 원리 충족 실패"]
    R --> R1["장점: 가격 레버"]
    R --> R2["한계: 메타 결정 비용"]

네 구조가 현실에서 독립적으로 존재하지는 않는다. 다만 각 구조의 전제 조건과 한계가 서로 다르다. 어느 하나가 가장 좋다고 말할 수 없다. 태스크 특성, 규제 요구사항, 모델 가격 구조에 따라 최적 구조가 달라진다.

여기서 세 가지 관찰이 따라 나온다.

능력이 올라갈수록 복잡도가 같이 올라간다

가장 흔한 오해는 이것이다. 모델이 똑똑해지면 시스템은 단순해질 것이다. 하나의 강한 에이전트가 많은 일을 할 테니.

2026년 현실은 정반대다. Claude Opus 4.7이 1M context와 향상된 추론을 제공하지만, 이 모델이 쓰이는 시스템은 더 복잡한 orchestration으로 가고 있다. Advisor·Plan-and-Act·xRouter 모두 모델 하나로 다 하지 않는 방향이다.

세 가지 이유가 겹친다. 가격 레버가 커졌다. Opus가 똑똑해질수록 단가도 높다. 모든 스텝에서 Opus를 쓰기엔 비용이 감당 안 된다. 그래서 쪼개서 일부만 쓴다. 쪼갤수록 시스템은 복잡해진다.

쪼개기 여유가 생겼다. 약한 모델은 큰 덩어리 태스크만 처리 가능했다. 강한 모델은 더 작은 단위로 쪼개도 각 조각이 의미 있는 결과를 낸다. 더 fine-grained 쪼개기가 가능해진 것이다.

평가·감사 요구가 올라갔다. 모델이 실제 production에 들어가면서 “왜 이 결정이 나왔는가”를 설명해야 할 상황이 늘었다. 하나의 블랙박스 에이전트로는 설명이 안 되니 스텝별로 쪼개서 각 스텝의 근거를 기록한다.

이 관찰이 의사결정에 주는 시그널은 분명하다. “더 좋은 모델을 도입하면 시스템이 간단해질 것”이라는 기대는 2026년 현실과 반대다. 더 좋은 모델을 도입하면 더 복잡한 orchestration을 설계할 준비가 필요하다.

컨설팅 관점에서는 모델 업그레이드와 orchestration 설계 리소스를 항상 쌍으로 제안해야 한다. 모델만 교체하고 구조를 그대로 두면 비용이 급증하거나 성능이 기대만큼 오르지 않는다.

LLM 스웜은 스웜이 아니다

앞서 다룬 LLM-Powered Swarms 논문의 핵심 주장을 다시 정리하면 이렇다. 스웜이라는 단어는 고전적으로 decentralization·emergence·scalability 세 원리를 만족하는 시스템에 쓰인다. 현재 “LLM 스웜”이라 불리는 대부분의 시스템은 이 중 하나도 충족하지 못한다.

실무 관점에서 이 회의론은 매우 실용적이다. 2026년 이후 “AI 스웜” 제안서를 받을 때 검증 질문이 명확해진다. 중앙 coordinator가 있는가. 있으면 스웜이 아니다. 개별 에이전트가 프로그램되지 않은 전체 행동을 발현하는가. 결정론적이면 스웜이 아니다. 10개가 아니라 1,000개로 확장 가능한가. 통신 비용이 곱으로 증가하면 스웜이 아니다.

세 질문을 통과하지 못하면 그 시스템은 Hierarchy나 Graph의 마케팅 변형이다. 그 자체가 나쁜 게 아니다. 다만 스웜이 제공한다고 약속하는 특성(확장성·탄력성)을 실제로 제공하지 못한다.

AI 도입 전략 관점에서 이 구분은 재무적 의미가 크다. 스웜을 기대하고 투자했는데 실제로는 Hierarchy인 시스템은 확장 시 비용이 예상의 곱 배로 증가한다.

구조는 독립 변수가 아니다

이 글의 마지막 관찰은 시리즈 3편 앵커와 직접 연결된다.

네 구조(Hierarchy·Graph·Swarm·Routing)는 서로 독립적 선택지처럼 보인다. 태스크에 따라 “이번엔 Graph로 가자”라고 결정할 수 있을 것 같다. 실제로는 아니다. 각 구조는 특정 가격·능력 조건에서만 최적이다.

구조	최적 조건
Hierarchy	상위-하위 모델 간 능력 격차가 클 때
Graph	태스크가 사전 분해 가능하고, 규제·감사 요구가 있을 때
Swarm	다수의 저가 하드웨어가 물리적으로 분산돼 있을 때
Routing	모델 풀의 가격 격차가 5배 이상일 때

이 조건 중 하나라도 바뀌면 최적 구조도 바뀐다.

Opus와 Sonnet의 가격 격차가 줄어들면 Routing의 레버가 약해진다. xRouter식 접근의 ROI가 감소한다. Sonnet 수준의 모델이 Haiku 가격으로 내려오면 기존 Hierarchy의 “비싼 coordinator + 싼 worker” 구조가 무의미해진다. 모두 비슷한 가격이라면 감독 계층의 비용 정당성이 사라진다. 하드웨어 측 AI 에이전트가 보편화되면(실내 로봇 등), 처음으로 Swarm의 세 원리가 실제 성립할 환경이 생긴다.

구조 선택은 경제·물리적 전제 조건의 함수다. 오늘 최적인 구조가 12개월 뒤에도 최적이라는 보장은 없다. 이는 3편 앵커의 “아키텍처가 아니라 가격표”라는 주장의 확장 버전이다.

엔터프라이즈 도입 결정에서는 구조를 고정하는 투자와 구조를 유연하게 두는 투자를 구분해야 한다. 구조 고정형은 특정 구조에 최적화된 커스텀 구현이다. 단기 성능이 높지만 장기 lock-in 위험이 있다. 구조 유연형은 LangGraph·LlamaIndex 같은 일반 프레임워크 위 구현이다. 구조 변경 비용이 낮다.

2026년 현재 구조 고정형의 성능 우위는 크지만, 가격·능력 환경이 빠르게 변하는 점을 고려하면 구조 유연형의 기대값이 더 높다.

마무리 — 조직의 모양은 가격을 따라 변한다

이 글은 시리즈 2편이다. 2026년 Agent Orchestration 연구의 네 가지 구조를 정리하고, 그 위에 세 가지 관찰을 얹었다.

네 구조에는 전제가 있다. 감독 체계, 사전 분해, 분산 원리, 가격 격차. 능력이 올라갈수록 시스템 복잡도도 같이 올라간다. 더 좋은 모델이 더 단순한 시스템을 만들지 않는다. 반대로 간다. LLM 스웜은 스웜이 아니다. 세 원리로 검증하면 대부분 통과 못 한다. 구조는 독립 변수가 아니다. 가격·능력 환경이 바뀌면 최적 구조도 바뀐다.

1편에서 다섯 개의 쪼개기 축을 다뤘고, 이 글에서 네 개의 조직 구조를 다뤘다. 3편 앵커에서 이 모든 것이 역전이라는 하나의 메타 동작으로 수렴한다는 주장을 이미 제시했다.

세 편을 함께 읽으면 2026년 Agent Orchestration이 어떤 풍경인지 한 장면으로 보인다. 쪼개기는 다섯 축으로 퍼져 있고, 용어는 아직 파편화돼 있으며, 시간축은 거의 비어 있다. 조직 구조는 네 가지로 분화돼 있고, 각 구조는 가격·능력 조건에 종속된다. 전체 흐름은 전통적 역할 배치의 역전이며, 그 중심에 있는 Advisor 패턴은 아키텍처가 아니라 가격표다.

이 렌즈로 2026년 나머지와 2027년 상반기의 논문을 읽으면 놀랄 일이 크게 줄어들 것이다. 대부분의 새로운 orchestration 패턴은 셋 중 하나에 속한다. 남은 이분법을 뒤집거나, 가격 환경 변화에 반응하거나, 시간축 공백을 메우거나.

세 방향을 미리 알고 있는 사람에게는 논문을 읽기 전에 결론의 실루엣이 이미 보인다.

시리즈 안내

1편 (쪼개기): 에이전트를 어떻게 쪼개는가 — 2026년 다섯 갈래
2편 (현재 글): 에이전트를 어떻게 조직하는가 — Hierarchy·Graph·Swarm·Routing과 회의론
3편 (앵커): Advisor는 건축이 아니라 가격표다

참고 논문

A Taxonomy of Hierarchical Multi-Agent Systems: Design. arxiv 2508.12683 (2025-08)
From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution. arxiv 2604.11378 (2026-04)
LLM-Powered Swarms: A New Frontier or a Conceptual Stretch? arxiv 2506.14496 (2025-06)
Online Automatic Code Generation for Robot Swarms. arxiv 2510.04774 (2025-10)
xRouter: Training Cost-Aware LLMs Orchestration System via Reinforcement Learning. arxiv 2510.08439 (2025-10)