멀티 에이전트 기본 모델(The Multi-Agent Primitive Model)

2026년에 출시되는 모든 멀티 에이전트 프레임워크(AutoGen, LangGraph, CrewAI, OpenAI Agents SDK, Microsoft Agent Framework)는 4차원 설계 공간 안의 한 점입니다. 원시 요소(primitive)는 네 개뿐입니다. 에이전트(agent), 핸드오프(handoff), 공유 상태(shared state), 오케스트레이터(orchestrator)가 전부입니다. 이 강의에서는 이 네 가지를 0부터 직접 만들고, 장난감 시스템을 네 요소 위에서 돌려본 뒤, 주요 프레임워크를 같은 축 위에 매핑합니다. 그러면 앞으로 나오는 어떤 새 릴리스도 한 문단으로 읽어낼 수 있습니다.

유형: Learn 언어: Python(stdlib) 선수 지식: Phase 14(에이전트 엔지니어링), Phase 16 · 01(왜 멀티 에이전트인가) 예상 시간: 약 60분

문제

6개월에 한 번씩 새로운 멀티 에이전트 프레임워크가 나옵니다. 2023년에는 AutoGen, 2024년에는 CrewAI, 같은 해 LangGraph와 OpenAI Swarm, 2025년 4월에는 Google ADK, 2026년 2월에는 Microsoft Agent Framework RC가 나왔습니다. 보도자료마다 자기네가 "올바른 추상화(the right abstraction)"라고 주장합니다.

이걸 하나씩 따라잡으려고 하면 금방 지칩니다. API는 서로 달라 보이고, 문서마다 "에이전트"가 무엇인지조차 다르게 정의합니다. 어떤 프레임워크는 공유 메모리를 칠판(blackboard)이라 부르고, 다른 곳은 메시지 풀(message pool)이라 부르며, 또 다른 곳은 상태 그래프(StateGraph)라고 부릅니다. 그러다 보면 이 분야가 그냥 이름만 바꿔가며 요동치는 churn처럼 보이기 시작합니다.

하지만 그렇지 않습니다. 마케팅 문구 아래에는 네 가지 원시 요소가 안정적으로 자리잡고 있습니다. 한 번만 제대로 익히면 새 프레임워크가 나와도 한 문단으로 읽어낼 수 있습니다.

개념

네 가지 원시 요소

1. 에이전트(Agent) — 시스템 프롬프트(system prompt)와 도구(tools) 목록입니다. 무상태(stateless)이며, 모든 실행은 시스템 프롬프트와 현재 메시지 이력에서 다시 시작합니다.
2. 핸드오프(Handoff) — 한 에이전트에서 다른 에이전트로 제어권을 구조적으로 넘기는 작업입니다. 기계적으로는 다음 에이전트를 반환하는 도구 호출(tool call)이거나, 조건을 따라가는 그래프 간선(graph edge)으로 구현됩니다.
3. 공유 상태(Shared state) — 둘 이상의 에이전트가 읽을 수 있고, 경우에 따라 쓸 수도 있는 자료구조입니다. 메시지 풀, 칠판, 키-값 저장소(key-value store), 벡터 메모리(vector memory)가 모두 여기에 속합니다.
4. 오케스트레이터(Orchestrator) — 다음에 누가 말할지 결정하는 주체입니다. 선택지는 명시적 그래프(결정적 방식), LLM 화자 선택기(speaker-selector; 유연한 방식), 마지막 화자의 핸드오프 호출(OpenAI Swarm 방식), 큐 위의 스케줄러(scheduler; 스웜 아키텍처) 네 가지입니다.

이것이 설계 공간의 전부입니다. 모든 프레임워크는 각 축에 대해 기본값을 고르고, 나머지는 표면적인 문법 차이일 뿐입니다.

2026년 모든 프레임워크는 이렇게 매핑됩니다

겉으로 보이는 차이는 어마어마합니다. 하지만 그 아래에서는 모두 똑같이 네 개의 손잡이(knob)를 돌리고 있을 뿐입니다.

왜 중요한가

원시 요소가 보이기 시작하면 프레임워크 비교는 짧은 체크리스트로 줄어듭니다.

• 오케스트레이터가 라우팅(routing)을 LLM에 맡기는가(Swarm), 아니면 라우팅을 코드 안에 못 박아 두는가(LangGraph)?
• 공유 상태가 전체 이력(full-history)인가(GroupChat), 아니면 투영된 상태(projected state)인가(StateGraph reducer)?
• 에이전트가 서로의 프롬프트를 바꿀 수 있는가(CrewAI manager), 아니면 핸드오프만 할 수 있는가(Swarm)?

이 세 질문이 주어진 문제에 어떤 프레임워크가 맞는지 80%를 결정합니다. 이제 "최고의 멀티 에이전트 프레임워크"를 쇼핑하는 대신 실제로 중요한 축을 설계하기 시작합니다.

