모바일 자동화의 실행·검증·증거 - ARTEMIS
ARTEMIS는 Android 기기를 조작하는 자동화 에이전트의 실행 환경이다. 이 자료에서는 실행을 이어 가는 구조 전체보다, 작업 완료·검사 결과·증거 시점을 나누는 설계를 재사용할 근거로 남긴다.
원천과 확인 범위
- 원자료: google/artemis.
- 확인 버전: 371aa6df56880643da57b30da936e9812fb0ec66, 해당 commit 시각 2026-09-12 02:59:56 UTC. 지속 갱신 저장소의 버전 날짜이며 최초 게시일을 뜻하지 않는다.
- 2026-09-15에 README·MCP 안내, Checker의 프롬프트·판정 처리, 실행 루프, 체크포인트·종료 결과 집계와 관련 단위 테스트를 읽었다.
- ARTEMIS 설치, Android 실기기 조작, 테스트·성능 벤치마크 실행은 하지 않았다. 아래 구현 설명은 이 버전의 코드와 테스트가 의도한 계약에 근거한다.
수행 완료와 검사 결과를 별도로 기록한다
작업의 목적이 제품을 검사하는 것이라면, 제품 결함을 발견한 실행도 검사 작업으로서는 완료될 수 있다. 제품이 기대와 다르게 동작했다는 결과를 에이전트의 미완료와 합치면, 에이전트가 올바르게 수집한 실패를 지우거나 통과할 때까지 대상을 바꾸게 만들 수 있다.
ARTEMIS는 작업의 상태와 검사 결과 집계를 별도 필드로 둔다. 완료·부분 수행·막힘과 통과·실패·판정 불가·미검사는 서로 다른 정보를 전달한다. 구현에는 작업이 완료됐어도 실패한 검사가 남는 경로가 있고, 종료 처리 테스트에도 이 조합을 기대하는 사례가 있다. 결과 모델과 집계, 종료 처리 테스트
실행 수용 기준과 제품 기대 동작을 구분한다
Checker는 두 종류의 검사를 받는다. 실행 수용 기준인 verify는 맡은 하위 목표를 요구한 수준까지 수행했는지를 묻는다. 제품 기대 동작인 assert는 검사 대상이 기대대로 반응했는지를 묻는다. 전자가 충족되지 않으면 실행을 보완할 수 있고, 후자의 실패는 증거와 함께 보존할 검사 결과다.
제품 동작을 실패로 판정하기 전에 의도한 자극이 실제로 실행됐는지도 확인하도록 한다. 알맞은 토글을 누르지 않았거나 해당 화면에 도달하지 못했다면, 기대한 변화가 없다는 사실만으로 제품 결함을 판정할 수 없다. 이 프롬프트는 그런 경우를 판정 불가로 남기도록 규정한다. 증거 문자열이 비어 있는 실패 판정은 코드에서 판정 불가로 바꾼다. 프롬프트가 요구하는 증거의 구체성과 코드가 검사하는 빈 문자열 여부는 범위가 다르다. 비어 있지 않은 증거가 곧 올바른 해석이라는 보장은 아니다. 검사 규칙, 판정 모델과 정규화 구현
실패를 보존한다는 것은 제품 결함을 고치지 말라는 뜻이 아니다. 실패 관찰을 기록한 검사와 이후의 수정·재검사를 구별해야 한다는 뜻이다.
관찰 판정과 실행을 계속할 정책을 분리한다
판정은 통과·실패·판정 불가로 남고, 다음 단계로 진행할지는 코드의 정책이 따로 계산한다. 이 버전은 일부 불확실한 verify 결과에서도 실행을 계속하는 정책을 사용한다. 계속 진행했다는 사실로 판정 불가가 통과로 바뀌지는 않는다.
재사용할 부분은 관찰 결과와 대응 정책을 나누고 원래 판정을 보존하는 구조다. 불확실할 때 계속할지 중단할지는 작업의 영향과 요구 계약에 따라 달라지므로, 이 프로젝트의 진행 정책을 일반 규칙으로 채택하지 않는다. 판정과 진행 정책의 분리
지나간 순간은 당시의 증거로 판단한다
잠깐 나타난 알림이나 조작 순서는 현재 화면만으로 확인하기 어렵다. ARTEMIS는 하위 목표 완료 시점의 단계 식별자와 실행 기록을 연결하고, 해당 시점의 검사는 그 부근의 기록을 보도록 한다. 작업 종료 때 판단할 항목과 하위 목표 완료 순간에 판단할 항목도 구별한다.
이미 끝난 시점의 검사를 현재 화면으로 다시 판정하면, 올바르게 사라진 알림을 실패로 보거나 나중에 복구된 상태로 과거의 실패를 덮을 수 있다. 증거를 수집하지 않았다면 수집 누락을 남기며 현재 상태로 과거를 확정하지 않는다. 계속 유지되는 설정값처럼 나중에도 조회 가능한 상태는 관찰 대상의 성격에 맞춰 별도로 취급한다. 증거 시점·종료 검사 규칙
이는 별도로 재사용할 수 있는 증거 시점의 후보 주장이다. 이번 증류에서는 Source에 보존하고, 독립 Atomic은 수행 완료와 검사 결과의 구분에 먼저 둔다.
최종 검사는 원래 목표와 미검사를 놓치지 않는다
최종 검사는 계획의 체크 표시만 확인하지 않고, 실행 중 받은 사용자 수정까지 반영한 원래 목표를 대조하도록 설계돼 있다. 종료 처리에서는 진행 중 검사를 일정 시간 기다리고, 끝내 결과가 없으면 미검사로 기록한다. 시간 제한이나 수집 누락을 성공으로 집계하지 않는다.
이 구현은 제품 동작 검사에서 한 번 관찰한 실패를 나중 통과로 지우지 않고, 실행 수용 기준은 보완 뒤의 판정을 반영한다. 두 종류의 이력을 다르게 다루는 이유는 묻는 질문이 다르기 때문이다. 이것을 모든 테스트 시스템의 재실행·이력 집계 정책으로 일반화하지 않는다. 종료 정산과 결과 집계, 종료 처리 테스트
역할 제한과 실제 보장의 경계
Checker는 기기를 조작하지 않는 역할로 설계됐고, 코드도 정해진 읽기 전용 조회와 기록 읽기를 제공한다. 과거 시점 검사에서 현재 화면을 섞지 않도록 도구 구성도 제한한다. 지침에 역할을 쓰는 것과 도구로 가능한 행동을 제한하는 것이 함께 쓰인 사례다. Checker 구현
실행 루프에는 여러 동작을 묶어 처리할 때 보호 절차를 생략하는 경로도 있다. 따라서 프로젝트 소개의 일반적인 보호 표현을 모든 실행 경로에 대한 검증 결과로 옮기지 않는다. 여러 동작 실행 경로
이 기록은 구조와 판정 계약의 증류다. 모델의 판단 정확도, 실제 기기에서의 성공률, 설명된 성능 수치의 재현을 확인한 기록은 아니다.