소프트웨어를 한 번도 설치하지 않고, 그 소프트웨어를 다루는 AI를 가르칠 수 있을까? AutoGUIWorld는 "그렇다"고 답한다.
핵심은 이미지 생성 모델을 색다르게 쓴 데 있다. 보통 이미지 생성 모델은 그림을 그리는 데 쓴다. 이 연구는 그것을 "어떤 행동을 하면 화면이 어떻게 바뀌는지 그려내는 도구"로 돌려 썼다. 여기에 작업 순서를 짜는 설계자(플래너)를 붙여, 실제 프로그램을 돌리지 않고도 '화면을 보고 클릭·입력하는' 연습 기록을 통째로 만들어낸다. 이렇게 합성한 가짜 연습 데이터로 AI를 추가 훈련시키자, 실제 컴퓨터 작업과 과학 작업 성적이 눈에 띄게 올랐다.
GUI 에이전트는 사람처럼 화면(스크린샷)을 보고 마우스를 움직이고 키보드를 두드려 소프트웨어 작업을 자동화하는 AI다. 그런데 버튼 위치를 외우는 것만으로는 부족하다. '이 버튼을 누르면 화면이 어떻게 바뀌는가', '무엇이 남고 무엇이 사라지는가', '앞 단계가 뒤 단계를 어떻게 제약하는가' 같은 감각을 익혀야 한다. 이 감각은 성공한 작업 기록 — 스크린샷에서 행동으로, 다시 바뀐 스크린샷으로 이어지는 '궤적' — 을 대량으로 보면서 길러진다.
문제는 이 궤적을 '지금 돌아가는 소프트웨어'에서만 모을 수 있다는 점이다. 에이전트가 겪을 수 있는 화면 상태와 작업 흐름은 깔려 있는 소프트웨어가 무엇이냐에 전적으로 묶인다. 커버리지를 넓히려면 결국 새 소프트웨어를 깔고, 설정하고, 작업 환경을 준비하고, 매번 똑같이 재현되도록 유지해야 한다. CAD나 과학 계산, 전자설계(EDA) 같은 전문 소프트웨어일수록 설치 의존성과 실행 요구가 제각각이고 라이선스·계정 제약까지 따라붙는다. 환경 하나하나를 만들고 유지하는 비용, 그 자체가 학습의 진짜 병목이다. AutoGUIWorld의 출발점은 이 비용을 아예 건너뛰자는 것이다.
이 논문의 영리함은 데이터 만들기를 두 층으로 쪼갠 데 있다. '무슨 일이 일어나야 하는가'(계획)와 '그래서 화면이 어떻게 보여야 하는가'(그림)를 분리했다. 영화에 비유하면, 각본을 든 감독이 장면 전개를 정하고, 촬영팀이 그 장면을 한 프레임씩 찍되 매 프레임이 바로 앞 프레임을 이어받아 찍는 구조다.
표 편집기에서 특정 셀의 글자색을 바꾸는 작업 하나로 흐름을 따라가 보자.
이런 방식으로 네 플랫폼(Ubuntu·Windows·macOS·Chrome)에서 79,266개의 스텝 단위 학습 샘플을 찍어냈다.
여기서 가장 중요한 개념이 '상호작용 충실도'다. 그럴듯해 보이는 화면과, 실제 시스템이 진짜로 만들어낼 화면은 다르다. 서식 대화상자를 띄웠으면 그 뒤의 표는 그대로 보존돼야 하고, B2 한 셀의 색만 바꿨으면 나머지 셀은 건드려지지 않아야 한다. 이미지 생성기가 단순히 보기 좋은 그림을 찍는 게 아니라, 레이아웃·스타일·배경·보이는 내용을 유지한 채 지정된 변화만 반영하는 '행동에 따라 상태를 바꾸는 모델'로 작동해야 한다는 뜻이다. 그래야 생성된 기록이 서로 무관한 스크린샷 더미가 아니라, 앞뒤가 맞는 화면-행동-화면 사슬이 된다.
이 접근의 바탕에는 똑똑한 포기가 하나 있다. 논문은 에이전트가 시스템의 진짜 상태를 다 보지 못하고 일부만 관측한다는 틀, 즉 부분 관측 모델(POMDP)로 이 상황을 설명한다. 쉽게 풀어 보면 안갯속에서 운전하는 사람과 비슷하다. 운전자는 도로 전체의 설계도도, 엔진 내부도 보지 못한 채 눈앞 차선과 표지판만으로 다음 행동을 정해야 한다. 컴퓨터도 마찬가지다. 진짜 상태는 운영체제 속, 앱 속, 파일 시스템, 눈에 안 보이는 내부 값까지 전부인데, 에이전트는 그중 '화면' 한 장만 본다. 이 논문의 핵심은 안개를 걷어내 진짜 상태를 복원하려 애쓰는 대신, '보이는 화면'이 다음 '보이는 화면'으로 어떻게 바뀌는지만 그럴듯하게 그려내는 데 집중했다는 것이다. 덕분에 만든 기록은 한 스텝씩 떼어 학습 데이터로 쓸 수 있고, 학습할 때 생성기를 옆에 둘 필요도 없다.
가장 궁금한 건 이거다. 진짜 소프트웨어를 한 번도 안 돌리고 만든 데이터로, 에이전트가 실제로 일을 더 잘하게 될까?
연구진은 합성 기록으로 한 대규모 언어 모델을 미세조정(이미 만들어진 모델을 특정 작업에 맞게 더 훈련시키는 것)한 뒤 실제 환경에서 돌렸다. 고른 모델은 Qwen3.5-35B-A3B다. 네 개 벤치마크 전부에서 성적이 올랐고, 그중 두 곳에 구체적인 수치를 붙였다. 교차 플랫폼 데스크톱 작업을 재는 OSWorld에서는 평균 과제 점수가 33.0%에서 40.8%로 올랐고, 과학 워크플로를 재는 ScienceBoard에서는 과제 성공률이 14.0%에서 32.2%로 두 배 넘게 뛰었다.
두 수치를 뭉뚱그리면 안 된다. OSWorld는 '평균 과제 점수', ScienceBoard는 '과제 성공률'로 지표 자체가 다르다. "평균 몇 %p 향상" 식으로 합치면 틀린다. 그래도 방향은 분명하다. 실제 소프트웨어 없이 합성한 연습 데이터가, 진짜 데스크톱·과학 과제의 실측 성능을 끌어올렸다.
다만 이 숫자가 증명하지 못하는 것이 있다. 합성된 화면은 '보이는 것'(창 배치, 내용, 스타일)만 담지, 파일 시스템 내용이나 앱 내부, 브라우저 내부 구조 같은 '보이지 않는 상태'는 담지 못한다. 보이는 화면만 모델링하기로 한 설계의 대가다. 그래서 진짜 백엔드가 없고, '클릭이 실제로 송장을 올바르게 등록했는지' 같은 기능적 정답을 확인할 길이 없다. 실행 가능한 환경에 검사 장치(verifier = 결과가 맞는지 검증하는 장치)를 붙이는 방식과 갈리는 지점이 바로 여기다. 그 방식은 정답 여부를 검증할 수 있는 대신 환경을 배포·설정하는 비용을 전부 치러야 하고, AutoGUIWorld는 검증 가능한 정답 일부를 포기하는 대신 넓은 커버리지를 싸게 얻는다. 둘은 경쟁이라기보다 서로를 메우는 관계다.
한 가지 더. 이 파이프라인은 '설계자의 계획이 옳다'는 전제 위에 서 있다. 계획이 틀린 순서를 짜면, 이미지 생성기는 그 틀린 계획마저 매끄럽고 그럴듯하게 그려낸다. 틀렸는데 보기엔 완벽한 기록이 나오는 것이다. 품질 관리가 잘못 그려진 장면은 걸러내지만, 계획 자체의 체계적 오류까지 잡아낸다는 보장은 분명치 않다. 성능 수치 역시 특정 모델 하나에서 나온 결과라, 다른 규모·계열의 모델에서도 같을지는 이 연구만으로 단정하기 어렵다.
성능과 별개로, 연구진은 '합성 데이터가 실제 데이터와 분포상 얼마나 가까운가'도 여러 각도로 쟀다. 결론부터 말하면 꽤 가까웠다. 다만 가깝다는 게 성능을 보장하지는 않는다 — 그래서 앞의 성능 수치와 아래 분포 수치는 따로 봐야 한다.
비교 기준이 된 '진짜' 데이터는 실제 GUI에서 모은 여섯 묶음(ScaleCUA, AgentNet, aria_ui, WebSTAR, Mind2Web, OS-Atlas)이고, 그중 해상도가 합성 데이터에 가장 가까운 ScaleCUA가 주 비교 상대다. 측정에는 네 가지 잣대를 썼다.
약점도 숫자로 드러난다. 가장 처지는 건 Ubuntu다. 같은 내용 영역끼리 맞춰 비교했을 때, 넓은 단색 배경에서 구분 시험 AUC가 0.65로 생성 흔적이 가장 뚜렷했다. 반대로 글자·아이콘 조각은 Ubuntu·Windows에서 AUC 0.44~0.57로 거의 못 구분됐다. 작은 글자와 아이콘은 실제와 구별이 안 되는데, 넓은 배경에서 생성 모델의 티가 남는 셈이다.
온틀의 AI PM이 고객사에서 흔히 만나는 장면이 있다. 어떤 고객이 사내 ERP나 전용 관리자 콘솔의 반복 작업을 자동화해달라고 한다. 그런데 그 콘솔을 다룰 줄 아는 에이전트 학습 데이터는 세상에 없다. 그렇다고 고객사 ERP를 통째로 복제해 샌드박스를 세우는 건 라이선스·개인정보·운영 리스크가 한꺼번에 걸린다. 바로 여기가 앞에서 말한 '환경 비용 병목'이다.
이 연구는 그 병목을 공략할 새 선택지를 준다. 온틀은 이 기술로 고객사 콘솔의 값싼 '디지털 트윈(실물을 본뜬 가상 복제판)'을 만들 수 있다. 실제 콘솔 스크린샷 몇 장에서 출발해 그 화면의 테마·레이아웃·상태를 시드로 뽑고, 그 위에서 말이 되는 작업을 생성하고, 설계자가 클릭·입력 순서를 깔고, 이미지 생성기가 다음 화면을 그리고, 그라운딩이 누를 좌표를 찍는다. 이렇게 모은 합성 기록으로 에이전트를 미리 훈련시키면, 실제 시스템에 손대기 전에 '화면을 읽고 어디를 누를지' 기본기를 상당 부분 길러둘 수 있다. 진짜 시스템 접근과 실제 데이터로의 미세조정은 마지막 남은 간극을 메우는 단계가 된다. 비싼 실환경을 통째로 세우는 대신, 투입 전에 연습시키는 '모의 훈련소'를 싸게 짓는 셈이다.
물론 선은 분명히 그어야 한다. 이 모의 훈련소에는 진짜 백엔드가 없다. 고객의 실제 DB에서 돈이 제대로 이체됐는지, 전표가 올바르게 등록됐는지를 이 안에서는 확인할 수 없다. 보이는 화면이 시스템의 참값은 아니기 때문이다. 그래서 이 기술은 '지각과 조작 기본기'를 미리 올리는 데는 강하지만, 결제·데이터 변경처럼 되돌리기 어려운 실행을 여기에만 맡겨선 안 된다. 기본기는 합성 데이터로 빠르게 끌어올리되, 운영 실행은 실환경 검증과 멱등 설계(같은 작업을 여러 번 눌러도 결과가 한 번 누른 것과 같게 만드는 안전장치)로 받쳐야 한다. 정리하면, 이 연구는 온틀에 '싸고 빠른 모의 훈련소'를 쥐여주지, 실전 승인 게이트를 없애주지는 않는다.
이 글이 참고한 공개 자료 범위에서는 데이터 공개 여부가 확인되지 않습니다. 정확한 사항은 아래 참고자료의 arXiv·HuggingFace 페이지를 확인하세요.
논문에서는 이미지 생성 모델 gpt-image-2를 씁니다. 현재 스크린샷을 밑그림으로 삼아 다음 화면을 그려내는 방식(image-to-image)으로, 역할은 '행동에 따라 화면 상태를 바꾸는 모델'입니다.
화면 한 장에는 스크롤 위치, 떠 있는 대화상자, 입력 중인 글자, 동적으로 바뀌는 페이지 내용 같은 맥락이 다 담기지 않기 때문입니다. 다음 행동을 제대로 고르려면 이전 화면과 행동의 이력에까지 조건을 걸어야 합니다.