에이전트 도구와 상호운용성

에이전트 도구와 상호운용성

원문: Agent Tools & Interoperability
저자: Kanchana Patlolla, Łukasz Olejniczak, Pier Paolo Ippolito
발행: 2026년 5월
번역 및 편집: 한국어 학습·연구용 번역 검수본

번역 주: 이 글은 원문 PDF의 목차와 절 순서를 기준으로 다시 옮긴 검수본이다. MCP, A2A, A2UI, AP2, UCP, API, JSON, SDK, 코드 식별자처럼 기술 표준명과 코드 문맥에서 의미가 고정된 표현은 원문 표기를 유지했다.

감사의 말

콘텐츠 기여자: Alan Blount, Mike Smith, Anant Nawalgaria, Lukas Geiger
큐레이터 및 편집자: Anant Nawalgaria
디자이너: Michael Lanning

목차

1. 서론
2. 왜 이 글인가, 왜 지금인가
3. 이 글의 독자
4. 바이브 코더가 보는 MCP: 발견, 설정, 연결
5. MCP 서버 디버깅
6. 바이브 코더 툴킷: MCP 소비 모범 사례
7. 에이전트 간(A2A) 상호운용성
8. 에이전트형 아키텍처의 진화
9. 제한된 문제 공간과 비제한 문제 공간
10. 에이전트형 아키텍처의 GOTO 문제
11. 가상 노동력 구축
12. 에이전트 카드
13. 등록소: 공개 마켓플레이스에서 사설 엔터프라이즈까지
14. A2A 프로토콜 구현
15. A2A 에이전트 공개
16. 원격 A2A 에이전트 연결
17. 확장 계층: UI와 상거래의 기반으로서 A2A
18. A2A 에이전트 수익화
19. 에이전트-UI(A2UI) 상호운용성
20. A2UI 생성: 두 가지 패턴
21. 상호작용형 산출물과 캔버스
22. 모범 사례
23. 에이전트와 상거래(AP2와 UCP)
24. 결론
25. 주석

서론

소프트웨어의 다음 진화는 직접 작성되는 것이 아니다. 상호운용 가능한 에이전트들에 의해 조율된다.

Day 1에서는 전통적인 소프트웨어 개발에서 에이전트 중심 엔지니어링(Agentic Engineering)으로 이동하는 패러다임 전환을 설명했다. 그 과정에서 공장 모델(Factory Model)을 소개했다. 이 모델에서 개발자의 주된 산출물은 더 이상 원시 구문 자체가 아니라, 코드를 생산하는 시스템이다. 이 시스템의 핵심 아키텍처는 다음과 같이 이해할 수 있다.

에이전트 중심 엔지니어링이 여러분이 조율하는 공장 바닥이라면, MCP, A2A, A2UI, AP2, UCP는 그 공장을 외부 세계와 안전하게 상호작용하게 만드는 산업 표준이다. 균일한 너트와 볼트, 나사 규격, 데이터 형식, 통신 채널이 있어야 기계들이 함께 작동할 수 있는 것과 같다.

이런 개방형 프로토콜이 없으면 여러분이 만드는 모든 에이전트는 차고 안에 홀로 놓인 고립된 맞춤형 기계가 된다. 그러면 개발자는 각각의 도구와 API 연결마다 취약한 전용 래퍼를 작성하느라 시간과 토큰을 쓰게 되고, 높은 레버리지의 오케스트레이터가 아니라 낮은 레버리지의 지휘자 역할에 갇힌다.

표준화된 상호운용성 계층을 도입하면 에이전트의 하네스는 모듈식 플러그 앤 플레이 플랫폼으로 바뀐다. 맞춤형 JSON 페이로드를 디버깅하는 시간은 줄고, 오케스트레이터로서 고수준 의도를 지시하는 시간은 늘어난다.

• OpenResponses와 Interactions API는 모두 장시간 실행 작업을 지원하는 현대적 LLM 추론 API 방식이다. 전원 플러그처럼 작동하며, 상태 없는 단일 턴과 상태 있는 에이전트 사이의 경계를 흐린다.
• MCP(Model Context Protocol)는 에이전트 하네스 내부의 USB-C처럼 모델을 데이터베이스, 파일 시스템, 웹 API에 즉시 연결한다.
• Skills는 플레이북이다. 터미널 같은 샌드박스 환경에서 사용할 수 있는 매우 단순한 마크다운 지침, 스크립트, 도구로 구성된다.
• A2A(Agent-to-Agent)는 공장 무전기처럼 전문 에이전트들이 서로 협상하고, 브레인스토밍하고, 작업을 위임할 수 있게 한다.
• A2UI(Agent-to-User Interface)는 생성형 디스플레이 창처럼 원시적이고 복잡한 JSON 출력을 사람이 다룰 수 있는 안전한 상호작용형 시각 컴포넌트로 바꾼다.
• AP2와 UCP는 글로벌 공급망과 거래 네트워크처럼 에이전트가 자율적 상거래를 안전하게 협상하고 실행할 수 있게 한다.

이 글은 바이브 코더가 이러한 프로토콜 일부를 빠르게 활용해, 단 하루 오후 안에 가상의 데이터·실행 팀을 구성하는 방법에 초점을 맞춘다.

그림 1: 에이전트 프로토콜 생태계

왜 이 글인가, 왜 지금인가

구조가 상대적으로 약한 바이브 코딩 시대에는 하네스와 프로토콜이 에이전트 개발 과정의 신뢰를 세우는 데 도움을 준다. 실무자와 개발자에게 여전히 가장 중요한 동인은 결과를 빠르게 내는 속도다. 그러나 표준화된 프로토콜은 고립된 맞춤형 기계를 모듈식 상호운용 플랫폼으로 바꾸어 더 복잡한 목표까지 도달할 수 있게 한다.

합의된 개방형 표준이 없다면 개발자는 기술 부채를 만든다. 각 API는 자기 자신만을 위한 표준이 되고, 개발자는 모든 도구마다 취약한 전용 래퍼를 작성하고, 시간이 지나며 이를 유지하고, 다른 요구에 맞게 고쳐야 한다. 이런 일은 레버리지가 낮다. 반대로 이러한 계층을 채택하면 단순한 빌더에서 고수준 오케스트레이터로 이동할 수 있다.

이 글의 독자

이 글은 에이전트 중심 엔지니어링으로의 이동이 결과의 충실도와 신뢰성을 유지하기 위해 프로토콜 준수를 요구한다는 점을 이해하는 소프트웨어 엔지니어, 엔지니어링 관리자, 아키텍트, 기술 리더를 위해 설계되었다. 또한 속도와 시각적 결과를 중시하는 바이브 코더가 가상의 데이터·실행 팀을 어떻게 구성할 수 있는지를 보여주는 실용 가이드이기도 하다.

적용 팁

Day 1 백서에서는 코딩 에이전트에게 표준 지침을 제공하기 위해 AGENTS.MD 파일을 사용할 것을 권했다.

코드를 작성하기 전에는 항상 깊이 생각하라. 가정을 명시하고, 트레이드오프를 드러내며, 모호성을 만나는 순간 조용히 추측하지 말고 멈춰서 명확화를 요청하라.

당장의 문제를 해결하는 데 필요한 최소한의 코드만 작성하라. 추측성 기능, 요청받지 않은 추상화, 예측적 설정은 엄격히 피하라.

기존 코드를 편집할 때는 요청을 충족하는 데 필요한 정확한 줄만 바꾸는 수술적 변경을 하라. 기존 스타일을 완벽히 유지하고, 변경으로 인해 import나 변수가 고아가 되는 경우가 아니라면 주변의 정상 코드는 그대로 두라.

마지막으로 모든 작업은 목표 중심 실행으로 접근하라. 명확한 단계별 계획과 강한 성공 기준으로 분해하고, 먼저 재현 테스트나 실패 테스트를 작성한 뒤, 해당 목표가 엄격히 충족될 때까지 독립적으로 검증 루프를 돌려라.

바이브 코더가 보는 MCP: 발견, 설정, 연결

