Executive Summary
몇 시간짜리 실제 업무를 AI 에이전트에게 통째로 맡길 수 있을까요. 이 질문을 정면으로 시험한 벤치마크가 새로 나왔습니다. 짧은 조작 과제를 모아 놓은 이전 세대에서는 최상위 에이전트가 83.5%까지 올라가 사실상 풀린 문제처럼 보였는데, 작업 길이를 실제 업무 수준으로 끌어올리자 같은 세대의 에이전트가 20% 안팎으로 주저앉았습니다. 이 글은 그 추락이 어디에서 오는지를 봅니다.
OSWorld-V2의 108개 작업은 중앙값 소요 시간이 약 1.6시간입니다. 최상위 에이전트조차 500스텝 안에 끝낸 작업은 20.6%뿐이었고, 45분 이하 구간에서 20% 남짓하던 완료율은 두 시간을 넘기며 10% 아래로 내려갔으며 163분을 넘어가면 어떤 모델도 하나를 끝내지 못했습니다. 실패의 다수는 모델이 몰라서가 아니라, 초반에 확인한 제약과 도중에 도착한 정보를 끝까지 들고 가지 못해서 벌어졌습니다.
그렇다면 병목은 지능이 아니라 상태입니다. 몇 시간에 걸쳐 쌓이는 맥락은 결국 하나의 데이터셋이고, 스키마도 신선도 점검도 검증 게이트도 없이 방치하면 사람이 짠 파이프라인처럼 오염되고 무너집니다. 이 글은 그 상태를 관리 대상 데이터로 다루자고 제안합니다.
주요 수치
출처: OSWorld-V2 (arXiv:2606.29537), 프로젝트 사이트
20.6%
최고 완료율
최상위 에이전트가 500스텝 안에 끝낸 작업 비율
0%
세 시간의 벽
163분을 넘는 작업은 모든 모델이 완주 실패
1.6시간
작업의 중앙값 길이
이전 세대(약 2분)의 약 48배로 늘린 난이도
83.5% → 20%
길이만 바꿨을 때
짧은 작업 포화 성적이 실제 길이 앞에서 추락
짧은 작업은 이미 풀렸다
컴퓨터를 직접 조작하는 에이전트의 성능은 지난 2년 사이 놀랍게 좋아졌습니다. 표준 척도 역할을 해 온 OSWorld 1.0에서 프론티어 에이전트들은 80% 안팎까지 올라섰고, OSWorld 개발팀이 밝힌 바에 따르면 최고 성적은 83.5%에 이르렀습니다. 파일을 열고 설정을 바꾸고 웹에서 정보를 찾아 입력하는 정도의 과제라면, 이제 사람의 개입 없이도 대부분 처리한다는 뜻입니다.
문제는 그 83.5%가 무엇을 재고 있었는가입니다. OSWorld 1.0의 작업은 중앙값 소요 시간이 약 2분, 평균 30스텝 안팎의 단발 조작이었습니다. 숙련자가 2분이면 끝낼 일을 잘 해낸다는 사실은 분명 진보지만, 우리가 실제로 에이전트에게 맡기고 싶은 일은 그런 모양이 아닙니다. 자료를 여러 곳에서 모아 표를 만들고, 조건에 맞는 항목만 골라 문서를 정리하고, 중간에 바뀐 요구를 반영해 다시 손보는 일은 2분이 아니라 몇 시간짜리입니다.
그래서 OSWorld를 만든 XLang Lab은 후속 벤치마크를 내놓으며 이렇게 물었습니다. 짧은 작업이 포화됐다고 해서 문제가 풀린 것인가. 답은 아니었습니다. 벤치마크가 잰 난이도가 실제 업무의 난이도를 담지 못했을 뿐입니다. 착시를 걷어 내려면 작업을 실제 길이로 되돌려야 했습니다.
핵심: 83.5%는 에이전트가 유능해졌다는 신호이자, 그 유능함을 재던 자가 너무 짧았다는 신호입니다. 짧은 작업의 포화는 문제 해결이 아니라 다음 질문의 출발점이었습니다.
실제 업무 길이로 재면 완주율이 절벽처럼 떨어진다
2026년 6월 공개된 OSWorld-V2는 108개의 장시간 워크플로우로 구성됩니다. 7개 전문 영역과 21개 세부 카테고리를 다루고, 외부 서비스 변동에 흔들리지 않도록 31개 서비스를 자체 호스팅한 통제된 환경에서 돌아갑니다. 작업의 중앙값 소요 시간은 약 1.6시간, 전체의 69.6%가 한 시간을 넘깁니다. OSWorld 1.0의 약 2분과 비교하면 난이도의 축을 지식이 아니라 지속 시간 쪽으로 크게 옮긴 셈입니다.
같은 세대의 프론티어 에이전트를 이 환경에 넣자 성적이 뒤집혔습니다. 최고 설정에서 최상위 에이전트가 500스텝 안에 끝낸 작업은 20.6%였고, 부분 점수까지 인정해도 54.8%에 그쳤습니다. 짧은 작업에서 83.5%를 받던 모델들이 실제 길이 앞에서 5분의 1 수준으로 내려앉은 것입니다. 모델이 갑자기 나빠진 게 아니라, 짧은 벤치마크가 가려 두었던 벽이 드러났습니다.
이 추락은 한 모델의 약점이 아니었습니다. 완료율 정상에 오른 에이전트는 다른 어떤 모델보다 많은 출력 토큰을 쏟아붓고도 그 자리에 머물렀고, 반대로 토큰을 가장 아낀 모델은 13% 안팎에 갇혔습니다. 연산을 더 들이거나 다른 프론티어 모델로 갈아탄다고 완주율이 크게 달라지지 않았다는 뜻입니다. 벽은 특정 모델이 아니라 작업 길이 그 자체에 있었습니다.
더 또렷한 그림은 작업 길이별 완료율에 있습니다. 45분 이하에서는 20%대를 유지하지만, 137분에서 163분 구간으로 가면 10% 아래로 떨어지고, 163분을 넘어가면 어떤 모델도 하나를 끝내지 못했습니다. 성능이 완만히 줄어드는 게 아니라, 한 시간 언저리에서 꺾이기 시작해 세 시간에 이르면 바닥에 닿는 절벽 곡선입니다.
| 작업 길이 구간 | 완료율(대략) | 해석 |
|---|---|---|
| 45분 이하 | 20~24% | 짧아도 실제 업무는 이미 어렵다 |
| 137~163분 | 10% 이하 | 한 시간을 넘기며 완주율이 꺾인다 |
| 163분 초과 | 0% | 세 시간에 이르면 아무도 끝내지 못한다 |
출처: Yuan et al., OSWorld-V2 (arXiv:2606.29537). 수치는 여러 모델의 대략적 구간별 완료율입니다.
핵심: 완주율은 작업이 길어질수록 완만히 낮아지는 것이 아니라 특정 지점에서 급격히 무너집니다. 시간이 곧 난이도인 세계에서, 데모의 성적과 실제 업무의 성적은 전혀 다른 곡선을 그립니다.
에이전트는 정확히 무엇을 잊는가
절벽이 어디에서 오는지는 실패를 뜯어봐야 알 수 있습니다. OSWorld-V2는 실패의 원인을 구조적으로 분류하는 방법론을 함께 제시했는데, 가장 어려운 카테고리는 화면에 드러나지 않은 상태를 스스로 복구해야 하는 작업(43개)이었고, 여러 출처의 정보를 엮어야 하는 작업(46개, 42.6%)이 뒤를 이었습니다. 두 유형의 공통점은 정보가 부족한 게 아니라, 이미 손에 쥔 정보를 끝까지 유지해야 한다는 데 있습니다.
케이스 스터디에서 반복된 실패 서사는 네 가지로 좁혀집니다. 정보를 언제 그만 모아야 할지 판단을 놓치고, 작업 도중에 벌어진 변경을 알아채지 못하며, 사용자에게 확인하는 대신 값을 추측하고, 마지막에 결과를 검증하지 않고 그대로 제출합니다. 어느 것도 지식의 문제가 아닙니다. 초반에 세운 조건, 중간에 도착한 사실, 다시 확인해야 할 시점을 몇 시간 동안 붙들고 가지 못한 문제입니다.
이 지점이 이전 두 편의 글과 이어지면서도 갈라집니다. 앞서 페블러스는 1년짜리 가상 경영 실험에서 생존을 가른 건 지능이 아니라 받아 적는 습관이었다는 이야기를 했고, 그전에는 에이전트를 무너뜨리는 건 약한 모델이 아니라 약한 하네스라는 이야기를 했습니다. 하네스라는 구조, 받아 적는 행동에 이어, 이번 글은 한 걸음 더 들어가 그 받아 적은 것 자체가 어떻게 망가지는가를 봅니다.
핵심: 에이전트가 잊는 것은 지식이 아니라 상태입니다. 확정한 제약, 도중에 도착한 정보, 다시 확인할 시점 — 몇 시간에 걸쳐 붙들어야 할 이 세 가지가 소리 없이 새어 나가는 순간 유능한 모델도 헛돕니다.
기억력이 아니라 데이터 품질 문제다
받아 적으면 해결된다는 처방은 절반만 맞습니다. 몇 시간에 걸쳐 쌓이는 맥락은 결국 에이전트가 계속 다시 읽는 하나의 데이터셋이고, 데이터셋은 관리하지 않으면 오염됩니다. OSWorld-V2가 관찰한 실패를 데이터 파이프라인의 언어로 옮기면, 우리가 사람의 데이터 품질에서 이미 알고 있던 실패와 정확히 겹칩니다.
| 에이전트가 보인 실패 | 데이터 품질의 언어로 |
|---|---|
| 초반에 정한 제약을 놓침 | 스키마 드리프트 — 확정한 조건이 상태 레코드에서 소리 없이 유실 |
| 작업 중 도착한 정보를 반영 못 함 | 증분 누락 — 초기 스냅샷만 참조하고 갱신을 흡수하지 못함 |
| 확인 대신 추측 | 무검증 삽입 — 출처 불명 값을 사실인 것처럼 상태에 기록 |
| 최종 검증 생략 | QA 게이트 부재 — 산출물을 검증 없이 그대로 커밋 |
여기서 한 가지 반전이 더 있습니다. Chroma Research가 18개 프론티어 모델을 시험한 결과, 컨텍스트가 길어질수록 한도에 닿기 전부터 성능이 비균일하게 저하됐고, 오히려 구조가 잘 잡힌 깔끔한 입력이 더 빨리 저하를 부르기도 했습니다. 깨끗해 보이는 로그일수록 사람도 에이전트도 다시 검증하지 않게 된다는 데이터 신뢰의 역설이, 에이전트의 긴 상태에도 똑같이 나타납니다.
핵심: 에이전트가 몇 시간짜리 일을 못 끝내는 건 더 똑똑한 모델이 없어서가 아니라, 그 몇 시간 동안 쌓인 상태를 하나의 데이터셋으로 관리하지 않았기 때문입니다. 스키마도 신선도 점검도 검증 게이트도 없는 데이터는 사람 손으로 짜도 파이프라인을 무너뜨립니다.
더 큰 모델이 아니라 상태를 데이터로
자연스러운 반문은 이것입니다. 컨텍스트 창을 더 넓히면 되지 않는가. 앞의 결과가 답합니다. 넓은 창이 곧 잘 활용되는 창은 아닙니다. 모델은 긴 입력의 처음과 끝은 붙들면서 중간은 흘려보내고, 창이 커질수록 오히려 어디에 주목해야 할지를 잃습니다. 더 큰 모델과 더 긴 창은 이 병목을 자동으로 풀어 주지 않습니다.
해야 할 일은 상태를 관리 대상 데이터로 승격시키는 것입니다. 첫째, 에이전트가 붙들어야 할 제약과 결정을 자유 서술이 아니라 구조화된 상태로 적게 합니다. 무엇이 확정됐고 무엇이 미정인지를 필드로 구분해 두면, 나중에 조용히 뒤집히는 일을 줄일 수 있습니다. 둘째, 작업을 시간 기준으로 쪼개 명시적 체크포인트를 두고, 그 지점마다 초기 제약과 최신 상태를 다시 대조하게 합니다. 셋째, 산출물을 제출하기 전에 검증 스텝을 통과하게 만듭니다. 사람의 파이프라인에 두는 스키마 검사와 QA 게이트를 에이전트의 상태에도 그대로 두는 것입니다.
그래서 질문은 이렇게 바뀝니다. 당신의 에이전트를 데모가 아니라 실제 몇 시간짜리 업무에 올리려면, 더 큰 모델을 기다릴 것인가, 아니면 그가 몇 시간 동안 들고 갈 상태를 데이터 계약처럼 설계할 것인가. 파일럿을 30분·1시간·2시간 구간으로 나눠 완주율을 재 보면, 당신의 에이전트가 정확히 어디에서 상태를 흘리는지 곧 드러납니다. 거기서부터가 진짜 시작입니다.
마무리: 긴 작업을 끝내는 힘은 더 큰 두뇌가 아니라 잘 관리된 상태에서 나옵니다. 에이전트가 몇 시간 동안 들고 가는 맥락은 데이터입니다. 그 데이터의 스키마와 신선도, 검증을 어떻게 다룰지가 자율화 시대의 실제 경쟁력입니다.
참고문헌
학술 논문
- 1.Yuan, M. et al. (2026). "OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks." arXiv:2606.29537. — 108개 장시간 데스크톱 워크플로우. 중앙값 1.6시간, 최상위 에이전트 이진 완료율 20.6%, 163분 초과 작업은 모든 모델 0%.
1차 소스
- 2.XLang Lab. (2026). "OSWorld-V2 Project Page." — 작업 길이 분포, 도메인 구성, 모델별 리더보드, exposure attribution 방법론 요약. 83.5% 포화 비교치 출처.
- 3.XLang Lab. (2026). "xlang-ai/OSWorld-V2." GitHub. — 벤치마크 코드·태스크·평가 하네스. 31개 자체 호스팅 서비스로 외부 변동 통제.
업계 리포트
- 4.Chroma Research. (2025). "Context Rot: How Increasing Input Tokens Impacts LLM Performance." Chroma. — 18개 모델 실험. 컨텍스트가 길어질수록 비균일 저하, 구조가 잘 잡힌 입력이 더 빨리 저하를 유발하기도.