Agent2Agent란 무엇인가: MCP 이후 AI 에이전트 협업을 위한 연결 계층

Agent2Agent란 무엇인가: AI 에이전트가 서로 일하기 위한 연결 계층

2026년 7월 7일
전략 분석

핵심 요약

Agent2Agent(A2A)는 AI 에이전트가 서로의 능력을 발견하고, 작업을 요청하고, 결과를 주고받기 위한 상호운용성 계층이다. 단순히 “에이전트끼리 대화하는 기술”이 아니라 서로 다른 프레임워크와 벤더에서 만든 에이전트가 협업하기 위한 공통 언어에 가깝다. 출처: Agent2Agent (A2A) Project · GitHub, A2A/README.md at main · a2aproject/A2A · GitHub
MCP가 에이전트와 도구·데이터·업무 시스템을 연결하는 계층이라면, A2A는 에이전트와 에이전트를 연결하는 계층으로 이해하는 것이 정확하다. 둘은 대체 관계가 아니라 보완 관계다. 출처: Introduction to A2A – Agent Development Kit (ADK), Enterprise-Managed Authorization – Model Context Protocol
기업 AI의 다음 병목은 모델 성능만이 아니다. 여러 에이전트가 어떤 권한으로 누구에게 일을 맡기고, 어떤 결과를 신뢰하며, 어떤 로그로 감사를 남길 것인가가 핵심 과제가 된다.
A2A 자체가 보안, 권한, 승인, 감사 문제를 모두 해결하지는 않는다. 실제 운영에서는 신원 관리, 접근 제어, 데이터 유출 방지, 로그 모니터링, 사람 승인 절차와 함께 설계해야 한다.
실무자가 지금 해야 할 일은 A2A를 즉시 도입할지 말지보다, 조직의 AI 아키텍처를 “도구 연결 계층, 에이전트 협업 계층, 제어·감사 계층”으로 나누어 설계할 준비를 하는 것이다.

왜 지금 Agent2Agent가 문제인가

초기 기업 AI 도입의 질문은 비교적 단순했다. 어떤 모델을 쓸 것인가. 어떤 사내 문서를 검색하게 할 것인가. 어떤 업무 시스템의 API를 연결할 것인가. 이 단계에서 AI는 대체로 하나의 대화형 인터페이스이거나, 특정 도구를 호출하는 자동화 도우미에 가까웠다. 사용자가 질문하면 모델이 답하고, 필요하면 검색, 데이터베이스 조회, 티켓 생성, 문서 요약 같은 도구 호출을 수행했다.

그러나 에이전트 논의가 본격화되면 질문이 달라진다. 하나의 범용 에이전트가 영업, 재무, 법무, 보안, 개발, 고객지원, 구매, 인사 업무를 모두 정확히 수행할 수 있는가. 현실적으로는 어렵다. 기업 업무는 도메인별 규칙, 권한, 승인 체계, 데이터 접근 범위, 책임 주체가 다르다. 따라서 앞으로의 에이전트 구조는 하나의 거대한 만능 에이전트보다, 여러 전문 에이전트가 각자의 역할을 맡고 필요한 순간 협업하는 구조로 확장될 가능성이 크다.

이때 새로운 문제가 생긴다. 영업 에이전트가 계약 검토 에이전트에게 어떤 형식으로 일을 맡길 것인가. 고객지원 에이전트가 환불 정책 에이전트의 능력을 어떻게 발견할 것인가. 분석 에이전트가 재무 데이터 에이전트에 요청할 때 어떤 권한과 사용자 맥락을 전달할 것인가. 외부 파트너가 제공한 에이전트를 내부 에이전트가 호출해도 되는가. 결과가 틀렸을 때 책임은 요청한 에이전트, 수행한 에이전트, 승인한 사람, 또는 플랫폼 중 어디에 있는가.

Agent2Agent는 이 질문에 대한 표준화 시도 중 하나다. Agent2Agent(A2A) 공식 프로젝트는 이 프로토콜을 독립적이고 잠재적으로 내부 구조가 불투명한 AI 에이전트 시스템 사이의 통신과 상호운용성을 촉진하기 위한 개방형 표준으로 설명한다. 여기서 중요한 표현은 “불투명한 에이전트 애플리케이션”이다. A2A는 상대 에이전트의 내부 프롬프트, 모델, 도구 체인, 추론 과정을 모두 알아야 협업할 수 있다는 전제에 서지 않는다. 대신 외부에서 이해 가능한 능력 설명과 공통 상호작용 방식을 통해 협업을 가능하게 하려는 접근이다. 출처: A2A/docs/specification.md at main · a2aproject/A2A – GitHub, a2aproject/A2A: Agent2Agent (A2A) is an open protocol … – GitHub

