• 도서: 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도 그 뒤를 따랐습니다. 세 개의 중복되는 프로젝트가 안정적인 API와 장기 지원(long-term support)을 갖춘 하나의 패키지로 통합되었습니다. Microsoft는 이 움직임을 통합(consolidation)이라고 설명했습니다. 만약 당신이 그날 아침 AutoGen 프로젝트를 운영하고 있었다면, 자고 일어났을 때 마이그레이션(migration) 과제를 마주하게 된 것입니다.

이것이 이 카테고리 전체의 형상입니다. 오늘 당신이 선택하는 프레임워크 지형은 1년 전에 선택했던 지형이 아니며, 내년에 선택하게 될 지형도 아닐 것입니다. 따라서 유용한 질문은 "어떤 프레임워크가 최고인가"가 아닙니다. "어떤 프레임워크가 어떤 강점(wedge)을 가지고 있으며, 그에 따른 트레이드오프(trade-off)는 무엇인가"입니다.

다음은 2026년에 설치할 가치가 있는 6가지 프레임워크에 대한 솔직한 분석과, 각각을 언제 사용해야 하는지에 대한 내용입니다.

변동성(Churn)은 버그가 아니라 특징입니다

둘러보기 전에, 계산 방식을 바꾼 한 가지 사실이 있습니다. 바로 이 SDK들의 하부 와이어 포맷(wire formats)이 수렴했다는 점입니다. 여기에 소개된 모든 프레임워크는 도구(tools)를 위해 MCP를 사용합니다. 대부분은 프레임워크 간 핸드오프(handoffs)를 위해 A2A를 지원합니다. Model Context Protocol은 2025년 초 Anthropic의 제안으로 시작되었으며, 현재 에이전트가 외부 도구를 가져오는 기본 방식이 되었습니다.

그러한 수렴은 여러분이 선택한 프레임워크가 이전만큼 여러분을 종속(lock-in)시키지 않는다는 것을 의미합니다. 하지만 여전히 추상화 계층(abstraction layer)에서의 종속은 존재합니다. CrewAI에서 Pydantic AI로 프로덕션 시스템을 마이그레이션하는 것은 모든 Agent 정의와 모든 도구 데코레이터(tool decorator)를 다시 작성하는 작업입니다. 선택은 강력한 결합력을 가집니다. 이 점을 염두에 두고 선택하십시오.

LangGraph: 지속성(durability)을 무기로

에이전트가 충돌(crash) 상황에서도 살아남아야 한다면 LangGraph를 선택하십시오. 이 프레임워크는 에이전트를 Postgres 또는 SQLite를 기반으로 하는 체크포인터(checkpointer)를 갖춘 그래프로 모델링하므로, 7단계에서 중단된 워크플로우는 7단계에서 다시 재개될 수 있습니다. 인간 참여형(Human-in-the-loop) 중단 기능도 일급 시민(first-class)으로 지원됩니다.

사전에 구축된 경로는 짧습니다:

from langchain_anthropic import ChatAnthropic
from langgraph.prebuilt import create_react_agent

...

대가로는 개념적 무게감이 따릅니다. 노드(nodes), 엣지(edges), 그리고 상태 리듀서(state reducers) 방식으로 사고해야 합니다. 재개할 필요가 없는 단순한 도구 호출(tool-call) 루프의 경우, 그래프 방식은 요구되는 것보다 과도할 수 있습니다. OTel 스팬(spans)은 네이티브가 아닌 OpenInference를 통해 전달됩니다.

OpenAI Agents SDK: OpenAI 환경에서의 빠른 경로

이미 스택이 OpenAI로 구성되어 있고 작동하는 에이전트까지의 거리를 가장 짧게 만들고 싶다면, 이것이 정답입니다. 기본 구성 요소(primitives)는 Agent, Runner, 그리고 Handoff입니다. 상태(State)는 세션 범위(session-scoped)이며 지속적(durable)이지 않습니다. LiteLLM 계층을 통해 다른 모델을 가리킬 수도 있지만, 사용성(ergonomics)은 이 SDK가 제공되는 OpenAI 생태계에 최적화되어 있습니다.

