MintAct는UI그라운딩·모바일·데스크톱·웹내비·툴사용을통합한2B~8BVLM이다

무엇인가

이 논문이 푸는 문제는 디지털 기기를 픽셀에서 직접 조작하는 비전-언어 에이전트를 하나로 묶는 일이다. 실제 기기에서 쓸모가 있으려면 에이전트는 지시를 화면상의 대상에 그라운딩하고, 모바일·데스크톱·웹 인터페이스에서 다단계 작업을 수행하고, 화면 밖 기능은 외부 도구를 호출해 도달해야 한다. 그런데 현재 이 능력들은 UI 그라운딩, 모바일 내비게이션, 데스크톱 제어, 웹 내비게이션, 비주얼 도구 사용으로 조각나 각각 별도로 만들어지고 벤치마크된다. 도메인마다 전문가를 따로 유지하는 것은 서빙과 확장 비용이 크고, 특히 온디바이스에 맞는 소형 크기에서는 비현실적이다. 통합이 어려운 이유는 모델링만이 아니다. 도메인마다 관측·행동 공간, 네이티브 상호작용, 데이터 소스, 실행 환경이 다르고, 행동 집합을 단순히 합치거나 데이터를 섞으면 도메인 간 간섭이 생겨 도메인별 품질이 깎인다. 게다가 온라인 강화학습은 느리고 불안정한 이기종 백엔드에 의존하며 긴 멀티모달 궤적을 만들어내는데, 비동기 실행에서는 실제 학습 분포가 가장 빠른 도메인 쪽으로 쏠린다.

어떻게 동작하나

MintAct는 2B, 4B, 8B 세 규모에서 단일 가중치로 세 능력을 모두 수행한다. 이를 가능하게 하는 설계는 세 가지다. 첫째, 공유 관측·그라운딩 공간으로, 모든 UI 도메인에서 원시 스크린샷만 쓰고 DOM이나 접근성 트리, 플랫폼별 API 없이 픽셀 좌표로 행동을 지정하며 좌표를 999×999로 정규화해 모바일·데스크톱·웹 사이에 지각과 그라운딩이 그대로 전이되게 한다. 둘째, 프롬프트 조건부 행동 집합으로, 도메인별 행동 집합을 하나로 합치는 대신 도메인별 시스템 프롬프트 c를 통해 노출하고 추론 시 대상 도메인의 프롬프트로 조건화해 해당 행동 집합에서 행동을 내도록 유도한다. 셋째, 균형 잡힌 교차 도메인 혼합으로, 지도학습과 강화학습 전 과정에서 도메인 분포를 명시적으로 균형 있게 유지해 한 도메인이 다른 도메인을 잠식하지 않게 한다. 학습은 여러 단계를 거친다. 먼저 고해상도 단일 스텝 SFT로 그라운딩을 포함한 기본 UI 능력을 끌어올리고, 다음으로 전 도메인에서 생성한 궤적으로 저해상도 다단계 SFT를 수행해 다단계 상호작용을 익힌다. 이어 도메인별 RL 전문가를 각각 학습한 뒤 rejection sampling을 쓰는 RFT 단계로 단일 모델에 증류하고, 마지막으로 에이전트 비동기 RL로 정책을 공동 최적화하며 모델이 여러 환경과 직접 상호작용하고 자기 행동의 결과로부터 배우게 한다.

무엇과 다른가