Agent2Agent(A2A)의 핵심: 대화가 아니라 업무 위임

A2A를 “에이전트끼리 채팅하는 기술”로 이해하면 핵심을 놓친다. 기업 환경에서 중요한 것은 자연어 대화 자체가 아니라 업무 위임의 구조다. 한 에이전트가 다른 에이전트에게 “이 일을 할 수 있는가”를 묻고, 필요한 입력을 제공하고, 진행 상태를 확인하고, 결과를 받아 다음 의사결정이나 실행에 반영하는 흐름이 중요하다.

예를 들어 고객지원 에이전트가 고객의 환불 요청을 받았다고 하자. 이 에이전트는 주문 이력 조회 도구를 직접 호출할 수도 있지만, 환불 정책 판단은 정책 에이전트에게 맡기는 편이 더 안전할 수 있다. 정책 에이전트는 최신 약관, 지역별 소비자 보호 규정, 상품 유형별 예외 조건을 알고 있다. 이후 고객지원 에이전트는 결제 에이전트에 환불 가능 금액 계산을 요청하고, 고액 환불이면 사람 승인 워크플로우로 넘길 수 있다. 이 구조에서 각 에이전트는 단순한 함수가 아니다. 자신의 업무 범위, 판단 기준, 입력 요구사항, 출력 형식, 실패 가능성을 가진 실행 주체다.

Agent2Agent(A2A)가 다루려는 영역은 바로 이 지점이다. 서로 다른 에이전트가 같은 회사 안에서 만들어졌을 수도 있고, 다른 벤더의 플랫폼에서 실행될 수도 있으며, 서로 다른 언어와 프레임워크로 구현됐을 수도 있다. 이들이 매번 맞춤형 통합 코드를 작성하지 않고도 협업하려면 공통 프로토콜이 필요하다. Google의 A2A 발표 역시 여러 엔터프라이즈 플랫폼이나 애플리케이션 위에서 에이전트가 정보를 안전하게 교환하고 작업을 조정하는 흐름을 강조한다. 출처: Announcing the Agent2Agent Protocol (A2A), Samples using the Agent2Agent (A2A) Protocol – GitHub

실무적으로 보면 Agent2Agent(A2A)의 가치는 세 가지로 압축된다. 첫째, 에이전트 발견이다. 어떤 에이전트가 존재하고 무엇을 할 수 있는지 알 수 있어야 한다. 둘째, 능력 설명이다. 해당 에이전트가 처리 가능한 업무, 필요한 입력, 반환하는 결과, 제약 조건을 기계가 이해할 수 있는 형태로 표현해야 한다. 셋째, 작업 상호작용이다. 요청, 진행, 결과, 오류, 취소, 후속 질문 같은 업무 흐름을 공통 방식으로 처리해야 한다.

MCP와 Agent2Agent(A2A)는 무엇이 다른가

MCP와 A2A의 차이는 연결 대상에서 출발한다. MCP(Model Context Protocol)는 모델이나 에이전트가 외부 도구, 데이터, 리소스에 접근하기 위한 표준화된 연결 방식으로 이해할 수 있다. 예를 들어 파일 시스템, 데이터베이스, 사내 지식베이스, 업무 SaaS, 개발 도구를 AI 애플리케이션에 연결하는 문제에 가깝다. 반면 Agent2Agent(A2A)는 에이전트가 다른 에이전트와 협업하기 위한 프로토콜이다. ADK 문서도 복잡한 에이전트 시스템을 만들수록 단일 에이전트만으로 충분하지 않고, 전문 에이전트들이 A2A를 통해 협업할 수 있다는 맥락에서 설명한다. 출처: ADK with Agent2Agent (A2A) Protocol – Agent Development Kit (ADK), Introduction to A2A – Agent Development Kit (ADK)

