GUI 에이전트의 실행 하네스를 반복 실행 증거로 자동 최적화한다

무엇인가

GUI 에이전트의 성능은 모델 가중치만으로 결정되지 않는다. 관찰을 어떻게 조립하고, 컨텍스트를 어떻게 구성하고, 액션을 어떻게 실행하며, 검증·복구·종료를 어떻게 제어하는지를 담은 실행 하네스가 성능을 좌우한다. 이 논문은 모델 가중치를 전혀 건드리지 않고 이 하네스 코드만 자동으로 고쳐 GUI 에이전트를 자기개선시키는 문제를 다룬다. 수학 추론이나 소프트웨어 엔지니어링 같은 비GUI 도메인에서는 텍스트 트레이스와 피드백으로 프롬프트와 코드를 고치는 Meta-Harness, Self-Harness 같은 최적화기가 이미 있었다. 저자들은 GUI에는 그대로 적용하기 어려운 세 가지가 얽혀 있다고 본다. 첫째, 모델의 의도와 실제 화면 변화가 어긋난다. 저장 버튼을 눌렀다는 트레이스가 성공을 주장해도 다이얼로그가 열려 있으면 작업은 끝나지 않았다. 둘째, 같은 작업을 반복 실행하면 결과가 달라진다. 저자들 베이스라인에서 전체 태스크의 11.8~20.4%가 세 번 실행 중 0점과 양수 점수를 모두 냈다. 셋째, 한 태스크에서 얻은 교훈이 다른 태스크에 그대로 쓸모 있다는 보장이 없다.

어떻게 동작하나

GUI-HARVEST는 이 문제를 증거 기반 하네스 진화로 정식화한다. 고정된 모델 M과 초기 하네스 H0가 주어지면 태스크를 검색 80개, 검증 80개, 봉인된 테스트 201개로 도메인 층화 분할하고, 검색 궤적만 진단 근거로 쓰며 검증은 집계 점수만 노출하고 테스트는 최적화가 끝날 때까지 열지 않는다. 최적화는 최대 B=10 라운드, 라운드당 최대 P=5개의 후보 수정안을 평가하는 예산으로 진행되고 각 태스크는 K=3회 반복 실행한다. 최적화기 안에는 네 개의 역할이 있다. Evidence Analyst가 실패를 진단하고, Cross-task Clusterer가 반복 패턴을 묶고, Harness Engineer가 소스 코드를 고치고, Validator가 성능과 예측된 행동 변화를 함께 검사한다. 수정안이 승격되면 그 하네스로 다시 실행한 궤적이 다음 라운드의 진단 근거가 되고, 거부되면 이전 하네스로 롤백한다. 결정들은 업데이트 원장(ledger)에 기록돼 이후 제안을 유도한다.

무엇과 다른가

Evidence Analyst는 같은 태스크의 반복 실행을 하나의 증거 단위로 묶는다. 각 실행은 텍스트, 계획된 액션과 실행된 액션, 스크린샷, 툴 출력을 단계별로 기록한 멀티모달 궤적과 점수, 종료 메타데이터를 남긴다. 여기에 지시문·도메인·관련 앱·설정 단계를 담은 Task Card와 런타임 요약인 Harness Card가 붙는다. 최소 한 번의 유효 실행이 0점이면 그 번들이 진단 대상이 되고 나머지 실행은 비교 증거로 쓰인다. GAFT(GUI Artifact and Fact Toolkit)가 텍스트·액션·전후 스크린샷을 실행 단계별로 정렬하고, 반복 액션 횟수나 픽셀 변화량 같은 기계적 사실을 계산한다. 분석가는 실패 실행의 결정적 단계를 찾아 관찰된 행동과 기계적 결과를 서술하고 근거가 된 실행 번호와 단계를 인용한다. 결정적 검증기가 하네스 버전, 인용된 실행·단계, 인용문 위치, 기계적으로 검증 가능한 궤적 사실을 확인한 뒤에야 finding으로 남는다. Cross-task Clusterer는 서로 다른 태스크에서 나온 검증된 finding들을 행동 모드로 묶는다. 먼저 결정적 결과 범주를 부여하고, 그 범주 안에서 최소 두 개 이상의 태스크가 공유하는 메커니즘을 찾아 모드를 만든다. 모드는 관찰 가능한 메커니즘, 소속 판정 기준, 행동 목표, 근거 finding, 독립 태스크 지지 수를 기록하며 라운드마다 버전 관리된다.

