[arXiv 2605.26114] MobileGym: 검증 가능한 병렬 모바일 GUI 에이전트 시뮬레이션 플랫폼

MobileGym: A Verifiable and Highly Parallel Simulation Platform for Mobile GUI Agent Research

https://arxiv.org/abs/2605.26114

Dingbang Wu, Rui Hao, Haiyang Wang, Shuzhe Wu, Han Xiao, Zhenghong Li, Bojiang Zhou, Zheng Ju, Zichen Liu, Lue Fan, Zhaoxiang Zhang | Institute of Automation, Chinese Academy of Sciences; Peking University; The Chinese University of Hong Kong | arXiv:2605.26114 | 2026년 5월

---

1. 서론: 모바일 GUI 에이전트 연구에서 환경이 병목이 되는 지점

모바일 GUI 에이전트 연구는 대규모 언어 모델이 화면을 보고, 버튼을 누르고, 앱 사이를 오가며 사용자의 목표를 완수하는 문제를 다룬다. 최근의 비전-언어 모델은 스크린샷 이해와 좌표 기반 클릭에서 빠르게 좋아졌지만, 실제 연구 파이프라인은 모델 능력보다 평가 환경에서 먼저 막히는 경우가 많다. 실제 스마트폰과 상용 앱을 그대로 쓰면 인터랙션은 자연스럽지만 병렬 실행, 초기 상태 통제, 자동 채점, 개인정보 격리, 실패 재현이 어렵다. 반대로 에뮬레이터나 단순 웹 데모는 통제하기 쉬우나 실제 모바일 앱의 긴 상태 전이와 다중 앱 작업을 충분히 담기 어렵다.

MobileGym은 이 간극을 브라우저 호스팅 모바일 시뮬레이션이라는 방향으로 풀어낸다. 논문은 상용 백엔드를 복제하려 하기보다, 일상 모바일 사용에서 필요한 앱 상태와 OS 동작을 구조화된 JSON으로 모델링하고, 그 상태를 빠르게 캡처·수정·복제·비교할 수 있게 만든다. 이 설계 덕분에 한 서버에서 수백 개의 인스턴스를 병렬로 띄울 수 있고, 인스턴스당 약 400MB 메모리와 약 3초 cold start라는 비용 프로파일을 제시한다. 모바일 에이전트가 온라인 RL을 수행하려면 같은 과제를 여러 번 반복하고 실패 궤적을 많이 수집해야 하므로, 이 비용 차이는 단순한 최적화를 넘어 연구 가능 범위를 바꾸는 조건이다.

논문의 핵심 주장은 MobileGym이 검증 가능한 outcome signal과 대규모 병렬 rollout을 동시에 제공한다는 데 있다. 기존 GUI 에이전트 벤치마크는 최종 화면, UI tree, SQL hook, XPath 규칙, LLM judge처럼 서로 다른 채점 방식을 사용했지만, 긴 작업에서는 작은 부작용이나 중간 상태 누락이 최종 성공 여부를 흐리게 만든다. MobileGym은 전체 환경 상태를 구조화된 JSON으로 보존하고, 과제 정의가 기대하는 상태 변화와 실제 상태 변화를 비교해 deterministic verdict와 dense RL reward를 함께 생성한다. 그래서 이 논문은 모델 아키텍처 제안보다 환경·벤치마크·훈련 루프를 결합한 연구 인프라 논문에 가깝다.

함께 제시된 MobileGym-Bench는 28개 앱 위에서 416개 parameterized task template을 제공한다. 이 중 256개는 test template, 160개는 train template으로 쓰이며, single-app 작업뿐 아니라 cross-app, multi-app, operate, query, hybrid objective까지 함께 포함한다. 논문은 Gemini 3.1 Pro, Doubao-Seed-2.0-Pro, Qwen3.6-Plus, AutoGLM-Phone-9B, UI-TARS-1.5-8B, UI-Venus-1.5-8B, GUI-Owl-1.5-8B-Think, Step-GUI-4B, Qwen3-VL-4B-Instruct를 비교하고, Qwen3-VL-4B-Instruct에 GRPO를 적용했을 때 test set에서 성공률이 12.8%p 증가한다고 보고한다. 또한 59개 real-device signal subset에서 simulation-side training gain의 95.1%가 유지된다는 결과를 제시해, 시뮬레이션이 실제 기기로 옮겨갈 때 어느 정도 신호를 보존하는지 확인한다.

Figure 1: MobileGym 예시 화면과 구성 가능한 샌드박스 기능

Figure 1은 MobileGym이 단순한 정적 스크린샷 모음을 넘어 앱 런처, 메시징 화면, 상태 주입 기능을 갖춘 샌드박스형 모바일 환경으로 설계됐음을 보여준다. 화면 요소에는 실제 에이전트가 클릭하거나 입력해야 하는 UI가 배치되고, 연구자는 동일한 과제를 여러 초기 상태로 만들 수 있다. 이 그림은 논문이 강조하는 “일상 앱 형태의 상호작용”과 “완전한 상태 통제”가 같은 환경 안에서 결합된다는 점을 시각적으로 요약한다. 특히 좌우 화면의 주석은 앱별 fixture와 runtime overlay가 task parameter를 바꿀 때 화면에 어떻게 드러나는지 보여 준다.

2. 배경 및 관련 연구: 실제 앱, 에뮬레이터, 웹 시뮬레이션 사이의 절충

모바일 GUI 에이전트를 평가하는 기존 흐름은 크게 세 갈래로 나뉜다. 첫째는 AndroidWorld나 AndroidLab처럼 Android emulator 위에서 시스템 앱과 오픈소스 앱을 실행하는 방식이다. 이 접근은 실제 OS 동작과 앱 프로세스에 가까운 장점이 있지만, AVD snapshot, adb instrumentation, UI tree 파싱 같은 인프라 의존성이 크고, 인스턴스당 메모리와 디스크가 커서 온라인 RL의 대량 rollout에는 부담이 된다. 둘째는 MobileBench-OL처럼 실제 기기와 일상 앱을 쓰는 방식이다. 현실성은 높지만, 동일 상태 복원과 병렬화가 어렵고, 민감한 계정·결제·삭제 작업을 반복 실험으로 돌리기 어렵다.

셋째는 surrogate app이나 웹 기반 모사 환경을 만드는 방식이다. 이 방식은 연구자가 앱 상태를 더 쉽게 제어하고 검증 로직을 심을 수 있지만, 실제 모바일 사용에서 나타나는 다중 앱 전이, 알림, 설정, 입력 방식, 뒤로가기 체인, 런처 상태 같은 요소가 빠지면 에이전트가 배우는 정책이 제한될 수 있다. MobileGym은 이 세 흐름 사이에서 일상 앱의 상호작용 패턴과 상태 기반 검증 가능성을 우선순위로 잡는다. 논문은 상용 서비스의 서버 데이터를 복제하지 않고, 앱별 world data와 runtime overlay를 분리해 연구용으로 안전하고 재현 가능한 상태 공간을 구성한다.

이 배경은 기존 위키에서 다뤘던 trajectory-level agent evaluation과 연결된다. 에이전트 평가는 최종 답변만 보면 부족하고, 어떤 도구를 어떤 순서로 호출했는지, 중간 상태가 의도한 범위 안에서 바뀌었는지, 실패했을 때 어디서 벗어났는지를 함께 봐야 한다. MobileGym의 state-diff judge는 이 관점을 모바일 GUI 환경에 적용한다. 특히 COMPLETE를 눌렀을 때 성공처럼 보이는 화면이 나왔더라도, 잘못된 연락처를 수정했거나 불필요한 설정을 바꿨다면 unexpected side effect로 분리할 수 있어야 한다.

또 하나의 배경은 long-horizon agent training이다. 모바일 작업은 한두 번의 클릭으로 끝나는 경우보다, 앱 실행, 검색, 세부 화면 이동, 폼 입력, 확인, 다른 앱 참조, 답변 제출이 이어지는 경우가 많다. 이런 작업에서는 sparse terminal reward만으로는 어떤 행동이 성공에 기여했는지 알기 어렵고, 실패 궤적은 길고 비싸게 쌓인다. MobileGym이 snapshot, reset, fork, deterministic judging을 강조하는 이유는 이 긴 horizon 문제를 모델 학습 단계에서 다루기 위한 기반을 마련하기 위해서다.

Table 1: 기존 모바일 GUI 에이전트 벤치마크와 MobileGym의 인프라 비교

	AndroidWorld	AndroidLab	MobileWorld	MobileBench-OL	MobileGym