OpenAI 환경에서의 속도를 위해 이를 선택하십시오. 지속적인 체크포인트가 필요하거나 프런트엔드 엔지니어가 읽을 수 있는 언어가 필요할 때는 다른 대안을 찾으십시오.

Claude Agent SDK: 코드와 파일을 다루는 에이전트를 위해

작업 내용이 코딩이나 파일 조작인 경우 Claude Agent SDK를 선택해야 합니다. 이 SDK는 Claude Code를 구동하는 것과 동일한 기본 구성 요소인 하위 에이전트(subagents), 파일 시스템 도구(file-system tools), 그리고 세션 재개(session resume) 기능을 갖추고 있습니다. 에이전트가 저장소(repo)를 읽고, 파일을 편집하며, 명령어를 실행해야 한다면, 이 SDK는 정확히 그러한 루프를 위해 설계되었습니다.

이 프레임워크는 Claude 모델에 의존하며, LLM 호출을 표시할 때 기본값은 claude-opus-4-8과 같은 Claude 모델입니다. 네이티브 OpenTelemetry (OTel)가 아직 지원되지 않으므로, 트레이싱 (tracing)을 위해 OpenInference로 감싸서 사용해야 합니다. 코딩 및 파일 에이전트 영역을 벗어난다면, 이 프레임워크의 강점은 덜 중요해집니다.

Microsoft agent-framework: Azure 기반의 엔터프라이즈 솔루션

이것은 AutoGen과 Semantic Kernel이 통합된 후속 제품입니다. 이 프레임워크의 핵심 경쟁력은 Microsoft 엔터프라이즈 환경입니다. 만약 귀하의 인프라가 Azure에서 실행되고, 감사인(auditors)들이 Purview라는 단어를 알고 있으며, 하나의 코드베이스 내에서 C#과 Python의 동등성 (parity)이 필요하다면, 이보다 더 나은 대안은 없습니다. 네이티브 OpenTelemetry GenAI 스팬 (spans)이 내장되어 있어, 프로덕션 (production) 환경에서 가장 중요한 지표 하나를 기준으로 볼 때 이 목록의 대부분보다 앞서 있습니다.

기본 구성 요소 (primitives)는 ChatAgent, Handoff, 그리고 Workflow입니다. 문제는 마이그레이션 피로도 (migration fatigue)입니다. AutoGen 0.2에서 0.4를 거쳐 agent-framework로 넘어온 사용자들은 18개월 동안 세 번의 파괴적 API (breaking APIs) 변경을 겪었습니다. TypeScript는 지원하지 않습니다. 귀하의 기술 스택이 Azure와 유사하고 거버넌스 (governance)가 실질적인 요구사항일 때 이를 선택하십시오.

CrewAI: 문제가 진정으로 '팀'의 문제일 때

CrewAI는 머신러닝 (ML) 엔지니어가 아닌 사람들이 가장 먼저 찾는 도구입니다. 당신은 에이전트를 고용합니다. 그들은 역할 (roles), 목표 (goals), 그리고 배경 이야기 (backstories)를 가집니다. 당신은 그들에게 작업을 부여하고, 크루 (crew)에 배치하며, 프로세스를 선택하고, 시작하면 됩니다. 사고 모델 (mental model)은 조직도 (org chart)이며, 이것이 소프트웨어를 구매하는 사람들에게 매우 잘 팔리는 이유입니다.

하지만 그 추상화가 곧 함정이기도 합니다. 많은 프롬프팅 (prompting)이 무대 뒤에서 일어납니다. 당신이 backstory를 설정하면, 프레임워크는 당신이 작성하지 않은 지시문 블록을 주입합니다. 무언가 잘못되면, 모델에 실제로 무엇이 전송되었는지 알아내기 위해 결국 CrewAI의 소스 코드를 읽게 됩니다. 제품 관리자(PM)가

Pydantic AI의 강점은 타입 시스템 (type system)입니다. 모든 에이전트는 의존성 타입 (dependency type)과 출력 타입 (output type)에 의해 매개변수화되며, 코드를 실행하기 전에 IDE가 불일치를 표시해 줍니다.

from pydantic import BaseModel
from pydantic_ai import Agent

...

