A2UI Express 공개: 생성형 UI의 구조와 문구를 분리해 지연 줄이기

화면의 구조와 내용을 따로 조립하는 방식을 표현한 생성형 개념 이미지. 실제 A2UI 제품 화면이 아니다.

생성형 UI가 느릴 때 모델을 바꾸는 것만으로 해결되지 않는 경우가 있다. 화면 전체를 긴 JSON으로 생성하도록 맡겼다면, 모델이 출력해야 할 구조 자체를 줄이는 방법도 살펴볼 만하다.

Google은 2026년 10월 27일 A2UI의 교체 가능한 추론 포맷과 A2UI Express를 소개했다. 자유롭게 화면을 구성해야 할 때는 짧은 중간 표현을 쓰고, 형태가 정해진 화면은 구조 선택과 문구 생성을 분리하는 방향이다. 공식 발표

모델의 출력 형식과 전송 형식을 분리한다

A2UI는 클라이언트가 허용하는 컴포넌트 목록을 바탕으로 에이전트가 화면을 설명하는 프로토콜이다. Express는 모델이 쓰는 중간 표현이며, SDK가 이를 표준 A2UI 메시지로 변환한다. 기존 렌더러를 모두 새로 만드는 변화는 아니다.

공식 발표는 Express가 Direct JSON보다 출력 토큰을 최대 약 3분의 1로 줄일 수 있다고 설명한다. 이는 공급자가 발표한 평가 결과다. 모든 서비스의 응답 시간이 똑같이 줄어든다는 보장은 아니다. Google 설명

짧게 쓰되, 카탈로그를 기준으로 해석한다

Express에서는 컴포넌트를 변수에 배정하고 다른 컴포넌트가 그 변수를 참조한다. 위치 인자는 카탈로그 스키마의 순서에 따라 해석하며, 중간의 선택 인자를 건너뛸 때는 밑줄을 쓴다. 데이터 바인딩은 별도의 경로 표현을 사용한다.

다음은 구조를 이해하기 위한 간단한 예시다. 실제 적용 시에는 선택한 프로토콜 버전과 카탈로그의 컴포넌트 서명을 확인해야 한다. 이 글에서 SDK로 실행한 결과는 아니다.

겉모습이 Python과 비슷해도 Python 프로그램으로 실행하는 코드는 아니다. 전용 파서와 스키마 기반 변환기가 처리할 선언형 표현이다. LLM 출력 문자열을 일반 언어의 실행 함수에 넘기는 방식으로 구현하면 안 된다. Express 기술 명세

형태가 정해져 있다면 선택만 맡길 수 있다

설정 화면이나 확인 화면처럼 구조를 미리 정의할 수 있다면, 모델이 컴포넌트 트리를 처음부터 작성할 필요가 줄어든다.

공개 예제 Apparite(jev2ui)는 Jev의 구조화된 결정으로 레이아웃을 선택하고, 코드는 컴포넌트를 조립하며, 별도의 작은 모델이 문구를 작성하는 접근을 보여준다. 예제 저장소의 11개 프롬프트 실험에서 첫 컴포넌트 전송은 92~298ms, 전체 완료는 0.8~1.7초로 보고됐다.

중요한 것은 측정 지점이다. 컴포넌트가 전송된 시각과 사용자가 완성된 내용을 읽는 시각은 다르다. 저장소도 표본이 작고 기준 프롬프트가 수작업이라는 한계를 밝혔으므로, 범용 벤치마크로 받아들이기 어렵다. 버튼·폼 이벤트도 예제에서는 로그만 남기며 실제 업무 처리가 연결된 완성 제품은 아니다. 예제의 결과와 한계

이 구조는 미리 정의한 패턴 밖의 화면을 자유롭게 만드는 데 제약이 있다. 따라서 화면 종류를 충분히 예상할 수 있을 때 먼저 검토하고, 자유로운 구성이 필요한 요청은 Express 같은 방식으로 보내는 편이 합리적이다. 이는 문서에서 설명한 두 방식을 바탕으로 한 설계 제안이다.

도입 전에 버전과 스트리밍부터 확인한다

발표 당시 Python·TypeScript SDK의 Express 경로는 전체 응답을 받은 뒤 컴파일한다고 명시됐다. 문법이 줄 단위라고 해서 사용 중인 SDK가 반드시 한 줄씩 화면을 그려 준다고 가정하면 안 된다. 발표의 SDK 지원 범위

SDK 변경 기록에는 패키지 의존성, 스키마 관련 import, 파서 API의 호환성 변경도 있다. 문서의 예제를 가져올 때 패키지 버전만 확인하지 말고 렌더러 프로토콜과 카탈로그 버전을 함께 맞춰야 한다. Python SDK 변경 기록

현재 설치 버전을 확인하는 명령은 다음과 같다. 패키지를 설치하거나 유료 모델을 호출하는 명령은 아니다.

내 서비스에서 비교할 항목

아래는 적용 여부를 판단하기 위한 검증 제안이다. 특정 서비스에서 이미 개선을 확인했다는 의미는 아니다.

• 동일한 요청과 카탈로그로 Direct JSON, Express, 고정 레이아웃 방식을 비교한다.

• 첫 화면 표시, 첫 의미 있는 문구, 전체 완료 시간을 따로 기록한다.

• 중앙값뿐 아니라 느린 요청 구간과 재시도 비율도 확인한다.

• 구문 통과와 내용의 정확성을 분리해 평가한다.

• 레이아웃 결정, 텍스트 생성, 재시도를 합친 총비용을 비교한다.

• 버튼 클릭 이후 인증·권한 검사와 실제 업무 처리가 연결되는지 검증한다.

가장 먼저 할 일은 큰 모델을 붙이는 것이 아니라 모델이 매번 만들어야 하는 범위를 줄일 수 있는지 확인하는 것이다. 정해진 화면은 코드로 만들고, 선택과 문구처럼 모델이 필요한 부분만 맡기면 지연과 오류를 따로 관리하기 쉬워진다.

자료 확인일: October 28, 2026. 공식 문서와 공개 저장소를 조사했으며, SDK 실행·유료 모델 호출·자체 성능 측정은 수행하지 않았다.