Mage-VL-Cowork가 GUI와 터미널을 한 정책으로 오가게 학습한 방법

무엇인가

컴퓨터 사용 에이전트(CUA)는 보통 스크린샷을 보고 키보드와 마우스로 조작한다. 이 논문은 그 GUI 채널이 도메인의 속성이 아니라 비용이 큰 모델링 선택이라고 지적한다. 고해상도 스크린샷 한 장에 수천 토큰이 들고, 사람은 터미널이 빠를 때 터미널을 열고 파일을 읽어 대화상자의 주장을 확인하지만 픽셀만 보는 정책은 같은 일을 GUI로 다시 유도해야 한다. 그래서 GUI 채널(시각 관찰과 좌표 제어)과 터미널 채널(지속 셸에서 코드 실행, CLI, 애플리케이션 라이브러리 호출)을 하나의 정책 안에서 함께 쓰는 하이브리드 CUA를 만든다. 저자들은 도구 접근성만으로 하이브리드 역량이 생기지 않는다고 못 박는다. 프런티어 모델조차 기본 설정에서는 채널 라우팅이 최적이 아니며, 그 기본 롤아웃을 그대로 증류하면 한계까지 학생 모델로 복사된다는 것이다.

어떻게 동작하나

핵심 장치는 교사 에이전트의 하네스 진화다. 교사를 A_T=(M_T,H), H=(F,T,P,E)로 정의하고 모델 가중치는 고정한 채 스캐폴드 F, 도구 인터페이스 T, 시스템 프롬프트 P, 터미널 실행 환경 E를 개발 세트에서 최적화한다. 진화는 추가만이 아니라 제거이기도 하다. xdotool을 빼고 스크린샷 기반 네이티브 GUI 액션으로 통일해 중복 경로와 취약한 창 포커스 처리를 없앴고, 반대로 python-pptx 같은 도메인 라이브러리를 터미널 환경에 넣어 슬라이드·도형·텍스트 런을 직접 다루게 했다. GUI+코딩 변형은 AX를 덧붙인 변형보다 성공률이 높고 실행 스텝도 적었으며, 이 차이는 4B 학생에게 증류했을 때 12.5%포인트 격차로 벌어졌다. 진화된 하네스는 GUI 전용, 터미널 전용, 하이브리드 세 구성으로 인스턴스화되어 같은 합성 태스크를 서로 다른 채널로 풀어 각 학습 단계에 맞는 궤적을 공급한다.

무엇과 다른가

데이터는 Mage-CUA-Forge가 만든다. 태스크마다 에이전트를 새로 세우는 대신, 저작 에이전트가 애플리케이션별 준비기(preparer)와 스킬 조건화된 재사용 생성 워크플로를 한 번 만들어 두고 태스크 인스턴스마다 재사용한다. 워크플로가 지시문, 환경 설정 스크립트, 평가 루브릭을 한 묶음으로 내고 파일 수준 게이트와 패키지 수준 게이트가 일관성을 검사한다. 결과는 6,915개 원자 스킬에 걸친 293,806개 데스크톱·웹 태스크, 필터를 통과한 교사 궤적 318,837개이며 태스크당 반복 비용은 82.6% 줄었다. 단일 앱 태스크가 61.76%, 다중 앱이 38.24%이고, 태스크의 90.5%가 파일 참조를 가진다(평균 2.99개). 총 877,608건의 파일 참조는 coding 136,736, 스프레드시트 135,805, 텍스트/마크다운 134,050, 문서 74,052, PDF 53,996, 프레젠테이션 93,784로 나뉜다. 브라우저·교차 앱 태스크는 안티봇과 콘텐츠 드리프트를 피하려고 InfiniteWeb 합성 사이트와 WebHarbor 기반 복제 사이트를 에피소드마다 로컬 시드 DB에서 리셋해 사용한다.

어떻게 쓰나

