오픈소스 폰 에이전트 프레임워크 추천: Open-AutoGLM, Mobilerun, mobile-use 비교
Open-AutoGLM, Mobilerun, Minitap mobile-use를 작업 적합도, 기기 준비, 모델 구성, 실행 방식, 추적·검사, 라이선스와 유지 비용 기준으로 비교합니다.
- Open-AutoGLM은 Android ADB 기반 화면 에이전트와 AutoGLM 계열 모델 실험을 함께 보고 싶은 팀에 맞습니다. iOS는 별도 WebDriverAgent 설정으로 봐야 하며, 저장소가 문서화한 민감 작업 확인과 로그인·캡차 사람 개입 흐름도 자신의 환경에서 검증해야 합니다.
- Mobilerun Framework는 로컬 컴퓨터에서 CLI·Python으로 휴대폰 자동화를 구성하고, 접근성 트리·스크린샷·실행 추적을 검사하려는 개발자에게 적합합니다. Mobilerun Cloud는 별도 관리형 실행 경로입니다.
- Minitap mobile-use는 자연어로 구조화된 모바일 UI 작업을 자동화하려는 경우에 살펴볼 만합니다. Android는 ADB 기반이고, iOS는 macOS의 시뮬레이터 지원과 물리 기기 미지원 조건을 구분해야 합니다.
- 오픈소스 프레임워크는 무료 모델 호출, 무료 클라우드 기기, 무관리 운영을 뜻하지 않습니다. 배포를 직접 관리하고 싶지 않다면 FoneClaw 같은 준비된 Android 제품 경로를 별도로 검토할 수 있습니다.
작업에 맞는 프레임워크 먼저 고르기
오픈소스 폰 에이전트 프레임워크 추천을 찾는다면 먼저 “어떤 모델이 가장 강한가”보다 “어떤 실행 환경을 관리할 수 있는가”를 정해야 합니다. 휴대폰 에이전트는 모델 하나로 끝나지 않습니다. 화면을 읽는 런타임, 모델 추론 경로, ADB나 접근성 서비스 같은 휴대폰 실행 계층, 실패를 기록하고 되돌리는 운영 방식이 함께 필요합니다.
| 선택지 | 잘 맞는 경우 | 먼저 확인할 조건 |
|---|---|---|
| Open-AutoGLM | Android 화면 에이전트와 AutoGLM 계열 모델 흐름을 함께 실험할 때 | ADB, USB 디버깅, ADB Keyboard, 모델 엔드포인트 또는 자체 추론, iOS는 별도 WebDriverAgent 설정 |
| Mobilerun Framework | CLI·Python으로 로컬 컴퓨터에서 모바일 자동화를 만들고 실행을 추적할 때 | ADB, Portal 접근성 서비스, 모델 공급자, 추적 저장 방식 |
| Minitap mobile-use | 자연어로 구조화된 모바일 UI 작업을 자동화하고 결과를 추출할 때 | Android ADB, LLM 공급자, iOS는 macOS 시뮬레이터 조건 |
이 글은 세 프레임워크의 성능 순위를 매기지 않습니다. 공식 저장소가 문서화한 장치 준비, 모델 구성, 실행 방식, 라이선스와 검사 기능을 기준으로 어떤 작업에 맞는지 고르는 가이드입니다.
설정, 실행, 모델, 라이선스 비교
세 프로젝트 모두 “폰 에이전트”라는 큰 범주에 들어가지만, 책임이 나뉘는 방식은 다릅니다. 프레임워크 런타임은 작업 상태를 관리하고 화면 정보를 모델에 전달합니다. 모델 추론은 외부 API나 자체 호스팅 모델에서 이루어질 수 있습니다. 휴대폰 실행은 ADB, 접근성 서비스, WebDriverAgent 같은 별도 계층을 통해 이루어집니다. 이 셋을 하나로 섞으면 비용과 실패 원인을 판단하기 어렵습니다.
| 항목 | Open-AutoGLM | Mobilerun | Minitap mobile-use |
|---|---|---|---|
| 공식 저장소 | Open-AutoGLM 저장소 | Mobilerun 저장소 | mobile-use 저장소 |
| 주요 실행 대상 | ADB 기반 Android, HDC 기반 HarmonyOS, iOS는 WebDriverAgent 설정 문서화 | Android ADB와 Portal 접근성 서비스, iOS 별도 Portal 흐름 | Android 물리 기기·에뮬레이터, macOS iOS 시뮬레이터 |
| 모델 구성 | 호스팅 API 또는 자체 모델 서비스 | 모델 공급자 선택 | 구성 가능한 LLM 공급자 |
| 검사·추적 | 민감 작업 확인과 로그인·캡차의 사람 개입 흐름을 저장소가 문서화함 | Arize Phoenix, Langfuse, 저장된 trajectory 문서화 | 구조화 추출과 작업 결과 검토 중심 |
| 라이선스 | 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의 장점은 실행 검사입니다. README는 Arize Phoenix와 Langfuse를 통한 tracing, 저장된 trajectory를 문서화합니다. 에이전트가 왜 특정 버튼을 눌렀는지, 어떤 화면을 보고 실패했는지 추적해야 하는 개발팀에 유리합니다. 한편 Mobilerun Cloud는 관리형 경로입니다. 로컬에 연결된 휴대폰이나 호스팅된 가상·물리 기기로 API workflow를 운영할 수 있지만, Framework와 Cloud는 운영 의존성과 비용 구조가 다릅니다.
Minitap mobile-use가 맞는 경우
Minitap의 mobile-use는 자연어로 모바일 UI 작업을 자동화하고, 필요한 결과를 구조화해 얻으려는 경우에 살펴볼 만합니다. mobile-use 저장소는 구성 가능한 LLM 공급자, 자연어 기반 모바일 UI 자동화, 구조화 추출을 설명합니다. Docker quickstart는 Android 전용으로 안내됩니다.
Android에서는 물리 기기나 에뮬레이터가 ADB 기반으로 준비됩니다. iOS는 특히 문구를 조심해야 합니다. 저장소의 수동 기기 설정은 macOS에서 iOS 시뮬레이터를 다루며, 물리 iOS 기기는 아직 지원되지 않는다고 명시합니다. 넓은 소개 문구만 보고 Android와 iOS 물리 기기가 같은 수준으로 지원된다고 판단하면 안 됩니다.
mobile-use는 비교적 구조화된 모바일 작업과 결과 추출에 맞습니다. 예를 들어 설정을 읽고 특정 상태를 확인하거나, 화면에서 정보를 뽑아 다음 시스템으로 넘기는 흐름이 어울립니다. 다만 저장소는 접근성 트리 정보가 부족한 게임류 작업의 한계도 언급합니다. 화면이 캔버스 중심이거나 접근성 정보가 빈약한 앱은 별도 검사가 필요합니다.
되돌릴 수 있는 작업으로 평가하기
프레임워크를 고를 때는 처음부터 메시지 전송, 결제, 계정 변경처럼 결과가 큰 작업을 넣지 마세요. 되돌릴 수 있는 하나의 작업으로 런타임, 모델, 실행 계층을 나누어 관찰하는 편이 좋습니다. 예를 들어 “설정 앱을 열고 Wi-Fi 상태를 읽은 뒤 아무것도 바꾸지 말고 요약하기”처럼 읽기 중심 작업부터 시작할 수 있습니다.
- 같은 Android 기기와 같은 앱 버전을 준비합니다.
- 모델 공급자, 모델 이름, 온도, 이미지 입력 여부를 기록합니다.
- 작업은 읽기, 초안, 되돌릴 수 있는 설정 확인 순서로 넓힙니다.
- 실패하면 화면 인식, 도구 인자, 기기 연결, 권한, 모델 응답 중 어디서 막혔는지 나눕니다.
- 로그, screenshot, accessibility tree, trajectory 같은 검사 자료를 보관합니다.
- 성공 여부는 “말이 그럴듯한가”보다 실제 대상 앱의 최종 상태로 확인합니다.
이 평가는 제안된 절차이지 우리가 세 프레임워크를 같은 조건에서 측정했다는 뜻이 아닙니다. 더 체계적인 기준이 필요하다면 안드로이드 폰 에이전트 벤치마크 가이드: 성공률보다 신뢰성을 평가하는 법에서 성공률, 복구, 반복성과 안전성을 나누어 볼 수 있습니다. 모델 선택 자체를 따로 검토하려면 AI 에이전트 모델 추천: Android 작업에 맞는 6가지 후보와 선택 기준이 도움이 됩니다.
프레임워크 없이 Android 제품 경로 선택
모든 독자가 ADB, 접근성 서비스, 모델 공급자, 추적 서버, 기기 풀을 직접 관리하고 싶은 것은 아닙니다. 그런 경우에는 오픈소스 프레임워크 대신 준비된 Android 제품 경로를 검토하는 편이 현실적입니다. FoneClaw는 오픈소스 프레임워크로 분류할 대상이 아니라, 구성 가능한 모델과 관리되는 지원 도구를 갖춘 Android 앱입니다.
FoneClaw에서는 무료 기본 모델로 시작하고, 조건이 맞는 경우 호환되는 모델 경로를 구성할 수 있습니다. 앱 실행, 현재 화면 맥락, SMS 요약, 메모 같은 지원 작업은 권한과 승인 흐름 안에서 다룹니다. 휴대폰에서 작업이 실행된다는 사실이 모든 추론이 기기 안에서만 이루어진다는 뜻은 아니며, 예약 자동화도 모든 Android 동작을 무인으로 수행하는 범용 기능이 아닙니다.
개발자가 프레임워크를 직접 조립할지, 사용자가 바로 쓸 수 있는 제품 경로를 택할지는 목표가 다릅니다. 내부 연구와 자동화 인프라가 목적이면 Open-AutoGLM, Mobilerun, mobile-use를 비교하세요. 실제 Android 작업을 사용자가 확인하며 처리하는 제품 경험이 필요하다면 AI 에이전트 Android 휴대폰 제어: 의도에서 확인, 실행, 검증까지에서 폰 에이전트 실행 단계를 먼저 이해한 뒤, FoneClaw 기능 안내와 FoneClaw 다운로드 안내에서 현재 제공 범위를 확인할 수 있습니다.