오픈소스 AI 에이전트 프레임워크
에이전트를 몇 개 직접 만들어 보고 나면, 똑같은 배관 작업이 계속 반복해서 나타납니다. 모델을 호출하고, 모델이 요청한 도구를 실행하고, 결과를 다시 넣어주고, 작업이 끝나면 멈추는 루프 말입니다. 에이전트 프레임워크는 그 배관 작업 — 여기에 상태, 메모리, 다중 에이전트 조정까지 — 을 패키징해 주므로, 여러분이 작성할 접착 코드가 줄어듭니다. 이 페이지는 주요 오픈소스 옵션들, 그것들이 실제로 제공하는 것, 그리고 선택 방법에 대한 지속적이고 공급자 중립적인 지도입니다. 이들 대부분은 모델에 구애받지 않습니다. 즉 Claude, GPT, Gemini, 그리고 로컬 오픈 웨이트 모델과 함께 작동합니다.
- 직접 만든 루프에 비해 에이전트 프레임워크가 무엇을 제공하는지 — 그리고 무엇을 제공하지 않는지 — 알기
- 세 가지 원형을 알아보기: 상태를 가진 그래프, 역할 기반 크루, 그리고 최소 루프
- 복잡성과 제어를 맞바꾸며 하나를 선택하는 반복 가능한 절차 사용하기
- 이들 대부분은 모델에 구애받지 않는다는 점을 기억하기 — 프레임워크가 여러분을 하나의 공급자에 묶어두는 일은 거의 없습니다
에이전트 프레임워크가 실제로 제공하는 것
브랜딩을 걷어내면, 프레임워크는 네 가지 중 일부를 여러분에게 제공하고 있습니다:
- 오케스트레이션 — 제어 루프. 순차적 단계, 분기, 재시도, 완료될 때까지 반복하는 루프, 그리고 (점점 더) 크래시에서 살아남아 멈춘 지점부터 재개되는 지속 실행(durable execution).
- 도구 — 모델이 호출할 수 있는 함수를 선언하고, 인자를 검증하고, 실행하고, 결과를 반환하는 표준적인 방법. 도구 사용(tool use)에서 이미 알고 있는 것과 동일한 describe→call→execute→return 루프입니다.
- 메모리 & 상태 — 대화 기록, 스크래치패드 사실, 그리고 검색된 문서를 여러 턴에 걸쳐 보관할 장소. 그래야 에이전트가 단계 사이에서 기억을 잃지 않습니다.
- 다중 에이전트 — 서로에게 작업을 넘겨주는 여러 전문화된 에이전트를 위한 패턴들: 작업자들에게 위임하는 슈퍼바이저, 또는 작업을 두고 협업하는 동료들. (개념적으로는 Claude Code의 서브에이전트와 같은 아이디어입니다.)
프레임워크는 그렇지 않으면 여러분이 네 가지 모두를 직접 손으로 작성하고 유지보수해야 할 때 그 가치가 있습니다. 여러분의 작업이 "모델을 호출하고, 도구 한두 개를 실행하고, 답을 반환한다"인 경우에는 가치가 없습니다. 그런 경우 프레임워크는 여러분이 시간을 들여 싸워야 할 부담이 됩니다.
세 가지 원형
프레임워크들은 그들의 마케팅이 암시하는 것보다 서로 덜 다릅니다. 사실상 세 가지 형태가 있고, 대부분의 프로젝트는 그중 하나의 변형입니다:
- 상태를 가진 그래프 / 워크플로. 에이전트를 노드와 엣지(또는 단계와 전이)로 이루어진 명시적 그래프로 모델링합니다. 최대의 제어, 검사 가능한 상태, 장시간 실행되는 흐름과 인간 개입(human-in-the-loop) 흐름에 좋습니다. 처음에 배울 것이 더 많습니다. → LangGraph, LlamaIndex Workflows.
- 역할 기반 크루. 에이전트를 역할("연구자", "작성자", "검토자")로 기술하고, 그들이 협업하거나 프로세스를 실행하도록 합니다. 다중 에이전트 팀을 빠르게 표현할 수 있습니다. 그 대신 고수준 추상화를 위해 일부 세밀한 제어를 맞바꿉니다. → CrewAI, 그리고 AutoGen의 대화형 다중 에이전트 스타일.
- 최소 루프 / 적은 추상화. 모델의 네이티브 도구 호출 위에 얇은 층을 두고, 몇 개의 에이전트 간 인계(handoff)와 그 외 별로 많지 않은 것을 얹습니다. 처음부터 끝까지 읽기 쉽고, 걷어내기 쉽습니다. → OpenAI Agents SDK (실험적인 Swarm의 프로덕션 후속작), 그리고 여러분이 직접 작성하는 평범한 루프.
- 작동하는 가장 단순한 것에서 시작하세요 — 종종 평범한 도구 호출 루프가 무거운 프레임워크를 이깁니다.
빠르게 둘러보기 (커밋하기 전에 포지셔닝을 확인하세요)
이들은 알아둘 가치가 있는 오픈 프로젝트들입니다. 각 프로젝트의 실제 저장소가 검증되었기 때문에만 이름을 언급합니다. 변동성이 큰 모든 것은 위의 VerifyNote 뒤에 있습니다.
- LangGraph — 그래프로 모델링된, 상태를 가진 장시간 실행 에이전트를 위한 저수준 오케스트레이션 프레임워크. 지속 실행과 인간 개입이 일급 시민입니다. 단독으로 또는 더 넓은 LangChain 생태계와 함께 사용 가능합니다. 모델에 구애받지 않습니다.
- LlamaIndex — 데이터/RAG 프레임워크(커넥터, 인덱스, 검색)로 시작했고 이제 에이전트를 위한 이벤트 기반 Workflows 층도 함께 제공합니다. 여러분의 에이전트가 근본적으로 여러분의 문서에 대한 검색일 때 강력합니다.
- Microsoft AutoGen — 대화형 다중 에이전트 시스템을 위한 프레임워크. 2026년 중반 기준으로 유지보수 모드에 있습니다. Microsoft는 새 프로젝트를 통합된 후속작(Microsoft Agent Framework, AutoGen + Semantic Kernel 병합)으로 안내합니다. 시작하기 전에 현재 상태를 확인하세요.
- CrewAI — 역할 기반 프레임워크: 에이전트를 역할과 목표로 정의하고, 이들을 Crews(자율적 협업) 또는 Flows(이벤트 기반 제어)로 조직합니다. 다중 에이전트 팀으로 가는 빠른 길입니다.
- OpenAI Agents SDK — 인계가 있는 다중 에이전트 워크플로를 위한, 의도적으로 가볍고 추상화가 적은 프레임워크. 이름과 달리 공급자에 구애받지 않으며(문서에서 100개 이상의 LLM 지원을 명시), 실험적인 Swarm의 프로덕션 준비가 된 후속작입니다.
- 평범한 에이전트 루프 — 프레임워크가 전혀 없는 것: 모델의 네이티브 도구 호출을 감싸는 여러분 자신의
while루프. 단순한 에이전트를 위한 올바른 기본값이며, 위의 모든 프레임워크가 궁극적으로 감싸고 있는 바로 그것입니다.
프레임워크를 선택하는 방법
- 에이전트가 무엇을 하는지 한 문장으로, 그리고 타협 불가능한 것들: 지연 시간, 비용 상한, 데이터 프라이버시, 실행이 크래시에서 살아남아야 하는지, 그리고 인간이 단계를 승인해야 하는지.
- 하나의 에이전트가 도구 한두 개를 호출하는 것이라면, 평범한 루프를 작성하세요. 많은 프로덕션 에이전트는 그 이상을 결코 필요로 하지 않습니다. 그렇지 않으면 오케스트레이션, 메모리, 그리고 다중 에이전트를 직접 재구현해야 할 때에만 프레임워크를 채택하세요.
- 장시간 실행 / 인간 개입 / 검사 가능한 상태 → 상태를 가진 그래프(LangGraph, LlamaIndex Workflows). 전문가 팀 → 역할 기반 크루(CrewAI). 몇 개의 에이전트가 인계하며 단순하게 유지 → 최소 루프(OpenAI Agents SDK, 또는 여러분 자신의 것).
- 저장소가 활발히 유지보수되고 있는지(유지보수 모드가 아닌지), 그리고 여러분이 실제로 사용하는 모델 — Claude, GPT, Gemini, 또는 로컬 모델 — 을 깔끔하게 지원하는지 확인하세요. 대부분은 공급자 중립적입니다. 가정하지 말고 확인하세요.
- 가장 어려운 단일 단계 — 까다로운 도구, 인계, 실패 후 재개 — 를 후보 두 개에서 만들어 보세요. 그 단계를 읽기 쉽게 만들어 주는 추상화가 여러분의 승자입니다.
- 여러분의 도구와 프롬프트를 평범한 함수와 문자열로 유지하여, 프레임워크가 여러분의 로직을 소유하는 것이 아니라 감싸도록 하세요. 프레임워크 교체는 모든 것을 다시 작성하는 것이 아니라 오케스트레이션을 다시 연결하는 것을 의미해야 합니다.
모든 프레임워크가 감싸는 것
어떤 라이브러리에 손을 뻗기 전에, 그것들이 모두 그 위에 지어진 루프를 보는 것이 도움이 됩니다. 이것이 아이디어의 전부입니다 — 모델이 결정하고, 여러분이 실행하고, 완료될 때까지 반복:
# Provider-neutral agent loop — the core every framework wraps.
# `model_call` and `run_tool` are yours; swap in Claude, GPT, Gemini, or a local model.
def agent_loop(task, tools, max_steps=10):
messages = [{"role": "user", "content": task}]
for _ in range(max_steps):
# 1. Ask the model what to do next (it sees the tool schemas).
response = model_call(messages, tools=tools)
# 2. No tool requested → the model is done. Return its answer.
if not response.tool_calls:
return response.text
# 3. Run each requested tool and feed results back in.
messages.append(response.as_message())
for call in response.tool_calls:
result = run_tool(call.name, call.arguments)
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
return "Stopped: hit max_steps without finishing."
이것을 읽을 수 있다면, 이 페이지의 모든 프레임워크가 내부에서 무엇을 하고 있는지 이해하는 것입니다. 그래프는 명시적 상태와 분기를 더하고, 크루는 역할과 위임을 더하며, 최소 SDK는 깔끔한 인계를 더합니다 — 하지만 심장 박동은 언제나 이 루프입니다.
최소 에이전트 시스템 프롬프트 (위의 루프와 짝을 이룸)
You are a task-completing agent with access to tools.
Loop:
1. Think briefly about the next single step toward the goal.
2. If a tool would help, call exactly ONE tool with valid arguments.
3. When you have enough to answer, stop calling tools and give the final answer.
Rules:
- Prefer the fewest tool calls that get the job done.
- If a tool fails, read the error and adjust — do not repeat the same call.
- Never invent tool results; use only what tools actually returned.
- If the goal is impossible with the available tools, say so and stop.
Goal: {one-sentence task}과대광고에 대한 한마디
여기 있는 어떤 프레임워크도 "최고"가 아닙니다 — 그 질문 자체가 잘못 형성된 것입니다. 그래프 프레임워크는 제어와 지속성에서 이기고, 크루 프레임워크는 팀을 빠르게 표현하는 데서 이기며, 최소 프레임워크는 가독성과 낮은 종속성에서 이기고, 평범한 루프는 프레임워크 README가 인정하는 것보다 더 자주 이깁니다. 올바른 선택은 여러분의 가장 어려운 단계를 명확하게 만들어 주는 가장 작은 도구입니다. 모델을 고를 때와 마찬가지로, 스타 수가 아니라 여러분 자신의 작업이 결정하게 하세요. 평가(evals)에 적용할 것과 같은 규율이 여기에도 적용됩니다: 프로토타입을 만들고, 실제 사례에서 측정하고, 탈출 경로를 유지하세요.
스스로 점검하기
0/3- 에이전트 프레임워크는 오케스트레이션, 도구, 메모리, 그리고 다중 에이전트 조정을 패키징합니다 — 그렇지 않으면 네 가지 모두를 직접 구축해야 할 때에만 채택하세요.
- 세 가지 원형이 이 분야를 아우릅니다: 상태를 가진 그래프(제어/지속성), 역할 기반 크루(빠른 팀), 그리고 최소 루프(가독성, 낮은 종속성).
- 이들 거의 모두는 모델에 구애받지 않습니다 — Claude, GPT, Gemini, 그리고 로컬 모델에서 실행됩니다; 가정하지 말고 프로젝트별로 확인하세요.
- 보편적으로 '최고'인 프레임워크는 없습니다; 여러분의 가장 어려운 단계를 명확하게 만들어 주는 가장 작은 도구를 고르고, 탈출 경로를 유지하세요.
- 평범한 도구 호출 루프가 정직한 기본값입니다 — 그리고 그것이 바로 모든 프레임워크가 감싸는 것입니다.
- 유지보수 상태는 바뀝니다(예: AutoGen → 후속작); 커밋하기 전에 프로젝트가 자체 저장소에서 활발히 유지보수되고 있는지 확인하세요.
출처 & 더 읽을거리
- LangGraph — GitHub — 상태를 가진 장시간 실행 에이전트를 위한 저수준 오케스트레이션 프레임워크.
- LangGraph 개요 — LangChain 문서 — 개념, 지속 실행, 그리고 인간 개입.
- LangChain — GitHub — LangGraph가 통합되는 더 넓은 생태계.
- LlamaIndex — GitHub — 에이전트를 위한 이벤트 기반 Workflows 층을 갖춘 데이터/RAG 프레임워크.
- LlamaIndex 문서 — RAG, 쿼리 엔진, 에이전트, 그리고 Workflows.
- Microsoft AutoGen — GitHub — 대화형 다중 에이전트 프레임워크 (유지보수 상태 확인).
- Microsoft Agent Framework — GitHub — 에이전트를 구축하고 조율하기 위한 통합 후속작(AutoGen + Semantic Kernel).
- CrewAI — GitHub — Crews와 Flows를 갖춘 역할 기반 다중 에이전트 프레임워크.
- CrewAI 문서 — 에이전트, 태스크, 크루, 플로, 그리고 도구.
- OpenAI Agents SDK — GitHub — 인계가 있는 가볍고 공급자에 구애받지 않는 다중 에이전트 프레임워크.
- OpenAI Agents SDK 문서 — 최소 추상화 에이전트 모델.
- OpenAI Swarm — GitHub — Agents SDK가 대체하는 실험적 전신(교육용, 현재 대체됨).