안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
얼마 전 이 블로그에서 MCP를 소개했습니다. AI가 사내 시스템과 데이터에 연결되는 표준이었죠.
그런데 AI를 본격적으로 쓰기 시작한 회사들이 다음으로 부딪히는 벽이 있습니다.
영업팀은 CRM에 들어 있는 AI 에이전트를 쓰고, 재무·구매는 SAP의 Joule을 쓰고, IT팀은 AWS 위에 자체 에이전트를 만들었습니다.
각자는 똑똑합니다. 그런데 서로 대화를 못 합니다.
그래서 결국 사람이 중간에서 이쪽 AI의 답을 복사해 저쪽 AI에 붙여넣고 있죠. AI를 도입했는데, 사람이 AI 사이의 통역사가 된 셈입니다.
이 문제를 풀겠다고 나온 표준이 A2A입니다.
그리고 지난주 SAP TechEd 2026에서 SAP는 외부 에이전트가 A2A로 SAP 에이전트를 호출할 수 있도록 문을 열었습니다.
*AI로 제작된 이미지입니다.
A2A는 Agent-to-Agent, 즉 에이전트와 에이전트 사이의 통신 표준입니다.
서로 다른 회사가 만든, 서로 다른 플랫폼 위의 AI 에이전트들이 서로를 찾고, 대화하고, 일을 주고받을 수 있게 하는 공통 규칙이죠.
원래 구글이 2025년에 처음 발표했고, 이후 특정 기업이 아니라 중립적인 기관이 관리하도록 리눅스 재단에 넘겨졌습니다.
흥미로운 건 지금은 MCP와 같은 리눅스 재단 산하 조직에서 함께 관리되고 있다는 점입니다.
두 표준이 짝을 이루는 구조가 된 거죠.
가장 많이 헷갈리는 부분이라 정리하고 가겠습니다.
MCP는 AI와 '도구' 사이의 연결입니다.
AI가 데이터베이스를 조회하고, 파일을 읽고, 시스템 기능을 호출하는 방법이죠.
A2A는 AI와 ‘AI’ 사이의 연결입니다.
한 에이전트가 다른 에이전트에게 일을 맡기고, 진행 상황을 주고받고, 결과를 돌려받는 방법입니다.
회사에 비유하면 이렇습니다.
MCP는 직원 한 명이 사내 시스템을 다루는 방법이고, A2A는 부서와 부서가 협업하는 방법입니다.
직원이 아무리 시스템을 잘 다뤄도, 부서 간 협업 규칙이 없으면 일이 중간에서 끊기죠.
그래서 실제로는 둘 중 하나를 고르는 게 아니라, 두 개를 함께 쓰는 경우가 대부분입니다.
이번 TechEd에서 SAP가 A2A와 MCP를 함께 지원한다고 밝힌 것도 같은 이유입니다.
A2A의 핵심 개념 중 하나는 에이전트 카드(Agent Card) 입니다.
각 에이전트가 일종의 명함을 공개합니다.
"나는 이런 일을 할 수 있고, 이런 방식으로 요청하면 된다"는 정보죠.
다른 에이전트는 이 명함을 보고 누구에게 일을 맡길지 판단합니다.
예를 들어 이런 흐름이 가능해집니다.
고객이 배송 지연에 대해 문의합니다.
고객 응대 에이전트가 접수한 뒤, A2A로 SAP의 Joule 에이전트에게 "이 주문의 출하 상태를 확인해줘"라고 요청합니다.
Joule 에이전트는 SAP 데이터를 조회해 답을 돌려주고, 필요하면 재고 확인을 다른 에이전트에게 다시 넘깁니다.
고객 응대 에이전트는 이 결과를 모아 고객에게 답합니다.
사람이 시스템 세 개를 오가며 복사하던 일을, 에이전트들이 서로 주고받으며 처리하는 겁니다.
(위 예시는 이해를 돕기 위한 시나리오입니다.)
표준은 결국 얼마나 많이 쓰이느냐가 전부입니다.
A2A는 빠르게 자리를 잡고 있습니다.
리눅스 재단에 따르면 올해 4월 기준 150개가 넘는 기관이 A2A를 지원하고 있습니다.
AWS, 구글, 마이크로소프트, SAP, 세일즈포스, IBM, 시스코, 서비스나우 같은 이름들이 들어 있고요.
BSG가 함께하는 두 플랫폼도 모두 포함됩니다.
SAP는 A2A를 멀티 에이전트 협업의 우선 표준으로 채택했습니다.
Joule 에이전트가 SAP 내부 에이전트는 물론, AWS Bedrock AgentCore나 마이크로소프트 Copilot Studio,
구글 Vertex AI 같은 외부 플랫폼의 에이전트와도 협업할 수 있도록 하고 있죠.
그리고 이번 TechEd에서 외부 에이전트가 표준 방식으로 SAP의 에이전트를 호출할 수 있는 관문을 공식화했습니다.
AWS는 에이전트를 배포하고 운영하는 서비스인 Bedrock AgentCore에 A2A를 기본 지원으로 넣었습니다.
AWS 위에서 만든 에이전트가 A2A로 다른 에이전트와 대화할 수 있다는 뜻입니다.
한 회사의 AI에 묶이지 않아도 됩니다.
지금까지는 “AI를 제대로 쓰려면 한 벤더의 생태계로 통일해야 하나?”라는 고민이 있었습니다.
A2A가 자리 잡으면 그럴 필요가 줄어듭니다.
영업은 영업 시스템의 AI를, 재무는 SAP의 AI를 그대로 쓰면서 서로 연결하면 되니까요.
이미 쓰는 시스템을 버리지 않아도 됩니다.
각 업무 시스템 안에는 그 업무를 가장 잘 아는 에이전트가 들어오고 있습니다.
이걸 하나로 갈아엎는 대신, 잘하는 에이전트끼리 협업하게 만드는 방향입니다.
사람이 '통역'에서 빠집니다.
AI 사이를 오가며 복사·붙여넣기 하던 일이 줄어들면, 사람은 판단과 승인에 집중할 수 있습니다.
에이전트끼리 일을 넘기기 시작하면 새로운 질문이 생깁니다.
"누구의 권한으로 실행되는가?"
고객 응대 에이전트가 Joule에게 일을 맡겼을 때, 그 작업은 누구 권한으로 돌아가야 할까요?
이걸 잘못 설계하면 원래 볼 수 없던 데이터가 에이전트를 거쳐 흘러나갈 수 있습니다.
지난 글에서 다룬 "에이전트 권한" 문제가 여러 에이전트 사이로 확장되는 셈입니다.
SAP가 A2A 연동에 신원 관리, 역할 기반 권한, 감사 기록을 함께 강조하는 이유이기도 하고요.
"무슨 일이 있었는지 추적할 수 있는가?"
에이전트 세 개를 거쳐 처리된 일에서 문제가 생기면, 어느 단계에서 틀렸는지 알 수 있어야 합니다.
TechEd에서 AI 사용 현황을 중앙에서 추적하는 기능이 함께 발표된 것도 이 때문입니다.
"아직 생태계는 초기다."
표준 자체는 안정화 단계에 들어섰지만, 실제 기업 환경에서 여러 벤더의 에이전트를 엮어 운영한 경험은 아직 많지 않습니다.
작은 범위로 검증하며 넓혀가는 접근이 필요합니다.
MCP가 “AI가 우리 시스템을 쓸 수 있게” 만드는 표준이었다면, A2A는 “AI들이 서로 함께 일할 수 있게” 만드는 표준입니다.
AI 도입의 다음 단계는 더 똑똑한 에이전트 하나를 들이는 게 아니라, 이미 있는 에이전트들을 팀으로 묶는 일이 될 가능성이 큽니다.
그리고 그 연결의 한가운데에는 대개 SAP와 클라우드가 있습니다.
업무 데이터는 SAP에, 에이전트를 돌리는 인프라는 클라우드에 있으니까요.
BSG는 SAP 플래티넘 파트너이자 AWS MSP 파트너로서 바로 이 두 세계를 잇는 일을 해왔고,
최근에는 SAP Partner-led AI Adoption Incentive 공식 참여 파트너로 선정돼 Joule Studio 기반 에이전트 구축을 함께하고 있습니다.
Joule과 AWS 위의 에이전트를 어떻게 연결할지 고민 중이시라면, 함께 설계해보시죠.
출처 : Linux Foundation A2A Protocol 발표(2026. 4.), SAP TechEd 2026 발표, SAP Architecture Center, Amazon Bedrock AgentCore 공식 문서
기획 : 도예원