Runtime	Emulator	Emulator	Emulator	Real device	Browser
App types	System + open-source	System + open-source	System + surrogates	Real everyday apps	Simulated everyday + system
Everyday app coverage	✗	✗	Surrogates	✓ (real)	✓ (simulated)
Apps / task units	20 / 116 templates	9 / 138 instances	20 / 201 tasks	80 / 1080 instances	28 / 416 templates
Verification	adb programmatic	UI-tree + LLM	SQL + hooks	XPath rules	State-based programmatic
Full environment state comparison	✗	✗	✗	✗	✓
Snapshot & restore	App-data snapshot	AVD snapshot	AVD snapshot	✗	JSON (ms-level)
State customization	Limited	Limited	Partial (SQL)	✗	Full (JSON)
Online RL-ready	Limited	Limited	Limited	✗	✓
Memory per instance	∼ ≈ 4.5 GB	∼ ≈ 6 GB	≥ ≥ 4.5 GB	N/A	∼ ≈ 400 MB
Disk footprint	∼ ≈ 20 GB	∼ ≈ 9 GB	≥ ≥ 20 GB	N/A	∼ ≈ 50 MB
Cold start	∼ ≈ 78 s	—	—	N/A	∼ ≈ 3 s
Parameterized tasks	✓	✗	✗	✗	✓
Sim-to-Real validation	N/A	N/A	N/A	N/A	Validated

Table 1에서 가장 두드러지는 차이는 자원 사용과 상태 제어다. AndroidWorld, AndroidLab, MobileWorld는 에뮬레이터 기반이므로 인스턴스당 수 GB 메모리와 큰 디스크 footprint가 필요하고, snapshot/restore도 AVD나 앱 데이터 스냅샷 수준에 머문다. MobileBench-OL은 실제 앱의 현실성을 얻는 대신 상태 customization과 온라인 RL-ready 항목에서 제약이 크다. MobileGym은 브라우저 기반이라는 선택을 통해 약 50MB 디스크 footprint와 약 400MB 메모리를 제시하고, JSON 상태를 밀리초 단위로 저장·복구할 수 있다고 보고한다.

이 표를 읽을 때 중요한 점은 MobileGym이 모든 기준에서 실제 기기보다 우월하다고 주장하기보다, 연구자가 반복 실험과 RL 학습을 수행할 수 있는 통제 가능한 일상 앱 대역폭을 만든다는 점이다. 실제 기기는 사용자의 계정, 서버 상태, 네트워크, 기기 권한, 앱 업데이트에 묶인다. MobileGym은 그런 외부 변수를 줄이고, 실험자가 task parameter, app state, OS setting, answer field를 직접 설정하게 한다. 그래서 논문의 비교축은 “현실성” 하나를 넘어 검증성, 병렬성, 비용, task creation practicality까지 확장된다.

3. 방법론: MobileGym의 구조화 상태와 검증 루프

3.1 브라우저 호스팅 환경과 계층형 상태 모델

MobileGym의 방법론에서 가장 먼저 봐야 할 부분은 계층형 state model이다. 논문은 앱 화면을 단순 DOM이나 이미지로만 보지 않고, read-mostly World Data, per-environment Runtime Overlay, OS Runtime을 조합해 하나의 구조화된 environment state로 만든다. World Data는 연락처, 메시지, 게시글, 상품, 노선, 음악 목록처럼 앱이 읽는 기준 데이터를 담고, Runtime Overlay는 각 인스턴스에서 발생한 수정·추가·삭제를 분리해 기록한다. OS Runtime은 런처, 설정, 권한, 알림, 최근 앱, 입력 상태 같은 모바일 시스템 동작을 표현한다.

이 구조는 에이전트 연구에서 두 가지 장점을 만든다. 첫째, 같은 world data를 공유하면서도 각 rollout이 독립적인 overlay를 가질 수 있으므로 대량 병렬 실험이 가능하다. 둘째, task generator가 특정 초기 상태를 프로그램적으로 만들 수 있고, judge가 expected state와 actual state를 비교할 수 있다. 예를 들어 메시지 앱에서 특정 사람에게 내용을 보내는 작업은 화면 OCR만으로는 성공 여부가 애매하지만, structured message store에서 수신자, 본문, timestamp, side effect를 확인하면 더 안정적인 판정이 가능하다.

논문은 Android의 build props, settings, hardware/sensor manager, app data, runtime volatile store를 MobileGym 구현 계층으로 매핑한다. persisted state와 volatile state를 나누는 이유는 replay와 reset의 의미를 명확히 하기 위해서다. 설정 값이나 앱 데이터는 snapshot에 남아야 하지만, 현재 포커스, 일시적인 popup, 애니메이션 상태는 episode 내부에서만 의미가 있을 수 있다. 이 구분이 흐려지면 동일 task를 다시 실행했을 때 결과가 달라지고, RL 보상도 불안정해진다.

Figure 2: MobileGym의 end-to-end workflow: task instantiation, parallel rollout, state-diff verification

Figure 2는 MobileGym의 전체 연구 루프를 보여준다. 과제는 구조화된 상태에서 인스턴스화되고, 동일한 초기 상태를 여러 rollout으로 fork할 수 있으며, 에피소드가 끝나면 state-diff 기반 판정이 벤치마크 지표와 RL reward로 변환된다. 이 흐름에서 환경은 단순 실행 컨테이너를 넘어 task 생성, 병렬 수집, 자동 채점, 학습 신호 생성을 연결하는 중앙 컴포넌트로 작동한다. 따라서 benchmark와 online RL이 서로 다른 환경을 쓰지 않고 같은 judge contract를 공유한다는 점이 중요하다.

Figure 3: World Data, Runtime Overlay, OS Runtime으로 구성된 MobileGym 상태 모델

Figure 3은 MobileGym의 상태가 어떤 계층으로 구성되는지 설명한다. 앱 view는 읽기 중심의 World Data, 각 환경별 Runtime Overlay, OS Runtime이 합성되어 만들어지며, 이 합성 결과가 화면 렌더링과 검증 모두에 쓰인다. 이 설계는 에이전트가 본 화면과 judge가 비교하는 상태가 같은 원천에서 나오도록 만들어, 평가와 학습 사이의 불일치를 줄이는 데 초점을 둔다. 특히 overlay가 per-environment mutation을 담기 때문에 대량 병렬 rollout에서도 앱의 기본 데이터와 실험 상태를 분리할 수 있다.

Table 2: Android 상태 계층과 MobileGym 구현 계층의 대응

Android tier	MobileGym implementation	Persisted
Build Props	OsStateStore.build	✓
Settings	OsStateStore.settings	✓
Hardware/Sensor	+ Managers	✓
App Data	createAppStore (per-app)	✓
Runtime	Volatile stores	× ×

3.2 Action abstraction과 모바일 상호작용 충실도

MobileGym의 action space는 17개 동작으로 구성된다. 물리 터치 계열에는 CLICK, DOUBLE_TAP, LONG_PRESS, TYPE, SWIPE, DRAG가 있고, 시스템 키에는 BACK, HOME, RECENT, ENTER가 있다. 제어 동작으로 WAIT와 AWAKE가 있으며, 종료·응답 동작으로 ANSWER, COMPLETE, ABORT가 제공된다. INFO와 NOOP도 포함된다. 이 action abstraction은 실제 모바일 사용에서 필요한 핵심 조작을 유지하면서도, 에이전트 로그와 judge가 해석하기 쉬운 형태로 동작을 표준화한다.

특히 COMPLETE와 ANSWER를 분리한 점이 중요하다. query task에서는 에이전트가 화면을 읽고 답을 제출해야 하지만, operate task에서는 실제 앱 상태를 바꾼 뒤 완료를 선언해야 한다. free-text answer 하나로 모든 작업을 처리하면 성공 판정이 텍스트 매칭에 과하게 의존하고, 반대로 완료 선언만 있으면 검색·질의형 과제의 답을 평가하기 어렵다. MobileGym은 task objective에 따라 state-diff, AnswerSheet, typed field check를 조합해 answer와 outcome을 분리한다.

이 action space는 모델에게도 학습 신호를 더 명확히 준다. 좌표 클릭이나 텍스트 입력이 실제 UI에 어떤 변화를 만들었는지 structured state에서 확인할 수 있고, 잘못된 클릭이 side effect로 남으면 USE 지표로 드러난다. 장기적으로는 action log, state diff, answer field를 함께 이용해 실패 유형을 fine-grained하게 분해할 수 있다. 이 점은 단순 success rate만 보고 모델을 비교할 때 놓치는 오류 구조를 분석하는 데 유용하다.

Table 3: MobileGym의 17개 action abstraction

Category	Action	Parameters & description
Physical touch	CLICK	point=[x,y] , single tap
DOUBLE_TAP	point=[x,y] , double tap
LONG_PRESS	long press to trigger context menu
TYPE	value=str (optional point/clear), supports Chinese pinyin IME
SWIPE	point1, point2 , with inertia
DRAG	point1, point2 , no inertia
System keys	BACK	invoke the BackDispatcher priority chain
HOME	return to desktop
RECENT	open recent-tasks list
ENTER	fire the Enter key
Control	WAIT	value=seconds
AWAKE	value=app_id , launch an app
Termination/answer	ANSWER	value=str , submit an answer (does not terminate)
COMPLETE	terminate the episode, declaring success
ABORT	terminate the episode, declaring inability to complete
Other	INFO	value=str , ask the user a clarifying question (does not terminate)
NOOP	no-op (used internally by the agent)