학습은 GUI 그라운딩과 코딩이 이미 강한 체크포인트에서 출발하는 기존 파이프라인과 달리, 일반 멀티모달 정렬 4B 체크포인트에서 시작하는 5단계 커리큘럼이다. 1단계 GUI 지향 미드트레이닝은 그라운딩, 도구 호출, 추론이라는 세 원자 능력을 세운다. 2단계 GUI 에이전트 SFT는 GUI 전용 하네스 궤적으로 다단계 상호작용을, 3단계 코딩·터미널 SFT는 같은 데스크톱 태스크를 터미널 전용 하네스로 푼 궤적과 SWE-bench·Terminal-Bench류 데이터로 코드 실행을 가르친다. 4단계 하이브리드 SFT는 진화한 하네스의 궤적 318,837개(패킹 bin 1,377,805개)로 턴 단위 채널 라우팅을 학습한다. 이 데이터에서 교사 도구 호출의 68.19%가 GUI, 31.81%가 터미널이다. 5단계는 ScaleCUA가 공개한 검증 가능 보상 1,988개 태스크에서 GRPO 온라인 RL을 돌린다.

전제와 한계

문맥 설계도 결과에 영향을 준다. 각 턴 예제는 최근 스크린샷 3장과 완전한 응답 4개만 유지하고 더 이전 단계는 시스템 프롬프트 뒤의 한 줄 Action: 요약으로 접는다. 텍스트 턴 10개에 스크린샷 1장만 주던 초기 설정에서는 살짝 빗나간 클릭이 화면을 바꾸지 못하면 클릭 루프가 반복됐다. 또 같은 스크린샷에 대한 유사 질의를 함께 패킹하면 앞 턴의 좌표를 복사하는 지름길이 생겨, 목표 위치당 질의를 하나만 남기는 중복 제거를 적용했다. 그라운딩 예제(평균 33개 감독 토큰)와 추론 주석 툴콜 예제(평균 575개, 69%가 think 블록)의 불균형은 think 본문만 선택적으로 마스킹하고 여는·닫는 태그와 tool_call은 감독하는 방식으로 해결했다.

결과는 OSWorld-Verified, 50스텝 예산에서 66.0%다. Muse Glimmer-30B 65.9%, Qwen3.6-27B 63.9%, EvoCUA-32B 56.7%를 앞선다. 커리큘럼 내부 상승폭도 명확하다. GUI SFT 45.56%에서 하이브리드 SFT 55.84%, 최종 RL 66.0%로 20.44%포인트 올랐다. 학습 연산은 총 7.787×10^21 FLOPs로 미드트레이닝 15.2%, SFT 51.2%, RL 33.6%를 차지한다. RL 인프라는 데스크톱 실행, 추론, 정책 최적화를 분리한 RaaS 위에서 돌아가며 70대 CPU 호스트에 1,120개 환경 슬롯, B200 32장(학습 24, 추론 8) 구성에서 업데이트당 평균 570.3초, 시간당 6.31회 업데이트, 평균 정책 지연 2.71 업데이트를 기록했다.

개발자 관점에서 값은 두 가지다. 첫째, 데스크톱 자동화에서 GUI 클릭과 코드·터미널 실행을 오케스트레이터로 나누지 않고 단일 정책 안에서 라우팅하며, 그 라우팅을 데이터로 가르치는 설계다. 둘째, 4B급 소형 모델로 온디바이스 에이전트를 만들 때 태스크를 매번 새로 만드는 대신 스킬 단위 재사용 워크플로와 애플리케이션 준비기를 자산화하는 비용 구조다. 다만 66.0%는 OSWorld-Verified 단일 벤치마크, 50스텝 예산의 수치이므로 사내 앱과 권한 모델에서 그대로 재현된다고 가정하면 안 된다.

저자가 명시한 전제도 함께 봐야 한다. 터미널 채널은 운영 배포 시 명시적 권한 부여와 샌드박스 격리를 요구한다. 4B 모델은 노이즈 많거나 모호한 시연에 민감해서, 교사 하네스를 성공률과 토큰 효율 양쪽으로 최적화하고 궤적을 필터링하는 전처리가 필수라고 강조한다. 라이브 웹사이트는 안티봇 차단, 콘텐츠 드리프트, 리셋 불가능한 백엔드 상태 때문에 결정론적 자체 호스팅 복제 환경으로 대체했고, 온라인 RL은 ScaleCUA가 공개한 1,988개 태스크로 범위가 한정된다. 문맥 또한 최근 스크린샷 3장만 유지하는 절충이며, 그 밖의 정량적 한계 분석은 원문에서 확인되는 범위에 제시되어 있지 않다.