구분	MCP	A2A
핵심 질문	에이전트가 어떤 도구와 데이터에 접근할 수 있는가	에이전트가 어떤 다른 에이전트와 협업할 수 있는가
연결 대상	도구, 데이터 소스, 파일, API, 업무 시스템	독립적 에이전트, 전문 에이전트, 외부 에이전트 애플리케이션
주요 가치	도구 호출 표준화, 컨텍스트 제공, 시스템 연동 단순화	에이전트 발견, 역량 설명, 작업 위임, 결과 교환
실무 예	CRM 조회, 데이터베이스 질의, 문서 검색, 티켓 생성	영업 에이전트가 법무 에이전트에 계약 검토 요청
보안 초점	도구 접근 권한, 사용자 동의, 서버별 인증·인가	에이전트 신원, 위임 권한, 신뢰 경계, 책임 추적

이 차이를 이해하면 “A2A가 MCP를 대체하는가”라는 질문은 부정확해진다. MCP는 에이전트가 업무 시스템에 손을 뻗는 통로이고, Agent2Agent(A2A)는 에이전트가 다른 업무 주체에게 일을 맡기는 통로다. 실제 기업 환경에서는 두 계층이 함께 쓰일 가능성이 크다. 예를 들어 영업 에이전트가 A2A로 가격 책정 에이전트에 견적 생성을 요청하고, 가격 책정 에이전트는 MCP를 통해 ERP, 계약 데이터베이스, 할인 정책 문서에 접근하는 식이다.

MCP 쪽에서도 기업 운영의 핵심 문제가 권한과 중앙 관리로 이동하고 있다. MCP의 Enterprise-Managed Authorization 문서는 일반적인 사용자 주도 승인 방식이 기업 환경에서는 마찰과 보안 공백을 만들 수 있으며, 조직이 신원 제공자를 통해 MCP 서버 접근을 중앙에서 관리하는 방식을 설명한다. 이는 도구 연결 계층에서도 이미 제어 평면의 중요성이 커지고 있음을 보여준다. 출처: Enterprise-Managed Authorization – Model Context Protocol, 모델 컨텍스트 프로토콜, 기업용 중앙 집중식 인증 체계 도입

에이전트 발견과 역량 설명: 협업의 첫 번째 조건

여러 에이전트가 함께 일하려면 먼저 서로를 찾아야 한다. 사람이 조직도와 업무 매뉴얼을 보고 “이 일은 법무팀에 물어봐야 한다”고 판단하듯, 에이전트도 어떤 상대가 어떤 일을 처리할 수 있는지 알아야 한다. 이때 필요한 것이 에이전트 발견과 역량 설명이다.

Agent2Agent(A2A) 생태계에서는 에이전트가 자신이 제공하는 능력, 상호작용 방식, 입력과 출력의 기대 형식, 인증 요구사항 등을 외부에 설명하는 구조가 중요해진다. 공식 문서의 세부 구현은 계속 발전할 수 있지만, 실무 관점에서 본질은 분명하다. 에이전트 설명은 단순 소개 문서가 아니라 실행을 유도하는 계약이다. “나는 계약서를 검토할 수 있다”는 문장이 아니라, “나는 어떤 계약 유형을 다루고, 어떤 입력이 필요하며, 어떤 위험 항목을 반환하고, 어떤 경우 사람 검토가 필요하다고 표시하는가”까지 포함해야 한다.

이 지점은 MCP의 도구 설명과도 닮았다. MCP 서버가 제공하는 도구 설명이 모델의 도구 선택을 유도하듯, A2A의 에이전트 능력 설명도 다른 에이전트의 위임 결정을 유도한다. 따라서 설명 메타데이터는 보안적으로 민감한 표면이 된다. 악의적이거나 부정확한 에이전트 설명은 잘못된 작업 위임을 유발할 수 있다. 예를 들어 “개인정보 비식별화 전문 에이전트”라고 자신을 소개하지만 실제로는 원문 데이터를 외부로 전송하는 에이전트가 있다면, 연결 표준은 오히려 위험을 빠르게 확산시키는 통로가 될 수 있다.

