MAI-Gym이 GUI 에이전트 평가와 RL 학습을 한 파이프라인으로 묶는다

무엇인가

GUI 에이전트에 온라인 강화학습을 적용하는 일은 수학이나 코딩과 사정이 다르다. 논문은 그 이유를 두 가지로 정리한다. 첫째, GUI 인스턴스는 코드 샌드박스처럼 동시 시도가 공유할 수 없다. 에이전트가 화면 전체를 조작하며 파일과 설정을 바꾸기 때문에, 시도마다 알려진 초기 상태의 별도 폰·PC·브라우저가 필요하고 리셋 전까지 스크린샷 기반 모델 호출이 수십 번 쌓인다. 게다가 플랫폼과 벤치마크마다 구현이 다르면 평가용과 학습용 에이전트가 서로 어긋나, 측정된 성능이 모델이 아니라 하네스에 좌우된다. 둘째, 현실적인 GUI 작업은 여러 앱과 파일에 흩어진 정보에 의존한다. 예컨대 첨부 청구서 합계를 메일로 회신하려면 메일·첨부·청구서 내용이 환경 안에 일관되게 존재해야 하는데, 기존 태스크 합성은 단일 입력 파일이나 앱 전체가 공유하는 샘플 데이터에 기대는 경우가 많아 다양성과 현실성이 제한된다.

어떻게 동작하나

MAI-Gym의 핵심 설계는 하나의 rollout 경로와 하나의 에이전트 하네스다. 평가, 데이터 수집, RL 학습이 관찰 처리·컨텍스트 구성·액션 실행을 그대로 공유하므로 하네스를 한 번 고치면 세 워크로드에 동시에 반영된다. 에이전트는 환경 관리자를 통해서만 환경에 닿는데, 이 관리자는 인스턴스 요청, 관찰, 태스크로의 리셋, 스텝, 평가의 다섯 연산을 노출하고 그 뒤에서 프로비저닝·세션 수명주기·태스크 등록·코드 검증기 또는 VLM 판정·궤적 저장·대시보드 상태 보고를 처리한다. 어댑터가 각 환경의 네이티브 API로 번역하며 어댑터 안에는 RL 관련 코드가 없다. 확장 지점은 하네스 추가, 태스크 추가, 환경 통합, 환경 커스터마이즈 네 곳이다. 태스크는 x=(E, s0, g, V)로 정의되고, 보상은 이진 기준 b_j의 가중 합으로 부분 점수를 주되 성공 S는 필수 기준의 곱이라 전부 만족해야 1이 된다. 액션 공간은 GUI와 CLI를 함께 쓰며, 모바일·웹은 GUI만 쓴다. 실패한 셸 명령은 에피소드를 끝내지 않고 오류를 피드백으로 돌려준다.

무엇과 다른가

확장성과 효율을 위한 장치도 구체적이다. 모바일은 중첩 가상화가 필요한 표준 안드로이드 에뮬레이터 대신 ReDroid로 각 폰을 호스트 커널 위 컨테이너로 띄우고, 리셋마다 골든 /data 스냅샷과 서비스 상태를 복원한다. 데스크톱은 준비 완료를 너무 일찍 보고하는 VM 문제와 동시 시도 간섭을 막기 위해 엄격한 준비 검사, 중간 실패 컨테이너 복구, 인스턴스별 서비스 포트와 아티팩트 캐시, 앱의 저장 완료 대기를 추가했다. 리셋에 큐잉과 태스크 준비를 포함한 중앙값은 안드로이드 165초, 데스크톱 VM 37초, 브라우저 6초다. 20,000개 인스턴스 병렬 실행을 시험했고, 새 인스턴스 1,000개를 모바일 328.4초, 컴퓨터 88.9초에 띄운다. 비동기 프로비저닝, 초기화된 인스턴스를 대기시키는 웜 풀, 스크린샷을 제어 메시지가 아닌 오브젝트 스토리지로 보내는 설계가 이를 가능하게 한다. 세션 리스, 액션 식별자, 모든 연산의 데드라인, 별도 프로세스 그룹에서 도는 검증기로 실패를 세션 단위에 가두고, 환경 실패를 0 보상과 분리 기록해 인프라 결함이 학습 신호에 섞이지 않게 한다. 멀티턴 추론에서는 최근 k개 스크린샷만 남기는 방식이 매 스텝 프롬프트 시작을 바꿔 KV 캐시 재사용을 깨뜨리는 문제를, K=10·O=2로 겹치는 윈도우 방식으로 바꿔 프리픽스가 K−O 스텝마다 한 번만 변하게 했다. 그 결과 학습 업데이트 시간이 2166.4초에서 810.9초로 줄었다.

어떻게 쓰나

