본문으로 건너뛰기
Kreath Archive
TechProjectsBooksAbout
TechProjectsBooksAbout
© 2026 Kreath
홈TechProjectsBooksAbout
//
  1. 홈
  2. 테크
  3. 2장: 멀티에이전트 팀 아키텍처 설계
2026년 3월 24일·AI / ML·

2장: 멀티에이전트 팀 아키텍처 설계

감독자-워커, 계층적 팀, 피어-투-피어 네트워크 등 멀티에이전트 팀 아키텍처의 설계 원칙과 트레이드오프를 코드 예제와 함께 분석합니다.

20분465자7개 섹션
ai-에이전트멀티에이전트오케스트레이션팀-아키텍처
공유
agent-orchestration2 / 11
1234567891011
이전1장: 멀티에이전트 오케스트레이션의 진화와 핵심 개념다음3장: 에이전트 간 통신 프로토콜 — A2A, MCP, 커스텀 패턴

팀 아키텍처의 선택이 중요한 이유

멀티에이전트 시스템에서 팀 아키텍처는 건물의 골조와 같습니다. 한번 결정되면 이후의 모든 설계 결정에 영향을 미치며, 나중에 변경하기 어렵습니다. 잘못된 아키텍처는 에이전트 간의 불필요한 통신을 유발하고, 단일 장애점을 만들며, 시스템 확장을 가로막습니다.

아키텍처 선택에서 고려해야 할 핵심 축은 세 가지입니다.

제어의 집중도: 의사결정이 중앙에 집중되는가, 분산되는가? 중앙 집중은 일관성이 높지만 병목이 생기고, 분산은 확장성이 좋지만 조율이 어렵습니다.

통신 토폴로지: 에이전트 간 누가 누구와 통신할 수 있는가? 스타 구조, 메시 구조, 트리 구조 각각의 통신 복잡도와 지연시간이 다릅니다.

전문화 수준: 에이전트가 얼마나 좁은 영역을 담당하는가? 과도한 전문화는 에이전트 수를 늘리고 조율 비용을 높이며, 부족한 전문화는 단일 에이전트의 한계를 반복합니다.

감독자-워커 패턴(Supervisor-Worker)

가장 널리 사용되는 아키텍처입니다. 중앙의 감독자(Supervisor) 에이전트가 사용자 요청을 분석하고, 적절한 워커(Worker) 에이전트에게 작업을 위임합니다.

기본 구조

python
from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent
 
# 워커 에이전트 정의
research_agent = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[web_search, document_reader],
    name="researcher",
    prompt="최신 기술 동향을 조사하는 리서치 전문가입니다."
)
 
writer_agent = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[text_editor, grammar_checker],
    name="writer",
    prompt="조사 결과를 정리하여 기술 문서를 작성하는 전문가입니다."
)
 
reviewer_agent = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[fact_checker, style_validator],
    name="reviewer",
    prompt="작성된 문서의 정확성과 품질을 검증하는 전문가입니다."
)
 
# 감독자가 워커를 조율
supervisor = create_supervisor(
    agents=[research_agent, writer_agent, reviewer_agent],
    model="claude-opus-4-6",
    prompt="""당신은 기술 문서 제작팀의 관리자입니다.
    사용자 요청을 분석하여 적절한 전문가에게 작업을 할당하세요.
    리서치 → 작성 → 검토 순서를 따르되, 검토에서 문제가 발견되면
    해당 단계로 돌아가 수정을 요청하세요."""
)
 
app = supervisor.compile()

감독자의 역할

감독자 에이전트는 단순한 라우터가 아닙니다. 다음과 같은 고차원 기능을 수행합니다.

작업 분해(Task Decomposition): "이번 분기 AI 트렌드 보고서를 작성해줘"라는 요청을 "트렌드 조사 → 데이터 수집 → 초안 작성 → 검토 → 수정"의 하위 작업으로 분해합니다.

동적 라우팅(Dynamic Routing): 현재 상태와 이전 결과를 바탕으로 다음에 어떤 워커를 호출할지 결정합니다. 검토 결과가 "수정 필요"이면 작성자에게 돌려보냅니다.

결과 종합(Result Synthesis): 여러 워커의 결과를 모아 최종 응답을 구성합니다.

품질 게이트(Quality Gate): 워커의 출력이 기준에 미달하면 재작업을 요청합니다.

