개방형 거버넌스와 표준화의 미래
표준은 코드보다 오래 살아야 한다
기업이 A2A를 검토할 때 처음 보는 것은 기술 명세다. Agent Card가 무엇인지, Task 상태가 어떻게 바뀌는지, 스트리밍과 Artifact가 어떻게 동작하는지 확인한다. 그러나 실제 채택 단계에서는 다른 질문이 더 중요해진다.
이 표준은 3년 뒤에도 유지될까. 특정 벤더의 제품 전략이 바뀌면 사라지지 않을까. 경쟁 클라우드와 SaaS 회사들이 같은 방식으로 구현할까. 보안 문제가 발견되었을 때 누가 고치고, 버전 호환성은 어떻게 관리할까.
엔터프라이즈 표준은 좋은 아이디어만으로 오래가지 않는다. 기술보다 더 느리고 지루해 보이는 요소, 즉 거버넌스와 생태계 신뢰가 필요하다. A2A의 마지막 장을 거버넌스로 마무리해야 하는 이유가 여기에 있다.
AI 생성 이미지
Google이 시작했지만 Google만의 것이 아니어야 한다
A2A는 Google이 처음 개발했다. 이는 장점이기도 했다. Google Cloud와 에이전트 개발 도구 생태계에서 실제 문제를 빠르게 발견하고, 프로토콜의 초기 형태를 만들 수 있었기 때문이다. 하지만 같은 사실은 기업 도입의 부담이 될 수도 있다. 한 회사가 주도하는 프로토콜은 아무리 공개되어 있어도 다른 벤더 입장에서는 조심스럽다. 고객도 특정 클라우드에 묶이는 신호로 받아들일 수 있다.
그래서 Google이 A2A를 Linux Foundation에 기여한 결정은 단순한 소유권 이전 이상의 의미를 갖는다. 공식 A2A 문서는 A2A가 Google에서 시작되어 Linux Foundation에 기여되었고, 현재는 AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, ServiceNow 대표가 참여하는 Technical Steering Committee가 유지한다고 설명한다.1 Linux Foundation 역시 이 이동을 장기적 중립성, 협업, 거버넌스를 확보하기 위한 조치로 설명했다.2
핵심은 Google이 빠졌다는 뜻이 아니다. 오히려 반대다. Google은 중요한 기여자로 남되, 표준의 방향이 Google 제품 일정만으로 결정되지 않도록 한 것이다. A2A가 정말로 서로 다른 클라우드, 프레임워크, 업무 애플리케이션 사이에서 쓰이려면 이 변화가 필요했다.
경쟁사가 같은 테이블에 앉는다는 것
Technical Steering Committee에 여러 경쟁사가 함께 있다는 사실은 상징 이상의 의미를 갖는다. A2A의 중요한 결정은 특정 SDK의 편의성보다 더 큰 범위를 다룬다. 예를 들어 다음과 같은 문제다.
Agent Card의 필수 필드를 어디까지 둘 것인가
Task 상태 전이를 얼마나 엄격하게 정의할 것인가
확장 필드는 어떻게 실험하고 언제 표준으로 승격할 것인가
인증과 신원 증명의 최소 요구사항을 어디에 둘 것인가
구버전 클라이언트와 신버전 서버가 함께 동작하도록 어떻게 보장할 것인가
이 문제들은 한 회사만의 사용 사례로 해결하기 어렵다. 클라우드 사업자는 확장성과 워크로드 신원을 중요하게 본다. SaaS 회사는 테넌트 경계와 업무 권한을 중요하게 본다. 네트워크·보안 기업은 신뢰 경로와 정책 집행을 본다. 엔터프라이즈 소프트웨어 기업은 오래된 시스템과의 연동, 감사, 변경 관리에 민감하다.
여러 이해관계자가 참여하면 의사결정은 느려질 수 있다. 그러나 표준에서는 그 느림이 장점이 되기도 한다. 빠른 독자 기능보다 중요한 것은 여러 구현체가 같은 의미로 동작하는 것이다. A2A가 엔터프라이즈 표준으로 남으려면 새로운 기능을 많이 넣는 것보다, 서로 다른 구현이 같은 Task와 Artifact를 같은 뜻으로 해석하게 만드는 일이 더 중요하다.
Apache License 2.0과 공개 기여의 효과
A2A 프로토콜은 Apache License 2.0으로 공개되어 있다.1 이 라이선스는 기업 채택에 유리하다. 기업은 프로토콜과 SDK를 제품, 내부 플랫폼, 상용 서비스에 비교적 자유롭게 사용할 수 있다. 또한 특허 관련 조항이 포함되어 있어 오픈소스 기반 기술을 상용 환경에 넣을 때 법무 검토의 부담을 줄이는 데 도움이 된다.
공개 라이선스는 커뮤니티 확장에도 중요하다. 특정 회사의 허락을 기다리지 않고 SDK를 개선하고, 예제 구현을 만들고, 테스트 도구를 보완할 수 있다. 작은 스타트업이나 내부 플랫폼 팀도 표준을 실험할 수 있다. 이것이 누적되면 표준은 문서가 아니라 구현 생태계가 된다.
다만 오픈소스라는 사실만으로 기업 준비가 끝나지는 않는다. 기업은 여전히 다음 질문을 해야 한다.
우리 조직에서 어떤 A2A 버전을 표준으로 삼을 것인가
Agent Card 변경은 누가 승인할 것인가
외부 에이전트와 연결할 때 보안 검토 절차는 무엇인가
SDK 업데이트가 기존 Task 흐름을 깨뜨리지 않는지 어떻게 검증할 것인가
내부 확장을 만들 경우 표준 확장과 충돌하지 않게 어떻게 관리할 것인가
공개 기여 절차는 이런 질문을 공개된 논의로 끌어낸다. 표준의 품질은 완벽한 첫 설계보다, 문제가 발견되었을 때 누구나 재현하고 수정하고 합의할 수 있는 절차에서 나온다.
제도권 표준화로 넘어가는 흐름
A2A의 Linux Foundation 이동은 오픈소스 거버넌스의 이야기다. 그러나 AI 에이전트 표준화는 거기서 끝나지 않는다. NIST의 AI Agent Standards Initiative는 에이전트가 사용자를 대신해 안전하게 행동하고, 디지털 환경 전반에서 상호운용되도록 산업 주도 표준과 공개 프로토콜을 촉진하겠다는 목표를 제시한다.3
중요한 점은 NIST가 A2A 하나를 지정했다는 뜻이 아니라는 점이다. 흐름은 더 넓다. 에이전트 보안, 신원, 인증, 권한 부여, 상호운용성은 더 이상 개별 벤더 문서 안에서만 다룰 수 없는 주제가 되었다. 특히 금융, 의료, 공공, 제조처럼 규제가 강한 산업에서는 다음과 같은 요구가 커진다.
이 에이전트가 실제로 누구의 권한으로 행동했는가
어떤 Agent Card를 근거로 상대 에이전트를 신뢰했는가
어떤 범위의 데이터와 작업만 허용되었는가
사람이 승인해야 할 지점을 건너뛰지 않았는가
사고가 났을 때 Task, Message, Artifact, 로그를 연결해 재구성할 수 있는가
A2A는 이런 질문에 답할 수 있는 공통 구조를 제공한다. 하지만 모든 답을 자동으로 제공하지는 않는다. 신원 인프라, 조직의 권한 정책, 감사 로그 보존, 위험 평가, 사고 대응은 여전히 각 기업과 산업의 책임이다. 앞으로의 표준화는 프로토콜 필드만이 아니라 운영 통제와 보안 보증까지 함께 다루는 방향으로 넓어질 가능성이 높다.
경쟁보다 계층화가 중요해진다
초기 에이전트 프로토콜 논의에서는 A2A, MCP, ACP가 경쟁 구도처럼 보이기도 했다. 이름은 비슷하고 모두 에이전트 상호운용성을 말했기 때문이다. 그러나 실무 관점에서는 점점 계층이 나뉘고 있다.
MCP는 에이전트가 도구, API, 데이터 소스에 접근하는 계층이다. A2A 공식 문서도 MCP와 A2A를 경쟁 관계가 아니라 보완 관계로 설명한다. MCP는 에이전트-도구 통신을, A2A는 에이전트-에이전트 통신을 맡는다.1 ACP 계열 논의는 구현 생태계에 따라 의미가 조금씩 다르지만, 대체로 프레임워크 간 연결이나 클라이언트-에이전트 상호작용을 다루는 층으로 정리되고 있다.4
따라서 앞으로 중요한 질문은 무엇이 하나로 통일되느냐가 아니다. 서로 다른 계층이 어떻게 함께 동작하느냐다.
예를 들어 구매 에이전트가 A2A로 공급망 에이전트에 재고 확인 Task를 위임한다고 하자. 공급망 에이전트는 내부에서 MCP를 통해 ERP API와 창고 데이터베이스를 조회할 수 있다. 사용자는 별도의 클라이언트 인터페이스나 업무 포털에서 이 흐름을 시작할 수 있다. 이때 표준화해야 할 것은 단일 프로토콜이 아니라 경계다. 어떤 정보는 A2A Message로 전달되고, 어떤 정보는 MCP 도구 호출 안에 머물며, 어떤 결과가 Artifact로 승격되는지 명확해야 한다.
남는 과제: 권한, 신원, 호환성
A2A가 개방형 표준으로 자리 잡아도 어려운 문제는 남는다. 첫째는 세밀한 권한 관리다. 어떤 에이전트가 어떤 에이전트에게 어떤 스킬을 요청할 수 있는지, 어떤 고객 데이터 범위에서만 작업할 수 있는지, 어떤 작업은 사람 승인 없이는 진행할 수 없는지 표현해야 한다. 단순히 호출 가능 또는 불가능으로는 부족하다.
둘째는 신원 증명이다. Agent Card는 발견의 출발점이지만, 그것이 진짜 신뢰할 수 있는 발행자에게서 왔는지 검증해야 한다. 앞으로는 서명된 Agent Card, 워크로드 신원, mTLS, OAuth 기반 권한 위임, 조직 간 신뢰 정책이 더 중요해질 것이다. 신원은 로그인 화면의 문제가 아니라 에이전트가 실제 행동을 수행할 수 있는 권한의 근거다.
셋째는 교차 프로토콜 호환성이다. A2A의 Task와 Artifact, MCP의 리소스와 도구 결과, ACP 계열의 메시지 모델이 서로 어떻게 매핑되는지 정리해야 한다. 오류 코드, 추적 ID, 사용자 동의, 취소 처리, 재시도 정책이 프로토콜마다 다르면 운영자는 전체 흐름을 추적하기 어렵다.
이 과제들은 A2A만의 문제가 아니다. 에이전트 생태계 전체가 풀어야 할 표준화의 다음 단계다. A2A는 그중 에이전트 간 협업이라는 한 축을 맡고 있다.
오래가는 표준을 고르는 기준
기업이 A2A를 도입할 때는 기능 목록만 보지 말아야 한다. 다음 기준을 함께 봐야 한다.
표준이 특정 벤더의 제품 전략에 과도하게 종속되어 있지 않은가
공개된 거버넌스와 유지관리자가 있는가
여러 클라우드와 엔터프라이즈 소프트웨어 기업이 실제 구현에 참여하는가
라이선스가 상용 사용과 내부 확장에 적합한가
호환성 테스트, 버전 관리, 보안 권고가 운영 절차로 이어지는가
MCP, ACP, 기존 API 표준과 함께 설계할 수 있는가
A2A의 강점은 모든 문제를 해결한다는 데 있지 않다. 오히려 자신이 맡은 범위를 비교적 분명히 한다는 데 있다. 에이전트가 도구를 쓰는 방식은 MCP나 내부 프레임워크에 맡기고, 에이전트가 다른 에이전트와 업무를 위임하고 상태와 결과를 교환하는 부분에 집중한다.
이 경계가 유지될 때 A2A는 더 오래간다. 표준은 넓어질수록 강해지는 것이 아니라, 필요한 만큼만 공통화하고 나머지는 생태계가 확장할 수 있게 둘 때 강해진다.
A2A의 미래는 합의의 품질에 달려 있다
A2A는 Google이 만든 기술에서 출발했지만, 이제는 여러 기업과 커뮤니티가 함께 다루는 개방형 표준의 길에 들어섰다. Linux Foundation 거버넌스, Apache License 2.0, 공개 기여, 주요 벤더의 참여, NIST를 비롯한 제도권 표준화 논의는 모두 같은 방향을 가리킨다. 에이전트가 기업 업무의 일부가 되려면, 서로 말할 수 있을 뿐 아니라 서로를 신뢰할 수 있어야 한다.
앞으로 A2A의 성패는 명세가 얼마나 화려한지보다 합의가 얼마나 잘 유지되는지에 달려 있다. 새로운 기능을 추가하는 속도, 보안 문제를 다루는 투명성, 구현체 간 호환성, 권한과 신원에 대한 현실적인 기준, 다른 프로토콜과의 연결 방식이 그 합의의 품질을 결정한다.
이 책에서 살펴본 A2A는 에이전트를 더 똑똑하게 만드는 기술이 아니다. 에이전트가 각자의 책임과 경계를 유지한 채 함께 일하도록 만드는 공통 언어다. 그리고 공통 언어가 오래 살아남으려면, 문법만큼이나 그 언어를 함께 관리하는 공동체가 중요하다.
참고
3AI Agent Standards Initiative | NIST
4Agent-to-Agent Communication Protocol Standards: A2A, MCP, ACP, and ANP
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.