여러 에이전트를 팀으로 — 멀티 에이전트

한 에이전트에 다 시키면 산만해진다

5장까지 에이전트 하나에 도구를 붙여 일을 시켰습니다. 그런데 일이 복잡해지면, 한 에이전트에게 리서치도 하고 글도 쓰고 검토까지 시키면 결과가 어정쩡해집니다.

사람 팀을 떠올리면 쉽습니다. 조사하는 사람, 쓰는 사람, 검토하는 사람이 나뉘어 있으면 각자 자기 일에 집중해 품질이 올라가죠. 멀티 에이전트는 이 팀 구성을 AI로 옮기는 일입니다.

여기서 AI 루프 엔지니어링 시리즈의 "역할 분리 루프"가 그대로 확장됩니다. 그때는 한 AI에게 역할을 번갈아 맡겼다면, 이번엔 아예 역할별로 다른 에이전트를 세워 서로 넘겨주게 합니다.

어떻게 나누나 — 두 가지 기본형

역할을 나누는 방식은 크게 두 가지입니다.

구조	흐름	잘 맞는 일
파이프라인	리서처 → 작성자 → 검토자 순서로 넘김	단계가 정해진 일(보고서, 콘텐츠)
매니저-워커	매니저가 일을 쪼개 워커들에게 분배·취합	병렬로 나눌 수 있는 일(여러 주제 조사)

파이프라인은 공장 컨베이어처럼 순서대로 흐릅니다. 매니저-워커는 팀장이 일을 나눠주고 결과를 모으는 방식이죠. 대부분의 업무는 이 둘 중 하나, 또는 둘의 조합으로 풀립니다.

매니저-워커가 빛나는 순간은 "같은 일을 여러 대상에" 해야 할 때입니다. 예를 들어 경쟁사 다섯 곳을 조사한다면, 매니저가 회사별로 워커 하나씩 붙여 동시에 조사시키고 결과만 모읍니다. 순서대로 하나씩 하는 것보다 훨씬 빠릅니다. 대신 워커가 늘수록 관리와 비용도 같이 늘어난다는 걸 염두에 둬야 합니다.

예시 — 콘텐츠 만드는 3-에이전트 팀

블로그 글 하나를 만드는 팀을 짜 보겠습니다.

• 리서처 에이전트: 주제를 검색해 근거와 통계를 모아 정리한다.
• 작성자 에이전트: 그 자료만 근거로 초안을 쓴다.
• 검토자 에이전트: 초안을 정해진 기준으로 채점하고, 약한 부분만 지적한다.

리서처가 모은 자료가 작성자에게, 작성자의 초안이 검토자에게 넘어갑니다. 각 에이전트는 자기 역할의 프롬프트와 도구만 갖습니다. 리서처에게는 검색 도구를, 작성자에게는 문서 도구를 주는 식이죠.

무엇으로 만드나

CrewAI 같은 도구는 이런 에이전트 팀을 짜는 데 특화돼 있습니다. 역할·목표·협업 순서를 정해 주면 여러 에이전트가 서로 넘겨주며 일합니다. 코드가 부담스러우면 n8n에서도 노드를 여러 개 이어 비슷한 흐름을 만듭니다.

도구 선택보다 중요한 건 "역할을 어떻게 쪼갤지"입니다. 그 설계만 분명하면 어떤 도구로도 옮길 수 있습니다.

나눈다고 늘 좋은 건 아니다

한 가지 함정을 짚고 갑니다. 역할을 잘게 쪼갤수록 좋아 보이지만, 두 단계면 될 일을 다섯 에이전트로 나누면 배보다 배꼽이 큽니다. 에이전트끼리 넘겨주는 사이 정보가 새고, 호출은 늘고, 디버깅은 어려워집니다.

기준은 간단합니다. 한 에이전트가 버거워하거나 결과가 어정쩡할 때만 나누세요. 잘 돌아가는 단일 에이전트를 굳이 쪼갤 이유는 없습니다.

증상도 뚜렷합니다. 에이전트를 늘렸는데 결과는 그대로이고 속도만 느려졌다면, 나눌 필요가 없던 일을 쪼갠 겁니다. 반대로 한 에이전트의 출력이 이것저것 섞여 초점을 잃었다면, 그때가 역할을 나눌 신호입니다. 팀을 먼저 크게 짜기보다, 둘로 시작해 필요할 때 늘리는 편이 안전합니다.

다음 챕터에서는 스스로 도구를 쓰는 에이전트가 잘못된 행동이나 무한 실행으로 폭주하지 않게 막는 가드레일을 다루겠습니다.