실무자는 에이전트 설명을 신뢰 가능한 출처, 서명, 등록 절차, 검증된 카탈로그, 정책 기반 승인과 함께 다뤄야 한다. 내부 에이전트 카탈로그를 운영한다면 단순 이름 목록이 아니라 소유 조직, 데이터 접근 범위, 허용 업무, 금지 업무, 감사 로그 위치, 장애 대응 담당자를 함께 관리해야 한다. A2A는 발견과 통신의 공통 기반을 제공하려는 시도지만, 기업이 어떤 에이전트를 신뢰할지는 별도의 거버넌스 문제다. 출처: A2A/docs/specification.md at main · a2aproject/A2A – GitHub, Service Discovery and Governance for A2A Java Implementations

작업 위임과 책임 소재: 멀티 에이전트의 진짜 난점

멀티 에이전트 구조에서 가장 어려운 문제는 연결 자체보다 책임의 경계다. 단일 에이전트가 도구를 호출하는 구조에서는 비교적 단순하게 추적할 수 있다. 사용자가 요청했고, 에이전트가 판단했고, 특정 도구 호출이 실행됐고, 결과가 반환됐다. 하지만 에이전트가 다른 에이전트에게 작업을 넘기기 시작하면 실행 사슬이 길어진다.

예를 들어 영업 에이전트가 고객사의 제안요청서를 분석하고, 산업 분석 에이전트에 시장 자료 요약을 요청하고, 가격 책정 에이전트에 견적안을 요청하고, 법무 에이전트에 계약 리스크 검토를 요청한다고 하자. 최종 제안서에 잘못된 할인 조건이 포함됐다면 누구의 오류인가. 영업 에이전트가 잘못 위임했는가. 가격 책정 에이전트가 오래된 정책을 참조했는가. MCP로 연결된 ERP 데이터가 최신이 아니었는가. 승인자가 검토를 건너뛰었는가.

이 문제는 기술 아키텍처이면서 운영 아키텍처다. 기업은 에이전트 간 요청에 대해 요청 주체, 원 사용자, 권한 범위, 데이터 출처, 중간 결과, 최종 승인자를 남겨야 한다. 특히 금융, 의료, 공공, 법무, 보안처럼 규제와 책임이 중요한 영역에서는 에이전트가 “그럴듯한 결과”를 반환하는 것만으로 충분하지 않다. 왜 그런 결과가 나왔는지, 어떤 입력과 근거를 사용했는지, 누가 실행을 승인했는지 추적 가능해야 한다.

따라서 Agent2Agent(A2A) 도입을 검토하는 조직은 프로토콜 호환성보다 먼저 업무 위임 정책을 정의해야 한다. 어떤 에이전트가 다른 에이전트에게 직접 요청할 수 있는가. 민감 데이터가 포함된 요청은 어떤 경로를 지나야 하는가. 고위험 작업은 사람 승인이 필요한가. 외부 에이전트의 결과는 자동 실행에 쓸 수 있는가, 아니면 참고 정보로만 쓸 수 있는가. 이 질문에 답하지 않은 상태에서 에이전트 연결만 늘리면 자동화의 속도만큼 사고의 전파 속도도 빨라진다.

Agentic Control Plane: 연결보다 중요한 제어 계층

Agentic Control Plane은 아직 업계에서 하나의 완전히 고정된 제품 범주로 정리된 용어라기보다, 여러 AI 에이전트가 조직 안에서 통제 가능한 방식으로 일하게 만드는 연결·권한·정책·감사 계층을 가리키는 실무적 개념에 가깝다. 여기에는 에이전트 등록, 신원 확인, 권한 부여, 정책 집행, 로그 수집, 위험 탐지, 비용 관리, 사람 승인, 장애 대응이 포함된다.

Agent2Agent(A2A)는 이 제어 평면의 한 구성 요소가 될 수 있다. 그러나 Agent2Agent 자체가 제어 평면 전체는 아니다. Agent2Agent(A2A)가 에이전트 간 통신과 상호운용성의 공통 언어라면, 제어 평면은 “그 통신을 어떤 조건에서 허용하고, 어떤 요청을 차단하며, 어떤 결과를 승인하고, 어떤 행위를 감사할 것인가”를 결정하는 운영 계층이다.