이전 백서인 「Model Context Protocol(MCP)을 활용한 에이전트 도구와 상호운용성」에서는 MCP의 엔터프라이즈 아키텍처를 설명했다. 그 글은 호스트-클라이언트-서버 토폴로지, 맞춤형 서버 생성, 보안 거버넌스를 자세히 다루었다.

그러나 바이브 코더에게 우선순위는 생성보다 소비다. 몇 시간 동안 맞춤형 서버 설정을 작성하고 싶지 않다. 이미 존재하는 공개·사설 등록소에 연결해 에이전트에게 즉시 플러그 앤 플레이 능력을 부여하고 싶다. 이 절은 MCP 서버를 효율적으로 소비하는 방법, NxM 통합 위기를 우회하는 방법, 문제가 생겼을 때 전송 계층을 디버깅하는 방법을 다룬다.

참고: Agent Skills는 다음 백서에서, 보안은 그 다음 백서에서 더 깊이 다룬다.

전통적인 엔터프라이즈 방식으로 도구를 LLM에 연결하려면 전용 직접 연결이 필요하다. 새 연결마다 맞춤형 REST 래퍼, API 키, 토큰 갱신 정책, 맞춤형 JSON 파서가 필요하다. MCP는 이 마찰을 표준화된 소켓으로 대체한다. 코딩 에이전트를 설정하는 일은 세 단계로 단순화된다.

그림 2: MCP 서버 온보딩 단계

발견

바이브 코더는 맞춤형 커넥터를 직접 작성하지 않는다. 대신 세 가지 주요 출처에서 미리 만들어진 MCP 서버를 찾는다.

• 공개 MCP 등록소: registry.modelcontextprotocol.io, github.com/mcp 같은 공개 등록소에는 수백 개의 사전 구축 서버가 올라와 있다. 빠른 로컬 프로토타이핑에는 훌륭하지만, 검증되지 않았으므로 사용자는 그 위험을 감수해야 한다.
• 제3자 원격 MCP 서버: 검증된 플랫폼이 호스팅된 엔드포인트를 노출한다. 공식 출처에서 관리되고 사전 검증된 MCP 서버를 찾을 수 있다. 예를 들어 Google이 공식적으로 공개한 Google Maps, BigQuery, Google Docs MCP 서버는 에이전트가 관리형 서비스와 안전하게 상호작용하게 한다.
• 내부 등록소: 조직 내부에서는 사내 도구를 MCP 서버로 노출하고 보안 등록소에 카탈로그화한다. 이런 등록소의 기술 구현은 일반적으로 API 게이트웨이, GCP Agent Registry, 사설 마이크로서비스 포털을 통해 관리된다.

적용 팁

결정할 때는 항상 보안을 최우선으로 고려하라. 가능하면 공식 지침을 찾아라. 공개 커뮤니티 서버를 사용할 때는 자격 증명을 넘기지 말고, 보안 문제를 피하기 위해 Model Armor 같은 서비스를 고려하라.

설정

연결하기 전에는 서버의 범위와 권한을 설명하는 표준 매개변수를 지정해야 한다. 여기에는 Personal Access Token이나 OAuth secret 같은 API 자격 증명을 처리하기 위한 환경 파일 설정, 그리고 파일 시스템을 보호하기 위한 읽기/쓰기 권한 정의가 포함된다.

적용 팁

• 사전 조건을 확인하라.
• 범위와 접근 기준을 식별하라.
• 해당 명세를 코딩 에이전트에 포함하라.
• 인증 방식을 확인하라.

연결

설정이 끝나면 클라이언트가 서버와 연결을 수립한다. 연결을 검증하기 위해 호스트 클라이언트는 기본 핸드셰이크 요청을 실행해 사용 가능한 도구 목록을 나열하고 출력 스키마를 검증한다.

NxM 프로토타이핑 문제 우회

MCP가 빠른 프로토타이핑에 왜 중요한지 이해하려면 통합 계산을 보면 된다. N개의 서로 다른 LLM, 예를 들어 Gemini 3.1 Pro, Gemini 3 Flash, Gemini 3.5 Flash 또는 로컬 오픈소스 모델을 실험하면서, 이를 Jira, BigQuery, GitHub, Google Drive 같은 M개의 외부 도구에 연결하려 한다고 하자. 전통적인 임시 개발 방식에서는 모든 모델-도구 조합마다 맞춤형 통합 코드를 작성해야 한다.

모델이 5개이고 도구가 10개라면 50개의 전용 통합 지점을 유지해야 한다. 프로토콜이 없는 상태에서 단 하나의 도구 API만 바뀌어도 여러 파서 루프가 깨진다.

코드 조각 1: MCP 복잡도

MCP는 이 복잡도를 선형 규모로 줄인다.

왜 중요한가

도구 정의를 표준화하면 통합 코드를 작성하지 않고도 표준 전송 방식을 에이전트 하네스에 직접 연결할 수 있다.

• stdio(Standard Input/Output): 로컬 개발과 프로토타이핑에서 가장 자주 사용된다. 복잡한 네트워크 연결 설정 없이 코딩 에이전트가 도구를 로컬 프로세스처럼 다룰 수 있다. 호스트 클라이언트는 MCP 서버를 로컬 백그라운드 하위 프로세스로 실행하고, JSON-RPC 2.0 메시지를 stdin/stdout으로 주고받는다.
• HTTP 위의 SSE(Server-Sent Events): 호스트 클라이언트는 로컬 또는 배포된 에이전트형 애플리케이션일 수 있으며, 표준 웹 프로토콜을 통해 원격 MCP 엔드포인트에 연결하고 데이터를 에이전트로 실시간 스트리밍한다. 이 방식은 stdio 방식보다 의존성이 적고, 항상 최신 상태를 유지하기 쉽고, 설치 공간이 작으며, 수명주기가 단순하다는 장점이 있다. 다만 클라우드 호스팅 MCP 서버에는 더 큰 부담을 준다.

두 선택지는 모두 바이브 코더가 여러 맞춤형 통합 계층 없이 플랫폼을 채택할 수 있게 한다.

MCP 서버 디버깅

에이전트가 매개변수를 환각하거나, 잘못된 도구를 호출하거나, 페이로드 파싱에 실패할 때 시스템 지시문을 무작정 고치느라 시간을 낭비하지 말라. 전송 파이프를 직접 디버깅하라.

• MCP Inspector: 로컬 웹 패널을 실행하는 네이티브 개발자 도구다. 로컬 또는 원격 MCP 서버를 수동으로 질의하고, 활성 도구 스키마를 보고, 페이로드 입력을 직접 테스트하며, 기본 에이전트 작업 흐름을 시작하지 않고도 원시 JSON-RPC 2.0 패킷을 검사할 수 있다.
• Chrome DevTools: 웹 기반 개발 환경을 실행하거나 SSE 연결을 디버깅할 때 적합하다. 들어오는 웹 스트림을 추적하고 서버 지연 시간을 확인할 수 있다.

바이브 코더 툴킷: MCP 소비 모범 사례

속도를 유지하면서 안정성을 희생하지 않으려면, 바이브 코더는 MCP 서버를 소비할 때 다음 지침을 따라야 한다.

해야 할 일

• 연결 전 공개 서버를 감사하라: 로컬 파일 시스템이나 자격 증명에 접근할 수 있는 에이전트에 공개 오픈소스 MCP 서버를 붙이기 전에는 항상 코드를 검토하라.
• 도구에도 RAG를 사용하라: 에이전트의 컨텍스트 창을 깨끗하게 유지하라. 도구는 필요할 때만 등록소에서 동적으로 불러오고, 작업이 끝나면 컨텍스트에서 제거해 주의 분산을 막아라.
• 내부 API 게이트웨이와 등록소를 활용하라: 가능하다면 내부 도구 등록소에 의존하라. 이렇게 하면 바퀴를 다시 만들거나 검증되지 않은 코드를 실행하는 대신, 승인되고 관리되는 데이터 스키마를 소비하게 된다.
• MCP Inspector를 사용하라: 에이전트가 도구 호출이나 인수를 환각하면 시스템 프롬프트를 무작정 바꾸지 말고 MCP Inspector나 Chrome DevTools로 원시 전송 데이터를 확인하라.
• HITL을 포함하라: 악의적이거나 우발적인 데이터 유출을 피하기 위해 서버를 호출하기 전에 도구 입력을 사용자에게 보여주라.
• 감사 요구를 반영하라: 감사 목적을 위해 도구 사용 기록을 남겨라.

