병렬·스웜·네트워크형 아키텍처(Parallel / Swarm / Networked Architectures)

감독자(Supervisor)와 대비되는 구조입니다. 중앙에서 결정을 내리는 주체가 없습니다. 에이전트(Agent)는 공유 이벤트 버스(Shared Event Bus)를 읽어가며 비동기적으로 작업을 가져오고, 결과를 다시 그 버스에 씁니다. LangGraph는 탈중앙·동적 환경(decentralized, dynamic environments)을 위한 "스웜 아키텍처(Swarm Architecture)"를 명시적으로 지원합니다. Matrix(arXiv:2511.21686)는 조율자 병목(orchestrator bottleneck)을 제거하기 위해 제어 흐름(control flow)과 데이터 흐름(data flow)을 모두 분산 큐(distributed queues)를 통과하는 직렬화된 메시지(serialized messages)로 표현합니다. 트레이드오프(tradeoff)는 명확합니다. 확장성(scalability)을 얻는 대신 결정성(determinism)과 추적성(traceability)을 내줍니다. 스웜은 서로 독립적인 하위 문제(sub-problems)가 많은 작업에 적합하며, 하나의 일관된 계획(coherent plan)이 필요한 작업에는 맞지 않습니다.

유형: Learn + Build 언어: Python (stdlib, threading, queue) 선수 지식: Phase 16 · 05 (감독자 패턴, Supervisor Pattern), Phase 16 · 04 (멀티 에이전트 기본 모델, Primitive Model) 예상 시간: 약 75분

문제

감독자(Supervisor) 구조는 워커(Worker)가 몇 개일 때까지는 잘 확장됩니다. 하지만 수백 개 규모라면 어떨까요? 이때는 감독자 자체가 병목(bottleneck)이 됩니다. 누가 무엇을 할지에 대한 모든 결정이 단 하나의 에이전트를 통과해야 하기 때문입니다. 계획 단계(plan step) 하나가 느려지면 시스템 전체가 멈춰버립니다.

스웜 아키텍처는 이 설계를 뒤집습니다. 중앙의 계획자(planner)가 작업을 분배(dispatch)하는 대신, 워커들이 공유 큐(shared queue)에서 직접 작업을 집어 갑니다. "조율(coordination)"은 이벤트 버스(event bus)의 시맨틱(semantics) 안에 녹아 있습니다. 별도의 조율자(orchestrator)는 없으며, 시스템은 큐가 버틸 수 있는 만큼 확장됩니다.

개념

형태

                ┌──── shared queue ────┐
                │                      │
       ┌────────┼────────┐  ◄──────┬───┘
       ▼        ▼        ▼         │
     Worker  Worker  Worker   Worker
      A       B       C        D
       │        │        │         │
       └────────┴────────┴─────────┘
                 │
                 ▼
            results pool

조율자(orchestrator)는 없습니다. 각 워커는 다음 동작을 반복합니다. 큐에서 작업(task)을 하나 가져오고, 처리한 뒤, 결과를 기록합니다(필요하면 후속 작업을 다시 큐에 넣습니다).

스웜이 잘 맞는 경우

• 독립적인 작업이 많을 때. 스크래핑(scraping), 변환(transforming), 분류(classifying)처럼 작업 사이에 의존성이 없는 경우입니다.
• 작업 소요 시간이 들쭉날쭉할 때. 어떤 작업은 100ms, 어떤 작업은 10초가 걸린다면, 스웜은 자동으로 부하(load)를 균형 있게 분배합니다. 빠르게 끝낸 워커가 다음 작업을 가져가기 때문입니다. 감독자 구조에서는 이 소요 시간을 미리 예측해야만 합니다.
• 결정성보다 처리량(throughput)이 중요할 때. 엄격한 순서(ordering)보다 전체 완료 시간이 더 중요한 경우입니다.

스웜이 잘 맞지 않는 경우

