복합 실세계 작업을 평가하는 모바일 에이전트 벤치마크

왜 중요한가

모바일 에이전트의 성공은 화면을 클릭하는 능력만으로 결정되지 않고, 사용자 기억 검색, API 호출, Skill 실행, Sub-agent 위임을 오류가 있는 운영체제 환경에서 올바른 순서로 조합하는지에 달려 있습니다. MobilePA-Bench는 1,705개 작업과 212개 도구를 실제 상태 변화와 구조화된 피드백이 있는 샌드박스에서 실행해 이 복합 신뢰성을 측정합니다. 최고 Overall 점수도 75.52%에 그쳐, 모바일 에이전트가 자율 실행에 이르려면 개별 기능보다 상태 인식과 단계 간 조정 능력을 함께 개선해야 함을 나타냅니다.

관련 Figure

Chart
안쪽 고리는 Work, Study & Productivity 12.9%, Entertainment & Media 12.2%, Communication & Social 10.4%, Apps·Data & Security 9.0% 등 상위 영역의 비중을 표시합니다. 바깥 고리는 Meeting Scheduling, Calendar & Tasks, Message Composition & Sending, Navigation & Routes 같은 세부 기능으로 확장되며, 이 분류는 1,705개 평가 분모와 별도의 descriptive snapshot입니다.
1,530개 시나리오 분류 query를 13개 상위 모바일 영역과 89개 하위 기능 범주로 나눈 계층형 sunburst 차트입니다.

핵심 기여

복합 모바일 작업을 위한 통합 벤치마크

MobilePA-Bench는 13개 기능 영역의 212개 모바일 도구와 1,705개 실세계 작업을 하나의 평가 체계로 묶었다. Basic Tool Use, Sub-agent Collaboration, Memory Usage, Skill Usage를 서로 다른 작업 설계와 검증 gate로 측정한다. 이 구성은 단순 함수 문자열 일치와 화면 조작만으로는 포착하기 어려운 장기 실행 실패를 드러낸다.

상태 유지형 모바일 실행 샌드박스

샌드박스는 Tool Schema, 실행 구현 코드, 영속 Tool Database를 연결해 호출마다 데이터베이스와 Operation_logs를 갱신한다. 실행기는 필수 인자 누락, 권한 차단, 중복 엔터티 같은 마찰을 적용하고 Status, ErrorType, Payload 형태의 피드백을 반환한다. 에이전트는 이 피드백을 대화 이력에 누적하며 다음 행동을 다시 선택한다.

완료 증거에 맞춘 세 가지 검증 기준

작업의 의미에 따라 정확한 도구와 인자를 검사하는 Tool Call, 최종 데이터베이스 차이를 검사하는 State Change, 위임과 후속 대화를 검사하는 Agent Behavior를 사용한다. Memory 검색과 Skill 로딩이 필요한 작업에는 요구된 기록이나 Skill을 실제로 호출했는지 별도 gate를 적용한다. 이 방식은 여러 유효 경로가 있는 작업을 과도하게 실패 처리하지 않으면서도 불필요한 부작용 호출을 거부한다.

모바일 Planner의 병목과 진단 기반 제공

13개 LLM을 비교한 결과 최고 Overall은 Claude-Opus-5의 75.52%였고 13개 모델 중 7개가 70% 미만이었다. Basic Tool Use 평균은 76.58%였지만 Memory Usage 평균은 50.98%로 낮았으며, 모델별 강점도 서로 달랐다. 전체 작업, 데이터셋, 고처리량 샌드박스를 공개해 이후 agentic reinforcement learning과 오류별 개선에 활용할 기반을 마련했다.

핵심 아이디어 이해하기

일반적인 LLM 도구 사용 평가는 모델이 올바른 함수 이름과 JSON 인자를 출력하는지만 보는 경우가 많고, GUI 벤치마크는 화면의 좌표와 픽셀 조작에 집중합니다. 그러나 모바일 요청은 사용자의 저장된 선호도를 먼저 찾고, 여러 API를 선행 조건에 맞춰 호출하며, 실행 중 권한 오류나 데이터 충돌에 대응해야 완료됩니다. MobilePA-Bench는 중앙 Planner가 고수준 결정을 맡고 GUI나 시각 처리는 필요한 경우에만 Sub-agent로 넘기는 구조를 채택합니다.

