멀티 에이전트 아키텍처 패턴: MCP, 이벤트 버스, 모델 라우팅 실전 설계

멀티 에이전트라는 말은 쉽게 붙지만, 실제로는 단일 모델에 이름만 여러 개 붙인 구조가 많습니다. Google for Startups AI Agents Challenge 회고에서 소개된 강한 제출작들의 공통점은 모델 성능보다 시스템 구조였습니다. 양방향 MCP, 이벤트 기반 동시성, 품질 기준이 있는 fallback, tiered routing 같은 패턴입니다.

이 글은 “멀티 에이전트 아키텍처”, “MCP agent server”, “AI agent event bus”, “모델 라우팅”을 찾는 개발자를 위한 설계 가이드입니다. 새 프레임워크 이름보다, 팀 레포에 적용 가능한 구조를 중심으로 설명합니다.

이름만 멀티 에이전트인지 먼저 확인하세요

멀티 에이전트의 기준은 이름표가 아닙니다. 역할, 권한, 상태, 실패 책임이 분리돼 있어야 합니다. “Planner”, “Researcher”, “Writer”라는 이름을 붙였지만 모두 같은 모델이 같은 도구를 쓰고 같은 컨텍스트를 공유한다면 디버깅만 어려운 단일 에이전트입니다.

진짜 분리가 필요한 경우는 다음과 같습니다.

• 어떤 agent는 DB를 읽을 수 있지만 쓸 수는 없다.
• 어떤 agent는 외부 API를 호출하지만 파일 시스템에는 접근하지 못한다.
• 어떤 agent는 느리지만 정확한 검증을 담당한다.
• 어떤 agent는 실시간 이벤트를 받아 빠르게 판단한다.
• 어떤 agent는 사람에게 확인 요청을 보내는 역할만 한다.

즉, 에이전트 분리는 “프롬프트 스타일”이 아니라 “운영 경계”입니다. 권한과 책임이 다를 때 나눠야 합니다.

패턴 1: 양방향 MCP는 agent를 인프라로 만듭니다

Google 글에서 흥미로운 패턴은 agent가 MCP client이면서 동시에 MCP server가 되는 구조입니다. 보통 MCP는 agent가 외부 도구 서버를 호출하는 방식으로 이해됩니다. 하지만 어떤 agent의 reasoning 결과 자체가 다른 agent에게 필요한 기능이라면, 그 agent를 MCP server로 노출할 수 있습니다.

예를 들어 성능 분석 agent가 telemetry DB를 읽고 “특정 job이 왜 느려졌는지” 판단한다고 합시다. 이 기능을 채팅 UI에만 묶어두면 사람이 질문하고 답을 복사해야 합니다. 반면 MCP server로 노출하면 코딩 agent가 직접 성능 분석 agent를 호출해 원인을 확인하고 코드 수정까지 이어갈 수 있습니다.

다만 외부 호출 가능한 MCP server는 접근 제어가 필수입니다. 내부 agent만 호출하던 도구와 다르게, 다른 agent나 워크플로우가 직접 reasoning 계층을 호출할 수 있기 때문입니다. 반환값도 제한해야 합니다. raw SQL 결과를 통째로 넘기지 말고, 목적에 맞게 필터링된 답을 반환해야 합니다.

패턴 2: 이벤트 버스는 call chain 병목을 줄입니다

많은 멀티 에이전트 데모는 A가 B를 호출하고, B가 C를 호출하고, C가 D를 호출하는 체인입니다. 이해하기는 쉽지만 latency가 누적됩니다. 서로 독립적으로 반응할 수 있는 agent까지 줄 세우면 가장 느린 단계가 전체 시간을 잡아먹습니다.

이벤트 기반 구조는 다릅니다. 하나의 신호가 발생하면 관심 있는 agent들이 각자 구독한 topic을 보고 동시에 움직입니다. 예를 들어 운영 알림에서 latency spike가 감지되면 다음 작업이 병렬로 실행될 수 있습니다.

• telemetry agent가 최근 지표를 분석한다.
• deploy agent가 최근 배포를 확인한다.
• incident agent가 과거 유사 장애를 검색한다.
• notification agent가 담당자를 찾는다.

이 작업들은 반드시 순차일 필요가 없습니다. 이벤트 버스를 쓰면 각 agent가 자신의 속도로 처리하고, 결과 이벤트를 다시 발행합니다. Python이라면 asyncio.Queue, 서버 환경이라면 Kafka, NATS, Redis Streams 같은 선택지가 있습니다.

