CrewAI란
CrewAI는 에이전트, 태스크, crew, flow, 도구를 위한 자체 기본 요소를 갖춘 MIT 라이선스의 독립형 Python 프레임워크입니다. Crew는 하나의 작업에서 자율적으로 협업하는 역할 기반 에이전트 팀입니다. Flow는 실행 경로, 상태, 분기를 정밀하게 제어할 수 있는 이벤트 기반 워크플로입니다. 이 프로젝트는 실행 중 사람의 입력을 지원하며, 상용 CrewAI AMP Suite는 관리형 배포, 관측성, 거버넌스, 지원을 위한 컨트롤 플레인을 더합니다.
자율적인 crew 대 통제된 구성
CrewAI는 에이전트의 자율성에 기대어, 역할, 목표, 태스크를 설명하면 crew가 협업 방식을 스스로 찾아내며, 더 엄격한 제어가 필요할 때 Flow를 씁니다. EDDI는 통제에 기댑니다. 결정론적 behavior rules가 다음에 실행할 동작을 결정하고, LLM은 선언된 태스크 안에서 호출되며, 멀티 에이전트 작업은 명시적 단계를 가진 이름 있는 그룹 토론 스타일을 따릅니다. 둘 다 멀티 에이전트 시스템을 만들 수 있습니다. 차이는 사전에 사람이 얼마나 결정하는지와 런타임에 모델이 얼마나 결정하는지에 있습니다.
코드 속의 에이전트 대 구성으로서의 에이전트
| 항목 | CrewAI | EDDI |
|---|---|---|
| 핵심 추상화 | 태스크를 가진 역할 기반 에이전트의 crew, 그리고 이벤트 기반 Flow | 에이전트 구성: 파이프라인, behavior rules, LLM 태스크, 도구를 버전 관리되는 JSON으로 |
| 언어와 런타임 | 애플리케이션에 내장되는 Python 라이브러리 | 가상 스레드를 사용하는 JVM(Quarkus) 플랫폼, 에이전트에는 코드가 필요 없음 |
| 라이선스 | MIT(오픈소스 프레임워크), 그 위에 상용 AMP Suite | Apache 2.0, OSI 승인 |
| 제어 흐름 | 에이전트가 런타임에 협업을 결정하며, Flow가 코드로 명시적 분기를 추가 | 결정론적 behavior rules가 다음 동작을 선택하고, 그룹 스타일이 단계를 정의 |
| 코드 실행 | crewai-tools에서 코드 인터프리터 도구가 제거되었고 에이전트 수준 코드 실행은 더 이상 권장되지 않으며, 문서는 E2B나 Modal 같은 전용 샌드박스를 권장 | 플랫폼에 런타임 eval() 또는 코드 실행 없음, 로직은 선언되거나 MCP 도구 또는 HTTP 호출 뒤에 있음 |
| Human in the loop | 실행 중 사람의 입력 지원 | 턴, 도구 호출, 그룹 단계에 대한 게이트, 타임아웃 정책, Manager, REST, MCP 또는 Slack에서의 승인 |
| 멀티 에이전트 패턴 | 코드로 구현하는 Crew 프로세스와 Flow | 7가지 스타일과 사용자 정의 스타일의 그룹 토론, 기록되는 결정, 집계, 반대 의견, 서명된 트랜스크립트 항목 |
| 관리와 거버넌스 | 상용 AMP Suite의 추적 및 거버넌스를 갖춘 컨트롤 플레인 | 오픈소스 빌드에 포함된 Manager UI, 시크릿 vault, 선택적 Keycloak/OIDC, 감사 원장 |
| 감사 추적 | 컨트롤 플레인 또는 자체 도구를 통한 추적과 관측성 | HMAC 서명, 추가 전용, 순번 검증 원장, GET /auditstore/verify/{conversationId} |
| 모델 | Python에서 다양한 제공자 지원 | 19개 LLM 제공자와 Ollama 또는 Jlama를 통한 로컬 모델 |
다른 도구에 대한 내용은 2026년 10월 기준으로 공식 문서와 저장소를 확인한 것입니다. 이러한 프로젝트는 변화가 빠르므로, 결정하기 전에 해당 벤더에서 최신 동작을 확인하세요.
둘 사이에서 고르기
CrewAI가 더 나은 선택인 경우
- 팀이 Python 우선이며 에이전트, 도구, crew 로직을 나머지 코드와 같은 저장소에 두고 싶습니다.
- 자율적인 역할 수행형 협업을 빠르게 프로토타이핑하고 코드를 편집해 조정하고 싶습니다.
- 구성으로 표현할 수 없는 임의의 로직을 가진 사용자 정의 Python 도구가 필요합니다.
- 운영하는 플랫폼보다 내장하는 라이브러리를 선호합니다.
- 상용 AMP Suite 컨트롤 플레인이 조직이 crew를 배포하고 모니터링하려는 방식에 맞습니다.
EDDI가 더 나은 선택인 경우
- 멀티 에이전트 동작이 검토할 수 있을 만큼 예측 가능해야 합니다: 자유로운 자율성이 아니라 이름 있는 단계, 기록된 결정, 규칙.
- 사람이 특정 도구 호출이나 그룹 단계를 승인해야 하고, 그 결정이 서명된 원장에 기록되어야 합니다.
- 거버넌스, 관리 UI, 감사를 별도의 상용 티어가 아니라 오픈소스 빌드에서 쓰고 싶습니다.
- 보안 리뷰에서 추론 시점에 어떤 코드가 실행되는지 물을 것이고, 플랫폼이 아무것도 실행하지 않기를 원합니다.
- 비엔지니어가 풀 리퀘스트 없이 에이전트 동작을 바꿔야 합니다.
CrewAI에서 crew 옮기기
역할과 목표는 프롬프트와 그룹 단계로 옮겨집니다. 가장 많이 바뀌는 부분은 자율성입니다. crew가 런타임에 결정하던 것은 직접 명시적으로 작성하는 규칙, 단계 또는 승인 게이트가 됩니다.
| CrewAI | EDDI |
|---|---|
| 에이전트(역할, 목표, 배경 이야기) | LLM 태스크의 시스템 메시지를 갖춘 EDDI 에이전트 |
| 태스크 | 파이프라인 태스크, 또는 그룹 토론의 단계 |
| Crew 프로세스 | 그룹 토론 스타일, 예를 들어 태스크 포스 또는 라운드 테이블 |
| 라우터가 있는 Flow | inputmatcher, actionmatcher 같은 조건 유형을 쓰는 behavior rules |
| 사용자 정의 Python 도구 | MCP 도구, httpCall, 또는 OpenAPI에서 가져온 API |
| 사람의 입력 | PAUSE_CONVERSATION 규칙, toolApprovals, 또는 단계의 requiresApproval |
| 메모리와 지식 소스 | 대화 메모리 범위와 RAG 지식 베이스 |
자주 묻는 질문
EDDI는 멀티 에이전트 시스템에서 CrewAI의 대안인가요?
네, 멀티 에이전트 협업을 통제된 서비스로 원하는 팀에게는 그렇습니다. EDDI 그룹 토론은 명시적 단계를 가진 이름 있는 스타일로 실행되며 결정과 반대 의견을 기록합니다. CrewAI는 에이전트에 더 많은 자율성을 주고 Python으로 정의되므로, 코드에 머물고 싶은 팀에 적합합니다.
EDDI에도 CrewAI 같은 자율 에이전트가 있나요?
EDDI 에이전트는 도구를 호출하고 그룹 토론에서 협업할 수 있지만, 제어 흐름은 에이전트가 즉흥적으로 정하도록 두지 않고 사용자가 구성한 behavior rules와 단계로 정해집니다. 이는 자율성을 예측 가능성과 맞바꾸는 의도적인 선택입니다.
여기서 코드 실행이 왜 중요한가요?
생성된 코드를 실행하는 에이전트에는 격리가 필요합니다. CrewAI는 내장 코드 인터프리터에서 벗어났으며 전용 샌드박스 서비스를 권장합니다. EDDI는 런타임에 코드를 평가하지 않음으로써 플랫폼 내부에서는 이 문제를 피하며, 실제 로직이 필요한 것은 사용자가 선언하고 승인할 수 있는 도구 뒤에 놓입니다.
둘 다 사용할 수 있나요?
네. CrewAI 서비스가 REST API, MCP 서버 또는 OpenAI 호환 API로 EDDI를 호출할 수 있고, EDDI도 httpCall로 CrewAI 엔드포인트를 호출할 수 있습니다. 코드 수준 실험에는 CrewAI를, 통제된 프로덕션 에이전트에는 EDDI를 쓰는 것은 합리적인 분담입니다.