각 단계에서 Planner는 요청 q, 지금까지의 이력 Hₜ, 사용 가능한 도구 집합 Aₜ를 입력으로 받아 다음 행동을 선택합니다. 이 선택은 $a_t = \pi(q, H_t, A_t)$ 로 표현되며, q는 사용자 의도, Hₜ는 이전 행동과 피드백의 누적, Aₜ는 현재 호출 가능한 함수 스키마입니다. 샌드박스는 선택된 행동을 실행해 새 상태와 피드백을 만들고, Planner는 그 결과를 이력에 추가한 뒤 다음 행동을 결정합니다.

기존 정적 평가와 달리 이 과정의 출력은 함수 문자열 하나가 아니라 실제 데이터베이스 변화, 오류 응답, 최종 상호작용 궤적입니다. 예를 들어 연락처 추가 호출은 이름과 전화번호를 검사하고, 중복이나 필수값 누락을 확인한 다음 새 ID와 timestamp를 저장하며 실행 로그를 남깁니다. 따라서 같은 함수명을 출력했더라도 잘못된 인자, 잘못된 호출 순서, 권한 위반, 무관한 데이터 변경이 있으면 실패로 처리됩니다.

장기 작업에서는 모든 세부 단계를 매번 생성하지 않고 Skill loader를 호출할 수 있습니다. Skill을 불러오면 해당 Skill의 실행 도구가 Aₜ에 추가되고, Planner는 확장된 선택지에서 후속 호출을 수행합니다. 또한 모호한 요청에는 Memory 검색으로 필요한 기록을 회수해야 하며, 구조화된 API가 없는 단계는 GUI Sub-agent에 맥락을 포함해 위임해야 하므로 단일 도구 정확도만으로는 전체 성공을 보장할 수 없습니다.

관련 Figure

Diagram
그림 왼쪽은 자연어 요청에서 여행 계획을 만들고 사용자 승인 뒤 항공·숙박 예약을 실행하는 대화를 보여줍니다. 오른쪽은 같은 작업을 Memory Retrieval, Skills Execution, Basic Tool Use, GUI Agent Collaboration으로 나누어, 하나의 장기 작업이 네 가지 능력을 순차적으로 결합한다는 점을 나타냅니다.
사용자가 상하이 여행을 요청하자 에이전트가 Memory에서 베이징 출발지와 Hilton 선호, 박물관 선호를 회수하고 항공편과 호텔을 예약한 뒤 QR 코드로 박물관 티켓을 예약하는 흐름을 담은 그림입니다.

방법론

MobilePA-Bench의 작업은 사용자 의도 q, 초기 실행 상태 S₀, 선택적 대화 이력 H₀, 초기 후보 행동 집합 A₀로 정의됩니다. 각 단계에서 Planner는 q, Hₜ, Aₜ를 입력받아 $a_t = \pi(q, H_t, A_t)$ 를 출력하고, 실행기는 $(S_{t+1}, f_t) = Exec(S_t, a_t)$ 를 계산합니다. 여기서 Sₜ는 데이터베이스 Dₜ와 실행 로그 Oₜ의 쌍이고, fₜ는 Status, ErrorType, Payload를 포함하는 구조화된 피드백입니다.

초기 action space는 질의와 이력에 맞춰 회수한 상위 N개 도구와 해당 질의에 가능한 Skill loader의 합집합으로 구성되며, 실험에서는 N=15를 사용했습니다. Planner가 Skill loader s를 호출하면 다음 단계의 선택지는 $A_{t+1}=A_t\cup G(s)$ 로 확장되고, G(s)는 해당 Skill에 연결된 구체적 도구 스키마 집합입니다. 실행은 Finish 행동이 나오거나 최대 단계 $T_{max}=15$ 에 도달할 때까지 이어지며, 매 단계의 행동과 피드백이 Hₜ에 누적됩니다.

