커뮤니티 해설난이도 보통파이토치 한국 사용자 모임 · 10월 28일(수) 공개

화면 조작과 코드를 함께 쓰는 OpenGCUA의 효과와 한계

화면 클릭과 코드 실행을 한 프로그램으로 묶는 OpenGCUA의 성능 비교와, 실제 컴퓨터에 적용할 때 남는 한계를 설명합니다.

쉽게 말하면비유하자면 표 수십 칸을 한 칸씩 지시해 채우게 하던 것을, 반복과 확인 방법까지 적은 절차서 한 장을 건네 처리하게 바꾼 것이다. 점수는 올랐지만, 오른 폭이 모두 이 방식 하나의 덕은 아니다.

왜 봐야 하나: 컴퓨터를 대신 조작하는 AI를 견줄 때 무엇과 비교한 점수인지 따져 보라는 뜻이다. 8개 모델 평균 19.6점 상승은 명령어 실행(셸)이 없는 방식과 견준 값이다. 셸을 똑같이 허용한 방식과 견주면 4개 모델에서 4.4~9.1점 차이다. 실제 기기용 도구는 초기 버전이다.

이 글은 2026년 10월 15일 최초 공개된 OpenGCUA 논문을 소개하는 10월 28일의 새 한국어 해설이다. 새 모델을 학습한 결과가 아니라, 기존 모델이 컴퓨터를 쓰는 방식을 바꾼 비교다. 매 단계 Python 프로그램으로 화면 조작과 셸 명령 등을 묶게 하자, 오프라인 82개 과제에서 8개 모델의 평균 부분 점수가 45.3점에서 64.9점으로 올랐다. 다만 셸 접근을 허용한 기준선과의 차이는 더 작아, 전체 이득을 코드 실행 하나의 효과로 볼 수 없다. 실기기 실험에서는 단계 수·토큰 사용량·금전 비용의 순위도 달랐다. 논문과 초기 구현 문서의 가능성 및 제약을 함께 읽어야 하는 연구 프리뷰다.

알아낸 것

82개 오프라인 과제에서 8개 모델의 평균 부분점수가 45.3점에서 64.9점으로 높아졌습니다.
같은 GUI·셸 접근을 허용한 기준선과 비교하면 점수 차이는 4.4~9.1점으로 줄었습니다.
실제 Mac의 네 과제에서는 토큰 사용량과 비용·완료 여부가 서로 다른 양상을 보였습니다.

한계와 주의할 점

기초 논문은 10월 15일 발표됐으며 오늘 새 연구 결과가 아닙니다.
선택된 실행과 제한된 과제의 결과이며 실기기 하네스는 초기 버전입니다.

용어 풀이

컴퓨터 사용 에이전트(CUA): 화면 캡처를 보고 마우스·키보드 동작을 출력해 컴퓨터 작업을 수행하는 에이전트. 전통적으로 GUI 전용이며, OpenGCUA는 이를 확장한 GCUA를 제안한다.
범용 컴퓨터 사용 에이전트(GCUA): 시각적 상호작용과 프로그램적 접근을 모두 사용하며, 무엇을 관찰할지·어떻게 행동할지·작업을 어떻게 정리할지를 모델이 매 단계 결정하는 에이전트 시스템. OpenGCUA의 핵심 정의다.
접근성 트리(AX Tree): 창 안의 버튼·입력란 등을 역할·이름·값으로 나타낸 구조 정보. 지원되는 요소는 좌표 대신 직접 지정할 수 있지만, 모든 앱·동작의 백그라운드 실행을 보장하지는 않는다.
코드 실행(Code Execution): 모델이 GUI 조작과 셸 명령을 반복문·조건문이 있는 Python 프로그램 하나로 묶어 출력하는 방식. 중간 결과가 다음 동작을 결정할 수 있어 모델 호출을 줄인다.
하네스-모델 결정 이전(Harness-to-Model Decision Transfer): 스크린샷 요청 시점, 작업 상태 기록 등 하네스가 규칙으로 고정하던 결정을 모델의 선택으로 옮기는 설계. OpenGCUA에서는 screenshot(), todo, <intent>로 구현된다.
배치 동작(Batched Actions): 한 번의 모델 호출에 여러 동작을 묶는 방식. 실행 결과에 따라 다음 동작을 바꾸는 분기나 반복이 없어, 논문은 제어 흐름이 없는 프로그램에 비유한다.
OSWorld-v2: 장시간 실제 업무형 컴퓨터 사용 에이전트 벤치마크. OpenGCUA는 외부 인터넷이 필요한 26개 과제를 제외한 오프라인 82개 과제로 평가했다.
부분 점수(Partial Score): 과제 완료 정도를 0~100으로 평가한 점수. binary full success와 구분되며, OpenGCUA의 주요 지표는 평균 부분 점수다.