이 구분이 중요한 이유는 기업 AI의 위험이 점점 “모델이 이상한 말을 한다”에서 “권한을 가진 에이전트가 실제 시스템에서 잘못된 행동을 한다”로 이동하기 때문이다. 읽기 전용 요약 챗봇의 오류는 대체로 사용자 판단 단계에서 걸러질 수 있다. 반면 에이전트가 데이터베이스를 수정하고, 고객에게 이메일을 보내고, 결제를 승인하고, 보안 설정을 바꾸고, 다른 에이전트에게 업무를 재위임한다면 위험은 실행 계층으로 내려간다. 출처: Enterprise-Managed Authorization – Model Context Protocol, A2A Security Specification – GitHub, 지티티코리아, Cybersecurity Insiders

최근 여러 벤더와 보안 기업이 에이전틱 AI의 제어 지점, 게이트웨이, 정책 집행, 통합 감사 계층을 강조하는 것도 같은 맥락이다. 예를 들어 데이터와 모델이 결합된 산업별 에이전트 워크플로우, 보안 검사를 위한 런타임 API 호출, 단일 정책 집행 지점 같은 접근은 모두 “에이전트가 많아질수록 중앙 통제가 필요하다”는 문제의식을 공유한다. 다만 특정 기업의 발표를 곧바로 업계 표준의 승패로 해석해서는 안 된다. 현재 확인할 수 있는 것은 주요 기업들이 에이전트 실행을 안전하게 운영하기 위한 제어 계층에 관심을 집중하고 있다는 점이다. 출처: A2A Java Governance Issue – GitHub, 스노우플레이크-엔비디아 블로그, 팔로알토 네트웍스 블로그

실무 시나리오로 보는 A2A의 의미

1. 고객지원 에이전트와 정책 에이전트

상황: 고객의 환불, 교환 등 약관 예외 문의 발생. 입력: 고객 문의, 주문 이력, 이전 보상 내역. 실행 흐름: 고객지원 에이전트가 의도 파악 후 정책 에이전트에 환불 여부 판단을 요청한다. 정책 에이전트가 약관과 예외 규칙을 적용한 근거를 반환하며, 고액 건은 사람 승인으로 넘긴다. 출력: 응대 초안, 정책 근거, 승인 필요 여부. 주의점: 협업 시 불필요한 개인정보 전달을 최소화해 데이터 노출 위험을 방지해야 한다.

2. 영업 에이전트와 법무·가격 책정 에이전트

상황: 기업 고객 제안서 및 견적 작성. 입력: 고객 요구사항, 계약 규모, 할인 요청, 표준 계약서. 실행 흐름: 영업 에이전트가 가격 에이전트에 견적을, 법무 에이전트에 비표준 조항 검토를 요청한다. 결과를 통합해 최종 제안 전 사람 승인자에게 변경 사항과 리스크를 전달한다. 출력: 견적안, 계약 리스크 목록, 승인 체크리스트. 주의점: A2A 연결이 가능하더라도 할인 등 민감한 결정 권한은 에이전트가 단독으로 자동 확정해서는 안 된다.

3. 개발 에이전트와 보안 검토 에이전트

상황: 코드 변경 제안 및 배포 보조. 입력: 변경 diff, 의존성 목록, 보안 정책. 실행 흐름: 개발 에이전트가 보안 검토 에이전트에 취약점 검토를 요청한다. 보안 에이전트가 비밀값 노출, 위험한 외부 호출, 민감 로그 여부를 확인해 고위험 건을 차단한다. 출력: 보안 검토 결과, 수정 권고, 차단 여부. 주의점: 보안 에이전트는 개발 에이전트의 하위 도구가 아닌 독립적인 정책 집행 지점으로 작동해야 한다.

4. 데이터 분석 에이전트와 개인정보 보호 에이전트

상황: 마케팅 목적의 고객 데이터 분석. 입력: 분석 목적, 필요 필드, 데이터 민감도. 실행 흐름: 분석 에이전트가 개인정보 보호 에이전트에 사용 가능 여부를 확인한다. 개인정보 에이전트가 최소 필드 원칙 및 비식별화 조건을 판단해 허용한 범위 내에서 분석을 수행한다. 출력: 허용 데이터 범위, 비식별화 조건, 분석 결과. 주의점: 동일 데이터라도 분석 목적에 따라 허용 범위가 달라지므로 목적 정의를 엄격히 검증해야 한다.

보안과 거버넌스: A2A 도입 전 반드시 물어야 할 질문

