에이전트가 서로 말해야 하는 이유

자동화는 한 부서에서 끝나지 않는다

초기의 AI 에이전트는 "한 사람이 하던 작은 일을 대신 처리하는 도구"에 가까웠다. 고객 문의를 요약하고, 문서를 검색하고, 이메일 초안을 만들고, 데이터베이스에서 필요한 값을 찾아왔다. 이런 에이전트도 충분히 유용하다. 반복 업무를 줄이고, 직원이 더 중요한 판단에 시간을 쓰게 해준다.

하지만 기업의 실제 업무는 보통 한 시스템이나 한 부서 안에서 끝나지 않는다. 고객이 "주문한 상품이 늦어졌고, 대체품을 받을 수 있는지" 묻는 상황을 보자. 고객지원 에이전트는 상담 이력과 주문 정보를 확인할 수 있다. 그러나 대체품 재고는 공급망 시스템에 있고, 추가 구매는 구매 부서의 승인 규칙을 따라야 하며, 환불 정책은 재무 시스템과 연결되어 있다. 고객지원 에이전트가 아무리 똑똑해도 다른 에이전트에게 맥락을 넘기지 못하면 여기서 자동화는 멈춘다.

결국 사람이 개입한다. 상담 내용과 주문 번호를 복사해 구매 담당자에게 보내고, 구매 담당자는 다시 공급망 담당자에게 확인을 요청한다. 각 단계에서 같은 설명이 반복되고, 중요한 조건이 빠지며, 책임 소재가 흐려진다. 에이전트가 각자 뛰어난데도 전체 업무가 끊기는 이유는 지능이 부족해서가 아니다. 서로 알아들을 수 있는 방식으로 상태와 의도를 주고받지 못하기 때문이다.

A2A(Agent-to-Agent, 에이전트 간 통신)를 이해하려면 이 지점에서 출발해야 한다. 문제는 "더 똑똑한 에이전트 하나를 만들면 되는가"가 아니다. 문제는 여러 에이전트가 각자의 역할과 권한을 유지하면서도 하나의 업무 흐름처럼 협업할 수 있는가이다.

AI 생성 이미지

하나의 거대한 에이전트가 답이 아닌 이유

가장 단순한 해결책은 모든 일을 처리하는 하나의 거대한 에이전트를 만드는 것이다. 고객지원, 구매, 인사, 공급망, 재무 시스템에 모두 접근할 수 있고, 모든 규칙을 알고, 모든 결정을 내리는 에이전트다. 이 생각은 처음에는 매력적으로 보인다. 연결할 대상이 하나뿐이니 구조도 단순해 보인다.

그러나 기업 환경에서는 곧 한계가 드러난다. 첫째, 권한 범위가 지나치게 넓어진다. 고객지원 업무를 돕기 위해 만든 에이전트가 인사 정보나 공급업체 계약 조건까지 볼 수 있어야 한다면 보안 위험이 커진다. 둘째, 업무 지식의 변화 속도가 다르다. 인사 규정, 구매 승인 기준, 공급망 예외 처리 방식은 서로 다른 주기로 바뀐다. 하나의 에이전트에 모든 지식을 몰아넣으면 작은 변경도 전체 시스템의 재검증으로 이어진다.

셋째, 조직의 책임 구조와 맞지 않는다. 실제 기업에서는 부서마다 데이터 소유권, 승인 권한, 감사 기준이 다르다. 인사 에이전트는 채용과 직원 정보에 강해야 하고, 구매 에이전트는 공급업체와 계약 조건에 강해야 한다. 공급망 에이전트는 재고, 물류, 납기 리스크를 다뤄야 한다. 각 에이전트가 전문성을 갖고 자기 경계 안에서 판단하는 편이 운영과 통제에 더 적합하다.

그래서 기업의 에이전트 시스템은 자연스럽게 다중 에이전트 구조로 향한다. 하나의 만능 에이전트가 모든 일을 처리하는 대신, 여러 전문 에이전트가 필요한 순간에 협력한다. 이때 핵심은 각 에이전트가 "무엇을 할 수 있는지", "어떤 입력이 필요한지", "작업이 지금 어떤 상태인지", "결과를 어떤 형식으로 돌려주는지"를 서로 이해하는 것이다.

단일 에이전트 자동화와 다중 에이전트 협업

