OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments (Xie et al., HKU · Salesforce · CMU · Waterloo, NeurIPS 2024)

Introduction

지금까지의 agent 벤치마크는 대부분 텍스트 또는 구조화된 인터페이스를 통해 환경과 상호작용했다. SWE-bench는 diff 패치를 출력하고, TravelPlanner는 Action: Tool[args] 포맷으로 도구를 호출하며, MedAgentBench는 FHIR API를 JSON으로 호출한다. 즉 환경이 agent에게 친절한 텍스트 API를 제공한다.

그러나 인간이 컴퓨터로 하는 일의 대부분은 이렇지 않다. 우리는 화면을 보고, 마우스를 움직이고, 버튼을 클릭하고, 키보드로 입력한다. 다음과 같은 평범한 부탁을 생각해 보자.

“이 폴더의 사진 30장 워터마크 지우고, 슬라이드에 한 장씩 붙여서 PDF로 내보내줘.”

이 작업을 하려면 agent는 파일 매니저를 열고, GIMP로 이미지를 편집하고, LibreOffice Impress에 붙여넣고, export 메뉴를 찾아 PDF로 저장해야 한다. 여러 앱을 넘나들며 GUI를 직접 조작해야 하는 것이다. 텍스트 API는 없다. 오직 픽셀과 마우스/키보드 이벤트만 있다.

OSWorld는 이 현실을 그대로 평가한다. Ubuntu(확장으로 Windows·macOS) 가상 머신 위에서, agent에게 스크린샷을 주고 마우스·키보드 명령만으로 369개의 실제 컴퓨터 작업을 풀게 한다. 결과는 시리즈의 다른 벤치마크들과 같은 충격을 준다.

“While humans can accomplish over 72.36% of the tasks, the best model achieves only 12.24% success.”

인간은 72.36%를 해내지만, 최고 모델(GPT-4V 기반)은 12.24%에 그친다. 저자의 진단은 명확하다. agent는 GUI grounding(화면에서 클릭할 위치를 정확히 찾는 능력)과 operational knowledge(앱을 어떤 순서로 조작해야 하는지에 대한 절차적 지식)에서 무너진다.

기여를 정리하면 다음과 같다.

• 최초의 확장 가능한 real computer 환경: 실제 OS·실제 앱 위에서 임의의 open-ended task를 셋업·실행·평가
• Execution-based 평가: LLM judge가 아니라 최종 시스템 상태를 검증 스크립트로 채점 → contamination·주관성에 강건
• 369개 실세계 task: 단일 앱부터 multi-app workflow, 그리고 infeasible task까지 포함
• 멀티모달 관찰·통일된 행동 공간: screenshot + a11y tree 관찰, pyautogui 기반 mouse/keyboard 행동

이 논문은 NeurIPS 2024(Datasets and Benchmarks Track)에 발표되었고, 이후 Claude computer use, OpenAI Operator(CUA) 등 computer-use agent의 사실상 표준 north-star 벤치마크가 되었다.

Related Work

GUI/computer-use agent 평가는 크게 세 갈래로 발전해왔다.

분류	대표 벤치마크	한계
웹 단독	WebShop, Mind2Web, WebArena	브라우저 DOM에 한정, 데스크톱 앱·OS 조작 불가
모바일/UI 단편	MiniWoB++, AndroidEnv, Rico	토이 위젯 또는 좁은 액션, multi-app workflow 부재
시뮬레이터/임바디드	ALFWorld, VirtualHome	합성 환경, 실제 소프트웨어와 mismatch

AgentBench가 8개 환경을 묶었지만 각 환경은 여전히 텍스트 grounding(bash, SQL, 정의된 web action)이었다. WebArena·Mind2Web은 실제 웹을 다루지만 브라우저 안에 갇혀 있어, 파일 시스템·이미지 편집기·코드 에디터를 넘나드는 작업은 평가하지 못한다.

OSWorld의 차별점은 두 가지다.

