에이전트 팀 디자인 패턴

얼마 전 Claude Code에 harness 플러그인을 설치하고 레퍼런스 문서를 뒤지다가 Agent Team Design Patterns라는 문서를 발견했다. 멀티 에이전트 아키텍처 패턴을 6가지로 분류하고, 각각의 적합한 상황과 주의점까지 깔끔하게 정리해둔 글이다. 참 잘 정리했다는 생각이 들었다.

이 글에서는 해당 문서를 기반으로, 6가지 패턴을 인터랙티브 데모와 함께 풀어본다.

먼저 알아야 할 것 — Agent Team vs Sub-agent

멀티 에이전트를 구성하는 방식은 크게 두 가지다.

Agent Team은 팀 리더가 TeamCreate로 팀을 구성하고, 팀원들이 독립 인스턴스로 실행되면서 SendMessage로 직접 통신한다. TaskCreate/TaskUpdate로 공유 작업 목록을 관리하며 자체 조율한다. 한 팀원의 발견이 다른 팀원의 작업 방향을 실시간으로 바꿀 수 있다.

다만 제약이 있다. 세션당 활성 팀은 하나뿐이고, 팀원이 자신의 팀을 만드는 중첩은 불가능하다. 리더도 고정이다. 그리고 팀원마다 독립 컨텍스트를 유지하므로 토큰 비용이 높다.

Sub-agent는 메인 에이전트가 Agent 도구로 서브 에이전트를 생성하고, 결과만 돌려받는 구조다. 서브 에이전트끼리는 통신하지 않는다. 가볍고 빠르지만, 실시간 협업은 불가능하다.

핵심 판단 기준은 하나다. 에이전트 간 통신이 필요한가? 필요하면 Agent Team, 필요 없으면 Sub-agent로도 충분하다.

이제 구체적인 패턴을 하나씩 살펴보자.

1. Pipeline — 순차 흐름

가장 직관적인 패턴이다. 이전 에이전트의 출력이 다음 에이전트의 입력이 된다. 공장의 컨베이어 벨트를 떠올리면 된다.

적합한 경우

각 단계가 이전 단계의 산출물에 강하게 의존할 때 사용한다. 단계별 전문성이 명확히 다르고, 순서를 건너뛸 수 없는 작업에 적합하다.

주의점

한 단계가 느리면 전체 파이프라인이 지연된다. 각 단계를 가능한 독립적으로 설계하고, 병목이 될 수 있는 단계를 미리 파악해두자. 순차 의존이 강해서 Agent Team의 이점이 제한적이다. 다만, 파이프라인 내부에 병렬 구간이 있으면 팀 모드가 유용해진다.

예시 — 소설 집필

세계관 설정 -> 캐릭터 생성 -> 플롯 구성 -> 집필 -> 편집. 세계관 없이 캐릭터를 만들 수 없고, 캐릭터 없이 플롯을 짤 수 없다. 전형적인 파이프라인이다.

2. Fan-out/Fan-in — 병렬 분기 후 통합

하나의 입력을 여러 에이전트에 동시에 보내고, 결과를 합치는 패턴이다. 같은 문제를 서로 다른 관점에서 동시에 분석할 때 강력하다.

적합한 경우

동일 입력에 대해 서로 다른 관점이나 영역의 분석이 필요할 때 사용한다. 독립적으로 수행 가능한 작업이 여러 개일 때 가장 효과적이다.

주의점

통합(Fan-in) 단계의 품질이 전체 품질을 결정한다. 아무리 개별 분석이 훌륭해도 통합이 부실하면 의미가 없다. 이 패턴은 Agent Team의 가장 자연스러운 형태다. 팀원들이 서로 발견을 공유하고, 한 에이전트의 발견이 다른 에이전트의 조사 방향을 실시간으로 수정할 수 있어 단독 조사 대비 품질이 크게 향상된다.

예시 — 종합 리서치

어떤 기술에 대한 종합 보고서를 작성한다고 하자. 공식 문서 조사, 미디어/블로그 조사, 커뮤니티 반응 조사, 기술적 배경 조사를 4개 에이전트가 동시에 수행한다. 마지막에 통합 에이전트가 모든 결과를 종합 보고서로 합친다.

