Google, A2UI Express와 별도 결정 모델 경로 소개

Published · AI Daily — AI-assisted deep research, methodology & disclosure

Google의 10월 27일 A2UI 업데이트는 에이전트가 화면을 만들 때 먼저 내놓는 형식을 바꾼다. 모델이 복잡한 JSON 전송 메시지를 직접 쓰는 대신 A2UI Express라는 중간 형식을 출력하고 SDK가 이를 표준 A2UI 메시지로 결정적으로 변환한다. 클라이언트는 여전히 허용된 구성 요소 목록을 알리고 렌더러는 기존 프로토콜을 받는다.

Google의 10월 27일 A2UI 업데이트는 에이전트가 화면을 만들 때 먼저 내놓는 형식을 바꾼다. 모델이 복잡한 JSON 전송 메시지를 직접 쓰는 대신 A2UI Express라는 중간 형식을 출력하고 SDK가 이를 표준 A2UI 메시지로 결정적으로 변환한다. 클라이언트는 여전히 허용된 구성 요소 목록을 알리고 렌더러는 기존 프로토콜을 받는다. 지시와 변환기가 같은 목록 구조에서 만들어지므로 Express가 승인되지 않은 구성 요소를 마음대로 추가하는 것은 아니다.

Google은 자사 시험에서 Express가 비슷한 화면을 만드는 데 Direct JSON보다 텍스트 단위를 최대 세 배 적게 쓰고 지연을 최대 세 배 줄일 수 있다고 말한다. Gemini 3.5 Flash로 51개 과제를 비교했지만 ‘최대’ 수치는 모든 화면과 모델의 보장이 아니다. SDK가 구조를 검증해도 화면의 값, 구성 요소 선택, 실제 업무 동작이 올바른지는 별도의 문제다. 첫 글자가 나오는 시간과 쓸 수 있는 화면이 완성되는 시간도 다르다.

원문은 Python, TypeScript, Dart 에이전트 SDK에서 Express를 쓸 수 있다고 한다. Python과 TypeScript의 Direct JSON은 조각별 전송이 가능하지만 Express는 전체 응답 뒤에 변환된다. Python SDK의 매크로는 주문 식별자를 받아 애플리케이션의 진짜 자료로 값을 채울 수 있어 모델이 금액을 지어낼 필요가 없다. 평가할 때 생성, 변환, 자료 조회, 렌더링을 따로 재야 한다.

화면 모양이 미리 정해졌다면 다른 방식도 있다. Apparite 예시에서는 Jev 결정 모델이 배치 질문에 답하고 코드가 구성 요소를 조립하며 작은 모델이 문구를 쓴다. 11개 입력의 한 번의 실행에서 구성 요소 트리는 92~298밀리초에 보였고 전체 화면은 0.8~1.7초에 완성됐다. 최대 80배라는 수치는 이렇게 제한된 결정 경로에 관한 것이다. 예시는 화면 원형 아홉 개와 블록 열두 개만 다루고 표본도 작다. A2UI SDK에는 아직 결정 모델용 추론 형식이 내장되지 않았다. 따라서 80배를 Express 자체의 결과로 쓰면 틀리다.

정해진 설정 화면에는 제한된 결정 방식이 맞을 수 있고, 승인된 구성 요소 안에서 유연하게 배치해야 하는 화면에는 Express가 더 알맞을 수 있다. 팀은 자체 과제에서 유효한 화면의 비율, 데이터 정확성, 완성까지 걸리는 시간과 실패 처리를 함께 확인해야 한다. Google의 수치는 공급자 시험과 작은 사례이며 독립적인 전 제품 비교가 아니다. 여기서 토큰은 모델이 만드는 텍스트 단위이지 암호화폐가 아니다.

