알리바바 토큰 허브(MAI-UI 팀)가 공개한 OpenGCUA는 "컴퓨터를 쓰는 AI"를 만드는 데 필요한 것 전부를 커뮤니티에 열겠다는 프로젝트의 첫 보고서다. 무엇이 달라지는지부터 말하면 두 가지다.
하나, 에이전트가 화면을 클릭하는 대신 코드를 짜서 컴퓨터를 다루게 하면 작업 점수가 오르고 단계 수가 줄어든다. 둘, 지금까지 하네스(에이전트를 감싸 실행을 통제하는 뼈대)가 규칙으로 정해 두던 결정을 모델이 직접 고르게 하면 효율이 좋아진다.
전제가 하나 있다. 이번 보고서에는 새로 학습한 모델이 없다. 기존 모델들을 이 설계 위에 얹어 돌린 결과이고, 실험에 올린 모델 전부에서 개선이 나타났다. 모델이 똑똑해져서가 아니라 일하는 방식을 바꿔서 나온 변화라는 뜻이다.
컴퓨터 사용 에이전트(CUA, 컴퓨터를 대신 조작하는 AI) 연구는 오랫동안 한 가지 그림에 묶여 있었다. 모델에게 스크린샷을 보여주고 마우스·키보드로 화면을 다루게 하는 것이다. 사람이 컴퓨터를 쓰는 모습을 그대로 흉내 낸다. 이걸 GUI 전용 에이전트라고 부른다.
이 방식은 화면을 오가는 일이 반복될수록 느려진다. 예를 들어 여러 엑셀 파일에 흩어진 매출을 모아 다른 업무용 앱에 입력하는 일을 생각해 보자. GUI 전용 에이전트는 파일을 하나 열어 화면을 찍고, 값을 눈으로 읽고, 앱으로 창을 바꿔 입력하고, 다음 파일로 돌아가 같은 일을 되풀이한다. 파일이 늘어날수록 "보고-판단-입력"의 왕복이 그대로 불어나고, 그때마다 모델을 다시 불러야 한다. 같은 일을 코드로 하면, 파일들을 한 번에 읽어 합치고 앱에 넣는 스크립트 한 조각으로 끝나는 경우가 많다.
그래서 가장 앞선 시스템들은 GUI 조작에 셸 명령(터미널에 입력하는 컴퓨터 명령), 접근성 트리(화면 요소를 좌표가 아니라 역할·이름·값의 구조로 읽는 통로), 각종 API를 섞기 시작했다. OpenAI도 GPT-6 Astra를 내놓으면서 컴퓨터 사용 가이드를 "GUI 조작을 코드로 쓰고, 계산과 묶어 한 번의 출력으로 처리하라"는 쪽으로 바꿨다. 질문이 달라진 것이다. "모델이 GUI를 얼마나 잘 다루나"에서 "시스템이 어떤 수단을 쓰든 실제 컴퓨터에서 일을 얼마나 잘 끝내나"로.
문제는 이런 대표 구현이 거의 닫혀 있다는 점이다. GPT-6 Astra만 해도 모델 가중치는 물론 전체 프롬프트 구성, 실기기 하네스, 기기 제어 SDK, 실행 기록 어느 것도 공개돼 있지 않다. 그래서 커뮤니티는 이 시스템을 재현하거나, 다른 설계와 비교하거나, 어떤 설계 선택이 비용과 성공률을 어떻게 바꾸는지 따져볼 수 없다. OpenGCUA는 그 닫힌 부분을 열어 함께 연구하자는 제안이다.
저자들은 좋은 에이전트를 부품의 개수로 정의하지 않는다. 모델, 화면 인식, 작업 조율, 도구, 실행 환경까지 구성요소를 다 갖춰도, 셸 명령 한 줄이면 될 일을 화면 열 번 클릭으로 처리하면 소용없기 때문이다. 그래서 "일반형 컴퓨터 사용 에이전트(GCUA)"를 매 단계 내리는 세 가지 결정으로 정의한다.
행동과 관찰은 네 가지 통로를 지난다. GUI(화면 클릭), 접근성 트리, CLI(명령어로 컴퓨터를 조작하는 방식), API다. 저마다 강점이 다르다. GUI는 픽셀이 보이는 곳이면 어디서든 통하지만 느리고, 접근성 트리는 좌표 없이 요소를 직접 집는다. CLI는 파일과 데이터를 대량으로 다루는 데 강하고, API는 화면으로도 명령어로도 닿지 못하는 기능에 닿는다. 하나가 늘 최선인 것은 아니어서, 매 단계 맞는 통로를 고르고 필요하면 섞는 것이 핵심이다.
첫 번째 결정축은 코드 실행이다. 모델이 pyautogui.click() 같은 화면 조작, bash()로 실행하는 셸 명령, 파이썬 계산을 하나의 프로그램 안에 섞어 쓴다.
기존의 "배치 동작" 방식과 비교하면 차이가 분명하다. 배치 동작은 모델이 한 번 불릴 때 할 동작들을 미리 정해 한꺼번에 내보낸다. 첫 클릭의 결과를 보기도 전에 그다음 클릭까지 다 정해야 한다. 코드 실행은 프로그램이 돌아가는 도중에 다음 행동을 정한다. 한 번의 호출 안에서 조건("대화상자가 보이면 닫아라"), 반복("각 행마다 세 필드를 채워라"), 검증("상태가 저장됨인지 확인해라")이 가능해진다. 열두 번 오갈 일이 한 번에 끝난다. 저자들은 자신들의 이전 작업인 배치 동작을 "제어 흐름이 없는 프로그램"이라 부르며, 종착지가 아니라 디딤돌이었다고 평가한다.
이점은 두 가지다. 중간 결과가 다음 동작을 정하므로 모델을 다시 부를 일이 줄고, 모델이 이미 가진 프로그래밍 능력을 컴퓨터 조작에 그대로 끌어 쓸 수 있다. 저자들이 GPT-6 Astra의 실제 실행 기록을 뜯어본 사례에서는 반복되는 패턴 다섯 가지가 나왔다. 한 통로에서 얻은 정보를 다른 통로가 받아 쓰는 교차 조합, 25개 화면을 한 장의 콘택트 시트(여러 화면을 한 장에 모아 붙인 이미지)로 묶어 다음 관찰로 쓰기, 배경 이미지와 투명도를 assert(조건이 맞는지 검사하는 코드)로 확인하기 등이다.
두 번째 결정축은 하네스가 쥐고 있던 결정을 모델에게 넘기는 것이다. 전통적 하네스는 "매 단계 스크린샷을 찍는다"처럼 많은 결정을 규칙으로 고정한다. OpenGCUA는 이런 결정을 모델이 직접 하게 한다. 지금 구현에서 모델은 스크린샷이 언제 필요한지 스스로 요청하고, 작업 상태를 어떻게 추적할지 정하며, 프로그램을 실행하기 전에 그 프로그램의 목적을 먼저 밝힌다.
이게 왜 비용과 연결될까. AI는 입력을 토큰(글자·이미지를 잘게 나눈 처리 단위)으로 바꿔 처리하고, 처리량이 많을수록 비용이 든다. 캐시는 입력의 앞부분(접두부)이 지난번과 똑같을 때 그 부분을 다시 계산하지 않고 재사용하는 장치다. 새 스크린샷을 입력 끝에 덧붙이는 것만으로는 이미 쌓인 접두부가 깨지지 않는다. 재사용이 깨지는 쪽은 맥락을 줄이려고 과거 스크린샷을 지우거나 바꿔 접두부 자체가 달라질 때다. 논문 구현은 매 단계 스크린샷을 계속 촬영하되, 그것을 모델에 넣을지만 고른다. 모델이 "지금은 화면을 볼 필요 없음"을 판단해 화면을 덜 끼워 넣으면, 맥락이 천천히 불어 과거 관찰을 지우거나 바꿀 일이 줄고, 그만큼 접두부가 유지돼 재사용이 살아 비용이 준다.
같은 틀(세 가지 결정)로 기존 계열을 세워 보면 차이가 보인다. GUI 에이전트는 세 결정을 전부 고정한다. 늘 스크린샷만 보고, 한 번에 GUI 동작 하나만 하고, 맥락은 "최근 몇 장" 같은 규칙을 따른다. CLI 에이전트는 화면을 못 보는 대신 셸에서 반복·분기·변수를 쓸 수 있어 유연하지만, 그래픽으로만 되는 앱은 다루지 못한다. 멀티 에이전트 하이브리드는 지휘자 역할이 과제를 쪼개 GUI 담당과 프로그래머에게 나눠 주는데, 통로 선택이 서브 과제마다 한 번, 그것도 지휘자에게서만 일어난다.
저자들의 이전 작업 Qwen-UI-Agent는 GUI와 CLI를 한 행동 공간에 넣되 동작을 배치로 묶은, GCUA의 제한된 특수 사례다. GCUA는 그 제약을 모두 푼다. 고정된 동작 순서 대신 네 통로에 걸친 프로그램을 쓰고, 매 단계 스크린샷을 받는 대신 무엇을 볼지 스스로 정하고, 하네스 규칙 대신 작업 상태를 모델이 관리한다. 이 연구의 새로움은 새 통로를 발명한 데 있지 않다. 흩어져 있던 접근을 "결정을 누가 내리는가"라는 한 축으로 정렬하고, 그 결정을 모델 쪽으로 밀어붙인 재구성에 있다.
평가 무대는 OSWorld-v2의 오프라인 세트다(컴퓨터 작업 수행 능력을 재는 벤치마크). 비교 대상은 여덟 개의 앞선 모델이고, GPT-6 Astra와 Claude Opus 5가 명시돼 있다. 저자들은 자신들의 GCUA 설계를 OpenGCUA 하네스로 구현해, 기존 모델들이 코드 실행과 결정 이양을 쓸 수 있게 한 뒤 돌렸다. 이번 단계에는 자체 학습 모델이 없으므로, 이 실험이 재는 것은 모델의 능력이 아니라 "같은 모델을 어떤 하네스에 얹느냐", 곧 설계의 효과다.
효율은 성공률 하나로 끝내지 않는다. 저자들은 작업당 단계 수(한 단계 = 모델 호출 한 번), 출력 토큰, 추론 토큰(출력 토큰에 포함되지만 따로 보고), 비용을 함께 본다. 위임은 사람이 직접 하는 것보다 빨리 결과를 낼 때 비로소 값하기 때문이다. 다만 이 지표들은 벤치마크 안의 효율을 잴 뿐, 실제 사용자 컴퓨터의 모든 조건을 담지는 못한다. 그 간극은 뒤의 실기기 파트에서 다룬다.
| 비교 조건 | 켠 기능 | 점수 변화 | 단계·효율 변화 |
|---|---|---|---|
| 전체 GCUA 설정 vs 배치 GUI 전용 | 코드 실행 + 결정 이양 | 평균 부분 점수 +19.6점 | 작업당 단계 −53.0% |
| 코드 실행 단독 vs GUI+CLI 기준선 | 코드 실행만 | 평균 부분 점수 +6.1점 | 단계 −14.8% |
| Qwen3.8-Max vs 하이브리드 CUA 기준선 | 코드 실행 | 평균 작업 점수 +5.2점 | 단계 −17.0% |
| 온디맨드 관찰(두 모델) | 결정 이양만 | 작업 점수 유지 | 캐시 적중률 +10.5%p, +14.4%p |
평균 부분 점수(mean partial score)는 과제를 끝까지는 못 해도 부분적으로 얼마나 해냈는지까지 반영한 점수다.
표의 첫 줄이 핵심이다. 코드 실행과 결정 이양을 모두 켠 전체 설정은 가장 약한 기준선인 배치 GUI 전용 대비 점수를 크게 올리고 단계를 절반 넘게 줄였다. 개선은 여덟 모델 전부에서 나타났고, 가장 강한 모델과 약한 모델 사이의 점수 격차를 절반 넘게 좁혔다. 격차 축소는 약한 모델이 설계 개선의 혜택을 더 크게 받았을 가능성을 보여준다.
둘째·셋째 줄은 코드 실행만 떼어낸 기여인데, 두 수치는 비교 기준이 다르다. 6.1점은 GUI+CLI 기준선 대비 평균이고, 5.2점은 Qwen3.8-Max 한 모델의 결과다. 이미 셸을 쓰는 시스템에 코드 실행을 더했을 때 기대할 몫은 이쪽에 가깝다.
넷째 줄의 결정 이양은 더 조심스럽게 제시된다. 온디맨드 관찰(모델이 필요할 때만 스크린샷을 요청)만 켰을 때, 두 모델에서 캐시 적중률이 오르면서도 작업 점수는 떨어지지 않았다. 효율은 벌되 성능은 지켰다는 뜻이며, 이는 특정 두 모델의 캐시 적중률이라는 한정된 관찰이다.
실기기 결과는 성격이 다르다. 실제 macOS 과제 네 개에서 모델 간 격차가 벤치마크보다 훨씬 크게 벌어졌다. 하네스를 고정한 채 Qwen3.8-Max는 GPT-6 Astra 대비 추론 토큰을 19.4배, 출력 토큰을 5.7배 쓰고도 완료한 과제는 더 적었다. 사례 연구는 원인을 모델 행동에서 찾는다. 단순 조작에 과한 추론을 쏟고, 실기기 조건에 적응하기 어려워하며, 코드 실행 능력에서 차이가 난다는 것이다. 하네스를 아무리 잘 짜도 메울 수 없는 격차가 모델 자체에 남는다는 뜻이고, OpenGCUA가 다음 단계로 자체 모델 학습을 로드맵에 올린 이유다.
저자들이 밝히는 한계는 분명하다. 이번 릴리스에는 학습된 모델이 없다. 실기기 하네스와 크로스 디바이스 SDK는 예비(preliminary) 버전이다. 실기기 평가는 macOS 과제 네 개뿐이라 경향을 짚기엔 작은 표본이고, 저자들도 이를 결정적 벤치마크가 아니라 사례로 다룬다.
더 따져볼 지점도 있다. 첫째, 전체 설정의 19.6점 향상은 배치 GUI 전용이라는 약한 기준선 대비다. 이미 코드 실행을 쓰는 시스템과 비교하면 순수 이득은 이 숫자만으로 단정하기 어렵고, 코드 실행 단독 6.1점이 그 질문에 더 가깝지만 역시 GUI+CLI 기준선 한정이다. 둘째, 코드 실행은 모델에게 임의의 셸 명령과 파이썬을 돌릴 권한을 준다. 이를 사용자 실기기에 올릴 때의 안전 경계는 이 보고서의 초점이 아니어서, 제품으로 가져갈 쪽이 따로 설계해야 한다. 셋째, "무엇을 볼지 모델이 정한다"는 설계에는 반대급부가 있다. 모델이 관찰을 건너뛴 사이 파일 저장이 실패하거나 화면 상태가 바뀐 것을 놓치면, 틀린 전제 위에서 다음 코드를 돌려 오류가 커진다. 호출을 줄이는 이득과 오류를 일찍 발견할 기회가 줄어드는 손실을 함께 봐야 설계의 절충이 보인다.
온틀은 AI 프로젝트 매니저를 파견하는 서비스다. 사람을 뽑기 어려운 소기업과 1인 창업가의 반복 업무를 덜어 주는 게 일이다. 매주 월요일 AI PM이 만드는 주간 운영 리포트를 예로 들어 보자. 재고 스프레드시트에서 지난주 판매량을 집계하고, 거래처 PDF 정산서에서 금액을 뽑고, 쇼핑몰 어드민에서 리뷰 평점을 확인해 보고 템플릿을 채우는 일인데, 여기엔 앞서 본 "여러 화면을 오가는 반복"이 그대로 들어 있다. 코드 실행이라면 집계를 스크립트로 처리하고, 정산서 합계와 어드민 매출이 맞는지 assert로 그 자리에서 검증해, 창을 열두 번 오갈 일을 한 프로그램 안에서 끝낼 수 있다.
아직 온틀에 이 설계를 적용한 것은 아니다. 다만 적용한다면 무엇이 남아야 하는지는 또렷하다. 실행 전에 프로그램의 목적을 먼저 밝히는 방식은, 입력으로 쓴 자료·실행 결과·대조에서 어긋난 기록이 함께 로그로 남을 때 비로소 감사 가능성이 된다. 리포트가 틀렸을 때 어느 판단에서 어긋났는지 되짚을 수 있어야 하고, 정산서 합계와 어드민 매출이 맞지 않는 것처럼 대조가 깨지는 순간에는 AI가 멈추고 사람에게 넘기도록 경계를 미리 정해 두어야 한다. 어떤 모델을 엔진으로 얹느냐도 함께 재야 한다. 실기기 결과가 보여줬듯, 같은 하네스에서도 모델에 따라 단순 조작에 추론 토큰을 19배 넘게 더 쓰기 때문이다.
컴퓨터·브라우저·휴대폰에 하나의 프로그래밍 인터페이스를 주려는 예비 도구입니다. 모든 조작을 특정 기기·앱·창·탭에 명시적으로 묶고, 접근성과 비전을 관찰·조작의 별도 수단으로 유지하며, 한 프로그램이 하나의 과제 안에서 여러 기기를 조율할 수 있게 합니다. 여러 기기에 걸친 작업을 한 흐름으로 다루려는 설계입니다.
추론 토큰은 출력 토큰에 포함되지만, 모델이 '생각'에 자원을 얼마나 쏟는지를 따로 보여 주는 양입니다. 실기기에서 어떤 모델이 단순 조작에 과한 추론을 쏟느냐가 비용 격차를 갈랐던 만큼, 출력에 섞어 두면 안 보이는 이 몫을 떼어 봐야 같은 하네스에서도 왜 비용이 벌어지는지가 드러납니다.
반영 요약 (비평 8건 대응):
1. 제목·요약을 '대체'→'선택'으로 전환.
2. 도입에서 OSWorld-v2·모델명·여덟 개 수치를 실험 절로 이동, CLI·assert·콘택트 시트·토큰·캐시·부분 점수를 첫 등장에서 한 줄 풀이.
3. 엑셀 1000행 예시 → 여러 파일 수집·입력 사례로 교체하고 GUI vs 코드를 같은 과제로 대비.
4. 다섯 층 신체 비유 삭제, 핵심 아이디어를 '제약→코드 실행→선택권' 순으로, 「다른 접근 비교」를 한계 뒤에서 앞으로 이동.
5. 결과를 '비교 조건·점수·단계' 표로 묶어 숫자 관리 부담 제거, 체크리스트=행동만, FAQ=본문에 없는 2건만(끊긴 문장 완결).
6. "왜 중요한가/가장 큰 숫자부터/왕도/발목을 풀어주는/연구자로서/발췌 범위 밖" 등 환기·장식 문구 제거, 해석을 문장 안에 담음.
7. 토큰·캐시 작동을 한 단락으로 설명, 한계의 "더 크게 틀릴 여지"를 저장 실패·화면 상태 변화 사례로 구체화하고 절충 관계 명시.
8. 온틀 사례를 한 단락으로 줄이고 실제 적용 여부(미적용)와 적용 구상을 구분, 감사 로그 구성과 사람 에스컬레이션 기준 제시.
제약 준수: 수치·링크·저자명 등 사실은 추가·변경 없이 그대로 유지했다.