환경과 데이터 인프라도 논문의 핵심 주장이다. 환경 파이프라인은 GPU 서버와 분리되어 HTTP 요청으로 통신하며, 데스크톱 환경은 OSWorld 기반 Docker 컨테이너를 Linux 클러스터에 배치하고 인스턴스당 10 CPU 코어와 40GB 메모리를 할당해 RL 중 200개 이상을 동시에 호스팅한다. 인스턴스 하나가 죽어도 나머지가 롤아웃을 계속 생성하므로 결함 허용성이 올라간다. 모바일은 AndroidWorld 에뮬레이터를 같은 방식으로 100개 이상 동시 실행한다. 웹은 Weblica-Cache와 Weblica-Synth를 쓰는데, 전자는 Playwright로 실제 브라우징 세션의 HTTP 트래픽을 기록한 뒤 규칙 기반 파라미터 정규화로 타임스탬프나 세션 ID 같은 휘발성 토큰을 제거해 완전한 네트워크 격리 아래 결정적 오프라인 리플레이를 보장하고, 후자는 자율 코딩 에이전트가 프레임워크 없는 HTML·CSS·JavaScript 사이트를 생성한다. 비주얼 도구 사용은 MM-ToolSandBox를 기반으로 하며 16개 애플리케이션 도메인에 걸친 500개 이상의 도구를 제공하고, 전체 도구 목록을 매 프롬프트에 넣는 대신 search_tool로 과제 관련 도구를 필요할 때 검색하고 coding_tool로 코드 기반 연산을 처리한다. 데이터 수집도 정교하다. 데스크톱은 소수의 사람 설계 시드 과제에서 출발해 EvoCUA-32B로 롤아웃을 만들고 그 롤아웃을 강한 VLM에 먹여 새 과제를 제안받는 과정을 반복하며, VLM-as-judge로 실패 롤아웃을 걸러낸다. RL용으로는 과제당 8개 궤적을 뽑아 성공과 실패가 섞이고 성공률이 50% 근처인 과제를 선호해 약 3k개의 OSWorld 과제를 확보한다. 모바일도 같은 방식으로 약 3k개 AndroidWorld 과제를 쓰되, 교사 모델의 사고 흔적이 빈약해 정답 행동과 그때까지의 롤아웃을 주고 frontier VLM이 사고 흔적을 다시 라벨링하는 오프라인 패스를 추가한다. 웹 SFT는 InstaV3의 수십만 도메인에서 질의를 샘플링해 Qwen3-VL-32B-Instruct로 롤아웃을 만들고 검증을 통과한 약 51.7k 궤적만 남기며, 웹 RL은 Weblica-Synth로 10k 과제를 구성한다. 비주얼 도구 사용은 COYO와 Aria UI에서 10만 이미지를 가져와 시나리오를 생성하고 RL용으로 약 800개 시나리오를 고른다. 비동기 RL 프레임워크는 학습 분포를 생산이 아니라 소비 지점에서 통제한다. 생산자가 궤적 그룹에 도메인 태그를 붙여 하나의 공유 큐에 넣으면, 트레이너가 도메인별 정수 쿼터 q_d(Σq_d = B)로 큐를 배출하며 해당 도메인이 쿼터를 넘지 않을 때만 그룹을 받는다. 주 실행은 B=64에 두 도메인 각각 q_d=32, 그룹 크기 8이다. 여기에 쿼터 정규화 백프레셔를 걸어 각 워커가 도메인별 누적 승인 그룹 수 c_d로 r_d = c_d/q_d를 계산하고, 자기 도메인이 가장 느린 도메인을 한 학습 배치 크기 이상 앞서면 멈췄다가 따라잡히면 재개한다. 또 GRPO 그룹 중 롤아웃이 전부 정답이거나 전부 오답이라 어드밴티지가 사라지는 그룹은 버리기 때문에, 도메인 기여도는 처리량만이 아니라 처리량에 혼합 결과 그룹을 만들어내는 비율을 곱한 값에 달려 있다. 한 도메인의 그룹이 계속 버려져 쿼터에 도달하지 못하면 트레이너가 무한 대기하므로, 일정 시간이 지나면 도메인별 상한을 풀고 생산적인 도메인이 배치를 채우는 폴백을 둔다.

어떻게 쓰나

실험은 그라운딩에 MMBench-GUI, ScreenSpot-v2, UI-Vision, OSWorld-G를, 모바일 내비게이션에 AndroidControl과 AndroidWorld를, 데스크톱에 OSWorld-Verified를, 웹에 Weblica와 Online-Mind2Web을, 비주얼 도구 사용에 MM-ToolSandBox를 사용하고 각 벤치마크의 공식 지표를 보고한다. 온라인 내비게이션 최대 스텝은 30, 비주얼 도구 사용은 100이다. 8B 기준으로 Qwen3-VL-8B 초기화 대비 AndroidWorld가 47.6에서 67.0으로, OSWorld-Verified가 33.9에서 48.9로, Weblica가 55.5에서 74.7로, MM-ToolSandBox가 3.1에서 24.5로 올랐고 2B와 4B에서도 비슷한 폭의 향상이 나타난다. 크기가 비슷한 공개 모델과 비교하면 MintAct-8B는 OSWorld-Verified 48.9, Weblica 74.7, UI-Vision 56.6, OS-World-G 64.5로 최고 점수를 내고 AndroidWorld 67.0, Online-Mind2Web 39.1로 경쟁력 있는 수준을 유지한다. 핵심 주장은 하나의 모델이 그라운딩, 모바일·데스크톱·웹 내비게이션, 비주얼 도구 사용에서 동시에 크기가 맞는 전문가 기준선과 대등하거나 앞선다는 것이다.

전제와 한계