3.3 AnswerSheet와 deterministic state-diff judge

MobileGym의 검증 루프는 state-diff judge와 AnswerSheet protocol을 중심으로 설계된다. state-diff judge는 과제가 요구한 상태 변화와 에이전트가 실제로 만든 상태 변화를 비교한다. 예를 들어 알람 설정, 연락처 수정, 메시지 발송, 일정 등록처럼 앱 내부 상태가 바뀌는 작업에서는 expected patch와 actual patch를 비교해 성공 여부를 판정한다. 이 방식은 화면 텍스트가 우연히 맞거나, 모델의 reasoning trace에 gold answer가 포함되는 문제를 줄인다.

AnswerSheet는 질의형 작업의 free-text 채점 실패를 줄이기 위한 장치다. 논문은 free-text heuristic이 동치 답변을 거절하거나, reasoning에 포함된 gold answer를 잘못 받아들이는 문제를 지적한다. AnswerSheet는 GUI form filling과 typed field check를 사용해 답변 형식을 구조화한다. 날짜, 숫자, 선택지, 텍스트, 다중 필드 답변처럼 유형이 다른 output을 명시적으로 검사할 수 있으므로, LLM judge 없이도 더 재현 가능한 판정을 제공한다.

이 검증 설계는 RL reward로도 이어진다. task가 끝났을 때 binary success만 주는 대신, 진행률이나 부분 상태 충족 정도를 dense reward로 변환할 수 있다. 논문이 reported Progress Rate(PR), False Complete(FC), Overdue Termination(OT), Unexpected Side Effects(USE)를 함께 보는 이유도 여기에 있다. 성공률이 같아도 어떤 모델은 너무 빨리 COMPLETE를 누르고, 어떤 모델은 긴 경로를 헤매며, 어떤 모델은 목표 외 상태를 바꿀 수 있다. MobileGym은 이런 차이를 지표로 분리해 학습과 디버깅에 쓰도록 설계한다.

Figure 4: AnswerSheet protocol: free-text heuristic 대신 typed field와 GUI form filling으로 답변 검증

Figure 4는 AnswerSheet가 필요한 이유를 예시로 설명한다. 자유 텍스트 채점은 같은 의미의 답을 거절하거나, 추론 문자열 안에 우연히 포함된 정답을 받아들일 수 있다. AnswerSheet는 에이전트가 GUI form에 값을 채우게 하고, 필드 유형별 검사를 수행해 query task의 평가를 구조화한다. 따라서 MobileGym의 judge는 operate task의 상태 변화와 query task의 답변 품질을 같은 실험 루프에서 다룰 수 있다.

4. 실험 설정: MobileGym-Bench와 비교 모델의 구성

4.1 데이터셋 및 벤치마크 구성

MobileGym-Bench는 28개 앱과 416개 task template으로 구성된다. 앱은 12개 everyday app과 16개 system app을 포함하며, everyday app에는 WeChat, RedNote, Alipay, Bilibili, Maps, 12306, WeChat Reading, Spotify, Taobao, JD, Weather, Clock 등이 들어간다. system app은 launcher, settings, notification, contacts, messages, camera, file manager 같은 모바일 OS 수준 기능을 다룬다. 논문은 각 앱의 route object와 compound uiState 수를 함께 제시해, 단순 화면 수보다 실제 navigational state가 더 넓다는 점을 보여준다.

task template은 parameterized되어 같은 논리 작업을 여러 상태와 값으로 생성할 수 있다. 예를 들어 특정 시간의 알람을 켜거나, 특정 도시의 날씨를 묻거나, 커뮤니티 앱에서 게시글을 작성하거나, 지도 앱에서 장소 정보를 찾는 과제가 있다. Test256과 Train160은 scope 기준으로 나뉜다. Test256에서는 single-app이 163개(64%), cross-app 2개 앱 작업이 65개(25%), 3개 이상 앱을 쓰는 multi-app 작업이 28개(11%)다. Train160에서는 single-app 비중이 141개(88.1%)로 더 높고, multi-app은 2개(1.3%)만 포함된다.

이 분할은 모델 평가와 RL 학습을 동시에 고려한 선택으로 보인다. test set은 다양한 난도를 포함해 모델 차이를 드러내고, train set은 상대적으로 안정적인 task에서 online RL을 수행할 수 있게 한다. 논문은 difficulty를 L1~L4로 나누고, objective를 operate, query, hybrid로, composition을 atomic, sequential, transfer, deep으로 나눈다. 이러한 분류는 단순히 평균 성공률 하나를 내기보다, 어떤 종류의 작업에서 모델이 무너지는지 보는 데 쓰인다.

Table 4: MobileGym의 simulated app coverage

Type / Category	Apps	#Routes
Everyday apps (12)
Social/Comm.	WeChat	100
	RedNote	41
Finance	Alipay	48
Video/Ent.	Bilibili	52
Travel	Maps, 12306	17, 48
Reading/Music	WeChat Reading, Spotify	30, 35
Social media	Reddit, X (Twitter)	17, 33
Business/Prod.	Tencent Meeting, eBay	18, 9
System apps (16)
Launcher	Launcher	− ∗ -^{ast}
Core utilities	Settings, Contacts, SMS	138 † , 39 † , 8
Productivity	Calendar, Notes, Calculator, Calculator (AOSP), AnswerSheet	10, 7, 1, 1, − ∗ -^{ast}
System apps	Browser, File Manager, Clock, Theme Store	2, 7, 5, 2
Info/Nav	Weather, Compass, Gallery	9, 4, 5

Table 5: 대표 task 예시와 목적·구성·난도

Objective	Composition	Diff.	App	Instruction example
operate	atomic	L1	Clock	Turn on the 7:30 alarm for me
query	atomic	L1	Weather	Tell me what the temperature is in Beijing right now
operate	sequential	L2	Spotify	Add “Shape of You” to my Liked Songs in Spotify
query	deep_dive	L3	Alipay	In the Alipay bill, accumulate the amounts and tell me which counterparty has the largest total
hybrid	transfer	L3	RedNote → → WeChat	Search “camping” in RedNote and send the title of the first note to Xiaohong via WeChat
query	sequential	L4	eBay	I want to buy a brand-new Sony Bluetooth headset shipped from Japan; which one is the cheapest, and how much is it including shipping?
hybrid	deep_dive	L4	eBay+Alipay → → Notes	Find the cheapest brand-new AirPods on eBay, see how much my Alipay balance would have left after buying it, and write the product name, price, and remaining balance to Notes

Table 6: Test256과 Train160의 scope 구성

Scope	Test (256)	Train (160)
S1 (Single-app)	163 (64%)	141 (88.1%)
S2 (Cross-app, 2 apps)	65 (25%)	17 (10.6%)
S3 (Multi-app, 3+ apps)	28 (11%)	2 (1.3%)
Total	256	160

4.2 구현 세부사항과 평가 지표

평가 지표는 크게 성공률 계열과 진단 계열로 구성된다. Success Rate(SR)는 과제 완료 여부를 나타내고, Progress Rate(PR)는 부분 진행도를 반영한다. 여기에 False Complete(FC), Overdue Termination(OT), Unexpected Side Effects(USE)가 추가된다. FC는 실제로 과제를 끝내지 못했는데 COMPLETE를 누른 경우를 잡고, OT는 성공 가능한 상태를 지나치게 오래 끌거나 종료 타이밍을 놓친 경우를 드러낸다. USE는 목표와 관계없는 상태 변화가 발생했는지 확인한다.

이 지표 구성은 모바일 GUI 에이전트에서 특히 필요하다. 예를 들어 모델이 메시지를 보낼 대상은 찾았지만 본문을 잘못 입력했다면 PR은 일부 높을 수 있으나 SR은 실패다. 반대로 올바른 화면에 도착했지만 COMPLETE를 너무 빨리 눌렀다면 FC가 올라간다. 또한 결제, 계정 설정, 삭제처럼 위험도가 높은 작업에서는 성공 여부보다 부작용을 먼저 봐야 할 수 있다. MobileGym은 high-risk subset을 별도로 분석해 financial operation, account-credential modification, irreversible deletion에 대한 모델별 안정성을 보고한다.

논문은 인스턴스 자원도 중요한 실험 조건으로 제시한다. 브라우저 기반 환경은 인스턴스당 약 400MB 메모리와 약 50MB 디스크 footprint를 갖고, cold start는 약 3초 수준이라고 보고된다. 이는 에뮬레이터 기반 환경의 수 GB 메모리·수십 GB 디스크와 대비된다. 실제 온라인 RL에서는 수천~수만 episode를 생성해야 하므로, 인스턴스 비용은 학습 가능성과 직접 연결된다. MobileGym이 “highly parallel”을 제목에 넣은 이유는 이 지점에서 분명해진다.