샌드박스는 세 가지 실행 마찰을 넣어 실제 환경의 오류를 재현합니다. 필수 인자 누락과 권한 제한은 호출 자체를 실패시킬 수 있고, 중복 엔터티나 변경된 상태는 이전 단계와 다른 결과를 만들 수 있으며, Planner는 반환된 ErrorType을 읽고 재계획해야 합니다. 시각 렌더링 대신 구조화된 데이터베이스를 직접 갱신하므로 실행을 빠르게 반복하고 동일 궤적을 재생할 수 있습니다.

검증은 작업 의미에 따라 고정된 세 bucket으로 나뉩니다. Tool Call은 도구명, 호출 순서, 필드와 정규화된 인자를 정답과 비교하고, State Change는 $D_T-D_0$ 로 표현되는 초기 상태와 최종 상태의 데이터베이스 차이를 목표 변화와 비교하며, Agent Behavior는 올바른 Sub-agent 경로와 사용자에게 제시한 후속 행동을 평가합니다. Memory와 Skill 작업은 기본 checker가 통과하면서 요구된 Memory ID 또는 정답 Skill도 호출해야 성공합니다.

관련 Figure

Diagram
상단 Planner는 전화, 캘린더, Memory, GUI Agent, 검색, 항공권 예약 같은 이질적인 기능을 통합합니다. 하단에서는 Tool Call, Parameter Validation, Tool Execution, Result Return이 실행되고 모바일 환경의 State Update와 Observation이 다시 Planner로 돌아가 폐쇄 루프를 형성합니다.
Mobile Planner Agent가 Basic Tool Use, Memory Usage, Sub-Agent Collaboration, Skill Usage를 통해 모바일 환경과 Tool Executor를 연결하는 전체 구조도입니다.

Diagram
실행 단계에서 행동은 $a_t=\pi(q,H_t,A_t)$ 로 선택되고 샌드박스는 $(S_{t+1},f_t)=Exec(S_t,a_t)$ 를 계산합니다. 종료 후 trajectory, 최종 상태, 도구 호출을 Query Bucket에 따라 Tool Call Verification, State Change Verification, Agent Behavior Verification으로 각각 검사합니다.
질의와 후보 도구, 이력을 입력으로 받아 Mobile Planner Agent가 행동을 선택하고 Stateful Mobile Sandbox가 상태와 피드백을 갱신하는 실행 및 검증 절차도입니다.

Diagram
Bucket 1은 정확한 도구와 인자를 검사하고, Bucket 2는 최종 환경 상태의 올바른 변화 여부를 검사하며, Bucket 3은 적절한 Sub-agent 호출과 후속 상호작용을 검사합니다. 예시로 Memory 검색 후 비서에게 메시지를 보내는 작업, 집중 모드 상태를 바꾸는 작업, 식당을 찾고 사용자에게 선택지를 묻는 작업이 각 기준에 배치됩니다.
Memory와 모바일 환경에서 수행된 작업을 Tool Call, State Change, Agent Behavior 세 가지 Query Bucket으로 분류하고 각각의 성공 증거를 연결한 도식입니다.

주요 결과

13개 모델을 1,705개 작업, 212개 도구, 13개 기능 영역에서 비교한 결과 Claude-Opus-5가 Overall 75.52%로 가장 높았습니다. 이 점수는 Basic Tool Use 83.85%, Sub-agent Collaboration 62.92%, Memory Usage 58.51%, Skill Usage 78.00%를 고정 가중치 50/10/20/20으로 합산한 값이며, 전체 모델 중 7개는 70% 아래에 머물렀습니다. 최고 모델도 최소 24.48%의 실패율을 남겨, 엄격한 호출 순서와 런타임 오류가 전체 성공을 제한했습니다.

Basic Tool Use는 13개 모델 평균 76.58%로 가장 강했지만, 최고 모델도 1,040개 중 872개만 성공해 168개 작업에서 실패했습니다. Memory Usage는 평균 50.98%였고, Qwen-3.8-Max가 376개 중 243개인 64.63%로 가장 높았습니다. 이 지표는 Memory ID를 찾는 것만이 아니라 검색 결과를 후속 인자와 상태 변화에 정확히 반영해야 통과하므로, 개인화된 실행이 직접 API 호출보다 어려웠습니다.

