UI-Voyager 4B의 AndroidWorld 81.0% 성공률은 실패 궤적 학습의 가능성을 보여 주지만, 보지 못한 앱의 운영 자동화를 맡기기에 충분한 보증은 아닙니다.
UI-Voyager 4B의 81%가 앱 자동화에 충분할까: GRSD와 SSIM Fork
성공 궤적만 따라 하면 같은 실수를 배울 수 없다
일반적인 rejection fine-tuning(RFT)은 여러 번 실행한 뒤 성공한 궤적만 골라 학습합니다. 올바른 행동 형식을 가르치기에는 좋지만, 거의 같은 화면에서 어떤 클릭이 성공과 실패를 갈랐는지는 버립니다. UI-Voyager는 실패 궤적을 단순한 폐기물이 아니라 비교 대상으로 사용합니다.
성공 여부는 작업별 규칙 기반 verifier가 판정합니다. 따라서 모델의 자기평가만 믿지 않고 실제 앱 상태가 목표를 만족했는지 확인할 수 있습니다. 동시에 작업마다 올바른 성공 조건을 작성해야 하고, verifier가 틀리면 잘못된 궤적이 성공으로 들어갈 수 있습니다.
논문이 보고한 AndroidWorld 81.0%는 이 평가 환경과 작업 구성에서 나온 수치입니다. 다른 앱, 계정 상태, 언어와 UI 버전에서는 다시 측정해야 합니다.
GRSD는 갈라진 한 지점을 찾는다
GRSD는 성공과 실패 궤적에서 화면이 비슷하게 진행되다가 행동이 달라지는 fork point를 찾습니다. 그 지점 이전의 공통 이력은 길게 반복 학습하지 않고, 성공 행동과 실패 행동의 차이에 더 조밀한 감독 신호를 줍니다.
이 접근은 “이 버튼을 눌러야 했다”뿐 아니라 “겉보기 비슷한 이 버튼은 왜 틀렸는가”를 가르칠 수 있습니다. 특히 메뉴 항목이나 아이콘이 가까운 모바일 UI에서 유용한 신호입니다. 그러나 fork 이후의 차이가 화면 한 장만으로 설명되지 않고 이전 스크롤이나 입력 상태에 달려 있다면, 잘못된 원인을 한 행동에 귀속할 위험도 있습니다.
SSIM이 같다고 같은 상태는 아니다
fork 후보를 찾을 때 원문은 화면 유사도에 SSIM을 사용합니다. 픽셀 구조가 비슷한 두 프레임을 빠르게 찾는 데 유용하지만, 동적 광고, 시계, 애니메이션은 같은 상태를 다르게 보이게 할 수 있습니다. 반대로 텍스트 한 글자나 토글 상태처럼 작은 차이는 행동 의미가 크게 달라도 높은 유사도를 가질 수 있습니다.
원문에 있던 OpenCV, SSIM 코드는 개념 모형이며 궤적 스키마와 create_dense_supervision 같은 핵심 정의가 빠져 있습니다. 완전한 fork 탐지 구현으로 실행할 수 없습니다. 실제 파이프라인에서는 SSIM 임계치만 쓰지 말고 화면 요소, 앱 상태와 직전 행동을 함께 확인해야 합니다.
동적 UI가 많은 앱에서는 다음 샘플을 사람이 검토해 임계치를 정하는 것이 좋습니다.
- 같은 상태지만 애니메이션만 다른 화면
- 토글 하나만 바뀌어 의미가 달라진 화면
- 팝업이 겹쳐 클릭 대상이 가려진 화면
- 스크롤 위치가 조금 달라진 화면
4B 모델의 장점과 배포 전 한계
작은 모델은 반복 호출과 디바이스 배치에 유리할 수 있지만 파라미터 수만으로 메모리, 지연이나 정확도를 단정할 수 없습니다. 화면 해상도, 시각 토큰 수, 실행 런타임과 양자화가 실제 자원을 결정합니다. 원문이 말하는 4B와 81%를 “어떤 기기에서나 무료 실시간 실행”으로 확대해 해석하면 안 됩니다.
GUI 에이전트는 한 번의 잘못된 클릭이 메시지 전송, 결제나 삭제로 이어질 수 있습니다. 읽기와 탐색 작업부터 시작하고, 외부 효과가 있는 행동 앞에는 승인과 되돌리기 경로를 둬야 합니다. 성공률 81%는 반복 업무 100번 중 남은 실패가 운영 사고가 될 수 있다는 뜻이기도 합니다.
평가할 때 평균 성공률을 쪼개 본다
먼저 팀의 실제 앱에서 20~30개 작업을 정하고 로그인, 스크롤, 텍스트 입력, 팝업 처리처럼 행동 유형별로 나눕니다. 성공률과 함께 첫 fork 위치, 복구 횟수, 불필요한 클릭 수와 verifier 오판을 기록합니다. 앱 업데이트 후 같은 궤적이 유지되는지도 확인해야 합니다.
UI-Voyager의 실질적인 아이디어는 작은 모델 자체보다 실패와 성공이 갈라지는 화면을 학습 자산으로 바꾸는 것입니다. 자체 궤적에 적용하려면 먼저 믿을 수 있는 verifier와 상태 비교기를 만들 수 있는지 판단해야 합니다. 그 두 가지가 없으면 실패 데이터가 오히려 잘못된 감독 신호가 됩니다.
Verifier는 최종 화면만 보면 충분할까
최종 상태가 목표처럼 보여도 중간에 허용되지 않은 작업을 했을 수 있습니다. 설정을 바꿨다가 되돌리거나 다른 파일을 열어 민감 정보를 노출한 뒤 마지막 화면만 맞춘 궤적을 성공으로 분류하면 위험한 행동이 학습됩니다. 작업 결과, 금지된 외부 효과, 행동 수와 대상 앱을 함께 검사해야 합니다.
성공 조건은 앱 내부 상태나 파일 결과처럼 가능한 한 결정적 값으로 확인합니다. 화면 텍스트만 읽으면 가려진 팝업, 저장되지 않은 편집이나 토스트 메시지를 완료로 오인할 수 있습니다. UI 화면과 구조화된 상태가 불일치할 때 어느 쪽을 기준으로 할지 작업별로 정하고, 판정 불가능은 성공, 실패와 별도 상태로 남깁니다.
Verifier 자체도 회귀 세트가 필요합니다. 정상 완료, 거의 완료, 잘못된 계정, 파일, 되돌릴 수 없는 부작용을 포함하고 앱 버전이 바뀔 때 다시 실행합니다. 모델 학습 전 성공 라벨의 오판율을 확인하지 않으면 81% 같은 에이전트 점수보다 라벨 오류가 결과를 더 크게 좌우할 수 있습니다.
Fork가 실제 실패 원인인지 어떻게 확인할까
성공과 실패가 처음 갈라진 행동이 원인처럼 보여도 앞선 숨은 상태가 달랐을 수 있습니다. 같은 fork 화면에서 성공 행동을 실패 궤적의 상태에 재실행해 결과가 복구되는지 확인하면 인과 근거가 강해집니다. 반대로 행동을 바꿔도 실패한다면 더 앞선 입력, 스크롤, 계정 상태를 찾아야 합니다.
화면 유사도 외에 접근성 트리나 앱 상태를 사용할 수 있다면 함께 비교합니다. SSIM은 위치와 픽셀에 민감하지만 작은 토글의 의미를 모르고, 구조 정보는 캔버스나 게임 UI를 놓칠 수 있습니다. 두 신호가 불일치한 후보는 자동 dense supervision보다 사람 검토 대상으로 보내는 편이 낫습니다.
여러 성공 경로가 있는 작업에서는 하나와 다른 행동을 모두 실패로 처리하지 않습니다. 메뉴 클릭과 단축키가 같은 결과를 만들 수 있으므로 최종 상태와 금지 행동을 통과한 경로는 각각 합법적인 궤적으로 남깁니다. GRSD의 목적은 한 경로를 외우는 것이 아니라 비슷한 상태에서 결과를 망치는 선택을 구분하는 것입니다.
실패 데이터는 어떤 비율과 순서로 넣을까
실패가 많다고 모두 학습에 유용한 것은 아닙니다. 실행 환경 장애, 네트워크 시간 초과와 잘못 작성된 작업처럼 모델 행동과 관계없는 실패를 분리합니다. 같은 잘못된 클릭이 수천 번 반복된 데이터는 다양한 fork보다 특정 화면을 과도하게 강조할 수 있어 오류 유형과 앱별로 균형을 맞춥니다.
먼저 성공 궤적으로 기본 행동 형식과 정상 경로를 익힌 뒤, 의미가 명확한 fork 쌍을 추가하는 실험과 처음부터 함께 학습하는 실험을 비교할 수 있습니다. 실패 신호를 늘렸는데 정상 화면에서도 지나치게 주저하거나 행동을 거부한다면 부정 예시의 가중치가 과한 것입니다.
학습 체크포인트마다 보지 못한 앱, 새 레이아웃, 실패 복구를 평가합니다. 훈련 앱의 성공률만 오르고 새 앱에서 떨어지면 dense supervision이 특정 좌표와 아이콘을 외운 것일 수 있습니다. 앱별 오류 표를 남겨 데이터 추가가 일반 능력과 특정 화면 기억 중 무엇을 늘렸는지 구분합니다.
4B 모델의 종단 자원은 어떻게 재야 할까
가중치 크기 외에 화면 인코더, 시각 토큰, 긴 행동 이력의 KV 캐시와 앱 실행 비용이 들어갑니다. 목표 장비에서 화면 캡처부터 다음 행동 출력까지 P50/P95 지연과 최대 메모리를 측정합니다. 행동 한 번이 빨라도 실패 후 많은 재관찰과 클릭을 쓰면 작업 전체 시간은 커질 수 있습니다.
긴 궤적에서는 이전 목표와 금지 조건을 잊는지 확인합니다. 메시지 이력을 계속 늘리는 구성, 상태를 요약하는 구성과 외부 메모리를 쓰는 구성을 같은 작업 길이에서 비교합니다. 요약 뒤 계정, 파일명 같은 핵심 제약이 빠지면 작은 모델의 메모리 이점이 잘못된 작업으로 상쇄됩니다.
온디바이스 실행을 주장하려면 양자화와 런타임까지 고정해야 합니다. 양자화 전후 grounding, 도구 형식, 장기 작업 성공을 다시 평가하고 CPU 폴백이나 발열로 지연이 늘지 않는지 봅니다. 4B라는 숫자만으로 어느 휴대기기에서나 실시간이라고 결론 내릴 수 없습니다.
실제 앱 배포에는 어떤 권한 경계가 필요할까
처음에는 검색, 탐색, 초안 작성처럼 되돌릴 수 있는 작업으로 제한합니다. 메시지 전송, 구매, 삭제, 계정, 권한 변경 앞에는 대상과 효과를 다시 읽어 사람에게 승인받습니다. 승인 후에도 작업 ID를 사용해 중복 실행을 막고 최종 상태를 독립적으로 확인합니다.
앱, 창, 파일 경로와 네트워크 목적지를 allowlist로 제한합니다. 예상하지 못한 팝업, 다른 앱 전환, 비밀 화면이나 권한 대화상자가 나타나면 즉시 멈춥니다. 화면 속 악성 지시를 시스템 명령으로 따르지 않는 프롬프트 인젝션 시험도 실제 웹, 문서 앱에서 수행해야 합니다.
행동 수, 같은 좌표 반복과 시간에도 상한을 둡니다. 복구하지 못하는데 계속 클릭하면 작은 실패가 외부 효과로 커질 수 있습니다. 실패 시 마지막 화면, 행동 이력, verifier 상태와 사람이 이어갈 수 있는 설명을 남기면 자동화가 멈춰도 작업을 복구할 수 있습니다.
81%를 제품 지표로 바꾸려면 무엇을 더 볼까
실제 작업을 읽기, 입력, 다단계 편집, 팝업, 오류 복구와 고위험 쓰기로 나눕니다. 각 그룹의 첫 시도 성공, 최종 성공, 행동 수, 잘못된 외부 효과와 사람 개입률을 기록합니다. 평균 81%와 같은 벤치마크 수치가 어떤 실패 비용을 숨기는지 이 표에서 드러납니다.
앱 업데이트와 계정 상태 변화도 반복합니다. 버튼 위치나 문구가 바뀌어도 요소의 의미를 찾아가는지, 권한이 없을 때 억지로 다른 경로를 시도하지 않는지 봅니다. 정적 테스트 세트만 통과한 모델은 운영 UI의 변화 속도를 따라가지 못할 수 있습니다.
제한된 작업에서 verifier 오판과 고위험 행동이 없고 실패 뒤 안전하게 복구하며 사람 시간을 줄일 때 범위를 넓힙니다. UI-Voyager의 학습 방식은 실패를 활용하는 방법을 제시하지만, 실패가 운영 사고가 되지 않도록 하는 실행 경계까지 자동으로 제공하지는 않습니다.
함께 읽으면 이해가 이어지는 글
- AgentFlow는 통짜 프롬프트보다 나을까: 4개 모듈과 Flow-GRPO의 비용 — Planner, Executor, Verifier, Generator로 흐름을 나누는 AgentFlow의 추적 가능성과, Flow-GRPO 학습, 검증 병목, 반복 호출 비용을 비교합니다.
- UniT는 Best-of-N보다 순차 편집이 나을까: 3.6회 학습, 4.7회 추론의 비용 — 같은 이미지 생성 예산에서 순차 수정이 병렬 후보보다 나았던 이유와 verifier 오류, 과편집, 중단 비용을 살펴봅니다.
- TinyZero는 정말 30달러로 추론 모델을 만들까? 가능한 문제의 조건 — TinyZero의 저비용 강화학습 재현이 성립하는 Countdown형 검증 문제와 모델 규모를 살펴보고, 이를 범용 자가 진화 AI로 확대 해석하면 안 되는 이유를 설명합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.