‘작업 완료’라는 AI의 말을 어떻게 확인할까: VeriCUA

배경과 문제

컴퓨터 사용 에이전트(CUA)는 화면을 보고 클릭·입력·파일 저장을 수행한다. 학습이나 평가를 위해서는 그 실행이 성공했는지 판정해야 한다. 이해를 위한 예로, 메모 내용을 입력한 화면과 “완료” 메시지가 있어도 실제 저장 파일은 없을 수 있다. 검증기는 시도한 행동과 남은 결과를 구분해야 하며, 이 논문은 작업을 수행하는 에이전트 자체보다 그 뒤의 판정 과정을 개선한다.

기존 방식은 화면 몇 장을 한 번에 읽는 VLM 판정기와, 작업별로 프로그램을 만들어 상태를 검사하는 생성 검증기로 나뉜다. 화면에 결정적 순간이 없거나 프로그램이 엉뚱한 저장 위치를 읽으면 둘 다 오판할 수 있다. 저자들은 검사 대상을 고정하기보다, 무엇이 아직 확인되지 않았는지에 따라 다음 읽기를 선택하도록 설계한다.

기존 접근의 한계

VLM 판정기는 주어진 화면 밖의 정보를 스스로 확인하기 어렵다. 논문의 동영상 사례에서는 하나만 녹화하라는 지시에 세 개를 만든 뒤 카메라의 마지막 화면만 보고 성공으로 오인했다. 반대로 음악 큐가 정상적으로 저장됐어도 화면에 보이지 않으면 실패로 볼 수 있다. 최종 화면 하나가 모든 작업의 성공 조건을 표현하지는 않는다.

생성 검증기는 파일·데이터베이스를 읽을 수 있어도 저장 구조를 잘못 가정할 수 있다. 첫 동영상 하나를 찾고 멈추거나, 음악 앱의 잘못된 테이블을 읽는 사례가 나왔다. 따라서 코드 도구의 유무뿐 아니라 실제 증거 위치를 먼저 살피는 과정이 중요하다. 다만 비교 대상도 충분한 기기 접근 권한은 받았으므로, 단순히 도구 사용을 막아서 차이가 난 실험은 아니다.

연구방법을 단계별로

VeriCUA는 검증을 '에이전트적 탐색'으로 재정의한다. 실행 에이전트의 시도가 끝난 뒤 검증기가 작동하며, 온라인에서는 성공·실패·보류(abstain)를 출력한다. 오프라인에서 미해결이면 탐색 전에 계산해 숨겨 둔 VLM 초기 판정을 최종 답으로 사용한다. 전체 절차는 네 단계로 나뉜다. 첫째, 문맥 검사(context inspection)로 앱 패키지, 관련 디렉터리, 데이터베이스 스키마, 또는 기록된 화면과 행동 로그를 살펴본다. 둘째, 루브릭 합성(rubric synthesis)으로 지시문과 관찰된 문맥을 바탕으로 세분화된 요구사항 목록을 만든다. 각 요구사항은 성공에 필수인 hard와 부가적인 soft로 표시된다. 셋째, 능동 탐색(active exploration)으로 아직 해결되지 않은 요구사항에 대해 GUI 검사(스크린샷, 확대, OCR)나 코드 검사(파일 읽기, 데이터베이스 질의)를 선택해 수행한다. 넷째, 규칙 기반 중재(rule-based arbitration)로 수집된 증거를 종합해 최종 판정을 내린다.

문맥 검사는 요구사항을 만들기 전에 수행한다. “메모를 저장하라”는 지시만 보고 존재하지 않는 파일 경로나 인터페이스를 가정하지 않도록 앱 구조와 디렉터리를 먼저 읽는다. 발견한 디렉터리는 증거를 찾을 장소이며, 그곳을 찾았다는 사실 자체가 저장 성공은 아니다. 저장 작업처럼 변화가 중요한 경우에는 실행 전 상태와 비교할 기준도 사용한다.

탐색 중에는 프레임 선택·확대·OCR과 파일·데이터베이스·시스템 조회를 결합한다. 온라인 체커는 읽기 전용 getter와 그 결과를 판단하는 조건으로 구성된다. 예컨대 파일 존재와 내용 일치를 함께 검사할 수 있다. 실제 호출 결과에 시점·출처·영속성 정보를 붙여 저장하고, 미확인 조건에 따라 다음 검사를 고른다. 검증 과정이 작업을 대신 완성하도록 상태를 바꾸는 방식은 아니다.

