먼저, 불편함에서 출발하자
새로운 프로토콜을 배울 때 가장 먼저 물어야 할 질문은 "무엇을 할 수 있는가"가 아니다. "무엇이 불편해서 이것이 필요해졌는가"다. A2A, 즉 Agent2Agent도 마찬가지다.
AI 에이전트가 하나뿐일 때는 문제가 단순했다. 사용자가 질문하고, 에이전트가 답한다. 필요하면 도구를 호출하고, 결과를 정리한다. 그러나 조직 안에 여러 에이전트가 생기기 시작하면 상황이 달라진다. 고객 상담 에이전트, 문서 검색 에이전트, 일정 조율 에이전트, 재무 분석 에이전트, 코드 작성 에이전트가 각자 다른 곳에서 실행된다. 어떤 것은 Google Cloud 위에 있고, 어떤 것은 사내 서버에 있으며, 어떤 것은 외부 SaaS에 붙어 있다. 개발 언어와 프레임워크도 다르다.
여기서 에이전트란 단순히 함수 하나를 실행하는 프로그램이 아니다. 쉽게 말해 "일을 맡길 수 있는 디지털 동료"에 가깝다. 사용자의 목표를 이해하고, 필요한 절차를 판단하고, 도구를 사용하고, 중간에 추가 정보를 요청할 수도 있다. 물론 사람처럼 자율적이라고 과장할 필요는 없다. 핵심은 에이전트가 단순 응답기가 아니라 일정한 업무 단위를 처리하는 소프트웨어 주체라는 점이다.
문제는 이 디지털 동료들이 서로 말이 통하지 않는다는 데 있다.
AI 생성 이미지
에이전트 사일로가 생긴다
사일로는 원래 곡물 저장고를 뜻하지만, 기술 조직에서는 서로 고립된 시스템을 가리킬 때 자주 쓴다. 데이터는 있는데 다른 팀이 못 쓰고, 기능은 있는데 다른 서비스가 호출하기 어렵고, 문서는 있는데 권한과 형식이 달라 연결되지 않는 상태다.
AI 에이전트에서도 같은 일이 벌어진다. A 회사의 프레임워크로 만든 에이전트와 B 회사의 플랫폼에서 실행되는 에이전트가 있다고 해 보자. 둘 다 훌륭한 기능을 갖고 있어도, 서로의 능력을 발견하고 요청을 주고받는 공통 방식이 없다면 협업은 어렵다. 결국 개발자는 각 에이전트마다 별도 어댑터를 만든다. 하나의 연결은 해결되지만, 에이전트가 늘어날수록 연결 조합은 급격히 많아진다.
A2A 명세는 바로 이 지점을 문제로 본다. 서로 다른 벤더, 언어, 프레임워크로 만들어지고 서로 다른 서버에서 실행되는 독립적인 에이전트 시스템 사이에 공통 언어와 상호작용 모델이 필요하다는 것이다1. 여기서 중요한 표현은 "독립적"이라는 말이다. A2A는 모든 에이전트가 같은 런타임 안에 있거나, 같은 메모리를 공유하거나, 같은 내부 구조를 가져야 한다고 가정하지 않는다.
오히려 반대다. 각 에이전트는 내부 상태, 메모리, 도구 구현을 숨긴 채 협업할 수 있어야 한다. 사람 회사로 비유하면, 다른 부서에 일을 요청할 때 그 부서의 모든 회의록, 업무 방식, 개인 메모를 들여다볼 필요는 없다. 우리는 그 부서가 어떤 일을 할 수 있는지 알고, 필요한 정보를 전달하고, 결과를 받으면 된다. A2A가 말하는 에이전트 간 통신도 이와 비슷하다.
복합 업무는 한 에이전트가 다 하기 어렵다
처음에는 "강력한 에이전트 하나가 모든 일을 하면 되지 않을까?"라고 생각하기 쉽다. 그러나 실제 업무는 그렇게 단순하지 않다.
예를 들어 신제품 출시 계획을 세운다고 해 보자. 시장 조사, 경쟁사 분석, 가격 정책, 법무 검토, 공급망 확인, 광고 문안 작성, 영업 자료 제작이 모두 필요하다. 이 일을 하나의 거대한 에이전트가 전부 처리하게 만들 수도 있다. 하지만 그렇게 하면 설계가 무거워진다. 권한 관리도 어려워지고, 특정 영역의 전문성을 개선하기도 힘들다. 무엇보다 실패 지점을 찾기 어렵다.
현실적인 접근은 전문 에이전트들이 나누어 일하는 것이다. 시장 조사 에이전트는 외부 보고서와 검색 결과를 잘 다루고, 법무 에이전트는 계약과 규정 검토에 특화된다. 재무 에이전트는 숫자와 시나리오 분석에 강하고, 문서 작성 에이전트는 결과를 읽기 좋은 형태로 정리한다.
이때 필요한 것은 "각자 잘하는 에이전트를 어떻게 연결할 것인가"다. 단순히 API 주소를 아는 것만으로는 부족하다. 요청하는 쪽은 상대가 어떤 일을 할 수 있는지 알아야 한다. 어떤 입력 형식을 받는지, 텍스트만 가능한지, 파일도 받는지, 결과는 즉시 주는지, 오래 걸리면 진행 상태를 알려주는지 알아야 한다.
앞으로 이 책에서 자주 볼 몇 가지 용어도 여기서 자연스럽게 등장한다. 클라이언트는 일을 요청하는 쪽이다. 사람으로 치면 업무를 의뢰하는 담당자다. 원격 에이전트는 네트워크 너머에 있는 다른 에이전트다. 다른 부서나 외부 협력사처럼, 내가 직접 내부를 통제하지는 않지만 일을 맡길 수 있는 상대다. 태스크는 에이전트에게 맡긴 하나의 업무 단위다. "이 보고서를 요약해 줘"나 "이 고객 이슈의 원인을 분석해 줘" 같은 일감이라고 보면 된다.
A2A는 이런 관계를 표준 방식으로 표현하려는 시도다.
API 호출과 에이전트 협업은 다르다
많은 개발자는 이미 API에 익숙하다. API는 자판기와 비슷하다. 정해진 버튼을 누르고, 정해진 입력을 넣으면, 정해진 형식의 결과가 나온다. 물론 좋은 API도 복잡한 일을 처리할 수 있다. 하지만 전통적인 API 호출은 대체로 "요청-응답" 구조에 가깝다.
에이전트 협업은 조금 다르다. 에이전트는 요청을 받은 뒤 추가 질문을 할 수 있다. 시간이 오래 걸리는 일을 처리하면서 중간 상태를 알려줄 수 있다. 텍스트뿐 아니라 파일, 표, 구조화된 JSON 데이터를 결과로 돌려줄 수도 있다. 어떤 경우에는 한 번의 응답으로 끝나지 않고, 진행 중인 업무를 계속 추적해야 한다.
그래서 A2A는 에이전트를 단순한 도구로만 보지 않는다. 도구는 보통 다른 시스템 안에서 호출되는 기능이다. 반면 A2A의 관점에서 에이전트는 협업 상대다. 상대의 능력을 발견하고, 어떤 방식으로 상호작용할지 조율하고, 태스크를 중심으로 정보를 주고받는다. 공식 프로젝트 설명도 A2A를 "불투명한 에이전트 애플리케이션 사이의 통신과 상호운용성을 가능하게 하는 공개 프로토콜"로 소개하며, 에이전트들이 내부 상태나 도구를 노출하지 않고 협력할 수 있다는 점을 강조한다2.
여기서 "불투명하다"는 말은 부정적인 뜻이 아니다. 내부가 보이지 않아도 된다는 뜻이다. 다른 에이전트의 프롬프트, 메모리 구조, 도구 목록, 실행 계획을 모두 알아야만 협업할 수 있다면 보안과 운영은 매우 어려워진다. A2A는 내부를 공유하는 대신, 바깥에서 합의된 통신 형식을 사용하자는 쪽에 가깝다.
표준이 없으면 연결 비용이 폭발한다
에이전트가 두세 개일 때는 직접 연결해도 된다. 하지만 조직 안팎에 수십 개의 에이전트가 생기면 이야기가 달라진다. 각 에이전트가 제각각 다른 방식으로 자기 능력을 설명하고, 다른 메시지 형식을 쓰고, 다른 인증 방식을 요구하면 매번 별도 통역사가 필요하다.
이 문제는 단순 개발 비용만의 문제가 아니다. 운영 안정성에도 영향을 준다. 어떤 에이전트가 업데이트되었을 때 연결된 다른 에이전트들이 깨질 수 있다. 요청이 실패했을 때 원인이 입력 형식인지, 권한인지, 처리 지연인지 파악하기 어렵다. 보안팀은 어떤 데이터가 어느 에이전트로 전달되는지 추적하기 힘들다.
표준 프로토콜은 이 혼란을 줄이는 공통 약속이다. 모든 것을 대신 설계해 주지는 않는다. 그러나 최소한 다음 질문에 대해 같은 언어로 답할 수 있게 해 준다.
이 에이전트는 어떤 능력을 제공하는가?
요청은 어떤 형식으로 보내는가?
하나의 업무는 어떻게 추적하는가?
진행 중인 상태와 최종 결과는 어떻게 구분하는가?
텍스트, 파일, 구조화 데이터는 어떻게 주고받는가?
내부 구현을 숨긴 채 어디까지 협업할 수 있는가?
A2A는 이러한 질문에 대한 공통 기반을 제공하려 한다. 뒤에서 살펴볼 Agent Card, Task, Message, Artifact 같은 요소들은 모두 이 문제의식에서 나온다.
Google의 제안에서 공개 표준으로
A2A는 Google이 개발하고 공개한 프로토콜로 출발했다. Google Cloud는 A2A를 소개하면서 AI가 단일 작업 전용 에이전트에서 여러 에이전트가 연결된 생태계로 이동하고 있으며, 서로 다른 플랫폼 위의 자율 에이전트들이 복잡한 문제를 함께 풀 수 있어야 한다고 설명했다3. 이 설명은 A2A의 출발점이 특정 제품 기능 하나가 아니라, 멀티 에이전트 시대의 상호운용성 문제였음을 보여 준다.
이후 A2A는 Linux Foundation 산하 프로젝트로 확장되었다. Linux Foundation 발표에 따르면 A2A는 Google이 만든 안전한 에이전트 간 통신과 협업을 위한 공개 프로토콜이며, Google은 이를 중립적 거버넌스 아래에서 발전시키기 위해 Linux Foundation에 기여했다4. 여기서 중립적 거버넌스란 특정 회사 하나가 방향을 독점하지 않고, 여러 기업과 커뮤니티가 공개적으로 기여할 수 있는 구조를 뜻한다.
이 변화는 중요하다. 에이전트 간 통신 프로토콜은 한 회사의 생태계 안에서만 쓰이면 효과가 제한된다. A2A가 해결하려는 문제 자체가 "서로 다른 회사, 서로 다른 플랫폼, 서로 다른 프레임워크 사이의 협업"이기 때문이다. 따라서 프로토콜이 널리 받아들여지려면 기술 내용만큼이나 신뢰할 수 있는 운영 구조가 필요하다.
물론 공개 표준이 되었다고 모든 문제가 자동으로 사라지는 것은 아니다. 어떤 에이전트에게 어떤 권한을 줄지, 민감한 데이터를 어떻게 제한할지, 실패한 태스크를 어떻게 복구할지, 결과 품질을 어떻게 검증할지는 여전히 설계자의 책임이다. A2A는 협업을 가능하게 하는 통신의 바닥을 깔아 준다. 그 위에 안전하고 유용한 시스템을 만드는 일은 각 조직과 개발자가 해야 한다.
이 장에서 기억할 것
A2A는 유행어가 아니라 연결 문제에서 출발한 프로토콜이다. 에이전트가 많아질수록 서로 다른 프레임워크, 회사, 서버에 흩어진 에이전트들이 고립되는 사일로 문제가 커진다. 복합 업무는 하나의 거대한 에이전트보다 여러 전문 에이전트가 나누어 처리하는 편이 현실적일 때가 많다. 그러려면 에이전트들이 서로의 능력을 발견하고, 업무를 맡기고, 상태와 결과를 주고받는 공통 방식이 필요하다.
A2A의 핵심 관점은 에이전트를 단순 API나 도구가 아니라 협업 주체로 본다는 데 있다. 내부를 모두 공개하지 않아도, 표준화된 메시지와 태스크 모델을 통해 함께 일할 수 있게 하자는 것이다.
다음 장에서는 이 문제의식을 더 큰 그림으로 확장해, 에이전트 상호운용성이 어떤 층위로 구성되는지 살펴본다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.