1. 앱·OS 경계가 없다: 브라우저, 오피스, 미디어 플레이어, IDE, 이미지 편집기, 그리고 이들을 조합한 workflow까지 하나의 환경에서 평가한다.
2. 진짜 컴퓨터다: 시뮬레이터가 아니라 실제 OS 위의 실제 앱이다. 따라서 벤치마크에서 잘하는 agent는 그대로 실사용 환경에 옮길 수 있다.

환경 설계

관찰 공간 (Observation Space)

agent가 매 스텝 받는 정보는 다음 중 하나 이상으로 구성된다.

관찰 종류	설명
Screenshot	고해상도 화면 캡처 (예: 1920×1080)
A11y tree	XML 형식 accessibility tree. Ubuntu는 ATSPI2, Windows는 PyWinAuto로 추출
Screenshot + A11y	둘을 결합 (가장 정보량 많음)
Set-of-Marks (SoM)	화면 요소에 번호 마크를 오버레이 → grounding을 쉽게 만든 변형

이 변형들은 핵심 trade-off를 드러낸다. 순수 screenshot은 가장 현실적이지만 모델이 클릭 좌표를 직접 찾아야 한다(GUI grounding 부담). A11y tree는 요소의 좌표·레이블을 텍스트로 제공해 grounding을 우회하지만, 거대한 XML이 컨텍스트를 잡아먹는다.

행동 공간 (Action Space)

행동은 pyautogui 스타일의 마우스·키보드 primitive로 통일된다.

• pyautogui.click(x, y), moveTo, dragTo, rightClick
• pyautogui.write("text"), hotkey('ctrl', 's')
• 특수 토큰: WAIT(대기), FAIL(불가능 판단), DONE(완료 선언)

즉 agent는 매 스텝 실행 가능한 파이썬 코드 한 조각을 출력하고, 환경은 이를 VM 안에서 실제로 실행한다. 이 점이 중요하다. agent는 “버튼 A를 누른다” 같은 추상 액션이 아니라, 화면 좌표 (x, y)를 직접 지정해 클릭해야 한다. 좌표가 몇 픽셀만 어긋나도 작업은 실패한다.

FAIL 토큰의 존재가 OSWorld를 특별하게 만든다. 일부 task는 의도적으로 불가능(infeasible)하게 설계되어, agent가 무리하게 시도하는 대신 “이건 할 수 없다”고 판단할 수 있어야 한다.

Execution-based 평가

각 task는 두 부분으로 구성된다.

1. Initial state setup config: VM을 특정 상태로 초기화 (예: GIMP에 이미지를 미리 열어둠, 특정 파일·계정·쿠키 셋업)
2. Execution-based evaluation script: agent가 끝낸 뒤 최종 시스템 상태를 검사하는 커스텀 스크립트

평가 스크립트는 결과 파일의 내용, 앱 설정값, 브라우저 쿠키, 셀 값 등을 직접 읽어 정답과 비교한다. SWE-bench가 테스트를 실행해 채점하듯, OSWorld는 OS 상태를 실행으로 검증한다. 이 방식은 다음 장점이 있다.

• Ground-truth 독립: “정답 trajectory”가 아니라 “정답 결과 상태”를 본다. 같은 목표를 여러 경로로 달성해도 인정된다.
• 재현 가능: 동일 setup → 동일 검증. LLM judge의 noise가 없다.
• Contamination에 강건: 결과 상태를 만들어내는 것은 암기로 풀 수 없다.

점수는 task별 reward \(r_i \in [0, 1]\)의 평균 success rate로 집계된다.

\[\text{SR} = \frac{1}{N}\sum_{i=1}^{N} r_i\]

대부분의 task는 binary(0/1)지만, 일부는 부분 달성에 부분 점수를 주는 스크립트를 가진다.

데이터셋 상세

369개 task의 구성

구분	수	비율
단일 앱 (single-app)	268	72.6%
Multi-app workflow	101	27.4%
Total	369	100%
(이 중 infeasible)	30	8.1%