증거 규율(evidence discipline)은 VeriCUA의 핵심 설계다. 탐색 중 각 발견 사항은 실제 실행된 검사에 연결되어야 하며, 실행되지 않은 호출을 인용하면 하네스(harness)가 거부한다. 증거는 attested(입증됨)와 asserted(주장됨)로 구분된다. 파일 읽기, 데이터베이스 질의, 행동 후 프레임은 attested 증거다. 반면 에이전트의 '완료' 메시지나 행동 전 프레임은 asserted 증거로, 추가 조사를 유도할 수는 있지만 그 자체로 요구사항 충족을 입증하지 못한다. 온라인에서는 영속적 저장소(파일, DB)와 휘발성 인터페이스(현재 화면)를 구분한다. 화면에 편집된 텍스트가 보이는 것은 내용을 뒷받침하지만, 파일 읽기는 저장 여부를 확인한다. 최종 중재는 결정적 규칙을 따른다. 확인된 근거가 hard 요구사항 전부를 뒷받침하면 성공이다. 서로 다른 검사로 반박이 확인되면 실패, 해결하지 못한 조건이 남으면 온라인 보류 또는 오프라인 초기 판정 복귀를 적용한다.

결과와 숫자의 의미

주요 비교는 모두 gemini-3-flash-preview 판정기를 썼다. 온라인 표본은 AndroidWorld 116개, OSWorld 361개, ScienceBoard 169개이며 정답 기준은 공식 검사기다. 정확도는 작업 수행 성공률이 아니라 기준 정답과 판정의 일치율이다. AndroidWorld에서 VLM·생성 검증기·VeriCUA의 정확도는 78.4%·82.4%·90.5%, 오탐률은 15.4%·16.9%·7.7%였다. OSWorld 정확도는 73.4%·75.9%·79.5%, ScienceBoard는 71.6%·76.9%·86.4%였다. ScienceBoard 오탐률은 VLM 24.8%, 생성 검증기 21.7%, VeriCUA 5.4%로 낮았다. 이 비교만으로 개선의 원인을 문맥 검사 하나에 모두 돌릴 수는 없다.

온라인에서 판정을 결정한 비율은 AndroidWorld 82%, OSWorld 78%, ScienceBoard 70%다. 그 사례만의 정확도는 95.1%·88.7%·91.6%이며 전체 정확도와 구분해야 한다. 전체 지표는 보류를 실패 판정으로 취급하므로 실제 성공을 놓치는 대가가 있다. OSWorld의 성공 재현율은 생성 검증기 78.1%, VeriCUA 71.3%, ScienceBoard는 72.5% 대 60.0%였다. 낮은 오탐률과 높은 성공 포착률이 동시에 보장된 결과는 아니다.

오프라인 검증에서도 VeriCUA는 논문의 비교 설정에서 가장 높은 정확도와 균형 정확도를 보였다. OSReward-Hard(어려운 284개)에서 정확도는 TRM 57.4%, CUAJudge 63.4%, OS-Themis 65.7%, VeriCUA 70.4%였다. 전체 OSReward(1019개)에서는 82.2% → 83.7% → 80.2% → 87.2%, WebArena(715개)에서는 79.6% → 81.3% → 75.4% → 82.7%였다. OSReward는 사람의 라벨을, WebArena는 공식 검사기를 정답 기준으로 쓴다. WebArena에서는 세 가지 실행 에이전트(Claude Sonnet 4.6, Gemini 3.1 Pro, Gemini 3 Flash) 모두에서 VeriCUA가 앞섰다.

구체적인 예시

논문의 사례 연구는 VeriCUA가 어떻게 오판을 피하는지 보여준다. AndroidWorld의 '동영상 하나를 찍으라'는 작업에서 에이전트는 세 개의 클립을 녹화하고 완료를 주장했다. VLM 판정기는 유휴 카메라와 저장된 썸네일을 보고 성공으로, 생성 검증기는 첫 번째 동영상만 찾고 성공으로 판정했다. VeriCUA는 미디어 저장소에 content_query를 실행해 에피소드 시작 이후 세 개의 새 비디오 행이 추가된 것을 확인하고, Movies 디렉터리 목록에서도 같은 세 파일을 발견했다. '정확히 하나의 새 동영상'이라는 하드 요구사항이 충족되지 않았으므로 실패를 판정했다. 네 번의 검증 패스 중 세 번이 실패, 한 번이 보류였다.

