Spring AI Agentic Patterns (Part 5): A2A Integration — 에이전트를 시스템 경계 너머로 연결하는 법
Spring AI Agentic Patterns (Part 5): A2A Integration — 에이전트를 시스템 경계 너머로 연결하는 법
서브에이전트 패턴까지 오면 자연스럽게 다음 질문이 생긴다.
같은 애플리케이션 안에서만 에이전트를 나눌 수 있는 걸까?
현실의 시스템은 대개 그렇게 단순하지 않다. 날씨 에이전트는 별도 서비스에 있고, 예약 에이전트는 다른 팀이 운영하고, 내부 정책 에이전트는 사내 네트워크 뒤에 있을 수 있다. 결국 진짜 문제는 “에이전트를 어떻게 잘 만들까?”만이 아니라, **서로 다른 에이전트를 어떻게 연결할까?**가 된다.
Spring AI의 A2A Integration은 바로 이 지점을 다룬다. 핵심은 Agent2Agent, 즉 A2A 프로토콜을 통해 에이전트들이 서로의 능력을 발견하고, 메시지를 주고받고, 작업을 위임할 수 있게 만드는 것이다.
A2A를 왜 봐야 하나
에이전트 아키텍처가 커질수록 한 프로세스 안에서 모든 걸 해결하기 어렵다.
- 소유권이 다른 팀의 에이전트가 있다
- 배포 단위가 서로 다르다
- 권한/네트워크 경계가 다르다
- 도메인별 전문 에이전트를 독립적으로 운영하고 싶다
이때 필요한 건 임시 HTTP API 몇 개를 억지로 맞추는 게 아니라, 에이전트끼리 통신하는 공통 규약이다.
A2A는 그 역할을 노린다. 원문 기준으로 A2A는 에이전트가
- 능력을 발견하고
- 메시지를 교환하고
- 작업을 조정하는
오픈 표준이다.
즉 MCP가 도구 연결 표준 쪽에 가깝다면, A2A는 에이전트 간 협업 표준에 가깝다고 이해하면 감이 빠르다.
Spring AI A2A가 해 주는 일
원문이 소개하는 spring-ai-a2a 프로젝트는 A2A Java SDK와 Spring AI를 연결해 준다. 특히 현재는 서버 측 통합에 초점이 맞춰져 있다.
즉 Spring AI 애플리케이션을 A2A 규약을 따르는 에이전트 서버로 노출할 수 있다.
여기서 제공되는 핵심은 다음과 같다.
- Spring Boot 자동 설정
ChatClient와 도구를 A2A 실행 흐름에 연결- Agent Card 노출
- JSON-RPC 기반 메시지 처리 엔드포인트 제공
즉 개발자는 프로토콜 세부사항을 처음부터 직접 구현하기보다, Spring AI 앱을 A2A 서버로 감싸는 방식으로 시작할 수 있다.
Agent Card가 왜 중요한가
A2A에서 핵심 개념 중 하나는 Agent Card다.
이건 쉽게 말해 에이전트의 자기소개서다.
- 이름
- 설명
- URL
- 지원 기능
- 입력/출력 모드
- 스킬 목록
- 프로토콜 버전
이 정보가 /.well-known/agent-card.json 같은 표준 경로로 노출되면, 다른 에이전트가 먼저 이 카드를 읽고 “이 에이전트가 무슨 일을 할 수 있는지” 파악할 수 있다.
이게 중요한 이유는, 원격 에이전트 호출을 하드코딩된 내부 API가 아니라 발견 가능한 능력 기반 상호작용으로 바꿔 주기 때문이다.
서버 에이전트 예제가 보여 주는 것
원문 예제는 날씨 에이전트를 A2A 서버로 노출하는 흐름을 보여 준다.
핵심 감각은 이렇다.
- AgentCard를 Bean으로 정의하고
AgentExecutor가 Spring AIChatClient를 감싸고- 도구를 포함한 Spring AI 에이전트 응답을 A2A 메시지로 되돌린다
즉 이미 잘 만들어 둔 Spring AI 에이전트를 버리는 게 아니라, 그 위에 A2A 통신 껍질을 씌우는 방식이다.
이 점이 좋다. 새로운 아키텍처를 강요하기보다, 기존 Spring AI 앱을 외부 협업 가능한 에이전트로 확장하는 접근이기 때문이다.
클라이언트 측 시나리오도 실용적이다
원문 후반부의 더 흥미로운 예제는 원격 A2A 에이전트를 호출하는 호스트 에이전트다.
예를 들어 여행 계획 에이전트가 있다고 해 보자.
- 날씨 에이전트는 기상 정보 전문
- 숙소 에이전트는 숙박 검색 전문
- 호스트 에이전트는 사용자 요청을 이해하고 어디에 물어볼지 판단
이 구조에서 호스트 에이전트는 원격 에이전트의 Agent Card를 먼저 읽고, sendMessage 같은 도구를 통해 적절한 원격 에이전트에게 일을 보낸다.
이 패턴의 좋은 점은 LLM 기반 라우팅과 표준 프로토콜 호출이 결합된다는 점이다.
즉 단순한 서비스 호출이라기보다,
- 어떤 전문 에이전트를 써야 하는지 모델이 판단하고
- 실제 통신은 A2A SDK가 맡고
- 결과는 다시 Spring AI 에이전트 흐름으로 돌아온다
실무적으로 기대할 수 있는 장점
1) 팀 경계에 맞는 분리
각 팀이 자기 에이전트를 독립적으로 운영하면서도 표준 방식으로 연결할 수 있다.
2) 도메인 전문화
모든 능력을 한 앱에 넣지 않아도 된다. 잘하는 에이전트를 따로 둘 수 있다.
3) 점진적 확장
처음엔 단일 앱으로 시작해도, 나중에 원격 에이전트로 분리하기 쉬워진다.
4) 상호운용성
Spring AI 밖의 에이전트 생태계와도 연결 가능성이 생긴다.
아직 초기 단계라는 점도 중요하다
원문은 이 프로젝트가 현재는 주로 서버 측 통합에 집중하고 있고, 앞으로 클라이언트 경험, 보안, 자동 발견, 스트리밍 전송 같은 확장이 더 필요하다고 설명한다.
이건 오히려 건강한 신호다. A2A 같은 표준은 개념만 크고 실제 개발자 경험이 뒤따르지 못하면 금방 흐려지는데, Spring AI 쪽은 적어도 무엇이 이미 되고 무엇이 아직 덜 됐는지를 비교적 솔직하게 보여 준다.
이 글에서 가져가야 할 핵심
A2A Integration의 포인트는 단순하다.
Spring AI 에이전트를 하나의 앱 내부 도구로만 두지 않고, 다른 에이전트와 대화 가능한 네트워크 참여자로 만든다.
이 관점은 꽤 크다. 지금은 작은 데모처럼 보일 수 있어도, 장기적으로는 에이전트 아키텍처가 도구 중심 앱에서 상호운용 가능한 에이전트 네트워크로 확장될 때 중요한 토대가 된다.
마무리
Subagent Orchestration이 한 애플리케이션 안에서 역할을 나누는 패턴이었다면, A2A Integration은 그 경계를 넘는다. 이제는
- 다른 프로세스,
- 다른 시스템,
- 다른 팀,
- 다른 배포 단위
에 있는 에이전트와도 표준 방식으로 협업할 수 있게 된다.
Spring AI 관점에서 이 글의 의미는 분명하다. ChatClient와 도구 기반 에이전트 구조를 유지하면서도, 원격 에이전트 협업이라는 다음 층위로 올라갈 수 있는 길을 보여 준다.
Series Links
- Part 1: Agent Skills 한국어 정리
- Part 2: AskUserQuestionTool 한국어 정리
- Part 3: TodoWriteTool 한국어 정리
- Part 4: Subagent Orchestration 한국어 정리
- Part 5: A2A Integration (원문)
- Dynamic Tool Discovery 한국어 정리
- Tool Argument Augmentation 한국어 정리