무상태(stateless)에서 얻는 통찰

공유 상태를 제외한 모든 원시 요소는 무상태입니다. 에이전트는 (프롬프트, 도구)의 함수이고, 핸드오프는 함수 호출이며, 오케스트레이터는 스케줄러입니다. 시스템에서 유일하게 상태를 가진 부분은 공유 상태뿐입니다. 흥미로운 버그는 모두 거기서 발생합니다. 메모리 오염(memory poisoning; 15강), 메시지 순서(message ordering), 버전 관리(versioning), 동시 쓰기 경합(write contention)이 대표적입니다.

공유 상태를 숨기는 프레임워크(Swarm)는 이 문제를 호출자에게 떠넘깁니다. 공유 상태를 중앙에 두는 프레임워크(LangGraph 체크포인트, AutoGen 풀)는 검사하기는 쉽지만, 조정 비용을 공유 상태 구현 쪽으로 옮깁니다.

단일 원시 요소의 해부

에이전트(Agent)

Agent = (system_prompt, tools, model, optional_name)

메모리도 없고 상태도 없습니다. 같은 시스템 프롬프트와 도구를 가진 두 에이전트는 서로 교체 가능합니다. 에이전트별 상태처럼 보이는 모든 것은 실제로는 공유 상태나 핸드오프 프로토콜(handoff protocol) 안에 들어 있습니다.

핸드오프(Handoff)

Handoff = (from_agent, to_agent, reason, payload)

지배적인 구현은 세 가지입니다.

• 함수 반환(Function return) — 도구가 다음 에이전트를 반환합니다. OpenAI Swarm 패턴이며, 에이전트는 자신의 도구 스키마(tool schema) 안에 라우팅 정보를 담아 둡니다.
• 그래프 간선(Graph edge) — LangGraph 방식입니다. 간선은 선언적으로 정의되며, LLM이 값을 만들어 내면 조건이 다음 노드(node)를 선택합니다.
• 화자 선택(Speaker selection) — AutoGen GroupChat 방식입니다. 선택기 함수(selector function), 때로는 그 자체가 LLM 호출인 함수가 메시지 풀을 읽고 다음 화자를 고릅니다.

공유 상태(Shared state)

SharedState = { messages: [], artifacts: {}, context: {} }

최소한으로는 메시지 리스트입니다. 더 풍부한 경우에는 구조화된 산출물(structured artifacts; CrewAI Task outputs), 타입이 지정된 컨텍스트(typed context; LangGraph reducers), 외부 메모리(external memory; MCP, vector DB)까지 포함합니다.

두 가지 토폴로지(topology)가 있습니다. 전체 풀(full pool) 방식에서는 모든 에이전트가 모든 메시지를 봅니다. 투영(projected) 방식에서는 에이전트가 자기 역할에 맞춘 뷰(role-scoped view)만 봅니다. 전체 풀은 단순하지만 확장성이 나쁘고, 투영 풀은 확장은 잘 되지만 사전에 스키마 설계(upfront schema design)가 필요합니다.

오케스트레이터(Orchestrator)

Orchestrator = ({state, last_speaker}) -> next_agent

네 가지 방식이 있습니다.

• 정적(Static) — 그래프가 빌드 시점(build time)에 고정됩니다(LangGraph deterministic, CrewAI Sequential).
• LLM 선택(LLM-selected) — LLM이 풀을 읽고 다음 화자를 고릅니다(AutoGen, CrewAI Hierarchical).
• 핸드오프 주도(Handoff-driven) — 현재 에이전트가 핸드오프 도구를 호출해 다음 화자를 결정합니다(Swarm).
• 큐 주도(Queue-driven) — 워커(worker)들이 공유 큐(shared queue)에서 작업을 꺼냅니다. 명시적인 "다음 화자(next-speaker)" 개념이 없습니다(스웜 아키텍처, Matrix).

프레임워크 사이에서 달라지는 것

원시 요소가 고정되면, 남은 설계 결정은 다음과 같습니다.

• 메모리 전략(Memory strategy) — 일시적(ephemeral) 메모리를 쓸 것인가, 영속 체크포인팅(durable checkpointing)을 쓸 것인가(LangGraph checkpointer).
• 안전 경계(Safety boundary) — 누가 핸드오프를 승인하는가(human-in-the-loop).
• 비용 회계(Cost accounting) — 에이전트별 토큰 예산(token budget).
• 관측성(Observability) — 핸드오프 추적(tracing), 재생(replay)을 위한 상태 보존.

이들은 모두 네 원시 요소 위에 얹어 구현할 수 있습니다. 어느 것도 새로운 원시 요소가 아닙니다.

만들어보기

code/main.py는 표준 라이브러리만 사용한 약 150줄짜리 Python 코드로 네 가지 원시 요소를 구현합니다. 실제 LLM은 등장하지 않습니다. 각 에이전트는 미리 작성된 정책(scripted policy)이라, 초점은 조정 구조(coordination structure)에 그대로 남아 있습니다.

