안드로이드 폰 에이전트 벤치마크 가이드: 성공률보다 신뢰성을 평가하는 법
안드로이드 폰 에이전트 벤치마크를 작업 성공률, 권한, 승인, 중단, 복구, 부작용 검증까지 평가하는 실전 프레임워크로 정리합니다. B-MoCA, MobileWorld, KnowU-Bench, PhoneHarness의 2026년 연구 흐름과 현재 FoneClaw 기준 테스트 매트릭스를 함께 설명합니다.
- 안드로이드 폰 에이전트 벤치마크는 화면을 그럴듯하게 누르는 능력보다 사용자의 의도, 올바른 부작용, 승인, 검증, 복구를 함께 측정해야 합니다.
- B-MoCA, MobileWorld, KnowU-Bench, PhoneHarness는 각각 설정 일반화, 장기 다중 앱 작업, 개인화와 동의, 부작용 검증과 실행 추적이라는 다른 약점을 드러냅니다.
- 작업 성공률 하나로 폰 에이전트 품질을 판단하기 어렵습니다. 부분 체크포인트, 잘못된 부작용, 복구율, 인간 개입, 지연 시간, 비용, 감사 추적 품질을 함께 봐야 합니다.
- 현재 FoneClaw는 플로팅 어시스턴트, 현재 화면 첨부, 작업 연속성, 승인·중지·권한 복구를 제공하며, 이 글은 점수가 아니라 재현 가능한 평가 방법과 테스트 매트릭스를 제시합니다.
안드로이드 폰 에이전트 벤치마크가 측정해야 할 것
안드로이드 폰 에이전트를 평가할 때 첫 질문은 “성공했는가”보다 “무엇을 성공으로 볼 것인가”입니다. 화면에서 버튼을 몇 번 눌렀고, 앱이 어느 화면까지 갔다는 사실만으로는 충분하지 않습니다. 사용자가 의도한 목표를 이해했는지, 실제 Android 상태가 맞게 바뀌었는지, 외부에 남는 부작용이 정확했는지, 권한과 승인이 적절했는지, 실패했을 때 복구 가능한 상태를 남겼는지를 함께 봐야 합니다.
FoneClaw를 만들면서 우리는 “그럴듯한 탭”과 “검증된 결과”의 차이를 계속 마주했습니다. 예를 들어 방해금지 화면을 열었다고 해서 방해금지 상태가 맞게 바뀐 것은 아닙니다. 메시지 앱에 본문을 넣었다고 해서 올바른 수신자에게 전송해도 된다는 뜻도 아닙니다. 폰 에이전트의 결과는 화면 이동이 아니라 사용자가 요청한 작업의 완료와 그 과정의 통제입니다.
좋은 안드로이드 폰 에이전트 벤치마크는 네 가지를 동시에 봅니다. 첫째, 목표 이해입니다. 둘째, 올바른 부작용입니다. 셋째, 권한과 사용자 통제입니다. 넷째, 결과 검증과 복구입니다. 이 기준을 제품 개선 루프로 연결하는 방법은 자기 개선 폰 에이전트에 필요한 스킬 버전·회귀 테스트·롤백에서 더 깊게 다룰 수 있고, 이 글에서는 재현 가능한 평가 프레임워크에 집중합니다.
2026년 모바일 에이전트 벤치마크 지형
2026년의 모바일 에이전트 평가 연구는 하나의 리더보드로 합치기보다 각 벤치마크가 드러내는 약점을 읽는 편이 정확합니다. Android 기기 설정이 바뀌면 잘 버티는가, 여러 앱을 오가는 긴 작업을 처리하는가, 사용자 성향과 동의를 이해하는가, 실제 부작용과 실행 추적을 기록하는가가 서로 다른 질문입니다. 점수는 각 논문의 환경과 과제 안에서 의미를 갖습니다.
| 벤치마크 | 확인하는 핵심 | 폰 에이전트 제품팀이 배울 점 |
|---|---|---|
| B-MoCA | B-MoCA PMLR 논문은 131개의 일반 Android 일상 작업을 정의하고, UI 레이아웃과 언어 설정 같은 기기 구성을 무작위화합니다. 논문은 단순한 작업보다 복잡한 작업에서 성능이 더 어려워진다고 보고합니다. | 앱 화면과 언어, 레이아웃이 바뀌어도 작업 의도를 유지하는지 봐야 합니다. 제품 QA에서는 한 기기 한 언어의 통과만으로 충분하지 않습니다. |
| MobileWorld | MobileWorld ACL 2026 논문은 20개 앱에 걸친 201개 작업을 포함합니다. 평균 27.8단계, 62.2% 다중 앱 작업을 다루며, 논문 안에서 AndroidWorld의 14.3단계와 9.5% 다중 앱 비율과 비교합니다. agent-user interaction과 MCP-augmented 과제도 추가합니다. | 현실 작업은 한 앱 안에서 끝나지 않습니다. 장기 작업, 사용자 질의, 외부 도구가 섞인 경우 task state와 복구가 중요해집니다. |
| KnowU-Bench | KnowU-Bench preprint는 42개 일반 GUI 작업, 86개 개인화 작업, 64개 proactive 작업을 다룹니다. 사용자 profile은 숨기고 행동 로그를 제공하며, clarification, proactive consent, rejection 이후 restraint를 테스트합니다. | 개인화는 맞춤 추천만의 문제가 아닙니다. 사용자가 거절한 뒤 멈추는지, 먼저 물어봐야 할 때 묻는지, 동의 없는 개입을 줄이는지 봐야 합니다. |
| PhoneHarness | PhoneHarness preprint는 GUI, CLI, host-side tool action을 함께 다루고, 관찰 가능한 부작용과 감사 가능한 실행 trace를 기록합니다. 논문은 실행 harness와 benchmark를 분리합니다. | 실제 결과 검증과 trace 품질이 중요합니다. 어떤 경로로 실행했는지, 결과가 실제로 남았는지, 나중에 재현할 수 있는지 평가해야 합니다. |
이 네 흐름은 서로 보완됩니다. B-MoCA는 configuration generalization을, MobileWorld는 long-horizon cross-app work를, KnowU-Bench는 personalization과 consent를, PhoneHarness는 mixed action surface와 side-effect verification을 드러냅니다. 도구와 리소스를 신뢰할 수 있게 발견하는 문제는 Agentic Resource Discovery란? ai-catalog.json과 폰 에이전트 신뢰 경계와도 연결됩니다. 벤치마크 이름보다 중요한 것은 우리 제품이 어떤 실패를 놓치고 있는지 확인하는 일입니다.
실제 Android GUI 에이전트 테스트의 여섯 축
실제 Android GUI 에이전트 테스트는 한 가지 난이도 축으로 만들면 쉽게 왜곡됩니다. 단계 수가 많다고 항상 어렵고, 단계 수가 적다고 항상 쉽지는 않습니다. 방해금지 토글은 짧지만 권한과 결과 확인이 중요하고, 여러 앱을 오가는 정보 수집은 길지만 부작용이 적을 수 있습니다. 우리는 테스트 suite를 설계할 때 여섯 축을 독립적으로 바꿔 봅니다.
첫째는 구성 변화입니다. 기기 해상도, Android 버전, OEM UI, 언어, 폰트 크기, 다크 모드, 앱 로그인 상태를 바꿔야 합니다. 둘째는 작업 길이입니다. 단일 앱 조회와 다중 앱 장기 작업을 분리합니다. 셋째는 의도 명확성입니다. “볼륨을 50%로”처럼 명확한 요청과 “회의 준비해 줘”처럼 해석이 필요한 요청을 따로 봅니다.
넷째는 실행 표면입니다. GUI만 쓰는 작업, 구조화 tool action, host-side action, 그리고 이들이 섞인 작업을 구분합니다. 다섯째는 부작용의 무게입니다. 읽기 전용, 되돌리기 쉬운 기기 제어, 외부 효과가 있는 메시지나 전화, 삭제나 변경처럼 민감한 작업을 나눕니다. 여섯째는 중단과 복구입니다. 화면이 바뀌거나 권한이 사라지거나 사용자가 중지하거나 네트워크가 끊겼을 때 상태를 잃지 않는지 봅니다.
이 여섯 축을 독립적으로 바꾸면 “평균 성공률” 뒤에 숨은 문제를 볼 수 있습니다. 어떤 에이전트는 영어 기본 UI에서는 강하지만 한국어와 큰 글씨에서는 약할 수 있습니다. 어떤 에이전트는 작업을 시작하는 데 능숙하지만 중간 승인 후 복구에서 무너질 수 있습니다. 폰 에이전트 신뢰성 지표는 이런 축별 실패를 드러내야 제품 개선에 쓸 수 있습니다.
작업 성공률을 넘어선 신뢰성 지표
작업 성공률은 필요하지만 충분하지 않습니다. 먼저 denominator를 고정해야 합니다. 어떤 작업을 제외했는지, 몇 번 재시도했는지, 실패 후 사람이 개입했는지, 앱 상태가 초기화됐는지 기록하지 않으면 같은 성공률도 의미가 달라집니다. PhoneHarness가 강조하는 관찰 가능한 부작용과 실행 trace는 이 지점에서 실용적입니다. 결과가 실제로 남았는지, 어떤 경로로 남았는지 확인해야 합니다.
우리가 쓰는 scorecard는 다층입니다. 첫째, verified pass입니다. 의도한 Android 상태나 외부 결과가 실제로 확인됩니다. 둘째, partial checkpoint입니다. 앱 열기, 대상 찾기, 초안 작성, 승인 표시처럼 중간 단계가 어디까지 맞았는지 봅니다. 셋째, wrong side effect입니다. 잘못된 수신자, 잘못된 설정, 중복 전송처럼 결과가 잘못 남는 경우는 단순 실패보다 더 무겁게 처리합니다.
넷째, recovery score입니다. 권한 부족, 앱 상태 변화, 사용자 중단 뒤 다시 이어갈 수 있는지 봅니다. 다섯째, human intervention입니다. 사용자가 어디서 얼마나 개입했는지 기록합니다. 여섯째, latency와 cost입니다. 휴대폰 작업은 빠르게 끝나야 하고 배터리와 모델 비용도 영향을 줍니다. 일곱째, trace quality입니다. 누가 무엇을 승인했고 어떤 도구가 어떤 결과를 만들었는지 나중에 확인할 수 있어야 합니다. 신원과 감사 구조를 더 깊게 다루려면 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계가 유용합니다.
승인, 권한, 절제, 중지를 테스트하기
AI 에이전트 벤치마크 2026에서 안전성은 별도 부록이 아니라 점수의 일부여야 합니다. 폰 에이전트가 작업을 끝냈더라도 권한을 과하게 요구했거나, 사용자가 거절한 뒤 계속 진행했거나, 외부 효과가 있는 행동을 승인 없이 실행했다면 좋은 결과라고 보기 어렵습니다. KnowU-Bench가 clarification, proactive consent, rejection 이후 restraint를 평가하는 이유도 여기에 있습니다.
안전성 테스트는 다섯 항목으로 나눌 수 있습니다. 첫째, 최소 권한입니다. 작업에 필요한 권한만 요구하는지 봅니다. 둘째, 승인 타이밍입니다. 메시지 전송, 전화, 설정 변경, 삭제처럼 결과가 남는 순간 전에 사용자가 볼 수 있는 확인을 제공하는지 봅니다. 셋째, clarification입니다. 수신자나 앱이 모호할 때 추측 대신 질문하는지 확인합니다.
넷째, restraint입니다. 사용자가 “아니”, “멈춰”, “나중에”라고 말한 뒤 진행을 멈추는지 봅니다. 다섯째, stop and audit입니다. 실행 중 중지와 결과 기록이 남는지 평가합니다. 승인 화면 자체의 문장, 이유, 신뢰도 표시를 더 깊게 보려면 AI 에이전트 승인 UX: 신뢰도, 작업 이유, 확인과 복구를 설계하는 법이 이어지는 기준입니다. 안전성은 거절률 하나로 측정되지 않습니다. 필요한 행동은 끝내고, 위험한 행동은 묻고, 거절된 행동은 멈추는 균형을 봐야 합니다.
현재 FoneClaw 폰 작업을 평가하는 방식
현재 공개된 FoneClaw는 플로팅 어시스턴트, 현재 화면 첨부, 작업 연속성, 승인과 중지, 권한 복구, 방해금지·볼륨·회의 모드·스크린샷 안정성, 빠른 작업을 제공합니다. 현재 버전은 FoneClaw 다운로드에서 확인할 수 있습니다. 이 글은 FoneClaw의 공식 벤치마크 점수를 발표하는 글이 아니라, 우리가 어떤 방식으로 평가해야 제품 품질을 제대로 볼 수 있는지 설명하는 방법론입니다.
현재 FoneClaw는 구성된 모델과 관리되는 Android 도구로 동작하며, 100+ built-in tools를 통해 지원되는 Android workflow를 제공합니다. 사용자 관점의 기능은 FoneClaw 기능에서 확인할 수 있습니다. 평가 matrix는 작업 종류별로 나눠야 합니다. 읽기 전용 상태 테스트에서는 현재 화면 읽기, Bluetooth 상태 확인, 권한 상태 확인처럼 잘못된 외부 효과가 없는 작업을 봅니다. 여기서는 관찰 freshness와 대상 식별이 중요합니다.
되돌리기 쉬운 기기 제어 테스트에서는 볼륨 조정, 방해금지 상태 확인과 변경, 회의 모드 준비, 스크린샷 같은 작업을 봅니다. 여기서는 실행 전 현재 상태, 실행 후 검증, 사용자가 중지했을 때의 상태가 핵심입니다. 외부 효과 승인 테스트에서는 메시지 초안, 일정 생성, 전화 준비, 지도 앱으로 목적지 넘기기처럼 다른 사람이나 앱 상태에 영향을 줄 수 있는 작업을 다룹니다. 수신자, 본문, 시간, 앱, 승인 기록이 모두 평가 대상입니다.
권한 손실과 복구도 별도 테스트 축입니다. 마이크, 접근성, 알림, 위치, 특수 접근 권한을 끄고 작업을 시작했을 때 FoneClaw가 어떤 화면과 설명으로 복구를 안내하는지 봅니다. 현재 화면 변화 테스트에서는 사용자가 앱을 바꾸거나 화면이 갱신되었을 때 task state가 깨지지 않는지 확인합니다. Android 권한 점검을 사용자 관점에서 더 구체화하려면 AI Android 휴대전화 상태 점검: 앱 권한, 특수 접근, 숨겨진 앱 감사 가이드가 실전 audit 시나리오를 제공합니다.
재현 가능한 폰 에이전트 벤치마크 프로토콜
재현 가능한 모바일 에이전트 테스트를 만들려면 먼저 환경을 고정해야 합니다. 기기 모델, Android 버전, 언어, 화면 크기, 글자 크기, 네트워크, 앱 버전, 로그인 상태, 권한 상태, 배터리 제한, retry policy를 기록합니다. 그다음 초기 상태와 기대 상태를 명확히 정의합니다. “메시지 앱 열기”가 아니라 “지정된 수신자에게 초안이 보이고 전송은 승인 대기 상태”처럼 검증 가능한 결과를 써야 합니다.
- 환경과 앱 상태를 기록합니다.
- 초기 상태와 기대 결과를 정의합니다.
- 구성, 언어, 앱 상태, 권한 중 하나의 축만 바꿔 변화를 봅니다.
- 모든 승인, 도구 호출, 화면 전환, 사용자 개입을 기록합니다.
- 외부 부작용을 실제 앱이나 시스템 상태로 검증합니다.
- 실패를 권한 부족, 화면 변화, 사용자 중지, 모델 오해, 도구 오류, 네트워크 문제로 분류합니다.
- 한계와 재현 조건을 함께 공개합니다.
처음 시작할 테스트는 되돌리기 쉬운 작업이 좋습니다. 예를 들어 방해금지 상태 확인, 볼륨 조정, 현재 화면 질문, Bluetooth 상태 확인처럼 결과가 보이고 위험이 낮은 작업입니다. 그 다음 메시지 초안, 일정 생성, 전화 준비처럼 승인과 복구가 필요한 작업으로 넓히면 됩니다. 이 프로토콜의 목적은 한 번의 멋진 성공 장면이 아니라, 같은 조건에서 반복해도 신뢰할 수 있는 폰 에이전트 행동을 만드는 것입니다.