소르테크 × 인제대, WAA 리더보드 1위를 찍다 — 15-step 단일 실행 64.22%

이 글은 WAA(Windows Agent Arena) 리더보드 시리즈의 2번째 글입니다.

필드 전체 순위(원본 WAA / WAA-V2)는 이전 글에 정리돼 있고, 이 글은 그중 우리 실험을 자세히 다룹니다.

TL;DR

Windows Agent Arena(WAA) 154개 태스크를 처음부터 끝까지 새로 돌린 단일 실행에서 98.906 / 154 = 64.22% 를 기록했습니다.

우리가 확보한 2026-06-05 리더보드에서, 여러 후보를 뽑거나 여러 번 돌린 결과(best-of-N, pass@N, selection)를 빼고 "한 번 돌린 결과끼리(comparable single-run)"만 줄 세우면 지금까지 최고점은 OS-Symphony(GPT-5)의 63.5% 였습니다. 이번 구성은 그 위에 섭니다.

한 가지는 분명히 하고 시작하겠습니다. 이건 "Gemini 모델이 GPT-5보다 세다"는 이야기가 아닙니다."Gemini 3.1 Pro backend + safe-tool orchestration + 검증/복구 pipeline"이라는 운영 구성이 동일 벤치마크의 comparable single-run 최고점을 찍었다는 이야기입니다. 리더보드 상단이 전부 "scaffold + 모델" 조합이라는 점에서, 이건 공정한 scaffold 대 scaffold 싸움입니다.

Windows Agent Arena란

WAA는 진짜 Windows 환경에서 컴퓨터를 대신 조작하는 에이전트를 평가하는 벤치마크입니다.

Chrome, Edge, VS Code, LibreOffice(Calc/Writer), 파일 탐색기, 설정, 메모장, 계산기, VLC, 그림판 같은 실제 앱에 걸친 154개 태스크를 줍니다. 에이전트는 스크린샷과 접근성 트리를 보고, 클릭·타이핑·단축키 같은 행동을 스스로 골라 목표 상태에 도달해야 합니다.

어려운 이유는 세 가지입니다.

하나, 상태 공간이 진짜 OS라서 넓고 지저분합니다.

둘, "메모장을 열어서 …를 입력하라" 같은 태스크는 결과만 맞다고 되는 게 아니라 지정된 경로(route)를 따라야 합니다.

셋, LibreOffice 저장 대화상자, 문서 복구 팝업, 차트/피벗 마법사처럼 흐름을 막는 modal 상태가 수시로 튀어나옵니다. 그래서 WAA 점수는 모델 지능만이 아니라, 그 모델을 감싼 에이전트 구성 전체의 실력을 잽니다.

리더보드 상단이 전부 정교한 scaffold인 이유입니다.

리더보드에서 우리는 어디에 서 있나

아래는 **원본 WAA(154 태스크)**에서 comparable single-run, 즉 한 번 돌려 나온

직접 비교 가능한 결과만 추린 표입니다. best-of-N / pass@N / BJudge selection / 평균낸 값은

성격이 다르므로 제외했습니다. (이 필터링이 이번 1위 주장의 근거입니다.)

step budget 이야기부터 정리하겠습니다. WAA는 허용 행동 수(15/30/50/100)에 따라 점수가 갈리므로, step이 다르면 직접 비교가 어렵습니다. 그런데 이번 64.22%는 가장 빡빡한 15-step 예산 (태스크당 --max-steps 15; 로그상 step_0–step_14, DONE 시 조기 종료)에서 나온 값입니다.

그런데도 50-step 최고점(OS-Symphony, 63.5)과 100-step 최고점(GUI-Pro-Agent, 61.0)을 모두 넘습니다. 남들이 3배~6배 많은 행동을 쓰고 얻은 점수를 더 적은 예산으로 넘었다는 뜻이라, step budget 축에서는 오히려 저희의 실험이 유리합니다.

정확한 표현

"이번 WAA safe-tools 실험 환경에서, Gemini backend에 UIA/opti pipeline을 결합한 운영 구성이 Qwen safe-tools reference와 comparable single-run 최고점을 모두 넘어 64.22%를 기록했다."

"Gemini 모델이 Qwen/GPT-5 모델보다 우수하다"라는 뜻은 아닙니다.

우리가 한 것

먼저 이름 정리부터 하겠습니다. 실제 backend 모델은 gemini-3.1-pro-preview입니다.

이번 결과는 예전 success-only overlay(성공한 것만 재시도로 반영한 93/154)가 아니라, waa-test-uia-opti-pipeline-v2에서 154개 태스크를 clean 상태에서 처음부터 끝까지 한 번에 돌린 값입니다.

전체 소요 시간은 약 8시간 27분입니다.

여기서 말하는 "pipeline"은 단순 후처리가 아니라, 아래를 함께 켠 실행 구성입니다.

• Safe common tool schema — 모델이 미리 정의된 safe tool call 중에서 고르도록 행동 공간을 구조화
• VLM common tool planner — 현재 스크린샷/a11y 상태와 태스크 지시를 보고 다음 tool call을 계획
• Tool critic / rerank — primitive action보다 더 적합한 semantic 후보가 있으면 교체
• General verification / repair — 너무 이른 DONE, 저장 누락, 산출 파일 미검증, 반복 action stuck을 잡음
• LibreOffice modal repair — 문서 복구·저장·마법사·응답 없음 상태를 자동 처리
• strict_when_explicit route policy — 앱/메뉴/버튼이 명시되면 그 경로를 강제
• WAA runtime 안정화 patch — UIA timeout, XML sanitize, cleanup, Chrome/Edge port 안정화

결과 뜯어보기

같은 154개 태스크 위에서 세 가지 구성을 비교하면 그림이 선명합니다.

핵심 델타만 보면:

• Gemini safe-only → pipeline fresh: +34.906
• Qwen reference → pipeline fresh: +12.906

64 → 98.906의 상승은 모델을 바꿔서가 아닙니다. 동일 Gemini backend 위에서 pipeline과 safe-tool orchestration을 켰을 때 나온 값입니다. 상승분의 정체는 "운영 구성 효과"입니다.

정수 성공 개수로는 98 full success + 1 partial positive(0.906) + 55 zero/fail입니다.

도메인별 성적

전체 상승의 핵심은 VS Code 24/24 완전 성공과 Settings·Notepad·Windows Calc의 안정적 만점입니다.

반대로 아직 갈 길이 있는 곳은 microsoft_paint(1/3), libreoffice_calc(11/24), chrome(8/17), vlc(10.906/21), libreoffice_writer(10/19), msedge(7/13)입니다.

Qwen reference 대비 우위는 주로 vs_code(+7), settings(+3), vlc(+2.906), clock(+2)에서 나왔고, file_explorer(-1), libreoffice_writer(-2), msedge(-2)에서는 오히려 밀렸습니다.

다만 clock(2/4)과 microsoft_paint(1/3)은 절대 성적 자체가 낮아, 결론을 뒤집진 않아도 남은 숙제입니다.

왜 올랐나: pipeline이 실제로 개입했다는 증거

명목상 켜두기만 한 게 아니라는 증거가 로그에 남아 있습니다. 이번 run에서 관측된 개입은 다음과 같습니다.

이 숫자들이 모든 개입이 성공을 만들었다는 뜻은 아닙니다. 하지만 pipeline이 명목 설정이 아니라 action 선택·검증·복구 단계에 실제로 손을 댔다action 선택·검증·복구 단계에 실제로 손을 댔다 짝지으면 이렇게 대응됩니다.

• 잘못된 tool 선택 → planner / critic / rerank로 semantic 후보 선택
• 너무 이른 DONE → premature-DONE 차단 + output verification
• 저장/산출 파일 검증 누락 → save-then-reobserve, verify output files
• 반복 action stuck → repeated-action guard, escape / reobserve
• LibreOffice modal block → recovery / save / wizard dialog repair
• UIA 수집 / runtime hang → timeout, XML sanitize, cleanup patch

그리고 route violation 0건이 중요합니다. "메모장을 거치지 않고 파일을 직접 만들어 점수만 챙기는" 식의 지름길이 이번 집계에서 관측되지 않았다는 뜻입니다. 즉 이 64.22%는 strict route policy를 지킨 상태에서 나온 점수입니다. shortcut으로 부풀린 수치가 아닙니다.

정직하게: 이 1위의 범위와 한계

기술 블로그의 신뢰는 자랑이 아니라 범위를 정확히 긋는 데서 나옵니다. 이 1위가 서 있는 조건은 이렇습니다.

1. model-only 비교가 아닙니다. 모델 + safe tools + pipeline + Windows runtime + wrapper + snapshot/revert 환경까지 포함한 운영 구성 비교입니다. "Gemini가 GPT-5보다 낫다" 같은 모델 우열 주장으로 읽으면 안 됩니다.
2. runtime 안정화 patch가 켜져 있었습니다. UIA timeout, XML sanitize, Chrome/Edge port 안정화 등은 표준 WAA 대비 우리가 손본 부분입니다. 평가 기준(evaluator) 자체를 바꾼 건 아니고 안정성 patch에 가깝지만, 이 사실은 숨기지 않습니다.
3. 비교 대상은 2026-06-05 리더보드입니다. 이건 논문·모델 카드·GitHub를 취합한 리포트입니다. 이후 새 결과가 나왔을 수 있으니, 정확히는 "이 리더보드 상의 comparable single-run 최고점"입니다.
4. partial score를 반영한 수치입니다. 98/154가 아니라 score sum 98.906/154가 대표값입니다.
5. 실패 55개가 남아 있습니다. chrome, LibreOffice, Paint, Edge, VLC 일부는 여전히 후속 분석 대상입니다.

이 다섯 개를 다 인정해도 결론은 유지됩니다. 가장 빡빡한 15-step 예산에서, strict route를 지킨 채, 50·100-step 최고점을 모두 넘는 64.22%. 그게 이번 실험이 확보한 자리입니다.

맺음

한 문장으로 남깁니다.

Gemini 3.1 Pro backend에 safe-tool orchestration과 검증/복구 pipeline을 결합한 운영 구성이, Windows Agent Arena 154 태스크를 단일 fresh run(태스크당 max-steps 15)으로 98.9/154(64.22%) 수행하며 comparable single-run 리더보드 최고점을 기록했습니다.

행동을 고르고·검증하고·복구하는 층을 제대로 쌓았을 때행동을 고르고·검증하고·복구하는 층을 제대로 쌓았을 때 Computer Use 에이전트가 어디까지 가는지를 보여준 숫자입니다.