하지 말아야 할 일

• 소비할 수 있으면 만들지 말라: 맞춤형 REST API 래퍼를 쓰고 싶은 충동을 억제하라. 범용 콘센트 철학을 유지하려면 먼저 기존 MCP 서버를 찾아라.
• 공개 검증되지 않은 MCP를 운영 환경에서 쓰지 말라: 오픈소스 MCP 서버는 주말 프로토타입에는 훌륭하지만 보안과 신뢰성 위험이 있다. 핵심 비즈니스 로직을 검증되지 않은 공개 엔드포인트나 API 래퍼 코드에 묶지 말라.
• 자격 증명을 하드코딩하지 말라: 설정 단계에서 API 키나 인증 토큰을 에이전트 프롬프트나 로컬 스크립트에 직접 붙여 넣지 말라. 환경 변수를 사용해 MCP 서버에 자격 증명을 전달하라.
• 운영 환경에 연결하지 말라: MCP 서버는 운영 프로젝트가 아니라 개발 프로젝트와 함께 사용하라. LLM은 애플리케이션을 설계하고 테스트하는 데 유용하므로, 실제 데이터를 노출하지 않는 안전한 환경에서 활용하라. 개발 환경에는 비운영 데이터 또는 난독화된 데이터가 있어야 한다.
• 업데이트 작업에 사용하지 말라: 실제 데이터에 연결해야 한다면 서버를 읽기 전용 모드로 설정해 모든 질의가 읽기 전용으로 실행되게 하라.
• 모든 프로젝트에 넓은 접근 권한을 주지 말라: MCP 서버 범위를 특정 프로젝트로 제한하고, 필요한 경우에만 해당 프로젝트의 리소스에 접근하게 하라.

이제 바이브 코더가 MCP 도구를 활용해 AI 에이전트를 만드는 방법을 살펴보았다. 하지만 AI 에이전트 구축은 도구에 그치지 않는다. 사용자가 애플리케이션 생태계 전반에 상호운용성을 가져오게 하는 것이 중요하다. 다음 절에서는 에이전트 상호운용성이 어떻게 작동하는지 살펴본다.

에이전트 간(A2A) 상호운용성

AI 시스템이 전문화된 도메인 전문가들의 분산 네트워크로 전환되면서, 표준화된 통신은 확장을 위한 필수 조건이 된다. 이 절은 Agent-to-Agent(A2A) 프로토콜을 생태계 파편화를 해결하는 기반 계층으로 살펴본다. A2A는 개발자가 전 세계적으로 상호운용 가능한 가상 노동력을 발견하고, 조율하고, 수익화할 수 있게 한다.

에이전트형 아키텍처의 진화

바이브 코딩이 에이전트형 아키텍처의 진화 안에서 어디에 위치하는지 이해하려면 기술에서 반복되는 패턴을 볼 수 있다. 사용자는 무엇을 원하는지 말하고, 어떻게 만들지는 말하지 않는다. 그때 시스템은 수동 저수준 설정에서 고수준 의도 기반 선언형 오케스트레이션으로 이동한다.

IT 인프라 역사에서도 병렬적인 흐름이 있었다. 수동 설정에서 Infrastructure as Code라는 선언형 스크립트로 이동했다. 머신러닝 역사에서도 비슷한 흐름이 있었다. Google이 AutoML 뒤에 둔 비전은 모델 생성의 지루한 작업을 자동화하여 AI를 민주화하는 것이었다.

AI를 더 쉽게 접근할 수 있게 만들기 위해, 우리는 신경망이라고 부르는 머신러닝 모델 생성을 단순화하려 한다. 오늘날 신경망을 설계하는 일은 시간이 매우 많이 든다. 그래서 우리는 AutoML이라는 접근법을 만들었고, 신경망이 신경망을 설계할 수 있음을 보였다. 우리는 AutoML이 오늘날 소수의 박사급 인력만 가진 능력을 더 넓게 확장하기를 바란다.

오늘날 기술은 전체 애플리케이션을 바이브 코딩으로 만들 수 있게 한다. 그러나 이런 애플리케이션을 바이브 코딩하는 데 쓰이는 에이전트형 아키텍처의 궤적은 소프트웨어 역사에서 가장 중요한 전환 중 하나를 닮고 있다. 바로 모놀리스에서 마이크로서비스 아키텍처로의 전환이다.

초기 웹 애플리케이션이 결제, UI, 데이터베이스 등 모든 기능이 강하게 결합된 거대한 단일 코드베이스로 만들어졌듯, 초기 바이브 코딩 프로젝트도 스위스 군용 칼 같은 단일 에이전트 모놀리스에 의존하는 경우가 많았다. 하나의 에이전트가 많은 도구와 연결된 고도로 정교한 프롬프트 하나로 데이터베이스 질의, UI 렌더링, 테스트까지 모두 처리하는 방식이다.

이 방식은 개발자가 주말 동안 프로토타입을 엮어내는 데는 유용하지만, 초기 웹 앱이 겪었던 것과 같은 모놀리스 한계에 결국 부딪힌다.

• 확장 마찰: 같은 프롬프트 안에 있는 UI 로직을 혼란스럽게 만들지 않고 데이터베이스 로직만 최적화하기 어렵다. 또한 단일 에이전트가 접근할 수 있는 도구가 많아질수록 의사결정은 나빠진다. 다음 행동을 고르는 탐색 공간이 너무 커져 환각성 매개변수를 만들거나 잘못된 도구를 발동하게 된다.
• 컨텍스트 과부하: 전체 시스템 지시문, 수십 개의 복잡한 도구 스키마, 진행 중인 대화 이력을 하나의 프롬프트에 밀어 넣으면 모델의 작업 기억은 빠르게 한계에 도달한다.
• 단일 장애점: 하나의 도구나 지시문의 버그가 전체 에이전트를 환각시키거나 중단시킬 수 있다. 컨텍스트에 저장된 무관하거나 손상된 데이터가 이후 추론으로 이어져 문제를 만든다.

이 병목을 극복하려면 수년 전 머신러닝 엔지니어와 소프트웨어 엔지니어가 따랐던 것과 비슷한 청사진을 따를 수 있다. 초기 AutoML 모델이 비즈니스 가치를 입증한 뒤에도, 팀들은 대개 자동 생성된 블랙박스를 핵심 비즈니스에 그대로 두지 않았다. 운영 규모에 도달하려면 그 블랙박스를 데이터 버전 관리, 피처 스토어, 드리프트 감지처럼 관찰 가능하고 유지보수 가능한 단계로 나누어야 했다. 컴포넌트를 전문화함으로써 시스템 설계의 기본 법칙을 적용한 것이다. 전문화는 확장의 메커니즘이다.

그림 3: 모놀리식 다중 에이전트 아키텍처

내부 전문화는 모놀리식 에이전트를 논리적으로 구분된 목적별 하위 에이전트로 나누는 방식이다. 각 에이전트는 매우 집중된 시스템 프롬프트와 관련 도구 부분집합으로 관리된다. 그러나 이 내부 하위 에이전트들이 네트워크 경계를 넘어 통신하지는 않으므로 여전히 모놀리스다. 같은 런타임과 기반 메모리를 공유한다.

이 논리적 분할은 복잡한 정의를 모듈화하면서도 단일 프로세스 애플리케이션의 낮은 지연 시간 실행과 단순한 상태 관리를 유지하게 한다. 동시에 단일 에이전트 시스템의 본질적 한계를 몇 가지 기술적 개선으로 완화한다.