더 깊이 읽기 읽는 데 약 8분

배경과 문제

컴퓨터 사용 에이전트(CUA)는 오랫동안 화면 캡처를 보고 마우스와 키보드 동작을 하나씩 내보내는 방식으로 연구되어 왔다. 이 방식은 픽셀만 있으면 어떤 앱이든 다룰 수 있지만, 표의 행 수십 개를 채우는 일처럼 같은 동작이 반복되는 작업에서는 클릭마다 모델을 다시 호출해야 한다. 논문은 GPT-6 Astra 같은 상용 시스템이 GUI 조작에 셸 명령과 접근성 트리(창 안의 버튼과 입력란을 역할·이름·값으로 나열한 구조 정보) 접근을 함께 쓴다고 설명한다. 그러나 이런 시스템의 프롬프트, 실기기 하네스, 실행 기록은 공개되어 있지 않아 연구자가 설계를 재현하거나 비교하기 어렵다.

OpenGCUA는 알리바바 MAI-UI 팀이 이 빈자리를 채우려고 공개한 프로젝트다. 이들은 범용 컴퓨터 사용 에이전트(GCUA)를 구성 요소가 아니라 결정 방식으로 정의한다. 매 단계마다 무엇을 관찰할지, 어떻게 행동할지, 작업을 어떻게 정리할지를 하네스 규칙이 아니라 모델이 정한다는 것이다. 기존 GUI 에이전트는 매 단계 스크린샷을 보고 GUI 동작 하나만 내보내며, 최근 k장의 스크린샷 유지 같은 작업 정리도 하네스 규칙으로 고정되어 있다. OpenGCUA는 이 결정들을 더 많이 모델에게 맡겨, 모델이 필요할 때만 스크린샷을 요청하고 Python 프로그램으로 여러 인터페이스를 조합하게 한다.

기존 접근의 한계

논문이 출발점으로 삼은 전형적인 GUI 에이전트는 세 가지 결정을 고정한다. 항상 스크린샷을 관찰하고, 한 단계에 GUI 동작 하나만 수행하며, 작업 상태는 하네스 규칙에 따라 유지한다. 이 때문에 반복 작업에서 모델 호출이 과도하게 늘고, 화면에 없는 정보(파일 내용, 앱 상태)를 확인하려면 별도의 도구가 필요하다. CLI 에이전트는 셸 명령과 스크립트를 쓸 수 있어 루프와 조건을 활용하지만, 그래픽 인터페이스로만 조작 가능한 앱은 다룰 수 없다.

같은 팀이 앞서 공개한 Qwen-UI-Agent는 GUI와 CLI 동작을 한 번의 호출에 여러 개 묶어 보내는 배치 방식을 썼다. 그러나 배치는 '제어 흐름이 없는 프로그램'이다. 모델이 첫 클릭의 결과를 보기 전에 모든 클릭을 정해야 하므로, 중간 결과에 따라 다음 동작을 바꿀 수 없다. OpenGCUA는 코드 실행을 도입해 프로그램이 실행되는 동안 조건 분기·반복·결과 확인이 이뤄지게 한다. 이는 배치 방식의 한계를 넘어서는 핵심 변화다.

연구방법을 단계별로

OpenGCUA의 코드 실행 하네스에서 모델은 단계마다 Python 프로그램 하나를 출력한다. OSWorld-v2 설정에서는 데스크톱 조작에 PyAutoGUI를, 셸 명령에 bash() 함수를 쓰고, 실기기 하네스는 브라우저 조작용 Playwright를 추가로 쓴다. 하네스는 코드 블록을 꺼내 문법을 확인한 뒤 실행하고, 표준 출력·오류·실행 상태를 다음 입력으로 돌려준다. 프로그램 안에서 GUI 클릭, 셸 명령, API 호출이 모두 문장으로 섞일 수 있고, 루프와 조건으로 중간 결과에 따라 다음 동작을 결정할 수 있다.

