에이전트가 "다 했습니다"라고 말할 때, 누가 그 말을 검사하는가 — VeriCUA (arXiv 2610.40578)

화면 녹화 30초가 남아 있다. 에이전트는 스프레드시트에 새 행을 채우고, 저장 단축키를 누르고, 채팅창에 "작업을 완료했습니다"라고 적는다. 그 30초를 되감아 보면 답이 나온다. 저장 대화상자가 화면 한가운데 떠 있었고, 파일은 디스크에 닿지 않았다. 사람이 한 번 보면 끝나는 이 확인을, 하루에 수천 궤적으로 늘리면 사람이 사라진다.

컴퓨터를 쓰는 에이전트(CUA, computer-using agent)를 데스크톱·모바일·웹으로 넓히려면 이 확인이 자동으로 되어야 한다. 학습 데이터를 고를 때도, 성능을 평가할 때도, 강화학습의 보상을 줄 때도 "끝났는가"를 먼저 판정해야 하기 때문이다. Qiushi Sun 등 8명의 저자가 2026년 10월 29일 arXiv에 올린 <VeriCUA: Verification as Agentic Exploration for Computer-Using Agents>는 바로 이 판정을 주제로 삼는다.

판정자라는 이름의 부분 시야

가장 흔한 자동 검증은 두 갈래다. 하나는 궤적을 비전-언어 모델(VLM)에 넣고 "성공했는가"를 묻는 판정자다. 다른 하나는 애플리케이션 상태를 들여다보는 프로그램을 생성해 실행하는 방식이다. 둘 다 그럴듯해 보이고, 둘 다 실제로 쓰인다.

논문이 겨냥하는 지점은 정확도가 아니라 시야다. VLM 판정자는 넘겨받은 관측만 볼 수 있고, 생성된 프로그램은 접근 가능한 상태에만 의존한다. 이 두 시야는 결정적인 증거를 빠뜨리거나, 완료 판정을 뒷받침하지 못한 채로 남길 수 있다. 화면에 뜬 네이티브 대화상자, 캔버스에만 그려진 결과, 접근성 트리에 노출되지 않은 위젯은 코드 검사 쪽에서 그냥 사라진다.

그래픽 인터페이스는 서로 겹친 창과 위젯으로 이뤄진다. 판정자가 보는 것은 이 장면 전체가 아니라 누군가 골라 준 일부다 — Squeak 5.1 Morphic 인터페이스 스크린샷, Marcel Taeumel, CC BY 4.0 (Wikimedia Commons)

코드로 검사하면 된다는 반론, 그리고 그 구멍

"화면을 보는 대신 상태를 읽으면 되지 않나"라는 반론은 자연스럽다. 프로그램은 거짓말을 하지 않고, 대화상자를 그림자처럼 흘려보내지도 않는다. 논문도 이 경로를 버리지 않는다. 다만 그것이 만능이 아니라고 본다. 프로그램이 읽는 상태 역시 환경이 공개한 부분집합이고, 그 부분집합에 없으면 검사는 조용히 통과한다.

여기에 실무 비용이 겹친다. 플랫폼마다, 접근 방식마다 검증기를 따로 맞추면 데스크톱용·모바일용·웹용 판정기가 각각 늘어난다. 정확도를 조금 올리려고 유지보수 대상만 늘리는 셈이다. 논문이 "platform-agnostic"을 앞세우는 이유가 여기에 있다.

반전: 검증도 하나의 탐색이다

VeriCUA의 발상은 판정을 한 번의 질의가 아니라 증거 수집 과정으로 바꾸는 것이다. 검증기는 먼저 주어진 맥락을 살펴 과제 루브릭을 만든다. 그다음 아직 해결되지 않은 요구사항을 골라, 그것을 확인할 GUI 검사와 코드 검사를 선택한다. 마지막으로 두 갈래에서 나온 발견을 명시적인 증거 규칙 아래 결합한다.