반대로 음악 앱에 노래 세 곡을 순서대로 추가하는 작업에서는 VLM 판정기와 생성 검증기가 모두 실패로 판정했지만 VeriCUA는 성공을 확인했다. 재생 큐는 앱 데이터베이스에만 있고 최종 화면에는 나타나지 않았다. VeriCUA는 환경 맵을 통해 재생 데이터베이스를 찾아 sqlite_query로 세 곡의 제목이 요청한 순서대로 있는지 확인했다. UI 덤프는 네 번 시도했지만 생성되지 않아 판정은 데이터베이스 읽기에만 의존했다. 이는 화면에 보이지 않는 영속 상태가 결정적 증거가 될 수 있음을 보여준다.

오프라인 기록에서도 유사한 사례가 있다. LibreOffice Impress에서 'BREAKING NEWS' 텍스트를 중앙에 배치한 슬라이드를 만들어 비디오로 내보내는 작업에서, 모든 기존 판정기는 완성된 내보내기 파일과 바탕화면의 파일을 보고 성공으로 판정했다. VeriCUA는 66번째 단계의 미리보기 프레임을 읽어 텍스트가 빈 검은 화면 위쪽에 있고 중앙이 비어 있음을 발견했다. 또한 7번째 단계의 행동 검사를 통해 텍스트가 슬라이드의 제목 자리표시자에 입력되어 위치가 고정되었음을 확인했다. '텍스트가 비디오 프레임 중앙에 있다'는 하드 요구사항이 충족되지 않아 실패로 판정했다. 웹 작업에서는 최종 화면에 25달러 미만 상품이 보였지만, a11ytree를 읽어 URL과 페이지 제목이 '여성 신발' 키워드 검색 결과이고 25달러를 넘는 가격이 여러 개 나열되어 있음을 확인해 실패로 판정했다.

한계와 오해하기 쉬운 점

검증에는 수십 번의 도구·모델 호출이 필요해 단일 판정 호출보다 지연과 비용이 커진다. 논문은 데이터 필터링·보상 검토 같은 일괄 처리 용도를 제시하지만, 실제 서비스의 비용 대비 효과를 입증한 것은 아니다. 오프라인 기록에 필요한 증거가 없으면 온라인처럼 보류하는 대신 최초 VLM 판정으로 돌아간다. WebArena의 23%가 이 경우였으며, 해결되지 않은 요구사항까지 확인됐다는 뜻은 아니다. 확률적 실행 간 변동도 남는다.

비교 구현도 해석에 중요하다. CUAJudge는 원래 네 단계를 한 호출로 줄여 별도 프레임 선택 등을 생략했고, OS-Themis도 호출·프레임 예산을 줄였다. 원 예산을 복원한 추가 실험은 있으나 원형 구현 전체와의 동일 비교는 아니다. Figure 5의 약 80% 거짓 완료 보고 거부는 선별된 AndroidWorld 14개·OSWorld 74개·ScienceBoard 40개 사례의 결과다. 전체 작업 정확도나 운영 안전 보장이 아니다. 본문의 AndroidWorld 오탐률 7.7%와 부록 표의 3/41은 계산상 일치하지 않아, 여기서는 본문 Table 1의 보고값을 사용했다.

실제로 어떻게 활용할까

활용을 검토할 때는 완료 선언 대신 파일·데이터베이스·후속 화면에서 작업 조건을 확인하는 구조를 참고할 수 있다. 데이터셋에서 성공 실행을 고르거나 보상 후보를 점검하는 데도 적용할 여지가 있다. 다만 보류를 실패로 처리하면 진짜 성공도 제외될 수 있으므로, 비용과 오탐·누락을 함께 측정해야 한다. 이 논문이 이 검증기를 넣은 강화학습의 최종 성능까지 개선했다고 보고한 것은 아니다.

참조 라벨과 불일치하는 사례를 사람에게 우선 검토시키는 감사 도구로도 쓸 수 있다. 논문의 모델 판정기는 표시된 81건 중 51건에서 VeriCUA 쪽을 지지했고, OSWorld에서는 57건 중 37건이었다. 이는 모델끼리의 추가 판정이며 전체 라벨의 63%가 틀렸다는 뜻이 아니다. 실제 배포에서는 접근 가능한 상태, 기록 누락과 오프라인 초기 판정 복귀 비율을 따로 확인하고, 판정기가 확신한다고 오류가 없다고 받아들이지 않는 편이 적절하다.