[논문 리뷰] MobileExplorer: Accelerating On-Device Inference for Mobile GUI Agents via Online Exploration
메타정보
| 항목 | 내용 |
|---|---|
| 저자 | Runxi Huang, Liyu Zhang, Shengzhong Liu, Xiaomin Ouyang (HKUST · SJTU) |
| 학회 | arXiv preprint · 2026 |
| arXiv 또는 DOI | 2605.26546 |
| 데이터 | AndroidWorld (116개 태스크, 20개 실제 Android 앱) + 자체 설계 실세계 태스크 |
| 리뷰 일자 | 2026-05-29 |
TL;DR
- 온디바이스 모바일 GUI 에이전트의 진짜 병목은 단일 추론이 아니라, 한 스텝당 수십 초씩 걸리는 VLM 추론이 15~20번 누적되는 데 있다. 그런데 그 추론 시간 동안 기기는 사실상 놀고 있다.
- MobileExplorer 는 이 유휴 추론 시간을 활용한다. VLM 이 다음 액션을 고민하는 동안, 별도로 태스크와 관련 높은 UI 요소를 가볍게 클릭해 보며 화면을 탐색하고, 그 결과를 간결한 텍스트 힌트로 요약해 다음 추론 스텝의 프롬프트에 주입한다.
- 탐색이 실제 UI 상태를 망가뜨리지 않도록 perceptual hash 기반의 2단계 롤백을 둔다. AndroidWorld 에서 성공률 50.86% (M3A 46.55% 대비 +4.31%p), 평균 추론 스텝 9.24 (M3A 10.93 대비 −15.5%), 실세계 케이스 스터디에서 평균 완료 시간 185.82초 (M3A 대비 −15.9%) 를 보인다.
소개 (Introduction)
모바일 GUI 에이전트 (mobile GUI agent) 는 사용자를 대신해 스마트폰을 자율적으로 조작하는 AI 시스템이다. 화면을 인식하고 (perception), 무엇을 할지 추론하고 (reasoning), 실제로 탭·입력·스와이프 같은 동작을 수행한다 (operation). 최근 vision-language model (VLM) 의 발전으로 스크린샷을 직접 입력받아 동작하는 vision-based 에이전트가 accessibility tree (a11y tree) 기반의 텍스트 에이전트를 추월했다. 스크린샷은 레이아웃, 공간 관계, 아이콘 같은 시각적 단서를 담고 있어 복잡한 인터페이스에서 더 강한 visual grounding 을 제공하기 때문이다.
문제는 배포 방식이다. 텍스트든 비전이든 거의 모든 기존 GUI 에이전트 시스템은 LLM/VLM 추론을 클라우드 서버에서 돌리고, 기기에서는 동작 실행만 한다. 이 구조는 사용자 인터페이스 데이터 — 화면 캡처, 입력 내용 — 를 외부로 업로드해야 하므로 명백한 프라이버시 위험을 안고 있다. 그래서 인식·추론·동작을 모두 기기 안에서 끝내는 완전 온디바이스 (fully on-device) GUI 에이전트의 필요성이 커지고 있다.
그런데 vision-based 에이전트를 온디바이스로 내리면 새로운 벽에 부딪힌다. VLM 은 고차원 시각 입력을 처리하므로 LLM 보다 훨씬 무겁다. 예를 들어 MAI-UI-2B 같은 작은 모델조차 Samsung Galaxy S24 에서 한 번 추론에 약 40초가 걸린다. 게다가 모바일 태스크는 본질적으로 다단계·순차적이라 한 태스크에 15~20번의 동작이 필요하고, 스텝마다 수십 초의 추론이 곧이곧대로 누적된다. 이 논문은 바로 이 지점 — “느린 추론이 한 번이 아니라 길게 반복되며 그 사이 기기는 놀고 있다” — 을 파고들어, 추론 시간을 탐색에 재활용하는 MobileExplorer 를 제안한다.
핵심 기여 (Key Contributions)
- 온디바이스 GUI 에이전트의 지연 구조를 분해하고, 긴 VLM 추론 시간이 기존의 순차 파이프라인에서 그대로 버려지고 있음을 정량적으로 보인다. 인식·동작은 가볍고 planning(추론)이 스텝 지연의 거의 전부를 차지한다.
- 이 유휴 추론 시간을 활용해 가볍고 병렬적인 온라인 탐색을 수행하는 MobileExplorer 프레임워크를 제안한다. 추론 횟수를 늘리지 않으면서 추가 UI 근거를 모은다는 것이 핵심 아이디어다.
- 태스크 관련성 기반 탐색(어떤 요소를 탐색할지) + 2단계 롤백(탐색 후 상태를 어떻게 되돌릴지) + 탐색-증강 추론(모은 정보를 어떻게 다음 추론에 주입할지) 세 컴포넌트를 설계한다.
- AndroidWorld 와 자체 설계한 복잡·동적 실세계 태스크에서 성공률을 유지·향상하면서 추론 스텝과 end-to-end 지연을 줄임을 실증한다.
관련 연구 / 배경 지식
모바일 GUI 에이전트의 두 갈래. 초기 시스템은 a11y tree 같은 구조화된 텍스트 표현 위에서 동작하는 LLM 기반이었다. AutoDroid 와 AutoDroid-V2 는 long-horizon 상호작용을 위해 planning 과 memory 메커니즘을, V-Droid 는 후보 UI 요소 중에서 동작을 고르는 verifier 기반 패러다임을 도입했다. 그러나 텍스트 표현은 아이콘·레이아웃·공간 관계 같은 풍부한 시각 단서를 놓친다. 그래서 CogAgent, Mobile-Agent-v3, MAI-UI, STEP-UI 처럼 스크린샷 위에서 직접 동작하는 vision-based 에이전트가 등장했고, AndroidWorld 리더보드 상위권을 비전 기반이 점령하고 있다.
온디바이스 배포 시도. AutoDroid 는 GUI 상태를 구조화된 UI transition graph 로 표현해 로컬 추론을, AutoDroid-V2 는 앱 문서와 생성된 태스크 샘플로 동작 계획을 만들어 지연을 줄였다. 하지만 이들은 텍스트·계획 prior 에 의존해 raw 스크린샷을 추론해야 하는 vision-based 에이전트에 곧장 적용되지 않는다.
오프라인 지식 베이스. GUI-explorer 는 state–action 트레이스에서 transition-aware 지식을 캐내고, LLM-Explorer 는 대규모 앱 탐색으로 UI 상태·상호작용 그래프의 재사용 가능한 저장소를 구축한다. 이들은 강력하지만 오프라인에서 수집한 트레이스나 사전 구축된 지식 베이스에 의존해, 구축 비용이 크고 동적으로 바뀌는 실제 인터페이스로의 일반화가 어렵다. MobileExplorer 의 차별점은 추론 중에 실시간으로 가벼운 온라인 탐색을 한다는 것, 오프라인 지식 구축 없이 동적 앱에 적응한다는 것이다.
동기 분석: 추론 시간은 왜 버려지는가
MobileExplorer 의 출발점은 “온디바이스 에이전트가 시간을 어디에 쓰는가”라는 측정이다. 저자들은 Samsung Galaxy S24 (12GB RAM) 에서 2B VLM (MAI-UI) 을 완전 온디바이스로 돌려, AudioRecorder 로 오디오를 녹음·저장하는 단순 태스크의 스텝별 지연을 분해했다.
결과는 명확하다. (1) 태스크 대부분이 여러 스텝을 요구하고 일부는 30 스텝을 넘는다. (2) 각 스텝의 지연은 거의 전부 planning(VLM 추론)이 차지하고, perception 과 operation 은 작은 조각에 불과하다. 즉 시스템의 비효율은 단일 느린 추론이 아니라, long-horizon 의사결정과 무거운 스텝당 추론 비용이 곱해지면서 발생한다.
여기서 저자들이 포착한 기회가 명확한 지연 불균형 (latency imbalance) 이다. UI 인식과 동작은 보통 1~2초로 가볍지만 VLM 추론은 수십 초로 무겁다. 기존 순차 파이프라인에서는 이 긴 추론이 끝나기를 기다리는 동안 기기가 그냥 놀고 있다. MobileExplorer 의 발상은 이 유휴 구간을 탐색에 쓰자는 것이다. 선택된 UI 요소를 미리 눌러 보고 화면 전이를 관찰하면, 이후 추론의 불확실성을 줄이고 trial-and-error 동작을 덜 하게 만들어 전체 궤적을 단축할 수 있다.
방법 / 아키텍처 상세
전체 구조는 부분 병렬 파이프라인이다. 스텝 $i$ 에서 VLM 은 현재 스크린샷과 태스크 설명으로 다음 동작을 추론한다. 그 추론이 도는 바로 그 시간 동안, 시스템은 현재 화면의 UI 요소를 파싱하고 태스크와의 의미 유사도를 계산해 일부 요소를 가볍게 눌러 보며 화면 전이를 관찰한다. 메인 궤적과의 일관성을 위해 탐색 트레이스를 기록하고 원래 UI 상태로 안전하게 복원한 뒤, 탐색에서 얻은 화면·UI 의미를 간결한 텍스트 힌트로 요약해 다음 추론 스텝의 프롬프트에 덧붙인다.
문제 정식화
스텝 $i$ 에서 에이전트는 현재 스크린샷 $s_i$ 를 관찰하고 태스크 설명 $\mathcal{G}$ 를 받는다. 모바일 인터페이스는 부분 관찰만 가능하므로 전체 UI 구조는 사전에 알 수 없고 상호작용으로만 드러난다. 상호작용 가능한 UI 요소 집합은 다음과 같다.
\[\mathcal{A}_i = \{a_i^{(1)}, a_i^{(2)}, \ldots, a_i^{(K_i)}\}.\]각 동작은 하나의 UI 요소와 상호작용(클릭·스크롤 등)하며 새로운 UI 상태로의 전이를 유발할 수 있다. 스텝 $i$ 의 VLM 추론 지연을 $\tau_i^{\text{vlm}}$ 라 하면, 이 시간 동안 기기는 상호작용 관점에서 유휴 상태이므로 사용자 체감 지연을 늘리지 않고 보조 동작을 수행할 여지가 생긴다. 시스템 목표는 온디바이스 지연 제약 아래 태스크 완료 확률을 최대화하는 것이다.
\[\max_\pi \; \Pr\!\big(v_N \in \mathcal{V}_{\text{goal}}(\mathcal{G})\big) \quad \text{s.t.} \quad \sum_i \tau_i^{\text{interact}} \le T,\]여기서 $T$ 는 지연 예산, $\pi$ 는 상호작용 정책이다. MobileExplorer 는 유휴 추론 지연을 활용해 가벼운 온라인 탐색을 수행하되, 전체 실행 지연을 늘리지 않는 것을 설계 제약으로 둔다.
태스크 관련성 기반 탐색
탐색은 두 가지 제약을 동시에 만족해야 한다. 첫째, 각 스텝의 VLM 추론 지연 안에서만 동작해 추가 지연을 만들지 않아야 한다. 따라서 UI 그래프 전체를 훑는 것은 불가능하고, 어떤 상호작용이 가장 유익한지 골라야 한다. 둘째, 이미 탐색한 UI 분기를 반복하지 않아야 한다.
후보를 가볍게 뽑기 위해, 탐색 모듈은 vision-based 파싱보다 훨씬 가벼운 a11y tree 를 활용한다. 스텝 $i$ 시작 시 현재 화면 $s_i$ 의 a11y tree 를 파싱해 클릭 가능한 요소 집합 $\mathcal{A}_i = {a_i^{(1)}, \ldots, a_i^{(K_i)}}$ 을 얻고, 각 요소 $a_i^{(k)}$ 를 가벼운 텍스트 표현(text label, content description, resource identifier)으로 변환한다. 그다음 가벼운 텍스트 임베딩 모델로 각 요소와 태스크 설명을 의미 벡터로 인코딩해 코사인 유사도로 태스크 관련성 점수를 구한다.
\[r\!\left(a_i^{(k)}\right) = \mathrm{sim}\!\left(e\!\left(a_i^{(k)}\right),\, e(\mathcal{G})\right),\]여기서 $e(\cdot)$ 는 가벼운 텍스트 임베딩 모델, $\mathrm{sim}$ 은 코사인 유사도다. 예를 들어 웹 검색 태스크에서는 브라우저를 여는 요소가 높은 점수를 받는다. 반복 탐색을 막기 위해 탐색 히스토리 $\mathcal{H}_i$(이전에 방문한 UI 요소 집합)를 도입해 최종 탐색 우선순위를 정의한다.
\[S\!\left(a_i^{(k)}\right) = r\!\left(a_i^{(k)}\right) - \lambda \cdot \mathbb{1}\!\left[a_i^{(k)} \in \mathcal{H}_i\right],\]여기서 $\lambda$ 는 이미 탐색한 요소의 재방문을 억제하는 패널티 가중치다. 탐색 컨트롤러는 $S(\cdot)$ 의 내림차순으로 후보를 프로브한다. 각 프로브는 클릭 한 번과 그 결과 화면 전이의 관찰로 이루어지며, 깊이 $d$ 까지 순차적으로 진행하다 원래 UI 상태로 돌아온다. 각 프로브가 짧고 깊이가 제한되므로 같은 추론 윈도우 안에 여러 프로브를 끼워 넣을 수 있다.
2단계 롤백: 탐색이 본 상태를 망가뜨리지 않게
시뮬레이터에서의 오프라인 탐색은 환경 상태를 자유롭게 복제·복원할 수 있다. 그러나 MobileExplorer 는 실제 라이브 기기에서 동작하므로, 탐색 동작 하나하나가 실제 UI 상태를 바꾼다. 상태 복원이 불완전하면 추론이 내려진 화면에서 시스템이 멀어져 일관성 없는 실행으로 이어진다.
단순 backtracking 이 부족한 이유는 두 가지다. 첫째, 많은 UI 전이는 진짜 역연산이 없다. back 동작이 다이얼로그를 닫거나 키보드를 내리거나 중간 화면을 건너뛰어, 정확한 이전 상태로 되돌아가지 못한다. 둘째, 같은 내비게이션 경로를 따라가도 비동기 업데이트(알림 배너, 동적 콘텐츠)로 화면이 달라질 수 있다. 그래서 사소한 시각 변화는 허용하면서도 올바른 UI 컨텍스트로 돌아가게 하는 강건한 롤백이 필요하다.
Level-1: 깊이 제한 backtracking. 탐색은 시작 화면 $s_i$ 에서 깊이 $d$ 까지만 진행한다. 시작 화면의 perceptual hash 를 다음처럼 기록한다.
\[H_0 = H(s_i),\]여기서 $H(\cdot)$ 는 pHash 함수다. a11y tree 를 다시 가져오는 것보다 스크린샷 캡처가 훨씬 빠르고, perceptual hash 는 동적 요소로 인한 사소한 시각 차이를 견디면서 화면 간 효율적 비교를 가능케 한다. 탐색 분기를 마친 뒤 에이전트는 back 을 최대 $d$ 번 발행해 이전 화면들로 돌아오고, 각 롤백 스텝 $k$ 마다 현재 화면 $s_{r_k}$ 를 캡처해 시작 화면과 대조한다.
여기서 $d_H(\cdot)$ 는 두 perceptual hash 의 Hamming distance, $\tau$ 는 스크롤 오프셋·동적 콘텐츠 같은 사소한 변화를 허용하는 임계값이다. 이 조건이 성립하면 원래 UI 상태가 성공적으로 복원되었다고 판단한다.
Level-2: home-and-replay 복구. Level-1 이 실패하면(되돌릴 수 없는 UI 전이나 내비게이션 불일치 등) 결정적 복구로 폴백한다. 예컨대 탐색 중 사전에 없던 확인 다이얼로그나 권한 프롬프트가 떴다면, back 이 그 다이얼로그를 닫는 게 아니라 더 앞 화면으로 가버릴 수 있다. 이때는 시작 상태로 이끈 상호작용 트레이스를 활용한다.
여기서 $a_k$ 는 스텝 $k$ 에서 실행된 동작이다. 에이전트는 먼저 홈 화면으로 돌아간 뒤 기록된 트레이스 $\Pi_i$ 를 결정적으로 재생해 UI 상태 $s_i$ 를 재구성한다. 실전에서 탐색 깊이가 작으므로 재생 시퀀스는 짧고, VLM 추론 지연에 비하면 오버헤드는 무시할 만하다.
전체 탐색·롤백 절차는 Algorithm 1 로 정리된다.
Algorithm 1: Exploration with Rollback
Require: 태스크 G, 시작 화면 s_i, 클릭 가능 집합 A_i, 깊이 d, 예산 τ_i, 임계값 δ
Ensure: 탐색 힌트 C_i 와 복원된 UI 상태 s_i
1: C_i ← ∅
2: H_0 ← H(s_i) # 시작 화면의 pHash 계산
3: A_i^cand 를 G 와의 의미 유사도로 순위화
4: for all a ∈ A_i^cand within τ_i do # 추론 예산 안에서
5: a 와 상호작용하며 깊이 d 까지 전이 탐색
6: 발견한 화면/요소를 C_i 에 기록
7: back 을 d 번 발행 (Level-1 롤백)
8: 현재 화면 s' 캡처
9: H' ← H(s')
10: if d_H(H', H_0) > δ then
11: 홈으로 가서 추론 트레이스 Π_i 재생 (Level-2 복구)
12: end if
13: end for
14: return C_i
핵심은 일반적인 경우 빠른 Level-1 경로로 처리하고, 비결정적 UI 동작이 일어나는 예외에서만 Level-2 가 정확성을 보장한다는 점이다. 덕분에 메인 의사결정 궤적을 영구히 바꾸지 않으면서 대체 UI 분기를 안전하게 탐색할 수 있다.
탐색-증강 추론: 모은 정보를 다음 추론에 주입
탐색은 추론 결정이 확정되기 전에 수행되므로, 실행된 추론 동작이 탐색 때와 다른 화면으로 데려갈 수 있다. 모든 탐색 결과를 무차별로 프롬프트에 넣으면 관련 없는 정보가 들어가 추론 지연만 늘어난다. 그래서 다음 단계를 거친다.
탐색 관찰 기록. 방문한 각 화면은 스크린샷의 perceptual hash 와 a11y tree 에서 파싱한 UI 요소로 이루어진 간결한 관찰로 저장된다. 큰 메모리 없이 화면 식별성과 UI 구조를 담는다.
스텝 정렬 (step alignment). 추론 동작이 실행되어 에이전트가 화면 $s_{i+1}$ 에 도달하면, 현재 화면의 perceptual hash 를 계산해 시각 구조가 비슷한 탐색 관찰만 골라낸다.
\[O_i^{\text{match}} = \{\, o_j \in O_i \mid d(h_{i+1}, h_j) < \delta \,\},\]여기서 $d(\cdot)$ 는 perceptual hash 간 Hamming distance다. 이 단계는 현재 상태와 무관한 UI 상태에 대응하는 탐색 결과를 걸러낸다.
UI 요소 선택. 정렬된 화면에도 서로 다른 앱·동작에 대응하는 요소가 여럿 남을 수 있다. 각 요소에 대해 다시 태스크 관련성 점수(앞의 의미 유사도)를 계산해, 높은 점수만 힌트 구성에 쓰고 나머지는 걸러낸다.
힌트 생성. 선택된 요소로부터, 잠재적으로 유용한 UI 위치를 묘사하는 간결한 텍스트 힌트를 만든다. 이 힌트가 탐색 컨텍스트 $C_i$ 가 되어 다음 추론 스텝의 프롬프트에 덧붙는다. 결국 VLM 은 현재 스크린샷·태스크 지시·탐색 컨텍스트로 이루어진 증강 입력 위에서 추론하되, 추론 입력 자체는 온디바이스 배포에 알맞게 작고 관련성 높은 상태로 유지된다.
학습 데이터와 파이프라인
이 논문은 모델을 새로 학습시키는 연구가 아니라, 기성 VLM 을 그대로 두고 추론·탐색 파이프라인을 재설계하는 시스템 연구다. 따라서 학습 데이터나 fine-tuning 절차는 없고, 평가 환경과 배포 구성이 핵심이다.
| 구성 요소 | 내용 |
|---|---|
| 벤치마크 | AndroidWorld (116개 태스크, 20개 실제 Android 앱). 난이도: Easy 61개(52.6%), Medium 36개(31.0%), Hard 19개(16.4%) |
| 기본 모델 | 4B VLM (baseline 도 4B VLM/LLM 기반). 모델 크기 스케일링 실험에는 MAI-UI 2B·8B 사용 |
| 양자화·서빙 | llama.cpp + Q8 양자화, vLLM 프레임워크로 서빙. 스마트폰에서는 Termux 안에서 llama.cpp 실행 |
| 평가 기기 | Samsung Galaxy S24 (CPU/GPU/NPU, 12GB), NVIDIA Jetson AGX Orin (CPU/GPU, 64GB), MacBook Air M4 (CPU/GPU, 24GB) |
| 실행 구성 | dual-device: 에뮬레이터가 UI 동작을 실행, 모델 추론은 대상 하드웨어(폰·Jetson·노트북)에서. HTTP 로 통신해 실제 온디바이스 지연을 측정 |
| 임베딩 모델 | 요소·태스크 인코딩에 가벼운 텍스트 임베딩 모델 사용 |
baseline 은 네 가지다. (1) M3A: 현재 화면을 VLM 으로 순차 추론하는 기본 vision-based 에이전트. (2) T3A: a11y tree 에 의존해 LLM 으로 단계별 추론하는 텍스트 에이전트. (3) Input-pruning VLM agent: 스크린샷·토큰 pruning 으로 시각 토큰 오버헤드를 줄이는 에이전트. (4) Offline exploration agent: 오프라인 탐색으로 지식을 구축하는 에이전트. 추가로 AndroidWorld 리더보드의 기존 결과들과도 비교한다.
평가 지표는 success rate(정해진 스텝 예산 안에서 완료한 태스크 비율), total steps(완료에 필요한 상호작용 스텝 수), latency(스텝 지연 = 스크린샷 캡처부터 동작 실행 완료까지; end-to-end 지연 = 태스크 전체 완료 시간), 그리고 CPU·메모리·전력 오버헤드다.
실험 결과
AndroidWorld 전체 성능
완전 온디바이스 설정에서 MobileExplorer 는 성공률 50.86% (59/116 태스크) 를 기록한다. 같은 4B VLM 기반 baseline M3A 의 46.55% 대비 +4.31%p, 상대적으로 9.3% 향상이다. 지연 제약 안에서 온라인 탐색을 추론에 통합하면 더 유용한 UI 컨텍스트를 얻어 더 나은 의사결정을 한다는 뜻이다.
효율 측면에서도 MobileExplorer 는 평균 9.24 스텝으로 태스크를 끝내, M3A 의 10.93 스텝 대비 15.5% 적다. 동작 횟수가 줄면 trial-and-error 가 줄고, 이는 다시 end-to-end 지연 감소로 이어진다. Figure 8(a) 에서 MobileExplorer(별표)는 가장 높은 성공률과 가장 낮은 end-to-end 지연을 동시에 차지하는 좌상단에 위치한다.
리더보드 비교에서도 강하다. AndroidWorld 에서의 성공률을 보면:
| Method | AndroidWorld (%) |
|---|---|
| MobileGPT | 23.0 |
| AutoDroid-V2 | 26.0 |
| M3A (a11y, GPT-4-Turbo) | 30.6 |
| M3A (a11y, Gemini-2.5-Pro) | 31.0 |
| M3A (SoM, GPT-4-Turbo) | 25.4 |
| M3A (SoM, Gemini-2.5-Pro) | 39.7 |
| GLM-4.1V-9B-Thinking | 41.7 |
| UI-TARS (UI-TARS-7B) | 33.0 |
| MobileExplorer | 50.9 |
주목할 점은 MobileExplorer 가 GPT-4-Turbo·Gemini-2.5-Pro 같은 거대 클라우드 모델을 백본으로 쓴 M3A 변종들조차 앞선다는 것이다. 작은 온디바이스 모델 위에서 탐색-증강이 만들어 내는 이득이 모델 규모 차이를 일부 메운다.
실세계 케이스 스터디
AndroidWorld 태스크는 비교적 단순하다(화면당 평균 약 19.75개 요소). 저자들은 실세계 모바일 환경의 세 가지 어려움을 별도 태스크로 설계했다. (1) 복잡한 UI 요소: Trip 앱의 도시 여행 계획 태스크 — 화면당 평균 48개 요소(AndroidWorld 의 2배 이상). (2) 팝업 간섭 요소: Notes 앱에 텍스트 입력 중 알람·메시지·전화·앱 알림 같은 인터럽트 주입. (3) 리소스 동적 변화: 영상·음악 재생 같은 백그라운드 작업이 도는 와중에 시스템 설정(Bluetooth, WiFi) 변경.
이 시나리오에서 MobileExplorer 는 평균 185.82초에 태스크를 완료해 M3A 대비 전체 지연을 15.9% 줄인다. 중요한 건 이 개선이 스텝당 추론 오버헤드를 늘리지 않고 — 탐색이 유휴 추론 시간에 병렬로 일어나므로 — 달성된다는 점이다. 세 가지 복잡 설정 모두에서 성공률은 비등하거나 더 높고 end-to-end 지연은 일관되게 낮으며, 인터럽트와 동적 리소스 조건에서도 강건함을 보인다.
참고로 abstract 와 intro 는 이 시스템의 효과를 “추론 스텝과 end-to-end 지연을 약 23% 감소, 성공률은 최대 5% 향상” 으로 요약한다. 본문 §6.2 의 구체 수치(스텝 −15.5%, 케이스 스터디 지연 −15.9%, 성공률 +4.31%p)와는 다소 차이가 있어, 헤드라인 23% 가 어떤 비교·집계 기준인지는 본문에 명시되지 않는다. 리뷰어 입장에서는 §6.2 의 측정값을 1차 근거로 보는 게 안전하다.
결과 분석 / Ablation
컴포넌트 ablation (Figure 12a). 세 컴포넌트를 하나씩 무력화해 본다.
- 태스크 관련성 선택 → 랜덤 탐색: 50.9% → 42.2% (−8.7%p). 랜덤 탐색은 제한된 추론 윈도우 안에서 태스크와 무관한 요소를 누르는 경우가 많아 정보가 덜 모인다.
- 2단계 롤백 제거: 50.9% → 39.7% (−11.2%p). 가장 큰 하락이며 end-to-end 지연도 늘어난다. 탐색이 원래 UI 상태로 돌아오지 못해 추론이 엉뚱한 화면에서 진행되기 때문이다. 즉 “안전하게 되돌리는 능력”이 탐색의 전제조건이다.
- 탐색 정렬(step alignment) 비활성화: 50.9% → 47.4% (−3.5%p). 걸러지지 않은 탐색 관찰이 프롬프트에 들어가 잘못된 정보를 주입한다.
세 결과를 합치면, 탐색이 성능에 기여하려면 (1) 무엇을 탐색할지 태스크 관련성으로 고르고, (2) 탐색 후 상태를 신뢰성 있게 복원하고, (3) 현재 추론 컨텍스트와 정렬된 정보만 주입해야 한다는 것이 드러난다. 특히 롤백이 빠지면 탐색이 오히려 독이 된다는 점이 인상적이다.
태스크 카테고리별 (Figure 12b). MobileExplorer 는 complex UI understanding, search, information retrieval 처럼 시각적으로 복잡하고 후보 요소가 많은 태스크에서 일관되게 향상된다. 반면 data entry, data edit 처럼 결정적 동작 시퀀스에 의존하는 구조적 태스크에서는 M3A 보다 살짝 낮다. 탐색의 이득이 “어느 요소가 관련 있는지 후보가 많아 헷갈리는” 상황에서 크다는 직관과 맞는다.
2단계 롤백 효과 (Figure 12c). UI 페이지를 클릭 가능 요소 수에 따라 Simple/Medium/Complicated 로 나눠 롤백 이벤트를 분석하면, Level-1 이 대부분을 처리하고, 복잡한 페이지일수록 Level-2 의 비중이 높아진다. 더 깊고 덜 가역적인 내비게이션에서 단순 backtracking 이 실패하기 쉽기 때문이다. 그럼에도 전체 롤백 성공률은 모든 카테고리에서 일관되게 높아, Level-2 가 Level-1 을 효과적으로 보완함을 보여 준다.
탐색-증강 추론 효과 (Figure 12d). UI 복잡도가 커질수록 hint-follow rate(추론이 힌트를 실제로 따른 비율)가 높아지고, hint-follow rate 가 높은 태스크일수록 성공률이 높다. 후보 요소가 많은 인터페이스에서 탐색 힌트가 특히 유용한 길잡이가 된다는 뜻이다.
모델 크기·해상도 (Figure 13). MAI-UI 2B·8B 로 크기를 바꿔도 MobileExplorer 는 성공률을 비등하게 유지하면서 평균 스텝을 줄여(태스크당 약 한 스텝 절약) end-to-end 지연을 낮춘다. 해상도(270×600, 540×1200, 1080×2400)는 높을수록 대체로 성공률이 오르지만, MobileExplorer 는 중간 해상도에서 최고 성능을 내고 모든 설정에서 M3A 보다 적은 스텝을 쓴다. 시각 충실도와 상호작용 효율의 균형점이 중간 해상도라는 관찰이다.
시스템 오버헤드 (Figure 14, 15). 폰·Jetson·노트북 모두에서 MobileExplorer 는 end-to-end 지연을 줄이면서 메모리·전력은 baseline 과 거의 동일하다. 컴포넌트별로 보면 추가 제어 로직은 스텝당 수십 ms 수준으로, 수 초짜리 VLM 추론에 비하면 무시할 만하다. 가장 큰 지연은 스크린샷 기반 상태 검증을 하는 롤백 검증이고, 탐색과 요소 선택은 가볍다.
한계와 비판적 평가
- 저자 인정 한계. 향후 과제로 태스크 요구와 UI 복잡도에 따라 탐색 경로를 동적으로 조절하는 적응형 전략, 그리고 UI 탐색과 모델 추론 사이의 더 정교한 상호작용을 든다. 현재의 탐색 깊이 $d$·예산 $\tau_i$·패널티 $\lambda$ 는 고정 하이퍼파라미터다.
- 헤드라인 수치와 본문 수치의 불일치. abstract 의 “약 23% 감소”와 §6.2 의 스텝 −15.5%·케이스 스터디 지연 −15.9% 가 다르고, 23% 가 어떤 비교 기준에서 나온 값인지 본문에 명확히 정의되지 않는다. 독자가 효과 크기를 가늠하기 어렵다.
- 탐색이 a11y tree 에 의존. 후보 선택과 탐색은 vision-based 가 아니라 a11y tree 파싱에 기댄다. a11y tree 가 부실하거나 비표준 위젯이 많은 앱(게임, 커스텀 렌더링 UI)에서는 후보 품질이 떨어질 수 있는데, 이런 조건에서의 성능은 보고되지 않는다.
- 롤백의 신뢰성 비용. 가장 큰 지연 원천이 롤백 검증이고, 복잡 페이지에서 Level-2(홈 복귀 후 트레이스 재생) 비중이 커진다. Level-2 가 빈번해지는 극단적 동적 환경에서 “재생이 정말 같은 상태를 복원하는가”에 대한 정량적 실패율·복원 정확도 보고가 부족하다.
- 통계적 유의성. 성공률·지연 수치에 분산이나 신뢰구간이 제시되지 않아, 50.86% vs 46.55% 같은 차이가 실행 간 변동을 넘어서는지 판단하기 어렵다. 케이스 스터디는 각 태스크 3회 반복이라 표본이 작다.
- 재현성. 소스 코드는 “논문 채택 후 공개” 예정이라 현재 미공개이고, “4B VLM” 의 정확한 정체(어떤 모델인지)도 본문에서 다소 모호하게 표기된다.
시사점 / Takeaways
- 유휴 시간은 자원이다. 온디바이스 GUI 에이전트의 병목이 “느린 단일 추론”이 아니라 “느린 추론의 반복적 누적”임을 명확히 진단하고, 그 사이 비어 있는 시간을 탐색으로 채운다는 발상이 깔끔하다. 추론 횟수를 늘리지 않고 정보만 더 모은다는 제약이 설계 전체를 관통한다.
- 탐색은 되돌릴 수 있을 때만 가치가 있다. ablation 에서 롤백 제거가 가장 큰 성능 하락을 일으킨다는 것은, 라이브 환경 탐색의 핵심이 “무엇을 보느냐”가 아니라 “본 다음 안전하게 되돌아오느냐”임을 보여 준다. perceptual hash + home-and-replay 의 2단계 설계는 실용적 엔지니어링 해법이다.
- 탐색의 이득은 복잡한 인터페이스에 집중된다. 요소가 많고 후보가 헷갈리는 화면(검색·정보 탐색)에서 크게 이기고, 결정적 시퀀스 태스크에서는 오히려 약간 손해다. “탐색이 항상 좋다”가 아니라 “불확실성이 클 때 좋다”는 조건부 결론이 더 정직하다.
- a11y tree 와 비전의 역할 분담. 무거운 비전 추론은 메인 의사결정에, 가벼운 a11y tree 파싱은 후보 탐색에 쓰는 비대칭 설계가 온디바이스 제약에 잘 들어맞는다. 두 모달리티를 비용에 따라 나눠 쓰는 패턴은 다른 온디바이스 에이전트에도 이식 가능하다.
참고 자료
- 논문: https://arxiv.org/abs/2605.26546
- 데모 영상: https://youtu.be/thK7MJmdlvM
- 벤치마크: AndroidWorld
더 읽어보기
- AndroidWorld: A Dynamic Benchmarking Environment for Autonomous Agents (Rawles et al., 2024) — 본 논문의 평가 기반이자 M3A·T3A baseline 의 출처. 116개 태스크를 동적으로 파라미터화하는 라이브 Android 환경.
- Mobile-Agent-v3: Fundamental Agents for GUI Automation (Ye et al., 2025) — GUI-Owl 백본과 멀티 에이전트 프레임워크로 AndroidWorld 73.3 을 기록한 오픈소스 SOTA.
- UI-TARS-2 Technical Report (Wang et al., 2025) — 멀티턴 RL 로 학습한 네이티브 GUI 에이전트. 본 논문의 UI-TARS baseline 의 후속.
- AutoDroid-V2: Boosting SLM-based GUI Agents via Code Generation (Wen et al., 2025) — UI 태스크를 코드 생성 문제로 바꿔 온디바이스 SLM 으로 푸는 접근. 온디바이스 지연·토큰을 크게 줄인다.
- GUI-explorer: Autonomous Exploration and Mining of Transition-aware Knowledge for GUI Agent (Xie et al., ACL 2025) — 오프라인 탐색으로 transition-aware 지식을 캐는 training-free 에이전트. MobileExplorer 의 온라인 탐색과 대비되는 오프라인 baseline.
Enjoy Reading This Article?
Here are some more articles you might like to read next: