배포 후 실행 피드백으로 GUI 에이전트 스킬을 고쳐 쓰는 학습 없는 자기진화 프레임워크

무엇인가

GUI 에이전트는 동적 화면 위에서 장기(long-horizon) 작업을 수행한다. 팝업, 지연 로딩, 위젯 위치 변경이 실행 전에 고정한 계획을 수시로 무효화한다는 것이 이 논문의 출발점이다. 최근의 에이전트 스킬 프레임워크들은 재사용 가능한 절차 지식을 캡슐화해 이를 완화하려 하지만, 저자들은 기존 스킬 설계가 GUI 실행 역학을 겨냥하지 않았고 스킬을 배포 전에 만들어지는 정적 산출물로 취급한다고 지적한다. 논문은 실행 중 실패가 어떤 스킬 부분이 틀렸는지에 대한 실행 가능한 정보를 담고 있다고 본다. 그라운딩 오류는 신뢰할 수 없는 로컬라이제이션을, 예상치 못한 팝업은 빠진 복구 분기를, 중복 단계는 잘못된 계획을 드러낸다. 저자들은 이런 실패를 버리거나 향후 학습용으로만 쓰는 대신, 배포된 에이전트가 즉시 실패를 반성하고 그 절차적 교정을 스킬 자체에 다시 써 넣을 수 있는지를 묻는다. 기존 설계가 공동으로 해결하지 못하는 네 가지 장벽도 제시한다. 스킬이 비구조적이라 편집이 어렵고, 인터페이스가 비정상(non-stationary)이라 한 상태에서 유효한 스킬이 다른 상태에서 실패하며, 외부 반성 모델은 지연과 느슨한 결합을 만들고, 절차 지식이 개별 궤적에 갇혀 축적되지 않는다는 것이다.

어떻게 동작하나

제안 방법 EvoSkill-GUI는 학습 없는 자기진화 프레임워크로, 각 스킬을 단일 프롬프트가 아니라 구조화된 다중 파일 패키지로 표현한다. 패키지는 S = (D, A, P, B, C, F)로 정의된다. D는 검색 메타데이터, A는 접근성 트리 관련 유틸리티, P는 실행 가능한 계획 지식, B는 백업 로컬라이제이션·인식 전략, C는 실패 복구 규칙, F = {f(1), …, f(n)}는 실패 사례를 저장한다. 이 분해는 GUI 에이전트 오류의 세 원천에 대응한다. P는 어떤 단계를 수행할지, B는 인터페이스 요소를 어떻게 식별·위치시킬지, C는 기대 상태가 깨졌을 때 어떻게 복구할지를 규정한다. 따라서 그라운딩 실패는 B를, 빠진 대비책은 C를, 상위 절차 오류는 P를 갱신하는 식으로 수정이 국소화된다. 패키지를 실행 중 편집 가능하게 만들기 위해 제한된 도구 인터페이스 T = {read, write, append, list, search, create_failure}를 노출하고, 패키지 스키마 밖의 임의 수정을 막는다. 별도로 읽기 전용 접근성 도구 ψ가 현재 창의 접근성 트리를 반환하는데, ψ는 관찰만 보강하고 S를 수정하지 않으므로 인터페이스 이해와 스킬 수정이 도구 수준에서 분리된다.

무엇과 다른가