4.3 베이스라인과 GRPO 학습 설정

베이스라인은 proprietary model, open-source GUI-specialized model, open-source generalist model로 나뉜다. proprietary model에는 Gemini 3.1 Pro, Doubao-Seed-2.0-Pro, Qwen3.6-Plus가 포함된다. GUI-specialized model에는 AutoGLM-Phone-9B, UI-TARS-1.5-8B, UI-Venus-1.5-8B, GUI-Owl-1.5-8B-Think, Step-GUI-4B가 들어가고, generalist model에는 Qwen3-VL-4B-Instruct가 포함된다. 이 조합은 강한 폐쇄형 모델, GUI 특화 공개 모델, 범용 VLM의 차이를 함께 보여준다.

RL case study는 Qwen3-VL-4B-Instruct를 대상으로 GRPO를 적용한다. 중요한 점은 MobileGym이 reward를 프로그램적으로 제공하므로, 학습 루프가 매 step마다 외부 LLM judge를 호출할 필요가 없다는 것이다. state-diff와 AnswerSheet에서 나온 outcome signal은 episode-level 보상과 progress signal로 변환될 수 있고, 병렬 rollout을 통해 같은 과제 분포에서 여러 trajectory를 수집할 수 있다. 이 조건이 갖춰져야 GUI 에이전트도 텍스트 추론 모델처럼 online RL 실험을 반복적으로 수행할 수 있다.

논문은 simulation에서 얻은 학습 효과가 실제 기기에서도 유지되는지를 보기 위해 59-task real-device signal subset을 사용한다. 여기서는 simulation과 real device의 base/trained 결과를 비교하고, real-device execution은 수동 audit을 거친다. 이 부분은 MobileGym이 모든 현실성을 완전히 포함한다는 주장보다, 시뮬레이션 기반 학습 신호가 실제 UI 실행에 어느 정도 transferable한지를 확인하는 validation으로 읽는 편이 적절하다.

5. 주요 실험 결과: 모델 성능, 난도별 붕괴, sim-to-real 전이

5.1 MobileGym-Bench 전체 성능

MobileGym-Bench test set의 전체 결과는 현재 모바일 GUI 에이전트가 얼마나 어려운 문제에 놓여 있는지 보여준다. 가장 높은 성공률을 기록한 Gemini 3.1 Pro도 SR 58.8%, PR 72.1%에 머문다. Doubao-Seed-2.0-Pro는 SR 52.0%, Qwen3.6-Plus는 SR 45.7%다. 반면 GUI-specialized open-source model은 20% 안팎 또는 그 이하에 머문다. AutoGLM-Phone-9B는 SR 20.0%, UI-TARS-1.5-8B는 13.8%, UI-Venus-1.5-8B는 15.4%, GUI-Owl-1.5-8B-Think는 15.1%, Step-GUI-4B는 12.9%다. 범용 Qwen3-VL-4B-Instruct는 9.4%로 더 낮다.

난도별 결과를 보면 L1에서는 대부분 모델이 어느 정도 성공하지만, L3와 L4에서 급격히 떨어진다. Gemini 3.1 Pro는 L1 97.5%, L2 83.6%, L3 63.3%, L4 21.9%로 감소한다. Doubao-Seed-2.0-Pro도 L1 100.0%, L2 93.2%에서 L3 48.2%, L4 6.2%로 내려간다. Qwen3.6-Plus는 L4가 3.8%에 그친다. 이 패턴은 MobileGym의 어려움이 화면 인식 하나보다 긴 계획, 다중 앱 전이, 입력·확인·종료 타이밍 조합에서 나온다는 점을 시사한다.

진단 지표도 눈에 띈다. Gemini 3.1 Pro의 FC는 34.0%, Doubao-Seed-2.0-Pro는 33.6%, Qwen3.6-Plus는 34.0%다. 즉 강한 모델도 과제를 실제로 완료하기 전에 완료 선언을 하는 오류가 많다. open-source GUI model 역시 FC가 높고, 일부 모델은 USE도 두 자릿수로 나온다. MobileGym이 성공률만 제시하지 않고 FC, OT, USE를 함께 보고하는 이유는 여기에서 드러난다. 모바일 GUI task에서는 “목표 상태에 도착했는가”와 “모델이 스스로 끝났다고 판단한 시점이 맞는가”를 분리해서 봐야 한다.

Table 7: MobileGym-Bench Test256의 주요 모델 성능

	Overall (%)	Difficulty SR (%)	Diagnostics (%)
Model	SR	PR	L1 (20)	L2 (73)	L3 (83)	L4 (80)	FC	OT	USE
Proprietary models
Gemini 3.1 Pro	58.8 ± ± 1.4	72.1	97.5	83.6	63.3	21.9	34.0	0.2	5.5
Doubao-Seed-2.0-Pro	52.0 †	63.6	100.0	93.2	48.2	6.2	33.6	0.4	4.7
Qwen3.6-Plus	45.7 †	59.2	100.0	78.1	44.6	3.8	34.0	0.4	14.5
Open-source GUI-specialized models
AutoGLM-Phone-9B	20.0 ± ± 1.3	35.3	86.2	33.6	9.6	1.9	39.6	0.6	12.6
UI-TARS-1.5-8B	13.8 ± ± 1.7	26.3	77.5	21.9	3.0	1.6	38.6	0.2	11.0
UI-Venus-1.5-8B	15.4 ± ± 2.4	28.3	85.0	21.9	6.0	1.9	22.9	0.5	7.7
GUI-Owl-1.5-8B-Think	15.1 ± ± 0.9	28.8	76.2	26.0	4.2	1.2	30.4	0.9	14.1
Step-GUI-4B	12.9 ± ± 1.1	25.7	83.8	17.8	2.4	1.6	37.0	0.8	7.6
Open-source generalist models
Qwen3-VL-4B-Instruct	9.4 ± ± 0.6	20.1	71.2	12.3	0.6	0.3	15.9	0.4	10.0

5.2 objective와 composition별 성능 분해

Table 8의 세부 분해는 평균 SR 뒤에 숨어 있는 병목을 더 잘 보여준다. Difficulty 축에서는 L1/L2와 L3/L4의 간극이 크고, Objective 축에서는 operate, query, hybrid가 서로 다른 실패 양상을 만든다. operate task는 상태 변경을 요구하므로 side effect와 종료 타이밍이 중요하고, query task는 AnswerSheet 기반 답변 정확도가 중요하다. hybrid task는 두 요소를 동시에 요구하므로 더 긴 경로와 더 많은 검증 포인트를 가진다.

Composition 축도 중요하다. atomic task는 하나의 짧은 UI 조작으로 끝날 수 있지만, sequential task는 여러 step을 올바른 순서로 수행해야 한다. transfer task는 한 앱에서 얻은 정보를 다른 앱에 적용하거나, 검색 결과를 이용해 후속 조작을 수행해야 한다. deep task는 깊은 메뉴 탐색과 장기 상태 유지가 필요하다. MobileGym은 이 분류를 통해 모델이 단순 클릭·입력 능력에서 실패하는지, 정보 이동과 장기 계획에서 실패하는지, 또는 완료 판단에서 실패하는지 분리할 수 있게 한다.

Table 8: 난도·목적·구성별 성공률 분해

	Difficulty	Objective	Composition
Model	L1 (20)	L2 (73)	L3 (83)	L4 (80)	oper. (170)	query (48)	hybrid (38)	atom. (22)	seq. (110)	trans. (56)	deep (68)
Proprietary models
Gemini 3.1 Pro	97.5	83.6	63.3	21.9	56.8	64.6	60.5	81.8	76.8	33.0	43.4
Doubao-Seed-2.0-Pro	100.0	93.2	48.2	6.2	52.4	52.1	50.0	77.3	70.0	25.0	36.8
Qwen3.6-Plus	100.0	78.1	44.6	3.8	41.2	50.0	60.5	81.8	61.8	16.1	32.4
Open-source GUI-specialized models
AutoGLM-Phone-9B	86.2	33.6	9.6	1.9	20.7	23.4	12.5	56.8	25.7	7.1	9.6
UI-TARS-1.5-8B	77.5	21.9	3.0	1.6	14.0	20.3	4.6	37.5	20.2	2.7	4.8
UI-Venus-1.5-8B	85.0	21.9	6.0	1.9	16.9	15.6	8.6	37.5	20.7	6.2	7.4
GUI-Owl-1.5-8B-Think	76.2	26.0	4.2	1.2	16.9	14.6	7.9	44.3	20.9	2.7	6.6
Step-GUI-4B	83.8	17.8	2.4	1.6	16.3	7.8	3.9	30.7	21.4	0.4	3.7
Open-source generalist models
Qwen3-VL-4B-Instruct	71.2	12.3	0.6	0.3	12.9	3.6	0.7	25.0	15.5	0.9	1.5

