OS-Helix는 GUI와 코드 실행을 한 정책으로 학습한다

무엇인가

이 논문은 실제 데스크톱 자동화가 순수 GUI도, 순수 코드도 아니라는 문제에서 출발한다. GUI 에이전트는 작거나 모호한 인터페이스 요소에서 실패할 수 있고, 구조화된 상태 조작은 번거롭다. 반대로 코드 실행만으로는 시각적 레이아웃, 애플리케이션별 UI 상태, 인터페이스로만 드러나는 소프트웨어 동작을 다루기 어렵다. 기존의 프레임워크 중심 하이브리드 시스템, 애플리케이션별 도구 호출, 모델 퓨전은 GUI와 코드를 밖에서 조합하지만, 하나의 정책이 언제 GUI를 쓰고 언제 코드로 전환할지를 학습하는 문제는 남아 있다. 저자들은 Qwen3-VL-32B-Instruct가 OSWorld-Verified에서 GUI만으로 약 34% 성공률을 보이다가 코드 실행을 순진하게 노출하면 약 32%로 떨어지는 예비 실험을 근거로, 프롬프트 수준의 도구 조합만으로는 라우팅이 생기지 않는다고 주장한다.

어떻게 동작하나

제안 방법의 핵심은 GUI 조작과 코드 실행을 하나의 행동 공간에 넣고 end-to-end로 학습하는 것이다. 행동 공간은 GUI 클릭·타이핑 같은 GUI 행동, 과제 종료 같은 메타 행동, Python 또는 Bash를 실행하는 코드 행동으로 구성된다. 코드 행동은 매번 새 프로세스에서 실행되고, stdout과 stderr가 현재 턴의 도구 응답으로 문맥에 추가되어 다음 의사결정에 쓰인다. 즉 모델은 스크린샷과 대화 이력을 보고 GUI 행동과 코드 행동 중 하나를 직접 선택하도록 훈련된다.

무엇과 다른가

데이터 인프라는 애플리케이션-아티팩트 합성과 환경 기반 과제 합성으로 이루어진다. 버전이 고정된 애플리케이션과 실제 파일 아티팩트를 파일 형식 호환성 그래프로 연결해 재현 가능한 Ubuntu 가상머신 상태를 만든다. Exploration Agent는 애플리케이션별로 이미 사용한 기능을 기록하는 전역 메모리, 파일 경로, 실행 설정, 튜토리얼, 초기 스크린샷을 받고 비파괴적 탐색을 짧게 수행한 뒤 현실적인 사용자 지시와 성공 조건을 제안한다. 이때 GUI나 코드 해법을 미리 정하지 않는다. 지시 제안과 평가기 합성은 분리되어, 독립 Evaluator Agent가 검증 로직을 만든다. 가능한 종료 조건은 파일로 검사하는 everything-is-a-file 추상화를 따르고, 규칙 기반 검사와 VLM 기반 검사, 둘의 혼합을 사용한다. 지시는 도달 가능성·모호성·현실성·검증 조건을, 평가기는 컴파일 가능성과 초기 상태에서 0 보상을 주는지를 검증하며, 중복 과제는 제거된다.

어떻게 쓰나

훈련은 SFT 콜드 스타트 뒤 온라인 RL로 진행된다. SFT에는 Claude Sonnet 4.6을 Computer Use와 Bash Tool을 켠 교사 모델로 사용해 만든 궤적을 평가기 점수로 거부 샘플링하고, 잘못된 도구 호출과 스키마 불일치를 걸러낸 약 31K개의 성공한 데스크톱 샘플과 40K개의 일반 멀티모달 샘플을 쓴다. 이후 실제 데스크톱 환경에서 규칙 기반 평가기만 보상으로 온라인 RL을 수행한다. 여러 머신에 걸친 100개 이상의 Ubuntu 샌드박스를 관리하고, 롤아웃 정책이 최신 정책보다 최대 한 버전 뒤처지는 비동기 파이프라인, 현재 역량 근처 과제를 더 샘플링하는 전략, 슬라이딩 윈도 시각 문맥 분할을 사용한다. 저자들이 제안한 Step-balanced GSPO는 표준 GSPO가 모든 어시스턴트 토큰의 로그 중요도를 평균해 긴 코드 행동이 최적화를 지배하는 문제를 바꾼다. 각 행동 스텝의 토큰 로그 중요도 평균을 구한 뒤, GUI와 코드 스텝에 동일한 가중치를 주어 스텝 수 기준으로 샘플 수준 비율을 집계한다. 토큰 수가 아니라 행동 스텝 수가 균형을 결정하게 만드는 것이다.

전제와 한계

