Code2World는 현재 스크린샷과 후보 행동을 받아 다음 화면을 렌더링 가능한 HTML로 예측하므로, GUI 에이전트가 클릭하기 전에 결과를 비교하는 세계 모델로 쓸 수 있습니다. 픽셀만 흉내 내는 대신 실행 가능한 코드를 만들기 때문에 예측 화면의 구조를 검사하고 다시 렌더링할 수 있다는 점이 핵심입니다. 다만 화면이 닮았다는 사실과 실제 앱의 상태 전이가 맞다는 사실은 다르므로, 시각 점수만으로 안전한 행동을 보장할 수는 없습니다.
GUI 에이전트는 클릭 전에 다음 화면을 예측할 수 있나: Code2World
왜 다음 화면을 픽셀 대신 코드로 예측할까?
다음 스크린샷을 직접 생성하면 화면은 그럴듯해도 버튼과 계층의 의미를 확인하기 어렵습니다. Code2World는 화면을 HTML 코드로 재구성한 뒤 브라우저로 렌더링합니다. 출력이 실행 가능한 구조이므로 요소 위치와 문구를 수정하고 다시 그려 볼 수 있습니다.
입력은 현재 화면과 행동, 출력은 그 행동 뒤의 화면입니다. 이 구분이 중요합니다. 단순한 스크린샷 복제가 아니라 상태 전이를 예측해야 하기 때문입니다.
예를 들어 같은 로그인 화면에서도 “비밀번호 표시”를 누른 뒤의 화면과 “로그인”을 누른 뒤의 화면은 달라야 합니다. 현재 화면만 복원하는 모델이라면 두 후보에 비슷한 결과를 낼 수 있지만, 세계 모델이라면 행동에 따른 차이를 코드 구조와 렌더링 결과에 반영해야 합니다. 이 차이를 검증해야 에이전트가 후보 행동을 비교할 근거가 생깁니다.
코드 출력은 오류를 찾는 단서도 제공합니다. 예상 문구가 잘못됐는지, 버튼의 위치만 어긋났는지, 요소 자체가 빠졌는지를 HTML과 렌더링 화면 양쪽에서 나눠 볼 수 있습니다. 반면 실제 앱의 내부 변수나 네이티브 위젯 상태가 HTML에 드러나지 않으면, 수정 가능한 표현이라는 장점이 곧 완전한 상태 표현을 뜻하지는 않습니다.
8만 개가 넘는 화면, 행동 쌍은 어떻게 교정될까?
연구는 8만 개가 넘는 화면-행동 쌍으로 구성된 AndroidCode를 사용합니다. 생성된 HTML을 실제로 렌더링하고 목표 스크린샷과 비교하는 시각 피드백 루프를 두며, 원문은 SigLIP 유사도 0.9를 교정 기준의 예로 제시합니다.
유사도 임계값은 편리하지만 기능의 동등성을 보장하지 않습니다. 두 화면이 비슷해 보여도 클릭 대상의 역할이나 스크롤 상태가 다를 수 있으므로, 시각 점수와 요소 동작 검사를 함께 봐야 합니다.
0.9라는 기준도 절대적인 정확도 선으로 읽으면 안 됩니다. 화면 대부분이 같은데 중요한 경고 문구 하나가 빠져도 전체 유사도는 높을 수 있고, 반대로 기능은 같지만 글꼴이나 간격이 달라 점수가 낮아질 수도 있습니다. 교정 단계에서는 전체 화면 점수와 함께 행동이 바꿔야 할 핵심 영역을 별도로 비교하는 편이 합리적입니다.
데이터를 볼 때는 화면 수뿐 아니라 전이의 다양성을 확인해야 합니다. 비슷한 정적 화면이 많이 반복되면 복원 능력은 좋아 보여도 스크롤, 팝업, 오류 상태처럼 중요한 변화는 충분히 배우지 못할 수 있습니다. AndroidCode의 규모는 학습 기반을 설명하지만, 적용하려는 앱의 화면과 행동 분포가 포함됐는지는 별도의 질문입니다.
왜 지도 미세조정 뒤에 RARL을 붙였을까?
초기 지도 미세조정은 화면 구조와 코드 문법을 배우게 합니다. 이후 RARL 단계는 GRPO를 이용해 의미적 시각 보상과 행동 일관성 보상을 함께 최적화합니다. 전자는 렌더링 결과가 목표와 닮았는지, 후자는 입력 행동에 맞는 상태 변화가 일어났는지를 다룹니다.
이 조합은 보기 좋은 정적 복제만 만드는 문제를 줄이려는 설계입니다. 그러나 보상 함수가 놓친 기능 차이는 그대로 학습될 수 있으므로, 높은 보상 자체를 정확성 증명으로 보아서는 안 됩니다.
두 보상은 서로 보완하지만 충돌할 수도 있습니다. 목표 화면과 비슷하게 그리는 데 유리한 선택이 행동의 실제 의미를 흐리거나, 행동 일관성을 맞추느라 세부 화면을 단순화할 수 있습니다. 따라서 학습 결과를 해석할 때는 총보상 하나보다 시각 보상과 행동 보상에서 각각 어떤 실패가 남는지 봐야 합니다.
검증 샘플도 성공 화면만 모아서는 부족합니다. 잘못된 비밀번호, 권한 거부, 네트워크 오류처럼 같은 행동이 다른 결과를 낳는 조건을 분리해야 모델이 하나의 평균적인 화면으로 도망가는지 알 수 있습니다. 이 글에 그런 모든 조건의 결과가 제시된 것은 아니므로, 실제 도입자는 자신의 전이 사례로 다시 시험해야 합니다.
에이전트는 예측 화면으로 행동을 어떻게 고를까?
Code2World는 여러 행동을 제안하고, 각각의 다음 화면을 시뮬레이션한 뒤, 목표에 가까운 결과를 선택하는 Propose–Simulate–Select 흐름에 들어갈 수 있습니다.
원문은 Qwen2-VL-7B 기반의 약 8B 모델, 8대의 H800 GPU를 사용한 설정과 AndroidWorld에서 에이전트 성공률 9.5% 향상을 보고합니다. 이는 해당 모델, 환경의 결과이며, 작은 웹 서비스나 다른 운영체제에 같은 비용과 향상이 적용된다는 뜻은 아닙니다.
후보가 많아질수록 더 좋은 행동을 찾을 가능성은 늘지만, 후보마다 HTML 생성과 렌더링을 반복해야 하므로 지연도 함께 늘어납니다. 위험도가 낮고 결과가 분명한 클릭까지 모두 시뮬레이션하면 비용이 커질 수 있습니다. 반대로 결제, 삭제, 권한 변경처럼 되돌리기 어려운 행동에만 예측 단계를 두면 계산을 중요한 지점에 집중할 수 있습니다.
9.5% 향상도 기준 성공률과 과제 구성, 후보 수를 함께 봐야 의미가 생깁니다. 이 결과는 Code2World를 넣은 의사결정 흐름이 AndroidWorld 설정에서 도움이 됐다는 근거이지, 예측된 각 화면이 모두 정확했다는 뜻은 아닙니다. 성공률 향상과 잘못된 고위험 행동의 빈도를 동시에 측정해야 제품 관점의 이득을 판단할 수 있습니다.
어떤 조건에서 실제 GUI 적용을 보류해야 할까?
HTML은 웹 화면에 자연스럽지만 네이티브 Android 위젯, Flutter 캔버스, 게임 UI의 내부 상태를 그대로 표현하지 못할 수 있습니다. 후보마다 코드를 생성하고 렌더링하면 행동 하나를 고르는 지연도 커집니다. 시각적으로 비슷한 가짜 버튼을 기능적으로 올바른 버튼과 혼동할 위험도 있습니다.
따라서 적용할 때는 화면 유사도 외에 클릭 가능 영역, 접근성 트리, 전환 후 상태를 별도 검사하고, 위험한 행동은 실제 실행 전에 차단해야 합니다. Code2World는 행동의 결과를 미리 보는 보조 모델이지 운영체제의 실제 상태를 대신하는 시뮬레이터는 아닙니다.
도입 실험은 실제 사용자 과정을 짧은 전이 단위로 나누는 데서 시작할 수 있습니다. 각 단계마다 현재 화면, 후보 행동, 실제 다음 화면, 예측 화면을 보관하고 핵심 요소, 문구, 클릭 가능 영역이 일치하는지 기록합니다. 첫 오류가 발생한 단계부터 뒤의 예측은 신뢰하기 어려우므로 연속 성공률뿐 아니라 첫 전이 오류의 위치도 살펴야 합니다.
네이티브 상태가 중요하거나 화면 밖의 조건이 결과를 크게 바꾸는데 HTML이 이를 표현하지 못한다면 적용 범위를 줄여야 합니다. 렌더링 지연이 실제 작업 시간보다 길거나, 시각적으로 유사한 오답이 고위험 행동으로 이어진다면 성공률 평균이 좋아도 운영 투입을 보류하는 편이 맞습니다. 반대로 제한된 화면 집합에서 상태 전이가 명확하고 실제 상태 검사를 함께 붙일 수 있다면, 후보 행동을 거르는 보조 장치로 시험할 수 있습니다.
예측 화면의 오류는 어떤 순서로 분류해야 할까?
먼저 입력 행동이 올바르게 반영됐는지 봅니다. 버튼을 눌렀는데 원래 화면을 그대로 복제했다면 상태 전이 오류이고, 올바른 창이 열렸지만 문구나 배치가 다르면 렌더링 오류에 가깝습니다. 다음으로 예측 HTML의 요소와 실제 화면의 클릭 영역을 대조해 보기만 비슷한 가짜 요소를 찾습니다.
마지막에는 그 오류가 행동 선택을 바꿨는지를 확인합니다. 사소한 색 차이는 후보 순위에 영향을 주지 않을 수 있지만 비활성 버튼을 활성 상태로 그린 오류는 위험한 선택을 만들 수 있습니다. 실패를 시각 차이의 크기가 아니라 다음 행동에 미친 영향으로 분류하면 Code2World를 사용할 수 있는 범위를 더 정확히 정할 수 있습니다.
예측과 실제 상태가 다를 때 에이전트가 즉시 실제 관측으로 돌아오는지도 시험해야 합니다. 틀린 HTML을 계속 세계 상태로 사용하면 작은 전이 오류가 이후 후보 전체에 누적될 수 있습니다. 매 행동 뒤 실제 화면과 핵심 상태를 다시 확인하는 경계가 있어야 예측 모델을 보조 수단으로 제한할 수 있습니다.
화면에 보이지 않는 로그인 상태, 권한, 네트워크 응답도 별도 변수로 취급해야 합니다. 동일한 버튼을 눌러도 계정 권한에 따라 다음 화면이 달라질 수 있는데, 렌더링 코드가 이런 숨은 상태를 받지 못하면 그럴듯한 한 경로만 만들게 됩니다. 파일 삭제, 결제, 권한 변경처럼 되돌리기 어려운 행동은 예측 화면이 일치해도 실제 시스템의 확인 대화상자와 정책 검사를 거쳐야 합니다. 세계 모델의 확신이 아니라 실제 상태를 최종 권한으로 두는 구조가 필요합니다.
함께 읽으면 이해가 이어지는 글
- GigaBrain-0.5M*는 월드 모델을 로봇 정책에 어떻게 연결하나 — GigaBrain-0.5M*의 RAMP가 월드 모델, 인간 개입 롤아웃, 지속 학습을 연결하는 방식과 보고된 로봇 과제 성능의 한계를 분석합니다.
- AI 에이전트가 클릭하기 전 결과를 미리 보면 실수가 줄까? CUWM의 2단계 예측 — CUWM이 행동 뒤의 상태 변화를 문장으로 예측하고 다음 화면을 그리는 이유, 후보 행동 탐색의 가치와 실제 적용 전 확인할 한계를 정리합니다.
- 로봇이 목표까지의 중간 장면을 상상하면 왜 나아질까? Act2Goal의 MSTH — Act2Goal이 현재 image와 goal image 사이의 중간 상태를 visual world model로 만들고, 가까운 미래는 촘촘하게 먼 미래는 성기게 읽는 MSTH로 control에 연결하는 방식을 설명합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.