“사람보다 잘한다”는 점수, 우리 업무에도 적용될까요?
컴퓨터 사용형 AI 에이전트를 검토하다 보면 슬라이드 한 장이 결정을 재촉합니다. OSWorld-Verified 85%, 인간 기준선 약 72%. 포털 입력이나 티켓 처리를 맡겨도 되겠다는 생각이 들 만한 숫자예요.
하지만 점수 옆에 벤치마크 버전, 과제 길이, 에이전트 구성, 허용된 스텝 수가 없다면 아직 자사 업무의 성공률로 읽을 수 없습니다. 실제로 공개된 85%와 OSWorld 2.0의 20.6%는 모델부터 과제와 채점 방식까지 다른 결과예요. 둘의 차이는 AI 능력이 갑자기 추락했다는 증거가 아니라, 무엇을 어떤 조건에서 완료로 봤는지 먼저 확인해야 한다는 신호입니다.
85%는 ‘검증 완료된 공인 점수’가 아닙니다
a16z는 2026년 8월 10일 글에서 2026년 6월 기준 제3자 OSWorld-Verified 리더보드의 Claude Fable 5 점수 85%를 소개하며 약 72%의 인간 기준선을 넘어섰다고 설명했습니다. 다만 확인한 리더보드에는 Fable 5가 85.0%, Claude Opus 4.8이 83.4%로 표시되는 동시에, 등록된 24개 결과가 모두 self-reported이고 독립적으로 verified된 결과는 0개라고 적혀 있습니다.
여기서 ‘Verified’는 벤치마크 이름의 일부이지, 표에 올라온 개별 실행이 독립 검증됐다는 보증이 아니에요. Fable 5의 원 실행 보고서, 과제별 결과, 하네스, 스텝 예산과 재시도 조건도 공개 페이지에서는 확인되지 않았습니다. 따라서 85%는 a16z가 당시 인용한 제3자 리더보드 스냅샷으로 다루는 편이 정확합니다.
인간 72%라는 숫자도 출처를 구분해야 합니다. 2024년 원래 OSWorld 논문은 369개 과제에서 인간 성공률 72.36%, 당시 최고 모델 성공률 12.24%를 보고했습니다. 이 인간 평가가 이후 OSWorld-Verified의 정확히 같은 과제 집합과 프로토콜에서 다시 산출된 값인지는 공개 자료로 확인되지 않았습니다.
20.6%는 더 긴 업무를 ‘완전히 끝냈는지’ 묻습니다
OSWorld 2.0은 이름만 바꾼 같은 시험이 아닙니다. 연구·콘텐츠 제작·소프트웨어 개발·비즈니스와 금융 등 실제 업무를 반영한 장기 과제 108개로 구성됩니다. 숙련된 사람의 과제 완료시간 중앙값은 약 1.6시간이고, 69.6%는 1시간을 넘습니다. 과제당 채점 체크포인트는 평균 27.25개예요.
이 시험에서 Claude Opus 4.8은 500스텝, maximum thinking, batched tool calls 조건으로 이진 완료율 20.6%와 부분 점수 54.8%를 기록했습니다. 절반 넘게 진척했더라도 최종 산출물을 조건대로 끝내지 못하면 완전 완료에는 포함되지 않는다는 차이가 드러납니다.
긴 업무에서는 실행 부담도 달라집니다. 공식 자료는 Claude Opus 4.7 maximum thinking 실행의 평균 도구 호출이 약 318회였다고 설명하며, OSWorld 1.0의 약 30회와 대비합니다. 이는 모든 모델의 평균이 아니라 특정 구성의 결과지만, 짧은 앱 조작과 여러 단계를 이어가는 업무를 같은 숫자로 비교하기 어려운 이유는 잘 보여줍니다.
| 공개 수치 | 확인된 조건 | 그대로 말할 수 없는 것 |
|---|---|---|
| 85% | 제3자 OSWorld-Verified 리더보드의 Claude Fable 5 자체 보고 점수 | 독립 검증된 재현 결과, 자사 장기 업무의 완료율 |
| 20.6% | OSWorld 2.0에서 Claude Opus 4.8의 500스텝 조건 이진 완료율 | Fable 5가 같은 조건에서 64.4%포인트 하락했다는 결론 |
| 54.8% | 같은 OSWorld 2.0 실행의 부분 점수 | 업무의 54.8%가 실무에서 바로 사용 가능하다는 뜻 |
점수는 모델 이름이 아니라 ‘평가 조건 묶음’입니다
벤치마크 결과를 비교하려면 최소한 벤치마크 계열·릴리스·과제 집합·모델·에이전트 하네스·스텝 예산·재시도·사람 개입·채점 지표가 함께 있어야 합니다. 하나라도 다르면 숫자는 서로 다른 질문에 답했을 수 있어요.
릴리스도 빠뜨리면 안 됩니다. OSWorld 2.0의 공식 저장소는 현재 osworld-v2-2026.08.08을 권장하며 코드, 과제, 자산과 웹사이트 버전을 맞추라고 안내합니다. 이 릴리스에서는 14개 과제가 수정됐고 31개 과제의 평가 견고성과 공정성이 개선됐습니다. 논문의 20.6%가 이 수정 릴리스에서도 그대로 재현되는지는 공개 자료에서 확인되지 않았으므로, 릴리스가 다른 점수를 한 표에 놓고 순위를 매기면 안 됩니다.
한 줄로 적을 수 없는 점수는 아직 구매 근거가 아닙니다.
“OSWorld 85%” 대신 “OSWorld-Verified, 릴리스 미확인, Claude Fable 5, 제3자 리더보드 자체 보고, 하네스·스텝·재시도 미공개”처럼 적어보세요. 빈칸이 곧 벤더에게 물어볼 질문이 됩니다.
오늘은 벤더 점수와 실제 업무를 한 줄씩 맞춰보세요
새 평가 시스템부터 만들 필요는 없습니다. 벤더가 제시한 원문 링크와 자동화 후보 업무 한 개의 실제 기록을 열고, 아래 순서로 비교해보세요.
- 점수의 신분표를 만듭니다.
벤치마크 이름과 릴리스, 과제 집합, 모델, 하네스, 이진·부분 점수 구분, 스텝 예산, 재시도와 사람 개입 여부를 한 줄에 적습니다. 공개되지 않은 항목은 추측하지 말고 ‘미확인’으로 남기세요. - 검증 상태를 따로 표시합니다.
공식 평가인지, 독립 재현인지, 벤더 자체 보고인지 구분합니다. 벤치마크 이름에 ‘Verified’가 들어간다는 이유만으로 개별 결과까지 검증됐다고 표시하지 마세요. - 실제 업무의 길이와 갈림길을 적습니다.
예를 들어 보험 포털 청구라면 사용하는 앱 수, 외부 자료 대조, 중간 저장, 예외 발생 시 질문, 제출 뒤 확인까지 기록합니다. 접수 화면이 떴을 때가 아니라 후속 보완 없이 처리됐을 때를 완료로 볼 것인지도 정하세요. - 완전 완료와 부분 진척을 분리합니다.
파일럿 표에 ‘최종 완료’, ‘부분 완료’, ‘재시도 횟수’, ‘사람 개입’, ‘실행 뒤 발견된 실패’를 별도 열로 둡니다. 부분 점수가 높아도 후속 업무를 사람이 다시 해야 한다면 자동화 완료로 세지 않습니다. - 조건 차이가 큰 점수는 참고값으로 내립니다.
릴리스나 하네스가 없고 실행 궤적도 공개되지 않았다면 성능 보증이 아니라 후보 선별용 정보로만 사용하세요. 실제 구매 판단은 같은 업무 기록과 성공 기준으로 진행한 파일럿에서 내립니다.
벤더 주장: OSWorld-Verified 85%
출처와 검증 상태: 제3자 리더보드 / self-reported
벤치마크 릴리스·하네스·스텝·재시도: 미확인
우리 업무: 보험 포털 청구 제출
완료 기준: 접수 화면이 아니라 후속 보완 없이 처리 완료
에스컬레이션: 정책번호 불일치 또는 추가 확인 요청 시 담당자 전달
이 기록을 마쳤을 때의 성공 기준은 특정 점수를 믿거나 반박하는 것이 아닙니다. 벤더 점수를 재현 가능한 조건으로 설명하고, 그 조건과 자사 업무의 차이를 표시하며, 파일럿의 완전 완료율과 사람 개입을 별도로 셀 수 있으면 됩니다.
a16z가 업체 인터뷰를 통해 소개한 적용 사례도 시스템 기록 갱신, 포털 간 데이터 이동, 티켓 처리처럼 범위와 완료 조건이 비교적 명확한 업무에 집중돼 있었습니다. 원문 역시 검증, 권한, 오류 처리와 에스컬레이션을 중요한 운영 계층으로 짚습니다. 다만 소개된 업체 사례는 전체 시도 수와 실패율, 독립 검증 자료가 공개되지 않았으므로 일반적인 ROI 근거로 확대하면 안 됩니다.