합성 파이프라인은 태스크의 모든 구성 요소를 만든다. 앱 수준에서는 리셋 가능한 백엔드를 가진 mocked app을 코딩 에이전트가 만드는데, 실제 서비스의 클론 7종(12306, 중국건설은행, 디디, 메이투안, 뎬핑, 더우인, 샤오홍슈)과 실제 앱 참조 없이 HTML5 템플릿 위에 결정적 상태 기계로 구현한 신규 앱이 있다. 태스크 수준에서는 페르소나와 시나리오로부터 일관된 세계를 먼저 구축해 여러 앱에 인물·사건·사실이 맞물린 파일과 레코드를 채우고, 그 위에서 앱을 넘나드는 정보 검색·추론·통합을 요구하는 태스크를 생성한다. 성공 기준을 먼저 정한 뒤 코드 검증기를 만들고, 초기·완료·리셋 상태에서 실행해 통과한 검증기만 채택한다. 실패한 궤적을 진단해 모델 약점을 겨냥하는 failure-driven 합성도 지원한다. 진단 자체도 Claude Code나 Codex 같은 코딩 에이전트가 진단 엔드포인트를 질의해 성공·실패 시도를 비교하고 개별 액션, 궤적 전체, 요구 지식 세 층위에서 분석하는 방식으로 자동화했다.

전제와 한계

실험 결과는 다음과 같다. 합성 태스크에 대한 모바일·컴퓨터 단일 joint RL 실행으로 학습한 MAI-Gym-9B는 MobileWorld 78.4%, OSWorld-Verified 76.2%를 기록해 10B 이하 오픈 GUI 에이전트 중 최고 성능을 주장한다. 비교 대상으로 UI-Venus-2-9B는 75.2/70.8, SCALECUA-Qwen3.5-9B는 12.8/68.7, 더 큰 GUI-Owl-1.5-32B는 43.9/56.5다. 도메인별 전문가를 따로 학습해 가중 평균으로 합치는 방식과 비교하면, MobileWorld 최적 병합(50/50)이 76.4%, OSWorld-Verified 최적 병합(30/70)이 74.8%로 joint RL이 두 도메인 모두에서 앞선다. 합성 태스크 수를 500개에서 5,000개로 늘리면 MobileWorld가 69.2%에서 78.4%로, OSWorld-Verified가 69.7%에서 76.2%로 오른다. 12306 클론에서만 RL한 뒤 실제 앱을 물리 폰에서 평가한 52개 쌍대 태스크에서는 클론이 36.5%→73.1%, 실제 앱이 28.8%→48.1%로 19.2%포인트 개선됐다. 신규 앱 252개 태스크로 학습해 62개 홀드아웃을 60스텝 예산으로 한 번씩 평가하면 25.8%→45.2%로 오르고, 예산 소진 시도가 27→5, 평균 궤적 길이가 33.3→16.4 스텝으로 줄었다. GRPO와 SAO 비교에서는 초반 성공률이 비슷했고 SAO가 표시 구간 끝에서 약간 낮았으며, 샘플링 대기는 줄지만 액터 업데이트당 두 번의 크리틱 업데이트 비용이 상쇄해 전체 학습 시간 우위가 뚜렷하지 않았다. 7개 벤치마크를 태스크당 3회 시도로 평가하는 데 약 3시간이 걸린다.

개발자 입장에서 이 논문의 값은 인프라와 태스크를 함께 공개한다는 데 있다. 프레임워크(평가 하네스와 온라인 RL 학습 코드), 합성 스킬, 49개 mocked app과 딸린 태스크, 실행 검증을 통과한 2,000개 태스크(MobileWorld·OSWorld 각 1,000개), 모델 체크포인트를 공개한다. 자체 GUI 에이전트를 만들거나 파인튜닝하는 팀이라면 환경 리셋·병렬 프로비저닝·검증기 작성에 드는 비용을 크게 줄일 수 있고, 특히 평가와 학습이 같은 하네스를 쓰도록 강제하는 구조는 벤치마크 점수와 실제 배포 성능의 괴리를 줄이는 데 직접 쓸모가 있다. 다만 도입 전에 확인할 것은 자신의 타깃 앱이 10개 지원 벤치마크나 49개 mocked app에 들어가는지, 그리고 클론-실제 격차가 자기 도메인에서도 감수 가능한 수준인지다.

저자들이 밝힌 한계와 전제도 분명하다. 진단-합성-재학습 루프는 반복 실행을 지원하지만 이 논문에서 반복 라운드는 아직 평가하지 않았다. 클론 학습의 실제 앱 전이는 완전하지 않아 클론과 실제 앱의 격차가 7.7%포인트에서 25.0%포인트로 오히려 벌어졌고, 클론에서의 향상이 실제 앱 성능을 온전히 예측하지 못한다. SAO 비교 역시 시험한 설정 범위 안에서의 결론이다. 또한 성능 수치는 합성 태스크와 학습 환경 밖 5개 벤치마크에서의 SFT 워밍업 대비 개선을 포함해 보고되지만, 학습에 쓰이지 않은 벤치마크라도 벤치마크 자체가 플랫폼별로 고정돼 있다는 전제 위에 서 있다.