하네스-모델 결정 이전은 '무엇을 관찰할지'와 '작업을 어떻게 정리할지'를 다룬다. 현재 구현은 세 가지 인터페이스를 모델에게 준다. screenshot()은 모델이 다음 입력에 새 스크린샷이 필요한지 정하게 하고, todo는 진행 상황·확인한 사실·남은 질문을 기록하며, <intent>는 프로그램 실행 전에 목적을 한 문장으로 밝힌다. 다만 오래된 스크린샷을 여러 장씩 지우는 롤링 스크린샷 버퍼와 오래된 도구 출력을 짧은 자리표시로 바꾸는 마이크로 압축은 여전히 하네스 규칙으로 남아 있다. 즉 모든 운영 결정을 모델에 넘긴 것은 아니다.

결과와 숫자의 의미

평가는 OSWorld-v2 v2.1 오프라인 82개 과제에서 이뤄졌다. 외부 인터넷이 필요한 26개 과제는 제외하고 로컬 웹앱은 포함했다. 비교 기준선은 배치 동작을 지원하는 GUI 전용 에이전트다. 8개 모델 모두 점수가 올랐고, 평균 부분 점수는 45.3점에서 64.9점으로 19.6점 상승했다. 모델별 단계 감소율을 동일 가중치로 평균하면 53.0%다. 이는 전체 합산 절감률이나 경과시간 53% 절감이 아니며, 성공률 19.6% 증가도 아니다. 과제를 완전히 끝냈는지를 따지는 성공률은 별도 지표다.

이 결과를 읽을 때 기준선 선택이 중요하다. GUI-only + batch 기준선에는 셸이 없다. GUI+CLI + batch와 전체 OpenGCUA를 비교한 표3은 4개 모델에서 +4.4~9.1점이며, 관찰·상태제어·문맥정책까지 함께 달라진 비교다. 별도 그림6의 코드 실행 요소만 바꾼 실험은 Qwen/DeepSeek/GLM 3개 모델에서 GUI+CLI + batch 점수 57.2/50.9/55.8을 코드 실행 62.4/56.7/63.2로 올렸다. 셸 접근 추가만으로도 큰 개선이 발생하므로 19.6점 전부를 코드 반복문 하나의 효과로 귀속하면 오류다. 또한 단계가 줄어도 모든 모델의 출력 토큰이 줄지 않았다. GPT-6 Astra는 30.8K→31.9K, Gemini 3.8 Flash는 80.3K→82.0K로 늘었고, 6/8 모델 감소와 평균 상대 27.2%만 성립한다.

구체적인 예시

OSWorld-v2의 고객 관리(CRM) 과제에서 GPT-6 Astra가 실제로 출력한 한 단계를 보자. 모델은 <intent>로 '29건의 증거 기반 상태 변경을 원래 고객 정보를 보존하며 적용한다'고 밝히고, todo.update로 계획을 기록한 뒤, 앱 상태가 마지막 확인 후 바뀌었으면 멈추는 스크립트를 작성해 실행한다. 스크립트는 앱의 자체 API로 29건을 수정하고 하나씩 assert로 확인하며, 스크립트가 성공한 뒤에만 기록을 claimed_verified로 바꾼다. 이 한 단계에서 의도 표명, 계획 기록, 조건부 실행, 반복 수정, 검증이 모두 일어난다.

기술 보고서는 GPT-6 Astra의 궤적에서 반복해서 나타난 코드 실행 패턴 다섯 가지를 정리한다. 교차 인터페이스 구성(GUI 클릭과 파일 검사를 번갈아 수행), 루프 기반 실행(웹 페이지 7개 섹션을 반복문으로 방문하며 DOM으로 확인), 결과 의존 실행(초안이 일치할 때만 Send 클릭), 관찰 준비(3차원 객체의 25개 시점을 한 장의 번호 붙인 이미지로 모으기), 실행 가능한 검증(슬라이드 배경 2개를 고친 뒤 프레젠테이션 파일의 나머지 64개 항목이 그대로인지 assert로 확인)이다. 저자들은 이런 assert가 독립적인 평가를 대신하지는 않는다고 덧붙인다.

한계와 오해하기 쉬운 점