task는 5개 도메인에 걸쳐 분포한다.

도메인	포함 앱	성격
OS	파일 매니저, 터미널, 설정	설치·설정·파일 I/O
Office	LibreOffice Calc / Writer / Impress	스프레드시트·문서·슬라이드 편집
Daily	Chrome, VLC, Thunderbird	웹 브라우징·미디어·이메일
Professional	VS Code, GIMP	코드 편집·이미지 편집
Workflow	위 앱들의 조합	여러 앱을 넘나드는 복합 작업

task는 실제 사용자의 use case(포럼 질문, 튜토리얼, 사용자 매뉴얼 등)에서 수집·검수되었다. 각 task에는 자연어 instruction, setup config, 검증 스크립트가 함께 붙는다.

Infeasible task

30개(8.1%)의 task는 달성 불가능하다. 예를 들어 존재하지 않는 기능을 요구하거나, 권한이 없는 작업을 시키는 식이다. 좋은 agent는 이런 경우 FAIL을 출력해야 한다. 무리하게 환각된 동작을 시도하면 오답이다. 이는 실사용에서 매우 중요한 능력 — “할 수 없는 일을 할 수 없다고 인식하는 것” — 을 직접 측정한다.

Task 예시

(Daily) “Chrome에서 내 기본 검색 엔진을 DuckDuckGo로 바꿔줘.”

→ 설정 메뉴 진입 → 검색 엔진 항목 → DuckDuckGo 선택. 검증 스크립트는 Chrome preference 파일을 읽어 확인.

(Office) “이 스프레드시트에서 매출 열의 합계를 마지막 행에 추가하고, 통화 형식으로 바꿔줘.”

→ Calc 셀 선택 → SUM 수식 → 셀 서식 변경. 검증은 해당 셀의 값과 포맷을 직접 검사.

(Workflow) “이 CSV의 데이터로 막대그래프를 만들어서 슬라이드에 넣어줘.”

→ Calc에서 차트 생성 → 이미지로 export → Impress에 삽입. 여러 앱을 거쳐 median 6 step 이상 소요.

Experiments

메인 결과 — 인간 72% vs 모델 12%

출시 시점(2024-04) baseline LLM/VLM agent들의 success rate는 0.99% ~ 12.24% 범위에 머물렀다.

시스템	관찰 입력	Success Rate
Human	(화면 직접 조작)	72.36%
GPT-4 (best 설정)	a11y tree 기반	12.24%
GPT-4V	screenshot only	~5.26%
Gemini-Pro-Vision	screenshot only	~5.80%
다수 오픈소스 VLM	screenshot only	< 5%

핵심 관찰은 다음과 같다.

• 인간과의 격차가 ~6배다. GAIA(92% vs 15%), TravelPlanner(0.6%)와 같은 “쉬워 보이지만 AI에겐 어려운” 패턴이 GUI에서도 반복된다.
• screenshot only가 가장 어렵다. GUI grounding 부담을 온전히 떠안기 때문이다.
• 어떤 도메인에서도 모델이 인간 근처에 가지 못한다.

관찰 modality의 영향

관찰 입력	경향
Screenshot only	가장 현실적·가장 어려움. grounding 실패가 지배적
A11y tree	좌표·레이블을 텍스트로 제공해 grounding 우회. 단 XML이 매우 길어짐
Screenshot + A11y	정보량 최대지만 컨텍스트 비용 큼
Set-of-Marks (SoM)	요소에 번호 마크 → step 수를 줄여줌 (Writer·VLC·Thunderbird·GIMP에서 효과적)

A11y tree를 주면 점수가 오른다는 사실은 역설적으로 “현재 모델의 진짜 병목은 추론이 아니라 grounding”임을 보여준다. 화면에서 클릭 위치를 텍스트로 떠먹여주면 더 잘한다.

도메인별 난이도

