Google AI Agent 패턴 적용법: MCP·이벤트 버스·fallback 라우팅으로 비용과 장애 줄이기

요약: Google Developers Blog가 AI Agents Challenge 상위 제출작에서 반복된 4가지 엔지니어링 패턴을 정리했습니다. bidirectional MCP, event-driven concurrency, fallback validation, tiered routing은 에이전트 제품을 데모에서 운영 단계로 옮길 때 바로 쓸 수 있는 기준입니다.

문제: 이름만 multi-agent인 시스템이 너무 많다

요즘 많은 제품이 multi-agent를 말합니다. 하지만 실제로 들여다보면 단일 모델이 프롬프트 체인을 따라 순서대로 답하는 경우가 많습니다. agent 이름만 여러 개 붙어 있을 뿐, 독립적인 상태도 없고, 병렬 실행도 없고, 실패 격리도 없습니다.

Google Developers Blog는 AI Agents Challenge 제출작을 검토하며 상위권 시스템에서 반복된 패턴을 네 가지로 정리했습니다. 이 글에서는 그 패턴을 실무 개발자가 바로 적용할 수 있게 구조와 체크리스트로 풀어봅니다.

중요한 관점은 “더 좋은 모델을 쓰자”가 아닙니다. 같은 모델을 써도 도구 경계, 이벤트 처리, fallback 검증, 라우팅 정책을 잘 잡으면 비용과 장애가 줄어듭니다. 반대로 이 네 가지가 없으면 모델 성능이 좋아도 운영에서 흔들립니다.

패턴 1: bidirectional MCP로 에이전트를 도구화한다

일반적인 MCP 사용은 한 방향입니다. 에이전트가 MCP server에 붙어 DB, 파일, API 도구를 호출합니다. Google이 소개한 강한 패턴은 양방향입니다. 에이전트가 내부적으로 MCP 도구를 소비할 뿐 아니라, 자기 기능을 다시 MCP server로 노출해 다른 에이전트가 호출할 수 있게 합니다.

예를 들어 성능 분석 에이전트가 있다고 해봅시다. 내부적으로는 telemetry DB를 직접 읽지 않고 MCP tool을 통해 bounded query만 수행합니다. “최근 1시간 job 실패율”, “특정 trace id의 stack trace”, “가장 느린 dependency call”처럼 목적이 좁은 도구를 둡니다.

그 다음 이 성능 분석 에이전트 자체를 MCP server로 노출하면 코딩 에이전트가 IDE나 터미널에서 바로 호출할 수 있습니다. 개발자가 대시보드에 들어가 내용을 복사해 채팅에 붙일 필요가 없습니다. 에이전트가 다른 에이전트의 인프라가 됩니다.

단, 외부 호출이 가능해지는 순간 access control이 필수입니다. 내부 agent만 부르던 도구와 다른 팀, 다른 agent가 부르는 도구는 위협 모델이 다릅니다. tenant, repo, environment, rate limit, audit log를 붙여야 합니다.

패턴 2: 이벤트 버스로 병렬 반응을 만든다

나쁜 multi-agent 구조는 call chain입니다. Agent A가 B를 부르고, B가 C를 부르고, C가 D를 부릅니다. 이 구조에서는 전체 지연 시간이 additive합니다. 가장 느린 agent가 전체 작업을 막습니다.

운영형 구조는 event-driven concurrency입니다. 하나의 신호가 발생하면 관심 있는 agent들이 각자 queue에서 이벤트를 받아 병렬로 처리합니다. Google 글에서는 topic 기반 이벤트와 asyncio.Queue 같은 구현이 예로 나옵니다.

실무 예시는 장애 대응입니다. DEPLOYMENT_FAILED 이벤트가 발생하면 다음 agent들이 동시에 움직일 수 있습니다.

• log agent: 최근 로그와 stack trace 수집
• code agent: 배포 diff와 관련 파일 확인
• infra agent: CPU, memory, database connection 확인
• comms agent: 상태 페이지 초안 준비

이 중 code agent가 log agent의 결과를 기다려야 하는 경우도 있지만, 처음부터 전부 직렬로 묶을 필요는 없습니다. 이벤트 버스는 독립 작업을 동시에 시작하게 해줍니다.

패턴 3: fallback 모델에도 같은 검증을 강제한다

모델 장애는 피할 수 없습니다. 503, rate limit, region 장애, provider 장애가 생깁니다. 그래서 fallback 모델을 두는 팀이 많습니다. 문제는 fallback이 품질 기준을 낮추는 통로가 되는 경우입니다.