이 해설은 최초 공개일이 10월 15일인 arXiv v1 PDF 전체와 확보한 공개 문서를 기준으로 한다. 프리프린트이며 독립 재현이나 동료 심사 완료는 확인하지 않았다. 성능과 비용은 개발팀이 선정한 실행을 분석한 값이다. 각 실행에서는 과제마다 최고점 시도가 아닌, 평가 결과가 있는 마지막 시도를 집계했다. 반복 실행 변동과 통계적 유의성은 확정되지 않았다. 시간 분석도 API 대역폭·동시 환경 수·대기열 등이 통제되지 않아 참고 수준이다. 사후 비용 상한 분석은 전체 실행이 상한 안에 들어왔을 때만 최종 점수를 인정하며, 실제 중간 종료의 부분 점수를 측정한 것이 아니다.

실기기 표 5는 네 가지 macOS 과제에서 모델별로 선택한 run 1의 집계다. GPT-6 Astra는 과제당 평균 34.5단계·12.9K 출력 토큰으로 4개를, Qwen3.8-Max는 50.8단계·73.4K 출력 토큰으로 3개를 완료했다. 추론 토큰의 19.4배 차이와 전체 출력 토큰의 5.7배 차이는 서로 다른 지표다. 논문이 보존한 가격으로 계산한 과제당 평균 비용은 GPT 18.29달러, Qwen 1.49달러로 반대 순서이며 현재 가격은 아니다. DeepSeek은 호텔 실행 기록이 없어 집계에서 제외됐다. 네 과제의 선택 실행만으로 일반 모델 순위를 정할 수 없다. 본문의 125문항 중 85개만 채운 Qwen 사례는 표 5와 별개인 이전 저강도 추론 실행이다. 표 5의 선택 실행에서는 두 모델 모두 워크북 조건을 충족했다.

실제로 어떻게 활용할까

이 자료는 컴퓨터 사용 에이전트를 연구하거나 하네스를 설계할 때 비교 조건을 점검하는 데 도움이 된다. 개발팀은 여덟 모델의 평가 실행 기록을 공개했다고 설명하지만, 확보한 ROADMAP에는 예제 기록과 일부 평가 스크립트가 아직 계획·정리 단계로 적혀 있다. 모든 기록을 내려받아 재현 가능성을 확인한 것은 아니다. 학습된 GCUA 모델 가중치도 다음 공개 계획에 있으므로, 전체 스택과 새 모델이 모두 공개됐다고 받아들이면 안 된다.

실기기 하네스는 초기 버전이며 문서는 중요한 작업의 확인 절차가 아직 개발 중이라고 밝힌다. QUICKSTART의 Allow/Reject는 SDK를 통해 전면 포커스나 실제 마우스·키보드 입력을 요청하는 동작에 적용된다. 임의 Python·Bash 코드나 앱·웹사이트 자체 동작까지 막는 장치는 아니다. 중단 명령도 이미 실행된 일을 되돌리지 않는다. 또한 메일 본문 검사 통과는 전송 전 확인일 뿐 실제 배달 확인이 아니며, todo의 claimed_verified는 모델이 확인했다고 기록한 상태다. 이런 표시와 코드 안의 assert는 독립된 결과 검증을 대신하지 않는다.

원문에서 확인한 근거 6곳

OpenGCUA는 OSWorld-v2 오프라인 82개 과제에서 8개 모델의 평균 부분 점수를 45.3점에서 64.9점으로 19.6점 올렸다.Table 2: CUA versus OpenGCUA on
모델별 단계 감소율의 평균은 53.0%이며, 이는 전체 합산 절감률이 아니라 각 모델의 상대 감소율을 동일 가중치로 평균한 값이다.3.3.2 CUA versus GCUA
GUI+CLI + batch와 전체 OpenGCUA를 비교하면 4개 모델에서 점수 차이가 +4.4~9.1점으로 줄어든다.3: Full GCUA versus batched GUI+CLI
실기기 macOS 4개 과제에서 GPT-6 Astra는 4개를 완료하고 Qwen3.8-Max는 3개를 완료했으며, 추론 토큰은 Qwen이 19.4배 많다.Real-device results on four macOS tasks
실기기 하네스의 확인 절차(confirmation gating)는 아직 구현 중이며, 그 전까지는 상태를 잃어도 되는 컴퓨터에서만 실행하라고 안내한다.Status in this preview
QUICKSTART의 Allow/Reject는 SDK를 통한 전면 포커스·마우스·키보드 입력을 통제하며, 임의 Python/Bash 코드 전체에 대한 승인 장치는 아니다.Driver and observation settings (`mac_agent`)

출처소개 글 — 파이토치 한국 다룬 원문 PDF

10월 29일(목) 정리 · AI가 쓰고 원문과 대조