목차
생성형 UI(generative UI)는 데모 단계에서는 인상적이지만, 실제 제품에 넣으려면 “에이전트가 마음대로 새 컴포넌트를 만드는 문제”와 “웹·모바일 렌더러가 서로 달라지는 문제”를 해결해야 한다. A2UI는 이 간극을 메우기 위해 등장한 프레임워크 독립형 UI 선언 표준으로, 에이전트는 UI 의도(intent)만 말하고 실제 렌더링은 팀이 이미 쓰는 디자인 시스템과 클라이언트가 담당하도록 분리한다.
무엇이 다른가
디자인 시스템을 바꾸지 않는다
A2UI의 핵심 메시지는 단순하다. 에이전트가 새 UI 프레임워크를 강요하는 것이 아니라, 기존 컴포넌트 카탈로그를 “말할 수 있게” 만들어야 한다는 것이다. 즉, AI가 Button, Form, Chart 같은 추상 UI 의도를 전달하면 각 클라이언트가 이를 자기 렌더러로 해석한다.
특정 프론트엔드 프레임워크에 묶이지 않는다
웹, 모바일, 로컬 앱이 함께 존재하는 환경에서는 React 전용 생성형 UI만으로는 한계가 있다. A2UI는 공통 스키마와 렌더링 계층으로 이식성(portability)을 확보하려는 접근이다.
v0.9에서 추가된 것
- Agent SDK: 에이전트 측 구현 단순화
- **공유
web-core라이브러리**: 브라우저 렌더러를 더 쉽게 작성 - 공식 렌더러 강화: React, Angular, Flutter, Lit 등 지원
- 언어 기능 추가: 클라이언트 정의 함수, 클라이언트-서버 데이터 동기화, 오류 처리 개선
- 전송 계층 단순화: MCP, WebSocket, REST, AG-UI, A2A 등 다양한 transport와 연결
왜 주목할 만한가
| 항목 | 일반적인 생성형 UI 데모 | A2UI |
|---|---|---|
| 컴포넌트 소유권 | AI가 새 UI를 직접 생성 | 팀의 기존 디자인 시스템 재사용 |
| 렌더링 대상 | 특정 프레임워크에 종속 | 웹·모바일·멀티플랫폼 지향 |
| 스트리밍 | 구현마다 제각각 | 표준화된 스트리밍 인터페이스 지향 |
| 에이전트 통합 | 개별 커스텀 연결 필요 | Agent SDK와 transport로 연결 단순화 |
아키텍처 개념
Agent
-> A2UI schema / intent
-> transport(MCP, WebSocket, REST ...)
-> client renderer
-> existing design system components이 구조 덕분에 에이전트는 “무엇을 보여줄지”에 집중하고, 프런트엔드는 “어떻게 렌더링할지”를 통제할 수 있다.
누가 쓰면 좋은가
- AI 에이전트가 앱 내부에서 동적으로 폼·카드·차트·위젯을 생성해야 하는 팀
- 웹과 모바일에 같은 생성형 경험을 확장하려는 제품 팀
- 자체 디자인 시스템을 유지하면서 생성형 UI를 붙이고 싶은 프론트엔드 팀
시작 예시
npx copilotkit@latest create my-app --framework a2ui실전에서는 렌더러를 바로 커스터마이즈하기보다, 먼저 작은 위젯 카탈로그부터 연결하는 것이 좋다.
라이선스 및 참고
A2UI는 Google이 주도하는 오픈 생태계 프로젝트이며, 렌더러와 도구는 GitHub 및 공식 문서에서 확인할 수 있다.
관련 문서
- gpt-54-tips-frontend — 생성형 모델로 프론트엔드 품질을 높이는 실전 팁
- gemma — 에지 디바이스에서 에이전트 경험을 구현할 때 함께 볼 만한 오픈 모델
참고 자료
- A2UI v0.9: The New Standard for Portable, Framework-Agnostic Generative UI — Google Developers Blog (2026-04-17)