AI 에이전트를 만들려고 검색하면 CrewAI, AutoGen, OpenAI Agents SDK, Google ADK, LangGraph가 함께 등장한다. 이름은 익숙해져도 선택은 쉽지 않다. 빠르게 시제품을 만드는 도구와, 실패한 작업을 복구하고 사람의 승인을 기다리는 흐름을 세밀하게 만드는 도구가 같은 기준으로 비교되기 때문이다.
노마드 코더의 「2025년. 최고의 AI 에이전트 프레임워크는?」는 같은 주식 분석 에이전트를 여러 프레임워크로 구현했다는 제작자의 경험을 바탕으로 장단점을 설명한다. 이 글은 2025년 영상의 평가와 현재 공식 자료를 구분해 읽는 비교 가이드다. 특히 유지보수 상태와 기능이 달라진 부분은 2026년 10월 27일 확인한 공식 자료로 보완했다.
먼저 구분할 것: 경험담은 성능 순위표가 아니다
영상 제작자는 같은 로직·프롬프트·도구를 사용해 프레임워크별 차이를 살폈다고 설명한다. 그러나 영상만으로 모델 버전, 반복 실행, 비용, 성공률, 평가 기준이 통제된 벤치마크를 확인할 수는 없다. ‘20분이면 만든다’, ‘가장 좋다’ 같은 표현은 제작자의 경험과 선호로 읽어야 한다.
주식 분석 에이전트의 수익률 언급도 프레임워크의 우수성을 증명하지 않는다. 투자 결과는 시장 상황과 전략 등 다른 요인의 영향을 받으므로, 이 글에서는 선택 근거로 사용하지 않는다.
실무에서는 다음 질문부터 정하는 편이 낫다.
- 작업 형태: 고정된 순서인가, 상황에 따라 분기·반복·재개해야 하는가?
- 모델과 도구: 어떤 모델·검색·파일·음성 기능을 연결해야 하는가?
- 실행 상태: 중간 결과 저장, 중단 후 복구, 사람의 승인이 필요한가?
- 운영 환경: 팀의 언어와 클라우드, 보안·배포 조건에 맞는가?
- 유지보수: 새 프로젝트에 사용할 만큼 지원 상태가 명확한가?
이 질문에 답하면 ‘최고의 프레임워크’보다 ‘이번 프로젝트에 맞는 후보’를 고르기 쉬워진다.
CrewAI: 역할과 과업으로 업무를 나누고 싶을 때
영상은 CrewAI를 에이전트 입문의 좋은 출발점으로 평가한다. 역할을 가진 에이전트에게 Task와 도구를 연결하고, Crew로 묶는 구성이 직관적이라는 이유다. 조사→작성처럼 역할과 산출물이 분명한 업무를 시제품으로 만들어 보는 데 검토할 수 있다.

다만 ‘빠르게 조립하기 좋다’와 ‘데모에만 쓸 수 있다’는 다른 말이다. 현재 공식 저장소는 Crews와 Flows를 함께 안내한다. 역할 기반 협업뿐 아니라 이벤트 기반 제어, 상태·분기와 일반 Python 로직의 연결도 설명한다.
따라서 영상의 ‘틀을 벗어나면 어렵다’는 평가는 당시 제작자가 경험한 사용성 평가로 구분해야 한다. 현재 CrewAI의 확장 가능성을 그 한 문장으로 제한할 수는 없다. 반대로 공식 자료가 운영용 구성을 소개한다는 사실만으로, 자신이 만든 Crew가 안전하게 운영될 준비를 마쳤다고 볼 수도 없다.
처음에는 두 역할 정도로 작은 작업을 만들고, 입력·출력·오류 지점을 설명해 보는 편이 좋다. 구체적인 구성은 CrewAI 입문 가이드에서 확인할 수 있다.
AutoGen: 2025년의 추천보다 현재 유지보수 안내를 먼저 본다
영상은 AutoGen의 대화 중심 협업 방식과 Studio·AgentChat·Core 구성을 소개하고, .NET 환경에 적합한 선택지로 평가한다. 이 설명은 당시의 특징을 이해하는 데 도움이 된다. 하지만 지금 새 프로젝트를 시작한다면 먼저 확인할 내용이 바뀌었다.
현재 AutoGen 공식 README는 프로젝트의 유지보수 종료를 명시하고, 새 사용자가 Microsoft Agent Framework에서 시작하도록 안내한다. 버그·보안 수정과 지원이 제공되지 않는다는 경고도 담겨 있다. 기존 사용자를 위한 이전 가이드도 연결한다.
여기서 근거는 공식 README의 유지보수 안내다. GitHub 저장소가 기술적으로 읽기 전용 보관 상태인지 여부와 혼동해서는 안 된다. 중요한 판단은 새 서비스가 의존할 코드에 어떤 수정과 지원을 기대할 수 있느냐는 것이다.
따라서 ‘C# 개발자는 AutoGen이 유일한 선택’이라는 영상의 조언을 그대로 현재 추천으로 옮기지 않는다. Microsoft Agent Framework는 .NET과 Python을 지원하며, 순차·동시·handoff·그룹 협업 등 여러 워크플로를 안내한다. Microsoft 생태계의 신규 도입 검토라면 이 후속 프레임워크와 이전 문서를 함께 확인하는 편이 타당하다.
기존 AutoGen 시스템도 이름만 바꿔 즉시 이전할 수 있다고 가정해서는 안 된다. 사용 중인 메시지·도구·상태 관리와 배포 구성을 확인한 뒤, 작은 대표 작업부터 호환성과 결과를 검토해야 한다.
OpenAI Agents SDK: 위임·도구·추적 기능을 간결하게 연결할 때
영상은 OpenAI 모델과 도구의 연동, 추적 기능, 음성 에이전트 개발 경험을 장점으로 든다. 현재 공식 저장소에서도 Agents, tools, guardrails, sessions, tracing, 사람의 개입 기능을 확인할 수 있다.
특히 다른 에이전트를 도구처럼 호출하는 방식(agents as tools)과 제어를 넘기는 방식(handoffs)을 구분해 볼 필요가 있다. 같은 ‘위임’이라도 호출한 쪽이 결과를 받아 계속 조정하는지, 다른 에이전트가 대화를 이어가는지에 따라 설계가 달라진다.