Skill Usage는 SOR와 MTSR를 합친 400개 trajectory 기준으로 Claude-Opus-5가 312개, 78.00%를 기록했고 Kimi-K3는 306개, 76.50%, Qwen-3.8-Max는 305개, 76.25%였습니다. 미리 묶인 절차가 원자적 도구를 처음부터 나열하는 부담을 줄였지만, 정답 Skill을 선택하지 못하거나 Skill 이후의 도구 순서를 틀리면 성공으로 이어지지 않았습니다. Sub-agent Collaboration은 Gemini-3.1-Pro가 77.53%로 가장 높았으나 Memory Usage는 48.67%에 그쳐, 한 모델이 모든 능력을 동시에 지배하지는 않았습니다.

동일 조건에서 Qwen3.6-27B를 세 번 실행했을 때 Overall은 57.22%에서 57.63% 사이였고 표준편차는 0.22%였습니다. Sub-agent Collaboration의 범위는 2.25점으로 가장 컸지만 89개 작업 중 두 작업의 해결 차이에 해당했고, 전체 점수 가중치가 10%여서 집계 영향은 약 0.23점이었습니다. 이 결과는 모델 생성의 확률성에도 벤치마크 순위와 실패 진단이 비교적 안정적임을 뒷받침합니다.

기술 상세

MobilePA-Bench는 중앙 Planner와 실행 환경을 분리하지만, 실행 결과를 즉시 다음 의사결정에 되돌립니다. 직접 모바일 도구, Sub-agent 진입점, Memory 검색, Skill loader가 모두 함수 이름과 JSON argument schema를 가진 동일한 action interface를 사용합니다. 이 통일된 표현은 Planner가 호출 대상뿐 아니라 인자, 위임 지시, 검색어, Skill 선택을 하나의 sequential decision 문제로 처리하게 만듭니다.

상태는 $S_t=\langle D_t,O_t\rangle$ 로 표현되며, Dₜ는 연락처나 캘린더 같은 현재 애플리케이션 데이터베이스이고 Oₜ는 실행 감사 로그입니다. 도구 호출이 입력으로 들어오면 실행 코드는 필수 필드와 제약을 검사하고, 통과한 경우 Dₜ를 갱신하고 Oₜ에 호출을 추가한 뒤 $f_t=\langle Status, ErrorType, Payload\rangle$ 를 반환합니다. 예를 들어 add_contact는 name과 phoneNumber를 받아 누락 여부를 확인하고, contacts 길이에 기반한 contact_002 같은 ID를 생성한 뒤 이름, 전화번호, 생성 시각을 저장합니다.

Memory Usage의 성공 gate는 요구된 정답 Memory ID 집합 $M_q^*$ 가 전체 trajectory에서 검색된 집합 $\hat{M}_T$ 에 포함되는지 검사합니다. 검색 도구가 반환한 Memory ID를 단계별로 합집합한 뒤 $M_q^*\subseteq\hat{M}_T$ 이면 retrieval gate가 1이 되고, 여기에 작업의 고정 primary checker가 논리곱으로 결합됩니다. 예를 들어 필요한 ID가 두 개라면 두 ID가 모두 반환되고, 검색 결과가 실제 도구 인자나 최종 상태에 올바르게 쓰여야 전체 작업이 통과합니다.

Skill Usage는 trajectory 안에서 LoadSkill로 불러온 Skill 집합에 정답 Skill ID가 포함되는지 검사한 뒤, SOR 또는 MTSR 조건에서 downstream 작업의 checker를 함께 적용합니다. 점수는 Basic Tool Use 50%, Sub-agent Collaboration 10%, Memory Usage 20%, Skill Usage 20%의 고정 가중치로 계산합니다. 이 배분은 직접적인 상태 실행을 가장 큰 비중으로 두면서도 개인화, 위임, 재사용 절차가 전체 모바일 신뢰성에 미치는 영향을 별도로 반영합니다.