python
# 감독자의 동적 라우팅 로직 예시
supervisor_prompt = """
현재 상태를 분석하여 다음 행동을 결정하세요:
 
1. 리서치가 아직 안 되었다면 → researcher에게 위임
2. 리서치가 완료되었고 초안이 없다면 → writer에게 위임
3. 초안이 있고 검토가 안 되었다면 → reviewer에게 위임
4. 검토 결과 수정이 필요하면 → writer에게 피드백과 함께 재위임
5. 검토가 통과되었다면 → 최종 결과 반환
 
최대 재작업 횟수는 2회입니다. 2회 수정 후에도 미흡하면
현재 상태의 최선의 결과를 반환하세요.
"""

장단점 분석

장점단점
제어 흐름이 명확하고 예측 가능감독자가 단일 장애점(SPOF)
디버깅과 모니터링이 용이감독자의 LLM 호출이 병목
일관된 품질 관리 가능워커 수 증가 시 감독자 부담 증가
구현이 상대적으로 단순감독자의 판단력에 전체 품질 의존
Tip

감독자 에이전트에는 더 강력한 모델을 사용하세요. 워커는 claude-sonnet-4-6으로 충분한 경우가 많지만, 감독자의 라우팅과 종합 판단에는 claude-opus-4-6이 효과적입니다.

계층적 팀 패턴(Hierarchical Teams)

감독자-워커 패턴을 다층으로 확장한 형태입니다. 상위 감독자가 하위 감독자 팀을 관리하고, 각 하위 감독자는 자신의 워커 팀을 운영합니다. 기업의 조직도와 유사한 구조입니다.

다층 구조 설계

python
# 하위 팀 1: 리서치 팀
web_researcher = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[web_search, url_fetcher],
    name="web_researcher",
    prompt="웹에서 최신 정보를 검색하고 수집합니다."
)
 
paper_analyst = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[arxiv_search, pdf_reader],
    name="paper_analyst",
    prompt="학술 논문을 검색하고 핵심 내용을 분석합니다."
)
 
research_supervisor = create_supervisor(
    agents=[web_researcher, paper_analyst],
    model="claude-sonnet-4-6",
    prompt="리서치 팀을 관리합니다. 웹 조사와 논문 분석을 조율합니다."
)
 
# 하위 팀 2: 콘텐츠 제작 팀
outline_writer = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[outline_generator],
    name="outline_writer",
    prompt="조사 결과를 바탕으로 문서 구조를 설계합니다."
)
 
content_writer = create_react_agent(
    model="claude-sonnet-4-6",
    tools=[text_editor, image_generator],
    name="content_writer",
    prompt="설계된 구조에 따라 본문을 작성합니다."
)
 
content_supervisor = create_supervisor(
    agents=[outline_writer, content_writer],
    model="claude-sonnet-4-6",
    prompt="콘텐츠 제작 팀을 관리합니다."
)
 
# 최상위 감독자: 팀 간 조율
top_supervisor = create_supervisor(
    agents=[research_supervisor, content_supervisor, reviewer_agent],
    model="claude-opus-4-6",
    prompt="""전체 문서 제작 프로세스를 총괄합니다.
    리서치 팀의 조사 결과를 콘텐츠 팀에 전달하고,
    최종 결과를 검토자에게 보내 품질을 확인합니다."""
)

계층 설계의 원칙

관심사 분리(Separation of Concerns): 각 계층은 자신의 범위 내에서만 결정합니다. 리서치 팀의 감독자는 어떤 소스를 검색할지 결정하지만, 최종 문서의 톤은 결정하지 않습니다.

정보 추상화(Information Abstraction): 하위 팀의 상세한 실행 과정은 상위 감독자에게 요약된 형태로 전달됩니다. 최상위 감독자는 "리서치 완료, 주요 발견 3가지" 수준의 정보만 받습니다.

독립적 배포(Independent Deployment): 리서치 팀의 구성을 변경해도 콘텐츠 팀에 영향이 없습니다. 인터페이스만 유지되면 내부 구현은 자유롭게 변경할 수 있습니다.

Warning

계층이 깊어질수록 지연시간이 기하급수적으로 증가합니다. 3단계 이상의 계층은 신중하게 판단하세요. 대부분의 시나리오에서 2단계면 충분합니다.

피어-투-피어 패턴(Peer-to-Peer)

중앙 감독자 없이 에이전트들이 직접 통신하는 패턴입니다. 각 에이전트는 자신이 처리할 수 없는 작업을 다른 에이전트에게 직접 전달합니다.

핸드오프 기반 P2P

OpenAI Agents SDK의 핸드오프 메커니즘이 대표적인 P2P 구현입니다.

python
from agents import Agent, handoff
 