• 순서가 있는 워크플로(ordered workflows). 3단계가 2단계의 출력을 필요로 한다면, 스웜에서는 2단계가 끝나기 전에 3단계가 실행될 위험이 있습니다.
• 전역 계획이 필요한 작업(global-plan tasks). 복잡한 연구 질문은 계획자(planner)가 있을 때 유리합니다. 연구자(researcher) 스웜은 일관된 보고서가 아니라 서로 독립적인 사실 조각들만 만들어 냅니다.
• 디버깅(debugging). 중앙 로그(central log)가 없고 작업이 비동기적으로 흘러가므로, 버그를 재현하는 비용이 큽니다.

Matrix(arXiv:2511.21686)

Matrix는 스웜을 자연스러운 끝까지 밀어붙인 2025년 논문입니다. 제어 흐름과 데이터 흐름이 모두 분산 큐 위를 흐르는 직렬화된 메시지로 표현됩니다. 중앙 조율자(central coordinator)는 없습니다. 장애 내성(fault tolerance)은 메시지 내구성(message durability)에서 옵니다. 확장성은 시스템이 아니라 메시지 브로커(message broker)가 풀어야 할 문제로 넘어갑니다.

Matrix의 기여는 새로운 프로그래밍 모델(programming model)입니다. 멀티 에이전트 조율이 "감독자가 다음에 어떤 에이전트를 고를 것인가?"가 아니라 "이 에이전트는 어떤 메시지 토픽(message topic)을 구독(subscribe)하는가?"라는 질문으로 바뀝니다. 그 결과 시스템은 발행/구독 이벤트 메시(pub/sub event mesh)처럼 보이게 됩니다.

LangGraph의 스웜 아키텍처(Swarm Architecture)

LangGraph 2025 docs는 멀티 에이전트 패턴(multi-agent pattern) 중 하나로 "Swarm Architecture"를 명시합니다. 에이전트는 노드(node)이지만, 간선(edge)은 사이클(cycle)을 가진 방향 그래프(directed graph)를 이루고, 어떤 노드든 풀(pool)에서 활성화될 수 있습니다. 워커는 감독자의 배정(assignment)이 아니라 조건(condition)에 따라 처리 가능한 작업을 스스로 골라 갑니다.

실패 모드: 기아(starvation)와 핫스팟(hot-spotting)

모든 워커가 가장 빨리 끝낼 수 있는 작업만 가져가면, 오래 걸리는 작업(long-running task)은 마지막까지 아무도 집어 가지 않게 됩니다. 전형적인 큐 기아(queue starvation) 현상입니다.

완화 방법은 다음과 같습니다.

• 대기 시간(wait time)에 따라 우선순위를 올리는 명시적 에이징(explicit aging)이 적용된 우선순위 큐(priority queue).
• 워커 특수화(worker specialization): 일부 워커는 "긴" 작업만 집어 가도록 둡니다.
• 백프레셔(back-pressure): 큐로 들어오는 빠른 작업의 양을 제한합니다.

콘텐츠 기반 라우팅(content-based routing)과의 연결

스웜은 콘텐츠 기반 라우팅(content-based routing, 22강)과 자연스럽게 짝을 이룹니다. 범용 큐 하나를 쓰는 대신, 메시지 타입(message type)별로 큐를 둡니다. 전문 워커(specialist worker)는 자신이 담당하는 타입만 구독합니다. 이것이 수천 개의 에이전트까지 확장 가능한 메시지 버스 아키텍처(message-bus architectures)의 기반입니다.

직접 만들기

code/main.py는 공유 queue.Queue에서 작업을 가져가는 4개의 워커 스레드(worker thread)로 구성된 스웜을 구현합니다. 작업마다 소요 시간이 다릅니다(빠른 작업과 느린 작업이 섞여 있음). 데모는 다음 세 가지를 비교합니다.

• 순차 기준선(Sequential baseline): 워커 하나가 모든 작업을 직렬(serial)로 처리합니다.
• 고정 배정(Fixed assignment): 각 작업을 특정 워커에게 미리 할당합니다(감독자 스타일, supervisor-style).
• 스웜(Swarm): 워커들이 공유 큐에서 작업을 가져갑니다.