성능은 도메인에 따라 크게 갈린다. 상대적으로 OS·Daily(웹/미디어) 작업은 그나마 점수가 나오지만, Professional(GIMP·VS Code)과 Workflow(multi-app)에서 거의 0%에 수렴한다. 특히 multi-app workflow는 긴 호흡과 앱 간 상태 전이를 요구해 가장 어렵다.

실패 분석

저자가 trajectory를 분석해 도출한 주요 실패 원인은 다음과 같다.

1. GUI Grounding 실패 (가장 치명적)

모델이 “무엇을 해야 하는지”는 알아도 “화면 어디를 클릭해야 하는지”를 못 맞춘다. 버튼의 픽셀 좌표를 몇 십 픽셀 빗나가게 지정하거나, 작은 아이콘·메뉴 항목을 찾지 못한다. screenshot only 설정에서 점수가 폭락하는 직접적 원인이다.

2. Operational Knowledge 부재

특정 앱에서 목표를 달성하는 절차적 지식이 부족하다. 예를 들어 “GIMP에서 배경 제거”의 정확한 메뉴 경로, “LibreOffice에서 PDF export”의 위치를 모른다. 인간은 메뉴를 탐색하며 알아내지만, 모델은 잘못된 가정으로 엉뚱한 메뉴를 헤맨다.

3. Long-horizon 붕괴

multi-app workflow처럼 스텝이 길어지면 중간 상태를 잃어버린다. TravelPlanner의 “부분은 맞지만 전체는 틀림”과 같은 양상으로, 한 스텝의 실수가 이후 전체를 무너뜨린다.

4. Infeasible task 오판

FAIL을 내야 할 불가능 task에서, 모델은 종종 존재하지 않는 동작을 환각하며 무리하게 시도한다. “모른다/할 수 없다”를 인정하는 메타인지가 약하다.

5. 환경과의 비동기 문제

앱이 로딩 중인데 클릭하거나, 다이얼로그가 뜨기 전에 다음 액션을 실행하는 등 타이밍을 못 맞춘다. WAIT 토큰을 적절히 쓰지 못한다.

이후 동향 (2024–2026)

OSWorld는 출시 직후 computer-use 연구의 표준 측정자가 되었고, 발전 속도는 가팔랐다.

시점	시스템	Success Rate	비고
2024-04	GPT-4 (원논문 best)	12.24%	출시 baseline
2024-10	Claude 3.5 Sonnet (computer use)	~14.9% (확장 시 22%)	Anthropic computer use 공개
2025-01	OpenAI CUA / Operator	38.1%	전용 computer-use agent
2025-02	Claude 3.7 Sonnet	28% (100 step)
2025 중반	Agent S2 (Claude 3.7 기반)	34.5% (50 step)	agent scaffold 효과
2025 후반	Agent S3	62.6% (BoN 69.9%)	65% 돌파
2026-02	Claude Opus 4.6	72.7%	OSWorld-Verified
2026-04~	GPT-5.5 / Claude Opus 4.7 / Holo3 계열	~78–82%	OSWorld-Verified 상위권

출시 2년 만에 12% → 80% 수준으로, 인간(72.36%)을 넘보는 단계에 도달했다. 다만 이 비교에는 주의가 필요하다 (아래 한계 참조).

OSWorld-Verified (2025-07)

원본 OSWorld에는 community가 보고한 버그성 task(불안정한 setup, 모호한 정답)가 있었다. 이를 SWE-bench Verified와 같은 정신으로 정제한 것이 OSWorld-Verified다. 결함 예제를 수정하고, AWS 지원으로 평가 시간을 1시간 내로 단축했으며, 결과를 갱신했다. 2026년 현재 리더보드는 OSWorld-Verified 기준으로 보고된다.

비판: 벤치마크가 정말 GUI 능력을 재는가

Epoch AI 등은 OSWorld 점수의 해석에 경고를 던졌다.

