화면에 완료 결과가 분명히 남는 작업이라면 ExeVRM은 에이전트 내부 상태 없이 실행 영상으로 성공 여부를 판정할 수 있습니다. 다만 결제 승인이나 파일의 실제 저장처럼 화면 밖 상태가 중요한 작업까지 영상 하나로 보증하지는 않습니다. 이 접근은 마지막 화면 한 장 대신 실행 전 과정의 변화를 보지만, 작은 오류 표시와 도메인 밖 UI를 놓칠 가능성은 따로 검증해야 합니다.
컴퓨터 에이전트가 일을 끝냈는지 영상만으로 알 수 있을까? ExeVRM의 조건
모든 프레임을 보지 않고 결정적인 변화만 남긴다
긴 화면 녹화에는 마우스 이동, 로딩 대기, 변하지 않은 배경이 대부분입니다. ExeVRM의 STP(Spatiotemporal Token Pruning)는 공간적으로 반복되는 UI 조각과 시간상 거의 변하지 않은 토큰을 덜어내고, 버튼 상태나 결과 메시지처럼 판정에 필요한 변화에 계산을 집중합니다.
이 설계가 중요한 이유는 정확도보다 먼저 비용에 있습니다. 원본 해상도의 모든 프레임을 그대로 넣으면 토큰 수가 빠르게 늘어납니다. 반면 가지치기가 지나치면 작은 체크 표시나 짧게 나타난 오류 창도 함께 사라질 수 있습니다. 작은 글자와 미세한 UI 변화가 많은 업무라면 압축률보다 누락률을 먼저 확인해야 합니다.
84.7이라는 숫자는 이 벤치마크 안에서 읽어야 한다
논문 페이지가 보고한 8B 모델의 정확도는 84.7, 재현율은 87.7입니다. 같은 평가표에서 GPT-5.2는 78.2, Gemini-3 Pro는 76.5로 제시됩니다. 이는 ExeVRM이 모든 컴퓨터 업무에서 더 낫다는 뜻이 아니라, 논문이 정의한 영상 판정 데이터와 절차에서 나온 비교값입니다.
실무 검증에서는 전체 정확도 하나보다 실패 비용을 나눠 봐야 합니다. 실제 실패를 성공으로 승인하는 오탐은 자동 배포나 결제 업무에서 특히 비쌉니다. 반대로 성공을 실패로 돌리는 경우에는 불필요한 재시도 비용이 생깁니다. 시간 구간을 얼마나 정확히 짚는지 보여 주는 temporal attribution도 함께 봐야 디버깅에 쓸 수 있습니다.
도입 전에는 화면 밖 상태와 도메인 이동을 시험한다
적용 순서는 단순합니다. 먼저 성공 여부가 화면에서 관찰 가능한 업무만 고르고, 현재 UI에서 실패 영상을 따로 모읍니다. 그다음 작은 글자, 팝업, 네트워크 지연, 앱 업데이트를 포함한 검증 세트로 오탐과 누락을 측정합니다. 마지막으로 고위험 작업은 사람이 다시 확인하도록 임계값을 보수적으로 둡니다.
8B라는 크기도 곧바로 저비용 로컬 실행을 뜻하지 않습니다. 영상 길이와 해상도, 가속기 메모리, 처리 지연을 함께 재야 합니다. 커스텀 사내 도구처럼 학습 분포와 다른 UI, 화면에는 성공처럼 보이지만 서버 반영이 안 된 작업, 보안상 녹화할 수 없는 화면은 ExeVRM만으로 닫을 수 없는 영역입니다.
성공과 실패 영상을 어떻게 수집할까
같은 작업에서 정상 완료, 중간 실패, 완료처럼 보이지만 저장되지 않은 경우, 성공 뒤 되돌린 경우를 함께 모읍니다. 단순히 오류 화면만 실패로 두면 모델이 빨간 배너나 “완료” 문구를 찾는 분류기로 흐를 수 있습니다. 화면은 비슷하지만 작업 지시가 다른 어려운 음성 사례를 포함해야 지시와 결과의 일치를 보게 할 수 있습니다.
각 영상에는 작업 지시, 실제 최종 상태, 중요한 시간 구간과 판정 이유를 사람이 표시합니다. 에이전트 종류, 운영체제, 앱 버전과 해상도도 기록해야 특정 UI에만 맞춘 성능을 찾을 수 있습니다. 훈련과 평가에서 같은 작업의 거의 동일한 녹화가 섞이지 않도록 분리합니다.
STP의 누락은 어떻게 평가할까
원본 영상에서 성공 판단에 필요한 프레임과 화면 영역을 사람이 표시하고 가지치기 뒤에 남았는지 확인합니다. 짧은 토스트 메시지, 비활성 버튼의 상태 변화, 작은 파일명과 체크박스를 별도 유형으로 나눕니다. 압축률이 높아도 결정 프레임을 자주 버리면 보상 모델의 입력부터 잘못됩니다.
영상 길이와 UI 변화량에 따라 가지치기 강도를 바꿔 오탐, 누락과 처리 비용의 곡선을 그립니다. 정적인 화면이 길게 이어지는 작업과 빠른 팝업이 많은 작업은 같은 설정이 맞지 않을 수 있습니다. 가지치기 전후의 판정 차이를 로그에 남기면 STP와 모델 추론의 오류를 분리할 수 있습니다.
화면 밖 상태는 어떤 검증기로 보완할까
파일 작업은 실제 경로와 내용, 웹 작업은 서버 응답이나 조회 API, 데이터베이스 작업은 트랜잭션 상태를 결정론적으로 확인할 수 있습니다. 영상 모델은 사용자 화면의 시각적 성공을 평가하고, 별도 검증기는 시스템 상태를 확인하는 두 관문으로 구성할 수 있습니다. 두 결과가 충돌하면 자동 승인하지 않고 조사 대상으로 보냅니다.
모든 앱에 내부 검증기를 만들 수 없다는 점이 ExeVRM의 동기이지만, 위험이 큰 작업까지 시각 판정만으로 통일할 이유는 없습니다. 읽기 전용 탐색과 UI 테스트는 영상 중심으로 시작하고, 결제, 배포, 삭제는 기존 시스템 확인을 유지합니다. 판정 모델의 편리함보다 실패 비용에 따라 검증 깊이를 정해야 합니다.
임계값은 오탐 비용으로 어떻게 정할까
실제 실패를 성공으로 승인하는 경우와 성공을 실패로 판단하는 경우의 비용이 다릅니다. 자동 배포의 거짓 성공은 위험하지만 테스트 재시도의 거짓 실패는 주로 시간 비용일 수 있습니다. 업무별로 두 오류의 허용 한도를 정하고 검증 세트에서 precision과 recall을 함께 봅니다.
모델 점수가 애매한 구간은 사람 검토나 추가 검증으로 보냅니다. 전체 정확도 84.7을 그대로 임계값으로 사용할 수는 없습니다. 자체 UI에서 점수 분포와 보정 상태를 확인하고 앱 업데이트 뒤 다시 측정해야 합니다. 고위험 작업은 더 보수적인 기준과 화면 밖 검증을 함께 둡니다.
도메인 이동은 어떤 변화로 시험할까
테마, 창 크기, 언어, 운영체제, 앱 버전과 네트워크 지연을 하나씩 바꿉니다. 버튼 위치만 이동한 경우와 완료 문구 자체가 바뀐 경우를 분리하면 모델이 화면 형태와 의미 중 무엇에 의존하는지 알 수 있습니다. 훈련에 없던 사내 도구와 원격 데스크톱 압축 영상도 별도 평가가 필요합니다.
UI가 바뀔 때마다 전체 모델을 다시 학습하기 전에 소수의 대표 영상을 수집해 회귀 테스트합니다. 성능이 크게 내려가면 자동 판정을 경고 모드로 낮추고 새로운 실패 데이터를 검수합니다. 벤치마크의 여러 운영체제 포함은 모든 미래 UI에 대한 일반화 보장이 아닙니다.
운영 비용과 개인정보는 어떻게 볼까
영상 길이, 프레임 샘플링, 해상도와 동시 작업 수에 따라 인코딩, 추론 메모리와 지연이 달라집니다. 한 작업당 녹화 저장량, STP 처리, 8B 모델 추론과 재시도 비용을 나눠 측정합니다. 실시간 보상에 쓸지 사후 판정에 쓸지에 따라 허용 지연도 다릅니다.
화면 녹화에는 비밀번호, 개인정보와 사내 문서가 포함될 수 있습니다. 녹화 금지 영역, 마스킹, 보존 기간과 접근 권한을 정하고 외부 모델로 전송되는지 확인합니다. 보안상 녹화할 수 없는 업무는 이 방식의 입력 전제 자체가 맞지 않을 수 있습니다.
운영 로그에는 원본 전체를 장기간 보관하지 않더라도 작업 ID, 판정 점수, 사용한 시간 구간, 모델, STP 버전과 최종 확인 결과를 남길 수 있습니다. 사람이 판정을 뒤집은 사례는 다음 평가 세트의 후보가 됩니다. 다만 오류 개선을 이유로 민감 영상의 보존 기간을 무제한 늘리지 말고, 재학습용 반출과 운영 감사용 접근을 분리해야 합니다.
모델 교체나 UI 개편 전후에는 동일 영상과 새로 수집한 영상을 함께 평가해야 합니다. 동일 영상은 판정기 자체의 변화를 보여 주고 새 영상은 실제 화면 변화의 영향을 보여 줍니다. 두 결과를 분리하면 성능 하락이 모델 업데이트 때문인지 도메인 변화 때문인지 더 정확히 판단할 수 있습니다.
함께 읽으면 이해가 이어지는 글
- 웹 스크래핑에 Chrome이 너무 무겁다면? Lightpanda가 맞는 작업 — 렌더링 화면을 버리고 DOM, JavaScript 실행에 집중한 Lightpanda의 구조, 벤치마크 수치와 스크린샷, 웹 API 호환성 한계를 정리합니다.
- Obscura는 정말 RAM 30MB로 V8을 돌릴까: CDP 호환성과 렌더링 공백 — Obscura의 30~40MB RAM, 70MB 바이너리, 85ms 시작 주장을 구분해 읽고, Blink를 덜어낸 대가인 CSS 렌더링, Web API, CDP 호환 공백을 점검합니다.
- UI-TARS는 Selenium을 대체할까: 픽셀 좌표 에이전트의 강점과 실패 — UI-TARS의 스크린샷 인지, 행동 전 추론, 통합 클릭, 타이핑 구조를 살펴보고 DOM 자동화와 비교해 좌표 지연, 비용, 승인 경계를 정합니다.
자주 묻는 질문
ExeVRM이 성공으로 판정하면 작업이 실제로 완료된 것인가요?
항상 그렇지는 않습니다. 화면에는 성공처럼 보여도 서버 저장, 결제 승인이나 파일 내용처럼 화면 밖 상태가 실패할 수 있어 고위험 작업은 별도 검증이 필요합니다.
STP로 토큰을 줄여도 작은 UI 변화를 놓치지 않나요?
놓칠 수 있습니다. 짧게 나타난 오류, 작은 체크 표시와 글자가 가지치기에서 사라질 수 있으므로 업무별 결정 프레임 누락률을 측정해야 합니다.
ExeVRM은 어떤 업무부터 시험하기 좋나요?
완료 상태가 화면에 분명히 남고 실패해도 되돌리기 쉬운 업무부터 시작해 현재 UI의 성공, 실패 영상에서 오탐과 누락을 측정하는 편이 좋습니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.