저는 여러분이 더 이상 Slack에서 이 문제로 논쟁하지 않아도 되도록, 10개의 서로 다른 프레임워크를 통해 동일한 작업을 수행하며 6주를 보냈습니다. 현재 에이전트 (Agents)를 구축하는 거의 모든 엔지니어링 팀에서는 비슷한 대화가 오갑니다. 누군가는 "LangChain을 사용해야 한다"라고 말합니다. 다른 누군가는 "멀티 에이전트 (multi-agent) 작업에는 CrewAI가 더 낫다"라고 말합니다. 세 번째 사람은 누군가 AutoGen을 살펴본 적이 있는지 묻습니다. 모두가 데모, 블로그 포스트, 그리고 막연한 느낌 (vibes)에 의존하고 있기 때문에 아무도 의견을 모으지 못합니다. 저는 그런 대화에 지쳐서 실제 벤치마크 (benchmarks)를 실행했습니다. 6주 동안, 10개의 프레임워크를 대상으로, 5가지 평가 작업 (evaluation tasks)을 모든 프레임워크에서 일관되게 반복했습니다. 작업들은 README 파일에서 멋져 보이는 것이 아니라, 실제 프로덕션 에이전트 시스템 (production agent systems)이 수행해야 하는 내용을 반영하도록 선정되었습니다. 제가 무엇을 테스트했고 무엇을 발견했는지 소개합니다.

벤치마크 설정 (Benchmark Setup)
5가지 평가 차원:

• 에이전트 설정 시간 (Agent setup time): pip install부터 도구 사용 (tool use)이 가능한 에이전트가 작동하기까지 걸리는 시간. "노력"이 아닌 분 (minutes) 단위로 측정.
• 도구 통합 복잡도 (Tool integration complexity): 외부 API를 호출하는 커스텀 도구를 추가하는 데 필요한 코드 라인 수.
• 멀티 에이전트 오케스트레이션 (Multi-agent orchestration): 여러 개의 특화된 에이전트들을 조정할 수 있는가? 얼마나 깔끔하게 수행하는가?
• 메모리 처리 (Memory handling): 대화 메모리 (conversation memory)와 세션 간 지속적인 컨텍스트 (persistent context)를 지원하는가?
• 오류 복구 (Error recovery): 도구 호출이 실패하거나 예상치 못한 출력을 반환할 때 어떤 일이 발생하는가?

하드웨어: M3 MacBook Pro, 32GB. 일관성을 위해 모든 테스트는 API를 통해 Claude Sonnet을 기본 모델로 사용했습니다. 저는 모델의 품질을 벤치마킹하는 것이 아니라, 프레임워크의 오버헤드 (overhead)와 개발자 경험 (developer experience)을 벤치마킹하고 있습니다.

프레임워크들
LangGraph, CrewAI, AutoGen, LlamaIndex Workflows, Haystack, OpenClaw, Semantic Kernel, Phidata, Pydantic AI, 그리고 AgentOps. 하나씩 살펴보겠습니다.

1. LangGraph
   설정 시간: 18분 | 도구 통합: 중간 (Medium) | 멀티 에이전트: 매우 우수 (Excellent) | 메모리: 좋음 (Good) | 오류 복구: 매우 우수 (Excellent)
   LangGraph는 그래프 (graphs) 방식으로 사고하는 엔지니어들에게 추천하고 싶은 프레임워크입니다.

이 멘탈 모델(mental model), 즉 노드(nodes)는 처리 단계(processing steps)이고, 엣지(edges)는 전이(transitions)이며, 상태(state)가 그래프를 통해 흐른다는 개념은 한 번 이해하고 나면 매우 강력하지만, 이해하기 전까지는 다소 생소하게 느껴질 수 있습니다.

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    tool_results: list
    next_action: str

def research_node(state: AgentState):
    # 에이전트 추론 단계 (Agent reasoning step)
    return {
        "messages": [{"role": "assistant", "content": "Researching..."}]
    }

def tool_node(state: AgentState):
    # 도구 실행 단계 (Tool execution step)
    return {
        "tool_results": ["result_data"]
    }

workflow = StateGraph(AgentState)
workflow.add_node("research", research_node)
workflow.add_node("tools", tool_node)
workflow.add_edge("research", "tools")
workflow.add_edge("tools", END)

app = workflow.compile()