5.3 GRPO 학습과 sim-to-real transfer

논문에서 가장 실용적인 결과는 GRPO 학습 사례다. MobileGym의 train templates에서 Qwen3-VL-4B-Instruct를 학습하면 256-task test set 성공률이 12.8%p 증가한다고 보고된다. 이 수치는 베이스 모델의 초기 성능이 낮다는 점을 감안하면 의미가 크다. 더 중요한 것은 학습 효과가 simulation 안에서만 나타나는지, 실제 기기에서도 유지되는지다. 논문은 59-task signal-bucket subset을 구성하고, simulation과 real device에서 base/trained 모델을 비교한다.

Figure 5는 simulation-side training gain이 real-device execution에서도 상당 부분 남는다고 보고한다. 전체 Signal Total에서 real-device execution은 simulation-side training gain의 95.1%를 유지한다. 이 결과는 MobileGym이 실제 앱 서버를 복제하지 않더라도, 일정 범위의 GUI 조작 정책과 completion 판단은 실제 환경으로 전이될 수 있음을 보여준다. 다만 이 수치는 59개 signal subset과 수동 audit 조건에서 나온 결과이므로, 모든 앱·모든 위험 작업·모든 장기 시나리오로 곧바로 확대해 읽으면 안 된다.

trajectory length diagnostic도 함께 봐야 한다. 성공률이 높아져도 trajectory가 지나치게 길어지면 실제 사용자 환경에서는 비용과 실패 가능성이 커진다. 논문은 전체 step 수와 성공 trajectory의 평균 길이를 따로 보고한다. 이 구분은 모델이 “천천히 성공하는가”, “빨리 실패하는가”, “성공 가능한 상태를 지나쳐 헤매는가”를 분리하는 데 필요하다. MobileGym의 state trace와 action log는 이런 분석을 자동화할 수 있는 기반을 제공한다.

Figure 5: GRPO 학습 효과의 simulation-to-real transfer 비교

Figure 5는 Qwen3-VL-4B-Instruct의 GRPO 학습 전후를 simulation과 real device signal subset에서 비교한다. 논문은 59개 signal-bucket task에서 simulation-side gain의 95.1%가 실제 기기 실행에서도 유지된다고 보고한다. 이 그림은 MobileGym이 학습용 시뮬레이터로만 머물지 않고, 적어도 제한된 신호 버킷에서는 실제 모바일 UI 조작 능력의 개선과 연결된다는 근거로 쓰인다.

Table 9: trajectory length diagnostic

Model	Steps	Steps✓
Proprietary models
Gemini 3.1 Pro	16.4	13.4
Doubao-Seed-2.0-Pro	17.1	12.8
Qwen3.6-Plus	20.6	14.0
Open-source GUI-specialized models
AutoGLM-Phone-9B	26.8	13.1
UI-TARS-1.5-8B	27.6	13.0
UI-Venus-1.5-8B	21.6	11.0
GUI-Owl-1.5-8B-Think	24.9	11.7
Step-GUI-4B	31.7	11.8
Open-source generalist models
Qwen3-VL-4B-Instruct	17.6	7.9

Table 10: high-risk subset 성공률

Model	Payment (7)	T256-Risk (7)	All (14)
Proprietary models
Gemini 3.1 Pro	64.3	71.4	67.9
Doubao-Seed-2.0-Pro	0.0	71.4	35.7
Qwen3.6-Plus	28.6	42.9	35.7
Open-source GUI-specialized models
AutoGLM-Phone-9B	3.6	28.6	16.1
UI-TARS-1.5-8B	0.0	25.0	12.5
UI-Venus-1.5-8B	10.7	14.3	12.5
GUI-Owl-1.5-8B-Think	3.6	25.0	14.3
Step-GUI-4B	0.0	14.3	7.1
Open-source generalist models
Qwen3-VL-4B-Instruct	0.0	28.6	14.3

high-risk subset은 MobileGym의 안전성 분석 가능성을 보여준다. Payment, account-credential modification, irreversible deletion 같은 작업에서는 단순한 성공률보다 잘못된 조작의 비용이 크다. Table 10에서 일부 모델은 Payment에서 0.0% 또는 낮은 성공률을 보이며, proprietary model 사이에서도 차이가 크다. 이 결과는 모바일 에이전트가 실제 사용자 계정과 연결되기 전에, 위험 작업을 별도 subset으로 분리해 평가해야 한다는 점을 뒷받침한다.

이 대목은 향후 모바일 에이전트 배포에서 특히 중요하다. 일정 확인이나 날씨 조회처럼 reversible하고 저위험인 작업과, 결제·삭제·계정 변경처럼 irreversible하거나 민감한 작업은 같은 평균 SR로 묶으면 안 된다. MobileGym은 task template과 state-diff judge를 이용해 위험 작업을 사전에 태깅하고, side effect를 정량화할 수 있다. 운영 관점에서는 이런 지표가 사람 검수 위치, confirmation policy, permission gate 설계로 이어질 수 있다.

6. 추가 분석 및 Ablation Study: 검증 신호의 안정성과 학습 루프의 해석

6.1 reference model sensitivity와 난도 보정

논문은 difficulty stratification이 특정 reference model에 과하게 의존하지 않는지도 확인한다. L1~L4 난도는 joint SR+PR 기준으로 보정되는데, reference model이 바뀌면 과제 난도 분류가 달라질 수 있다. 이 민감도 분석은 benchmark 설계에서 자주 빠지는 부분이다. 어떤 과제가 “어렵다”고 말할 때, 그 난도가 사람에게 어려운 것인지, 특정 모델 family에게 어려운 것인지, 평가 지표가 불안정해서 어려워 보이는 것인지 구분해야 한다.

MobileGym의 난도 보정은 benchmark를 학습용 환경으로도 쓰려는 목적과 맞물린다. RL curriculum을 만들 때 난도 bucket이 불안정하면 모델은 쉬운 task에서 보상을 빠르게 얻거나, 너무 어려운 task에서 실패 trajectory만 쌓을 수 있다. reference sensitivity를 확인하면 L1~L4가 단일 모델의 편향을 넘어 여러 모델 관측에서 비교적 유지되는지를 볼 수 있다. 이는 train/test 분할과 curriculum sampling을 설계할 때 중요한 품질 게이트다.

Table 11: L1~L4 stratification의 reference-model sensitivity

	8 reference models (primary)	4 reference models (sensitivity check)
Model	L1 (20)	L2 (73)	L3 (83)	L4 (80)	L1 (25)	L2 (99)	L3 (58)	L4 (74)
Proprietary models
Gemini 3.1 Pro	97.5	83.6	63.3	21.9	98.0	85.4	56.0	12.2
Doubao-Seed-2.0-Pro	100.0	93.2	48.2	6.2	100.0	88.9	34.5	0.0
Qwen3.6-Plus	100.0	78.1	44.6	3.8	100.0	66.7	34.5	8.1
Open-source GUI-specialized models
AutoGLM-Phone-9B	86.2	33.6	9.6	1.9	78.0	23.5	8.2	5.1
UI-TARS-1.5-8B	77.5	21.9	3.0	1.6	67.0	15.9	0.4	3.4
UI-Venus-1.5-8B	85.0	21.9	6.0	1.9	79.0	15.9	5.2	1.4
GUI-Owl-1.5-8B-Think	76.2	26.0	4.2	1.2	64.0	19.2	5.6	0.7
Step-GUI-4B	83.8	17.8	2.4	1.6	79.0	11.6	2.6	0.3
Open-source generalist models (Sim-to-Real subject)
Qwen3-VL-4B-Instruct (base)	71.2	12.3	0.6	0.3	63.0	7.6	0.9	0.3
Qwen3-VL-4B-10s (trained)	92.5	37.7	11.7	1.2	86.0	30.1	8.2	1.0
Trained − - base lift (pt)	+21.3	+25.4	+11.1	+0.9	+23.0	+22.5	+7.3	+0.7

6.2 VLM judge, manual audit, deterministic judge의 역할 분담

실제 기기 실험에서는 MobileGym 내부의 deterministic state를 그대로 사용할 수 없기 때문에, 논문은 VLM judge와 manual audit을 함께 사용한다. 여기서 중요한 점은 MobileGym이 simulation 안에서는 deterministic judge를 제공하지만, sim-to-real validation에서는 실제 기기 관측과 사람이 확인한 결과가 필요하다는 것이다. 논문은 real-device VLM-judge misjudgment를 수동 검토하고, 같은 trajectory를 GPT-5.4로 다시 judge했을 때의 robustness도 확인한다.

