Google의 ADK·A2A 예제는 Python LLM 에이전트와 Go 기반 결정론적 검증 서비스를 하나의 멀티에이전트 파이프라인으로 조립한다. 핵심 메시지는 프로덕션 에이전트 시스템이 단일 언어·단일 프롬프트가 아니라, 각 팀이 잘하는 런타임을 유지한 채 표준 프로토콜로 협업해야 한다는 것이다.
예제 구조
계약 컴플라이언스 파이프라인은 세 단계로 나뉜다.
| 단계 | 구현 | 역할 |
|---|---|---|
| 추출 에이전트 | Python + Gemini | 계약서에서 금액, 계약자, 날짜, 보험 조건 등을 추출 |
| 컴플라이언스 에이전트 | Go HTTP 서버 | 회사 정책에 맞는지 결정론적 규칙으로 검증 |
| 리포트 에이전트 | Python + Gemini | 최종 감사 요약과 위반 보고서 작성 |
Python 오케스트레이터는 ADK의 SequentialAgent로 세 단계를 순서대로 실행한다. Go 서비스는 A2A 프로토콜을 구현하므로 Python 쪽에서는 RemoteA2aAgent로 로컬 하위 에이전트처럼 감싼다.
A2A가 해결하는 것
A2A는 에이전트가 자기 능력을 /.well-known/agent.json의 Agent Card로 광고하고, JSON-RPC 2.0으로 메시지를 주고받게 한다. 입력과 출력은 TextPart, DataPart 같은 typed message part로 전달된다. 호출자는 상대 에이전트가 Go인지 Python인지, 내부에 LLM이 있는지 규칙 엔진인지 알 필요가 없다.
이 구조는 세 가지 장점이 있다.
- 팀이 Python, Go, Rust 같은 적합한 언어를 유지할 수 있다.
- 하나의 거대한 에이전트 컨텍스트에 모든 도구를 넣지 않아도 된다.
- 정책 검증처럼 감사 가능해야 하는 부분을 LLM 밖의 결정론적 서비스로 분리할 수 있다.
프로덕션 패턴
예제에서 중요한 부분은 장애 처리다. Go 검증 에이전트가 지연되거나 다운되면 전체 파이프라인이 조용히 실패하지 않고 MANUAL_REVIEW 상태로 전환된다. 에이전트 협업은 성공 경로보다 실패 경로가 더 중요하다. 외부 서비스가 불안정할 때 사람 검토로 넘기는 상태 전이가 있어야 운영 가능한 시스템이 된다.
언제 쓸 만한가
금융·법무·보안·조달처럼 “LLM이 읽고 요약하되 최종 판정은 규칙과 감사 로그가 필요한” 업무에 적합하다. 추출과 설명은 LLM 에이전트가 맡고, 정책 판정은 별도 서비스가 맡는 방식은 멀티에이전트 시스템을 엔터프라이즈 아키텍처에 맞게 끼워 넣는 현실적인 패턴이다.
관련 문서
- a2a — 에이전트 간 작업 위임 프로토콜
- gemini — Google의 멀티모달 AI 모델
- agent-harness — 에이전트 실행 구조와 하네스 설계
참고 자료
- Build Cross-Language Multi-Agent Team with Google’s Agent Development Kit and A2A — Google Developers Blog (2026-06-24)