오류 복구(error recovery) 능력은 진정으로 인상적입니다. 명시적인 폴백 엣지(fallback edges)를 정의할 수 있어, '이 노드가 실패하면 대신 여기로 경로를 지정한다'와 같은 설정이 가능합니다. 이는 애플리케이션 코드 곳곳에 try/except 스파게티 코드를 흩뿌리지 않고도 회복 탄력성 있는 에이전트 동작(resilient agent behaviour)을 만들어냅니다. 트레이드오프(trade-off)는 학습 곡선(learning curve)이 실제로 존재한다는 점입니다. 그래프 기반 사고(graph-based thinking)에 익숙하지 않은 엔지니어들은 이 추상화(abstraction)와 씨름하게 될 것입니다. 설정 시간(setup time)도 이를 반영하는데, 제가 상태 스키마(state schema) 설계를 계속 재검토하느라 18분이 걸렸습니다.

2. CrewAI
   설정 시간: 8분 | 도구 통합: 쉬움 (Easy) | 멀티 에이전트 (Multi-agent): 매우 우수 (Excellent) | 메모리 (Memory): 좋음 (Good) | 오류 복구 (Error recovery): 보통 (Medium)

CrewAI는 이 목록에 있는 프레임워크 중 멀티 에이전트 작업을 위해 가장 직관적인 API를 제공합니다. '역할-작업-크루(Role-Task-Crew)' 멘탈 모델은 당신이 다른 엔지니어에게 업무를 설명하는 방식과 직접적으로 매칭됩니다.

from crewai import Agent, Task, Crew, Process

# 리서처(Researcher) 에이전트 설정
researcher = Agent (
    role = "Research Analyst (리서치 분석가)",
    goal = "{topic}에 대한 정확한 정보 찾기",
    backstory = "복잡한 정보를 합성하는 데 능숙한 전문가",
    verbose = True,
    tools = [search_tool, web_scraper_tool]
)

# 라이터(Writer) 에이전트 설정
writer = Agent (
    role = "Technical Writer (기술 작가)",
    goal = "리서치 내용을 바탕으로 명확한 문서 작성하기",
    backstory = "기술적 발견 사항을 읽기 쉬운 콘텐츠로 변환하는 전문가"
)

# 리서치 작업(Research Task) 정의
research_task = Task (
    description = "{topic}을(를) 조사하고 주요 기술적 세부 사항을 식별하기",
    agent = researcher,
    expected_output = "출처가 포함된 구조화된 리서치 요약본"
)

# 작성 작업(Write Task) 정의
write_task = Task (
    description = "리서치 내용을 바탕으로 문서 작성하기",
    agent = writer,
    expected_output = "완성된 기술 문서"
)

# 크루(Crew) 구성 및 실행
crew = Crew (
    agents = [researcher, writer],
    tasks = [research_task, write_task],
    process = Process.sequential
)

# 실행 (입력값: topic = "MCP protocol")
result = crew.kickoff(inputs = {"topic": "MCP protocol"})

AssistantAgent ( name = " assistant ", llm_config = { " config_list " : config_list }, system_message = " 당신은 유능한 코딩 어시스턴트입니다. " )
code_reviewer = autogen . AssistantAgent ( name = " code_reviewer " , llm_config = { " config_list " : config_list }, system_message = " 당신은 버그와 개선 사항을 위해 코드를 리뷰합니다. " )
user_proxy = autogen . UserProxyAgent ( name = " user_proxy " , human_input_mode = " NEVER " , code_execution_config = { " work_dir " : " coding " , " use_docker " : False } )

멀티 에이전트 대화 시작

user_proxy . initiate_chat ( assistant , message = " 중첩된 JSON을 파싱하는 Python 함수를 작성하세요 " )

코드 실행 능력(에이전트가 샌드박스 환경에서 코드를 작성하고 실행할 수 있는 기능)은 진정으로 유용하며, 모든 프레임워크가 이를 깔끔하게 처리하는 것은 아닙니다. 22분의 설정 시간은 Azure OpenAI 설정 옵션과 에이전트 파라미터의 수를 반영합니다. 복잡한 것이 아니라, 단지 장황할 뿐입니다.

4. LlamaIndex
   설정 시간: 15분 | 도구 통합 (Tool integration): 쉬움 | 멀티 에이전트 (Multi-agent): 좋음 | 메모리 (Memory): 우수함 | 오류 복구 (Error recovery): 보통