핵심 절차는 반영-수정-재사용(reflect-revise-reuse) 루프다. 반복 i에서 실행기가 현재 패키지 S(i)를 환경에서 돌려 궤적 τ(i) = Φ(S(i), E)를 얻고, 롤아웃 도중 도구 T를 호출해 즉시 수정(instant revision)을 수행해 중간 패키지 S(i,end)를 만든다. 이는 위젯 이동이나 예상치 못한 팝업 같은 국소 불일치가 전체 실패로 연쇄되는 것을 막는다. 롤아웃이 끝나면 같은 백본 모델이 고립된 비평가 πθJ 역할을 맡아 궤적을 진단하고, 실패 단계 위치, 직접 원인 분석, 실행 가능한 수정 제안을 담은 구조화 피드백 c(i)를 낸다. 비평가의 정보 집합은 엄격히 실행 궤적 안으로 제한된다. 즉 C_J ⊆ {I} ∪ o_1:T ∪ a_1:T이고 C_J ∩ {S, CoTθ, GT} = ∅이며, 실행기 쪽 정보 집합은 C_E ⊇ C_J ∪ {S, CoTθ}다. 비평가는 실행기와 파라미터를 공유하되 별도 세션에서 돌기 때문에, 개선을 더 강한 외부 감독자 덕으로 돌릴 수 없다. 이후 실행기가 S(i+1) ∼ πθ(· | S(i,end), c(i), τ(i))로 패키지를 수정하고, 실패한 경우 create_failure로 실패 사례 f(i) = (I, c(i), τ(i))를 F에 덧붙인다. 루프는 성공하거나 최대 수정 라운드에 도달하면 끝난다. 재사용을 위해 스킬은 전체 절차 본문이 아니라 구조화 메타데이터 D = (id, intent, app, platform, kw, args, hist, status)로 색인된다. 검색 점수는 질의 토큰 Q, 스킬 토큰 T_S, 중복 O = Q ∩ T_S에 대해 base(q,S) = 0.6·|O|/|Q| + 0.4·|O|/|Q ∪ T_S|로 계산하고, 앱·키워드 일치 보너스와 질의 고유 개념 토큰 누락에 대한 발산 페널티를 더한 뒤 score(q,S) = clip(base + b_app + b_kw − p_div, 0, 1)로 자른다. 최상위 후보가 임계값 θ_r을 넘으면 해당 패키지를 재사용하고, 아니면 새 패키지를 만든다. 새 패키지는 성공적으로 실행되거나 자기진화 루프를 거친 뒤에만 라이브러리에 들어간다.

어떻게 쓰나

실험은 모바일과 데스크톱을 아우르는 세 벤치마크에서 수행됐다. AndroidWorld는 20개 실제 앱에 걸친 116개 과제, MobileWorld는 장기·교차 앱 워크플로를 반영하는 모바일 벤치마크(GUI 전용 설정으로 평가), OSWorld는 Ubuntu·Windows·macOS를 아우르는 실제 컴퓨터 환경이다. 베이스 모델은 범용 모델(Claude-Sonnet-4.6, Qwen3.6-Plus, Qwen3.6-35B-A3B)과 GUI 특화 모델(GUI-Owl-1.5-8B, MAI-UI-8B) 두 부류다. GUI 전용 MobileWorld 부분집합에서 EvoSkill-GUI는 모든 모델을 끌어올렸다. Claude-Sonnet-4.6은 57.1%에서 67.6%로, Qwen3.6-Plus는 53.3%에서 69.5%로, Qwen3.6-35B-A3B는 32.4%에서 44.8%로, MAI-UI-8B는 29.5%에서 37.1%로 상승했다. AndroidWorld에서는 seed 30에서 +2.6%p, seed 42에서 +6.0%p를 얻었다. OSWorld에서 GUI-Owl-1.5-8B는 전체 성공률이 46.7%에서 54.8%로(+8.1) 올랐고 Thunderbird +20.0, VLC +42.7, VS Code +5.2 같은 응용별 큰 향상이 있었으며, Qwen3-VL-8B-Instruct는 23.8%에서 34.3%로(+10.5) 개선됐다. 초록이 제시한 최대 향상치는 각각 +16.2%, +6.0%, +10.5%다.

전제와 한계