이 분석은 MobileGym의 강점과 한계를 동시에 드러낸다. 시뮬레이션 안에서는 structured JSON state 덕분에 빠르고 일관된 판정이 가능하지만, 실제 기기로 넘어가면 화면 기반 judge가 다시 필요하다. 따라서 MobileGym은 real-device judge를 완전히 대체하기보다, 대규모 학습과 사전 필터링을 담당하고, 최종 deployment validation은 real-device audit으로 보완하는 구조가 자연스럽다. 이런 역할 분담을 명확히 해야 시뮬레이션 벤치마크의 과신을 피할 수 있다.

Table 12: real-device VLM judge 오판 수동 검토

Model	FP	FN	Total	Misjudge
Base (Qwen3-VL-4B-Instruct)	4	1	5/59	8.5%
Trained (+Sim RL, train10s )	4	3	7/59	11.9%
Total	8	4	12/118	10.2%

Table 13: GPT-5.4 재판정 기반 judge robustness check

Judge	Base	Trained	Total	Error rate
Qwen3.6-Plus	5/59	7/59	12/118	10.2%
GPT-5.4	3/59	9/59	12/118	10.2%

6.3 case study: Reddit 글쓰기 궤적에서 보이는 실패와 개선

부록의 Reddit case는 학습 전후의 차이를 더 구체적으로 보여준다. 게시글 작성 과제에서는 제목, 본문, 커뮤니티 선택, post 버튼 활성화 조건이 서로 얽혀 있다. 모델이 버튼 위치만 보고 grayed-out 상태의 Post를 누르면 진행되지 않고, 어떤 필드가 빠졌는지 다시 추론해야 한다. GRPO 학습 후 궤적은 이런 UI precondition을 더 잘 맞추는 방향으로 바뀔 수 있다. MobileGym은 같은 초기 상태에서 base와 trained model의 action trace를 비교할 수 있어, 학습 효과가 성공률 숫자 안에서 어떤 행동 변화로 나타나는지 확인하게 해준다.

이 case study는 state-diff가 왜 필요한지도 설명한다. 화면상으로는 버튼을 누른 것처럼 보여도, 실제 게시글이 생성되지 않았거나 필수 필드가 비어 있으면 outcome은 실패다. 반대로 UI가 잠시 변하거나 toast가 뜨는 것만으로 성공을 판단하면 오판이 생긴다. MobileGym은 게시글 객체, 필드 값, route state, overlay mutation을 함께 확인해 성공 판정을 내릴 수 있다. 긴 GUI task에서 이런 내부 상태 검증은 모델 디버깅과 reward shaping 모두에 직접적으로 쓰인다.

Figure 6: Reddit 글쓰기 과제에서 학습 후 모델의 중간 화면 예시

Figure 6은 Reddit 계열 글쓰기 과제의 portrait screenshot 중 하나로, 모바일 GUI 작업이 단일 클릭보다 여러 필드와 상태 조건의 조합에 가깝다는 점을 보여준다. 학습 후 모델은 화면의 버튼 상태, 입력 필드, 게시 흐름을 더 일관되게 따라가야 하며, MobileGym은 이런 중간 화면을 action trace와 state mutation으로 연결한다. 세로형 화면은 실제 모바일 조작의 공간적 제약을 그대로 드러낸다. 이 사례는 template 수준 지표만으로는 보이지 않는 trajectory 품질 차이를 설명하는 보조 증거로 쓰인다.

Figure 7: Reddit 글쓰기 과제에서 base 모델 궤적의 후반 화면 예시

Figure 7은 같은 계열 과제에서 base 모델 trajectory의 후반 화면을 보여준다. 긴 episode에서는 한 번의 잘못된 클릭보다 누적된 작은 지연, 비활성 버튼 클릭, 필드 누락, 잘못된 완료 선언이 최종 실패를 만든다. MobileGym이 trajectory length, false complete, side effect를 별도로 기록하는 이유는 이처럼 화면 하나만 보면 원인을 분리하기 어려운 실패를 상태와 행동 로그로 재구성하기 위해서다.

6.4 대규모 RL에서 judge 비용이 만드는 병목

MobileGym의 또 다른 분석 포인트는 judge 비용이다. GUI 에이전트 RL에서는 한 번의 학습 라운드가 수천 개 episode를 만들고, 각 episode가 여러 화면 관측과 행동 로그를 포함한다. 만약 모든 에피소드의 최종 상태나 중간 상태를 VLM judge로 확인한다면, 모델 학습보다 평가 호출 비용이 더 커질 수 있다. 논문은 per-run cost와 large-scale RL training cost를 별도로 계산해, deterministic state judge가 단지 재현성을 높이는 장치에 그치지 않고 학습 경제성을 좌우하는 요소임을 보여준다.

이 비용 관점은 모바일 GUI 벤치마크에서 특히 중요하다. 텍스트 추론 벤치마크는 하나의 prompt와 하나의 answer를 비교하는 식으로 단순화할 수 있지만, 모바일 작업은 화면 전이와 앱 상태 변화가 함께 발생한다. judge가 매번 screenshot을 읽고 reasoning을 해야 하면, 학습 데이터 생성 속도는 judge latency에 묶인다. MobileGym은 expected state와 actual state를 프로그램적으로 비교하므로, reward 계산이 외부 모델 호출 수에 비례하지 않는다. 이 구조가 있어야 병렬 rollout으로 얻은 속도 이점이 평가 단계에서 사라지지 않는다.

Table 14: VLM judge를 사용할 때의 per-run 비용 비교

Scenario	Qwen3.6-Plus †	GPT-5.4 ‡
One eval over 1 × × 256 tasks	∼ ≈ $2.6 (¥18)	∼ ≈ $23 (¥158)
GRPO 1 step (96 traj)	∼ ≈ $1 (¥7)	∼ ≈ $8.5 (¥59)
Code-level judging (this paper) : $0 (any scale)

Table 14는 작은 규모 실험에서도 judge 비용이 무시하기 어렵다는 점을 보여준다. 실제 연구자가 여러 모델, 여러 seed, 여러 prompt format, 여러 decoding setting을 반복하면 per-run 비용은 금방 누적된다. MobileGym의 deterministic judge는 task definition을 작성할 때 비용을 미리 지불하고, 이후 반복 실행에서는 낮은 marginal cost로 verdict를 생성한다. 물론 task definition과 schema를 잘못 만들면 잘못된 verdict가 반복되므로, 초기 검증과 manual audit은 여전히 필요하다.

Table 15: 대규모 RL 학습에서 VLM judge 비용이 누적되는 방식

Scale	Qwen3.6-Plus	GPT-5.4	Code-level
100 step (9.6K traj)	∼ ≈ $100	∼ ≈ $850	$0
1K step (96K traj)	∼ ≈ $1,000	∼ ≈ $8.5K	$0
10K step (960K traj) ∗	∼ ≈ $10K	∼ ≈ $85K	$0

Table 15의 누적 비용 분석은 온라인 RL을 실제로 돌릴 때 더 중요하다. 수십만 episode 규모로 확장하면 VLM judge 호출은 단일 논문 실험비 수준을 넘어 인프라 예산의 핵심 항목이 된다. 반면 state-diff judge는 episode 수가 늘어도 비교 연산과 storage 비용 중심으로 증가한다. 이 차이는 연구실 규모의 팀이 모바일 GUI RL을 반복할 수 있는지, 또는 대기업만 가능한 실험으로 남는지를 가르는 조건이 된다. MobileGym의 병렬성은 judge 비용 절감과 같이 읽을 때 실질적 의미가 커진다.

6.5 Sim-to-real gap을 trajectory 단위로 읽는 방법

Sim-to-real 결과는 단순히 성공률 보존 비율 하나로 끝나지 않는다. 같은 task에서 simulation과 real device가 같은 outcome을 냈더라도, 경로 길이와 행동 패턴은 달라질 수 있다. 실제 기기는 animation, loading, keyboard behavior, touch latency, app permission dialog, network delay 같은 요소가 있고, 이런 차이는 step count와 termination timing에 영향을 준다. 논문은 same-outcome paired trajectory length를 objective와 outcome별로 나눠, simulation과 real 사이의 길이 차이를 따로 관찰한다.

Table 16: 난도별 simulation-side training gain

Model	L1 (20)	L2 (73)	L3 (83)	L4 (80)	All
Qwen3-VL-4B-Instruct (base)	71.2	12.3	0.6	0.3	9.4 ± ± 0.6
Qwen3-VL-4B-10s (trained)	92.5	37.7	11.7	1.2	22.2 ± ± 1.2
Δ Δ (training gain, pt)	+21.3	+25.4	+11.1	+0.9	+12.8

