에이전트 프레임워크 선택은 “가장 유명한 도구”를 고르는 문제가 아니다. 2026년의 주요 프레임워크는 상태 관리, 멀티에이전트 협업, 도구 호출, 평가, 배포, 관찰성에서 서로 다른 철학을 갖는다. 작은 프로토타입과 장시간 실행되는 운영 워크플로는 필요한 추상화가 다르다.
빠른 선택 기준
| 상황 | 우선 검토할 프레임워크 | 이유 |
|---|---|---|
| 상태 전이와 재시작이 중요한 장기 워크플로 | LangGraph | 그래프 기반 상태, 체크포인트, 휴먼 인 더 루프를 명시적으로 설계하기 좋다 |
| 역할 기반 리서치·보고서 프로토타입 | CrewAI | 역할과 태스크 단위 모델이 이해하기 쉽고 빠르게 데모를 만들 수 있다 |
| 가벼운 도구 사용 에이전트 | OpenAI Agents SDK | 에이전트, 툴, 핸드오프, 세션, 추적을 작은 API 표면으로 제공한다 |
| Google Cloud·Firebase 기반 앱 | Google ADK, genkit | Gemini·Google Cloud·Firebase 배포 흐름과 잘 맞는다 |
| TypeScript 제품 코드 안에 AI 플로우를 넣는 경우 | Mastra, genkit | 백엔드 앱 코드와 가까운 형태로 모델 호출·툴·워크플로를 관리한다 |
선택 전에 확인할 질문
상태를 누가 책임지는가
단발성 질문 답변이면 프레임워크가 거의 필요 없다. 반대로 고객지원, 코드 수정, 리서치, 운영 자동화처럼 여러 단계에 걸쳐 상태가 누적되는 작업이라면 체크포인트, 재시도, 중단 후 재개, 승인 지점을 명시할 수 있어야 한다.
멀티에이전트가 정말 필요한가
역할 기반 멀티에이전트는 설명하기 쉽지만, 검증·중복 작업·비용 관리가 함께 필요하다. 단순히 “리서처와 라이터”를 나누는 것보다 하나의 에이전트에 좋은 도구와 평가 루프를 붙이는 편이 더 안정적인 경우가 많다.
운영 관찰성이 있는가
프로덕션 에이전트는 실패 이유를 추적할 수 있어야 한다. 프롬프트, 도구 호출, 승인, 모델 응답, 비용, 재시도 이력이 남지 않으면 문제가 생겼을 때 “모델이 틀렸다” 이상의 분석이 어렵다.
실무 권장 패턴
처음부터 범용 에이전트 플랫폼을 만들기보다 가장 작은 성공 루프를 먼저 만든다. 이후 다음 조건이 생길 때 프레임워크 레벨을 올리는 편이 낫다.
- 상태가 길어져 재시작·복구가 필요해진다.
- 여러 도구 호출을 사람이 감사해야 한다.
- 같은 워크플로를 여러 팀이 반복 사용한다.
- 평가와 회귀 테스트 없이는 변경이 위험해진다.
- 배포 후 비용·지연시간·실패율을 추적해야 한다.
관련 문서
- mcp — 에이전트가 외부 시스템과 연결되는 표준 프로토콜
- genkit — Google Firebase가 프로덕션에서 쓰는 오픈소스 AI 앱 프레임워크
- pydantic-ai — 타입 안전한 Python 에이전트 프레임워크
- cloudflare-agents — Durable Objects 기반 영속 상태 에이전트 SDK
참고 자료
- 10 Agentic AI Frameworks You Should Know in 2026 — KDnuggets (2026-07-02)