저장 여부를 모를 때 무엇을 더 읽을까: VeriCUA의 상태 탐색·판정 보류·검증 비용

메모 편집기에 요청한 문장이 보인다. 자동화 에이전트도 완료했다고 답했다. 그런데 앱을 닫았다가 다시 열면 그 문장은 남아 있을까? 화면의 글자를 읽는 검사는 현재 보이는 내용에는 답하지만, 저장된 결과에 대해서는 충분하지 않을 수 있다. 이때 중요한 질문은 “완료라는 말을 믿을까”에서 끝나지 않는다. 아직 해결되지 않은 요구사항이 무엇이며, 그것을 해결하려면 다음에 어느 상태를 읽어야 하는지가 핵심이다.

VeriCUA는 작업 실행이 끝난 뒤, 앱과 기록의 맥락을 먼저 탐색하고 요구사항별 증거를 더 모으는 검증 프레임워크다. 이 글은 2026년 10월 29일자 arXiv v1 원문을 대상으로 한다. 심사 완료를 확인한 논문이나 바로 설치해 검증한 제품이 아니라 프리프린트의 방법과 저자 보고 결과를 분석한다. 직접 모델 실행이나 벤치마크 재현은 하지 않았다.

1. 파일부터 읽기 전에, 무엇이 저장인지 알아야 한다

설명을 위한 가상 예를 생각해 보자. 사용자는 “메모 앱에 다음 문장을 저장해 줘”라고 요청했다. 화면에는 문장이 있지만 저장 경로는 아직 모른다. 임의의 텍스트 파일을 찾아 문장 일치만 확인하면 다른 파일을 검증할 수도 있다. 반대로 앱이 내부 데이터베이스를 쓰는데 파일이 없다는 이유로 실패를 선언하는 것도 잘못이다. 이 예는 실제 실행 로그나 논문의 측정 사례를 재현한 화면이 아니다.

논문의 순서는 그래서 중요하다. 먼저 접근 가능한 앱 패키지, 디렉터리, 데이터베이스 구조 또는 녹화 기록을 살펴 맥락을 얻고, 그다음 사용자 요청을 점검 가능한 필수 조건과 보조 조건으로 나눈다. 발견한 디렉터리는 증거를 찾는 장소이지, 사용자가 요구하지 않은 새로운 성공 조건이 아니다. “이 경로에 있어야 한다”를 검증기가 임의로 덧붙이면 원래 작업과 다른 시험이 된다. [원문 §3.1–3.2, pp.4–5]

설명용 가상 메모의 증거 경로. 앱 맥락으로 저장 대상을 찾되, 그 위치를 새 요구사항으로 만들지 않는다. 실제 실행 화면이 아니다. 출처: arxiv.org/abs/2610.40578v1.

맥락이 정리되면 미해결 조건에 맞춰 다음 검사를 고른다. 화면이 흐리면 확대하거나 다른 시점의 프레임을 읽고, 저장 여부가 남으면 파일이나 앱 저장소를 읽는다. 각 발견은 실제 실행한 검사와 연결되고, 관찰 시점과 영속성 같은 속성을 함께 가진다. 행위자가 완료했다고 말한 기록은 탐색 방향을 제시할 수 있지만, 그 주장만으로 조건을 충족했다고 판정하지 않는다. [§3.3–3.4, pp.5–6]

2. 다음 읽기를 고르는 결정표

저장이 요구사항이면 화면을 한 번 더 보는 것보다, 해당 앱이 실제로 사용하는 저장 대상을 먼저 식별하는 편이 질문에 맞다. 다만 모든 작업에서 데이터베이스를 읽으라는 뜻은 아니다. 시각적 배치가 요구사항이면 저장된 문자열만으로는 충분하지 않다. 작업의 목표와 증거의 성질이 일치해야 한다.

아래 결정표는 논문을 바탕으로 작성한 설계 제안이며, VeriCUA 실행이나 실제 업무 시스템의 재현 결과가 아니다.

아직 모르는 것	다음에 읽을 후보	그 읽기가 답하는 범위	멈추거나 보류할 조건
화면의 문장이 실제 저장됐는가	앱 맥락으로 식별한 파일 또는 저장 레코드	요청 내용이 영속 대상에 있는가	저장 대상 식별 실패, 접근 권한 없음
기존 데이터가 이번 실행에서 바뀌었는가	실행 전 기준과 종료 상태, 적절한 시간 정보	이전부터 있던 결과와 이번 변경의 구별	비교할 기준이 없고 현재 상태만으로 변화 입증 불가
요청한 배치·모양이 맞는가	작업 이후의 화면, 필요한 영역 확대	실제 보이는 배치와 표시 내용	실행 전 프레임뿐이거나 화면이 누락됨
기록 속 저장 버튼 누름이 성공했는가	이후 프레임과 보존된 결과물	시도 이후에 관찰된 효과	클릭 로그만 남고 결과 관찰 없음
두 증거가 서로 어긋나는가	동일 요구사항에 대한 다른 출처·시점	출처·시점 차이로 모순을 설명할 수 있는가	예산 소진 뒤에도 필수 조건 미해결