Table 16은 GRPO 학습 이득이 난도별로 균등하게 나타나는지 확인하게 해준다. 낮은 난도에서는 이미 base 모델이 일정 수준 성공하기 때문에 gain의 여지가 제한될 수 있고, 높은 난도에서는 exploration 자체가 어려워 gain이 불안정할 수 있다. 따라서 전체 +12.8%p라는 숫자만 보면 어느 bucket에서 학습이 실제로 작동했는지 놓치기 쉽다. MobileGym처럼 task metadata가 구조화되어 있으면, 학습 전후 변화를 난도, objective, app group, risk category로 다시 잘라 볼 수 있다.

Table 17: simulation과 real device의 same-outcome trajectory length 비교

Model	Slice	Pairs	Sim	Real	Δ Δ	MAE
Trained	operate-succ.	91	10.08	12.20	+2.12	5.40
operate-fail	12	23.75	17.42	− 6.33 -6.33	8.50
query-succ.	28	13.71	5.54	− 8.18 ⋆ -8.18^{star}	8.18
hybrid-succ.	17	18.06	15.06	− 3.00 ⋆ -3.00^{star}	3.94
Base	operate-succ.	38	5.00	6.03	+1.03	1.34
operate-fail	57	16.74	38.32	+ 21.58 † +21.58^{†}	21.75
query-succ.	6	15.50	6.00	− 9.50 ⋆ -9.50^{star}	9.50
query-fail	28	16.21	30.57	+ 14.36 † +14.36^{†}	27.79
hybrid-fail	39	17.64	34.23	+ 16.59 † +16.59^{†}	19.97

Table 17은 성공·실패 outcome이 같아도 simulation과 real device의 평균 step 차이가 생길 수 있음을 보여준다. 이 차이는 단순한 noise가 아니라 배포 관점에서 중요한 신호다. 실제 기기에서 같은 성공을 얻기 위해 더 많은 step이 필요하다면 사용자는 지연을 체감하고, 더 긴 trajectory는 중간 오류와 side effect의 노출 면적을 키운다. 반대로 simulation에서만 길게 헤매고 실제 기기에서 짧아지는 경우라면, simulator UI나 timing이 불필요한 어려움을 만들고 있을 가능성도 검토해야 한다.

따라서 MobileGym의 sim-to-real validation은 “성공률이 유지된다”는 주장에만 머물면 부족하다. 더 정확한 읽기는 성공률, progress, step length, false complete, unexpected side effect, manual audit 결과를 함께 보는 것이다. 시뮬레이션은 빠른 학습과 반복 가능한 디버깅을 담당하고, 실제 기기는 위험 작업과 timing-sensitive interaction을 검증하는 역할을 맡는다. 이 분담이 명확할수록 MobileGym 같은 환경은 실제 배포 전 단계의 filter와 training accelerator로 더 설득력을 갖는다.

6.6 앱 coverage와 task template이 만드는 연구 확장성

MobileGym의 28개 앱 coverage는 단순한 앱 개수보다 route와 compound uiState 수가 더 중요하다. 모바일 앱은 같은 화면처럼 보여도 tab, drawer, popup, permission banner, keyboard state, modal sheet가 결합되면 다른 상태가 된다. 에이전트는 이런 미세 상태 차이를 보고 다음 행동을 선택해야 하며, task template은 그 상태 차이를 평가 가능한 목표로 변환해야 한다. 논문이 navigation declaration과 compound uiState를 세는 이유는 환경 복잡도를 화면 수보다 세밀하게 드러내기 위해서다.

Parameterized task template은 benchmark 유지보수 측면에서도 장점이 있다. 사람이 416개 task instance를 각각 손으로 쓰는 방식은 빠르게 낡고, 특정 값이나 화면에 과적합된 평가가 되기 쉽다. MobileGym은 template에서 target contact, city, item, time, route, answer field를 바꿔 여러 instance를 만들 수 있으므로, 모델이 특정 정답 문자열을 외우는 것을 줄이고 더 넓은 상태 분포를 만들 수 있다. 이 방식은 후속 연구자가 새로운 앱을 추가하거나 curriculum을 만들 때도 그대로 재사용할 수 있다.

다만 template 기반 확장은 품질 관리가 함께 따라와야 한다. task generator가 생성한 값이 앱 state와 맞지 않거나, judge가 expected patch를 잘못 정의하면 deterministic judge는 빠르게 잘못된 판정을 반복한다. 그래서 MobileGym의 다음 과제는 task authoring tool, schema validation, automatic sanity check, small manual audit loop를 더 촘촘하게 만드는 것이다. 특히 high-risk task에서는 generated template이 실제로 안전한 sandbox 안에 남는지, 위험한 side effect가 별도 필드로 잡히는지 확인하는 검증 절차가 필요하다.

이 관점에서 MobileGym은 benchmark라기보다 벤치마크를 계속 생성하고 검증하는 시스템에 가깝다. 새로운 모델이 등장할 때마다 같은 static task만 반복하면 곧 포화되거나 누출될 수 있다. 반면 structured state와 parameterized generator가 있으면 task distribution을 주기적으로 갱신하고, 모델 실패 유형에 맞춘 adversarial template도 만들 수 있다. 모바일 GUI 에이전트 연구가 장기적으로 발전하려면 이런 생성형 벤치마크 운영 능력이 모델 성능만큼 중요해진다.

6.7 실패 taxonomy를 학습 데이터로 되돌리는 방법

MobileGym의 진단 지표는 결과 보고용 표에서 끝나지 않고, 다음 학습 라운드의 데이터 선택 기준으로 되돌릴 수 있다. FC가 높은 모델에는 완료 선언 직전 상태를 더 많이 샘플링해 completion calibration을 학습시킬 수 있고, USE가 높은 모델에는 목표 field와 non-target field를 구분하는 negative example을 늘릴 수 있다. OT가 높은 모델에는 성공 가능한 중간 상태에서 episode를 짧게 끝내는 continuation을 만들 수 있다. 이런 식으로 실패 taxonomy가 curriculum sampler와 연결되면, benchmark는 점수판에서 훈련 데이터 생성기로 역할이 확장된다.

이 접근은 모바일 GUI 에이전트가 겪는 오류를 더 현실적으로 다룬다. 많은 실패는 화면을 전혀 이해하지 못해서 생기기보다, 이미 필요한 정보를 얻었는데 완료를 선언하지 못하거나, 필드 하나를 잘못 채우거나, 뒤로가기를 한 번 더 눌러 이전 상태를 잃어버리는 식으로 발생한다. 최종 SR만 보면 이런 오류는 모두 실패로 뭉개진다. MobileGym은 action trace와 state mutation을 함께 남기기 때문에, 같은 실패라도 “탐색 실패”, “정보 추출 실패”, “입력 오류”, “종료 판단 오류”, “부작용 발생”으로 다시 분해할 수 있다.

운영 관점에서는 이 분해가 permission policy와도 연결된다. 결제나 삭제처럼 위험한 작업에서는 모델이 목표 상태를 정확히 만들었더라도 즉시 COMPLETE를 허용하지 않고, 변경된 state field와 사용자가 확인해야 할 summary를 제시하게 할 수 있다. 반대로 저위험 query task에서는 AnswerSheet 검증을 통과하면 빠르게 종료해도 된다. MobileGym의 task metadata와 high-risk subset은 이런 차등 정책을 실험하기 위한 출발점이 된다. 에이전트 성능을 높이는 것과 배포 안전성을 높이는 것을 같은 환경에서 측정할 수 있다는 점이 실무적으로 중요하다.

또한 MobileGym은 실패 재현성을 높인다. 실제 기기에서 한 번 실패한 trajectory는 앱 서버 상태나 알림, 네트워크, 계정 정보가 바뀌면 그대로 재현하기 어렵다. 하지만 MobileGym에서는 episode 시작 state를 JSON snapshot으로 저장하고, 같은 state에서 모델, prompt, decoding temperature, action parser만 바꿔 비교할 수 있다. 이는 모델 디버깅에서 매우 큰 장점이다. 같은 실패를 반복 실행할 수 있어야 prompt 수정이 문제를 고쳤는지, 단지 우연히 다른 경로를 탔는지 구분할 수 있다.

장기적으로는 이 재현성이 benchmark governance와도 연결된다. task template이 공개되고 모델이 여러 번 평가되면, 일부 작업은 학습 데이터에 섞이거나 프롬프트 수준에서 공략될 수 있다. MobileGym처럼 state와 parameter를 프로그램적으로 바꿀 수 있는 환경은 고정된 instance 목록보다 누출에 더 강한 평가 운영을 가능하게 한다. 연구자는 동일한 task family 안에서 unseen parameter와 unseen initial state를 계속 만들 수 있고, 특정 모델이 외운 답이 아니라 실제 GUI 조작 정책을 쓰는지 더 자주 확인할 수 있다.

7. 한계점 및 향후 연구 방향: 시뮬레이션의 통제성과 현실성 사이

