컴퓨터를 사람처럼 조작하는 AI를 '컴퓨터 사용 에이전트(CUA)'라고 부른다. 이런 AI를 가르치려면 실제로 눌러볼 수 있는 소프트웨어가 대량으로 필요한데, 그 소프트웨어를 구하는 일이 늘 병목이었다. SoftwareGym은 발상을 뒤집는다. 훈련에 쓸 소프트웨어 자체를 자동으로 찍어낸다. 이렇게 합성한 환경에서 배운 조작 능력만으로 모델 하나가 실제 앱 벤치마크 OSWorld의 성공률을 41.39%에서 56.97%로 끌어올렸다. 여기서 성공률은 Pass@3, 즉 세 번 시도해 한 번 이상 성공한 과제의 비율이다. OSWorld에 들어 있는 앱도, 과제도, 행동 기록도 학습에 단 하나 쓰지 않고 거둔 결과다.
컴퓨터 사용 에이전트를 가르치는 일은 운전 교습과 닮았다. 교과서만 읽어서는 운전을 못 배운다. 실제 도로에 나가 핸들을 돌리고 브레이크를 밟아봐야 몸에 밴다. CUA도 마찬가지다. 실행되는 소프트웨어 안에서 버튼을 누르고 메뉴를 열고 파일을 저장해 본 행동 기록 — 이 분야에서는 '궤적(trajectory)'이라 부른다 — 이 쌓여야 실력이 는다. 문제는 이 '도로'를 확보하는 일이 병목이라는 데 있다.
지금까지 길은 크게 둘이었고, 둘 다 한계가 뚜렷했다.
첫째, 이미 있는 데스크톱·모바일 앱을 그대로 훈련장으로 끌어오는 길이다. GIMP, VLC, Thunderbird 같은 진짜 프로그램이라 상태도 현실적이고 워크플로도 복잡하다. 그러나 앱 하나를 '언제 돌려도 같게 재현되는 훈련 환경'으로 통합하는 비용이 크다. 그래서 다룰 수 있는 앱 수가 적고, 같은 앱으로 반복 학습하다 보면 '그 앱에만 통하는 요령'을 외워버리는 과적합 위험이 남는다. OSWorld, Windows Agent Arena, AndroidWorld가 이 계열이다.
둘째, 브라우저 위에 소프트웨어 환경을 지어 올리는 길이다. 배포가 쉽고 상태를 통제하기 편하다. 대신 전부 브라우저·HTML·DOM이라는 같은 바닥 위에 올라가기 때문에, 네이티브 앱 특유의 구조나 여러 단계에 걸쳐 상태가 이어지는 깊은 워크플로를 담기 어렵다. 상호작용이 얕아진다는 뜻이다.
저자들은 좋은 CUA 훈련 환경이 세 가지를 동시에 갖춰야 한다고 본다. 화면과 조작 방식이 충분히 다양할 것(다양성), 복잡하면서도 끝까지 작동하는 궤적을 뽑아낼 것(신뢰성), 적은 손품으로 환경을 계속 늘릴 것(확장성)이다. 기존 두 길은 이 셋을 한꺼번에 채우지 못했다. 다양성을 풀어놓으면 같은 범주 안에서 레이아웃이 비슷하게 수렴하고, 신뢰성을 보장하려면 명세한 기능이 전체 화면 흐름에서 끝까지 작동하는지 일일이 확인해야 하는데, 이를 대규모로 하면 사람 손으로는 감당 못 할 검증 부담이 쌓인다.
SoftwareGym의 선택은 '빌려오기'도 '브라우저로 흉내 내기'도 아니다. 검증 루프를 안에 넣은 채 네이티브 데스크톱 앱을 새로 합성해, 소프트웨어 분포 자체를 넓히는 쪽이다.
SoftwareGym은 여러 AI 에이전트가 역할을 나눠 맡는 자동 파이프라인이다. 소프트웨어를 설계하고, 구현하고, 직접 눌러보며 검증한다. 합성은 세 단계로 흐른다. 한 가지 기능을 따라가며 보자. '파일 이름을 바꾸고 앱을 닫았다 다시 열어도 그 이름이 그대로 남아 있다'는, 어느 앱에나 있는 평범한 기능이다.
1단계 설계. 소프트웨어 종류와 참고 자료만 주면, 파이프라인이 상세한 기능 명세와 여러 가지 UI 설계를 뽑아낸다. 우리 예시 기능이라면 여기서 '사용자가 이름을 고치는 지점은 어디인지, 어떤 동작을 하면 이름이 바뀌는지, 바뀐 뒤 화면에 무엇이 보여야 하는지, 그리고 다시 열었을 때 이름이 유지됐는지를 무엇으로 확인할지'까지 미리 글로 못 박는다. 이 '확인 방법'을 설계 단계에서 정해두는 것이 핵심이다. 기능 명세가 곧 테스트 기준이 되므로, 만드는 목표와 채점하는 목표가 처음부터 같아진다. 같은 설계 단계에서 다양성도 강제한다. 같은 '이름 바꾸기' 기능이라도 메뉴 위치와 화면 구조를 서로 다르게 바꾼 여러 변형을 만들어, 모델이 한 가지 생김새에만 익숙해지지 않게 한다.
2단계 구현과 평가. 받은 설계대로 앱을 실제로 구현한다. 그런데 코드가 그럴듯하다고 눌렀을 때 정말 작동한다는 보장은 없다. 그래서 평가 단계가 '실행 중인 앱'을 따로 테스트한다. 우리 예시라면, 테스트 담당 에이전트가 앱을 띄워 파일 이름을 실제로 바꾸고, 앱을 닫았다 다시 연 뒤, 이름이 남아 있는지를 화면으로 확인한다. 통과하지 못하면 어디서 막혔는지 기록해 구현 단계로 돌려보내 고치게 하고, 모든 케이스를 통과하거나 정해진 버전 예산을 소진할 때까지 이 수리 루프를 돈다.
3단계 과제 합성. 마지막으로 이 앱에서 에이전트가 풀 과제를 만든다. 이때 '증거 게이트'가 작동한다. 앞 단계에서 실제로 눌러 작동이 확인된 기능만 과제 재료로 쓴다. 테스트를 못 거쳤거나 실패한 기능은 과제에서 빠진다. 걸러낸 기능을 난이도별로 묶어, 쉬운 과제는 목표 하나로, 어려운 과제는 앞 단계 결과가 다음 단계의 출발점이 되는 다단계 작업으로 구성한다. 사용자에게 보여줄 때는 좌표나 조작 경로, 내부 식별자 같은 정답 힌트를 숨긴 자연스러운 요청 문장으로 바꾼다.
🔧 구현 상자 — 안을 들여다보면 - 설계: FunctionDesigner가 기능을 네 걸음(성숙한 제품의 기능 기준선 → 다중 조건 검색·일괄 작업·히스토리·설정 유지·입력 검증 같은 전문 기능 추가 → 모듈 간 상태·의존·실패 복구를 잇는 워크플로 → '구현·평가 계약'으로 명세화)으로 확장한다. 계약에는 사용자 진입점, 사용자 동작, 기대 상태 변화, 눈에 보이는 GUI 반응, 합격 체크포인트가 담긴다. - 다양성 장치: StyleDesigner가 같은 기능을 제품 포지션·정보 구조·상호작용·시각 정체성이 다른 여러 스타일로 재현한다. 변형끼리 최소 두 개의 레이아웃 차원에서 달라야 하고, 각 설계를 창·영역·패널·컨트롤의 레이아웃 트리로 바꿔 트리 간 편집 거리(tree-edit distance)로 유사도를 잰다. 최소 거리가 임계값 아래면 가장 안 구별되는 설계를 다시 생성한다. IconDesigner는 아이콘이 색만 다른 게 아니라 구조적으로 다르도록 제약한다. UI 기술은 Avalonia이며, 생성된 XAML을 전부 컴파일해 실행 가능성을 확인한다. - 구현·평가: Coder가 Avalonia 앱을 구현하고, DevCoder가 기능 매뉴얼과 대조해 감사·보완한다(여기까지 소스 수준 검증). EvalTaskGenerateAgent가 테스트 케이스를 만들고 GUIAgent가 마우스·키보드로 실행하며 궤적·체크포인트 증거·최종 상태·실패 위치·수리 제안을 남긴다. 매 평가 라운드 뒤 구현물과 UI 설계도 사이의 시각 충실도 점수를 계산해, 임계값 아래로 떨어진 부분을 집어 수리한다.
여기서 세 가지 층위를 구분해두면 뒤에 나올 숫자를 오해하지 않는다.
무엇으로 학습했나. 베이스 모델은 Qwen3.5-9B다. 여기서 9B는 매개변수 90억 개 규모라는 뜻으로, 요즘 기준으로는 작은 축이다. 여기에 SoftwareGym 앱에서 모은 궤적만으로 멀티모달 SFT(지도 미세조정)를 돌렸다. OSWorld의 앱·과제·궤적은 한 톨도 쓰지 않았다.
어디에서 평가했나. 두 벤치마크를 썼다. 하나는 OSWorld로, Chrome·GIMP·Calc·Impress·Writer·Thunderbird·VLC·VS Code 8개 도메인 244개 과제다. 다른 하나는 저자들이 직접 만든 SoftwareGym-Bench로, 12개 범주에서 범주당 앱 하나, 앱당 수동 검증 과제 10개씩 총 120개 과제다.
두 평가가 각각 무엇을 보여주나. 둘은 재는 것이 다르다. OSWorld는 '학습에 쓰지 않은 실제 앱으로의 전이'를, 같은 12개 범주 안에서 겨루는 SoftwareGym-Bench는 '배운 범주 안에서의 실력(도메인 내)'을 본다. 여기서 한 가지 오해를 짚어둘 필요가 있다. OSWorld가 학습 범주와 '범주 자체가 겹치지 않는' 벤치마크인 것은 아니다. 논문 §4.2에 따르면 합성 앱 중 121개가 OSWorld와 대응하는 8개 범주에 속한다. 전이가 성립한다는 말은 소프트웨어 범주가 안 겹친다는 뜻이 아니라, 학습에 한 번도 쓰지 않은 실제 앱으로 조작 능력이 옮겨간다는 뜻이다. 그래서 두 점수를 더해 하나의 성과처럼 읽으면 안 된다. 특히 SoftwareGym-Bench에는 함정을 일부러 심었다. 과제마다 건드리면 안 되는 보호 객체와 헷갈리게 하는 교란 요소를 넣어, 정해진 순서를 기계적으로 밟는 게 아니라 무엇을 고치고 무엇을 무시하고 무엇을 지킬지 판단하게 만든다. 단순 조작 재현이 아니라 상태를 읽고 분별하는 능력을 재는 것이다.
결과. OSWorld에서 이 9B 모델은 전 도메인에서 베이스보다 나아졌고, 전체 Pass@3가 41.39%에서 56.97%로 15.58포인트 올랐다. OSWorld의 어떤 것도 학습에 쓰지 않았으니, 합성 환경에서 익힌 조작 능력이 진짜 앱으로 옮겨갔다는 직접 증거다. 같은 표(Table 1)에서 이 모델은 자신보다 훨씬 큰 오픈 가중치 베이스라인들과 견줄 수준까지 올라선다.
SoftwareGym-Bench(Table 2)에서는 같은 9B 모델이 25.8%에서 40.0%로 14.2포인트 올랐다. Qwen3.7-Plus를 넘고, 상당히 큰 전문 CUA 여럿보다 앞선다. 다만 GPT-5.5(73.3%)나 Gemini 3.1 Pro(70.8%) 같은 대형 파운데이션 에이전트와는 아직 큰 차이가 있다. 따라서 이 결과는 'SOTA를 이겼다'가 아니라, 작은 모델이 합성 환경 학습만으로 자기 체급 위의 모델들과 겹치는 구간을 만들었다는 쪽으로 읽어야 한다.
합성의 규모와 신뢰성도 수치로 뒷받침된다. 182개 앱의 평균 GUI 과제 통과율은 91.5%다. Figure 4 기준으로 8개 정렬 범주의 121개 앱에서 GUI 증거가 49개 주요 모듈 전부와 구체적 네이티브 기능의 78.8%를 덮는다. 생성된 소프트웨어가 겉만 번지르르한 껍데기가 아니라 실제로 눌리는 기능으로 차 있다는 뜻이다.
📎 재현용 정보. 합성에는 GPT-5.5를 얹은 Codex CLI 에이전트가 설계·구현·평가 케이스 생성을 맡았고, 각 앱은 최대 3개 버전까지 다듬었다(모든 케이스 통과 시 조기 종료). 생성된 앱의 GUI 평가는 Seed 2.1 Pro가 Ubuntu 22.04.3 가상머신에서 케이스당 최대 50스텝으로 수행했다. 최종 모델 평가 조건은 온도 1, 상호작용 예산 100스텝, 과제마다 독립 롤아웃 3회다. 설계·구현 모델과 평가 모델을 분리한 것은 만든 쪽이 자기 결과를 채점하는 편향을 줄이기 위해서다.
무엇이 전이되는가 — 가설. 저자들은 '전이 가능한 GUI 상호작용'을 배운다고 결론짓는다. 무엇이 옮겨가는지를 구체적인 능력의 가설로 적어보면 이렇다. ① 낯선 화면에서 원하는 기능을 찾아내는 능력, ② 여러 작업에 걸쳐 앱의 상태가 어떻게 바뀌었는지 추적하는 능력, ③ 저장하거나 다시 실행한 뒤 결과가 제대로 남았는지 확인하는 능력. 이 셋은 특정 앱의 절차가 아니라 앱을 가로질러 통하는 능력이므로, OSWorld로의 전이를 설명할 수 있다.
남은 질문 — 무엇이 성과를 만들었나. 이 전이가 레이아웃 다양성 덕인지, 검증 품질 덕인지, 단순히 학습량 덕인지는 아직 가려지지 않았다. 세 요인을 하나씩 떼어 비교하는 실험이 있어야 '무엇이 효과의 원천인지'를 말할 수 있다.
남은 질문 — 현실의 지저분함. SoftwareGym은 설계 계약과 체크포인트로 깔끔하게 검증되는 소프트웨어를 만든다. 그 깔끔함이 강점이자 약점일 수 있다. 실제 업무 소프트웨어는 느린 네트워크, 깨진 상태, 모호한 에러 메시지, 레거시 UI의 비일관성으로 가득하다. 그렇다면 검증할 지점도 좁혀진다. 네트워크 지연이 끼어든 상황, 조작이 한 번 실패한 뒤 복구해야 하는 상황에서 이 모델이 버티는지를 따로 평가해봐야 한다.
설계상의 제약. 합성 대상은 Avalonia 기반 독립 데스크톱 애플리케이션이다. 브라우저 접근의 얕은 상호작용을 피하려는 선택이지만, 반대로 생성 가능한 소프트웨어가 이 기술 스택과 데스크톱 패러다임에 묶인다. 웹 전용 워크플로나 모바일 특유의 제스처가 이 파이프라인으로 자연히 커버되는지는 발췌 범위에서 확인되지 않는다.
상위 모델 의존. 합성에 GPT-5.5와 Seed 2.1 Pro 같은 상위 모델을 설계·평가자로 동원한다. 즉 더 강한 모델의 판단을 증류해 작은 모델을 키우는 형태에 가깝다. 이 방식이 평가자 모델 자체의 성능 상한을 넘을 수 있는지, 평가자가 보지 못하는 실패 유형이 데이터에 그대로 남는지는 따져볼 지점이다. 다만 설계·구현·평가 주체를 나눠 자기 채점 편향을 줄인 설계가 이 우려를 일부 덜어준다.
온틀(ONTLE)은 소기업과 1인 창업가가 사람을 더 뽑기 어려운 반복 업무를 덜도록 'AI PM'을 붙여주는 서비스다. AI PM은 고객사의 업무 도구를 직접 조작해 정해진 반복 업무를 처리하는 에이전트다.
한 장면으로 좁혀보자. 온틀이 어느 소기업에 AI PM을 붙인다. 그 회사는 자체 제작한 재고 관리 어드민을 쓴다. 메뉴 구조도, 버튼 위치도, 저장 흐름도 이 회사만의 것이다. AI PM이 '입고된 신규 품목을 분류하고, 중복 SKU는 건드리지 말고, 월말 재고 리포트를 내보내라' 같은 일을 맡으려면 바로 그 어드민에 손이 익어야 한다. 그런데 이 어드민용 훈련 데이터는 세상에 없다. 고객사 소프트웨어를 그대로 긁어 학습시키는 길은 PII·기밀 문제로 막혀 있다.
SoftwareGym에서 빌릴 원칙은 하나로 좁혀진다. '수정할 데이터와 보존할 데이터를 함께 평가한다'는 것이다. SoftwareGym-Bench가 보호 객체와 교란 요소로 '건드릴 것과 지킬 것'을 판단하게 만든 바로 그 설계가, '중복 SKU는 건드리지 마라'는 업무 지시와 정확히 같은 모양이다. 정해진 순서를 기계적으로 밟는 에이전트가 아니라, 상태를 읽고 무엇을 지켜야 할지 아는 에이전트라야 반복 업무 경감이 사고 없이 돌아간다.
적용 가설은 이렇다. 고객사 어드민을 직접 긁어 쓰는 대신, 그 범주와 기능 명세에서 출발해 구조가 다양한 '연습용 어드민들'을 합성해 거기서 먼저 학습시킨다. 그런 다음 실제 고객사 환경에서 재고 수정·중복 보존·리포트 생성이 제대로 되는지 검증한다. 연습장에서 익히고, 실전에서 확인하는 셈이다. 온틀의 자리는 사람을 대체하는 게 아니라 못 뽑는 일손을 메우는 것이고, 합성 환경과 실환경 사이의 간극은 결국 이 마지막 검증으로 메워야 한다.
실행되는 프로그램이다. 각 기능이 진입점부터 상태 저장·화면 반응까지 갖춰 구현되고, 띄워서 눌러보는 GUI 검증을 거친다. 182개 앱의 평균 GUI 과제 통과율이 91.5%라는 점이 그 근거다. 다만 이 수치가 모든 기능의 완벽 작동을 보장한다는 뜻은 아니다.
아니다. OSWorld의 앱·과제·궤적은 학습에 전혀 쓰지 않고 평가에만 썼다. 그래서 41.39%에서 56.97%로의 상승이 '배운 적 없는 앱으로의 전이' 증거로 읽힌다.
아니다. SoftwareGym-Bench에서 9B는 40.0%로 Qwen3.7-Plus와 여러 대형 전문 CUA는 앞섰지만, GPT-5.5(73.3%)·Gemini 3.1 Pro(70.8%)와는 여전히 큰 차이가 있다. 요지는 전면적 우위가 아니라 '작은 모델이 합성 환경 학습만으로 체급 위와 겹치는 구간을 만들었다'는 것이다.
설계·구현·평가·수리를 최소한의 사람 입력으로 자동화하고 배치 단위로 앱을 생성한다. 단, 합성에 GPT-5.5(Codex CLI)와 Seed 2.1 Pro 같은 상위 모델을 동원한다는 점은 비용으로 염두에 둬야 한다. 세부 자원 소요는 논문 Figure 5에서 다룬다.