작업 분포는 Basic Tool Use 1,040개, Sub-agent Collaboration 89개, Memory Usage 376개, Skill Usage 200개입니다. Memory Usage 376개에는 single-turn 176개와 multi-turn 200개가 포함되고, DB-primary와 API-primary 작업은 각각 188개로 균형을 맞췄습니다. 별도의 시나리오 분류 snapshot은 1,530개 query와 13개 상위 시나리오, 89개 level-2 하위 범주로 구성되지만, Overall 점수의 분모는 1,705개 작업입니다.

관련 Figure

Diagram
상단 스키마는 name과 phoneNumber를 필수 인자로 지정하고, 오른쪽 코드는 누락 필드 검사와 새 연락처 ID 생성을 수행합니다. Tool Executor는 실행 결과를 JSON으로 반환하면서 Contacts와 Operation_logs를 함께 갱신하므로 함수 출력뿐 아니라 지속 상태 변화까지 평가할 수 있습니다.
add_contact 호출을 예로 Tool Schema, Tool Database, Tool Code, Tool Executor가 연락처 상태와 실행 로그를 읽고 쓰는 구조를 나타낸 그림입니다.

Chart
Memory Type에서는 single-record grounding이 가장 큰 비중을 차지하고 conflicting-record resolution과 multi-record composition이 뒤를 잇습니다. Target Operation은 personalized phone action이 가장 크며 Memory 추가·교체·삭제가 이어지고, Application Domain은 workplace, study and research, family and health, business-travel 영역으로 균등하게 분할되어 있습니다.
376개 Memory Usage 작업을 Memory Type, Target Operation, Application Domain 세 축으로 나누어 원형 차트로 나타낸 그림입니다.

한계점

논문은 현재 frontier LLM이 PermissionDenied 같은 실행 예외에서 성급하거나 환각된 도구 호출을 내고, 모호한 제약에서 질문이나 전략 수정을 충분히 하지 못한다고 명시합니다. 또한 GUI 조작을 중앙 Planner가 아닌 downstream Sub-agent 경로로 분리하므로, 이 벤치마크의 점수는 중앙 계획과 위임 품질을 중심으로 반영하며 저수준 화면 인식 능력 전체를 직접 측정하지 않습니다.

실무 활용

이 벤치마크는 모바일 에이전트가 함수 호출을 출력하는 수준을 넘어, 기억 검색과 Skill 로딩, API 실행, Sub-agent 위임을 상태 변화와 오류 피드백 속에서 연결하는지 점검하는 데 사용할 수 있습니다. 구조화된 샌드박스와 고정된 checker를 이용하므로 특정 오류 유형을 반복 재현하고 agentic reinforcement learning rollout에도 활용할 수 있습니다.

모바일 Planner의 도구 선택, 인자 연결, 선행 조건 처리, PermissionDenied 복구 성능 비교
사용자 프로필과 과거 선호도를 검색해 개인화된 모바일 작업으로 연결하는 Memory pipeline 평가
복합 Skill을 선택하고 동적으로 추가된 도구를 끝까지 실행하는 장기 계획 평가
API가 없는 시각 작업을 GUI Sub-agent에 올바른 맥락으로 위임하는 handoff 평가
상태 데이터베이스와 실행 로그를 이용한 모바일 에이전트 오류 재현 및 reinforcement learning rollout

코드 공개 여부: 미확인

키워드

MobilePA-Bench(모바일 Planner 평가 벤치마크)tool-calling(도구 호출)mobile planning agent(모바일 계획 에이전트)stateful sandbox(상태 유지형 샌드박스)Sub-agent Collaboration(Sub-agent 협업)Memory Usage(메모리 사용)Skill Usage(Skill 사용)reinforcement learning(강화학습)

용어 해설