실험은 OSWorld-Verified 361개 과제에서 진행됐다. 원래 369개 중 Google Drive 8개를 제외했고, 에피소드는 최대 50 상호작용 스텝, 최대 8개 스크린샷 1504x832을 사용한다. Qwen3.5-27B와 Qwen3.5-35B-A3B 기반 OS-Helix-27B와 OS-Helix-35B-A3B는 매칭된 Qwen3.5 하이브리드 베이스라인 대비 각각 상대 35.0%, 33.7% 개선됐고 절대값으로는 16.25점, 14.43점 올랐다. OS-Helix-27B-RL은 매칭 베이스라인 대비 상대 42.9% 개선으로 66.44% 성공률에 도달했으며, SFT 62.75%에서 RL로 66.44%까지 올라갔다. Office 범주는 각각 33.3점, 29.1점, Work 범주는 16.0점, 14.1점 개선됐다. RL의 추가 이득은 Professional 23.10점, OS 7.61점, Daily 6.69점에 집중됐다. WindowsAgentArena에서는 OS-Helix-27B-RL이 63.87%로 Qwen3.5-27B GUI 베이스라인보다 23.05점 높았다. Pass@1은 62.75%에서 66.44%, Pass@3은 70.88%에서 76.44%로 증가했다. GPT-5 기반 Agent-S3, OS-Symphony와 경쟁적이지만 더 크고 최신인 일반 모델이 전체적으로 더 강하다고 저자들은 밝힌다.

절제 실험은 방법의 각 주장을 뒷받침한다. 표준 GSPO는 성공률을 60.47%로 낮추고 코드 행동 비율을 SFT의 27.9%에서 40.0%로 끌어올렸다. Step-balanced GSPO는 성공률을 높이면서 코드 행동 비율을 26.1%로 SFT에 가깝게 유지했다. 같은 정책에서 코드를 끄면 52.13%였고, 켜면 10.62점이 더해져 GUI 능력이 유지되면서 코드가 보완한다는 증거를 제시한다. 10K 샘플 예산을 고정한 비교에서는 하이브리드 SFT가 GUI-only SFT보다 3.05점 높았다. OSWorld 관련 9개 애플리케이션 도메인을 제거해도 62.75%에서 62.31%로만 변해, 평가 도메인 밖으로 전이되는 능력을 시사한다. Kimi K2.5와 Claude Sonnet 4.6 교사 궤적 모두 적응 전 하이브리드 백본을 앞섰고 더 강한 교사가 더 좋았다. 합성 지시와 OSWorld의 코사인 유사도는 OSWorld 내부 지시 유사도와 비슷한 수준이어서 직접적인 지시 중복 가능성도 낮다고 주장한다.

개발자 관점에서 이 논문은 데스크톱 에이전트에 셸 도구를 붙이는 것만으로는 GUI/코드 라우팅이 생기지 않는다는 점을 보여준다. 재현 가능한 애플리케이션-아티팩트 상태, 해법 양식과 무관한 평가기, 행동 길이가 다른 이종 행동을 위한 스텝 균형 RL 목적이 실무 설계에 직접 참고된다. 다만 코드 행동은 매번 새 프로세스에서 실행되고 출력이 문맥에 붙는 구조이므로, 샌드박스·권한·감사 로그·결과 검증을 함께 설계해야 한다. 또한 RL은 규칙 기반 평가기만 사용하고 평가는 50스텝으로 제한된다는 전제를 확인해야 한다.

저자들이 밝힌 한계는 배포 안전성이다. 실험은 고정된 애플리케이션 버전과 큐레이션된 로컬 파일 라이브러리를 쓰는 격리된 Ubuntu 가상머신에서 수행되어 개인 호스트 파일과 자격 증명에서 분리되어 있다. 그러나 실제 기기에서 GUI 관찰과 Python/Bash 실행을 결합하면 개인식별정보, 기밀 문서, 인증 정보에 노출될 수 있고, 인터페이스 콘텐츠나 외부 파일을 통한 프롬프트 인젝션, 코드 행동으로 인한 오류·악성 워크플로의 영향 확대 위험이 남는다. 저자들은 최소 권한, 애플리케이션·디렉터리·네트워크·코드 실행에 대한 세분화된 권한, 되돌릴 수 없는 작업 전 인간 확인, 런타임 정책 검사, 샌드박스 실행, 감사 로그, 사후 검증, 스크린샷·궤적·도구 출력의 데이터 최소화와 정제, 사용자의 권한 정의·철회, 민감 애플리케이션 기본 차단을 요구한다. 이 격리 실험이 배포 시점의 위험을 해결하지는 않는다고 명시한다.