패턴 3: fallback 모델에는 품질 기준이 있어야 합니다

비싼 모델이 느리거나 unavailable일 때 작은 모델로 fallback하는 것은 자연스럽습니다. 문제는 품질 기준 없이 fallback하는 경우입니다. 작은 모델이 답을 만들었기 때문에 성공으로 처리하면, 사용자는 품질 저하를 장애로 경험합니다.

fallback에는 “same-bar” 기준이 필요합니다. 작은 모델이 대신하더라도 같은 품질 기준을 통과해야 합니다. 예를 들어 코드 수정이면 테스트 통과, 타입 체크, lint, diff 제한을 통과해야 합니다. 문서 작성이면 필수 섹션, 링크, 금지 표현 검사를 통과해야 합니다.

좋은 fallback 흐름은 다음과 같습니다.

1. 저비용 모델이 초안을 만든다.
2. 규칙 기반 검사를 먼저 통과한다.
3. 필요하면 독립 reviewer 모델이 읽기 전용으로 평가한다.
4. 기준 미달이면 상위 모델로 escalation한다.
5. 기준을 통과하지 못한 결과는 사용자에게 성공처럼 보여주지 않는다.

이 구조는 비용을 줄이면서도 품질 하한선을 유지합니다.

패턴 4: tiered routing은 모델 호출 전에 할 일을 줄입니다

모든 요청을 바로 LLM에 보내는 것은 비쌉니다. 많은 요청은 deterministic rule, 캐시, 검색, 정규식, 권한 검사로 먼저 줄일 수 있습니다. 이것이 tiered routing의 핵심입니다.

예를 들어 “이 PR은 문서만 바꿨는가?”는 모델이 필요 없습니다. 파일 경로와 diff를 보면 됩니다. “이 요청이 결제 정보에 접근하려 하는가?”도 키워드와 도구 권한으로 1차 판단할 수 있습니다. 모델은 애매하거나 reasoning이 필요한 요청에 쓰는 게 좋습니다.

추천 routing 순서는 다음과 같습니다.

• 0단계: 인증, 권한, rate limit 확인
• 1단계: 규칙 기반 분류와 캐시 조회
• 2단계: 작은 모델 또는 로컬 모델로 간단한 판단
• 3단계: 강한 모델로 복잡한 reasoning
• 4단계: reviewer 또는 human approval

이렇게 하면 비용뿐 아니라 안전성도 좋아집니다. 모델이 판단하기 전에 정책으로 막아야 할 요청은 미리 차단할 수 있기 때문입니다.

팀 레포에 적용하는 최소 구현

처음부터 거대한 agent platform을 만들 필요는 없습니다. 최소 구현은 다음 네 가지 파일로 시작할 수 있습니다.

• 'agents.yaml': agent 이름, 역할, 허용 도구, 모델, timeout 정의
• 'tools.yaml': 도구 스키마, 권한 등급, 민감 액션 여부 정의
• 'events.yaml': topic 이름, payload schema, 구독 agent 정의
• 'evals/': agent별 행동 평가와 안전 테스트

이 네 가지가 있으면 멀티 에이전트 구조를 코드 리뷰할 수 있습니다. “이 agent가 왜 이 도구를 호출할 수 있지?”, “이 이벤트는 누가 소비하지?”, “fallback 시 품질 기준은 어디 있지?”를 PR에서 확인할 수 있습니다.

실행 체크리스트

• agent 분리 기준을 역할이 아니라 권한과 실패 책임으로 정의했다.
• MCP server로 노출되는 agent에는 인증과 반환값 제한이 있다.
• 독립적으로 반응 가능한 agent는 call chain 대신 event bus를 쓴다.
• fallback 모델은 같은 품질 기준을 통과해야 성공 처리된다.
• 모델 호출 전에 권한, 캐시, 규칙 기반 분류를 먼저 수행한다.
• reviewer agent는 읽기 전용 컨텍스트에서 실행한다.
• agent, tool, event, eval 정의를 레포에서 코드 리뷰한다.
• “멀티 에이전트”라는 이름보다 관측성, 비용, 권한 경계를 먼저 본다.

출처: Google Developers Blog, “4 engineering patterns behind the strongest AI Agents Challenge submissions”