현재 공식 README는 SDK를 제공자 중립적으로 소개하며 OpenAI 외 모델 연동도 안내한다. 영상의 ‘다른 모델 지원은 베타’라는 설명을 현재 전체 SDK의 상태로 단정할 수는 없다. 다만 SDK가 여러 제공자를 지원한다는 것과, 특정 제공자의 호스팅 도구·음성·실행 기능을 모든 모델에서 똑같이 쓸 수 있다는 것은 별개다.
또 하나 주의할 것은 ‘배포에 필요한 기능이 있다’는 말이다. 추적이나 guardrail은 유용한 구성 요소지만, 그것만으로 사용자 로그인·권한 관리·비밀정보 보호·데이터 보존 정책이 완성되는 것은 아니다. 애플리케이션에서 누가 어떤 도구를 실행할 수 있는지는 별도로 설계해야 한다.
Google ADK: 개발·평가 환경과 Google 연동을 함께 검토할 때
영상은 Google ADK의 개발 UI, 평가 기능과 Google 생태계 연결을 높이 평가한다. 현재 Python 저장소에서도 개발용 Web UI, 평가 실행과 배포 관련 안내를 확인할 수 있다. Gemini에 최적화하면서도 모델 중립적이라는 설명도 제공한다.

이런 기능은 모델 응답만 보는 데서 나아가 도구 사용과 실행 경로를 확인하려는 팀에 유용한 검토 항목이다. 하지만 영상의 ‘UI가 있는 유일한 프레임워크’, ‘평가 기능이 있는 유일한 프레임워크’라는 표현은 그대로 사용하기 어렵다. UI·평가 도구의 제공 범위와 제품 구성은 생태계와 버전에 따라 다르므로, 배타적인 순위 주장보다 자신의 개발 과정에 맞는지 살펴봐야 한다.
아키텍처도 2025년의 고정된 설명으로 제한하지 않는 것이 좋다. 현재 ADK 저장소는 그래프 기반 Workflow와 분기·반복·상태 관리 등을 소개한다. ‘메인 에이전트와 하위 에이전트 구조밖에 못 만든다’고 요약하면 현재 안내를 놓치게 된다.
개발용 UI나 REST API 실행이 가능하다는 사실도 운영 배포 완료와 같지는 않다. 인증, 접근 통제, 비용·쿼터, 관측과 장애 대응은 실제 배포 환경에서 별도로 점검해야 한다.
LangGraph: 상태와 제어 흐름을 명시적으로 설계하고 싶을 때
영상 제작자가 가장 선호한다고 밝힌 도구는 LangGraph다. 역할을 조립하는 비유보다 노드와 연결을 직접 구성하는 그래프 방식에 가깝다고 설명한다. 이는 개인적 선호이지만, 어떤 설계 차이를 보는지 이해하는 데는 도움이 된다.
현재 공식 저장소는 LangGraph를 오래 실행되며 상태를 유지하는 에이전트를 위한 저수준 오케스트레이션 프레임워크로 소개한다. 지속 실행과 복구, 사람의 개입, 메모리와 상태 관리가 주요 기능으로 안내된다.

