Google AI Agents Challenge 분석: 좋은 멀티 에이전트는 프롬프트 체인이 아니라 시스템 구조로 갈린다

요약: Google Developers Blog가 2026년 9월 2일 공개한 AI Agents Challenge 회고에서 반복적으로 확인한 패턴은 단순합니다. 좋은 멀티 에이전트 시스템은 “역할 이름이 붙은 프롬프트 체인”이 아니라 MCP, 이벤트 버스, 검증 함수, 라우팅 계층을 가진 소프트웨어 시스템에 가깝습니다. 실무 개발자 입장에서는 모델 선택보다 아키텍처 기본기를 먼저 점검해야 합니다.

왜 이 이슈가 중요한가

최근 몇 달 동안 “멀티 에이전트”라는 말이 너무 쉽게 쓰였습니다. 하나의 모델이 순서대로 세 가지 프롬프트를 실행해도 planner, researcher, writer 같은 이름을 붙이면 멀티 에이전트처럼 보입니다. 하지만 운영 환경에서는 이름보다 의존성, 지연 시간, 장애 격리, 검증 위치가 중요합니다.

Google은 AI Agents Challenge 제출작을 보면서 상위권 시스템에서 네 가지 공통 패턴을 봤다고 정리했습니다. 양방향 MCP, 이벤트 기반 동시성, 동일 기준을 통과하는 fallback, 비싼 모델 호출 전에 실행되는 tiered routing입니다. 이 네 가지는 새 모델 발표보다 덜 화려하지만, 실제 제품 안정성에는 더 직접적입니다.

검색 의도 관점에서도 “AI agent architecture”, “multi agent system design”, “MCP event bus fallback routing” 같은 키워드는 개발자가 당장 구현 기준을 찾을 때 쓰는 쿼리입니다. 그래서 이 글은 뉴스 요약보다 실무 해석에 초점을 맞춥니다.

핵심 변화: 에이전트를 API 소비자이자 제공자로 본다

첫 번째 패턴은 양방향 MCP입니다. 많은 에이전트는 MCP 서버를 도구처럼 호출합니다. 데이터베이스 조회, 파일 검색, 외부 API 호출을 MCP tool로 감싸는 식입니다. Google이 소개한 강한 제출작은 한 단계 더 갔습니다. 에이전트가 내부 데이터를 MCP로 소비할 뿐 아니라, 자기 reasoning 결과를 다른 에이전트가 호출할 수 있는 MCP 서버로 노출했습니다.

이 설계의 장점은 두 가지입니다. 첫째, raw SQL이나 거대한 로그 테이블을 모델 컨텍스트에 그대로 밀어 넣지 않습니다. “최근 30분 실패한 job의 execution plan만 반환” 같은 좁은 tool contract로 컨텍스트와 권한을 동시에 줄입니다. 둘째, 사람용 대시보드 없이도 다른 coding agent나 IDE agent가 해당 reasoning layer를 인프라처럼 호출할 수 있습니다.

다만 이 패턴은 권한 문제를 바로 만듭니다. 내부 agent만 쓰던 tool surface는 느슨해도 버틸 수 있습니다. 외부 agent가 부르는 MCP server가 되면 인증, rate limit, audit log, tenant boundary가 필요합니다. “agent-to-agent 호출”은 멋진 데모가 아니라 API 제품 운영 문제입니다.

이벤트 기반 동시성은 latency 구조를 바꾼다

두 번째 패턴은 event-driven concurrency입니다. Google 예시는 sensor-monitoring agent가 compliance agent, messaging agent, dispatch agent로 이어지는 선형 파이프라인을 이벤트 버스로 바꾼 사례였습니다. 선형 호출에서는 전체 지연 시간이 각 agent 처리 시간의 합이 됩니다. A가 끝나야 B가 시작하고, B가 끝나야 C가 시작합니다.

이벤트 버스에서는 같은 신호를 여러 agent가 동시에 받습니다. 예를 들어 CLINICAL.ANOMALY_DETECTED 이벤트가 발생하면 compliance agent는 약물 상호작용을 확인하고, messaging agent는 보호자 메시지 준비를 시작할 수 있습니다. 서로의 결과가 꼭 필요하지 않은 작업을 순서대로 묶지 않는 것이 핵심입니다.

개발자가 확인할 질문은 간단합니다. “우리 agent 중 두 개 이상이 같은 이벤트를 보고 독립적으로 움직일 수 있는가?” 답이 예인데 코드가 함수 호출 체인이라면, 멀티 에이전트가 아니라 단일 스레드 워크플로우입니다. 이 경우 Kafka, Pub/Sub, Redis Streams, asyncio.Queue 중 무엇을 쓰느냐보다 event schema와 retry policy를 먼저 정해야 합니다.