실무에 옮길 때의 최소 기록 단위는 “요구사항, 읽은 대상, 관찰 시점, 실제 반환값, 그 값이 지지하는 범위, 남은 의문”이다. 이는 이 글의 설계 제안이다. 파일이 있다는 사실과 요청 내용이 맞다는 사실, 실행 이전부터 있던 파일과 이번에 저장한 파일을 분리하면 불필요한 반복 캡처를 줄일 여지가 있다. 여기서 비용 절감량을 측정했다는 뜻은 아니다.

온라인 보류와 보고된 오프라인 대체 정책은 다르다. 초기 판정 대체가 미해결 조건에 관찰 증거를 추가하지는 않는다. 출처: arxiv.org/abs/2610.40578v1.

3. 모른다는 상태는 실패와 같지 않다

VeriCUA의 조건별 상태는 충족·불충족·미해결로 나뉜다. 필수 조건이 모두 충족되면 성공, 하나라도 불충족이면 실패다. 불충족은 없지만 미해결 조건이 남으면 설정별 정책으로 넘어간다. 온라인 환경에서는 해결되지 않은 작업에 판정을 보류한다. 논문의 이진 평가에서는 이 보류를 실패로 접어 계산하지만, 이것이 곧 “실제로 저장되지 않았다”는 관찰은 아니다. [§3.4–3.5, Appendix B.4]

오프라인은 다른 제약을 갖는다. 녹화하지 않은 저장 상태를 나중에 읽어낼 수는 없다. 논문의 보고 설정은 탐색 전에 계산하고 탐색 경로에는 숨겨 둔 초기 VLM 판정으로 최종 결론을 대체한다. 이 대체가 미해결 조건을 새 증거로 채우는 것은 아니다. 온라인의 보류와 오프라인의 초기 판정 대체를 같은 신뢰도 정책으로 설명해서는 안 된다. [§3.5, p.7; Appendix A.3]

따라서 운영 설계에서도 미해결 사유를 별도로 보존하는 것이 유용하다. “접근 불가”, “필요한 시점 누락”, “증거 충돌”, “검사 예산 소진”은 다음 조치가 다르다. 권한 부족을 자동으로 실패나 권한 확대의 근거로 바꾸지 말고, 승인된 읽기 범위 안에서 더 확인할 수 있는지를 결정해야 한다.

4. 상태 읽기가 늘린 것은 작업 성공률이 아니라 판정 범위다

AndroidWorld의 도구 구성 비교는 이 주제를 가장 직접적으로 보여 준다. GUI만 사용했을 때와 파일·앱 저장소 읽기를 더한 혼합 구성을 비교하면, 공식 평가기와의 일치율은 77.0%에서 90.5%, 판정률은 45%에서 82%로 높아졌다. 두 구성 모두 거짓 양성 건수는 공식 실패 41건 중 3건이었다. 전체 평가 에피소드는 116개다. [§5.1, Table C.1 p.19; Table B.1]

저자 보고 구성 비교. 일치율은 공식 평가기 기준이며 작업 수행 성공률이 아니다. 판정률 분모는 전체 116개, 거짓 양성 분모는 공식 실패 41개다. 출처: arxiv.org/abs/2610.40578v1.

판정률의 분모는 전체 에피소드이며, 판정한 사례만의 정확도와는 다르다. 보류를 실패로 처리한 전체 일치율과도 구별해야 한다. 반올림된 판정률에서 정확한 판정 건수를 역산하지 않았다. 저자들은 코드 채널로 추가된 올바른 판정이 파일 또는 앱 저장소 읽기에 의해 뒷받침됐다고 보고한다. 하지만 이는 특정 환경의 구성 비교다. 어느 업무 앱에서나 동일한 개선이 나온다는 독립적인 인과 검증은 아니다.

OSWorld의 주 비교도 별도 맥락으로 읽어야 한다. 361개 에피소드에서 최종 화면을 보는 VLM 판정기와 VeriCUA의 일치율은 각각 73.4%, 79.5%, 거짓 양성률은 27.9%, 13.9%였다. VeriCUA의 판정률은 78%, 판정한 사례의 정확도는 88.7%다. 거짓 양성률의 분모는 전체 361개가 아니라 공식 실패 하위 집합이다. [Table 1 p.8; B.1/B.4]