절제 실험은 각 단계가 실제로 기여한다는 것을 보여준다. 1단계만 쓰면 MMBench-GUI 84.1, UI-Vision 59.3으로 그라운딩은 강하지만 OSWorld-Verified 9.4, Weblica 15.6으로 다단계 상호작용이 약하다. 2단계만 쓰면 OSWorld-Verified 41.5, Weblica 59.1로 내비게이션이 살아나지만 UI-Vision이 25.0으로 떨어진다. 두 단계를 합치면 UI-Vision 56.9를 유지하면서 내비게이션과 도구 사용 성능을 함께 얻는다. RFT는 도메인별 성능을 유지하는 데 효과적이어서, 모바일에서는 RFT 모델이 모바일 RL 전문가를 넘어선다(AndroidWorld 68.1 대 67.8). 2B에서는 AndroidWorld가 44.8에서 55.7로, Weblica가 44.4에서 55.6으로, MM-ToolSandBox가 2.7에서 4.3으로 오르고, 4B에서는 각각 53.5에서 62.4, 57.1에서 65.8, 14.4에서 18.1로 오른다. 모바일과 데스크톱만 공동 RL로 학습한 모델은 평균적으로 단일 도메인 RL 전문가를 능가하고, 웹 데이터를 전혀 쓰지 않았는데도 웹으로 전이된다(Weblica 57.5에서 60.8, Online-Mind2Web 30.0에서 32.8). 다만 가장 먼 도메인인 비주얼 도구 사용은 공동 학습 대상이 아니어서 SFT 수준에 머물며, 가까운 도메인 사이의 전이가 더 쉽다는 것을 시사한다. RFT 이후 공동 RL을 적용하면 8B에서 OSWorld-Verified가 43.1에서 48.9로, Weblica가 72.8에서 74.7로, Online-Mind2Web이 36.3에서 39.1로 오르고 AndroidWorld는 1.1포인트 내려간다. 4B는 OSWorld-Verified 41.0에서 44.8, Online-Mind2Web 27.9에서 31.1이고 2B에서 효과가 가장 커서 31.6에서 36.1, 19.7에서 25.3으로 오른다. 합성 환경은 실제 데이터 노출이 부족한 도메인에서 값을 한다. 합성 모바일은 26.9에서 SFT 후 43.1, 합성 RL 후 51.9로, 합성 데스크톱은 39.3에서 50.0, 66.4로 오른다. 실제 AndroidWorld나 OSWorld 에뮬레이터를 전혀 쓰지 않고 합성 환경만으로 학습한 베이스 모델도 AndroidWorld가 47.6에서 60.3으로, OSWorld-Verified가 33.9에서 38.6으로 개선된다. 실제 iOS 데이터 없이 학습한 MintAct-SFT는 iOSWorld에서 12.8로 베이스 모델의 2.3을 크게 앞서고, 합성 환경만으로 18.8, 합성 RL을 더하면 22.3이 된다. 반대로 도메인 내 실제 데이터가 있으면 합성 환경의 이점은 사라진다. 실제 도메인 RL이 합성 RL보다 큰 이득을 준다(AndroidWorld 66.7 대 59.8, OSWorld 48.3 대 39.4).

한국 개발자 입장에서 이 논문의 실무적 의미는 온디바이스 지향 크기에서 여러 UI 도메인을 하나의 모델로 커버하려는 구체적 레시피와 인프라 청사진을 얻는다는 점이다. 도메인별 행동 집합을 합치지 않고 시스템 프롬프트로 분기하는 구조이므로, 배포 시 도메인 프롬프트 관리와 프롬프트별 행동 파서가 품질을 좌우한다는 것을 먼저 확인해야 한다. 환경 파이프라인이 HTTP로 GPU 서버와 분리되어 있어 자체 백엔드나 사내 시뮬레이터를 붙이기 쉬운 것도 참고할 만하다. RL 데이터를 성공률 50% 근처 과제 중심으로 고르고, 전부 정답이거나 전부 오답인 그룹을 버리며, 도메인별 쿼터와 백프레셔로 학습 분포를 통제하는 방식은 자체 에이전트 RL 파이프라인을 만들 때 그대로 차용할 수 있는 패턴이다. 다만 컨텍스트 관리가 순진하다는 점은 실무에서 바로 부딪히는 제약이다. 학습 중 들어오는 모든 스크린샷을 컨텍스트에 덧붙이는 방식이라 궤적이 길어질수록 컨텍스트와 메모리가 빠르게 커진다. 도구 호출도 동적 레지스트리 때문에 새 도구가 실행 중 도입되면 프롬프트 프리픽스가 바뀌어 프리픽스 캐싱 효율이 떨어지고, 이를 궤적 분할로 근사하면서 궤적 수준 보상을 세그먼트에 할당하고 마지막 세그먼트로 학습하는 조악한 크레딧 할당에 의존한다.

저자들이 명시한 한계는 다음과 같다. 공동 RL은 모바일과 데스크톱에만 적용했고, 모바일·데스크톱·웹·비주얼 도구 사용을 모두 포함하도록 확장하는 것은 여러 이기종 환경을 학습 내내 동시에 유지해야 해 자원 집약적이라 미래 과제로 남긴다. 컨텍스트 관리도 열린 문제로, 오래된 관측을 요약하거나 가지치는 정교한 관리가 장기 작업 확장에 필요하다고 본다. 내비게이션과 도구 사용의 통합 역시 현재는 비주얼 도구 사용을 거의 별개 능력으로 취급하며, 도구가 직접 조작보다 효과적일 때만 자동으로 호출하는 단일 정책의 온디맨드 전환은 달성하지 못했다. 온디바이스와 서버 측 모델의 협업, 즉 소형 온디바이스 모델이 단순하고 민감한 작업을 로컬에서 처리하고 역량을 넘는 작업만 서버로 넘기는 구조도 제안된 방향일 뿐 검증되지 않았다. 함수 호출 공식화에서는 동적 도구 레지스트리를 다루는 더 우아한 인터페이스와 원리적인 세그먼트 수준 크레딧 할당이 남은 과제라고 밝힌다.