단일 에이전트 자동화는 한 에이전트가 자기 도구를 사용해 작업을 끝내는 방식이다. 예를 들어 고객지원 에이전트가 지식베이스를 검색하고, 고객의 이전 문의를 요약하고, 답변 초안을 작성한다. 이 흐름은 비교적 명확하다. 에이전트가 호출할 도구와 데이터가 정해져 있고, 결과도 한 사용자에게 돌아간다.

다중 에이전트 협업은 다르다. 업무가 다른 역할로 넘어간다. 고객지원 에이전트가 "이 고객은 배송 지연으로 대체품을 요청했고, 주문 번호는 A123이며, 프리미엄 고객이므로 24시간 안에 해결해야 한다"는 맥락을 공급망 에이전트에게 전달한다. 공급망 에이전트는 재고와 물류 상태를 확인한 뒤, 구매 에이전트에게 긴급 발주 가능성을 묻는다. 구매 에이전트는 승인 정책과 공급업체 조건을 검토하고, 결과를 다시 돌려준다.

여기서 중요한 것은 단순한 메시지 전송이 아니다. 협업에는 업무의 의미가 담겨야 한다. 요청의 목적, 필요한 입력, 기대하는 산출물, 진행 상태, 실패 이유, 사람이 승인해야 하는 지점이 함께 전달되어야 한다. 그래야 다음 에이전트가 이전 단계의 맥락을 잃지 않고 자신의 일을 시작할 수 있다.

이 차이를 실제 업무 흐름으로 보면 더 분명하다. 단일 에이전트 자동화는 "내가 가진 도구로 처리할 수 있는 일"에 강하다. 다중 에이전트 협업은 "여러 조직과 시스템의 판단이 이어져야 하는 일"에 필요하다. 기업 자동화의 큰 가치는 후자에서 나온다. 고객 요청 처리, 채용, 구매 승인, 공급망 조정, 장애 대응처럼 중요한 업무일수록 여러 역할이 연결된다.

점대점 통합의 비용

에이전트를 서로 연결하는 방법이 전혀 없었던 것은 아니다. 개발자는 특정 에이전트와 다른 에이전트 사이에 API를 만들 수 있다. 고객지원 에이전트가 구매 에이전트의 REST API를 호출하고, 구매 에이전트가 공급망 에이전트의 별도 API를 호출하는 식이다. 이런 방식은 작은 규모에서는 충분히 동작한다.

문제는 수가 늘어날 때 생긴다. 에이전트가 두세 개일 때는 연결을 직접 관리할 수 있다. 하지만 고객지원, 구매, 인사, 재무, 법무, 공급망, 영업, 외부 파트너 에이전트가 함께 움직이기 시작하면 연결선은 빠르게 늘어난다. 각 연결마다 인증 방식, 요청 형식, 오류 처리, 상태 표현, 로그 정책을 따로 맞춰야 한다. 어느 한 에이전트의 인터페이스가 바뀌면 연결된 모든 상대가 영향을 받는다.

이것이 점대점(point-to-point) 통합의 전형적인 한계다. 점대점 통합은 두 시스템을 직접 잇는 방식이다. 처음에는 빠르지만, 연결 대상이 늘수록 유지보수 비용이 커진다. 특히 에이전트는 일반적인 API 클라이언트보다 더 복잡하다. 단순히 값을 조회하는 것이 아니라 작업을 요청하고, 중간 상태를 기다리고, 추가 정보를 요구하고, 결과물을 주고받아야 한다.

벤더와 프레임워크가 다르면 문제는 더 커진다. 어떤 에이전트는 Google Cloud 위에서 동작하고, 어떤 에이전트는 다른 클라우드에 있으며, 어떤 에이전트는 특정 에이전트 프레임워크로 만들어졌을 수 있다. 기업은 이미 여러 클라우드, 여러 SaaS, 여러 내부 플랫폼을 사용한다. 에이전트도 같은 방식으로 다양해질 가능성이 높다. 이 환경에서 모든 연결을 개별 프로젝트로 처리하면 확장성은 곧 한계에 부딪힌다.

필요한 것은 개별 연결이 아니라 공통 약속이다. 에이전트가 자신을 설명하고, 상대의 능력을 발견하고, 작업을 요청하고, 상태를 확인하고, 결과를 주고받는 표준 방식이 필요하다. 이것이 상호운용성(interoperability)의 핵심이다. 상호운용성은 서로 다른 시스템이 같은 회사 제품이 아니어도 함께 동작할 수 있는 능력을 말한다.