여기에는 대가도 있다. OSWorld에서 자동 생성 검증기의 성공 재현율은 78.1%로 VeriCUA의 71.3%보다 높다. 보수적으로 성공을 인정하면 실제 성공 일부도 놓칠 수 있다. 게다가 입력 정보, 상태 접근, 모델 호출 예산이 같지 않다. 이 수치를 에이전트의 작업 수행 성공률 개선이나 동일 비용 우위로 소개하는 것은 과장이다.

5. 더 읽는 검증은 공짜가 아니다

검증을 매 단계 실시간으로 붙일지, 종료 후 고위험 사례에 붙일지는 비용을 보고 정해야 한다. 논문 Table C.9의 오프라인 OSReward에서 VeriCUA는 궤적 하나당 345K–378K 토큰을 사용했다. 비교 대상은 단일 판정기가 아니라 세 판정기를 합친 4회 호출이며, 합계 33K–35K 토큰이다. K는 천 토큰 단위다. 이 범위는 신뢰구간으로 제시된 것이 아니다. [Appendix C.5, p.23]

저자 보고 오프라인 토큰 수 비교. K는 천 토큰이며 범위는 신뢰구간이 아니다. 세 판정기 합계 4회 호출과 비교하며 금액·온라인 지연 시간으로 해석하지 않는다. 출처: arxiv.org/abs/2610.40578v1.

이는 오프라인 토큰 사용량 비교이지 온라인 OSWorld의 지연 시간이나 통화 비용이 아니다. API 단가를 대입해 비용 절감액을 만들어 내지 않았다. 검증 품질과 함께 호출량·판정 범위·성공 누락을 기록해야 한다는 것이 이 글의 해석이다. 모든 사소한 클릭에 무거운 탐색을 붙이기보다, 데이터 선별·보상 신호 생성처럼 잘못된 성공 승인 비용이 큰 구간부터 적용할 만하다. 이 역시 실제 배포 효과를 측정한 추천은 아니다.

접근 권한도 비용과 별개인 경계다. 저자들은 허용 목록 기반 읽기 도구, 셸 제어를 끼워 넣을 수 있는 인수의 거부, 영속 대상의 전후 다이제스트 비교를 설명한다. AndroidWorld 어댑터에는 root adb 접근과 종료 상태 스냅샷이 있다. 일반 사용자 기기나 운영 데이터베이스에서 같은 접근을 당연시할 수 없다. 영속 대상의 다이제스트가 같다고 해서 화면 등 모든 부작용이 없었다는 독립 보안 인증이 되는 것도 아니다. [Appendix A.4–A.5, p.17]

결론: 다음 검사를 정하는 기준을 바꾼다

VeriCUA에서 가져올 핵심은 “더 많은 스크린샷”도 “항상 DB를 읽기”도 아니다. 앱 맥락을 먼저 파악하고, 원래 요청에서 나온 필수 조건을 유지하며, 아직 모르는 조건에 답할 증거를 선택하는 순서다. 저장 확인이라면 영속 상태가, 시각적 결과라면 적절한 시점의 화면이 중요하다. 둘 다 얻지 못했을 때는 미해결 상태와 처리 정책을 남겨야 한다.

이 글의 표와 그림은 그 선택을 돕기 위한 원문 기반 분석이다. 벤치마크 결과는 저자 보고이며, 모든 앱으로의 일반화·동일 계산량 우위·독립 보안 검증·실제 업무 절감액을 입증하지 않는다. 읽어 본 본문에서는 VeriCUA를 바로 설치할 공식 저장소 주소를 확인하지 못했으므로, 참고문헌에 나오는 다른 프로젝트를 해당 코드로 연결하지 않았다. 관련 내부 글은 이번 패키지에서 본문 적합성까지 새로 검증하지 않아 억지로 추가하지 않았다.

출처와 근거 범위

• VeriCUA: Verification as Agentic Exploration for Computer-Using Agents — arXiv v1: 방법 §3.1–3.5, 온라인 결과 Table 1, 도구 구성 비교 §5.1/Table C.1, 접근 경계 Appendix A.3–A.5, 분모 B.1/B.4, 토큰 사용량 C.5/Table C.9.
• 같은 버전 PDF: 본문의 페이지 표기는 PDF 페이지 기준이다. 보존된 원문과 추출문을 대조했으며 새 모델 실행·독립 재현·실제 앱 저장 실험은 수행하지 않았다.