이 파일이 노출하는 것은 다음과 같습니다.

• Agent — 이름, 시스템 프롬프트, 도구, 정책 함수를 담은 데이터클래스(dataclass)입니다.
• Handoff — 새 에이전트를 반환하는 함수입니다.
• SharedState — 스레드 안전(thread-safe) 메시지 풀입니다.
• Orchestrator — 세 가지 변형이 있습니다. StaticOrchestrator, HandoffOrchestrator, LLMSelectorOrchestrator(시뮬레이션 버전).

데모는 동일한 세 에이전트 파이프라인(research → write → review)을 세 가지 오케스트레이터 방식으로 모두 실행한 뒤 마지막에 메시지 풀을 출력합니다. 출력에서 달라지는 것은 누가 다음을 고르는가 뿐이며, 에이전트와 공유 상태는 모든 실행에서 동일하다는 사실을 확인할 수 있습니다.

실행 방법:

python3 code/main.py

예상 출력은 세 번의 오케스트레이터 실행이며, 패턴마다 한 번씩 진행되고 마지막에 최종 메시지 풀이 출력됩니다. 핸드오프 주도 방식 실행은 researcher가 일찍 끝났다고 판단하면 도달하는 에이전트 수가 더 적을 수 있습니다. 이것이 바로 LLM 라우팅 트레이드오프(routing tradeoff)의 축소판입니다.

사용해보기

outputs/skill-primitive-mapper.md는 임의의 멀티 에이전트 코드베이스나 프레임워크 문서를 읽고, 네 가지 원시 요소 매핑(primitive mapping)을 돌려주는 스킬(skill)입니다. 새 프레임워크 릴리스를 깊게 파고들기 전에 이 스킬을 한 번 돌려, 한 문단짜리 이해를 먼저 얻어 두세요.

산출물 만들기

새 프레임워크를 도입하기 전에 먼저 그 프레임워크의 원시 요소 매핑을 작성하세요. 매핑이 안 된다면 문서가 부실하거나, 프레임워크가 다섯 번째 원시 요소를 새로 만들어내고 있다는 뜻입니다. 후자는 드뭅니다. 처음 보는 공유 상태(shared-state) 변형이 아닌지 먼저 확인해 보세요.

매핑은 아키텍처 문서(architecture doc)에 못 박아 두세요. 새 팀원이 들어오면 API 문서보다 먼저 이 매핑을 보내세요. 프레임워크 버전이 바뀌면 changelog가 아니라 매핑을 diff하세요.

연습문제

1. (쉬움) code/main.py를 에이전트 정책을 바꿔가며 세 번 실행해 보세요. 오케스트레이터 선택이 어떤 에이전트가 실제로 실행되는지를 어떻게 바꾸는지 관찰하세요.
2. (중간) 네 번째 오케스트레이터 종류를 구현하세요. 에이전트들이 공유 상태에서 작업을 폴링(poll)하는 큐 주도 방식입니다. 어떤 교착(deadlock)이 발생할 수 있고, 그것을 어떻게 감지할 수 있나요?
3. (중간) LangGraph 빠른 시작 문서(https://docs.langchain.com/oss/python/langgraph/workflows-agents)를 네 가지 원시 요소 기준으로 다시 작성해 보세요. LangGraph의 어떤 추상화가 1:1로 매핑되고, 어떤 것이 편의용 래퍼(convenience wrapper)에 해당하나요?
4. (중간) OpenAI Swarm 쿡북(https://developers.openai.com/cookbook/examples/orchestrating_agents)을 읽으세요. Swarm이 네 원시 요소 중 어떤 것을 가장 쓰기 좋게 만들고, 어떤 것은 호출자에게 떠넘기는지 찾아보세요.
5. (어려움) 위 표에서 공유 상태를 완전히 감추는 프레임워크 하나를 찾으세요. 에이전트가 이력을 다시 읽지 않고 핸드오프를 가로질러 협력해야 할 때, 무엇이 깨지는지 설명하세요.

핵심 용어

더 읽을거리

• OpenAI cookbook: Orchestrating Agents — Routines and Handoffs — 핸드오프 주도 오케스트레이션을 가장 명확하게 설명한 자료입니다.
• AutoGen stable docs — GroupChat과 화자 선택이 LLM 선택 방식 오케스트레이션의 기준점이 되는 문서입니다.
• LangGraph workflows and agents — 그래프 간선 기반 오케스트레이션과 리듀서(reducer) 기반 공유 상태 설명입니다.
• CrewAI introduction — 역할-목표-배경(role-goal-backstory) 에이전트와 Sequential / Hierarchical 프로세스 소개입니다.
• AG2 (community AutoGen continuation) — Microsoft가 v0.4를 유지보수(maintenance) 모드로 옮긴 뒤에도 살아 있는 AutoGen v0.2 계열입니다.