• 탐색 공간 감소: 하위 에이전트의 도구와 스킬을 제한하면, 예를 들어 DB 에이전트에게 질의 도구만 주면, 도구 호출 오류와 환각을 크게 줄일 수 있다.
• 주의 분산 완화: 전문화는 기반 LLM이 하나의 도메인 프롬프트에 집중하도록 하여 더 날카로운 추론을 가능하게 한다.
• 컨텍스트 부하 최적화: 오케스트레이터가 전체 논리 트리를 직접 처리하는 대신 작업을 라우팅하므로, 하위 에이전트는 컨텍스트 창에서 높은 신호 대 잡음비를 유지한다.

에이전트형 아키텍처가 성숙하면서 분산 다중 에이전트 아키텍처에 기반한 중요한 생태계 전환이 진행 중이다. Google, Salesforce, ServiceNow, Workday 같은 업계 선도 기업들은 API 제공을 넘어가고 있다. 이 조직들은 각자의 독자 생태계를 네이티브 수준의 정밀도로 탐색하도록 설계된 도메인 특화 AI 에이전트를 배포하고 있다.

그림 4: 분산 다중 에이전트 아키텍처. 오케스트레이터는 네트워크 경계를 넘어 원격 도메인 특화 에이전트에게 작업을 위임한다.

이 변화는 개발자에게 전략적 기회를 제공한다. 그러나 다음 확장 단계에 도달하려면 기술 리더와 비즈니스 리더는 현대적인 만들 것인가 살 것인가(Build vs. Buy)의 렌즈로 초점을 냉정하게 우선순위화해야 한다.

ServiceNow나 Salesforce 같은 제3자 플랫폼을 위해 맞춤형 하위 에이전트를 직접 만들어 다중 에이전트 시스템을 구성하는 것은 기술적으로 가능하다. 그러나 이 접근은 상당한 유지보수 비용을 낳는다. 도메인 전문가를 전용 개발하기로 선택하면, 개발자는 상위 제품 업데이트와 API 스키마 변경을 반영하는 프롬프트 로직과 도구 정의를 계속 갱신할 책임을 떠안는다.

고가치 애플리케이션을 만들기 위한 더 나은 아키텍처 전략은 공식 전문가 에이전트를 활용하는 것이다. 이 에이전트들은 깊은 도메인 전문성을 가진 팀이 유지관리하므로 신뢰성과 성능을 극대화한다. 전문 도메인 로직의 유지보수를 이런 공식 주체에 맡기면, 오케스트레이터와 개발자는 애플리케이션의 고유한 사용자 가치와 핵심 혁신에 완전히 집중할 수 있다.

하지만 이렇게 분산된 AI 전문가들의 가상 팀을 조율하려 하면 새로운 병목이 등장한다. 바로 파편화다. 각각의 전문가 에이전트는 서로 다른 팀이 서로 다른 기술로 만들 수 있다. Google의 에이전트는 ADK를 사용해 Python, Go, Java로 작성되었을 수 있고, Salesforce의 에이전트는 LangChain 프레임워크에서 실행될 수 있으며, Workday의 에이전트는 완전히 전용 방식일 수도 있다. 이들은 네트워크 경계 밖에 존재하고, 서로 다른 언어를 말하며, 전혀 다른 페이로드 구조를 기대하고, 대화 상태를 서로 다르게 처리하며, 다양한 전송 계층에 의존한다.

개발자가 고용하려는 모든 전문가마다 맞춤형 통합 코드와 전용 오류 수정 루프를 작성해야 한다면, 가상 팀이라는 개념은 즉시 통합 작업으로 변한다. 이런 맞춤형 다리들이 무너지지 않게 유지하는 비용이 프로젝트 전체를 잡아먹게 된다.

이 파편화의 혼란을 표준화하기 위해 설계된 것이 Agent-to-Agent(A2A) 프로토콜이다. A2A는 원래 Google이 개발했고 지금은 Linux Foundation에 기증되었으며, 에이전트형 시스템을 위한 보편적 통신 계층을 도입한다. 이는 AI 생태계의 공용어처럼 작동해 네트워크 전송의 세부 차이, 기반 프레임워크, 프로그래밍 언어, 페이로드 차이를 추상화한다.

A2A는 중앙 오케스트레이터가 생태계 안의 어떤 전문가 에이전트든 발견하고, 온보딩하고, 협업할 수 있게 한다. 그 전문가가 내부적으로 어떻게 만들어졌는지에는 완전히 독립적이다. HTTP가 웹을 표준화했듯, A2A는 가상 노동력을 표준화한다.

제한된 문제 공간과 비제한 문제 공간

“호출자에게 필요한 것은 결과인가, 아니면 책임을 맡을 또 다른 참여자인가?” 이 질문은 이 결정을 가장 깔끔하게 설명한다. 중앙 에이전트 프롬프트가 우연히 작업 흐름 엔진으로 비대해지는 냄새는, 대부분의 팀이 협업 의미론이 필요했다는 사실을 석 달 늦게 깨닫는 방식이다.

그러나 여기서 다음 아키텍처 질문이 생긴다. 외부 전문가에게 위임하는 것뿐이라면, 왜 이들을 표준 도구처럼 취급하면 안 되는가?

전문가와 도구의 관계는 본질적으로 다르다. 집주인이 주방을 리모델링한다고 상상해 보자. 집주인은 개별 도구와 설명서를 사서 직접 시도할 수도 있고, 주방을 직업적으로 만드는 도메인 전문가에게 프로젝트를 위임할 수도 있다.

도구는 수동적 기구일 뿐이다. 전문가는 협업 파트너다. 전문가를 고용할 때는 청사진 하나를 건네고 완벽한 주방이 마법처럼 완성되길 기대하며 떠나는 것이 아니다. 전문가는 엣지 케이스나 원래 설계의 누락을 만나면 멈추고, 트레이드오프를 상의한 뒤 다시 작업을 진행한다.

이것이 전문가 AI 에이전트를 단순 도구로 취급하는 방식이 확장되지 않는 이유 중 하나다. 표준 도구나 API는 요청 후 결과만 받는 방식으로 동작한다. 단일하고 완벽하게 형식화된 요청, 즉 청사진 페이로드를 기대하고 응답을 반환한다. 현실의 소프트웨어 환경에는 삐뚤어진 벽의 디지털 등가물, 곧 모호한 데이터 구조, 오해를 부르는 요구사항, 상충하는 사용자 선호가 자주 존재한다.

반면 에이전트는 비제한 문제 해결 공간에서 동작한다. 복잡한 작업 흐름에서는 여러 차례의 명확화 없이 필요한 모든 세부 사항을 지정하기 어렵다.

에이전트형 아키텍처의 GOTO 문제

에이전트의 도메인이 비제한적이기 때문에, 에이전트를 표준 도구 래퍼 안에 강제로 넣으려 하면 오케스트레이터 안에 GOTO 문을 넣는 것과 같은 아키텍처 문제가 생긴다. 협업 에이전트를 호출하면 제어 흐름은 예상된 구조화 컨텍스트를 벗어난다. 에이전트는 중단 상태에 도달해 추가 정보를 요청할 수도 있고, 사용자가 마음을 바꾸거나 프롬프트를 포기하면 원래 호출자에게 기대한 출력이 돌아오지 않을 수도 있다.

이 복잡한 다중 턴 상태를 격리하는 패러다임이 필요하다. 도메인 에이전트가 실행을 멈추고, 오케스트레이터에게 다시 연락해 해법을 협상하고, 대화 상태를 잃지 않은 채 작업을 재개할 수 있게 하는 프로토콜이 필요하다.

A2A 프로토콜은 바로 이 공백을 채운다. 협업 라우팅을 A2A 계층에 격리함으로써 도구 계층인 MCP를 깔끔하고 예측 가능하며 엄격히 구조화된 상태로 유지한다.

가상 노동력 구축

A2A 프로토콜의 도입과 전문화로의 이동은 기술적 병목을 해결하는 데 그치지 않는다. 이는 전문성을 위한 새로운 마켓플레이스의 기반을 만들며, 가치 전달 방식의 새로운 모델을 나타낸다.

