• 도서: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust
• 저자의 다른 저서: Observability for LLM Applications — The AI Engineer's Library (2권 시리즈)의 동반 도서
• 나의 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구를 사용하여 작업하는 개발자들을 위한 IDE
• 나: xgabriel.com | GitHub

2026년 4월 2일, Microsoft는 Agent Framework 1.0을 출시했으며, 같은 발표에서 AutoGen을 유지 관리 모드(maintenance mode)로 전환했습니다. Semantic Kernel도 그 뒤를 따랐습니다. VentureBeat는 "]"Microsoft가 AutoGen을 은퇴시키고 통합 및 거버넌스를 위한 Agent Framework를 선보이다(""라는 헤드라인으로 이 소식을 다루었습니다. 만약 그날 아침에 AutoGen 프로젝트를 진행 중이었다면, 이제 마이그레이션(migration)을 해야 합니다.

이는 프레임워크가 요동치는 한 해 동안 발생한 가장 큰 사건이며, 브랜드 이름으로 프레임워크를 생각하는 것을 멈춰야 할 좋은 이유이기도 합니다. 이름은 바뀝니다. 하지만 그 밑에 깔린 멘탈 모델(mental models)은 바뀌지 않습니다. 세 가지 모델이 존재하며, 이를 파악하고 나면 프레임워크를 선택하는 것이 훨씬 쉬워집니다.

10개의 프레임워크가 아닌 세 가지 멘탈 모델

2026년의 모든 멀티 에이전트 프레임워크는 조정(coordination)에 대해 세 가지 방식 중 하나를 제시합니다.

역할과 크루(Roles and crews). 당신은 마치 사람을 채용하는 것처럼 에이전트를 설명합니다. 각 에이전트는 역할, 목표, 배경 이야기를 가집니다. 당신은 그들에게 작업을 부여하고 프로세스를 선택합니다. CrewAI가 이 방식의 가장 명확한 버전입니다.

대화형 에이전트 (Conversational agents). 에이전트들은 중단 조건 (stopping condition)이 발생하거나, 라벨이 지정된 전달 (labeled transfer)을 통해 작업을 넘기기 전까지 차례대로 서로 대화합니다. 이것이 Microsoft Agent Framework에 구현되어 있는 AutoGen 계보이며, OpenAI Agents SDK가 '핸드오프 (handoff)'라고 부르는 원시적인 방식이기도 합니다.

그래프 (Graphs). 흐름을 사전에 그려둡니다. 노드 (Nodes)는 단계이며, 엣지 (edges)는 전이 (transitions)이고, 프레임워크는 그래프를 따라 이동합니다. LangGraph가 이 분야의 기준점이며, Pydantic AI'의 그래프 API도 타입 (types)이 결합된 동일한 개념입니다.

당신이 이미 말로 문제를 설명하는 방식과 일치하는 모델을 선택하세요. 만약

이런 경우에 선택하세요: 제품 소유자(product owner)가 시스템을 하나의 팀으로 설명하고, 업무가 전문화된 작업들로 깔끔하게 분해될 때 선택하세요.

대화형 에이전트 (Conversational agents): AutoGen의 후계자

AutoGen 모델은 그룹 채팅(group chat) 방식이었습니다. 에이전트들은 종료 조건이 발동될 때까지 차례대로 대화를 나누었습니다. 그 루프인 GroupChat은 Microsoft Agent Framework에서 사라졌습니다. 새로운 Workflow API는 그래프(graph) 기반이며, 이는 중요한 점을 시사합니다. 즉, 대화의 계보(conversational lineage)조차도 흐름을 사전에 그려내는 방향으로 이동하고 있다는 것입니다.

살아남은 것은 핸드오프(handoff), 즉 한 에이전트에서 전문가에게 전달되는 라벨이 지정된 전송(labeled transfer)입니다. 라우터(router)가 들어오는 메시지를 읽고, 경로를 결정한 뒤, 작업을 전달합니다. 문제는 마이그레이션(migration) 자체입니다. AutoGen 0.2에서 0.4, 그리고 Agent Framework로의 변화는 18개월 만에 세 번의 파괴적 API(breaking APIs) 변경을 의미하며, GroupChat을 사용하던 코드는 기계적으로 이식되지 않습니다. 코드를 새로 작성해야 합니다.

이런 경우에 선택하세요: 인프라가 Azure이거나, 하나의 코드베이스에서 .NET과 Python의 동등성(parity)이 필요하거나, 감사인(auditor)에게 전달할 수 있는 일급 객체인 OpenTelemetry 스팬(spans)을 원하는 경우입니다. 이 환경 밖에 있는 사람들에게 마이그레이션 비용(migration tax)은 실재하며, 선택의 폭은 좁습니다.

그래프 (Graphs): LangGraph 및 Pydantic AI

그래프는 사전에 더 많은 것을 요구하지만, 그 대가로 내구성(durability)을 제공합니다. LangGraph는 워크플로가 7단계에서 중단되었을 때 1단계가 아닌 7단계부터 재개되어야 하는 경우에 사용합니다. 이는 Postgres 또는 SQLite 체크포인터(checkpointers)와 인간 참여형(human-in-the-loop) 중단 기능을 통해 지원됩니다.

from langchain_anthropic import ChatAnthropic
from langgraph.prebuilt import create_react_agent

...

Pydantic AI는 다른 각도에서 동일한 영역에 도달합니다. 바로 계약으로서의 타입(types)입니다. 모든 프로그램은 출력 타입(output type)에 의해 매개변수화된 Agent이며, 모델의 응답은 해당 타입에 따라 검증되거나 재시도됩니다.

from pydantic import BaseModel
from pydantic_ai import Agent

...

output_type은 설치를 유도하는 핵심적인 부분입니다. 모델은 검증된 객체(validated object)를 반환하거나 깔끔한 예외(exception)를 발생시키며, 코드를 실행하기도 전에 IDE가 형태 불일치(shape mismatch)를 표시해 줍니다. 트레이드오프(trade-off)는 생태계의 규모입니다. Pydantic AI의 그래프 API는 체크포인팅(checkpointing) 및 인터럽트(interrupts) 기능 측면에서 LangGraph보다 아직 초기 단계이므로, 오늘 당장 Postgres 기반의 내구성 있는 상태(durable state) 관리가 필요하다면 LangGraph가 여전히 더 안전한 선택입니다.

그래프(graph)를 선택해야 하는 경우: 당신의 시스템을 정직하게 묘사했을 때, 분기점(branches)과 중단 지점으로부터 재개(resume)가 필요한 파이프라인(pipeline) 구조인 경우입니다.

솔직한 판결

모델 (Model)	프레임워크 (Framework)	강점 (Wedge)	약점 (Weak spot)
역할 (Roles)	CrewAI	"팀"이라는 사고 모델로 가장 빠르게 전환 가능	숨겨진 프롬프팅 (Hidden prompting), 높은 비결정성 (non-determinism)
...
현재 이들이 모두 동의하는 한 가지는 다음과 같습니다: 도구를 위한 MCP와 프레임워크 간 핸드오프(handoffs)를 위한 A2A입니다. CrewAI에서 에이전트를 구축하고, A2A를 통해 Pydantic AI의 에이전트에게 작업을 넘기면, 두 프레임워크는 서로의 존재를 알 필요가 없습니다. 프레임워크 선택의 중요성은 1년 전보다 덜해졌습니다. 왜냐하면 이제 특정 프레임워크를 선택한다고 해서 선택하지 않은 다른 프레임워크를 사용하지 못하는 상황(lock-out)이 발생하지 않기 때문입니다.

멀티 에이전트가 과잉(overkill)인 경우

여기는 벤더들의 발표 자료(vendor decks)에서 생략되는 부분입니다. "멀티 에이전트"라고 라벨링된 대부분의 시스템은 사실 역할 프롬프트(role prompts)를 입고 코스튬을 입은 단일 에이전트일 뿐입니다. Anthropic과 Cognition은 2025년 6월부터 이 문제에 대해 공개적으로 논쟁해 왔으며, 양측 모두 옳습니다. 결정 기준은 당신의 문제가 컨텍스트 윈도우(context window)를 공유할 수 없는 진정한 의미의 병렬 전문화된 전문가(parallel specialists)들로 분해될 수 있느냐 하는 것입니다. 대부분의 프로덕션(production) 시스템에 대한 정직한 답변은 "아니오"입니다.

세 가지 질문을 던져보십시오. 에이전트들이 서로 다른 도구(tools)를 가지고 있습니까, 아니면 단순히 다른 지침(instructions)만 가지고 있습니까? 그들이 별도의 컨텍스트 윈도우에서 병렬로 실행됩니까? 모든 도구를 가진 프롬프트가 잘 작성된 단일 에이전트가 동일한 답을 얻을 수 있습니까? 만약 세 번째 질문의 답이 "예"라면, 당신은 단일 에이전트를 가지고 있는 것입니다.

그리고 단일 에이전트는 종종 순수한 프로바이더 SDK(provider SDK)와 루프(loop)만으로 구성됩니다:

import anthropic

client = anthropic.Anthropic()
...

이는 프레임워크 판매자들이 여러분이 믿고 싶어 하는 것보다 훨씬 더 많은 프로덕션 시스템(production systems)에 충분한 방식입니다. 재시작 시에도 유지되는 내구성이 있는 상태(durable state)가 필요하거나, 프레임워크가 이미 결합되어 있는 생태계 위에서 구축하고 있거나, 혹은 팀원들이 루프(loop)의 구조를 머릿속에 담아두기 어려워 공유된 어휘(shared vocabulary)가 필요한 경우에만 프레임워크를 고려하십시오. 만약 이 중 어느 것도 해당되지 않는다면, 탭을 닫고 루프를 직접 작성하십시오. 그러면 더 빠르게 배포하고 더 저렴하게 디버깅할 수 있을 것입니다.

결정의 핵심은 프레임워크가 아닙니다. 작업의 형태(shape of the work)가 결정의 핵심입니다.

프레임워크는 나타났다 사라지지만, 질문은 항상 동일합니다: 어떤 모델이 문제에 적합한가, 그리고 배포 후 그것이 제대로 작동하고 있다는 것을 어떻게 알 수 있는가. _Agents in Production_은 도구 설계(tool design)부터 핸드오프(handoffs), 그리고 위에서 언급한 트레이드오프(trade-offs)에 이르기까지, 그 답변의 '빌드 및 배포(build-and-ship)' 측면을 다룹니다. _Observability for LLM Applications_는 트레이싱(tracing), 평가(evals), 비용 계산(cost accounting)을 통해 에이전트 팀(crew)이나 단일 루프(single loop)가 실제로 제 역할을 하고 있는지 확인할 수 있게 해주는 나머지 절반의 답변을 제공합니다. 두 권의 책은 모두 _The AI Engineer's Library_를 구성합니다.