LlamaIndex는 여기서 소개된 어떤 프레임워크보다 최고의 RAG (Retrieval-Augmented Generation) 통합 기능을 갖추고 있으며, 이는 그 기원을 고려할 때 당연한 결과입니다. 만약 당신의 에이전트가 대규모 문서 컬렉션에 대해 추론해야 한다면, LlamaIndex Workflows는 별도로 추가된 복잡성 없이 이를 처리할 수 있는 프레임워크입니다. LlamaIndex는 여기서 소개된 어떤 프레임워크보다 최고의 RAG 통합 기능을 갖추고 있으며, 이는 그 기원을 고려할 때 당연한 결과입니다. 만약 당신의 에이전트가 대규모 문서 컬렉션에 대해 추론해야 한다면, LlamaIndex Workflows는 별도로 추가된 복잡성 없이 이를 처리할 수 있는 프레임워크입니다.

from llama_index.core.workflow import Workflow , StartEvent , StopEvent , step , Event

class ResearchEvent ( Event ):
query : str

class AnalysisEvent ( Event ):
research_results : str

class ResearchWorkflow ( Workflow ):
@step
async def research ( self , ev : StartEvent ) -> ResearchEvent :
# 문서 쿼리 및 컨텍스트 검색
results = await self . query_index ( ev .

query ) return ResearchEvent ( query = ev . query )

@step
async def analyse ( self , ev : ResearchEvent ) -> StopEvent :
# 연구 분석 합성 (Synthesise the research analysis)
analysis = await self . synthesise ( ev . query )
return StopEvent ( result = analysis )

workflow = ResearchWorkflow ( timeout = 60 , verbose = True )
result = await workflow . run ( query = " Explain the MCP protocol " )

이 이벤트 기반 아키텍처 (event-driven architecture)는 구조를 이해하고 나면 매우 깔끔합니다. 메모리 처리, 특히 RAG (Retrieval-Augmented Generation) 비중이 높은 워크로드에 있어서는 이 목록 중 최고입니다. 아쉬운 점: 멀티 에이전트 오케스트레이션 (multi-agent orchestration)을 위해 CrewAI나 AutoGen보다 더 많은 수동 연결 (manual wiring)이 필요합니다. 유능하긴 하지만, 조정 (coordination) 작업을 사용자가 직접 더 많이 수행해야 합니다.

5. Haystack
   설정 시간: 12분 | 도구 통합: 쉬움 | 멀티 에이전트: 좋음 | 메모리: 좋음 | 오류 복구: 좋음

Haystack의 파이프라인 기반 아키텍처 (pipeline-based architecture)는 여기에 나열된 어떤 프레임워크보다도 감사 가능성 (auditable)이 가장 높습니다. 모든 처리 단계가 명시적이며, 데이터 흐름이 가시적이고, 문제가 발생했을 때 시스템을 디버깅하기가 매우 직관적입니다.

from haystack import Pipeline
from haystack.components.generators import AnthropicGenerator
from haystack.components.routers import MetadataRouter

pipeline = Pipeline ()
pipeline . add_component ( " router " , MetadataRouter ( rules = { " search " : { " task " : { " $eq " : " search " }}, " analysis " : { " task " : { " $eq " : " analysis " }} }))
pipeline . add_component ( " search_agent " , AnthropicGenerator ( model = " claude-sonnet-4-5 " ))
pipeline . add_component ( " analysis_agent " , AnthropicGenerator ( model = " claude-sonnet-4-5 " ))
pipeline . connect ( " router.search " , " search_agent.prompt " )
pipeline . connect ( " router.analysis " , " analysis_agent.prompt " )

컴플라이언스 (compliance)나 감사 (audit) 요구 사항이 있는 팀의 경우, 명시적인 파이프라인 구조 덕분에 Haystack은 불투명한 다른 프레임워크들보다 진정으로 선호될 수 있습니다. 파이프라인 로그를 통해 "이 에이전트가 무엇을 왜 했는가"라는 질문에 명확하게 답할 수 있습니다. 트레이드오프 (trade-off): 그래프 기반 프레임워크 (graph-based frameworks)보다는 역동성이 떨어집니다.

복잡한 조건부 추론 (complex conditional reasoning)을 파이프라인 (pipeline) 용어로 표현하기는 더 어렵습니다.