Agent2Agent(A2A)는 협업을 쉽게 만들 수 있지만, 협업이 쉬워진다는 것은 요청 경로가 늘어난다는 뜻이기도 하다. 보안팀 관점에서는 새로운 공격 표면이 생긴다. 에이전트 설명이 변조될 수 있고, 신뢰하지 않는 외부 에이전트가 내부 요청을 유도할 수 있으며, 한 에이전트가 받은 권한이 다른 에이전트로 과도하게 위임될 수 있다. 또한 민감 데이터가 중간 에이전트를 거치며 예상치 못한 곳에 기록될 수 있다.

첫 번째 원칙은 최소 권한이다. 에이전트는 자신의 업무 수행에 필요한 데이터와 도구에만 접근해야 한다. 특히 다른 에이전트를 호출할 때 원 사용자 권한을 그대로 전달할지, 제한된 위임 토큰을 발급할지, 작업별 일회성 권한을 사용할지 결정해야 한다. 사람에게 부여된 넓은 권한을 에이전트가 그대로 상속하면 내부자 위험과 유사한 문제가 생긴다. 출처: 권한 부여된 AI 에이전트의 통제 불능 위험, 신뢰 모델 재설계 시급

두 번째 원칙은 작업별 승인이다. 읽기, 요약, 추천, 초안 작성, 외부 전송, 데이터 수정, 결제, 계정 변경은 위험 수준이 다르다. 모든 요청을 같은 방식으로 처리하면 과도하게 느슨하거나 과도하게 불편한 시스템이 된다. 실무적으로는 위험 등급을 나누고, 낮은 위험 작업은 자동화하되 고위험 작업은 사람 승인이나 추가 정책 검사를 요구해야 한다.

세 번째 원칙은 에이전트 신원 확인이다. 사람 사용자, 서비스 계정, 도구 서버뿐 아니라 에이전트 자체도 식별 가능한 주체로 관리해야 한다. 어떤 에이전트가 어떤 버전으로 실행됐고, 어떤 조직이 소유하며, 어떤 정책 묶음에 속하는지 알아야 한다. 에이전트가 업데이트되거나 능력 설명이 바뀌면 재검증 절차가 필요하다.

네 번째 원칙은 요청·응답 로그와 감사 추적이다. 멀티 에이전트 환경에서 로그는 디버깅 자료가 아니라 책임 소재를 밝히는 핵심 증거다. 어떤 에이전트가 어떤 입력으로 누구에게 요청했고, 어떤 응답을 받았으며, 그 결과 어떤 도구 호출이나 업무 실행으로 이어졌는지 연결해야 한다. 단, 로그에 민감 데이터가 과도하게 남지 않도록 마스킹과 보존 정책도 함께 설계해야 한다.

다섯 번째 원칙은 결과 검증이다. 다른 에이전트의 응답을 그대로 실행하지 말고, 업무 중요도에 따라 검증 계층을 둬야 한다. 금액, 날짜, 법적 조항, 보안 설정, 고객 통지, 의료·금융 판단처럼 오류 비용이 큰 영역은 별도 검증 에이전트, 규칙 기반 검사, 사람 승인, 샘플링 감사가 필요하다.

Agent2Agent(A2A)를 기업 아키텍처에 넣는다면

Agent2Agent(A2A)를 실제 아키텍처에 넣을 때는 단순히 “A2A 서버를 만든다”가 아니라 계층을 나눠야 한다. 가장 아래에는 기존 업무 시스템과 데이터가 있다. 그 위에는 MCP 서버, API 게이트웨이, 데이터 접근 계층이 위치한다. 이 계층은 에이전트가 도구와 데이터에 접근하는 방식을 관리한다. 그 위에는 업무별 전문 에이전트가 있다. 영업 에이전트, 재무 에이전트, 법무 에이전트, 고객지원 에이전트, 보안 에이전트처럼 역할별로 나뉜다. A2A는 이 에이전트들이 서로 협업하는 통신 계층이 된다. 최상단에는 정책, 권한, 감사, 모니터링, 비용 관리, 사람 승인 흐름을 담당하는 제어 평면이 있어야 한다.

사용자 / 업무 프로세스
        ↓
오케스트레이션 에이전트 또는 업무별 에이전트
        ↓ A2A
전문 에이전트들: 법무, 재무, 보안, 분석, 고객지원
        ↓ MCP / API / 데이터 접근 계층
