스마트폰 화면을 보며 음성 지시를 듣고, 동영상의 어느 순간을 기다렸다가 버튼을 누르는 AI를 떠올려 보자. 이렇게 화면을 보고 사람 대신 앱을 눌러 일을 처리하는 AI를 GUI 에이전트라고 한다. 요즘 이 에이전트는 스크린샷·소리·영상·조작 이력이 한꺼번에 흘러드는 환경에서 움직인다. 여러 종류의 정보가 동시에 들어오는 이런 환경을 옴니모달이라 부른다.
지금까지의 관행은 매 단계 이 모든 입력을 한꺼번에 모델에 넣고, 무엇이 중요한지는 모델이 알아서 골라내게 하는 것이었다. FocusGUI는 입력을 빼지 않는다. 대신 기반 모델은 고정한 채, 단계마다 어떤 정보에 먼저 주목할지를 학습하는 작은 보조 부품 하나를 얹는다. 난양공대와 알리바바 그룹 연구진은 기존 관행이 긴 작업에서 왜 무너지는지를 실측으로 보여주고, 이 부품을 제안했다.
다음 행동의 단서가 꼭 지금 화면 안에 있으란 법은 없다. 갑작스러운 알림음이 즉시 맥락을 바꾸기도 하고, 라이브 영상의 전환 순간이 클릭 타이밍을 정하기도 하며, 음성 지시는 화면 변화에 계속 연결돼야 한다. 이 모든 걸 매 단계 균일하게 쏟아붓는 방식이 문제의 뿌리다.
저자들은 이걸 직접 쟀다. Qwen2.5-Omni라는 기반 모델에서 정보의 종류를 하나씩 빼 가며, 정답 행동에 대한 모델의 로그우도(정답을 얼마나 그럴듯하게 여기는지를 나타내는 점수)가 어떻게 변하는지 봤다. 어떤 정보를 뺐을 때 점수가 떨어지면 도움이 됐던 것이고, 오히려 올라가면 방해물이었다는 뜻이다.
| 관찰 | 수치 | 의미 |
|---|---|---|
| 가장 중요한 정보원이 직전 단계와 바뀌는 비율 | 45.3% | 중요한 것은 단계마다 바뀐다 |
| 그런 전환을 한 번 이상 겪은 작업 | 94.0% | 거의 모든 작업이 겪는다 |
| 방해되는 정보가 하나 이상 섞인 단계 | 90.1% | 매 단계 군더더기가 낀다 |
| 눌러야 할 대상이 차지하는 화면 면적(중앙값) | 0.87% | 중요한 것은 극히 일부에 몰려 있다 |
| 한 단계에서 영상이 실제로 바뀌는 양(중앙값) | 7.41% | 영상도 대부분은 노이즈다 |
수치는 한 방향을 가리킨다. '지금 중요한 정보'는 관찰에 붙박인 고정 성질이 아니라 단계마다 달라지고, 한 단계 안에서도 아주 일부에만 몰려 있다. 그런데 모델은 매 단계 아무 안내도 없이, 전체 관찰에서 무엇이 중요한지를 스스로 다시 찾아야 한다.
여기에 구조적 요인이 하나 더 있다. GUI 에이전트는 폐루프, 즉 실행한 행동이 환경을 바꾸고 그 바뀐 환경이 다시 다음 단계의 입력으로 돌아오는 구조다. 한 번의 작은 오독이 그 단계에서 끝나지 않고 시간을 두고 쌓인다. 내비게이션이 한 번 길을 잘못 들면 이후 모든 안내가 틀어진 현재 위치를 기준으로 계산되는 것과 같다. 저자들은 이 누적을 '순차적 산만(Sequential Distraction)'이라 부른다.
가장 직관적인 처방은 입력을 빼는 것이다. 실제로 기존 연구들은 화면에서 관심 영역만 남기고 잘라내는(cropping) 방식을 썼다. 이 '덜 주기'는 두 곳에서 어긋난다. 첫째, 결정적 신호는 소리·영상·기기 상태처럼 화면 자르기가 닿지 못하는 곳에서도 튀어나온다. 둘째, 신호가 화면 안에 있어도, 거칠게 잘라낸 배경에는 정작 정확한 좌표와 입력값을 집는 데 필요한 맥락이 들어 있는 경우가 많다. 모델이 헷갈리는 이유는 너무 많이 줘서가 아니라, 무엇을 먼저 볼지에 대한 안내가 없어서다.
그래서 FocusGUI는 입력을 그대로 두고, 단계마다 어떤 정보에 주목할지의 비중만 조정한다. 슬라이드 전체를 가리는 대신, 레이저 포인터로 지금 봐야 할 지점만 비추는 발표자를 떠올리면 된다. 청중은 슬라이드 전체를 여전히 보지만, 시선은 포인터가 가리키는 곳으로 간다. 이건 입력의 순서를 뒤바꾸는 게 아니라, 매 단계 어떤 정보를 강조할지를 조정하는 일이다.
이 포인터 역할을 하는 것이 어댑터다. 기반 모델은 손대지 않고 겉에 덧붙이는 작은 부품으로, 기반 모델을 고정한 채 100만 개 남짓한 값(파라미터)만 학습한다. 동작은 세 단계다. 앞의 스마트폰 상황, 알림음이 울려 지금 전송 버튼을 눌러야 하는 순간에 대어 보면 이렇다.
기술 독자를 위한 주석 — 1단계 점수는 소프트맥스(여러 점수를 합이 1인 비율로 바꾸는 계산)로 정규화되고, 나눠 둔 채널에는 기반 모델의 통합 은닉 상태(관찰 전체를 한 덩어리로 요약한 내부 표현)까지 포함된다. 3단계의 '더하기'는 원래 신호를 그대로 두고 위에 얹는 잔차 주입이다. 별도 예측 헤드도, 출력 어휘 수정도, 프롬프트에 끼워 넣는 텍스트 힌트도 없다.
학습은 가볍다. 어떤 정보가 중요한지 일일이 라벨을 달지 않는다. 오직 '다음에 할 행동' 하나만 정답으로 준다. 그 정답을 더 잘 맞히도록 보조 부품만 학습하는 과정에서, 무엇을 강조할지·어떻게 요약할지·그 요약을 모델의 표현으로 어떻게 옮길지가 한 목표 아래 함께 배워진다.
그 학습된 우선순위는 작업 한 건(에피소드) 안에서 실제로 재배열된다. 채널이 일곱 개라면 균일 배분은 각각 14.3%다. 그런데 상호작용 상태 채널은 시작 스텝에서 30.9%로 두 배 넘게 받다가 마무리 단계에서 7.7%로 내려간다. 반대로 소리·영상은 각각 13.4%·11.3%에서 18.8%·18.3%로 올라간다. 어떤 고정 가중치도 이 양극단을 동시에 만들 수 없다. 단계마다 다시 가중하는 방식만이 만든다.
이 순서는 '어떤 정보가 중요하다'는 라벨 없이, 오직 행동 정답만으로 나왔다. 사람이 중요도를 지정해 주지 않았는데, 모델이 정답을 더 잘 맞히려 애쓰는 과정에서 '언제 무엇에 먼저 주목할지'가 함께 정해진 것이다.
평가는 OmniGUI 벤치마크에서 이뤄졌다. 29개 앱에 걸친 스마트폰 조작 모음으로, 각 스텝의 스크린샷에 소리·영상·행동 이력이 짝지어져 있다.
지표를 보기 전에 전제 하나를 못 박자. 아래 수치는 모두 오프라인 평가(teacher-forced)다. 정답 이력을 그대로 입력으로 주고, 그다음 한 스텝의 정답 행동을 맞히는지만 본다. 에이전트가 실제 환경에서 자기 예측을 실행하며 궤적을 스스로 만들어 갈 때의 온라인 성공률은 별개 문제이며, 이 수치로는 알 수 없다.
지표는 세 가지다.
주 결과는 아키텍처가 서로 다른 네 기반 모델(Qwen2.5-Omni, VITA-1.5, MiniCPM-o 4.5, Baichuan-Omni-1.5)에서 일관됐다.
| 지표(4개 모델 평균) | 고정 모델 직접 추론 | FocusGUI |
|---|---|---|
| 행동 종류(TM) | 31.0% | 64.2% |
| 정확한 행동(EM) | 11.2% | 33.5% |
| 목표 진행(GP) | 기준 | +6.6점 |
관찰. TM이 31.0%에서 64.2%로 올랐다. 화면을 잘라 입력을 줄이는 자르기 계열(DRS-GUI·OmniParser·RegionFocus)은 반대 방향을 가리킨다. 이들은 TM에서는 거의 중립이었지만 EM은 상대적으로 28%, GP는 35% 낮았고, 12개 사례 전부에서 그랬다.
가설. 화면을 좁히면 행동 종류는 또렷해져 TM은 버틴다. 그러나 좌표와 입력값을 고정해 주던 주변 맥락까지 함께 사라져 EM이 무너진다. 중요한 것이 특정 영역이 아니라 단계에 걸린 문제라면, 영역을 아무리 잘 다듬어도 그 손실은 되돌릴 수 없다.
가려내기 어려운 요인. 이 이득이 '학습할 거리가 하나 더 생겨서'인지, 아니면 매 단계 우선순위를 다시 매기는 구조 때문인지는 TM 숫자만으로는 갈라지지 않는다. 가까운 비교 대상이 GUI-Actor다. GUI-Actor도 FocusGUI처럼 기반 모델을 고정한 채 추가 파라미터만 학습한다. 다만 두 기법의 차이를 '매 단계 재우선순위화를 하느냐'로만 좁혀 볼 수는 없다. 행동을 뽑아내는 행동 헤드와 신호를 더하는 잔차 어댑터라는 구조도 서로 다르다. 재우선순위화 효과만 떼어 내려면 파라미터 수를 맞춘 통제 비교가 필요한데, 저자들은 이를 부록 C.3·표 5에서 수행했다. 거기서 재우선순위화가 더해 준 몫은 TM +0.98점, EM +3.54점, GP +3.44점이다. 재우선순위화가 기여한다는 쪽을 받쳐 주되, 전체 향상폭의 일부이지 향상 전부가 재우선순위화 덕이라는 뜻은 아니다.
관찰. EM은 11.2%에서 33.5%로 약 3배가 됐다. 개선 폭보다 눈에 띄는 건 두 지표 사이의 간격이다. TM 64.2%와 EM 33.5% 사이에는 여전히 큰 틈이 남아 있다.
스마트폰 상황으로 돌아가 보자. 알림음에 맥락이 바뀌는 순간 '지금 할 행동은 탭'이라고 안정적으로 고르게 된 것이 TM이 잡아 준 부분이다. 하지만 그 탭을 전송 버튼의 위치에 정확히 내리거나 입력창에 맞는 값을 넣는 일은 아직 자주 어긋난다. 이 어긋남이 EM에 잡힌다.
가설. 어디서 간격이 좁혀지는지는 분리 실험이 짚어 준다. '더하는 잔차'를 '프롬프트 임베딩을 덮어쓰는 방식'으로 바꾸면 EM이 5.30점, GP가 5.38점 떨어지는데 TM 변화는 1.20점에 그친다. 원래 입력을 덮지 않고 그대로 보존하는 설계가, 고른 행동을 정확한 대상·값에 맞추는 데 특히 중요하다는 뜻이다.
실무로 옮기면 33.5%는 무인 자동화를 그냥 맡기기엔 이른 수준이다. 민감한 스텝에는 사람이 결과를 확인하는 검증 단계를 끼워 두는 쪽에 가깝다.
관찰. GP는 평균 +6.6점 올랐다. 평균보다 '어디서' 벌어지느냐가 핵심이다. 상호작용이 깊어질수록, 즉 후반 스텝으로 갈수록 차이가 커졌다. 대표적으로 고정한 Qwen2.5-Omni는 첫 스텝 TM 64.79에서 네 번째 스텝부터(인덱스 3+) 32.79로 절반을 잃는데, FocusGUI는 같은 구간에서 첫 스텝 정확도의 86.8%를 유지한다. 세부 수치는 아래 표에 모았다.
| 후반 단계(네 번째 스텝부터, 인덱스 3+) | 기반 모델(고정) | FocusGUI |
|---|---|---|
| TM 유지 — Qwen2.5-Omni(첫 스텝 64.79) | 32.79로 하락 | 첫 스텝 정확도의 86.8% 유지 |
| EM — Qwen2.5-Omni 추이 | — | 38.73 → 46.72 |
| EM — 시간 추론 과제 | 0.00 | 39.39 |
가설. 이득이 '누적이 쌓이는 깊이'에서만 벌어진다는 점이 설명을 좁혀 준다. 이 장치가 균일하게 더 센 예측기였다면 깊이와 무관하게 일정한 격차를 유지했을 것이다. 깊이에 비례해 벌어진다는 건, 이것이 앞서 말한 순차적 산만을 겨냥한 장치라는 쪽을 뒷받침한다. 반대로 누적 이력이 거의 없는 Instant 과제의 첫 두 스텝에서는 둘이 통계적으로 구분되지 않았다.
가려내기 어려운 요인. 다만 이건 오프라인 관찰이다. 에이전트가 스스로 궤적을 만들어 갈 때도 실패 누적이 실제로 줄어드는지는 이 범위를 넘어서는 질문으로 남는다.
과제 성격도 같은 결을 보탠다. 단서가 여러 프레임에 이어지는 Temporal에서 TM 향상이 37.3점으로 가장 컸고, 대개 현재 화면에 답이 있는 Instant에서 27.8점으로 가장 작았다. 기반 모델 간 TM 격차도 35.6점에서 13.0점으로 좁혀졌다. 관찰을 잘 조직하면 올바른 행동 종류를 고르는 일이 기반 모델 성능에 덜 좌우된다는 뜻으로 읽힌다.
저자들이 직접 선을 긋는다. 위 우선순위 그림은 '기반 모델이 내부적으로 각 정보를 어떻게 쓰는지'에 대한 설명이 아니다. FocusGUI가 자신의 보조 경로 안에서 증거를 조직하는 전략으로만 읽어야 한다. 이론 분석에서도 이 잔차가 행동 '종류'는 고를 수 있지만 정확한 인자 교정은 제한된 방식으로만 한다고 구분한다. 결과 둘에서 본 TM–EM 격차와 맞물리는 지점이다.
남는 질문은 둘이다. 검증은 OmniGUI라는 스마트폰 벤치마크 한 곳(708개 작업·2,572개 스텝)에서만 이뤄졌다. 화면 구조와 정보 분포가 다른 데스크톱·웹으로 그대로 옮겨 가는지는 이 결과만으로 알 수 없다. 또 상호작용 상태 같은 특정 채널에 우선순위가 크게 쏠리는 양상이 이 벤치마크의 과제 구성 탓인지 더 일반적인 패턴인지도 추가 검증이 필요하다. 논문이 틀렸다는 게 아니라, 다른 도메인에서 그대로 성립한다고 가정하지는 말라는 경계다.
온틀은 사람을 더 뽑기 어려운 소기업과 1인 창업가의 반복 업무를, AI PM을 파견하듯 대신 처리해 주는 서비스다.
매주 금요일, 고객사 슬랙·메일·시트에 흩어진 자료를 모아 하나의 리포트로 정리해 지정된 폴더에 올리는 업무를 떠올려 보자. 자동화가 미끄러지는 지점은 대개 정해져 있다. 정리 단계에서 계속 울리는 새 알림 하나를 자료로 착각해 끌어오면, 그 오염된 중간본이 게시 단계로 넘어가 엉뚱한 최종본이 올라간다. 끝에 가서 "왜 결과물이 이상하지?"가 되는 자리다.
여기서 이 논문에서 가져올 것은 결론이 아니라 하나의 실험 가설이다. 단계마다 '지금 봐야 할 자료'의 우선순위가 다르고, 그 우선순위를 명시해 주면 중간 오염이 줄 수 있다는 가설.
주의할 제약이 하나 있다. FocusGUI의 어댑터는 기반 모델의 내부 표현을 읽고 행동 직전 자리에 신호를 더한다. 즉 모델 내부에 접근할 수 있어야 동작한다. 온틀의 업무 자동화는 대개 그런 내부 접근 없이 프롬프트와 업무 지침 수준에서 이뤄진다. 그러니 논문의 어댑터를 그대로 이식하는 일과, '단계별 우선순위'라는 아이디어만 업무 지침으로 옮겨 시험하는 일은 전혀 다른 작업이다. 우리가 할 수 있는 건 후자다.
그 가설을 검증하려면 두 가지를 따로 떼어 시험하는 편이 낫다. 하나는 단계별 정보 우선순위, 즉 각 단계에서 '지금 봐야 할 자료'를 명시해 주는 것이다. 다른 하나는 중간 결과 검증, 즉 단계마다 중간본을 확인하는 게이트를 두는 것이다. 각각을 따로 켜 보고, 최종 산출물의 오류율과 재작업으로 돌아오는 횟수가 어떻게 달라지는지 본다. 둘을 섞으면 어느 쪽이 실패를 줄였는지 가려낼 수 없다.
우리는 아직 이 방법을 온틀 과제에 적용해 본 적이 없다. 그러니 이건 논문이 증명한 결론이 아니라 진단에서 끌어낸 가설이고, 들이기 전에 우리 과제·우리 도구 분포에서 작은 표본으로 먼저 재 보는 것이 순서다.
이 논문의 비교 대상은 기반 모델을 고정한 네 기법(DRS-GUI, OmniParser, RegionFocus, GUI-Actor)이다. 전체 파인튜닝과의 직접 비교 수치는 이 발췌 범위에 없으므로 단정하지 않는다. 설계 철학만 분명하다. 원래 파라미터를 바꾸지 않고 읽는 방식만 조건 짓는 비침습(non-intrusive) 접근을 지향한다.
설정에 따라 다르다. 경계 윈도는 K를 1에서 16까지 16배 넓혀도 지표가 2~3점 안에서 뚜렷한 추세 없이 움직여, 넉넉히 둬도 민감하지 않다. 반면 압축 차원은 사정이 다르다. 32~256의 8배 범위에서 너무 작게 조이면 성능이 꺾이는데, 64에서 32로 줄이면 EM이 6.9점, GP가 6.5점 떨어진다(표 3·§3.4). 경계 윈도는 크게 공들일 필요가 없지만, 압축 차원은 지나치게 작게 잡지 않는 편이 안전하다.
본문에서 짚었듯 이 방식은 기반 모델의 통합 은닉 상태를 읽고, 행동을 만들기 직전의 임베딩 자리에 신호를 더한다. 그래서 '가중치를 못 바꾸는 제약'과 '내부를 아예 못 보는 블랙박스 API'는 다른 이야기다. 가중치는 고정하더라도 내부 표현에 접근만 되면 동작하지만, 후자에는 이 구조를 그대로 얹기 어렵다.