3. Expert Pool — 조건부 라우팅

입력 유형에 따라 적절한 전문가를 골라서 호출하는 패턴이다. 병원의 접수 데스크를 떠올리면 된다. 증상에 따라 내과, 외과, 피부과로 안내하는 것이다.

적합한 경우

입력 유형에 따라 완전히 다른 처리가 필요할 때 사용한다. 전문가마다 필요한 도구와 컨텍스트가 다른 경우에 적합하다.

주의점

라우터의 분류 정확도가 핵심이다. 잘못된 전문가에게 라우팅되면 결과가 엉뚱해진다. 이 패턴은 Sub-agent가 더 적합하다. 필요한 전문가만 호출하므로 상시 팀을 유지할 필요가 없다.

예시 — 코드 리뷰

PR이 올라오면 라우터가 변경 파일의 성격을 분석한다. 보안 관련 변경이면 보안 전문가를, 성능 관련이면 성능 전문가를, 아키텍처 변경이면 아키텍처 전문가를 호출한다. 모든 리뷰에 모든 전문가를 동원할 필요가 없다.

4. Producer-Reviewer — 피드백 루프

생성 에이전트가 산출물을 만들고, 검증 에이전트가 검수하고, 문제가 있으면 다시 생성하는 패턴이다. 우리가 코드 리뷰를 주고받는 과정과 동일하다.

적합한 경우

산출물의 품질 보장이 중요하고, 객관적인 검증 기준이 존재할 때 사용한다. "좋은 결과"의 기준이 명확해야 검증 에이전트가 판단할 수 있다.

주의점

무한 루프 방지가 필수다. 최대 재시도 횟수를 2~3회로 설정하지 않으면, 생성자와 검증자가 끝없이 핑퐁하는 사태가 벌어진다. Agent Team을 사용하면 생성자와 검증자 간 실시간 피드백으로 재작업을 최소화할 수 있다.

예시 — 웹툰 제작

아티스트 에이전트가 패널을 생성하면, 리뷰어 에이전트가 스타일 일관성, 캐릭터 비율, 대사 배치를 검수한다. 문제가 있는 패널만 재생성 요청을 보낸다. 3회 재시도 후에도 통과하지 못하면 사람이 개입한다.

5. Supervisor — 동적 작업 분배

중앙의 감독자 에이전트가 작업 상태를 모니터링하면서, 하위 워커들에게 동적으로 작업을 분배하는 패턴이다. 비슷해 보이는 두 패턴과의 차이를 짚고 가자. Fan-out은 사전에 작업을 고정 분배하지만, Supervisor는 진행 상황을 보며 실시간으로 조정한다. Expert Pool은 입력 유형에 따라 다른 전문가를 호출하지만, Supervisor는 워커의 가용 상태에 따라 같은 종류의 작업을 분배한다. 병원이 Expert Pool이라면, Supervisor는 콜센터다 — 빈 상담원에게 다음 전화를 연결하는 것이다.

적합한 경우

작업량이 가변적이거나, 런타임에 작업 분배를 결정해야 할 때 사용한다. 어떤 워커가 빨리 끝나면 다음 작업을 배정하고, 실패하면 다른 워커에게 재할당하는 유연성이 핵심이다.

주의점

감독자가 병목이 되지 않도록 위임 단위를 충분히 크게 설정해야 한다. 파일 하나씩 할당하면 감독자가 바쁘게 분배만 하느라 전체 처리량이 떨어진다. Agent Team의 공유 작업 목록이 감독자 패턴과 자연스럽게 맞는다.

예시 — 대규모 코드 마이그레이션

레거시 코드베이스를 새 프레임워크로 마이그레이션한다고 하자. 감독자가 전체 파일 목록을 분석하고, 워커들에게 모듈 단위로 배치를 할당한다. 한 워커가 예상보다 빨리 끝나면 다음 배치를 받고, 다른 워커가 복잡한 모듈에서 막히면 감독자가 보조 워커를 투입한다.