업무 시스템: CRM, ERP, 문서 저장소, 데이터베이스, 티켓 시스템
        ↕
제어 평면: IAM, 정책, 승인, 로그, 감사, 비용, 위험 탐지

이 구조에서 중요한 설계 판단은 세 가지다. 첫째, 오케스트레이션을 중앙 집중형으로 할지, 에이전트들이 분산적으로 서로 요청하게 할지 결정해야 한다. 중앙 집중형은 통제가 쉽지만 병목이 생길 수 있다. 분산형은 유연하지만 로그와 권한 추적이 복잡해진다. 둘째, 내부 에이전트와 외부 에이전트의 신뢰 경계를 명확히 해야 한다. 외부 에이전트는 기본적으로 낮은 신뢰 수준에서 시작하고, 민감 데이터 접근과 자동 실행 권한을 제한해야 한다. 셋째, 에이전트 결과가 업무 시스템에 쓰기 작업을 수행하는 순간 별도 승인과 검증을 요구해야 한다.

Envoy 커뮤니티에서도 A2A 지원과 서비스 발견, 거버넌스 패턴을 논의하는 움직임이 있다. 이는 A2A가 단순 애플리케이션 코드 내부의 라이브러리 문제가 아니라, 프록시, 게이트웨이, 서비스 메시, 관측성 같은 엔터프라이즈 인프라 논의와 연결될 수 있음을 시사한다. 다만 이 역시 진행 중인 설계 논의로 보아야 하며, 특정 구현이 표준 운영 방식으로 확정됐다고 단정해서는 안 된다. 출처: Design Proposal: Agent2Agent(A2A) Support in Envoy · Issue #43268, Service Discovery and Governance for A2A Java Implementations

제품·전략 담당자가 봐야 할 도입 판단 기준

Agent2Agent(A2A)를 검토할 때 “우리도 최신 프로토콜을 써야 하는가”보다 나은 질문은 “우리 조직에 에이전트 간 업무 위임이 실제로 필요한가”다. 단일 챗봇이 사내 문서를 검색하고 간단한 티켓을 만드는 수준이라면 A2A는 당장 핵심 과제가 아닐 수 있다. 반대로 여러 부서의 전문 에이전트가 협업하고, 외부 벤더 에이전트와 연동하며, 업무 결과가 실제 시스템 변경으로 이어진다면 에이전트 간 연결·제어 계층의 중요성은 커질 수 있다.

첫 번째 판단 기준은 에이전트 수와 다양성이다. 같은 프레임워크로 만든 내부 에이전트 두세 개라면 맞춤형 통합으로도 충분할 수 있다. 하지만 프레임워크, 벤더, 조직, 실행 환경이 달라질수록 공통 프로토콜의 가치가 커진다.

두 번째 판단 기준은 업무 위임의 위험도다. 단순 요약과 추천 중심이면 연결 표준의 효과가 먼저 보일 수 있다. 그러나 결제, 계약, 보안 설정, 개인정보 처리, 고객 통지처럼 되돌리기 어려운 작업이 포함되면 A2A 자체보다 권한과 승인 설계가 우선이다.

세 번째 판단 기준은 감사 요구 수준이다. 규제 산업이나 대기업 환경에서는 “누가 무엇을 왜 했는가”를 설명할 수 있어야 한다. 에이전트가 다른 에이전트에 재위임하는 구조라면 감사 로그도 단일 호출 로그를 넘어 작업 그래프 형태로 남겨야 한다.

네 번째 판단 기준은 벤더 종속성이다. A2A의 목표는 상호운용성이지만, 실제 구현과 운영 도구는 벤더별로 차이가 날 수 있다. 특정 플랫폼의 에이전트 카탈로그, 배포 도구, 관측성, 보안 정책에 깊이 묶이면 표준 프로토콜을 쓰더라도 운영 종속성이 생길 수 있다. 따라서 프로토콜 호환성과 운영 이식성을 나누어 평가해야 한다.

다섯 번째 판단 기준은 조직 운영 역량이다. 멀티 에이전트 시스템은 모델팀만의 일이 아니다. 보안, 법무, 데이터 거버넌스, 업무 부서, 플랫폼 엔지니어링, 감사 조직이 함께 기준을 정해야 한다. A2A는 기술 연결을 쉽게 만들 수 있지만, 책임과 승인 체계를 자동으로 만들어주지는 않는다.

