구글이 AI 에이전트가 웹·모바일 클라이언트에 구조화된 UI를 전달할 수 있게 하는 A2UI v0.9를 공개했다. 핵심은 "또 하나의 UI 프레임워크"가 아니라, 에이전트와 프런트엔드 사이에 공통 계약을 두겠다는 점이다.12
지금 이게 중요한 이유는 간단하다. 이미 많은 팀이 챗봇만으로는 부족하고, 그렇다고 모든 보조 화면을 사람이 직접 설계·개발하기엔 너무 느리다는 문제를 겪고 있다. A2UI는 그 틈을 노린다. 다만 질문은 "A2UI가 뭔가?"보다 "UI를 코드가 아니라 에이전트가 조립할 때, 무엇이 더 쉬워지고 무엇이 더 위험해지는가?"에 가깝다.
A2UI가 잘 맞는 곳: 채팅만으론 답답하고, 고정 화면으론 비효율적인 인터페이스
확인된 사실부터 보자. 구글은 A2UI를 프레임워크 비종속 표준으로 설명하며, 기존 디자인 시스템의 컴포넌트 카탈로그를 재사용하도록 설계했다고 밝혔다. React, Flutter, Angular, Lit용 렌더러가 있고, 웹 코어 라이브러리와 에이전트 SDK도 추가됐다.2
이 말이 실무에서 뜻하는 바는 분명하다. A2UI는 "앱 전체를 AI가 그린다"보다, 문맥에 따라 달라지는 좁은 화면에 더 잘 맞는다. 예를 들면 다단계 업무 플로우, 권한과 데이터 상태에 따라 바뀌는 폼, 운영용 대시보드, 상담 중 즉석에서 뜨는 위젯 같은 것들이다. 일반 채팅은 표현력이 부족하고, 반대로 완전한 하드코딩은 변경 비용이 크다.
반대로 브랜딩이 아주 중요하거나, 픽셀 단위 일관성이 핵심인 메인 사용자 여정은 아직 A2UI의 주전장이 아니다. 생성 속도보다 예측 가능성이 더 중요하기 때문이다.
진짜 트레이드오프: UI 생성 속도는 빨라지지만, 제품 통제권은 프로토콜 안으로 들어간다
A2UI의 가장 큰 변화는 렌더링 기술이 아니라 책임 배분이다. 레이아웃, 입력 검증, 상호작용 규칙, 상태 동기화 같은 제품 결정 일부를 코드베이스가 아니라 "에이전트가 따르는 스키마와 카탈로그"로 옮긴다.2
구글이 v0.9에서 클라이언트 정의 함수, 검증용 함수, 클라이언트-서버 데이터 동기화, 버전 협상, 동적 카탈로그를 강조한 이유도 여기 있다.2 데모 단계에서는 "AI가 UI를 만든다"가 매력적이지만, 운영 단계에서는 "누가 이 UI의 규칙을 소유하나?"가 더 중요해진다.
실무적으로는 세 가지를 먼저 정해야 한다.
첫째, 에이전트가 고를 수 있는 컴포넌트의 범위다. 카탈로그가 넓을수록 유연하지만, 예기치 않은 조합과 디자인 붕괴 가능성도 커진다.
둘째, 실패 방식이다. 잘못된 텍스트 응답은 무시하고 넘어갈 수 있지만, 잘못된 UI는 사용자를 오작동으로 이끈다. 그래서 검증과 복구 로직이 제품 기능 그 자체가 된다.
셋째, 디버깅 책임이다. 이제 문제는 "프런트 코드 버그"만이 아니다. 프롬프트, 스키마, 스트리밍 파서, 렌더러, 상태 동기화 중 어디서 깨졌는지 봐야 한다.
A2UI vs MCP Apps vs AG-UI: 기능표보다 "프로덕션에서 무엇이 깨지나"로 고르기
이 영역은 이름이 비슷해 더 헷갈린다. 하지만 층위를 나누면 정리가 된다.
AG-UI는 에이전트와 UI 사이의 실시간 상호작용 프로토콜에 가깝다. 이벤트 스트리밍, 상태 전달, 툴 실행 흐름 같은 런타임 연결을 다룬다.34 A2UI는 그 위에서 에이전트가 어떤 UI를 선언할지에 대한 명세다.4 둘은 경쟁보다 보완 관계다.
MCP Apps는 더 개방적이고 웹 중심적인 방향으로 읽힌다. 반면 A2UI는 구글과 관련 생태계 문서들에서 네이티브·크로스플랫폼 렌더링을 더 전면에 둔다.5 그래서 선택 기준은 "무엇을 더 지원하나"보다 "어떤 실패를 감당할 수 있나"다.
플랫폼 이식성과 기존 앱 통합이 중요하면 A2UI가 설득력이 있다. 반대로 특정 플랫폼 안에서 더 자유로운 웹 UI를 만들고 배포 유통까지 노린다면 MCP Apps류가 나을 수 있다. 이미 AG-UI 기반 에이전트 스택이 있다면, A2UI를 그 위에 올려 선언형 UI만 추가하는 접근도 현실적이다.24
도입은 작게 해야 한다: 앱 전체가 아니라 '에이전트 소유 화면' 하나만
A2UI를 검토하는 팀이 가장 피해야 할 실수는 거대한 리빌드다. 구글이 SDK, 스트리밍 복구, 버전 협상 같은 생산성 요소를 내놨다고 해도, 아직은 빠르게 진화하는 초기 표준에 가깝다.2 외부에서도 A2UI를 "툴"보다 "프로토콜"로 보는 해석이 많지만, 업계 합의가 끝난 상태는 아니다.6
그래서 가장 안전한 테스트는 하나의 좁은 표면을 고르는 것이다. 예를 들어 "고객 지원 중 환불 폼 생성", "영업 담당자용 즉석 비교 카드", "운영팀용 필터형 대시보드" 같은 화면이다. 여기에 디자인 가드레일, 허용 컴포넌트, 검증 규칙, 실패 시 폴백 UI를 먼저 정의해야 한다.
판단 기준도 데모 완성도가 아니라 다음이어야 한다. 사람이 만든 화면보다 더 빨리 적합한 UI를 내놓는가. 예외 상황에서 안전하게 망가지는가. 운영 로그만으로 원인을 찾을 수 있는가. 이 셋 중 둘도 만족하지 못하면, 아직은 채팅 보조나 제한된 AG-UI 패턴이 더 현실적이다.
A2UI는 결국 "AI가 UI를 만든다"는 화려한 이야기보다, 제품 결정의 일부를 프로토콜로 외부화하는 변화다. 그래서 지금 가장 신경 써야 할 사람은 프런트엔드 엔지니어만이 아니라 PM, 디자인 시스템 오너, 플랫폼 팀이다. 이 기술을 볼 때는 생성 능력보다 통제 경계가 어디로 이동하는지를 먼저 봐야 한다.
참고
1Google launches generative UI standard for AI agents
2A2UI v0.9: The New Standard for Portable, Framework-Agnostic Generative UI
3AG-UI Explained: How the Agent-User Interaction Protocol Actually Works
4Agent Protocols - MCP, A2A, A2UI, AG-UI
5The accelerating GenUI ecosystem: MCP Apps, OpenAI's Apps SDK and Google A2UI
6Vercel Releases JSON-Render: a Generative UI Framework for AI-Driven Interface Composition
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.