6. OpenClaw
   설정 시간: 25분 | 도구 통합 (Tool integration): 중간 | 멀티 에이전트 (Multi-agent): 좋음 | 메모리 (Memory): 좋음 | 오류 복구 (Error recovery): 좋음

OpenClaw는 이 목록에서 셀프 호스팅 (self-hosted) 옵션이며, 데이터 프라이버시 (data privacy)가 요구 사항인 경우 반드시 알아두어야 할 도구입니다. 외부 서비스로의 API 호출 없이 모든 것이 귀하의 인프라 내에서 실행됩니다.

from openclaw import Agent, LocalLLM, Tool

llm = LocalLLM(
    model_path = "./models/llama-3.1-70b-q4",
    context_length = 8192
)

@Tool.register("database_query")
async def query_db(sql: str) -> dict:
    conn = await get_db_connection()
    result = await conn.execute(sql)
    return {"rows": result.fetchall()}

agent = Agent(
    llm = llm,
    tools = ["database_query"],
    system_prompt = "You are a data analysis assistant.",
    memory_enabled = True
)

response = await agent.run("Analyse the monthly revenue trend from the sales table")

25분의 설정 시간은 모델 다운로드 및 로컬 구성을 반영한 것입니다. 일단 실행되면 해당 클래스 내에서 견고한 성능을 보여줍니다. 솔직한 트레이드오프 (trade-off): 상당한 로컬 컴퓨팅 자원 (local compute)을 보유하지 않은 한, 모델 역량의 한계치 (capability ceiling)가 API 기반 프레임워크보다 낮습니다. 최고 성능보다 데이터 거주성 (data residency)이 더 중요한 유스케이스 (use cases)의 경우, 충분히 가치가 있습니다. OpenClaw의 전체 아키텍처 (architecture)와 셀프 호스팅 환경에서의 위치에 대해서는, README가 담지 못하는 내용을 Dextra의 심층 분석 (deep-dive)에서 다룹니다.

7. Semantic Kernel
   설정 시간: 20분 | 도구 통합 (Tool integration): 쉬움 | 멀티 에이전트 (Multi-agent): 좋음 | 메모리 (Memory): 좋음 | 오류 복구 (Error recovery): 좋음

Microsoft의 또 다른 에이전트 프레임워크입니다. AutoGen이 대화형 멀티 에이전트 패턴 (conversational multi-agent patterns)을 중심으로 구축된 반면, Semantic Kernel은 플러그인 (plugins)과 플래너 (planners)를 중심으로 구축되었으며, 이는 더 구조화되고 덜 대화적인 접근 방식입니다.

import semantic_kernel as sk
from semantic_kernel.connectors.ai.anthropic import AnthropicChatCompletion

kernel = sk.Kernel()
kernel.

add_service ( AnthropicChatCompletion ( ai_model_id = " claude-sonnet-4-5 " , api_key = " your_key " ))
@sk.kernel_function ( name = " analyse_data " , description = " 데이터셋 분석 " )
async def analyse_data ( kernel : sk . Kernel , data : str ) -> str :
return f " 분석 대상: { data } "

kernel . add_function ( plugin_name = " DataPlugin " , function = analyse_data )

.NET 우선(first)의 유산은 C# 문서가 Python 문서보다 현저히 더 뛰어나다는 점에서도 나타납니다. 만약 팀이 .NET 환경에서 작업한다면, Semantic Kernel이 명확한 선택입니다. Python 우선(first) 팀의 경우, 사용은 가능하지만 가끔 부족한 Python 문서에 대해 인내심을 가질 필요가 있습니다.

8. Phidata
   설정 시간: 6분 | 도구 통합 (Tool integration): 매우 쉬움 | 멀티 에이전트 (Multi-agent): 좋음 | 메모리 (Memory): 탁월함 | 오류 복구 (Error recovery): 보통

Phidata는 이 목록에서 가장 빠른 설정 시간을 자랑합니다. 6분이라는 시간은 정말로 6분이며, 에이전트 메모리를 위한 내장 스토리지 통합 (PostgreSQL, SQLite, Redis)은 별도의 설정 없이도(out of the box) 이 목록의 거의 다른 어떤 프레임워크보다 뛰어납니다.

from phi.agent import Agent
from phi.model.anthropic import Claude
from phi.tools.duckduckgo import DuckDuckGo
from phi.storage.agent.sqlite import SqlAgentStorage

agent = Agent ( model = Claude ( id = " claude-sonnet-