예를 들어 자료가 부족하면 조사로 돌아가고, 위험한 실행 전에는 승인을 기다리며, 중단된 작업의 상태를 이어가야 한다면 이런 제어 방식이 중요한 검토 대상이 된다. 다만 체크포인트 기능이 있다고 해서 외부 시스템에 발생한 모든 작업을 자동으로 되돌릴 수 있는 것은 아니다. 메일 발송이나 결제처럼 이미 발생한 부수효과의 중복 실행 방지는 별도로 고려해야 한다.
‘작은 API’ 역시 ‘실제 서비스 개발이 항상 쉽다’는 의미는 아니다. 상태 구조, 분기 조건과 오류 처리의 책임을 개발자가 더 명확히 맡아야 할 수 있다. 그래프 방식이 필요한 작업에는 장점이지만, 짧은 단일 과업에는 과한 설계가 될 수도 있다.
어떤 상황에서 무엇부터 검토하면 좋을까
다음은 영상의 고정 순위를 옮긴 것이 아니라, 현재 공식 안내를 바탕으로 재구성한 선택 출발점이다.
- 역할별 조사·작성 파이프라인을 빠르게 시험하고 싶다: CrewAI의 작은 Crew부터 검토한다. 역할과 산출물의 차이가 분명한지 먼저 본다.
- 도구·handoff·세션·추적을 SDK 중심으로 엮고 싶다: OpenAI Agents SDK를 검토한다. 사용할 모델과 기능별 호환 범위를 확인한다.
- Google 생태계 연동과 개발·평가 도구가 중요하다: Google ADK를 검토한다. 필요한 서비스와 배포 조건까지 확인한다.
- 상태·분기·복구·승인 흐름의 제어가 중요하다: LangGraph를 검토한다. 일반 코드와 에이전트 판단의 경계를 먼저 정한다.
- Microsoft·.NET 환경에서 새로 시작하거나 AutoGen을 이전한다: Microsoft Agent Framework와 공식 이전 안내를 함께 검토한다.
이 목록은 서로 배타적이지 않다. 여러 프레임워크에서 비슷한 패턴을 구현할 수 있다. 결정적인 차이는 기능 이름이 있는지보다 팀이 필요한 동작을 얼마나 명확하게 구현·검증·유지할 수 있는가에 있다.
비교는 같은 작은 과업과 운영 조건으로 한다
한 번의 인상적인 데모보다 같은 입력을 반복해서 시험하는 편이 낫다. 처음부터 큰 업무 전체를 이식하기보다, 조사→근거 정리→검토처럼 작은 과업을 정해 다음 항목을 비교해 볼 수 있다.
- 같은 요구사항에서 어떤 출처와 도구 실행 기록을 남기는가?
- 자료를 찾지 못하거나 도구가 실패했을 때 어떻게 멈추는가?
- 사람이 수정·승인한 뒤 작업을 이어갈 수 있는가?
- 실행 비용과 지연, 재시도 횟수를 파악할 수 있는가?
- 외부 전송이나 수정 권한을 필요한 범위로 제한할 수 있는가?
같은 모델을 사용해도 프레임워크 내부 프롬프트나 기본 설정이 다를 수 있다. 따라서 이런 비교도 모든 변수가 통제된 보편적 성능 순위가 아니라, 자신의 업무에 맞는 적합성 시험으로 이해해야 한다.
모든 프레임워크를 깊게 익힌 뒤에야 일을 시작할 필요는 없다. 후보 하나로 작은 과업을 만들고, 충족되지 않는 요구가 확인됐을 때 다른 후보를 검토해도 된다. 장기적으로 남길 것은 특정 도구의 문법만이 아니라, 역할·상태·도구 권한·검증 기준을 설명할 수 있는 설계다.
함께 읽으면 좋은 글
FAQ
AI 에이전트 프레임워크 중 하나만 배워도 되나요?
처음부터 모두 깊게 배울 필요는 없다. 대표 과업을 정하고 후보 하나로 시작하되, 역할·도구·상태·검증 같은 공통 개념을 익히면 다른 도구로 옮길 때도 도움이 된다.
AutoGen을 지금 새 프로젝트에 추천해도 되나요?
현재 공식 README는 유지보수 종료와 Microsoft Agent Framework로의 이동을 안내한다. 신규 도입은 이 안내와 후속 프레임워크를 먼저 확인해야 한다. 기존 시스템은 의존성과 이전 범위를 별도로 검토한다.
CrewAI는 데모용이고 LangGraph만 운영용인가요?
그렇게 나눌 수는 없다. CrewAI도 Crews와 Flows를 통해 업무 실행과 제어를 안내한다. 어떤 도구를 쓰든 인증·권한·출처 검증·장애 복구 등 운영 조건을 구현하고 시험해야 한다.
OpenAI Agents SDK는 OpenAI 모델에서만 쓸 수 있나요?
현재 공식 README는 여러 모델 제공자와의 연동을 안내한다. 다만 모델 연동과 특정 호스팅 도구의 사용 가능 범위는 다르므로, 필요한 기능별로 지원 조건을 확인해야 한다.
참고자료
- 노마드 코더, 2025년 AI 에이전트 프레임워크 비교 원본 영상
- CrewAI 공식 저장소
- AutoGen 공식 유지보수 안내
- Microsoft Agent Framework 공식 저장소
- AutoGen에서 Microsoft Agent Framework로 이전하는 공식 가이드
- OpenAI Agents SDK 공식 저장소
- Google ADK Python 공식 저장소
- LangGraph 공식 저장소
본문 이미지는 원본 영상의 설명을 인용·비평하기 위한 캡처다. 제작자의 경험과 선호, 현재 공식 자료에서 확인한 기능·유지보수 안내, 이 글의 실무 적용 제안을 구분했으며 독립적인 성능 벤치마크를 수행한 것은 아니다.