A2A가 등장한 배경

구글은 2025년 4월 Agent2Agent Protocol, 즉 A2A를 공개하며 이 문제를 정면으로 다뤘다. 발표의 핵심은 명확했다. 기업은 이미 자율적으로 일하는 에이전트를 만들고 있지만, 그 에이전트들이 서로 다른 벤더, 프레임워크, 애플리케이션, 클라우드 환경을 넘어 협업하지 못하면 전체 업무 자동화는 제한된다는 것이다.¹

A2A는 특정 클라우드나 특정 프레임워크 안에서만 쓰는 내부 규칙이 아니다. 서로 다른 환경에서 만들어진 에이전트가 발견, 통신, 작업 조정, 결과 교환을 할 수 있도록 돕는 개방형 프로토콜을 지향한다. 여기서 프로토콜(protocol)은 시스템들이 대화하기 위해 지키는 약속이다. 사람 사이의 업무 양식처럼, 에이전트 사이에도 요청과 응답을 이해하기 위한 공통 형식이 필요하다.

구글이 처음 A2A를 발표할 때 50개 이상의 기술 파트너와 서비스 제공자가 함께 언급된 점도 중요하다.¹ 프로토콜의 가치는 문서 자체보다 채택에 달려 있다. 아무리 잘 설계된 약속이라도 실제 벤더와 기업이 따르지 않으면 또 하나의 고립된 기술이 된다. 이후 A2A 생태계는 150개 이상의 조직으로 확대되었고, 리눅스 재단에서 호스팅되는 프로젝트로 자리 잡으며 주요 클라우드와 기업 환경에서의 활용이 언급되었다.²

이 흐름은 A2A가 "구글 제품을 연결하기 위한 기능"에 머물지 않으려 한다는 신호다. 물론 구글은 A2A의 출발점에서 중요한 역할을 했다. 그러나 기업 입장에서 더 중요한 질문은 특정 회사가 만들었는지가 아니라, 여러 회사와 플랫폼이 함께 따를 수 있는 공통 계층이 될 수 있는가이다. 에이전트 협업은 한 공급자의 생태계 안에서만 일어나지 않는다. 고객, 파트너, 외부 서비스, 내부 시스템이 함께 연결될수록 개방형 표준의 필요성은 커진다.

A2A가 해결하려는 것과 그렇지 않은 것

A2A는 에이전트를 갑자기 더 똑똑하게 만드는 기술이 아니다. 잘못된 업무 규칙을 고쳐주지도 않고, 품질이 낮은 데이터를 자동으로 정리해주지도 않는다. 보안 정책, 승인 체계, 책임 소재도 기업이 별도로 설계해야 한다. A2A가 해결하려는 문제는 더 구체적이다. 서로 다른 에이전트가 협업할 때 필요한 공통 대화 방식과 작업 조정 방식을 제공하는 것이다.

이 구분은 중요하다. A2A를 도입한다고 해서 모든 업무가 자동화되는 것은 아니다. 하지만 A2A 같은 공통 프로토콜이 없으면 다중 에이전트 협업은 매번 새로운 통합 프로젝트가 된다. 에이전트가 늘어날수록 복잡도는 커지고, 운영팀은 연결을 유지하는 데 더 많은 시간을 쓴다.

앞으로의 기업 AI는 "가장 똑똑한 에이전트 하나"를 찾는 경쟁만으로 설명하기 어렵다. 더 현실적인 방향은 여러 전문 에이전트가 각자의 경계를 지키며 협력하는 구조다. 고객지원 에이전트가 고객의 문제를 이해하고, 구매 에이전트가 조달 가능성을 판단하며, 공급망 에이전트가 납기 리스크를 계산하고, 인사 에이전트가 채용 절차를 이어받는 식이다.

그 협업이 자연스럽게 이어지려면 에이전트들은 서로 말할 수 있어야 한다. 단순히 텍스트를 주고받는 수준이 아니라, 업무 맥락과 상태와 결과를 이해할 수 있는 방식으로 말해야 한다. A2A는 바로 그 필요에서 출발한다. 다음 장에서는 이 프로토콜이 정확히 무엇이고, 어디까지를 맡으며, 다른 도구·데이터 연결 방식과 어떤 경계를 갖는지 살펴본다.

참고

¹Announcing the Agent2Agent Protocol (A2A)

²A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year