핵심은 순서다. 무엇을 물을지 먼저 정하고, 물을 방법을 나중에 고른다. 판정자가 처음부터 화면 전체를 판정하는 대신 "저장이 실제로 일어났는가"라는 미해결 항목을 붙잡고, 그 항목에 맞는 증거를 얻으러 움직인다. 온라인과 오프라인, 여러 플랫폼과 관측 양식이 같은 절차를 공유한다는 점도 이 설계의 결과다.

사용성 실험실의 피실험자. 사람이 화면을 보며 "정말 됐는지" 확인하던 일을 자동 판정자가 대신하려면, 보는 행위 자체를 설계해야 한다 — Andreas Bohnenstengel, CC BY-SA 3.0 DE (Wikimedia Commons)

경쟁 가설: 판정 모델을 더 크게 만들면 되지 않나

가장 강한 경쟁 가설은 관측을 늘리거나 판정 모델을 키우면 해결된다는 쪽이다. 스크린샷을 더 많이 주고, 더 큰 모델에 판정을 맡기면 사각지대도 줄어들 것 같다. 하지만 논문이 지적하는 것은 관측의 양이 아니라 관측의 선택이다. 같은 화면을 열 배 더 줘도, 저장 대화상자가 그 프레임에 없다면 판정자는 여전히 모른다.

논문은 실제로 얻은 이득을 두 가지로 설명한다. 하나는 상보적 증거, 즉 GUI 검사와 코드 검사가 서로의 빈칸을 메우는 효과다. 다른 하나는 테스트 시점 탐색, 즉 판정하는 동안 환경을 더 들여다보는 행위 자체의 효과다. 두 설명이 맞다면 "더 큰 판정자" 가설은 관측을 늘리는 것으로는 같은 개선을 재현하지 못해야 한다.

논문이 스스로 인정한 범위와, 이 글의 지적

논문이 보고하는 성과는 비교 기준선 대비 참조 라벨과의 일치도 향상이다. 오프라인에서는 어려운 사례에서 이득이 가장 컸고, 온라인에서는 거짓 완료 주장을 더 잘 걸러냈다고 한다. 다만 초록에는 구체적인 수치가 제시되지 않는다. 어느 벤치마크에서 몇 퍼센트포인트인지는 본문을 봐야 하고, 이 글은 그 숫자를 만들어 채우지 않는다.

여기에 딸린 물음이 남는다. 참조 라벨과의 일치도는 그 라벨이 옳다는 전제 위에서만 의미가 있다. 검증기를 검증하려면 결국 사람이 라벨을 다시 봐야 한다. 또 탐색은 공짜가 아니다. 판정 한 건에 드는 시간과 호출 수가 늘어나는데, 초록은 그 비용을 논의하지 않는다. 어려운 사례에서 이득이 컸다는 서술은, 어려운 사례일수록 탐색을 더 오래 했다는 뜻이기도 하다.

독자에게

이 논문이 바꾸는 것은 판정기의 정확도 하나가 아니다. "끝났다"는 보고를 믿을 수 있는 조건이 무엇인지에 대한 정의다. 증거를 먼저 모으고 결론을 나중에 내리는 절차는, 사람이 리뷰할 때 쓰는 습관과 크게 다르지 않다.

여러분은 어떤 쪽을 신뢰하겠는가. 화면을 보는 판정자인가, 상태를 읽는 프로그램인가. 아니면 둘 다 보되 무엇을 확인할지 먼저 정하는 절차인가. 그리고 그 절차가 틀렸을 때, 우리는 무엇을 근거로 그것을 알게 될까.

참고 자료

• Qiushi Sun, Da Yu, Alexander Knop, Amer Sinha, Lingpeng Kong, Ben Kao, Ravi Kumar, Pritish Kamath, <VeriCUA: Verification as Agentic Exploration for Computer-Using Agents>, arXiv:2610.40578v1 (2026-10-29) — https://arxiv.org/abs/2610.40578v1
• 이미지 1: Squeak 5.1 Morphic interface screenshot, Marcel Taeumel, CC BY 4.0, Wikimedia Commons
• 이미지 2: Usability Lab 02, Andreas Bohnenstengel, CC BY-SA 3.0 DE, Wikimedia Commons