상태 유지형 샌드박스(Stateful Sandbox): — 상태 유지형 샌드박스는 에이전트의 도구 호출에 따라 애플리케이션 데이터베이스와 실행 로그를 계속 갱신하는 실행 환경이다. MobilePA-Bench에서는 도구 스키마, 실행 코드, 영속 데이터베이스를 결합하고 상태 변화와 오류를 구조화된 피드백으로 반환한다. 이를 통해 정적인 함수 문자열 일치가 아닌 실제 실행 순서와 오류 복구 능력을 측정한다.
도구 호출(Tool Calling): — 도구 호출은 언어 모델이 자연어 요청을 실행 가능한 함수 이름과 JSON 인자로 변환해 외부 기능을 사용하는 방식이다. 이 논문에서는 직접 모바일 API 호출뿐 아니라 Memory 검색, Sub-agent 위임, Skill 로딩도 같은 구조화된 함수 인터페이스로 표현한다. 따라서 도구 선택, 인자 연결, 선행 조건 준수, 실행 결과에 따른 재계획을 하나의 과정으로 평가한다.
Sub-agent 협업(Sub-agent Collaboration): — Sub-agent 협업은 중앙 Planner가 직접 처리하기 어려운 시각 조작이나 조건 감시 같은 작업을 전문 하위 에이전트에 전달하는 구조다. 중앙 에이전트는 적절한 경로를 선택하고 작업 지시와 실행 맥락을 함께 넘기며, 하위 에이전트의 결과를 받아 전체 흐름을 이어간다. MobilePA-Bench는 위임 경로와 handoff payload의 완전성을 행동 검증 기준으로 삼는다.
메모리 사용(Memory Usage): — 메모리 사용은 저장된 사용자 프로필, 선호도, 과거 기록을 검색한 뒤 모호한 요청의 실행 인자에 반영하는 능력이다. 필요한 Memory ID를 모두 검색하고 후속 도구 호출에 올바르게 활용해야 최종 작업이 성공한다. 논문에서는 단일 기록 연결, 충돌 기록 해결, 여러 기록 조합을 포함한 376개 작업으로 이 능력을 측정한다.
Skill 사용(Skill Usage): — Skill 사용은 여러 원자적 도구 호출을 매번 새로 계획하지 않고, 미리 묶인 composite skill을 불러와 관련 실행 도구를 동적으로 추가하는 방식이다. Skill loader 호출 뒤 환경은 해당 Skill에 연결된 도구 스키마를 다음 단계의 action space에 합친다. 이 구조는 장기 실행에서 단계별 계획 오류가 누적되는 문제를 줄이지만, 올바른 Skill 선택과 후속 실행이 모두 필요하다.
증거 정렬형 검증(Evidence-Aligned Verification): — 증거 정렬형 검증은 모든 작업에 동일한 성공 기준을 적용하지 않고, 완료를 가장 잘 입증하는 관찰 증거에 맞춰 검증기를 선택하는 방식이다. MobilePA-Bench는 정확한 함수 순서를 검사하는 Tool Call, 최종 데이터베이스 변화를 검사하는 State Change, 위임과 사용자 상호작용을 검사하는 Agent Behavior로 작업을 나눈다. Memory 검색과 Skill 로딩은 이 기본 검증기에 별도 gate로 결합한다.

복합 실세계 작업을 평가하는 모바일 에이전트 벤치마크

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

용어 해설

관련 토론

댓글

관련 기사

MobileWorld, 모바일 에이전트 평가의 새 기준

MCP-Bench: MCP 서버 기반 도구 사용 에이전트 벤치

SOP-Bench, 실제 업무 절차용 에이전트 평가 기준

대화가 아닌 결과로 AI 에이전트 평가

대화형 에이전트의 신뢰성과 협업 능력을 측정하는 벤치마크인 τ-bench와 τ²-bench 연구.

왜 중요한가

핵심 기여

핵심 아이디어 이해하기

방법론

주요 결과

기술 상세

한계점

실무 활용

키워드

관련 토론

댓글

관련 기사

MobileWorld, 모바일 에이전트 평가의 새 기준

MCP-Bench: MCP 서버 기반 도구 사용 에이전트 벤치

SOP-Bench, 실제 업무 절차용 에이전트 평가 기준

대화가 아닌 결과로 AI 에이전트 평가

대화형 에이전트의 신뢰성과 협업 능력을 측정하는 벤치마크인 τ-bench와 τ²-bench 연구.