fallback은 모델 교체가 아니라 품질 계약이다

세 번째 패턴은 fallback model입니다. 강한 시스템은 Pro 모델이 503을 반환할 때 Flash 모델로 단순히 바꿔치기하지 않습니다. primary path와 fallback path가 동일한 validation function을 통과하도록 만듭니다. Google 글에서는 clinical guideline citation 검증이 예시였습니다.

실무에서 흔한 사고는 fallback을 “장애 대응”으로만 보는 것입니다. 그래서 try primary, catch fallback 구조를 만들고 fallback 결과는 빠르게 반환합니다. 하지만 이 순간 제품의 품질 기준이 두 개가 됩니다. primary는 citation check, schema validation, policy check를 통과하는데 fallback은 일부를 건너뛸 수 있습니다.

안전한 설계는 검증을 모델 호출 뒤 공통 단계로 빼는 것입니다. generate_with_primary_or_fallback()은 후보 답변만 만들고, validate_response()가 출구를 지킵니다. 검증을 통과하지 못하면 재시도하거나 사람 검토 큐로 보내야 합니다. fallback은 낮은 품질을 허용하는 면허가 아니라 같은 계약을 만족하는 대체 경로입니다.

tiered routing은 비용 최적화이면서 장애 완충 장치다

네 번째 패턴은 비싼 모델 앞의 계층형 라우팅입니다. Google이 소개한 한 팀은 “내 주문 어디 있나요”, “예약 취소해줘” 같은 쉬운 요청까지 frontier model로 보내고 있었습니다. 수정 후에는 로컬 regex가 navigation intent를 먼저 잡고, 애매한 요청만 저렴한 모델이 분류하고, 정말 어려운 요청만 고비용 reasoning model로 보냈습니다. 첫 번째 pass만으로 40% 이상의 메시지를 모델 호출 없이 처리했다는 설명도 있었습니다.

이 숫자가 중요한 이유는 비용보다 운영 안정성 때문입니다. 모든 요청이 최고가 모델로 몰리면 rate limit, 503, queue 지연이 사용자 전체에 번집니다. 반대로 deterministic route, cheap classifier, expensive reasoner로 나누면 장애 반경이 작아집니다. 쉬운 요청은 모델 장애와 무관하게 계속 처리되고, 어려운 요청만 degraded mode를 탑니다.

권장 구현 순서는 regex부터가 아닙니다. 먼저 지난 7일의 요청 로그를 intent별로 샘플링해야 합니다. 상위 20개 intent 중 deterministic하게 처리 가능한 항목을 표시하고, false positive가 치명적인 항목은 cheap classifier 뒤로 미룹니다. 그런 다음 각 계층의 latency, token cost, escalation rate를 대시보드로 봐야 합니다.

기존 시스템에 적용하는 점검 순서

이미 agent workflow가 있다면 전체를 갈아엎을 필요는 없습니다. 아래 순서로 한 지점씩 바꾸는 편이 안전합니다.

1. agent가 읽는 데이터 소스를 raw access와 tool access로 구분합니다.
2. tool output에 최대 행 수, 필드 whitelist, tenant scope를 넣습니다.
3. 독립 실행 가능한 agent 호출을 찾아 이벤트로 분리합니다.
4. primary와 fallback 응답이 같은 validation function을 통과하는지 테스트합니다.
5. 최근 요청 로그 기준으로 cheap route가 가능한 intent를 찾습니다.
6. 모델 호출 전후에 latency, retry count, validation fail count를 남깁니다.
7. 사람이 개입해야 하는 실패 모드를 별도 큐로 분리합니다.

이 순서를 따르면 “대규모 리팩터링”이 아니라 병목 하나를 줄이고, 실패 하나를 격리하고, 비용 하나를 낮추는 식으로 전진할 수 있습니다.

마무리 체크리스트

• 우리 멀티 에이전트가 실제로 병렬 실행되는가, 아니면 역할명만 나뉜 프롬프트 체인인가?
• MCP tool output에 범위 제한, 권한, 감사 로그가 있는가?
• fallback model이 primary와 같은 검증 함수를 반드시 통과하는가?
• 비싼 모델 호출 전에 deterministic route와 cheap classifier가 있는가?
• agent 간 통신을 사람이 읽는 chat UI에만 의존하고 있지 않은가?
• latency를 agent별, route별, validation 단계별로 나눠 보고 있는가?

이번 Google 회고의 결론은 명확합니다. 좋은 AI agent architecture는 더 긴 프롬프트가 아니라 더 좋은 경계, 더 명확한 이벤트, 더 엄격한 검증, 더 싼 라우팅에서 나옵니다.