Agent2Agent와 ARD: 용어보다 구조가 중요하다

일부 논의에서는 에이전트가 서로를 찾고 능력을 이해하는 방식을 가리켜 에이전트 리소스 발견 또는 유사한 표현을 쓰기도 한다. 다만 제공된 공식 A2A 자료 기준으로 “ARD”를 A2A의 확정된 핵심 공식 구성요소처럼 단정하기는 어렵다. 따라서 실무적으로는 특정 약어보다 구조를 보는 편이 안전하다.

중요한 질문은 네 가지다. 첫째, 에이전트는 어디에 등록되는가. 둘째, 능력 설명은 누가 검증하는가. 셋째, 요청자는 설명을 어떻게 신뢰하는가. 넷째, 능력 설명과 실제 동작이 달라졌을 때 어떻게 탐지하고 차단하는가. 이 질문에 답하지 못하면 어떤 약어를 쓰더라도 운영 위험은 남는다.

특히 에이전트 발견은 편의 기능이 아니라 보안 경계다. 검색 가능한 에이전트 목록이 곧 공격자가 탐색할 수 있는 표면이 될 수 있다. 따라서 내부 카탈로그, 접근 가능한 에이전트 범위, 외부 공개 여부, 버전 관리, 폐기 절차를 함께 설계해야 한다.

흔한 오해 네 가지

첫째, “A2A는 MCP의 다음 버전이다”라는 오해다. 아니다. MCP와 A2A는 다루는 연결 대상이 다르다. MCP는 도구와 데이터 연결에 가깝고, A2A는 에이전트 간 협업에 가깝다. 기업 아키텍처에서는 함께 쓰일 수 있다.

둘째, “A2A를 쓰면 에이전트들이 알아서 협업한다”는 오해다. 프로토콜은 상호작용 방식을 정할 수 있지만, 업무 목표, 권한, 승인, 데이터 정책, 책임 소재는 조직이 설계해야 한다.

셋째, “상호운용성은 곧 안전성이다”라는 오해다. 상호운용성은 연결 비용을 낮춘다. 그러나 연결이 쉬워질수록 잘못된 위임, 과도한 권한, 민감 데이터 전달, 결과 오용도 쉬워질 수 있다. 안전성은 별도의 정책과 제어 계층으로 확보해야 한다.

넷째, “하나의 표준이 곧 승자가 된다”는 오해다. A2A는 중요한 표준화 시도지만, 기업 AI 인프라는 프로토콜 하나로 정리되지 않는다. MCP, A2A, API 게이트웨이, 신원 관리, 데이터 거버넌스, 관측성, 보안 정책, 사람 승인 흐름이 함께 결합된다.

결론: 다음 경쟁력은 모델이 아니라 연결과 제어다

Agent2Agent의 의미는 새 프로토콜 하나를 더 배워야 한다는 데 있지 않다. 더 중요한 변화는 AI 에이전트가 기업 시스템 안에서 단독 도구가 아니라 협업하는 실행 주체로 다뤄지기 시작했다는 점이다. 업무별 전문 에이전트가 늘어나고, 서로 다른 벤더와 프레임워크의 에이전트가 함께 일하려면 공통 연결 계층이 필요하다. A2A는 그 흐름을 보여주는 대표적인 시도다.

그러나 연결은 시작일 뿐이다. 에이전트가 서로 일하기 시작하면 기업은 곧바로 더 어려운 질문을 만나게 된다. 어떤 에이전트를 신뢰할 것인가. 어떤 권한을 위임할 것인가. 어떤 데이터가 전달될 수 있는가. 어떤 결과는 자동 실행하고, 어떤 결과는 사람 승인을 요구할 것인가. 오류가 발생하면 어느 지점에서 책임을 추적할 것인가.

따라서 실무자가 기억해야 할 문장은 명확하다. MCP가 AI 에이전트와 도구를 연결하는 계층이라면, A2A는 AI 에이전트가 서로 일하기 위한 연결 계층이다. 그리고 기업 AI의 실제 경쟁력은 이 두 계층을 얼마나 안전하게 제어하고 감사할 수 있는가에서 갈릴 가능성이 크다.

참고 출처

함께 읽기: AI 에이전트 실무 도입