MobileGym의 가장 큰 한계는 시뮬레이션이 구조화된 상태를 제공하는 만큼, 실제 상용 앱의 모든 동작을 포함하지 않는다는 점이다. 논문은 interaction fidelity를 목표로 하지만 proprietary backend를 복제하지 않는다. 따라서 추천 피드, 실시간 네트워크 지연, 서버 측 권한 정책, 실제 결제 흐름, 앱 업데이트, 지역별 UI 변형, 사용자별 personalization은 제한적으로만 반영될 수 있다. 이 제한은 연구 환경으로서의 안전성과 재현성을 얻기 위한 선택이지만, 실제 배포 성능을 예측할 때는 별도의 real-device validation이 필요하다.

두 번째 한계는 deterministic judge가 상태 스키마에 의존한다는 점이다. judge가 볼 수 있는 것은 MobileGym이 모델링한 state field와 expected patch다. 어떤 부작용이 스키마 밖에서 발생하거나, 화면상으로 중요한 의미가 state에 반영되지 않으면 judge는 이를 놓칠 수 있다. 즉 state-based judging은 free-text나 LLM judge보다 재현성이 높지만, schema coverage와 task definition 품질에 강하게 묶인다. 따라서 새로운 앱을 추가할 때는 route, uiState, store, side effect taxonomy를 함께 설계해야 한다.

세 번째 한계는 sim-to-real 결과의 범위다. 논문은 59-task signal subset에서 95.1% retention을 보고하지만, 이 subset은 전체 모바일 사용 공간을 대표한다고 보기 어렵다. real-device execution은 수동 audit을 거쳤고, 실제 서비스 계정이나 고위험 작업 전체를 포괄하지 않는다. 이 결과는 MobileGym 기반 학습이 실제 기기로 전혀 전이되지 않는다는 우려를 줄여주지만, 모든 도메인으로 일반화하려면 앱 종류, 언어, 지역, 계정 상태, 네트워크, 권한, 접근성 설정까지 더 넓은 validation이 필요하다.

향후 연구에서는 MobileGym의 JSON state와 실제 Android instrumentation을 연결하는 hybrid validation이 유용할 수 있다. 예를 들어 simulation에서 학습된 policy를 real-device mirror task에 주기적으로 실행하고, 화면 observation, accessibility tree, server-visible state, user confirmation event를 함께 기록하면 sim-to-real gap을 더 정량적으로 측정할 수 있다. 또한 high-risk task에는 permission ladder와 human confirmation policy를 붙여, 모델이 위험 작업을 완료하기 전에 어떤 증거를 제시해야 하는지 평가할 수 있다.

학습 측면에서는 state-diff reward를 그대로 쓰는 것에서 한 단계 더 나아가, action-level provenance와 curriculum scheduler를 결합할 수 있다. MobileGym은 snapshot/fork를 제공하므로 특정 실패 지점에서 여러 continuation을 생성하고, 어떤 action suffix가 outcome을 바꾸는지 비교할 수 있다. 이는 기존 위키에서 다룬 Tree-GRPO식 branch comparison이나 token-level auxiliary signal과 다른 환경 중심 credit assignment로 확장될 수 있다. 모바일 GUI task처럼 긴 horizon과 sparse reward가 함께 나타나는 영역에서는 이런 환경 기반 credit 분석이 모델 학습의 병목을 줄일 가능성이 있다.

8. 내 해석: 검증 가능한 환경이 에이전트 학습의 출발점이 되는 방식

나는 MobileGym을 모델 성능 논문보다 에이전트 학습용 runtime substrate에 가까운 작업으로 읽었다. 이전에 정리한 trajectory-level agent evaluation은 tool order, artifact lineage, recoverability를 함께 봐야 한다고 설명했는데, MobileGym은 그 관점을 모바일 GUI로 옮긴다. 특히 COMPLETE, ANSWER, state-diff, USE를 분리한 점은 “성공처럼 보이는 화면”과 “실제로 목표 상태가 되었는지”를 나누는 데 유용하다. 다만 약점도 분명하다. sim-to-real validation이 59-task signal subset에 머물고, 실제 앱의 서버 상태·추천 피드·계정 정책이 제한적으로만 반영되므로, MobileGym에서 좋아진 정책이 고위험 실제 앱 전반에서도 같은 신뢰도를 갖는다고 보기에는 근거가 아직 좁다.

내가 이 작업을 확장한다면 MobileGym의 state-diff judge를 provenance-aware trace와 결합해 보고 싶다. 각 action이 어떤 state field를 바꾸었고, 그 field가 task objective, side effect, risk tag 중 어디에 연결되는지 episode graph로 남기면 long-horizon agent training에서 credit assignment가 더 선명해질 수 있다. Tree-GRPO나 self-distilled agentic RL은 모델 내부의 rollout·teacher signal을 다루지만, MobileGym은 환경이 직접 fork와 검증을 제공한다는 점에서 보완적인 축이다. 다음 단계는 simulation에서 얻은 branch-level reward 차이를 실제 기기 audit과 주기적으로 맞춰 보는 hybrid benchmark가 될 것 같다. 그렇게 하면 브라우저 시뮬레이션의 속도와 real-device 검증의 신뢰도를 한 파이프라인 안에서 조정할 수 있다.

9. 결론: 모바일 GUI 에이전트 연구를 반복 가능한 실험으로 바꾸기

MobileGym은 모바일 GUI 에이전트 연구에서 자주 분리되어 있던 세 요소를 하나로 묶는다. 첫째, 일상 앱 형태의 상호작용을 제공한다. 둘째, 전체 환경 상태를 JSON으로 캡처·수정·복제·비교할 수 있게 만든다. 셋째, deterministic judge와 AnswerSheet를 통해 benchmark verdict와 RL reward를 같은 프로그램적 검증 루프에서 생성한다. 이 조합은 모델 성능 비교와 함께 실패 분석, curriculum 설계, online RL, sim-to-real validation까지 이어진다.

결과적으로 MobileGym-Bench는 현재 모델들이 모바일 GUI 작업에서 여전히 큰 간극을 보인다는 점을 보여준다. Gemini 3.1 Pro도 Test256에서 SR 58.8%에 머물고, L4 난도에서는 21.9%까지 떨어진다. 공개 GUI 특화 모델과 범용 VLM은 더 낮은 성공률을 보인다. 동시에 Qwen3-VL-4B-Instruct에 GRPO를 적용했을 때 +12.8%p의 simulation gain이 나오고, 제한된 real-device subset에서 그 gain의 95.1%가 유지된다는 결과는 환경 설계가 학습 가능성을 직접 만든다는 점을 보여준다.

이 논문의 가치는 새로운 에이전트 모델을 제안하는 데 있지 않다. 더 정확히는, 모바일 에이전트가 배워야 할 환경을 연구자가 통제 가능한 형태로 다시 만든 데 있다. 앞으로 GUI 에이전트가 실제 사용자 작업을 맡으려면, 화면 이해와 클릭 정책만큼이나 초기 상태 통제, 반복 가능한 실패 재현, side effect 감지, 고위험 작업 분리, real-device audit이 중요해진다. MobileGym은 그 요구를 실험 가능한 형태로 낮추는 인프라를 제시한다.

10. 요약 정리: MobileGym에서 챙겨야 할 핵심 포인트

• MobileGym은 브라우저 호스팅 모바일 GUI 시뮬레이션으로, structured JSON state를 통해 task instantiation, snapshot, fork, reset, state-diff judging을 제공한다.
• 논문은 한 서버에서 수백 개 인스턴스를 띄울 수 있고, 인스턴스당 약 400MB 메모리와 약 3초 cold start를 보고해 온라인 RL용 병렬 rollout 비용을 낮춘다.
• MobileGym-Bench는 28개 앱, 416개 parameterized task template, 256개 test template, 160개 train template으로 구성된다.
• 검증은 free-text matching에 의존하지 않고, state-diff judge와 AnswerSheet를 사용해 operate task와 query task를 구분해 판정한다.
• Gemini 3.1 Pro는 Test256에서 SR 58.8%, PR 72.1%를 기록하지만 L4 난도에서는 SR 21.9%로 떨어져 긴 모바일 작업의 어려움을 드러낸다.
• Qwen3-VL-4B-Instruct는 GRPO 학습 후 test set 성공률이 12.8%p 증가하고, 59-task real-device signal subset에서 simulation-side gain의 95.1%가 유지된다.
• FC, OT, USE 같은 진단 지표는 성공률만으로 보이지 않는 premature completion, 종료 지연, 예상 밖 side effect를 분리한다.
• 한계는 실제 상용 앱의 서버 상태와 개인화, 네트워크, 계정 정책을 완전히 포함하지 않는다는 점이며, real-device audit과 hybrid validation이 계속 필요하다.
• 이 논문은 모델 구조보다 환경·검증·학습 루프를 연결하는 인프라 제안으로 읽을 때, 모바일 GUI 에이전트 연구에서 가장 실용적인 의미가 드러난다.