A2A가 없다면 개발자는 애플리케이션을 만들고 점점 커지는 복잡성을 유지하느라 어려움을 겪을 수 있다. A2A 시대에는 같은 개발자가 실시간 규제 준수 같은 고가치 틈새 영역을 완성하는 데 집중할 수 있다. 정교한 다중 에이전트 모놀리스로 만들었든 분산 앱으로 만들었든, 이런 시스템은 이제 A2A 호환 에이전트로 세상에 노출될 수 있다. 즉 세계 한쪽에서 바이브 코딩으로 만든 전문가가 지구 반대편의 다른 오케스트레이터에게 발견되고 고용될 수 있다.

에이전트 카드

이 발견을 가능하게 하기 위해 모든 에이전트는 에이전트 카드(Agent Card)로 정의된다. 에이전트 카드는 AI 세계의 표준화된 이력서이며, 다음을 설명하는 기계 판독 가능 정체성을 제공한다.

• 역량: 에이전트가 어떤 작업을 수행할 수 있는가.
• 보안과 규정 준수: 데이터 처리 정책과 권한 요구사항은 무엇인가.
• 상호작용 스키마: 다른 에이전트가 A2A 프로토콜을 통해 어떻게 통신해야 하는가.

등록소: 공개 마켓플레이스에서 사설 엔터프라이즈까지

에이전트 카드가 준비된 에이전트는 에이전트 등록소에 등록될 수 있다. 등록소의 목적은 에이전트를 검색 가능한 서비스로 바꾸는 것이다. 개발자에게는 두 가지 주요 경로가 열린다.

1. 공개 등록소(마켓플레이스): 글로벌 인재 중개소처럼 공개 등록소는 개발자가 전문가 에이전트를 전 세계에 공개하게 한다. 이는 특정 산업을 위한 전문가 에이전트를 만들고 그 전문성을 수천 개의 다른 오케스트레이터에 라이선스하는 길을 연다.
2. 사설 등록소: 엔터프라이즈 내부에서 에이전트 등록소는 안전하고 관리되는 환경을 제공한다. 대기업 내부 개발자는 내부 작업 흐름을 자동화하는 전문가 에이전트를 만들고 다른 부서가 사용할 수 있도록 등록할 수 있다. 이를 통해 보안을 훼손하지 않고 전문성을 회사 경계 너머로 공유할 수 있다.

궁극적으로 A2A 프로토콜은 고립된 에이전트형 애플리케이션을 만드는 행위를, 전 세계적으로 상호운용되는 디지털 노동력의 기반 구성원을 만드는 행위로 바꾼다.

A2A 프로토콜 구현

A2A 아키텍처의 실제 구현은 두 가지 뚜렷한 개발 흐름을 가능하게 한다.

• AI 에이전트를 A2A 에이전트로 공개하기: 공급 측
• 원격 A2A 에이전트를 조율하기: 수요 측

A2A 에이전트 공개

A2A 생태계를 위해 에이전트를 패키징하려면 세 가지 핵심 단계가 필요하다.

• 에이전트 카드 정의: 공식 에이전트 명세를 작성한다.
• 에이전트 실행기 구현(번역 계층): 들어오는 A2A 요청과 응답을 ADK, LangGraph, 전용 엔터프라이즈 코드 같은 기반 에이전트형 프레임워크가 요구하는 특정 호출로 번역한다.
• A2A 엔드포인트 구축: 실행기는 A2A 호환 엔드포인트로 노출되어야 한다.

그림 5: 네이티브 AI 에이전트를 공급 측 A2A 서버로 공개하고, 수요 측에서 A2A 클라이언트를 통해 소비하는 구조

원격 A2A 에이전트 연결

성숙한 생태계에서 애플리케이션은 접촉하는 모든 도메인에 대한 깊은 지식을 네이티브하게 갖고 있지 않다. 대신 오케스트레이터로 작동한다. 오케스트레이터는 사용자 의도를 이해하고, 전체 작업 흐름을 관리하며, 특정 작업을 전문화된 원격 A2A 에이전트에게 위임하는 중앙 허브다.

원격 A2A 에이전트는 A2A 프로토콜로 통신하는 자율적이고 도메인에 묶인 계약자처럼 동작한다. 이런 원격 에이전트 연결은 일반적으로 두 가지 아키텍처 패턴을 따른다. 첫째는 하드코딩된 엔드포인트를 통한 직접 점대점 통합이다.

# 1. 하드코딩된 엔드포인트를 통한 직접 인스턴스화
# 특정 공급사 통합이나 사설 에이전트에 적합하다.
billing_specialist = RemoteA2aAgent(
    name="billing_agent",
    endpoint="https://api.vendor.com/v1/billing/a2a"
)

코드 조각 2: 하드코딩된 엔드포인트를 통한 직접 원격 A2A 에이전트 인스턴스화

둘째는 에이전트 등록소를 사용해 에이전트를 발견하는 방식이다.

# 2. 에이전트 등록소를 통한 간접 인스턴스화
registry = AgentRegistry(project_id=project_id, location=location)

# 등록소는 리소스 이름을 해석하고 인증 검증을 처리한다.
agent_name = f"projects/{project_id}/locations/{location}/agents/YOUR_AGENT_ID"
my_remote_agent = registry.get_remote_a2a_agent(agent_name=agent_name)

코드 조각 3: 에이전트 등록소를 통한 간접 원격 A2A 에이전트 발견과 인스턴스화

확장 계층: UI와 상거래의 기반으로서 A2A

초기 AI 생태계에 내재한 파편화를 해결함으로써 A2A 프로토콜은 통합 통신 계층을 세운다. 이 통신 계층은 개발자가 그 표준화된 토대 위에 더 풍부한 애플리케이션을 만들 수 있게 한다. 핵심 A2A 프로토콜이 전송과 협상의 골격으로 작동하더라도, 풍부한 거래형 애플리케이션을 실현하려면 매우 특화된 역량이 필요한 경우가 많다.

이 요구는 A2A 확장이라는 메커니즘으로 해결된다. A2A 확장은 기본 메시지 전달을 넘어서는 선택적 고급 기능을 에이전트가 안전하게 알리고, 협상하고, 실행할 수 있는 표준화된 패턴을 제공한다.

핵심 A2A 기반 위에서 네이티브 확장으로 작동하는 세 가지 기반 프레임워크가 있다. 동적이고 상태를 가진 사용자 경험을 생성하도록 설계된 Agent-to-User Interface(A2UI), 안전한 자율 에이전트형 상거래를 촉진하도록 설계된 Universal Commerce Protocol(UCP), 신뢰할 수 있고 검증 가능한 에이전트형 결제의 기반을 놓는 Agent Payments Protocol(AP2)이다. 세 가지 모두 뒤의 절에서 더 자세히 다룬다.

A2A 에이전트 수익화

에이전트를 작동하게 만드는 것은 절반의 싸움일 뿐이다. 나머지 절반은 장기적 상업 지속가능성을 확보하는 것이다. Software-as-a-Service(SaaS) 패러다임의 성공을 이어, A2A 프로토콜은 자연스럽게 Agent-as-a-Service(AaaS) 모델을 가능하게 한다. 전문화된 에이전트는 다양한 판매 채널을 통해 사용량 기반 모델로 제공될 수 있다.

한 가지 예는 Google Cloud Marketplace를 수익화 엔진으로 활용하는 것이다. 독립 에이전트/소프트웨어 공급사와 개발자는 A2A 에이전트를 마켓플레이스에 등록해 기존 Google Cloud 엔터프라이즈 고객 기반을 즉시 활용할 수 있다. 고객은 이런 전문가를 조달하면서 동시에 기존 GCP 재정 약정을 사용할 수 있다. 모두에게 이득이다.

마켓플레이스 인프라는 복잡한 청구라는 어려운 부분을 자동 처리한다. 예를 들어 정액 요금과 사용량 요금을 결합한 모델 같은 혼합 가격 책정을 네이티브로 지원한다. 이를 통해 공급사는 예측 가능한 기본 요금을 부과하면서, 컴퓨트나 토큰 기반 초과 사용량도 수익화할 수 있다.