소거 실험은 설계 선택의 기여를 수치로 보여준다. 구조화 다중 파일 패키지는 단일 파일 표현보다 성공률이 66.67%에서 69.52%로(+2.85) 높았다. 즉시 수정을 제거하면 69.52%에서 62.86%로(−6.66), 정보 격리를 제거하면 69.52%에서 60.95%로(−8.57) 떨어졌다. 패키지 구성요소별로는 계획 문서 제거 시 65.71%(−3.81)로 가장 큰 하락이 있었고, 실패 반영 제거 시 66.67%(−2.85)가 됐다. 접근성 트리 입력을 추가하면 Qwen3.6-Plus +3.80, Qwen3.6-35B-A3B +1.90, MAI-UI-8B +2.85가 향상됐다. 검색에서는 메타데이터 기반이 12개 재사용 사례에서 평균 점수 0.88로 전체 텍스트 검색의 0.41을 크게 앞섰고, θ_r = 0.6에서 12개 전부 정답 스킬을 찾은 반면 전체 텍스트는 1개만 성공했다. 임계값 민감도는 0.4에서 55.2%, 0.6에서 69.5%, 0.8에서 66.7%로 0.6이 균형점이었다. 라운드별로는 Claude-Sonnet-4.6이 1라운드 58.1%에서 3라운드 67.6%로, Qwen3.6-35B-A3B가 32.4%에서 44.8%로, MAI-UI-8B가 28.5%에서 37.1%로 올랐다. Qwen3.6-Plus를 5라운드까지 늘리면 56.2% → 61.9% → 68.6%로 오른 뒤 4라운드 68.6%, 5라운드 69.5%(+0.9)에 그쳐, 첫 3라운드가 12.4%p를 벌고 추가 2라운드는 0.9%p만 더한다. 같은 예산 비교에서 Qwen3.6-Plus pass@3 베이스라인은 103.00M 토큰으로 62.8%인 반면, 3라운드 EvoSkill-GUI는 94.75M 토큰으로 69.5%를 기록해 더 적은 예산으로 6.7%p를 더 얻었다. AndroidWorld 116+116 과제 집합에서는 Phase 1이 68.1%에서 70.7%로(37.9% 재사용), Phase 2가 55.2%에서 61.2%로(전량 재사용) 개선됐고, 초기 실패 89건 중 27건을 회복했으며 그중 19건이 재사용 스킬에 의한 것이었다. 라이브러리는 과제 10에서 9개, 과제 110에서 69개 스킬로 늘고 Phase 2에서 98개·재사용률 56.1%에 도달했다. 실패 유형별 수리 가능성은 계획 수준 오류가 23건 중 16건으로 가장 잘 고쳐졌고(plan.md), 그라운딩 오류는 12건 중 6건(backup.md), 빠진 대비책은 4건 중 1건(recover.md)에 그쳤다.

개발자 관점에서 이 논문의 실용적 의미는 재학습이나 파인튜닝 없이, 이미 배포된 에이전트의 실패 궤적만으로 절차 지식을 축적할 수 있다는 점이다. 특히 스킬을 계획·그라운딩·복구로 분리해 두면 어떤 실패가 어느 파일을 고쳐야 하는지가 분명해지고, 정보 격리된 비평가와 도구 제한 편집이 수정 범위를 감사 가능하게 유지한다. 다만 실무 도입 시 확인할 것은 세 가지다. 첫째, 검색 임계값 θ_r을 낮추면 무관한 스킬이 섞여 성능이 급락하므로(0.4에서 55.2%) 도메인별로 임계값을 튜닝해야 한다. 둘째, 라운드 수는 3회가 비용 대비 효율의 한계로, 이후 추가 라운드의 이득은 미미하다. 셋째, 실패 유형에 따라 수리율이 크게 다르므로 계획 수준 오류가 많은 워크플로에서 효과가 크고, 빠진 대비책처럼 복구 규칙으로 잘 고쳐지지 않는 실패는 별도 설계가 필요하다.

저자들이 밝힌 한계는 분명하다. EvoSkill-GUI는 스크린샷, 접근성 트리, 실행 궤적을 해석하고 도구 호출로 구조화된 수정을 만들어내는 일을 전적으로 백본 모델에 의존한다. 백본의 지각이나 궤적 진단이 신뢰할 수 없으면 스킬 편집이 실패의 진짜 원인을 담지 못하고, 원리상 이전에 검증된 패키지에 회귀를 유발할 수 있다. 도구 제한 인터페이스와 정보 격리 비평이 위험을 줄이지만, 유해한 스킬 편집을 거부하는 형식적 검증기는 현재 포함되어 있지 않다. 평가는 세 개의 대표적 GUI 벤치마크에 한정되며, 실제 배포는 더 잦은 인터페이스 업데이트, 개인화 설정, 네트워크 의존 지연, 프라이버시 민감 상태를 포함하므로 벤치마크가 반영하지 못한다. AndroidWorld에서 관측된 재사용률은 같은 과제 계열의 파라미터화 변형에서 얻은 것이며, 진짜 처음 보는 애플리케이션 범주로의 전이는 이 수치보다 더 완만하게 떨어질 수 있다. 마지막으로 스킬 진화 루프는 실패한 롤아웃마다 비평가 호출 1회와 수정 호출 1회의 추가 추론 비용을 발생시킨다. 백본 재학습이나 파인튜닝에 비하면 무시할 수준이지만, 지연에 민감한 배포에서는 재사용을 통해 상각해야 한다.