billing_agent = Agent(
    name="billing",
    instructions="결제 관련 문의를 처리합니다.",
    tools=[query_payment, process_refund],
    handoffs=[
        handoff(
            agent="shipping",
            description="배송 관련 문의가 포함된 경우"
        ),
        handoff(
            agent="technical",
            description="기술적 문제가 발견된 경우"
        )
    ]
)
 
shipping_agent = Agent(
    name="shipping",
    instructions="배송 추적과 물류를 관리합니다.",
    tools=[track_package, update_delivery],
    handoffs=[
        handoff(
            agent="billing",
            description="환불이 필요한 배송 사고인 경우"
        )
    ]
)
 
technical_agent = Agent(
    name="technical",
    instructions="기술적 문제를 해결합니다.",
    tools=[check_system_status, run_diagnostics],
    handoffs=[
        handoff(
            agent="billing",
            description="기술 문제로 인한 보상이 필요한 경우"
        )
    ]
)

P2P의 특성

피어-투-피어 패턴에서 각 에이전트는 자율적으로 핸드오프 결정을 내립니다. 이는 대화형 시스템에서 자연스러운 흐름을 만들어내지만, 몇 가지 위험을 내포합니다.

순환 핸드오프(Circular Handoff): A → B → C → A로 무한 순환이 발생할 수 있습니다. 이를 방지하려면 핸드오프 횟수에 상한을 두거나, 방문 이력을 추적하는 메커니즘이 필요합니다.

python
# 순환 방지 메커니즘
class HandoffTracker:
    def __init__(self, max_handoffs: int = 5):
        self.max_handoffs = max_handoffs
        self.history: list[str] = []
 
    def can_handoff(self, target: str) -> bool:
        if len(self.history) >= self.max_handoffs:
            return False
        # 같은 에이전트로 2번 이상 돌아가면 차단
        if self.history.count(target) >= 2:
            return False
        return True
 
    def record(self, target: str) -> None:
        self.history.append(target)

책임 공백(Responsibility Gap): 어떤 에이전트도 처리하지 않는 요청이 핸드오프 사이에서 떠돌 수 있습니다. 폴백 에이전트를 반드시 지정하세요.

그룹 채팅 패턴(Group Chat)

모든 에이전트가 하나의 공유 대화 공간에서 소통합니다. 선택자(Selector)가 문맥을 분석하여 다음 발언할 에이전트를 결정합니다.

그룹 채팅 구현

python
from autogen import GroupChat, GroupChatManager
 
analyst = AssistantAgent(
    name="Analyst",
    system_message="데이터를 분석하고 인사이트를 도출합니다."
)
 
engineer = AssistantAgent(
    name="Engineer",
    system_message="분석 결과를 기반으로 기술적 구현을 제안합니다."
)
 
critic = AssistantAgent(
    name="Critic",
    system_message="제안된 솔루션의 약점과 개선점을 지적합니다."
)
 
group_chat = GroupChat(
    agents=[analyst, engineer, critic],
    messages=[],
    max_round=10,
    speaker_selection_method="auto",  # LLM이 다음 발언자 결정
    allow_repeat_speaker=False        # 연속 발언 방지
)
 
manager = GroupChatManager(
    groupchat=group_chat,
    llm_config={"model": "claude-sonnet-4-6"}
)

선택자 전략

다음 발언자를 결정하는 방식에 따라 그룹 채팅의 품질이 크게 달라집니다.

전략설명적합한 상황
라운드 로빈순서대로 발언각 에이전트가 균등하게 기여해야 할 때
LLM 선택문맥 기반 다음 발언자 결정대부분의 복잡한 토론
규칙 기반특정 키워드나 상태에 따라 결정정형화된 워크플로우
자발적에이전트가 스스로 발언 필요성 판단전문가 합의 도출
Info

그룹 채팅은 브레인스토밍, 코드 리뷰, 다각적 분석처럼 여러 관점이 필요한 작업에 효과적입니다. 반면 명확한 순서가 있는 작업에는 파이프라인이나 감독자 패턴이 더 적합합니다.

하이브리드 아키텍처

실제 프로덕션 시스템에서는 단일 패턴만 사용하는 경우가 드뭅니다. 여러 패턴을 조합한 하이브리드 아키텍처가 일반적입니다.

감독자 + 핸드오프 조합

[감독자]
  ├── [분석 팀] (감독자-워커)
  │     ├── 데이터 분석가
  │     └── 시각화 전문가
  ├── [대화 팀] (핸드오프 체인)
  │     ├── 트리아지 → 기술지원 → 에스컬레이션
  └── [검증 팀] (그룹 채팅)
        ├── 정확성 검증자
        ├── 보안 검토자
        └── 품질 관리자