output_type 기능이 이 프레임워크를 선택하게 만드는 핵심입니다. 모델이 Triage로 파싱되지 않는 값을 반환하면, 프레임워크는 검증 오류 (validation error)를 모델에 다시 전달하여 재시도 (retry)를 유도합니다. 사용자는 검증된 객체를 받거나 깔끔한 예외 (exception)를 받게 되며, JSON 코드 펜스 (code fence)가 포함된 문자열을 받는 일은 결코 없습니다. Logfire 통합을 통해 단 한 줄의 코드로 OTel 트레이스 (traces)를 얻을 수 있습니다.

약점은 생태계입니다. LangGraph나 CrewAI보다 규모가 작으며, 체크포인팅 (checkpointing)을 위한 그래프 API (graph API)도 더 초기 단계입니다. 오늘 당장 Postgres 기반의 내구성 있는 상태 (durable state)가 필요하다면 여전히 LangGraph가 승자입니다. 여러분의 조직이 이미 Pydantic을 사용 중이고, FastAPI 라우트 (routes)처럼 느껴지는 에이전트를 원한다면 Pydantic AI를 선택하세요.

필요에 따른 선택 매트릭스 (The pick-by-need matrix)

프레임워크	이럴 때 선택하세요	주의할 점
LangGraph	내구성 있는 상태와 인간 참여형 (human-in-the-loop)이 필요할 때	그래프 오버헤드 (Graph overhead); OpenInference를 통한 OTel
...

설치하기 전에

다음은 프레임워크 판매자들이 여러분이 건너뛰기를 바라는 내용입니다. 이 목록에 있는 모든 프레임워크는 새로운 어휘 (vocabulary), 실패 모드 (failure mode), 버전 고정 (version pins) 세트, 그리고 사용자와 모델 사이의 계층 (layer)을 추가합니다. 때로는 그 계층이 제값을 하지만, 그렇지 않은 경우가 더 많습니다.

가장 솔직한 기본값은 순수 제공자 SDK (provider SDK)입니다. 이벤트 루프 (event loop), 도구 목록 (list of tools), 그리고 messages.create 호출을 감싸는 while 루프만 있으면 됩니다.

import anthropic

client = anthropic.Anthropic()
...

이것만으로도 프레임워크 마케팅에서 주장하는 것보다 훨씬 더 많은 프로덕션 시스템을 구축할 수 있습니다. 다음 세 가지 중 하나에 해당할 때만 프레임워크를 고려하세요: 재시작 시에도 유지되는 내구성 있는 상태가 필요하거나, 프레임워크가 이미 밀접하게 결합되어 있는 생태계 위에서 구축 중이거나, 팀이 원시 루프 (raw loop)를 직접 관리하기 어려워 공유된 명명된 프리미티브 (named primitives)가 필요한 경우입니다.

외주를 줄 수 없는 테스트: 가장 유력한 후보 두 가지를 선정하여 가장 작은 형태의 정직한 프로그램을 구축하고, 이를 나란히 실행한 뒤 다음 날 오전 9시에 어떤 코드가 더 읽기 쉬운지 확인하십시오. 문서(docs)가 더 멋진 것이 아니라, 파일을 처음 열었을 때 에이전트가 무엇을 하려 하는지 명확히 알려주는 것을 선택해야 합니다. 그런 다음 생성된 트레이스(trace)를 읽어보십시오. 출력된 형태가 예상했던 형태와 일치하지 않는다면, 당신은 해결할 가치가 있는 다음 문제를 발견한 것입니다.

프레임워크를 선택하는 것은 쉬운 절반에 불과합니다. 어려운 절반은 제품을 출시한 후 이를 운영하는 것입니다. 즉, 도구 호출(tool call)이 왜 루프를 돌았는지, 한 턴(turn)의 비용이 얼마인지, 그리고 에이전트가 실제로 작업을 수행했는지 아는 것입니다. _Agents in Production_은 다단계 루프(multi-step loop)를 구축하고 출시하는 방법을 다루며, _Observability for LLM Applications_는 출시 후 시스템의 정직함을 유지하기 위한 트레이싱(tracing), 평가(evals), 비용 회계(cost accounting)를 다룹니다. 이 두 권은 합쳐져 _The AI Engineer's Library_를 구성합니다.