Express의 문법은 각 줄이 구성 요소에 식별자를 부여하고 속성을 정해진 순서대로 전달하는 방식이다. 컴파일러는 이 결과를 표준 전송 메시지로 바꾸기 전에 목록의 계약에 맞는지 확인한다. 입력 형식을 바꿀 수 있다는 것은 화면을 그리는 클라이언트와 네트워크 전송 방식을 매번 새로 만들 필요가 없다는 뜻이다. 하지만 모델이 사용자에게 맞지 않는 구성 요소를 선택하거나 잘못된 데이터 식별자를 제시하면 구조가 올바르더라도 업무 결과는 틀릴 수 있다. 형식 검증과 실제 사용성 평가는 다른 단계다.

속도 수치를 읽을 때는 처음 보이는 화면과 완성된 화면을 구분해야 한다. 원문은 Python과 TypeScript에서 Direct JSON은 조각마다 보낼 수 있지만 Express는 답 전체를 받은 다음 변환한다고 설명한다. 따라서 출력 텍스트가 적다는 것만으로 모든 상황에서 첫 화면이 더 빠르다고 단정할 수 없다. 매크로가 기존 주문 자료를 읽어 값을 채우는 경우에는 자료 조회와 권한 확인도 측정해야 한다. 실제 사용자에게 보이는 정확한 결과가 목적이므로 생성 시간 하나만 비교해서는 안 된다.

Jev를 사용하는 Apparite 예시에서는 모델이 이미 작성된 질문에 답하고 코드가 정해진 틀 안에서 화면을 조립한다. 이 제한 덕분에 속도가 높아질 수 있지만 아홉 화면 원형 밖의 새로운 형태에는 그대로 적용되지 않는다. 11개 예시에서 나온 시간 수치는 작은 첫 관찰이라는 원문의 설명을 함께 남겨야 한다. 특히 A2UI SDK가 아직 결정 모델용 형식을 제공하지 않는다는 제한을 빼면 독자가 바로 그 경로를 설치할 수 있다고 오해한다. 3배와 80배는 서로 다른 비교에서 나왔으므로 같은 성능 주장으로 묶지 않는다.

Sources

FAQ

A2UI Express는 무엇을 바꾸나요?

Google의 10월 27일 A2UI 업데이트는 에이전트가 화면을 만들 때 먼저 내놓는 형식을 바꾼다. 모델이 복잡한 JSON 전송 메시지를 직접 쓰는 대신 A2UI Express라는 중간 형식을 출력하고 SDK가 이를 표준 A2UI 메시지로 결정적으로 변환한다. 클라이언트는 여전히 허용된 구성 요소 목록을 알리고 렌더러는 기존 프로토콜을 받는다. 지시와 변환기가 같은 목록 구조에서 만들어지므로 Express가 승인되지 않은 구성 요소를 마음대로 추가하는 것은 아니다.

최대 80배 수치는 어떤 방식의 결과인가요?

화면 모양이 미리 정해졌다면 다른 방식도 있다. Apparite 예시에서는 Jev 결정 모델이 배치 질문에 답하고 코드가 구성 요소를 조립하며 작은 모델이 문구를 쓴다. 11개 입력의 한 번의 실행에서 구성 요소 트리는 92~298밀리초에 보였고 전체 화면은 0.8~1.7초에 완성됐다. 최대 80배라는 수치는 이렇게 제한된 결정 경로에 관한 것이다. 예시는 화면 원형 아홉 개와 블록 열두 개만 다루고 표본도 작다. A2UI SDK에는 아직 결정 모델용 추론 형식이 내장되지 않았다. 따라서 80배를 Express 자체의 결과로 쓰면 틀리다.

이 속도 수치가 모든 A2UI 앱에 적용되나요?

정해진 설정 화면에는 제한된 결정 방식이 맞을 수 있고, 승인된 구성 요소 안에서 유연하게 배치해야 하는 화면에는 Express가 더 알맞을 수 있다. 팀은 자체 과제에서 유효한 화면의 비율, 데이터 정확성, 완성까지 걸리는 시간과 실패 처리를 함께 확인해야 한다. Google의 수치는 공급자 시험과 작은 사례이며 독립적인 전 제품 비교가 아니다. 여기서 토큰은 모델이 만드는 텍스트 단위이지 암호화폐가 아니다.