좋은 구조는 primary path와 fallback path가 같은 validation function을 통과하게 만드는 것입니다. 예를 들어 의료 답변이면 guideline citation check, 코드 수정이면 테스트와 lint, 보안 분석이면 재현 가능성과 영향 범위 검증을 동일하게 통과해야 합니다.

중요한 건 “fallback에도 검증을 적용하자”라는 문서가 아니라 코드 구조입니다. validation이 primary와 fallback 뒤에 공통 후처리로 있어야 합니다. 그래야 나중에 fallback을 바꿔도 품질 기준이 유지됩니다.

간단한 구조는 이렇습니다.

1. primary model 호출
2. 실패하면 fallback model 호출
3. 어느 쪽이든 candidate result 생성
4. 공통 validator 실행
5. 실패하면 retry, escalate, human review 중 하나로 이동

fallback은 저렴한 결과를 받는 경로가 아니라 같은 기준을 통과하는 다른 실행 경로입니다.

패턴 4: expensive model 앞에 tiered routing을 둔다

모든 요청을 가장 비싼 모델로 보내면 비용이 버티지 못합니다. Google 글에서 소개된 팀은 쉬운 요청이 inference budget을 많이 먹는다는 사실을 측정하고, 모델 앞에 세 단계 classifier를 뒀습니다. 로컬 regex가 zero-token으로 일부를 처리하고, 애매한 요청은 작은 모델이 분류하고, 정말 필요한 요청만 full reasoning model로 보냅니다. 첫 번째 pass만으로 40% 이상의 메시지를 처리했다는 사례도 언급됩니다.

이 패턴은 대부분의 서비스에 적용됩니다. 고객지원, 내부 개발 도구, 문서 검색, 코드 리뷰, 데이터 분석 모두 마찬가지입니다. “어디 있나요?”, “상태 보여줘”, “로그 다시 보내줘” 같은 요청은 frontier model이 필요 없습니다.

추천 라우팅은 다음과 같습니다.

• layer 0: 정규식, route table, cache, exact command
• layer 1: 작은 모델 분류, temperature 낮게, 짧은 token budget
• layer 2: 중간 모델 요약 또는 후보 생성
• layer 3: frontier model reasoning
• layer 4: human review 또는 specialist agent

이때 routing decision을 로그로 남겨야 합니다. 그래야 나중에 비용을 줄일 때 어떤 layer에서 새 규칙을 추가할지 알 수 있습니다.

네 패턴을 함께 적용하는 순서

처음부터 완벽한 multi-agent 플랫폼을 만들 필요는 없습니다. 작은 순서로 적용하면 됩니다.

첫째, 현재 에이전트가 직접 DB나 API를 때리는 부분을 MCP tool로 감쌉니다. 반환값을 작고 목적이 분명하게 만듭니다.

둘째, 가장 시간이 오래 걸리는 call chain 하나를 찾아 event bus로 바꿉니다. 독립 agent가 같은 이벤트에 반응하게 만드는 것부터 시작합니다.

셋째, fallback 모델을 추가하기 전에 validator를 먼저 공통화합니다. 테스트, citation, schema, 정책 검사를 한 곳에 모읍니다.

넷째, 지난 7일 요청 로그를 보고 쉬운 요청을 layer 0 또는 layer 1로 빼냅니다. 비용 절감은 모델 교체보다 라우팅에서 먼저 나옵니다.

마무리 체크리스트

• 에이전트가 raw DB를 읽지 않게 하고 bounded MCP tool을 둡니다.
• 유용한 에이전트 기능은 다른 에이전트가 부를 수 있는 MCP server로 노출할지 검토합니다.
• call chain으로 묶인 agent 중 독립 실행 가능한 작업을 event bus로 분리합니다.
• fallback 모델은 primary와 같은 validator를 통과하게 만듭니다.
• 쉬운 요청은 regex, cache, 작은 classifier에서 먼저 처리합니다.
• routing decision, validation failure, fallback 발생률을 로그로 남깁니다.
• 비용 최적화는 모델 가격표보다 실제 요청 분포에서 시작합니다.

Google AI Agent 패턴의 핵심은 화려한 데모가 아니라 운영 가능한 구조입니다. MCP는 권한 경계, 이벤트 버스는 지연 시간, validator는 품질, tiered routing은 비용을 다룹니다. 이 네 가지를 잡으면 에이전트 제품은 훨씬 덜 흔들립니다.