인스타그램에 "구글이 공개한 안드로이드 자동화 오픈소스, 사람 성공률 80%를 AI가 넘었다"는 카드가 돌아다닌다. AndroidWorld 과제 성공률에서 ARTEMIS가 99.1%로 1위라는 그래프가 붙어 있다.
저장소와 벤치마크 원본을 대조해 봤다. 숫자는 전부 진짜다. 순위가 틀렸다.
무엇인가
google/artemis다. 2026년 8월 13일 공개, Apache-2.0, 9월 19일 기준 스타 7,947개다.
정식 릴리스 태그는 아직 하나도 없다.
자연어로 시키면 안드로이드 기기를 조작한다. 화면을 보고 다음 동작을 정하는 반응형 루프다. 접근성 계층과 OCR, 비전 모델을 함께 쓰고, ADB로 기기를 제어한다. 기본 모델은 Gemini 계열이고 OpenAI·Anthropic·OpenRouter·xAI 키 슬롯도 준비돼 있다. 실행 모드가 둘이다.
| 모드 | 스텝당 | 구성 |
|---|---|---|
flash | 3~5초 | 단일 루프. 계획·검증·보고서 없음. 사전 안전검사 없음 |
pro | 15~40초 | Planner–Operator–Checker 멀티에이전트. 액션 사전 검사, 체크포인트 검증 |
실기기 없이 에뮬레이터로도 돌아간다. Python 3.12 이상, ADB, scrcpy, FFmpeg가 필요하다.
1위가 아니라 2위다
AndroidWorld는 구글 리서치가 만든 공식 벤치마크다. 20개 앱에 걸친 116개 과제를 실제 안드로이드 에뮬레이터에서 돌린다. "116개 과제 Pass@1"이라는 조건도 맞다.
문제는 저장소의 리더보드가 README 텍스트가 아니라 이미지 파일 한 장이라는 점이다. 공식 리더보드 시트를 받아 대조한 결과가 이렇다.
| 모델 | 점수 | ARTEMIS 이미지의 순위 | 공식 순위 |
|---|---|---|---|
| FluizAI | 100% | (누락) | 1위 |
| ARTEMIS | 99.1% | 1위 (OURS) | 2위 |
| FinalRun | 97.4% | 2위 | 3위 |
| Midscene.js | 93.1% | 6위 | 8위 |
| 사람 평균 | 80.0% | — | — |
| Gemini 2.5 Computer Use | 69.7% | 21위 | 23위 |
| UI-TARS | 46.6% | 34위 | 36위 |
점수는 여섯 개 모두 공식 시트와 일치한다. 그런데 1위인 FluizAI(100%)와 공동 4위권인 askui가 빠져 있고, 그만큼 모든 순위가 두 계단씩 당겨졌다. 리더보드가 갱신되기 전 스냅샷에 "#1 OURS" 배지를 붙여 둔 상태로 보인다.
더 중요한 건 리더보드 자체의 성격이다. 시트 맨 위에 경고가 적혀 있다. 커뮤니티가 제출한 결과이고 독립 검증을 하지 않으며 점수는 자기 신고라는 내용이다. 상위권 팀 상당수가 검증용 실행 기록을 함께 제출했는데, ARTEMIS 행의 실행 기록 칸은 비어 있다. 저장소에 AndroidWorld를 돌리는 하네스 코드도 없고, 논문이나 기술보고서도 없다.
숫자를 인용할 때 봐야 하는 건 숫자가 아니라 그 숫자를 누가 검증했는지다. 여기서는 아무도 검증하지 않았다.
그럼 쓸모는 뭔가
점수가 아니라 MCP 서버다. Claude Code, Codex, Cursor 같은 도구에 실제 폰을 붙여 준다.
툴 다섯 개(mobile_run_task, mobile_manage_task, mobile_get_device_state,
mobile_inspect_trace, mobile_diagnose)가 노출되고, IDE 채팅에서
"이 APK 설치하고 로그인 화면 열어서 팝업 뜨는지 확인하고 스크린샷 줘"가 된다.
에뮬레이터로 되고 Gemini 키 하나로 시작되니 앱 QA 자동화를 실험해 보기에 진입 장벽이 낮다.
다만 "성능 측정 결과를 문서로 정리해 준다"는 소개는 반만 맞다. 보고서를 만드는 에이전트는 실제로 있는데, perfetto나 gfxinfo 같은 전용 성능 계측기는 없다. ARTEMIS가 ADB 셸을 열어 주고 그걸 코딩 어시스턴트가 읽어 표로 만드는 구조다. ARTEMIS의 기능이 아니다.
에뮬레이터에 직접 올려 봤다
말로만 "에뮬레이터로 된다"고 쓰기 싫어서 실제로 설치했다. 모델 API 키가 없어서 과제 수행은 못 했지만, 키 없이 확인되는 것이 꽤 많았다. 특히 위험 항목은 전부 실동작으로 재현했다.
| 단계 | 시간 | 용량 |
|---|---|---|
| 명령줄 도구 + SDK + arm64 시스템 이미지(API 35) | 125초 | 3.1GB |
| 저장소 클론 + 파이썬 의존성 | 19초 | 1.2GB |
| AVD 생성 + 부팅(Pixel 6, 1080×2400) | 49초 | 646MB |
구글 계정 로그인 없는 순정 이미지로 만들었다. 막힌 곳은 없었다.
mobile_diagnose 결과는 "4/5 통과, 막는 건 모델 키 하나"였다. artemis 1.29.0, Android 15 에뮬레이터, 2026-09-20.설치 문서대로 하면 안 된다. 권장 스크립트(./start.sh, artemis mcp --install all)가
~/.claude/rules/, ~/.codex/, ~/.cursor/rules/ 같은 홈 디렉터리 전역 설정을 말없이 고친다.
artemis mcp --generate-config claude 는 스니펫만 출력하니 그걸 보고 직접 붙이는 게 안전하다.
접근성 도우미 자동 설치 — 경로가 둘이다
앞에서 "첫 실행에서 접근성 APK가 자동 설치된다"고 썼는데, 코드를 보고 실제로 돌려 보니 더 정확한 사실이 있다. 관찰 경로와 과제 경로가 갈린다.
mobile_get_device_state,artemis doctor는 설치하지 않는다. 도우미가 없으면 UIAutomator2로 대신 읽는다. 실제로 호출해 봤고 패키지는 설치되지 않았다.mobile_run_task,artemis run은 설치한다. 키 없이 이 코드 경로만 따로 실행해 재현했다.
설치 전후로 기기 상태가 이렇게 바뀐다.
| 확인 항목 | 전 | 후 |
|---|---|---|
| 설치된 패키지 | 없음 | com.artemis.helper v1.2.0 |
accessibility_enabled | 0 | 1 |
enabled_accessibility_services | null | com.artemis.helper/.ArtemisAccessibilityService |
사용자가 탭 한 번 하지 않는다. ADB로 settings put secure 를 직접 써서 접근성 서비스를
켠다. 4초쯤 걸리고, 알림은 중요도 최하로 설정돼 접혀서 뜬다. 화면을 읽는 서비스가 조용히
켜지는 셈이라 개인 폰에서는 하면 안 된다.
끄는 스위치는 있다. ARTEMIS_HELPER_AUTO_INSTALL=false 를 주면 설치를 거부하고
"artemis helper install 로 직접 한 번 깔아라"며 멈춘다. artemis helper uninstall 로 패키지와
접근성 설정이 모두 원복된다.
화면 잠금 해제는 읽기만 해도 발동한다
이쪽은 더 놀랐다. 키 없는 mobile_get_device_state 한 번으로 stay_on_while_plugged_in
값이 1에서 2로 바뀌었다. 과제를 시키지 않고 화면 상태만 물어봐도 전원 정책이 바뀐다.
내부적으로 svc power stayon usb → KEYCODE_WAKEUP → wm dismiss-keyguard 를 순서대로 보낸다.
다만 wm dismiss-keyguard 는 보안 잠금이 아닌 화면만 푼다. PIN·패턴·지문이 걸린 기기까지
뚫는 건 아니다(잠금 건 기기에서의 실동작은 확인하지 못했다).
이것도 ARTEMIS_KEEP_DEVICE_AWAKE=false 로 끄면 값이 그대로 유지된다. 실제로 확인했다.
MCP 툴 다섯 개가 컨텍스트 4.4k를 먹는다
MCP 서버를 띄워 툴 목록을 실제로 받아 토큰을 셌다(tiktoken o200k_base 근사치).
| 툴 | 정의 토큰 |
|---|---|
mobile_diagnose | 1,400 |
mobile_run_task | 1,259 |
mobile_inspect_trace | 748 |
mobile_manage_task | 692 |
mobile_get_device_state | 275 |
| 합계 | 4,374 |
폰 하나 붙이는 값으로 매 요청 4.4k다. 여러 MCP 서버를 한 허브에 모아 쓰는 구조라면 툴 검색(지연 로딩)을 켜 두는 게 맞다.
사내 게이트웨이에 물릴 수 있다
폐쇄망이나 사내 LLM 게이트웨이를 쓰는 기관이라면 이게 중요하다. 가짜 OpenAI 호환 서버를 띄워 실제로 요청이 그쪽으로 가는지까지 확인했다. 된다.
OPENAI_BASE_URL=https://내부-게이트웨이/v1
OPENAI_API_KEY=<게이트웨이 토큰>
config/artemis.jsonc 에서 provider 를 custom 으로 두면 키 검증도 건너뛴다.
제공자 목록에는 openai, google, anthropic, openrouter, xai, vertexai, ollama,
vllm, custom 이 있다.
함정도 셋 있다. 모델별로 다른 엔드포인트는 지정할 수 없다(설정에 api_base 항목이 없다).
OLLAMA_BASE_URL, VLLM_BASE_URL 은 진단은 통과시키는데 실제 라우터가 읽지 않아 요청은
기본 주소로 간다. 그리고 좌표 검출 노드는 Gemini ER 모델을 요구해서, 사내 게이트웨이만으로
flash 프로파일을 돌리면 좌표 기반 조작을 포기해야 한다.
그래서 개인 폰에는 붙이지 않는다
위 두 가지가 실측으로 확인된 이상 결론은 분명하다. 화면 전체를 읽는 서비스가 탭 한 번 없이 켜지고, 상태만 물어봐도 전원 정책이 바뀐다. 문서도 개인 폰과 공용 폰에서는 자동 설치를 끄라고 권고한다.
여기에 빠른 flash 모드에는 사전 안전검사가 없다. 에이전트가 결제나 전송처럼 되돌릴 수 없는
버튼을 누르는 걸 막을 장치가 그 모드에는 없다는 뜻이다. 실험은 계정이 로그인되지 않은
에뮬레이터에서 하는 게 맞다. 설치해 보니 에뮬레이터 준비는 5분이면 끝난다.
라이선스 분쟁이 진행 중이다
프랑스 스타트업 Minitap이 9월 11일, ARTEMIS가 자사 Apache-2.0 프로젝트
minitap-ai/mobile-use의 코드를 출처 표기 없이 가져갔다고 주장했다. 안드로이드 연결 코드가
일치하고 에이전트 지시문이 한 단어까지 같으며 같은 버그까지 공유한다는 내용이다.
저장소에서 확인되는 정황은 이렇다. 문제로 지적된 hopper 디렉터리가 지금도 있고,
그것을 정리하고 서드파티 고지를 넣으려던 커밋이 되돌려졌다. 블로그 다음 날인 9월 12일
README에 "이 프로젝트는 Minitap, Inc.가 개발한 소스 코드를 포함한다"는 한 줄이 추가됐다.
그런데 Apache-2.0이 요구하는 NOTICE 파일은 아직 없고, 이를 지적한 이슈 #113이 열려 있다.
깃허브 google 조직에 올라와 있다는 게 구글이 공식 지원한다는 뜻은 아니다.
CONTRIBUTING에 구글 CLA 요구가 없고, 구글 오픈소스가 보통 넣는 "공식 지원 제품이 아님"
문구도 없다. 구글 공식 발표는 찾지 못했다.
폰이 일하는 기기가 되면
여기서부터는 내 관점이다. ARTEMIS의 순위는 틀렸지만, 이런 프로젝트가 계속 나온다는 사실은 가볍게 보지 않는다. 폰이 에이전트로 조작되기 시작하면 폰은 소비 기기에서 일하는 기기로 바뀐다.
사람들은 이미 대부분의 일을 폰으로 한다. 전 세계 1인당 하루 앱 사용 시간은 3.6시간이다 (Sensor Tower, 2025년). 한국에서는 모바일뱅킹 79%, 배달앱 64%, 모바일쇼핑 63%가 1년 안에 써 본 서비스다(2025년 조사, 한국갤럽 2026년 보고서 인용). 여기에 AI가 붙고 있다. 한국 AI 사용자의 95%가 스마트폰으로 쓰고, 주 용도 1위는 업무·생산성(22%)이다(한국갤럽, 2026년 7월). 전 세계 AI 비서 앱 사용 시간은 1년 새 426% 늘었다.
지금까지 폰에서 AI는 "물어보면 답하는" 수준이었다. 다음 단계는 "시키면 앱을 눌러 끝내는" 것이다. 주문, 예약, 송금, 결재가 전부 앱 안에 있으니, 앱을 대신 누를 수 있는 쪽이 일을 가져간다.
안드로이드가 먼저 열었다
공식 발표만 날짜순으로 놓으면 이렇다.
| 날짜 | 안드로이드 | 아이폰 |
|---|---|---|
| 2026-02-25 | Gemini 다단계 앱 자동화 베타. 미국·한국, 음식·장보기·차량호출 앱 | |
| 2026-05-12 | Gemini Intelligence 발표. 앱 조작을 OS 차원으로 확장 | |
| 2026-06 | WWDC에서 Siri AI 발표 | |
| 2026-07-22 | 자동화 지원 앱 40개 이상으로 확대 | |
| 2026-08-13 | ARTEMIS 오픈소스 공개 | |
| 2026-09-14 | Siri AI 영어 베타 출시. 한국어는 10월 예정 |
소비자 기능 기준으로 안드로이드가 7개월 먼저다. 구조 차이도 있다. iOS는 App Store 가이드라인 2.5.2가 앱이 자기 영역 밖의 데이터를 읽거나 다른 앱의 동작을 바꾸는 걸 막는다. Siri도 개발자가 미리 열어 둔 App Intents로만 다른 앱을 조작한다. 오픈소스 폰 에이전트가 거의 전부 안드로이드 전용인 이유가 이거다. ARTEMIS 로드맵에도 iOS는 아직 미완료다.
실험은 위험한 곳에서 먼저 일어난다. ARTEMIS처럼 사전 안전검사 없는 모드를 달고 나오고, 출처 분쟁이 붙고, 벤치마크 순위를 부풀리는 프로젝트도 섞여 나온다. 그래도 새 시도가 계속 쏟아지는 쪽이 안드로이드이고, 폰이 생산성 기기로 바뀌는 속도는 그 시도의 양에 달려 있다고 본다. 그렇게 되면 지금의 점유율 구도가 그대로 유지될 거라고 보기 어렵다.
반대 근거도 적어 둔다
다만 지금 숫자는 반대 방향이다. 이걸 빼고 쓰면 앞의 판단이 희망이 된다.
- 아이폰은 지금 역대 최고다. 2026년 2분기 전 세계 출하 점유율 20%, 매출 점유율 49%로 둘 다 2분기 기준 최고치다(Counterpoint). 같은 분기 아이폰 매출은 1년 전보다 21.7% 늘었다(애플 공시).
- 사람들은 AI 때문에 폰을 바꾸지 않는다. 미국 조사에서 AI 때문에 폰을 바꿨다는 비율은 11%였고, 구매 기준 1위는 가격(62%)이었다(CNET·YouGov, 2025년). 아이폰 구매자의 39%는 직전 폰을 3년 이상 썼다(CIRP, 2026년).
- 안드로이드도 일반 앱에는 닫혀 있다. 구글 플레이 정책이 접근성 API로 앱이 스스로 계획하고 행동하는 걸 금지한다. ARTEMIS가 ADB, 즉 개발자 경로로 도는 이유다. "안드로이드는 열려 있다"는 말은 개발자와 제조사 기준이다.
그래서 내 판단은 이렇게 정리된다. 폰이 일하는 기기로 바뀌는 흐름은 맞고, 그 실험장은 안드로이드다.
하지만 점유율은 기능이 먼저 나왔다고 움직이지 않는다. 사람들이 폰을 바꾸는 3년 주기 안에서,
결제·송금 같은 되돌릴 수 없는 동작을 믿고 맡길 만큼 안전한 쪽이 판을 가져간다.
ARTEMIS의 flash 모드에 사전 안전검사가 없다는 건 그래서 작은 문제가 아니다.
정리
앱 QA를 에이전트로 돌려 보고 싶다면 실험 가치가 있다. 에뮬레이터 + MCP 조합이 실용적이다.
반대로 "구글이 만든 1위 모델"이라는 문장으로 도입 근거를 만드는 건 위험하다. 1위가 아니고, 자기 신고 점수이고, 재현 코드가 없고, 정식 릴리스도 없고, 출처 분쟁이 열려 있다.
저장소: google/artemis · 벤치마크: google-research/android_world · 확인 기준일 2026-09-18
에뮬레이터 실측: Android 15(API 35) arm64 이미지, artemis 1.29.0, 2026-09-20. 모델 키가 없어 과제 수행은 아직 하지 않았다.
모바일 수치 출처: Sensor Tower State of Mobile 2026 · 한국갤럽 스마트폰 조사 2026 · Gemini 다단계 작업 · Siri AI 출시 · App Store 가이드라인 · Counterpoint 2026년 2분기 · CIRP · 확인 기준일 2026-09-19