그림 6: 서비스형 에이전트(AaaS) 수명 주기

Google Cloud Marketplace에 등록된 에이전트는 Gemini Enterprise 앱 사용자가 직접 접근할 수 있다. Gemini Enterprise는 모든 직원의 모든 작업 흐름에 Google AI의 장점을 제공하는 고급 에이전트형 플랫폼이다. 팀은 하나의 안전한 환경 안에서 AI 에이전트를 발견하고, 만들고, 공유하고, 실행할 수 있다. Gemini Enterprise는 에이전트 등록소와 통합되고 네이티브 A2A 클라이언트로 동작함으로써 직원들이 넓은 전문가 노동력 생태계에 접근하게 하여 사람의 경험을 증강한다. 동시에 Gemini Enterprise는 Assistant API를 통한 서비스형 에이전트 플랫폼이며, 원격 에이전트를 위한 호스트이기도 하다.

클라우드 마켓플레이스와 전통적인 결제 게이트웨이가 서비스형 에이전트 청구 대부분을 처리하겠지만, A2A 프로토콜은 사용자 계정 관리를 완전히 피하고 싶은 개발자를 위해 허가 없는 기계 간 소액 거래도 지원한다.

A2A 확장 프레임워크를 활용하면 에이전트 서버는 x402 또는 L402 표준을 구현할 수 있다. 이 패턴에서 서버는 요청을 가로채고, 결제되지 않은 상태라면 HTTP 402 Payment Required 상태 코드와 기계가 읽을 수 있는 청구서를 함께 반환한다. 호출 에이전트는 결제를 자율적으로 실행하고 암호학적 결제 증명 토큰과 함께 요청을 재시도한다. 이는 엄격히 상태 없는 자동 청구가 필요한 호출당 과금 엔드포인트를 위한 표준화된 선택지를 제공한다.

에이전트-UI(A2UI) 상호운용성

소통의 간극

동료에게 “지역별로 Q4 실적이 어땠나요?”라고 물으면 동료는 스프레드시트를 건네지 않는다. 화이트보드에 막대그래프를 그리고, 두드러진 지역에 표시를 하며, 맥락을 덧붙인다. 사람이 통찰을 공유하는 방식은 시각 자료와 상호작용이다.

하지만 에이전트는 원시 JSON을 반환한다. 그러면 사용자가 직접 차트를 만들어야 한다. 라이브러리를 가져오고, 축을 설정하고, 상태를 관리해야 한다. 통찰을 요청하는 일과 프런트엔드 작업 사이의 이런 컨텍스트 전환은 바이브 코딩 흐름을 깨뜨린다.

Agent-to-UI(A2UI) 상호운용성은 에이전트가 단순한 JSON 덩어리가 아니라 완성된 상호작용형 사용자 인터페이스를 출력으로 생성하게 함으로써 이 문제를 해결한다.

생성형 UI와 A2UI

생성형 UI는 LLM이 사용자 의도와 컨텍스트에 따라 실행 시점에 사용자 인터페이스를 동적으로 생성하는 개념이다. 개발자가 가능한 모든 UI 상태를 하드코딩하는 대신, 모델이 필요에 맞는 인터페이스를 생성한다. 사용자가 “지역별 Q4 매출을 비교해줘”라고 요청하면, 시스템은 데이터를 가져오는 데 그치지 않고 그 특정 요청에 맞춘 상호작용형 레이아웃, 카드, 필터, 컨트롤을 조합한다.

이는 정적이고 미리 만들어진 인터페이스에서 동적이고 컨텍스트를 인식하는 UI로의 전환을 의미한다. 과제는 이를 안전하게 수행하는 것이다. LLM이 생성한 임의 UI 코드를 실행하면 코드 삽입, XSS 공격, 통제되지 않는 부작용 같은 보안 위험이 생길 수 있다.

A2UI: 안전한 구현

A2UI는 UI 의도를 선언하기 위한 프레임워크 독립 표준이다. 원시 데이터를 스트리밍하거나 임의 코드를 보내는 대신, 에이전트가 인터페이스를 이식 가능한 선언형 형식으로 설명하게 하는 Google의 오픈소스 방식이다.

왜 여기서 형식이 중요한지 이해하려면 작곡가가 자신의 작업을 전달하는 방식을 생각해 보라. 작곡가는 연주자에게 녹음 파일을 주지 않는다. 악보를 준다. 같은 악보는 피아노, 오케스트라, 신시사이저에서 연주될 수 있으며, 각 악기는 자신의 목소리로 기보를 해석한다.

A2UI는 UI를 위한 악보다. 에이전트는 의도, 즉 무엇을 렌더링할지와 어떻게 조합할지를 쓰고, React, Angular, Lit, Flutter, Jetpack Compose, SwiftUI 같은 렌더러가 사용자가 실제로 가진 기기에서 이를 네이티브로 수행한다. 에이전트는 웹, 모바일, 웨어러블, 가전 중 무엇을 대상으로 하는지 알 필요가 없다. 사용 가능한 컴포넌트 카탈로그와 제공하고 싶은 예시만 알면 된다.

이 관심사 분리가 A2UI를 안전하게 만든다. 에이전트는 실행 코드를 생성하지 않고, 미리 렌더링된 픽셀도 보내지 않는다. 실행 코드는 보안 악몽이고, 픽셀은 다시 흐르거나 상호작용성을 유지할 수 없다. 대신 에이전트는 버튼, 텍스트 필드, 카드, 자체 차트 같은 신뢰된 카탈로그의 컴포넌트를 요청하고, 클라이언트는 자체 컴포넌트 라이브러리로 이를 렌더링한다. 카탈로그는 무엇이 사용 가능한지 정의하고, 에이전트는 이를 어떻게 배열할지 결정하며, 클라이언트는 최종 구조를 조립한다. LEGO 블록처럼 조합적이지만, 그 블록은 디자인 시스템의 UI 컴포넌트다.

기본 카탈로그와 자체 카탈로그 가져오기

A2UI는 프로토타입과 시연을 위해 즉시 사용할 수 있는 18개의 기본 컴포넌트 카탈로그를 제공한다.

범주	컴포넌트
레이아웃	Row, Column, List
표시	Text, Image, Icon, Divider
컨테이너	Card, Modal, Tabs
미디어	Video, AudioPlayer
상호작용	Button, TextField, CheckBox, Slider, DateTimeInput, ChoicePicker

표 1: A2UI 기본 카탈로그

이 집합은 v0.8에서는 standard라고 불렸고, v0.9에서는 basic으로 이름이 바뀌었다. 이는 운영 프런트엔드가 기존 컴포넌트, 예를 들어 디자인 시스템 버튼, 차트, 지도 등을 A2UI 타입에 매핑하는 자체 카탈로그를 가져와야 한다는 의도적 신호다. 에이전트는 바뀌지 않는다. 바뀌는 것은 렌더러의 카탈로그 매핑뿐이다. ChoicePicker는 v0.8에서 MultipleChoice였다.

다음은 A2UI 메시지가 어떻게 보이는지 보여주는 v0.9 형식의 예다.

{
  "version": "v0.9",
  "updateComponents": {
    "surfaceId": "main",
    "components": [
      {"id": "root", "component": "Column", "children": ["title", "summary", "export"]},
      {"id": "title", "component": "Text", "text": "Q4 Sales", "variant": "h1"},
      {"id": "summary", "component": "Text", "text": "Revenue grew 12% QoQ"},
      {"id": "export", "component": "Button", "child": "export-label", "action": {"event": {"name": "export_csv"}}},
      {"id": "export-label", "component": "Text", "text": "Export CSV"}
    ]
  }
}

코드 조각 4: A2UI 메시지 예시

컴포넌트는 id로 참조되는 평평한 인접 목록을 형성한다. 이 구조는 LLM이 점진적으로 생성하기 쉽고, 클라이언트가 다시 렌더링하지 않고 갱신하기 쉽다. 별도의 createSurface 메시지는 어떤 id가 루트인지 클라이언트에게 알려준다. 그러면 클라이언트는 이를 완성된 상호작용형 인터페이스로 렌더링한다. React 코드는 필요 없다.

