Google Developers Blog가 2026년 6월 22일 공개한 Agent Development Kit(ADK)와 Agent2Agent(A2A) 예제는 에이전트 개발 흐름이 어디로 가고 있는지 꽤 선명하게 보여줍니다. 핵심은 Python으로 만든 Gemini 기반 추출 에이전트와 Go로 만든 결정론적 검증 에이전트를 하나의 계약 컴플라이언스 파이프라인으로 묶는 구조입니다.
이 글의 검색 의도는 명확합니다. Google ADK, A2A 프로토콜, 멀티 에이전트 아키텍처를 실제 서비스에 어떻게 적용할지 알고 싶은 개발자를 위한 정리입니다. 단순히 “에이전트를 여러 개 만들 수 있다”가 아니라, 왜 언어와 런타임이 다른 서비스를 억지로 하나로 합치지 않아도 되는지가 포인트입니다.
대부분의 AI 기능은 처음에 하나의 큰 프롬프트로 시작합니다. 도구를 붙이고, 정책을 붙이고, 예외 처리를 붙입니다. 데모에서는 잘 돌아갑니다. 문제는 도구가 10개, 20개로 늘어나는 순간부터 생깁니다. 모델은 어떤 도구를 언제 호출해야 하는지 헷갈리고, 실패한 하위 작업 하나가 전체 실행을 망가뜨립니다.
Google 예제는 이 문제를 세 가지로 설명합니다. 첫째, 컨텍스트가 희석됩니다. 둘째, 장애 범위가 커집니다. 셋째, 테스트하기 어려워집니다. 실제 서비스에서는 이 세 가지가 모두 비용입니다. 회귀 테스트가 어려운 에이전트는 배포 속도를 늦추고, 장애 범위가 큰 에이전트는 운영팀을 피곤하게 만듭니다.
따라서 멀티 에이전트 설계의 출발점은 “멋진 협업”이 아닙니다. 책임 분리입니다. 추출은 추출 에이전트가, 검증은 검증 서비스가, 보고서는 보고서 에이전트가 맡는 식으로 좁은 책임을 부여해야 합니다.
A2A의 중요한 개념은 Agent Card입니다. 각 에이전트는 /.well-known/agent.json 경로에서 자신의 이름, URL, 버전, 지원하는 입력과 출력, 수행 가능한 skill을 JSON 메타데이터로 노출합니다. 호출하는 쪽은 이 카드를 먼저 읽고 상대 에이전트가 무엇을 할 수 있는지 파악합니다.
통신은 JSON-RPC 2.0 기반입니다. Google 예제에서는 message/send 방식으로 계약 데이터를 보내고 결과를 동기적으로 받습니다. 데이터는 자연어 텍스트뿐 아니라 구조화된 JSON으로도 오갑니다. 그래서 Python 에이전트가 Go 패키지를 import하지 않아도 되고, Go 서비스가 Python 런타임을 알 필요도 없습니다.
개발자 입장에서 이 구조의 장점은 분명합니다. 이미 Go로 만들어 둔 정책 엔진, Rust로 만든 고성능 파서, Python으로 만든 LLM 추론 레이어를 같은 에이전트 팀 안에 넣을 수 있습니다. 중요한 것은 내부 구현이 아니라 외부 계약입니다.
Google ADK는 원격 A2A 호환 서비스를 로컬 서브 에이전트처럼 다룰 수 있는 RemoteA2aAgent 추상화를 제공합니다. Python orchestrator 입장에서는 원격 Go 서비스가 로컬 agent처럼 보입니다. Agent Card handshake, JSON-RPC payload 구성, 네트워크 요청 처리 같은 반복 작업은 SDK가 맡습니다.
예제 파이프라인은 세 단계입니다. 첫 번째 Python 에이전트가 계약서에서 금액, 계약자, 날짜, 보험 조건 등을 추출합니다. 두 번째 Go compliance agent가 정책 위반 여부를 결정론적으로 검사합니다. 세 번째 보고서 에이전트가 결과를 Markdown summary로 만듭니다.
여기서 눈여겨볼 부분은 모든 단계를 LLM에 맡기지 않는다는 점입니다. 정책 검증은 LLM보다 결정론적 코드가 적합합니다. 감사가 필요한 영역에서는 같은 입력이 항상 같은 결과를 내야 합니다. 멀티 에이전트 설계는 LLM을 더 많이 쓰자는 뜻이 아니라, LLM이 필요한 곳과 필요 없는 곳을 정확히 나누자는 뜻에 가깝습니다.
Google 예제에는 네트워크 fault simulation이 포함되어 있습니다. Go agent를 정상, 지연, 장애 상태로 바꾸고 Python 에이전트가 어떻게 반응하는지 볼 수 있습니다. Go 검증기가 죽으면 파이프라인은 조용히 실패하지 않고 MANUAL_REVIEW 상태로 전환됩니다.
이 패턴은 실무에서 매우 중요합니다. 에이전트 시스템은 API, 벡터 DB, 파일 저장소, 외부 SaaS, 사내 마이크로서비스에 의존합니다. 어느 하나라도 느려지거나 실패할 수 있습니다. 따라서 상태 체크포인트, timeout, retry, manual review 라우팅을 처음부터 설계해야 합니다.
특히 금융, 법무, 보안, 의료처럼 책임 소재가 중요한 도메인에서는 “모델이 알아서 처리했다”가 답이 될 수 없습니다. 어떤 단계에서 실패했는지, 어떤 입력이 어떤 서비스로 전달됐는지, 사람이 어디서 개입했는지를 로그로 남겨야 합니다.
모든 AI 기능을 처음부터 멀티 에이전트로 만들 필요는 없습니다. 작은 내부 도구라면 하나의 에이전트가 더 빠릅니다. 하지만 다음 조건 중 2개 이상에 해당하면 분리를 검토하는 편이 좋습니다.
처음 나눌 때는 역할 기준이 가장 안전합니다. “문서 읽기”, “필드 추출”, “정책 검증”, “보고서 작성”, “사용자 승인 요청”처럼 사람이 봐도 책임이 분명한 단위로 나누면 테스트와 운영이 쉬워집니다.
Google ADK와 A2A 프로토콜을 바로 도입할지 여부보다 중요한 것은 설계 관점입니다. 에이전트도 결국 분산 시스템입니다. 프롬프트만 잘 쓰는 팀이 아니라, 계약, 상태, 장애, 테스트를 설계하는 팀이 production에서 이깁니다.
실행 체크리스트는 다음과 같습니다.
참고 자료는 Google Developers Blog의 “Build Cross-Language Multi-Agent Team with Google’s Agent Development Kit and A2A”입니다. 핵심 키워드는 Google ADK, A2A 프로토콜, 멀티 에이전트 아키텍처, RemoteA2aAgent입니다.
