A2UI v0.9가 중요한 이유는 생성형 UI를 새 장난감처럼 보여주는 데서 끝나지 않고, 기존 프론트엔드 컴포넌트 체계와 에이전트를 연결하는 표준을 더 현실적인 방향으로 밀어붙였기 때문입니다. Google Developers Blog의 공식 발표(https://developers.googleblog.com/en/a2ui-v0-9-generative-ui/)를 보면 핵심 메시지는 분명합니다. 에이전트가 화면을 직접 마음대로 그리게 두는 것이 아니라, 클라이언트가 이미 가진 디자인 시스템과 컴포넌트 카탈로그를 존중하면서 UI 의도만 공통 포맷으로 전달하자는 겁니다. 실무에서는 이 차이가 큽니다. 데모 단계에서는 LLM이 HTML 비슷한 걸 뱉어도 돌아가지만, 운영 단계에서는 디자인 토큰, 접근성, 상태 관리, 검증 로직, 디바이스별 렌더러 문제가 한꺼번에 터지기 때문입니다.
지금까지 생성형 UI가 실제 서비스에 잘 못 들어간 가장 큰 이유는 세 가지였습니다. 첫째, 에이전트가 프론트엔드 구현 세부사항을 너무 많이 알아야 했습니다. React 컴포넌트 구조, 모바일 렌더링 제약, 필드 검증 규칙이 섞이면 프롬프트가 금방 비대해집니다. 둘째, 팀마다 이미 쓰는 디자인 시스템이 다릅니다. 새로운 표준이 기존 컴포넌트를 대체하려 들면 도입 저항이 커집니다. 셋째, 스트리밍 중간 상태와 오류 복구가 약했습니다. 사용자는 응답이 늦는 것보다 UI가 어설프게 깨지는 걸 더 싫어합니다.
A2UI v0.9는 이 지점에 꽂혀 있습니다. 발표문에서 “Standard”를 “Basic”으로 바꾼 것도 같은 맥락입니다. 프론트엔드 팀은 새로운 기본 컴포넌트 세트를 강요받고 싶지 않습니다. 자기 디자인 시스템을 유지한 채 에이전트가 UI 의도만 말하게 만드는 쪽이 훨씬 현실적입니다.
에이전트가 임의의 UI 조각을 생성하는 대신, 클라이언트가 제공한 컴포넌트 카탈로그를 기준으로 동작합니다. 즉 실무팀은 “우리가 이미 검증한 버튼, 폼, 카드, 테이블만 써라”라는 통제를 유지할 수 있습니다. 이건 접근성과 일관성 면에서 엄청 중요합니다.
브라우저 렌더러를 단순화하는 web-core, 그리고 React·Flutter·Lit·Angular 렌더러 업데이트는 멀티플랫폼 팀에게 꽤 실용적입니다. 지금까지는 웹 데모 하나 성공시키고 모바일은 별도 구현으로 찢어지는 경우가 많았는데, 이런 공용 코어는 중복 작업을 줄여줍니다.
생성형 UI는 LLM 출력만 맞는다고 끝나지 않습니다. 스트리밍 JSON 파싱, 오류 복구, 검증, 지연시간이 다 중요합니다. Agent SDK가 이 부분을 감싸주면 팀은 에이전트 로직에 집중하고, UI 프로토콜 처리 비용을 줄일 수 있습니다.
발표에서 언급한 client-defined functions, client-to-server data syncing은 폼 검증과 협업 편집 시나리오에서 바로 연결됩니다. 예를 들어 에이전트가 제안한 폼 입력값을 클라이언트 쪽 검증 함수로 먼저 걸러내고, 그 상태를 다시 서버와 동기화하는 흐름이 쉬워집니다.
MCP, WebSocket, REST, A2A 등 위에서 A2UI를 태울 수 있다는 점은 특정 런타임에 묶이지 않는다는 뜻입니다. 실무에서는 이 유연성이 중요합니다. 표준이 좋다 해도 기존 통신 구조를 갈아엎어야 하면 채택이 늦어집니다.
A2UI v0.9는 특히 아래 팀에 맞습니다.
반대로 아직도 “에이전트가 직접 HTML을 뱉게 하자” 수준에 머물러 있다면, 초반 속도는 빨라 보여도 운영 단계에서 다시 구조를 뜯어고칠 가능성이 높습니다.
물론 지금 바로 만능은 아닙니다. 첫째, 표준이 있다고 해서 모델이 항상 좋은 UI 결정을 내리는 건 아닙니다. 카탈로그 설계와 예시 품질이 낮으면 결과도 흔들립니다. 둘째, 팀의 상태 관리 구조가 복잡하면 렌더러 연결 비용이 여전히 큽니다. 셋째, 생성형 UI는 보안과 권한 제약을 반드시 클라이언트 측 통제로 보완해야 합니다. 에이전트가 허용된 컴포넌트만 쓴다고 해서 민감 액션이 자동으로 안전해지진 않습니다.
실무적으로는 “어떤 컴포넌트를 노출할지”와 “어떤 필드를 LLM이 조작 가능하게 할지”를 먼저 좁혀야 합니다. 처음부터 전체 디자인 시스템을 다 열면 오히려 디버깅 범위만 커집니다.
가장 좋은 시작은 단순한 조립형 UI부터 붙이는 겁니다. 예를 들면 검색 필터, 결과 카드, 요약 패널, 액션 버튼 정도가 있는 업무 도구입니다. 먼저 카탈로그를 작게 정의하고, 렌더러에서 허용 가능한 props만 노출하세요. 그다음 스트리밍 중간 상태에서 어떤 조각이 먼저 렌더되는지 관찰해야 합니다. 마지막으로 폼 검증, 권한 검증, 실패 시 폴백 UI까지 넣어야 비로소 운영 가능성이 생깁니다.
핵심은 생성형 UI를 “화면을 AI가 마음대로 만든다”로 이해하지 않는 겁니다. A2UI v0.9가 보여주는 방향은 반대입니다. 화면 생성의 자유도를 줄이는 대신, 제품 팀이 통제 가능한 범위 안에서 에이전트가 UI 의도를 말하도록 만드는 겁니다. 실무에서는 이 방식이 더 느려 보여도 결국 더 빨리 갑니다.