어떻게 쓰나

Harness Engineer는 행동 모드를 실제 런타임 코드 수정으로 옮긴다. 코드를 읽고 테스트하는 세션 안에서 관련 코드 영역을 찾아 범위가 제한된 패치를 적용하고 로컬 테스트를 돌린다. 중요한 점은 GUI 평가에 들어가기 전에 수정 계획을 먼저 기록한다는 것이다. 어떤 모드와 증거를 겨냥했는지, 어느 코드 영역을 고쳤는지, 어떤 관찰 가능한 행동 변화를 예측하는지, 어떤 검색 태스크로 확인할지를 미리 적고 깨지면 안 되는 인터페이스와 불변식도 명시한다. 예컨대 완료 확인 패치라면 성공을 선언하기 전에 열린 저장 다이얼로그를 해결할 것 같은 예측이 남는다. Validator는 두 단계로 거른다. L0는 편집 권한, diff 크기 제한, 문법, 정적 규칙을 검사하고 L1은 임포트, 인터페이스 호환성, 단위 테스트, 스모크 테스트를 확인한다. 통과한 후보는 검색과 검증의 모든 태스크에서 K회 실행된다. 유틸리티 하드 게이트는 검색과 검증 어느 쪽에서도 점수가 떨어지지 않고(델타 0 이상) 최소 한쪽에서 엄격히 올라야 통과시킨다. 행동 소프트 게이트는 사전에 기록한 예측이 실제 실행에서 지지됐는지, 반박됐는지, 판단 불가인지를 태스크별로 판정하고, 각 예측에 최소 하나의 확정 판정이 있으면서 지지가 반박보다 많아야 한다. 두 게이트를 모두 통과할 때만 후보가 승격된다.

전제와 한계

실험은 OSWorld-Verified에서 Google Drive 태스크 8개를 제외한 361개 태스크로 수행했다. 백본은 Qwen3-VL-8B/32B-Instruct, OpenCUA-32B/72B, Gemini 3.1 Pro, GPT-5 여섯 개이며 가중치와 디코딩 설정은 고정했다. Qwen3-VL과 상용 백본은 Agent S3에서 출발하고(그라운딩 모델 UI-TARS-1.5-7B, best-of-N 비활성) OpenCUA는 자체 좌표 기반 런타임을 쓴다. 최적화기 네 역할은 모두 Claude Sonnet 5를 사용했다. 15스텝, K=3 프로토콜에서 여섯 백본 모두 테스트 점수가 1.49~10.16점 올랐다. 가장 큰 폭은 Qwen3-VL-32B-Instruct로 테스트 53.18%(+10.16점), 전체 361개 스위트 50.94%(+12.33점)를 기록했다. 같은 초기 하네스에서 Self-Harness는 테스트 +2.00점, Meta-Harness는 +4.38점에 그친 반면 GUI-HARVEST는 +10.16점을 냈다. LFF의 공개 패치와 비교해도 OpenCUA-72B에서 테스트 44.18%, 전체 42.33%로 LFF의 41.29%, 39.50%를 앞섰다.

