에이전트 하나로는 안 되는 일이 있어요.
기획하고, 코드를 짜고, 그 결과를 검증하는 일을 동시에 잘하는 에이전트를 하나 만들려고 하면 프롬프트가 산더미가 되거든요. 그래서 나온 답이 역할을 쪼개는 거예요. 기획자, 개발자, 검수자 역할을 각각의 에이전트에게 맡기고 서로 협업하게 만드는 멀티 에이전트 워크플로우가 요즘 화두인 이유가 여기에 있어요. 실제로 구글 클라우드의 2026년 설문을 보면 기업의 70%가 이미 프로덕션 환경에서 AI 에이전트를 운영 중이라고 답했더라고요. 2024년 초만 해도 20%가 안 됐었는데 말이에요.
문제는 "그래서 어떻게 만드냐"는 거예요. CrewAI와 AutoGen, 이름은 다들 들어봤지만 실제로 기획자-개발자-검수자 구조를 어떻게 짜야 하는지는 막상 손에 잘 안 잡혀요.
CrewAI와 AutoGen, 협업을 다루는 방식이 다릅니다
두 프레임워크는 출발점 자체가 달라요.
CrewAI는 에이전트를 '팀'으로 모델링해요. 각 에이전트한테 role(역할), goal(목표), backstory(배경 설정)를 부여하고 이들을 crew로 묶어서 작업을 맡기는 방식이에요. 사람이 업무를 위임하는 방식과 비슷하게 사고할 수 있다는 게 강점이에요. 2026년 3월 기준 깃허브 스타 4만 5,900개를 넘었고, 최신 버전은 1.10.1까지 나왔어요.
CrewAI의 핵심 구성요소는 네 가지예요. Agent(역할·목표·도구를 가진 주체), Task(작업 설명과 기대 결과물), Crew(이들을 담는 컨테이너), 그리고 Process(실행 순서를 정하는 엔진)요. Process에는 두 종류가 있는데, 하나씩 순서대로 처리하는 Sequential과, 매니저 에이전트가 동적으로 작업을 쪼개고 배분하는 Hierarchical이에요. 기획자-개발자-검수자 구조를 짤 때는 보통 Hierarchical 쪽을 씁니다. 매니저(기획자) 에이전트가 목표를 읽고 하위 작업으로 나눠서 워커 에이전트들에게 분배하고, 결과를 검증하는 흐름을 따로 하드코딩하지 않아도 알아서 진행하거든요.
반면 AutoGen은 대화 중심(conversation-driven) 패턴을 씁니다. UserProxyAgent, AssistantAgent, 그리고 필요하면 Critic 에이전트까지 구조화된 대화를 주고받으며 문제를 풀어요. AutoGen에서 Planner, Executor, Critic 에이전트를 띄워 자율적으로 대화하게 만드는 패턴이 대표적인 예시예요. Critic 에이전트는 다른 에이전트가 내놓은 계획이나 코드를 재검토하고 피드백을 주는 역할을 맡습니다.
그런데 여기서 한 가지 변화를 짚어야 해요. 2025년 10월, 마이크로소프트가 AutoGen과 Semantic Kernel(엔터프라이즈용 SDK)을 통합한 "Microsoft Agent Framework"를 발표했고, 2026년 4월 3일 정식 버전 1.0이 출시됐어요. 이 통합 이후 AutoGen과 Semantic Kernel은 둘 다 유지보수 모드로 전환됐습니다. 버그 수정은 계속되지만 새 기능은 더 안 들어가는 거예요. 신규 기능이 필요하면 사실상 Microsoft Agent Framework로 넘어가야 하는 구조고요. 다만 연구나 프로토타입 목적이라면 AutoGen v0.7.5도 여전히 쓸 만하다는 의견도 있어요.
정리하면, 워크플로우가 대체로 선형적이고 빠른 프로토타입이 필요하면 CrewAI가 맞아요. 반면 그룹 토론이나 합의 형성처럼 대화형 패턴이 핵심이라면 AutoGen 계열(혹은 그 후속인 Agent Framework)이 더 잘 맞습니다.
기획자-개발자-검수자, 실제로는 이렇게 돌아갑니다
말로만 들으면 추상적인데, 실제 구현 사례를 보면 흐름이 꽤 명확해요.
CrewAI 쪽 코드북 예시를 보면, 매니저 에이전트(기획자 역할)가 목표를 받아서 두 명의 전문 에이전트에게 작업을 위임하는 구조가 나와요. 예를 들어 "특정 주제를 조사해서 보고서를 쓰라"는 목표를 주면, 매니저가 이걸 리서치 작업과 작성 작업으로 쪼개서 각각 다른 에이전트한테 맡기고, 결과를 합쳐서 최종본을 만드는 식이에요. 여기에 검수자 역할의 에이전트를 하나 더 추가하면, 개발자(작성자) 에이전트가 만든 결과물을 검수자가 한 번 더 점검하고 피드백을 주는 구조로 확장할 수 있어요.
AutoGen 쪽은 좀 다른 그림이에요. GroupChat을 구성해서 여러 에이전트가 한 대화방에 모여있는 것처럼 만들고, speaker_selection_method로 누가 다음에 말할지 정하는 방식이에요. 코드를 짜는 에이전트, 그걸 비평하는 Critic 에이전트, 필요하면 웹에서 맥락을 찾아오는 에이전트까지 한 대화 안에서 핑퐁을 주고받게 만들 수 있어요. 마이크로소프트의 공식 예제 중에는 "코드 작성 에이전트 + 시각화 결과를 비평하는 Critic 에이전트"로 구성된 사례도 있어요. 검수자가 코드를 보고 "이 그래프는 라벨이 빠졌다"고 지적하면 작성자가 다시 고치는 식의 피드백 루프가 자연스럽게 만들어지는 거죠.
AWS 기술 블로그에 나온 'Deep Insight' 아키텍처 사례도 참고할 만해요. 여기서는 감독(Supervisor) 에이전트가 시스템 프롬프트에 엄격한 실행 순서를 못 박아 둬요. Coder가 작업하면 무조건 Tracker로 넘기고, Tracker가 진행 상태를 확인한 다음에야 Validator(검수)로 넘어가고, 다시 Tracker를 거쳐 Reporter로 가는 식이에요. 핵심은 이거예요. 현재 에이전트의 체크리스트가 다 끝나야만 다음 단계로 넘어간다는 규칙을 강제하는 거죠. 이 구조는 도메인에 종속되지 않아서, 에이전트 역할과 프롬프트만 바꾸면 기획-개발-검수가 아닌 다른 업무에도 그대로 재활용할 수 있다고 설명돼 있어요.
AI 에이전트 개발 관련 커뮤니티나 기술 블로그를 보면 공통적으로 강조하는 게 하나 있어요. "역할을 명확히 나누는 것보다 더 중요한 건, 한 단계가 끝났다는 걸 어떻게 확인시키느냐"라는 점이에요. 검수자 에이전트한테 단순히 "검토해줘"라고만 시키면 통과 기준이 모호해서 다음 단계로 넘어가도 되는지 판단이 흔들리거든요. expected_output(기대 결과물)을 구체적으로 못 박아두는 게 결국 핵심이라는 얘기가 많이 나와요.
시작 전에 알아야 할 비용과 실패 패턴
멀티 에이전트가 마냥 좋은 것만은 아니에요. 여기서 발이 걸리는 경우가 생각보다 많습니다.
멀티 에이전트 시스템 신뢰성을 분석한 MAST 연구는 2025년 3월에 나왔는데, 7개 오픈소스 프레임워크에서 1,642개의 실행 트레이스를 분석했더니 실패율이 41%에서 86.7%까지 나왔다고 해요. 그중 가장 큰 실패 유형이 코디네이션(협업 조율) 붕괴였는데, 전체 실패의 36.9%를 차지했습니다. 역할을 나눠놨는데 막상 서로 손발이 안 맞아서 실패하는 경우가 가장 많다는 뜻이에요.
비용 문제도 꽤 현실적이에요. 에이전트 간 통신 한 번이 LLM 호출 한 번과 같아서, 코디네이터를 통해 조율하는 10개 에이전트 시스템은 작업 하나에 50~100번의 LLM 호출이 발생할 수 있어요. 독립적으로 동작하는 구성은 토큰 오버헤드가 약 58% 정도지만, 중앙화된 구성은 약 285%까지 치솟는다는 분석도 있고요. 에이전트가 4개를 넘어가면 조율 비용이 협업으로 얻는 이득을 갉아먹는 지점이 온다는 얘기도 나와요.
에러 전파도 무시 못 할 위험이에요. 리서치 단계에서 환각(잘못된 정보)이 하나 생기면 그게 다음 단계인 분석·작성 단계로 그대로 흘러가거든요. 멀티 에이전트 협업은 결국 의존성 그래프라서, 한 군데서 생긴 거짓 정보가 시스템 전체의 거짓 합의로 퍼질 수 있다는 점을 염두에 둬야 해요.
| 항목 | CrewAI | AutoGen / Agent Framework |
|---|---|---|
| 협업 모델 | 역할 기반 팀(crew) | 대화 중심(conversation) |
| 실행 순서 결정 | Sequential / Hierarchical | Sequential / Concurrent / Handoff / Group Chat |
| 적합한 상황 | 선형적 워크플로우, 빠른 프로토타입 | 그룹 토론, 합의 형성, 복잡한 추론 |
| 2026년 현황 | 활발한 신규 개발 진행 중 | 유지보수 모드, 후속은 Agent Framework |
CrewAI든 AutoGen이든 공통적으로 보고되는 단점도 있어요. CrewAI는 작업 정의가 부실하면 에이전트가 같은 단계를 진전 없이 반복 시도하는데, 가시성이 낮아서 이걸 알아채기가 어렵다는 지적이 있어요. AutoGen은 대화가 끝나지 않고 루프에 빠지는 경우가 있고, 실행마다 출력 형식이 달라지는 일관성 문제도 보고됩니다.
결국 멀티 에이전트는 작업에 전문화가 필요하거나, 의사결정을 분리해야 하거나, 에이전트마다 권한이 달라야 할 때 고려할 가치가 있어요. 비용은 단일 에이전트 대비 3~10배까지 늘어날 수 있다는 점, 그리고 통신 불안정성 위험이 있다는 점은 시작하기 전에 분명히 알고 가야 합니다.
결국 역할보다 검증 기준이 먼저예요
기획자-개발자-검수자 구조를 만드는 건 사실 어렵지 않아요. CrewAI든 AutoGen이든 며칠이면 데모는 돌립니다.
진짜 어려운 건 그 다음이에요. 검수자가 "통과"라고 판단하는 기준을 누가, 어떻게, 얼마나 구체적으로 정의하느냐가 전체 시스템의 신뢰도를 좌우하더라고요.
역할을 셋으로 나눴다고 문제가 셋으로 쪼개져서 쉬워지는 게 아니에요. 오히려 조율 비용이라는 새로운 문제가 하나 더 생기는 거죠.
그래서 처음 설계할 때는 에이전트 수보다 expected_output(기대 결과물) 정의에 시간을 더 써보길 권해요. 결국 코디네이션이 무너지는 지점이 거기서부터 시작되니까요.
참고: AWS 기술 블로그, Microsoft Learn (Agent Framework)