• 터미널 우회: 약 45%의 task가 의도된 GUI 조작 대신 터미널/파이썬 스크립트로 우회 가능하다. 즉 높은 점수가 반드시 “GUI를 잘 다룬다”를 뜻하지 않는다.
• Instruction 모호성: 일부 task는 지시가 모호해, 실제 능력과 무관하게 점수가 흔들린다.
• Task instability: 외부 웹·앱 버전에 의존하는 task는 시간이 지나며 깨진다. 시점 간 비교의 신뢰도를 떨어뜨린다.

이 비판들은 OSWorld-Verified가 만들어진 이유이기도 하며, “점수 상승 = GUI 능력 향상”으로 단순 해석하지 말 것을 시사한다.

Discussion / 한계

저자가 인정한 한계

1. 환경 구축 비용: 실제 VM·앱 셋업은 무겁다. 평가에 상당한 시간·자원이 든다 (이후 AWS 병렬화로 완화).
2. Ubuntu 중심: Windows·macOS로 확장했으나 대부분 task는 Ubuntu 기반이다.
3. English·특정 앱 버전 의존: 앱 UI가 업데이트되면 좌표·메뉴가 바뀌어 task가 깨질 수 있다.
4. 단순 baseline: 정교한 agent scaffold(메모리, 계획, reflection)는 future work로 남겼다 — 이후 Agent S 시리즈 등이 이를 채웠다.

후속 평가가 보강한 부분

• OSWorld-Verified: 결함 task 정제 + 평가 인프라 개선
• OSWorld-Human: agent의 효율성(스텝 수)까지 측정하는 변형
• WindowsAgentArena, AndroidWorld 등 OS별 심화 벤치마크가 OSWorld의 좌표 위에서 확장

Conclusion

OSWorld가 agent 평가에 끼친 영향을 정리하면 다음과 같다.

• GUI/computer-use 평가의 표준: 텍스트 API 뒤에 숨지 않고, 픽셀과 마우스·키보드만으로 실제 OS를 다루게 한 첫 본격 벤치마크.
• Execution-based의 확장: SWE-bench가 코드에서 보인 “실행으로 채점”을 OS 전반으로 넓혔다. 가장 객관적인 평가 패러다임 중 하나다.
• 진짜 병목의 규명: 실패의 핵심이 추론이 아니라 GUI grounding과 operational knowledge임을 보였다. a11y tree를 주면 점수가 오른다는 사실이 이를 뒷받침한다.
• computer-use 시대의 north star: Claude computer use, OpenAI Operator, Agent S 시리즈 등이 모두 OSWorld 점수로 경쟁한다.

핵심 메시지는 시리즈 전체를 관통한다. 코딩(SWE-bench)·QA(GAIA)·계획(TravelPlanner)·도메인(MedAgentBench)에 이어, 컴퓨터를 인간처럼 직접 조작하는 능력 역시 출시 시점엔 인간의 발끝에도 못 미쳤다. 그러나 2년 만에 12% → 80%에 도달한 궤적은, GUI agent가 빠르게 실용 임계선에 다가서고 있음을 보여준다. 남은 질문은 “그 80%가 진짜 GUI 능력인가, 아니면 터미널 우회인가”이며, 이 reality check가 OSWorld-Verified와 후속 연구를 계속 추동하고 있다.

이어서 읽기: AgentBench, GAIA, SWE-bench, TravelPlanner, MedAgentBench, TelAgentBench: 통신 도메인 LLM 에이전트 평가

참고 문헌

• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments (arXiv 2404.07972) — Xie et al., NeurIPS 2024
• OSWorld 공식 사이트 및 리더보드
• OSWorld GitHub (xlang-ai)
• OpenReview — OSWorld
• XLANG Lab — Introducing OSWorld-Verified
• Epoch AI — What does OSWorld tell us about AI’s ability to use computers?
• OSWorld-Human: Benchmarking the Efficiency of Computer-Use Agents (arXiv 2506.16042)
• WebArena (Zhou et al., ICLR 2024)
• Mind2Web (Deng et al., NeurIPS 2023)