스웜은 부하를 자동으로 균형 잡습니다. 고정 배정 방식은 배정된 작업이 오래 걸리는 동안 빠르게 끝난 워커가 그냥 놀고(idle) 있게 됩니다.

실행:

python3 code/main.py

출력은 워커별 처리 작업 수(스웜은 균등하게 분배하지는 않지만 결과적으로 최적에 가깝게 분배합니다)와 실제 벽시계 시간(wall-clock time)을 보여줍니다.

사용해보기

outputs/skill-swarm-fit.md는 어떤 작업이 스웜에 적합한지 감독자에 적합한지를 평가하는 스킬입니다. 입력은 작업 독립성(task independence), 소요 시간 분산(duration variance), 순서 요구사항(ordering requirements), 디버깅 가능성(debuggability) 요구입니다.

출시하기

체크리스트:

• 에이징이 적용된 우선순위 큐(Priority queue with aging). 긴 작업의 기아를 막습니다.
• 워커 멱등성(Worker idempotency). 워커가 실행 도중 충돌(crash)하면 같은 작업이 한 번 이상 꺼내질 수 있습니다. 따라서 워커는 멱등(idempotent)해야 합니다.
• 내구성 있는 큐(Durable queue). 운영 환경에서는 Kafka, Redis Streams, 데이터베이스 기반 큐(database-backed queue)를 사용합니다. queue.Queue는 메모리 안에서만 동작합니다.
• 작업 단위 관측성(Observability per task). 모든 작업에 추적 ID(trace ID)를 부여하고, 모든 워커가 그 ID와 함께 시작/종료 시점을 기록(log)합니다.
• 백프레셔(Back-pressure). 큐가 워커가 비우는 속도보다 빠르게 커지면, 생산자(producer)의 속도를 늦춥니다.

연습문제

1. code/main.py를 실행하세요. 소요 시간이 들쭉날쭉한 워크로드에서 스웜은 순차 처리보다 얼마나 빠른가요? 고정 배정과 비교하면 얼마나 빠른가요? (쉬움)
2. 우선순위 큐 변형(queue.PriorityQueue 사용)을 추가하세요. 작업의 "importance" 필드(field)로 우선순위를 부여합니다. 지속적인 부하에서 낮은 우선순위 작업이 굶주리는(starve) 일이 발생하는지 관찰하세요. (중간)
3. 핫스팟 탐지기(hot-spot detector)를 구현하세요. 어떤 워커가 가장 느린 워커보다 3배 이상 많은 작업을 처리하면 로그를 남깁니다. 이것은 작업 소요 시간 분포(task-duration distribution)에 대해 무엇을 말해주나요? (중간)
4. Matrix 논문(arXiv:2511.21686)의 abstract와 Section 3을 읽으세요. Matrix가 받아들이는 트레이드오프 하나(확장성 이득)와 포기하는 것 하나(추적성, 결정성)를 찾아내세요. (어려움)
5. 스웜 데모를 (task_type, payload) 튜플(tuple)로 이루어진 queue.Queue로 바꾸고, 워커가 특정 타입만 구독하도록 만드세요. 작업이 이질적(heterogeneous)일 때 어떤 라우팅 규칙(routing rule)이 타당할까요? (어려움)

핵심 용어

더 읽을거리

• LangGraph workflows and agents — Swarm Architecture — 스웜을 명시적으로 지원하는 공식 문서입니다.
• Matrix — A Decentralized Framework for Multi-Agent Systems — 완전한 메시지 패싱(message-passing) 스웜을 제안한 논문입니다.
• Anthropic engineering — why supervisor not swarm in Research — 특정 운영 시스템이 왜 스웜이 아닌 감독자 구조를 명시적으로 선택했는지 설명한 글입니다.
• AutoGen v0.4 actor-model docs — 이벤트 기반(actor-model) 아키텍처로 새로 작성된 버전이며, v0.2의 GroupChat보다 스웜에 더 가깝습니다.