오픈소스 스마트폰 에이전트 프레임워크 비교와 선택 기준
Open-AutoGLM, Mobilerun, Minitap mobile-use를 배포·기기 연결·모델·추적·라이선스로 비교합니다. Mobilerun의 기기 선택, 앱 카드 이전, Portal 권한과 실패 후 재시도 조건도 확인하세요.
- Open-AutoGLM은 Android ADB 기반 화면 에이전트와 AutoGLM 계열 모델 실험을 함께 보고 싶은 팀에 맞습니다. iOS는 별도 WebDriverAgent 설정으로 봐야 하며, 민감 작업 확인과 로그인·캡차의 사람 개입 흐름도 자신의 환경에서 검증해야 합니다.
- Mobilerun Framework는 로컬 CLI·Python 자동화와 실행 추적에 맞고 Cloud는 별도 관리형 경로입니다. 10월 변경 사항에 맞춰 명시적 기기 선택, 플랫폼별 앱 카드 경로, Portal 서비스 상태와 실패 후 실제 결과를 확인해야 합니다.
- Minitap mobile-use는 자연어 기반의 구조화된 모바일 UI 작업과 결과 추출을 검토할 때 적합합니다. Android는 ADB 기반이고, iOS는 macOS 시뮬레이터 지원과 물리 기기 미지원 조건을 구분해야 합니다.
- 오픈소스 라이선스는 무료 모델 호출이나 무관리 운영을 뜻하지 않습니다. 직접 구축 대신 준비된 Android 제품이 필요하면 FoneClaw를 별도로 검토하되, 지원 도구·실제 권한·승인 정책과 결과를 확인하세요.
작업에 맞는 프레임워크 먼저 고르기
오픈소스 스마트폰 에이전트 프레임워크를 찾는다면 먼저 “어떤 모델이 가장 강한가”보다 “어떤 실행 환경을 관리할 수 있는가”를 정해야 합니다. 휴대폰 에이전트는 모델 하나로 끝나지 않습니다. 화면을 읽는 런타임, 모델 추론 경로, ADB나 접근성 서비스 같은 휴대폰 실행 계층, 실패를 기록하고 복구하는 운영 방식이 함께 필요합니다.
| 선택지 | 잘 맞는 경우 | 먼저 확인할 조건 |
|---|---|---|
| Open-AutoGLM | Android 화면 에이전트와 AutoGLM 계열 모델 흐름을 함께 실험할 때 | ADB, USB 디버깅, ADB Keyboard, 모델 엔드포인트 또는 자체 추론, iOS는 별도 WebDriverAgent 설정 |
| Mobilerun Framework | CLI·Python으로 로컬 컴퓨터에서 모바일 자동화를 만들고 실행을 추적할 때 | 명시적 기기 선택, Portal 서비스, 플랫폼별 앱 카드, 모델 공급자와 추적 저장 방식 |
| Minitap mobile-use | 자연어로 구조화된 모바일 UI 작업을 자동화하고 결과를 추출할 때 | Android ADB, LLM 공급자, iOS는 macOS 시뮬레이터 조건 |
이 글은 세 프레임워크의 성능 순위를 매기지 않습니다. 공식 문서가 설명하는 기기 준비, 모델 구성, 실행 방식, 라이선스와 검사 기능을 기준으로 작업 적합도를 비교합니다. Mobilerun의 10월 변경 사항은 특히 여러 기기를 연결하거나 기존 앱 카드 설정을 옮기는 경우 확인할 운영 조건입니다. 다른 두 프로젝트까지 같은 시기에 새로 업데이트됐다는 뜻은 아닙니다.
설정, 실행, 모델, 라이선스 비교
세 프로젝트 모두 폰 에이전트라는 큰 범주에 들어가지만, 책임이 나뉘는 방식은 다릅니다. 프레임워크 런타임은 작업 상태를 관리하고 화면 정보를 모델에 전달합니다. 모델 추론은 외부 API나 자체 호스팅 모델에서 이루어질 수 있습니다. 휴대폰 실행은 ADB, 접근성 서비스, WebDriverAgent 같은 별도 계층을 통해 이루어집니다. 이 셋을 하나로 섞으면 비용과 실패 원인을 판단하기 어렵습니다.
| 항목 | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| 공식 저장소 | Open-AutoGLM 저장소 | Mobilerun 저장소 | mobile-use 저장소 |
| 배포·운영 | 프레임워크와 호스팅 API 또는 자체 모델 서비스를 구성 | 로컬 컴퓨터의 Framework와 별도 관리형 Cloud 경로 구분 | 실행 환경과 LLM 공급자 구성, Docker 빠른 시작은 Android 전용 |
| 기기 연결 | Android ADB, HarmonyOS HDC, iOS는 별도 WebDriverAgent | Android ADB·Portal, iOS는 별도 Portal 흐름; 실행 대상 명시 확인 | Android 물리 기기·에뮬레이터, macOS iOS 시뮬레이터 |
| 모델·공급자 | 호스팅 API 또는 자체 모델 서비스 | 모델 공급자 선택 | 구성 가능한 LLM 공급자 |
| 권한·개입 | 디버깅·입력 환경과 문서화된 민감 작업 확인·사람 개입을 검증 | Portal 접근성 서비스·키보드의 실제 상태와 실행 중 복구 동작 확인 | ADB 연결과 대상 플랫폼 설정, 작업별 실행 범위 확인 |
| 앱별 설정 | 대상 앱과 실행 설정을 해당 문서에서 확인 | Android·iOS별 앱 카드 파일과 플랫폼 식별자 확인 | 대상 앱의 UI·접근성 정보와 작업 구성 확인 |
| 추적·실패 대응 | 민감 작업 확인 및 로그인·캡차의 사람 개입 흐름 문서화 | Arize Phoenix·Langfuse·저장된 실행 경로; 실패 후 실제 기기 상태 확인 | 구조화 추출과 작업 결과 검토; 최종 상태를 직접 대조 |
| 저장소 라이선스 | Apache-2.0 | MIT | Apache-2.0 |
표의 라이선스는 저장소 코드에 관한 구분입니다. 도입할 때는 실제 사용할 코드의 라이선스 파일을 확인하고, 모델·클라우드 기기·외부 API 조건을 별도로 읽어야 합니다. 오픈소스는 시작 코드를 볼 수 있다는 뜻이지 모델 호출료, GPU, 테스트 기기, 클라우드 실행 환경과 유지보수가 무료라는 뜻은 아닙니다. 로컬 컴퓨터에서 실행하는 프레임워크도 모델 호출은 외부 서비스로 보낼 수 있습니다.
Open-AutoGLM이 맞는 경우
Open-AutoGLM은 Android 화면을 보고 다음 행동을 계획하는 시각 기반 폰 에이전트 흐름을 직접 다루고 싶을 때 적합합니다. 공식 저장소는 Android에서 개발자 옵션, USB 디버깅, ADB와 ADB Keyboard를 준비하는 흐름을 설명합니다. HarmonyOS 쪽에는 HDC 관련 문서도 있고, iOS는 Android ADB와 같은 경로가 아니라 별도 WebDriverAgent 설정으로 다뤄야 합니다.
모델 추론은 프레임워크와 분리해 봐야 합니다. 문서에는 제3자 호스팅 모델 API를 쓰는 경로와 자체 모델 서비스를 운영하는 경로가 함께 나옵니다. 호스팅 API를 쓰면 로컬 GPU가 필수는 아니지만 모델 호출 비용과 계정 조건이 생깁니다. 자체 추론을 고르면 서버, 런타임, 모델 배포와 지연 시간을 관리해야 합니다.
Open-AutoGLM을 고를 만한 핵심 이유는 화면 에이전트 연구와 실행 흐름을 비교적 낮은 수준에서 직접 다룰 수 있다는 점입니다. 저장소는 민감 작업 확인과 로그인·캡차 상황에서 사람에게 제어를 넘기는 흐름을 문서화합니다. 이런 통제 장치를 처음부터 모두 새로 만들어야 한다는 뜻은 아니지만, 자신의 기기, 앱, 계정, 모델 경로에서 실제로 어떻게 작동하는지는 별도로 확인해야 합니다. Apache-2.0 라이선스도 연결하는 모델이나 기기의 모든 조건을 대신하지 않습니다.
Mobilerun Framework와 Cloud 선택
Mobilerun은 현재 저장소 기준으로 Mobilerun Framework를 먼저 봐야 합니다. 예전 DroidRun 이름을 본 적이 있더라도 선택 기준은 현재 Mobilerun 저장소의 문서입니다. Framework는 로컬 컴퓨터에서 에이전트를 실행하고, CLI나 Python으로 모바일 제어를 구성하며, 접근성 트리와 스크린샷을 모델에 제공하는 흐름을 다룹니다.
Android 준비에는 ADB, 개발자 모드, USB 디버깅과 Portal 접근성 서비스가 들어갑니다. iOS는 프로젝트가 문서화한 별도 Portal 설정 흐름을 따라야 합니다. 모델은 공급자를 선택해 연결하는 구조이므로 로컬에서 프레임워크를 실행한다는 사실만으로 모델 추론까지 로컬이라는 뜻은 아닙니다.
Mobilerun의 10월 14일 UTC 릴리스 안내는 실행 대상 선택 순서를 명확히 합니다. 명시한 -d, 환경 변수 ANDROID_SERIAL, 온라인 기기가 하나뿐인 경우의 자동 선택 순서입니다. 여러 기기가 연결됐는데 대상을 지정하지 않으면 첫 기기를 고르는 대신 오류가 납니다. 실행 전 연결 목록을 살펴보고 시험용 기기의 식별자를 의도적으로 지정하세요. 이 릴리스는 한국·중국 시각으로는 10월 15일에 해당합니다.
기존 설정을 옮긴다면 10월 5일 앱 카드 변경 안내도 확인해야 합니다. 앱 카드 기준 디렉터리를 app_cards_dir로 두었을 때 Android는 app_cards_dir/android/app_cards.json, iOS는 app_cards_dir/ios/app_cards.json을 사용합니다. 기준 디렉터리 바로 아래에 두던 평면 파일은 무시됩니다. 파일이 존재하는지만 보지 말고 실제 경로와 플랫폼별 앱 식별자가 맞는지 대조하세요.
설정 과정은 적절한 Portal 버전을 지정하고 이미 설치된 더 새로운 Portal은 유지합니다. 임의의 호환 버전을 정해 덮어쓰기보다 공식 설정 흐름과 실제 설치 상태를 확인하는 편이 맞습니다. Portal은 실행 중 접근성 서비스와 Portal 키보드를 복구할 수 있으므로, 접근을 철회하려는 경우에는 에이전트를 먼저 중지한 뒤 기기의 서비스·키보드·권한 상태를 확인하세요. 서비스가 다시 활성화됐다고 보안 기능을 끄거나 Play Protect를 우회해서는 안 됩니다.
FastAgent의 호출 처리도 재시도 설계에 영향을 줍니다. 첫 번째 function_calls 블록만 사용하고 뒤의 블록은 무시하며, 호출 하나가 실패하면 남은 호출은 건너뜁니다. 앞서 성공한 동작까지 취소되는 것은 아닙니다. 실패하면 멈추고 실제 기기 결과와 실행 기록을 대조한 뒤 원인을 고쳐야 합니다. 이를 자동 롤백이나 일괄 처리의 원자성이 보장된다는 뜻으로 해석하지 마세요.
Mobilerun의 실행 검사에는 Arize Phoenix와 Langfuse를 통한 추적, 저장된 실행 경로가 문서화돼 있습니다. 어떤 화면을 보고 실패했는지 확인해야 하는 개발팀에 유용한 선택 기준입니다. Mobilerun Cloud는 별도 관리형 경로로, 로컬 연결 휴대폰이나 호스팅된 가상·물리 기기를 이용한 API 워크플로를 다룹니다. Cloud SDK의 UI 트리 호환성과 탭·입력의 재시도 없는 동작 변경도 운영 전 확인할 항목이지, 모든 앱에서 성공한다는 근거는 아닙니다.
Minitap mobile-use가 맞는 경우
Minitap의 mobile-use는 자연어로 모바일 UI 작업을 자동화하고, 필요한 결과를 구조화해 얻으려는 경우에 살펴볼 만합니다. mobile-use 저장소는 구성 가능한 LLM 공급자, 자연어 기반 모바일 UI 자동화, 구조화 추출을 설명합니다. Docker 빠른 시작은 Android 전용으로 안내됩니다.
Android에서는 물리 기기나 에뮬레이터가 ADB 기반으로 준비됩니다. iOS는 특히 문구를 조심해야 합니다. 저장소의 수동 기기 설정은 macOS에서 iOS 시뮬레이터를 다루며, 물리 iOS 기기는 지원되지 않는다고 명시합니다. 넓은 소개 문구만 보고 Android와 iOS 물리 기기가 같은 수준으로 지원된다고 판단하면 안 됩니다.
mobile-use는 비교적 구조화된 모바일 작업과 결과 추출에 맞습니다. 예를 들어 설정을 읽고 특정 상태를 확인하거나, 화면에서 정보를 뽑아 다음 시스템으로 넘기는 흐름이 어울립니다. 다만 저장소는 접근성 트리 정보가 부족한 게임류 작업의 한계도 언급합니다. 화면이 캔버스 중심이거나 접근성 정보가 빈약한 앱은 별도 검사가 필요합니다.
되돌릴 수 있는 작업으로 평가하기
처음부터 메시지 전송, 결제, 계정 변경처럼 결과가 큰 작업을 넣지 마세요. 자신이 소유한 시험용 Android 휴대폰에서 계산기처럼 민감하지 않은 앱 하나를 고르고, “이 앱을 열고 첫 화면이 보이는지 확인하되 아무것도 입력하거나 변경하지 않기”를 공통 작업으로 제안합니다. 공식 문서를 바탕으로 한 설정 점검 예시이며, 세 프레임워크를 직접 측정한 결과가 아닙니다.
- 대상 기기를 확정합니다. 연결 목록과 실제 휴대폰을 대조합니다. Mobilerun에서는
-d또는ANDROID_SERIAL설정이 의도한 기기를 가리키는지 확인합니다. - 실행 조건을 기록합니다. 같은 기기·앱 버전과 시작 화면을 준비하고 모델 공급자, 모델 이름, 이미지 입력 여부 등 사용한 설정을 남깁니다.
- 앱 열기만 요청합니다. 메시지 전송·구매·권한 변경을 시험에 섞지 않습니다.
- 틀린 기기나 실패가 보이면 중지합니다. 화면 인식, 도구 인자, 연결, 권한, 모델 응답 중 어느 단계에서 막혔는지 나눠 봅니다.
- 기록과 실제 화면을 대조합니다. 제공되는 로그·스크린샷·접근성 트리·실행 경로를 확인하되 민감한 정보는 남기지 않도록 주의합니다.
- 원인을 고친 뒤 재개합니다. 이미 앱이 열렸는지 등 완료된 상태부터 확인하고, 실패한 호출이 앞선 동작까지 되돌렸다고 가정하지 않습니다.
통과 기준은 요청한 시험 기기에서 선택한 앱의 첫 화면이 실제로 보이고 다른 변경이 없는지입니다. 에이전트가 완료했다고 말했어도 다른 기기가 움직였거나 화면이 다르면 통과가 아닙니다. 재시도할 때도 같은 요청을 무조건 반복하기보다 현재 상태에서 필요한 단계만 판단해야 합니다.
더 체계적인 기준이 필요하다면 안드로이드 폰 에이전트 벤치마크 가이드: 성공률보다 신뢰성을 평가하는 법에서 성공률, 복구, 반복성과 안전성을 나누어 볼 수 있습니다. 모델 선택 자체를 따로 검토하려면 Android 작업에 맞는 AI 에이전트 모델 선택 기준이 도움이 됩니다.
프레임워크 없이 Android 제품 경로 선택
모든 독자가 ADB, 접근성 서비스, 모델 공급자, 추적 서버, 기기 풀을 직접 관리하고 싶은 것은 아닙니다. 그런 경우에는 오픈소스 프레임워크 대신 준비된 Android 제품 경로를 검토하는 편이 현실적입니다. FoneClaw는 오픈소스 프레임워크로 분류할 대상이 아니라, 구성 가능한 모델과 지원 도구를 갖춘 Android 폰 에이전트입니다.
FoneClaw에서는 구성된 모델이 요청을 이해하고 계획하며, 활성화된 도구가 실제 Android 권한과 전역·도구별 승인 정책에 따라 실행합니다. 앱 열기나 지원되는 화면 확인 같은 작업도 해당 도구와 기기 상태를 기준으로 봐야 합니다. 모든 앱을 제어하거나 매 동작마다 확인창이 뜬다는 뜻은 아니며, 여기서 비교한 프레임워크와의 기본 연동을 의미하지도 않습니다.
휴대폰에서 작업이 실행된다는 사실만으로 모든 모델 추론이 기기 안에서 이루어진다고 볼 수는 없습니다. 또한 준비된 제품을 고르더라도 실행 대상, 허용 범위, 중지 방법과 실제 결과를 확인하는 일은 남습니다. 내부 연구와 자동화 인프라가 목적이면 Open-AutoGLM, Mobilerun, mobile-use를 비교하고, 직접 구축보다 지원되는 휴대폰 작업을 사용하는 것이 목적이면 제품 경로를 검토하세요.
실행과 권한의 관계는 AI 에이전트 Android 휴대폰 제어: 의도에서 확인, 실행, 검증까지에서 먼저 확인할 수 있습니다. FoneClaw의 현재 제공 범위는 FoneClaw 기능 안내에서, Android 배포 경로는 FoneClaw 다운로드 안내에서 살펴볼 수 있습니다.