A2UI 생성: 두 가지 패턴

실무에서 A2UI를 만드는 방법은 두 가지다. 선택 기준은 주로 레이아웃 결정을 누가 소유하는가다.

기본 방식은 LLM이 A2UI를 직접 생성하게 하는 것이다. 모델이 레이아웃을 소유하고, 사용자 의도에 적응하며, 같은 에이전트가 “이 지역들을 비교해줘”와 “추세를 보여줘”를 서로 다른 인터페이스로 처리한다. 이 패턴의 운영 코드는 공식 a2ui-agent-sdk를 사용한다.

전문화 방식은 도구가 고정된 A2UI 구조를 반환하게 하는 것이다. 한 번의 도구 호출로 처리되고, UI 생성에 LLM 토큰을 쓰지 않으며, 출력은 완전히 예측 가능하다. 입력에 따라 레이아웃이 결정적인 경우에 적합하다. 모든 지역의 영업 대시보드가 같은 형태를 갖거나 모든 예약 양식이 같은 필드를 갖는 경우다. 사실상 도구가 서버 측 템플릿으로 작동한다.

깔끔한 도구-템플릿 도구는 본문에서 두 가지 일을 한다. 첫째, f-string 보간이 아니라 경로 참조를 가진 데이터 바인딩으로 A2UI 구조를 만든다. 둘째, 이를 반환한다. 프레임워크의 A2uiPartConverter는 도구 응답을 가로채 클라이언트에 A2UI part로 라우팅하므로, 도구 자체는 단순한 Python 함수로 유지된다.

from google.adk.agents import LlmAgent
from google.adk.models import Gemini

def get_sales_dashboard(region: str) -> dict:
    """Build a data-bound sales dashboard for `region`."""
    data = fetch_sales(region)
    return {
        "version": "v0.9",
        "updateComponents": {
            "surfaceId": "sales",
            "components": [
                {"id": "root", "component": "Column", "children": ["title", "total", "drill"]},
                {"id": "title", "component": "Text", "text": {"path": "/title"}, "variant": "h1"},
                {"id": "total", "component": "Text", "text": {"path": "/total"}},
                {"id": "drill", "component": "Button", "child": "drill-label",
                 "action": {"event": {"name": "expand_details"}}},
                {"id": "drill-label", "component": "Text", "text": "Drill Down"},
            ],
        },
    }

agent = LlmAgent(
    name="sales_agent",
    model=Gemini(model="gemini-flash-latest"),
    tools=[get_sales_dashboard],
)

코드 조각 5: LLM이 UI를 생성하는 패턴

데이터 값은 병렬 updateDataModel 메시지를 통해 흐르며 {path: "/title"} 참조를 해석한다. 따라서 클라이언트는 구조를 다시 보내지 않고도 데이터 갱신에 따라 다시 렌더링할 수 있다. LLM은 렌더링된 UI가 아니라 구조화된 도구 응답만 보므로, 컨텍스트는 방금 만든 UI가 아니라 다음에 무엇을 할지에 집중된다.

언제 어떤 패턴을 사용할 것인가

질의	반환
“평균이 얼마야?”	데이터(텍스트)
“이 지역들을 비교해줘”	LLM이 생성한 UI
“내 대시보드를 보여줘”	도구가 만든 UI
API 간 통신	데이터(JSON)

표 2: 질의와 출력의 매핑

상호작용이나 시각화가 원시 데이터 이상의 가치를 더할 때 A2UI를 사용하라. 그리고 레이아웃 결정을 누가 소유하는지에 따라 패턴을 고르라. 의도 주도형이면 LLM, 입력 주도형이면 결정적 템플릿이다.

상호작용형 산출물과 캔버스

전통적인 채팅 인터페이스는 선형적이다. 각 응답은 정적이다. 캔버스 방식은 다르다. 캔버스는 에이전트와 사용자가 모두 편집할 수 있는 지속적인 작업 공간을 만든다.

채팅 이력을 스크롤하는 대신 살아 있는 문서를 갖게 된다. 에이전트는 섹션을 수정할 수 있고, 사용자는 수동으로 편집할 수 있다. 양쪽의 변화는 실시간으로 반영된다.

캔버스 + A2UI

캔버스의 지속성과 A2UI의 상호작용성을 결합하면 유용한 작업 흐름이 만들어진다.

그림 7: 사용자, 에이전트, 캔버스의 상호작용 흐름

UI는 단순히 렌더링되는 것이 아니다. UI는 소통 매체다. 에이전트는 사용자의 상호작용을 관찰하고 그에 맞게 응답한다.

모범 사례

LLM이 A2UI를 생성하게 하라

LLM이 UI를 생성하는 기본 패턴에서는 A2UI JSON을 손으로 작성하는 일이 지루하다. 공식 a2ui-agent-sdk를 사용하라. A2uiSchemaManager는 카탈로그 스키마와 작동 예시가 이미 포함된 시스템 프롬프트를 만들고, 카탈로그는 자체 JSON 스키마 검증기를 제공하며, 같은 SDK는 에이전트가 생성하는 <a2ui-json> 블록을 파싱하는 파서를 제공한다. 그런 다음 스키마 오류가 있으면 검증하고 재시도하라.

코드 조각 6: A2uiSchemaManager 구현

운영 환경에서는 create_ui()를 try/except로 감싸고, 스키마 검증 실패 시 텍스트 응답으로 대체하라. LLM 출력은 확률적이며, 렌더러는 잘못 형식화된 페이로드를 절대 받아서는 안 된다.

유연성을 위한 혼합 출력

소비자가 선택할 수 있도록 데이터와 UI를 모두 제공하라.

{
  "data": {"sales": [...]},
  "ui": {"version": "v0.9", "updateComponents": {"surfaceId": "main", "components": [...]}},
  "ui_available": true
}

코드 조각 7: 혼합 출력 예시 스키마

API 클라이언트는 ui 필드를 무시하고 데이터를 사용한다. 사용자 대상 클라이언트는 A2UI 메시지를 렌더링한다.

요약

생성형 UI는 LLM이 사용자 의도에 따라 실행 시점에 사용자 인터페이스를 만들게 한다. A2UI는 이를 안전하게 수행하기 위한 Google의 오픈소스 표준이다. 프레임워크에 독립적인 UI 의도 선언 형식이므로, 같은 에이전트 메시지가 Lit, Flutter, React 또는 자체 디자인 시스템에서 네이티브하게 렌더링될 수 있다.

보안 모델이 중요하다. 에이전트는 임의 코드를 주입할 수 없다. 렌더러의 카탈로그가 이미 신뢰하는 컴포넌트만 요청할 수 있다. 이것이 A2UI를 안전하게 만들면서도 동적이고 생성적인 인터페이스를 가능하게 하는 이유다.

에이전트와 상거래(AP2와 UCP)

작업 흐름 예시로 보는 자율 조달

바이브 코더는 에이전트와 함께 결제, 카탈로그, 주문 기능, 승인 규칙을 배운다.

프로토콜의 핵심 특성과 이점

형식화된 스키마, 보안, 오픈소스, 통합 부채 감소, 공급사 중립성이 핵심 특성과 이점이다.

실습 추천: ADK Agent Commerce codelab

앞선 절들은 코딩 에이전트가 에이전트형 프레임워크 안에서 도구, 다른 에이전트, 사용자 인터페이스와 어떻게 상호작용하는지에 초점을 맞추었다. 그러나 이런 상호작용은 MCP, A2A, A2UI 같은 프로토콜을 사용하는 읽기 작업에 제한되는 경우가 많다. 시스템이 발전하면 에이전트는 현실 세계의 재정적 영향을 갖는 행동을 실행하는 방향으로 이동해야 한다.

상거래 프로토콜을 우선시하고 견고한 운영 하네스를 구축하면, 에이전트가 거래를 관리할 때 업계 표준을 엄격히 따르게 할 수 있다.

이 시스템을 구현하는 방법을 이해하려면 먼저 프로토콜의 성격과 상호 보완적 역할을 살펴보아야 한다.

