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

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

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

사람 팀을 떠올리면 쉽다

조사하는 사람, 쓰는 사람, 검토하는 사람이 나뉘어 있으면 각자 자기 일에 집중해 품질이 올라갑니다. 멀티 에이전트는 이 팀 구성을 AI로 옮기는 일입니다. 한 명에게 세 역할을 몰아주면 초점이 흐려지듯, 에이전트도 역할이 섞이면 어느 것 하나 제대로 못 합니다.

역할 분리 루프의 확장

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

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

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

파이프라인과 매니저-워커

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

매니저-워커가 빛나는 순간

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

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

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

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

각자 자기 역할의 도구만

리서처가 모은 자료가 작성자에게, 작성자의 초안이 검토자에게 넘어갑니다. 각 에이전트는 자기 역할의 프롬프트와 도구만 갖습니다. 리서처에게는 검색 도구를, 작성자에게는 문서 도구를 주는 식이죠. 검토자에게는 아예 쓰기 도구를 주지 않아, 지적만 하고 직접 고치지는 못하게 합니다. 이렇게 도구를 역할별로 좁히면 사고 범위도 함께 줄어듭니다.

넘길 때 정보가 새지 않게

에이전트 사이에서 결과를 넘길 때 가장 흔한 문제가 "전달 유실"입니다. 리서처가 열 개를 조사했는데 작성자에게 넘어갈 땐 두루뭉술한 요약만 가서, 정작 중요한 수치와 출처가 빠지는 식이죠. 사람 팀에서 인수인계가 부실하면 뒷사람이 헤매는 것과 똑같습니다.

이를 줄이려면 넘김의 "형식"을 못 박습니다. 예를 들어 리서처에게 "각 항목을 출처·수치·한 줄 요약 세 칸의 표로 넘겨라"라고 정해 두면, 뒤 에이전트가 받아야 할 것을 놓치지 않습니다. 형식이 없으면 에이전트마다 제멋대로 요약해 넘겨, 단계를 거칠수록 원본이 흐려집니다. 넘김 형식 한 줄을 정하는 것만으로 협업 품질이 눈에 띄게 올라갑니다.

무엇으로 만드나

CrewAI와 n8n

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

전용 프레임워크 고르기

에이전트 팀을 짜는 데 특화된 도구들도 있습니다. 성격이 조금씩 다릅니다.

빠른 프로토타이핑엔 진입 장벽이 낮은 CrewAI, 운영급 상태 관리엔 가장 검증된 LangGraph가 흔히 꼽힙니다. 단 Microsoft는 2026년 AutoGen을 유지보수 모드로 돌리고 더 큰 Microsoft Agent Framework로 방향을 옮겼으니, 새로 시작한다면 참고하세요. (출처: Turing·DataCamp 2026 프레임워크 비교)

도구보다 역할 설계가 먼저

도구 선택보다 중요한 건 "역할을 어떻게 쪼갤지"입니다. 종이에 "누가 무엇을 받아 무엇을 넘기는지"를 먼저 그려 보세요. 그 설계만 분명하면 어떤 도구로도 옮길 수 있습니다.

나눈다고 늘 좋은 건 아니다

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

나눌 신호와 합칠 신호

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

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