지난 2년 동안 네 개의 프로덕션 에이전트 프로젝트를 진행했습니다. 네 가지 서로 다른 프레임워크를 사용했죠.

중요한 결정 지점에서 인간의 검토 단계(human review gates)를 포함하는 상태 유지형 다단계 파이프라인(stateful multi-step pipeline)을 위해 LangGraph를 사용했습니다. 역할 기반의 작업 위임(role-based task delegation)이 필요한 연구 워크플로우에는 CrewAI를 사용했습니다. 얇은 API 래퍼(API wrapper) 뒤에서 타입이 지정된 도구 호출(typed tool calls)을 위해 Pydantic AI를 사용했습니다. 그리고 어차피 OpenAI 런타임 내부에서 실행될 프로젝트에는 OpenAI Agents SDK를 사용했습니다.

이 모든 프로젝트는 동일한 방식으로 시작되었습니다. 2주 동안 문서를 읽고, 장난감 데모(toy demos)를 만들고, 문제가 그래프(graph), 크루(crew), 타입 지정 도구 루프(typed tool loop), 또는 완전히 다른 무언가를 필요로 하는지 이해하려고 노력했습니다.

제가 빠르게 내리지 못하고 계속 실패했던 결정은 프레임워크 선택이었습니다. 정보가 숨겨져 있어서가 아니라, 정보가 흩어져 있었기 때문입니다. 어떤 사이트에는 GitHub 별(stars) 수가 있고, 다른 사이트에는 실제 프로덕션에서는 접해보지 못한 정형화된 작업(canned tasks)을 측정한 벤치마크(Benchmark) 수치가 있었습니다. 마케팅 페이지들은 구체적인 무언가를 설명하기보다는 모든 사람을 끌어들이기 위해 만들어진 언어를 사용하고 있었습니다.

제가 원했던 것은 표였습니다. 제어 스타일(Control style): 그래프, 역할 크루(role crew), 타입 지정 도구(typed tool), 대화형(conversational). 상태 모델(State model): 프레임워크가 단계 사이에서 상태를 어떻게 유지하고 전달하는지. 라이선스(License). 프레임워크가 실제로 어떤 용도에 맞춰 설계되었는지. 프로젝트가 유지 관리되고 있는지 알 수 있는 활성 신호(liveness signal). 프레임워크당 한 행. 이 모든 것이 한곳에 모여 있는 것 말입니다.

그런 표는 존재하지 않았고, 그래서 제가 직접 만들었습니다.

표가 다루는 내용

출시 당시 15개의 프레임워크: LangGraph, CrewAI, AutoGen, Pydantic AI, OpenAI Agents SDK, Mastra, LangChain Agents, LlamaIndex Agents, Semantic Kernel, Haystack Agents, Smolagents, Atomic Agents, Phidata, DSPy, AG2.

각 행에는 프레임워크의 마케팅 페이지에 있는 문구가 아니라, 선택 결정을 내리고 있는 친구에게 제가 직접 써줄 법한 슬로건(tagline)이 포함되어 있습니다. 제어 스타일(Control style). 상태 모델(State model). 라이선스(License). 프레임워크가 설계된 용도. 대략적인 활성 지표로서의 GitHub 별(stars) 수.

전체 디렉토리: https://compare-lab.xyz/ai-agent-frameworks/

왜 벤치마크가 아닌가

저는 현재 공개된 에이전트 벤치마크(benchmarks)를 신뢰하지 않습니다. 이들은 정해진 작은 작업들에 대한 도구 호출(tool-call) 성공 여부만을 측정하며, 실제 프로젝트에 어떤 프레임워크가 적합한지를 결정하는 세 가지 핵심 요소를 놓치고 있습니다.

첫 번째는 상태 모델 적합성(state-model fit)입니다. 만약 당신의 작업이 단계와 조건부 분기(branches)를 거치며 유지되는 명시적인 상태(explicit state)를 필요로 한다면, LangGraph나 Semantic Kernel이 필요합니다. 반면, 작업이 독립적인 역할들로 자연스럽게 분해될 수 있다면 CrewAI나 멀티 에이전트(multi-agent) AutoGen 패턴이 더 적합합니다. 잘못된 상태 모델을 선택한다는 것은 프레임워크를 활용하여 구축하는 것이 아니라, 프레임워크와 싸우게 된다는 것을 의미합니다.

두 번째는 추상화 탈출(abstraction escape)입니다. 모든 프레임워크에는 일반적인 사례를 위해 설계된 추상화 계층(abstraction layer)이 있습니다. 하지만 프로덕션(production) 환경의 에이전트는 끊임없이 예외 상황(edge cases)에 직면합니다. 중요한 것은 전체 파이프라인(pipeline)을 다시 작성하지 않고도, 필요할 때 추상화에서 깔끔하게 벗어날 수 있느냐 하는 것입니다. 어떤 프레임워크는 이를 쉽게 만들어주지만, 어떤 프레임워크는 매우 어렵게 만듭니다.

세 번째는 실패 복구(failure recovery)입니다. 장시간 실행되는 작업 도중 도구 호출(tool call)이 실패했을 때, 프레임워크는 실제로 무엇을 합니까? 체크포인트(checkpoint)에서 재시도할 수 있습니까? 부분적인 상태(partial state)를 로그로 남기고 세 번째 단계부터 다시 시작할 수 있습니까? 이러한 질문들은 장난감 수준의 데모(toy demos)에서는 보이지 않지만, 프로덕션 환경에서는 매우 결정적입니다.

기여하기 (Contributing)

데이터 파일은 공개되어 있습니다. 만약 이 중 하나를 프로덕션에 적용했는데 특정 행의 상세 내용이 틀렸다면, 한 줄의 PR(Pull Request)로 수정할 수 있습니다. 아직 목록에 없는 프레임워크를 사용 중이라면, 저에게 슬러그(slug)를 보내주세요.

제가 벤치마크 대신 디렉토리 형식을 선택한 이유에 대한 더 자세한 글은 다음을 참조하세요: https://hannune.ai/blog/why-i-built-ai-agent-framework-compare.html