AP2와 UCP란 무엇인가

그림 8: AP2와 UCP 생태계

새벽 2시에 룸메이트들과 배가 고픈 상황을 상상해 보자. 공부 때문에 멈출 수 없어서 AI 스마트 어시스턴트에게 아파트로 음식을 가져오라고 맡긴다. UCP(Universal Commerce Protocol)와 AP2(Agent Payments Protocol)는 그 부리토가 기숙사 로비에 도착하도록 일을 나누어 처리한다.

UCP: 궁극의 음식 배달 앱

2024년 방식이라면 AI는 Chrome을 수동으로 열고, 동네 부리토 가게의 형편없이 설계된 웹사이트에 들어가, 과카몰리 추가 체크박스를 클릭하려고 시도하고, 사이트가 멈추지 않기를 바라야 했다.

반면 UCP는 범용 번역기처럼 작동한다. 캠퍼스의 모든 음식점은 메뉴, 영업시간, 맞춤 옵션을 깨끗한 표준 기계 언어로 공개한다.

AI는 UCP를 사용해 음식점 시스템에 “아직 영업 중인가요? 채식 부리토가 있나요?”라고 묻는다. 주문을 만들려면 “치킨 부리토 하나, 양파 제외, 사워크림 추가, 칩 사이드”라고 요청할 수 있고, 음식점은 세금, 배달비, 예상 도착 시간을 응답한다.

요약하면 UCP는 AI가 상점과 대화하고, 선택지를 살펴보고, 원하는 주문을 구성하는 방법이다. UCP 이전에도 애플리케이션은 정보를 발견하고 가져올 수 있었다. 그러나 서로 다른 제공자 사이의 상호작용은 개별적으로 조율해야 했다. 상호작용을 표준화하면 사람이 아닌 주체들끼리도 더 쉽게 상호작용할 수 있다.

AP2: 엄격한 규칙이 있는 부모의 신용카드

이제 음식이 장바구니에 담겼지만 AI가 결제해야 한다. 사용자는 실제 체크카드 번호를 AI 프롬프트에 입력하고 “마음대로 써”라고 말하고 싶지 않다.

AP2는 에이전트와 판매자 사이의 안전하고 규정을 준수하는 거래를 위한 공통 언어를 제공하는 개방형 공유 프로토콜이다. 사용자가 설정한 규칙 안에서만 AI가 음식값을 지불하게 한다.

• 안전장치, 곧 승인 규칙(Mandate): AI를 보내기 전에 사용자는 “Taco Bell에서 최대 25달러까지 쓸 수 있다”는 디지털 규칙을 승인한다.
• 핸드셰이크: AI가 결제할 때 카드 번호를 보여주지 않는다. 대신 “내 사용자가 이 18.50달러 주문을 승인했다”라고 말하는, 사용자가 서명한 디지털 암호화 약속 증서를 보여준다. 음식점의 은행은 이 전자서명을 즉시 검증한다.
• 숨은 수수료 없음: 음식점이 18.50달러가 아니라 50달러를 몰래 청구하려 하면, AP2 프로토콜은 사용자가 서명한 규칙을 위반했기 때문에 즉시 차단한다.

요약하면 AP2는 AI가 사용자의 돈으로 물건을 결제할 수 있게 하되, 실수로 1,000달러짜리 TV를 사지 못하게 막는 안전한 잠금 상자다.

UCP	AP2
무엇을 살지 결정하고, 메뉴를 처리하며, 음식을 장바구니에 넣는 두뇌	사기를 당하지 않도록 결제 방식을 안전하게 처리하는 지갑
모든 사업 제공자와 통합	결제와 통합
통합된 연동	승인과 감사 가능성
공유 언어	의도의 진정성
확장 가능한 아키텍처	에이전트 오류와 환각 대응
보안 우선 접근	책임 추적성

표 3: UCP와 AP2 비교

• 판매자나 결제 처리사를 위한 UCP 에이전트를 만드는 개발자는 관련 지침을 따라야 한다.
• 판매자나 결제 처리사를 위한 AP2 에이전트를 만드는 개발자는 관련 지침을 따라야 한다.
• 구매자처럼 AP2 에이전트를 소비하는 에이전트를 만드는 개발자는 관련 지침을 따라야 한다.

결론

MCP, A2A, A2UI, AP2, UCP 같은 기반 표준을 채택하면 조직은 전용 통합이 낳는 무거운 기술 부채를 제거하고, 고부가가치 비즈니스 로직을 조율하는 일에 온전히 집중할 수 있다. 이 패러다임 전환은 개발자를 취약한 API를 연결하는 단순 정비공에서, 전 세계 자율 노동력의 진정한 설계자로 근본적으로 끌어올린다. 이러한 표준화된 통신 계층이 성숙하면 완전히 새로운 규모의 경제가 열리고, 기업용 소프트웨어가 만들어지고, 소비되고, 수익화되는 방식이 바뀔 것이다.

주석

1. A2A Community (2026), A2A Documentation: Extensions, A2A Protocol. https://a2a-protocol.org/latest/topics/extensions/
2. Antigravity Team (2026), Antigravity Editor: MCP Integration, Antigravity Docs. https://antigravity.google/docs/mcp
3. Fowler M, Lewis J (2014), Microservices, MartinFowler. https://martinfowler.com/articles/microservices.html
4. Google A2A Team (2025), Announcing the Agent2Agent Protocol (A2A), Google Developers Blog. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
5. Google A2UI Team (2025), Introducing A2UI: An Open Project for Agent-Driven Interfaces, Google Developers Blog. https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/
6. Google A2UI Team (2026), A2UI v0.9: The New Standard for Portable, Framework-Agnostic Generative UI, Google Developers Blog. https://developers.googleblog.com/a2ui-v0-9-generative-ui/
7. Google A2UI Team (2026), A2UI, GitHub. https://github.com/google/A2UI
8. Google Cloud Databases Team (2025), MCP Toolbox for Databases, Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/mcp-toolbox-for-databases-now-supports-model-context-protocol
9. Google Cloud Team (2026), Announcing Agents-to-Payments (AP2) Protocol, Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol?e=48754805
10. Google Cloud Team (2026), Configure MCP in an AI Application, Cloud Docs. https://docs.cloud.google.com/mcp/configure-mcp-ai-application#antigravity
11. Google Stitch Team (2026), Google Stitch Documentation: MCP Setup, Stitch with Google Docs. https://stitch.withgoogle.com/docs/mcp/setup
12. MCP Team (2026), Specification for Model Context Protocol, MCP Docs. https://modelcontextprotocol.io/specification/2025-11-25
13. Muchandi V (2026), Rad-skills: Gemini Skills for Rapid Agent Development, GitHub. https://github.com/VeerMuchandi/rad-skills
14. Hotz H. (2026), The Agentic Commerce Revolution, O’Reilly Radar. https://www.oreilly.com/radar/the-agentic-commerce-revolution/
15. Pichai S. (2017), Making AI Work for Everyone, Google Blog. https://blog.google/innovation-and-ai/products/making-ai-work-for-everyone/
16. Saboo S, Overholt K (2026), Developer’s Guide to AI Agent Protocols, Google Developers Blog. https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/
17. Styer M, Patlolla K, Mohan M, Diaz S (2025), Agent Tools & Interoperability with Model Context Protocol (MCP), Kaggle. https://www.kaggle.com/whitepaper-agent-tools-and-interoperability-with-mcp
18. The Linux Foundation (2026), A2A Protocol Surpasses 150 Organizations, Linux Foundation Press. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
19. Common AI Catalog and Registry Standard Documentation (2026). https://github.com/Agent-Card/ai-catalog
20. Ricardo Cataldi (2026), MCP vs A2A: Tools, Agents, and Where Each Protocol Belongs. https://levelup.gitconnected.com/mcp-vs-a2a-tools-agents-and-where-each-protocol-belongs-53e1f9ab9765
21. Lukas Geiger (2026), Monetizing AI Agents: Ensuring Profitability. https://medium.com/google-cloud/monetizing-ai-agents-ensuring-profitability-92efa535ebb3