전이는 OSWorld 밖에서도 확인됐다. OSWorld에서만 최적화한 하네스를 그대로 WindowsAgentArena에 50스텝으로 옮겼을 때 Qwen3-VL-32B-Instruct는 38.21%에서 44.68%(+6.47점), GPT-5는 50.88%에서 64.75%(+13.87점)로 올랐다. 15스텝에서 최적화한 하네스를 더 긴 예산에 그대로 쓴 경우에도 성능이 계속 올라 Gemini 3.1 Pro는 100스텝에서 79.14%에 도달했다. 백본과 스텝 예산을 맞춘 비교에서는 GPT-5로 CoAct-1을 22.61점(62.42% 대 39.81%), Gemini 3.1 Pro로 VLAA-GUI를 21.68점(73.37% 대 51.69%) 앞섰고, 50스텝에서 Qwen3-VL-32B 하네스는 51.52%로 Qwen 베이스라인 32.60%보다 18.92점 높았다. 비용 측면에서도 GPT-5 15스텝 하네스는 62.4%로 Agent S3의 62.6%에 거의 맞먹으면서 전체 스위트 API 비용이 72달러로 Agent S3의 260달러보다 약 72% 낮았다. 제거 실험에서는 시각 증거를 빼면 테스트 44.54%/전체 40.69%로 가장 크게 떨어졌고, 교차 태스크 클러스터링을 빼면 45.66%/42.13%, 반복 실행 증거를 1회로 줄이면(K=1) 각각 5.74점, 7.82점 낮아졌다. 하드 게이트만 쓰는 변형은 9라운드까지 돌고도 전체 기법(8라운드 종료)보다 낮은 하네스를 골랐다.

실무적으로 이 논문이 던지는 메시지는 명확하다. 에이전트 성능을 올리는 지렛대가 모델 교체나 파인튜닝만 있는 게 아니라 모델 주위의 실행 코드에도 있다는 것이다. 특히 GUI 자동화를 운영하는 팀이라면 실패한 실행 로그를 텍스트만 보지 말고 전후 스크린샷과 함께 단계별로 정렬해 진단 근거로 삼고, 같은 태스크를 여러 번 돌려 성공과 실패가 갈리는 지점을 비교해야 한다는 설계 원칙을 참고할 만하다. 또 수정 전에 예측을 먼저 적어두고 수정 후 그 예측이 맞았는지 확인하는 절차는 점수만 보고 패치를 채택하는 흔한 실수를 줄여준다. 다만 이 기법은 하네스 코드를 읽고 고칠 수 있는 에이전트형 최적화기(여기서는 Claude Sonnet 5)를 전제로 하므로, 자체 평가 파이프라인과 반복 실행 인프라가 갖춰져 있지 않으면 그대로 재현하기 어렵다.

저자들이 밝힌 한계도 분명하다. 남은 실패는 스크린샷과 실행 로그로는 탐지하기 어려운 유형으로 옮겨간다. 초기 수정은 반복 액션, 잘못된 호출, 저장되지 않은 파일처럼 런타임 신호가 뚜렷한 실패를 잡지만 이후에는 액션 자체는 성공했는데 엉뚱한 객체나 경로, 평가에 중요한 상태를 건드린 오류가 남는다. 이런 오류는 화면상 정상으로 보여 하네스가 복구를 트리거할 국소 신호를 얻지 못한다. 유용한 개입은 백본에 따라 다르다. Qwen3-VL은 코드 라우팅에 액션 복구와 완료 확인을 결합하는 게 효과적이었고, 프런티어 모델은 라우팅·지속성·실현 가능성·완료 정책 변경에서 주로 이득을 봤으며, OpenCUA는 자체 좌표 기반 액션 규약에 가까운 수정(액션 정규화, 파일 마무리, 터미널 의미론)에 머물렀다. 그래서 OpenCUA의 개선폭은 3.53~4.68점으로 다른 백본(6.91~12.33점)보다 작았고 저자들은 이를 자체 프로토콜에 맞춰진 낮은 적응성으로 해석한다. Qwen 계열은 15스텝에서 100스텝으로 예산을 늘려도 2.54점, 0.85점만 올라 장기 호라이즌 실행 병목이 남아 있음을 시사한다. LFF 비교는 최적화기 구현과 검색 설정이 공개되지 않아 공개된 패치만 같은 프로토콜로 평가한 결과라는 점도 전제로 달려 있다.