6. Hierarchical Delegation — 재귀적 위임

상위 에이전트가 하위 에이전트에게 재귀적으로 위임하는 패턴이다. 복잡한 문제를 계층적으로 분해해서, 각 레벨에서 더 세부적인 작업을 처리한다. 회사 조직도를 떠올리면 된다.

적합한 경우

문제가 자연스럽게 계층적으로 분해되는 구조일 때 사용한다. 도메인별로 명확히 분리되고, 각 도메인 내에서 다시 세부 작업으로 나뉘는 프로젝트에 적합하다.

주의점

깊이 3단계 이상은 지연과 컨텍스트 손실이 커진다. 2단계 이내로 유지하는 것이 좋다. Agent Team은 중첩이 불가능하므로(팀원이 자신의 팀을 생성할 수 없다), 1단계는 팀으로, 2단계는 Sub-agent로 구현하거나, 아예 평탄화해서 단일 팀으로 구성하는 방법을 고려하자.

예시 — 풀스택 앱 개발

총괄 에이전트가 프론트엔드 팀장과 백엔드 팀장에게 위임한다. 프론트엔드 팀장은 다시 UI 구현, 상태 관리, 테스트 작성 에이전트에게 위임하고, 백엔드 팀장은 API 설계, DB 스키마, 통합 테스트 에이전트에게 위임한다.

복합 패턴 — 실전은 조합이다

실전에서 단일 패턴만 딱 맞아떨어지는 경우는 드물다. 대부분의 복잡한 작업은 여러 패턴을 조합해서 사용한다. 몇 가지 실전에서 자주 보이는 조합을 살펴보자.

Fan-out + Producer-Reviewer — 다국어 번역

4개 언어로 병렬 번역(Fan-out)한 뒤, 각 번역 결과를 네이티브 리뷰어가 검수(Producer-Reviewer)하는 구조다. 병렬성과 품질 보장을 동시에 잡는다.

Pipeline + Fan-out — 분석에서 구현까지

요구사항 분석은 순차(Pipeline)로 진행하고, 분석이 끝나면 여러 모듈을 병렬(Fan-out)로 구현한다. 구현이 끝나면 다시 순차로 통합 테스트를 돌린다. 파이프라인 내부에 병렬 구간을 끼워넣는 가장 흔한 형태다.

Supervisor + Expert Pool — 고객 문의 처리

감독자가 들어오는 문의를 실시간으로 분류하고(Supervisor), 문의 유형에 맞는 전문가에게 라우팅(Expert Pool)한다. 문의량이 들쑥날쑥해도 감독자가 동적으로 조율한다.

복합 패턴에서의 실행 모드

기본적으로 모든 복합 패턴에 Agent Team을 사용한다. 팀원 간 커뮤니케이션이 결과 품질의 핵심 동력이다.

서브 에이전트와의 혼합은 단일 에이전트가 완전히 격리된 단발성 작업을 수행할 때만 고려한다. 또한, Phase별로 다른 전문가 조합이 필요하면 이전 팀의 산출물을 파일로 저장한 뒤 팀을 정리하고 새 팀을 구성하는 팀 재구성 패턴도 가능하다.

에이전트를 어떻게 나눌 것인가

패턴을 골랐으면, 다음 질문은 "에이전트를 몇 개로, 어떻게 나눌까?"다. 원문에서는 4가지 기준을 제시한다.

4가지 중 하나라도 "분리"에 해당하면 분리하는 쪽이 안전하다. 애매하면 일단 통합하고, 문제가 생기면 그때 나누자.

패턴 비교 요약표

어떤 패턴이든 결국 핵심은 같다. 에이전트를 어떻게 나누고, 어떻게 연결하고, 결과를 어떻게 합치느냐. 작업의 성격을 먼저 파악하고, 가장 단순한 패턴부터 시도해보자. 복잡한 패턴이 항상 좋은 건 아니다. 파이프라인 하나로 충분한 작업에 계층적 위임을 적용하면 오히려 느려진다. 단순함에서 시작해서, 필요할 때만 복잡도를 올리자.