구글, AI 에이전트용 생성형 UI 표준 출시

구글이 공개한 A2UI 0.9는 AI 에이전트가 기존 애플리케이션의 UI 컴포넌트를 동적으로 조합해 화면을 생성할 수 있도록 해주는 프레임워크 독립적(framework-agnostic) 표준이다. 기존의 챗봇 기반 에이전트가 텍스트나 고정된 카드 형태로만 응답하던 한계를 넘어, 에이전트가 런타임에 JSON/스키마 형태의 UI 기술서를 내려주면 클라이언트가 이를 자신이 이미 보유한 네이티브 컴포넌트(React, Flutter, SwiftUI, Android View 등)에 매핑해 렌더링하는 구조다. 즉 LLM이 HTML을 직접 생성하는 방식이 아니라, "버튼/폼/리스트/결제 위젯 같은 의미론적 요소"를 선언적으로 지시하고 실제 렌더링과 상태 관리, 접근성 처리는 호스트 앱이 담당한다. 이 방식은 Generative UI의 고질적 문제였던 디자인 시스템 일관성 파괴, 보안 리스크(임의 마크업 주입), 플랫폼별 UX 편차를 구조적으로 차단한다.

현업 엔지니어 입장에서 이 표준이 중요한 이유는 AI 에이전트의 UX 계층이 드디어 "백엔드 API처럼 계약(contract) 기반"으로 정리되기 시작했다는 점이다. 그간 MCP가 도구 호출 표준을 제공해 에이전트-서비스 연동을 규격화했다면, A2UI는 그 출력 계층, 즉 에이전트-사용자 상호작용을 규격화한다. 결과적으로 백엔드팀은 "에이전트가 어떤 UI 컴포넌트를 호출할 수 있는지"를 OpenAPI처럼 스키마로 노출하고, 프론트엔드팀은 한 번만 컴포넌트 레지스트리를 구현하면 챗봇·음성·에이전트형 제품 어디서든 재사용할 수 있다. 특히 Gemini, ChatGPT Apps, Copilot처럼 서로 다른 에이전트 런타임 위에서 동일한 제품 UI를 제공해야 하는 B2C·B2B SaaS 진영에서 벤더 락인 해소 효과가 크다.

다만 0.9 버전이라는 점에서 프로덕션 도입 전 점검해야 할 사항이 많다. 상태 동기화 모델(에이전트와 클라이언트 간 양방향 이벤트), 폼 검증 책임 경계, 스트리밍 중 부분 렌더링, 다국어·접근성(ARIA) 처리 규약이 아직 확정되지 않았을 가능성이 높으므로 스펙 원문과 레퍼런스 구현을 직접 확인해야 한다. 또한 LLM이 UI 트리를 생성한다는 것은 "의도하지 않은 액션 버튼"이 렌더링될 수 있다는 뜻이므로, 컴포넌트 레지스트리 수준에서 화이트리스트와 권한 스코프(예: 결제·삭제 버튼은 명시적 승인 필요)를 강제하는 방어적 설계가 필수다.

국내 엔지니어가 지금 당장 취해야 할 액션은 세 가지다. 첫째, 자사 디자인 시스템(스토리북 등)에 "에이전트 노출용 컴포넌트 메타데이터(props 스키마, 허용 파라미터, 위험도 등급)"를 태깅하는 작업을 선제적으로 시작하면 A2UI뿐 아니라 향후 등장할 유사 표준(OpenUI, AG-UI 등)에도 즉시 대응 가능하다. 둘째, MCP 서버를 이미 구축했다면 A2UI를 "MCP 도구 호출 결과의 렌더링 규약"으로 결합하는 PoC를 해볼 만하다. 셋째, 보안팀과 함께 "에이전트가 렌더링 가능한 UI의 CSP 격리, 입력 샌드박싱, 감사 로깅" 정책을 수립해두어야 향후 규제·컴플라이언스 이슈에서 자유롭다. 표준이 1.0으로 수렴하기 전에 내부 컴포넌트 인벤토리부터 정리하는 것이 가장 저비용·고효율 준비 작업이다.