이 구조에서 최상위 감독자는 요청의 성격에 따라 적절한 하위 팀에 라우팅합니다. 분석 작업은 감독자-워커 팀이, 고객 대화는 핸드오프 체인이, 최종 검증은 그룹 채팅 팀이 담당합니다.

설계 결정 프레임워크

아키텍처 선택을 위한 질문 목록입니다.

  1. 작업의 순서가 고정되어 있는가? → 파이프라인 또는 감독자
  2. 실시간 대화가 필요한가? → 핸드오프 패턴
  3. 여러 관점의 종합이 필요한가? → 그룹 채팅
  4. 에이전트 수가 10개를 넘는가? → 계층적 팀
  5. 외부 시스템의 에이전트와 협업하는가? → A2A 프로토콜 기반 P2P
python
def select_architecture(requirements: dict) -> str:
    if requirements["fixed_order"] and requirements["agent_count"] <= 5:
        return "pipeline"
    elif requirements["realtime_conversation"]:
        return "handoff"
    elif requirements["multi_perspective"]:
        return "group_chat"
    elif requirements["agent_count"] > 10:
        return "hierarchical"
    else:
        return "supervisor_worker"  # 기본값

팀 구성 안티패턴

슈퍼 에이전트(God Agent)

하나의 에이전트가 모든 도구와 권한을 가지고 "필요하면 다른 에이전트에게 위임"하는 구조입니다. 실질적으로 단일 에이전트와 다를 바 없으며, 멀티에이전트의 이점을 얻지 못합니다.

과도한 세분화(Over-Fragmentation)

"인사말 에이전트", "날씨 조회 에이전트", "결과 포맷팅 에이전트"처럼 지나치게 세분화하면 조율 비용이 에이전트 실행 비용을 초과합니다. 하나의 에이전트가 도구 3~7개를 보유하는 것이 적정 수준입니다.

대칭적 중복(Symmetric Redundancy)

동일한 능력을 가진 에이전트를 여러 개 배치하여 "투표"로 결정하는 구조입니다. 비용이 선형으로 증가하며, 품질 향상 효과는 제한적입니다. 대신 하나의 에이전트에 자기 검증(Self-Review) 단계를 추가하는 것이 비용 효율적입니다.


다음 장에서는 에이전트 간의 통신을 표준화하는 프로토콜들을 살펴봅니다. A2A(Agent-to-Agent), MCP(Model Context Protocol), 그리고 커스텀 통신 패턴의 설계 원칙을 다룹니다.

이 글이 도움이 되셨나요?

관련 글

AI / ML

1장: 멀티에이전트 오케스트레이션의 진화와 핵심 개념

단일 에이전트에서 멀티에이전트 시스템으로의 진화 과정, 오케스트레이션의 핵심 개념과 패턴 분류, 그리고 프로덕션 환경에서의 도전 과제를 살펴봅니다.

2026년 3월 22일·19분
AI / ML

11장: 실전 프로젝트 — 멀티에이전트 오케스트레이션 시스템 구축

고객 서비스 자동화 시스템을 처음부터 설계하고 구축하며, 감독자-워커 아키텍처, A2A 통신, 컨트롤 플레인, 관측 가능성을 통합합니다.

2026년 4월 9일·16분
AI / ML

3장: 에이전트 간 통신 프로토콜 — A2A, MCP, 커스텀 패턴

A2A(Agent-to-Agent) 프로토콜, MCP(Model Context Protocol), 그리고 커스텀 메시지 패턴까지 에이전트 간 통신의 표준과 구현을 다룹니다.

2026년 3월 25일·15분
이전 글1장: 멀티에이전트 오케스트레이션의 진화와 핵심 개념
다음 글3장: 에이전트 간 통신 프로토콜 — A2A, MCP, 커스텀 패턴

댓글

목차

약 20분 남음
  • 팀 아키텍처의 선택이 중요한 이유
  • 감독자-워커 패턴(Supervisor-Worker)
    • 기본 구조
    • 감독자의 역할
    • 장단점 분석
  • 계층적 팀 패턴(Hierarchical Teams)
    • 다층 구조 설계
    • 계층 설계의 원칙
  • 피어-투-피어 패턴(Peer-to-Peer)
    • 핸드오프 기반 P2P
    • P2P의 특성
  • 그룹 채팅 패턴(Group Chat)
    • 그룹 채팅 구현
    • 선택자 전략
  • 하이브리드 아키텍처
    • 감독자 + 핸드오프 조합
    • 설계 결정 프레임워크
  • 팀 구성 안티패턴
    • 슈퍼 에이전트(God Agent)
    • 과도한 세분화(Over-Fragmentation)
    • 대칭적 중복(Symmetric Redundancy)