[arXiv 2606.27330] PEEU for GUI Agents: 자율 경험 탐색과 사후 경험 활용으로 계획 능력 키우기

Empowering GUI Agents via Autonomous Experience Exploration and Hindsight Experience Utilization for Task Planning

https://arxiv.org/abs/2606.27330

Tianyi Men, Zhuoran Jin, Pengfei Cao, Yubo Chen, Kang Liu, Jun Zhao | Institute of Automation, Chinese Academy of Sciences; School of Artificial Intelligence, University of Chinese Academy of Sciences | arXiv:2606.27330 | 2026년 6월 | ACL 2026 Main

---

1. 서론: 작은 GUI 에이전트의 계획 병목

웹 기반 GUI 에이전트는 사람 대신 브라우저 화면을 읽고 클릭, 입력, 스크롤을 이어 가는 시스템이다. 사용자는 “가장 평점이 높은 레시피를 찾아줘”처럼 자연어 목표를 말하지만, 모델이 실제로 처리해야 하는 것은 버튼 위치, 필터 상태, 페이지 전환, 부분적으로만 보이는 검색 결과, 그리고 중간 화면마다 달라지는 선택지다. 이 논문이 겨냥하는 병목은 바로 그 사이의 task planning이다. 화면을 보는 능력과 다음 클릭을 고르는 능력이 있어도, 긴 목표를 실행 가능한 하위 목표로 안정적으로 쪼개지 못하면 에이전트는 초반 몇 단계에서 방향을 잃는다.

상용 대형 모델은 이런 계획 문제를 어느 정도 흡수할 수 있지만, 비용과 개인정보 문제가 남는다. 기업 내부 웹, 교육 플랫폼, 쇼핑 사이트, 지도 서비스처럼 화면 자체가 민감한 경우에는 작은 오픈소스 multimodal large language model을 로컬 또는 제한된 환경에서 쓰고 싶어진다. 문제는 Qwen2.5-VL 3B나 7B 같은 작은 모델이 일반적인 시각 질의응답에서는 쓸 만해 보여도, 웹 사이트가 바뀌고 목표가 길어지면 계획 단위의 일반화가 급격히 약해진다는 점이다. 논문은 이 격차를 “더 큰 모델을 쓰자”라는 처방에서 “작은 모델이 배울 수 있는 경험을 어떻게 만들 것인가”라는 데이터 문제로 바꾼다.

제안법 PEEU, 즉 Planning Experience Exploration and Utilization은 두 가지 아이디어를 결합한다. 첫째, 에이전트가 주어진 URL에서 스스로 탐색 목표를 만들고 실행하면서 화면 전이와 행동 경험을 모은다. 둘째, 탐색이 끝난 뒤 실제 trajectory가 남긴 결과를 되돌아보며 원래 목표와 어긋난 부분을 보정하고, 더 엄격한 고수준 학습 과제로 다시 쓴다. 이 “사후 경험 활용”이 중요한 이유는 웹 환경의 제약이 홈페이지 문장만으로는 드러나지 않기 때문이다. 평점 기준, 필터 이름, 준비 시간 조건, 검색 결과의 정렬 방식 같은 조건은 직접 눌러보고 나서야 알 수 있다.

논문은 방법론뿐 아니라 분석 프레임워크도 함께 제안한다. TDHAF, Task Decomposition Hierarchical Analysis Framework는 작업을 low, middle, high 세 과립도로 나누고, 저수준 기술 학습이 고수준 계획으로 올라가는지, 고수준 계획 학습이 저수준 실행으로 내려오는지, 그리고 사이트가 바뀌어도 이 능력이 유지되는지를 분해해서 본다. 이 덕분에 결과 해석이 단순 성공률 비교에서 끝나지 않는다. 어떤 과립도의 데이터가 어떤 방향의 일반화에 유리한지, 작은 GUI 에이전트가 실제로 무엇을 배워야 하는지가 표와 그림으로 드러난다.

Figure 1: Planning Experience Exploration and Utilization 방법의 전체 개요.

Figure 1은 기존 방식과 PEEU의 차이를 한 장에 압축한다. 원래 trajectory를 그대로 쓰면 목표와 실제 화면 결과가 느슨하게 붙어 있지만, PEEU는 탐색 과정에서 얻은 전후 화면 변화와 atomic experience를 다시 모아 high-level task를 재작성한다. 따라서 훈련 데이터는 “어떤 버튼을 눌렀는가”보다 “실제 웹 환경에서 어떤 제약을 만족해야 했는가”를 더 강하게 담게 된다. 또한 그림 왼쪽의 기존 방법은 경험을 atomic 또는 coarse 단위로 흩어 보관하지만, 오른쪽 PEEU는 실제 탐색 결과를 기준으로 목표 문장을 다시 맞추기 때문에 학습 데이터의 조건 누락을 줄인다.

이 논문을 지금 볼 만한 이유는 GUI 에이전트 학습이 평가 벤치마크에서 제품 적용 단계로 넘어가는 구간에 있기 때문이다. 최근 VISUALSKILL처럼 screenshot evidence를 스킬 문서에 넣는 연구는 에이전트가 화면 증거를 어떻게 기억해야 하는지 보여 주었다. PEEU는 그 다음 질문, 즉 그렇게 얻은 화면 경험을 작은 모델의 post-training 데이터로 어떻게 바꾸어야 하는지 다룬다. 두 흐름을 함께 보면 GUI 에이전트의 병목이 단일 모델 크기보다 경험의 구조, 증거의 정렬, 과제 과립도에 놓여 있다는 점이 선명해진다.

PEEU가 흥미로운 지점은 experience loop를 학습 데이터 제작의 중심에 놓는다는 점이다. 많은 GUI agent pipeline은 성공 trajectory를 모아 imitation data로 쓰거나, 실패 로그를 사람이 다시 주석 처리한다. 이 논문은 그 중간에 자동 탐색과 hindsight rewriting을 넣는다. 즉 trajectory를 수집한 뒤 바로 학습시키지 않고, 실제로 무엇이 보였고 어떤 조건이 확인됐는지 다시 읽어 목표를 보정한다. 이 단계가 없으면 웹사이트별 우연한 클릭 순서가 모델에게 목표 자체처럼 주입된다.

작은 모델을 쓰려는 동기는 단순 비용 절감에 머물지 않는다. 회사 내부 도구, 병원 예약 시스템, 교육 LMS, 개발자 dashboard처럼 GUI 화면에 민감 정보가 들어간 경우 상용 API 호출이 부담스럽다. open-source MLLM을 자체 인프라에서 fine-tuning하고 배포할 수 있다면 개인정보 경계가 명확해진다. PEEU는 이런 환경에서 “작은 모델을 얼마나 똑똑하게 만들 수 있는가”보다 “어떤 경험을 어떤 형태로 주면 작은 모델이 계획 행동을 배울 수 있는가”를 묻는다.

또 하나 중요한 배경은 GUI 에이전트가 일반 텍스트 agent보다 오류 표면이 훨씬 넓다는 점이다. 텍스트 agent는 잘못된 tool call을 내면 로그로 비교적 쉽게 잡히지만, GUI agent는 화면 상태가 바뀌고 모달이 열리며 일부 정보가 viewport 밖에 숨는다. 같은 action이라도 현재 화면 위치와 scroll state에 따라 의미가 달라진다. 따라서 학습 데이터는 action 이름만 담아서는 부족하고, state transition과 목표 조건의 관계를 함께 보존해야 한다.

2. 배경 및 관련 연구: 화면 조작 에이전트에서 경험의 의미

2.1 GUI 에이전트와 planning granularity

GUI 에이전트 연구에서 가장 흔한 데이터 단위는 trajectory다. 한 trajectory는 시작 화면, 사용자 목표, 중간 관찰, 행동, 최종 결과를 포함한다. 하지만 trajectory를 학습 데이터로 쓸 때 목표의 과립도가 크게 갈린다. “검색창을 클릭한다” 같은 atomic action은 명확하고 검증하기 쉽지만, “조건에 맞는 상품을 찾아 비교한다” 같은 high-level task는 여러 단계와 화면 전환을 포함한다. 작은 모델은 atomic action을 많이 배워도 고수준 목표를 스스로 계획하는 데 어려움을 겪을 수 있다.

기존 접근은 대체로 두 방향으로 나뉜다. Atomic 방식은 전후 화면 차이를 보고 클릭, 입력, 선택 같은 미세 행동을 학습한다. 이 방법은 라벨이 좁고 action grounding이 쉬운 장점이 있다. 반대로 trajectory-level 방식은 긴 목표와 전체 실행 흐름을 학습하지만, 실제 trajectory가 원래 목표와 정확히 일치하지 않는 경우가 많다. 예를 들어 목표는 별점 4.5 이상 레시피를 요구했는데, 탐색 중 실제로는 별점 4.0 항목만 골랐다면 그 trajectory를 그대로 훈련시키는 것은 모델에게 잘못된 목표-결과 대응을 주입한다.

PEEU의 배경 문제는 여기서 나온다. 웹은 부분 관찰 환경이며, 사이트마다 필터 이름, 정렬 기준, 카드 구조, 로그인 요구, 스크롤 로딩 방식이 다르다. 홈페이지에서 생성한 coarse task는 실제 페이지 내부 제약을 충분히 반영하지 못한다. 따라서 경험을 모으는 것만큼, 경험을 보고 학습 목표를 재정렬하는 단계가 중요하다. 이 논문은 GUI 에이전트 경험을 단순 replay memory로 보지 않고, 후견적으로 재작성해야 하는 학습 신호로 본다.

2.2 관련 연구와 이 논문의 위치

논문은 DeepResearch agent, web agent memory, trajectory quality filtering, GUI action learning의 여러 흐름과 연결된다. WebSailor, WebShaper, WebWatcher 계열은 넓은 웹 검색과 정보 수집을 중심으로 에이전트 성능을 키운다. AWM, Agent KB, Memento, Memp 같은 연구는 과거 경험을 지식베이스나 메모리로 저장해 다음 행동에 활용한다. 반면 PEEU는 경험을 inference-time retrieval로만 쓰지 않고, 작은 MLLM의 SFT 또는 GRPO post-training 데이터로 전환한다는 점이 다르다.

이 차이는 경험 활용 위치를 바꾼다. retrieval 방식은 입력 task가 들어왔을 때 비슷한 경험을 찾아 prompt에 붙인다. 작은 모델은 긴 prompt를 충분히 해석하지 못할 수 있고, 실제 논문 결과에서도 3B 모델은 Atomic-Prompt와 Trajectory-Prompt에서 거의 성능을 내지 못한다. PEEU는 경험을 모델 파라미터에 반영하는 훈련 데이터로 만든다. 따라서 inference 시점에 긴 사례를 읽는 부담을 줄이고, 계획 패턴 자체를 모델 행동으로 옮기는 쪽에 가깝다.

위키 관점에서 보면 이 논문은 [[computer-use-agents]]와 [[visualskill-multimodal-skills-computer-use-agents-2606-18448]] 사이를 잇는다. VISUALSKILL은 GUI 작업에 필요한 절차와 스크린샷 근거를 스킬 문서로 저장하는 쪽에 초점을 맞췄다. PEEU는 그런 화면 경험이 학습 데이터가 될 때 어떤 granular task로 변환되어야 하는지 묻는다. 즉 하나는 agent memory의 표현 문제, 다른 하나는 post-training 신호의 정렬 문제를 다룬다.

다음 표는 논문이 비교하는 경험 활용 방식의 차이를 요약한다. 핵심은 PEEU가 “경험을 보관한다”에서 멈추지 않고, 실제 관찰된 웹 제약을 반영한 strictly aligned high-level task를 합성한다는 점이다. 이렇게 만들어진 데이터는 모델에게 단순 UI 조작 순서를 넘어서 목표와 실행 조건 사이의 관계를 학습시킨다.

방식	경험 단위	사용 시점	장점	한계
Atomic-Prompt	전후 화면 차이에서 뽑은 atomic experience	추론 중 prompt retrieval	개별 클릭·입력 근거가 명확함	작은 모델이 긴 컨텍스트를 계획 신호로 잘 흡수하지 못함
Trajectory-Prompt	전체 trajectory 수준 experience	추론 중 유사 사례 retrieval	목표 흐름을 넓게 참조할 수 있음	trajectory가 목표와 느슨하게 맞으면 오히려 혼선을 줌
Coarse training	원래 exploration task	SFT 또는 GRPO 데이터	데이터 제작이 단순함	실제 탐색 결과와 task 조건이 불일치할 수 있음
Atomic training	클릭·입력 등 저수준 task	SFT 또는 GRPO 데이터	action grounding 학습에 유리함	고수준 계획 구성 능력을 보장하지 못함
PEEU	사후 경험으로 재작성한 high-level task	SFT 또는 GRPO 데이터	실제 웹 제약과 목표가 더 엄격하게 정렬됨	탐색·요약·재작성 품질에 의존함

경험 기반 GUI agent 연구는 memory와 training 사이에서 선택지를 갖는다. memory-first 방식은 과거 task와 화면 증거를 저장해 다음 task에서 검색한다. 이 방식은 빠르게 확장할 수 있지만, 검색된 사례가 현재 화면과 미묘하게 다르면 모델이 스스로 차이를 보정해야 한다. training-first 방식은 경험을 미리 데이터로 흡수시키므로 inference가 단순해진다. PEEU는 둘 중 training-first에 가깝지만, 경험을 raw trajectory가 아닌 정렬된 high-level task로 바꾸어 두 방식의 장단점을 조정한다.

특히 GUI 작업에서는 “비슷한 경험”의 기준이 애매하다. 같은 Amazon 검색이라도 상품 카테고리, 가격 필터, 배송 조건, 정렬 버튼 위치가 달라지면 이전 사례의 어느 부분을 따라야 할지 불분명하다. Atomic-Prompt는 element-level 경험을 많이 찾을 수 있지만, 목표 전체를 재구성하기 어렵다. Trajectory-Prompt는 전체 흐름을 주지만, 현재 task와 불필요한 절차까지 함께 들어온다. PEEU가 경험을 task로 재작성하는 이유는 이 ambiguity를 줄이기 위해서다.

논문에서 비교하는 Coarse 방식도 실무에서는 흔히 쓰일 수 있다. 탐색 목표를 만들고 trajectory가 생기면 그 목표를 그대로 label로 붙여 학습시키는 것이다. 그러나 웹 탐색은 중간에 goal drift가 자주 생긴다. 모델은 원래 목표를 완전히 만족하지 못했는데도 성공 trajectory처럼 기록될 수 있다. hindsight rewriting은 이 drift를 인정하고, 실제 trajectory가 달성한 조건에 맞게 목표를 다시 쓰려는 장치다. 이것이 PEEU의 데이터 정렬 철학이다.

이 관점은 기존 [[computer-use-agents]] 페이지의 운영 포인트와도 맞다. 화면 조작 agent에서는 결과만큼 provenance와 중단 조건이 중요하다. PEEU는 safety boundary 자체를 해결하지는 않지만, 적어도 학습 데이터가 어떤 화면 변화에서 왔는지 추적할 수 있는 구조를 만든다. 이후 verifier를 붙이면 “이 task 조건은 어떤 screenshot transition에서 추출되었는가”를 검토할 수 있다.

3. 방법론: PEEU가 경험을 만들고 쓰는 방식

3.1 Planning tree exploration

PEEU의 첫 단계는 planning tree exploration이다. 사용자가 사람이 만든 세부 task 목록을 주는 대신, 시스템은 웹사이트 URL과 홈페이지 상태를 입력으로 받아 탐색 목표 목록을 생성한다. 이 목표들은 해당 사이트에서 시도해 볼 만한 정보 탐색, 필터 조작, 상세 페이지 이동, 조건 확인 같은 작업이 된다. 이후 에이전트는 환경과 상호작용하며 관찰 상태와 행동을 연결한 방향성 tree를 만든다. 모든 trajectory는 홈페이지를 root로 공유하고, 각 branch는 서로 다른 목표 또는 선택 경로를 나타낸다.

이 tree 구조가 중요한 이유는 웹사이트 탐색이 선형 로그 하나로 충분히 설명되지 않기 때문이다. 같은 홈페이지에서 레시피 조건, 가격 조건, 지도 경로, repository 검색처럼 서로 다른 작업이 갈라질 수 있다. 하나의 trajectory만 모으면 특정 경로의 우연한 성공이나 실패에 과하게 묶인다. 반면 tree는 여러 작업을 같은 사이트 구조 위에 배치하므로, 후속 단계에서 “어떤 화면 변화가 어떤 제약을 드러냈는지”를 비교하기 쉽다.

논문은 이 과정을 사람의 학습 방식과 연결한다. 사람도 처음 보는 웹사이트에서 곧바로 완벽한 계획을 세우지 않는다. 메뉴를 눌러 보고, 검색 결과가 어떻게 정렬되는지 보고, 필터가 어떤 속성을 갖는지 확인한 뒤 다음 번에 더 정확한 목표를 세운다. PEEU는 이 탐색을 모델 데이터 생성 과정으로 끌어온다. 작은 MLLM이 직접 모든 추론을 내재화하기 어렵다면, 탐색을 통해 드러난 환경 제약을 명시적 학습 task로 바꾸겠다는 설계다.

Figure 2: 두 단계로 구성된 Planning Experience Exploration and Utilization 방법.

Figure 2는 PEEU의 핵심 흐름을 stage 1과 stage 2로 분리해 보여 준다. 첫 단계는 URL에서 출발해 task list와 exploration tree를 만들고, 두 번째 단계는 전후 화면 변화로 atomic experience를 추출한 뒤 high-level task로 다시 묶는다. 중요한 부분은 원래 탐색 목표를 그대로 쓰지 않고, 실제 trajectory가 만든 관찰 결과에 맞추어 학습 목표를 재정렬한다는 점이다. 이 도식은 논문의 contribution이 새 model architecture보다 data transformation pipeline에 있음을 분명히 보여 주며, 작은 MLLM이 읽을 수 있는 형태로 planning experience를 압축하는 위치를 설명한다.

3.2 Planning experience utilization

두 번째 단계는 planning experience utilization이다. 논문은 coarse high-level task의 약점을 두 가지로 본다. 첫째, task와 trajectory가 항상 맞지 않는다. 목표가 요구한 조건과 실제 클릭 경로가 만족한 조건이 어긋날 수 있다. 둘째, 원래 task는 환경 내부의 세부 제약을 모른다. 사용자가 “가장 빠른 준비 시간”을 요구하더라도, 해당 사이트가 준비 시간 필드를 어떤 이름으로 제공하는지, 정렬 버튼이 어디에 있는지는 직접 탐색 후에야 알 수 있다.

PEEU는 각 action 전후의 화면 상태를 비교해 atomic experience를 추출한다. 여기서 experience는 단순 좌표보다, 특정 element와 상호작용했을 때 어떤 의미 있는 UI 변화가 발생했는지를 설명하는 쪽에 가깝다. 예를 들어 필터 버튼을 눌렀더니 cuisine, rating, time 조건이 나타났다면, 그 경험은 다음 high-level task의 제약 조건을 더 엄격하게 만드는 근거가 된다. 화면 변화가 없는 bounding box 차이보다, 새 element, 데이터 갱신, 페이지 전환처럼 실제 의사결정에 영향을 주는 변화가 중요하다.

그 다음 atomic experience들을 trajectory-level experience로 묶고, 다시 high-level PEEU task로 aggregation한다. 이 aggregation은 원래 task에서 지나치게 구체적인 클릭 순서를 덜어내고, 사용자가 현실에서 말할 법한 선언형 목표로 바꾸되, 탐색 중 확인된 제약은 보존한다. 결과적으로 모델이 학습하는 문장은 “왼쪽 메뉴를 누른 뒤 세 번째 항목 클릭”보다 “조건 A와 B를 만족하는 항목을 찾아라”에 가까워진다. GUI 에이전트가 필요로 하는 것은 특정 페이지의 클릭 암기보다 목표-제약-행동의 관계이기 때문이다.

훈련 단계에서는 이렇게 생성된 PEEU task를 현재 상태, 과거 history, task description에서 다음 action을 고르는 정책 학습 문제로 사용한다. 논문은 SFT와 GRPO를 모두 실험한다. SFT는 정렬된 trajectory를 모방하도록 만들고, GRPO는 rollout reward를 통해 성공적 계획을 강화한다. 두 학습법이 모두 들어간 이유는 데이터 정렬만으로 충분한지, 혹은 실제 실행 보상까지 붙였을 때 작은 모델의 계획 능력이 더 좋아지는지를 비교하기 위해서다.

PEEU pipeline을 작업 단위로 쪼개면 다음과 같다. 각 단계는 앞 단계에서 만든 artifact를 그대로 넘기지 않고, 웹 환경에서 드러난 정보만 남기는 방향으로 압축한다. 이 압축은 정보를 버리는 과정이면서 동시에 학습 신호를 더 선명하게 만드는 과정이다.

단계	입력	출력	학습 신호로서의 의미
Self-driven task generation	홈페이지 상태, URL, MLLM	탐색할 기본 task list	사이트에서 가능한 목표 후보를 사람이 만들지 않고 초기화함
Self-execution exploration	task list, environment, URL	rooted directed exploration tree	여러 trajectory를 같은 사이트 구조 위에 모아 비교 가능하게 함
Atomic experience extraction	행동 전 화면, action, 행동 후 화면	전후 변화 중심 atomic experience	좌표보다 element 의미와 UI 변화에 초점을 둠
Experience aggregation	atomic experience sequence	정제된 high-level PEEU task	실제 환경 제약을 반영한 선언형 목표로 재작성함
Policy training	state, history, PEEU task	SFT 또는 GRPO로 학습된 action policy	작은 MLLM이 inference prompt 없이 계획 패턴을 내재화하도록 함

3.3 Hindsight experience의 역할

이 논문에서 hindsight라는 단어는 강화학습의 Hindsight Experience Replay와 닮은 직관을 갖는다. 원래 목표로는 실패하거나 어긋난 trajectory도, 실제로 무엇을 달성했는지 되돌아보면 유용한 학습 사례가 된다. 웹 탐색에서 이 관점은 특히 자연스럽다. 사용자가 처음 요구한 조건을 완전히 만족하지 못했더라도, trajectory는 여전히 “이 사이트에서는 어떤 필터가 있고, 어떤 상세 정보가 어디에서 보이며, 어떤 클릭이 어떤 상태 변화를 만든다”는 경험을 남긴다.

따라서 PEEU의 핵심은 실패 경험을 버리지 않고 올바른 목표로 다시 붙이는 것이다. 이는 작은 모델 훈련에서 데이터 효율성과 연결된다. 웹 trajectory를 새로 수집하는 비용은 작지 않고, 사이트가 바뀌면 기존 action sequence의 직접 재사용성은 떨어진다. 하지만 action 전후 변화와 결과 기반 제약을 추출하면, 특정 좌표는 달라도 계획 단위의 패턴은 남는다. 논문은 이 패턴을 high-level task training이 더 잘 흡수한다고 주장한다.

Planning tree exploration을 실제로 구현할 때 가장 중요한 설계는 root state 공유다. 같은 홈페이지에서 여러 task가 갈라지면, 모델은 어떤 element가 공통 navigation entry인지, 어떤 element가 task-specific control인지 구분할 수 있다. 예를 들어 레시피 사이트의 검색창은 거의 모든 task에서 공통 entry가 되지만, cuisine filter나 preparation time filter는 특정 조건 task에서만 중요하다. tree로 수집하면 이런 공통 구조와 특수 구조가 trajectory 간 비교로 드러난다.

Experience extraction prompt가 전후 화면을 비교하라는 점도 의미가 있다. GUI에서는 action text만으로 변화의 의미를 알기 어렵다. “click button”이라는 action은 검색 실행, 필터 열기, 상세 페이지 이동, modal 닫기 모두가 될 수 있다. 전후 screenshot을 함께 읽으면 action의 semantic role이 드러난다. PEEU는 이 role을 atomic experience로 만들고, 나중에 high-level task를 재작성하는 재료로 사용한다.

Experience aggregation 단계에서는 지나치게 절차적인 정보를 줄인다. 학습 task가 “왼쪽 두 번째 드롭다운을 열고 세 번째 옵션을 누른다”처럼 좌표화되면, 다른 웹사이트로 옮겨 갔을 때 도움이 적다. 대신 “평점 조건과 준비 시간 조건을 함께 만족하는 결과를 찾는다”처럼 목표 조건을 남기면, 모델은 현재 화면에서 해당 조건을 만족시키는 UI를 다시 찾아야 한다. 이것이 PEEU가 OOD 성능을 겨냥하는 방식이다.

정책 학습 관점에서 PEEU task는 state, history, task description을 action으로 연결하는 조건부 policy를 만든다. 여기서 history는 단순 로그를 넘어 이전 action이 어떤 목표 조건을 이미 만족했는지 알려 주는 맥락이다. 작은 MLLM이 history를 완벽하게 reasoning하지 못하더라도, 훈련 중 반복적으로 “조건 확인 후 다음 action 선택” 패턴을 보면 planning prior가 생길 수 있다.

오류 모드도 명확하다. 첫째, exploration agent가 사이트를 충분히 탐색하지 못하면 중요한 제약이 task에 들어오지 않는다. 둘째, atomic experience extraction이 UI 변화를 잘못 설명하면 aggregation이 잘못된 조건을 만든다. 셋째, aggregation이 너무 추상적이면 모델이 action supervision을 잃고, 너무 구체적이면 OOD 일반화가 약해진다. PEEU의 성능은 이 세 지점의 균형에 달려 있다.

4. 실험 설정: WebVoyager와 TDHAF로 보는 계획 일반화

4.1 WebVoyager 기반 OOD 사이트 평가

주요 성능 평가는 WebVoyager 기반 실제 웹사이트에서 이뤄진다. 테스트 사이트는 Allrecipes, Amazon, Apple, arXiv, GitHub, Coursera, Map, Wolfram 등으로 구성된다. Allrecipes가 in-domain 학습 소스 역할을 하고, 나머지 사이트들은 전혀 다른 UI와 정보 구조를 가진 OOD 환경으로 사용된다. 이 세팅은 GUI 에이전트가 특정 사이트 조작을 암기했는지, 아니면 목표 분해와 조건 확인 능력을 다른 사이트로 옮길 수 있는지를 확인한다.

비교 대상은 상용 대형 모델과 다양한 작은 오픈소스 MLLM post-training 방식이다. GPT-4o, Claude 3 Opus, Qwen2.5-VL-72B, Qwen2.5-VL-32B가 vanilla 기준선으로 들어가고, 작은 모델에서는 Qwen2.5-VL-3B와 7B를 사용한다. 작은 모델에 대해서는 Vanilla, Atomic-Prompt, Trajectory-Prompt, Coarse-SFT, Coarse-GRPO, Atomic-SFT, Atomic-GRPO, PEEU-SFT, PEEU-GRPO를 비교한다. 이렇게 설계해야 prompt retrieval, coarse trajectory training, atomic action training, hindsight high-level training의 차이가 분리된다.

SFT 실험은 llama-factory를 사용하고 batch size 16, learning rate 5.0e-6, epoch 5로 진행된다. GRPO 실험은 verl 기반이며 batch size 20, learning rate 1.0e-6, rollout size 10, epoch 7을 사용한다. 모든 실험은 4대의 A800 GPU에서 수행되고, 공정 비교를 위해 같은 trajectory scale을 사용한다. 논문은 0.1k Allrecipes trajectory와 2k unseen website trajectory라는 두 데이터 규모를 둔다. 작은 모델이 데이터 양과 과립도 변화에 어떻게 반응하는지 보기 위한 장치다.

다음 표는 실험 대상과 학습 구성을 정리한다. 수치 자체보다 중요한 점은 baseline이 단순 모델 크기 비교로 끝나지 않도록 설계됐다는 것이다. 같은 Qwen2.5-VL 계열에서 prompt, SFT, GRPO, coarse, atomic, PEEU를 모두 비교하므로, 개선이 모델 크기 때문인지 데이터 변환 때문인지 더 잘 구분할 수 있다.

항목	설정	해석 포인트
Base models	Qwen2.5-VL-3B-Instruct, Qwen2.5-VL-7B-Instruct	작은 오픈소스 MLLM의 계획 학습 가능성을 확인
Commercial / large baselines	GPT-4o, Claude 3 Opus, Qwen2.5-VL-72B, Qwen2.5-VL-32B	큰 모델의 vanilla web planning 성능과 비교
SFT setup	batch 16, learning rate 5.0e-6, epoch 5, llama-factory	정렬된 task-trajectory 데이터를 모방 학습으로 흡수
GRPO setup	batch 20, learning rate 1.0e-6, rollout size 10, epoch 7, verl	성공 보상 기반으로 action policy를 강화
Trajectory scale	0.1k Allrecipes, 2k unseen website trajectories	데이터 규모와 과립도 효과를 함께 관찰
Hardware	4 A800 GPUs	대형 상용 모델 호출 없이 재현 가능한 post-training 세팅

4.2 TDHAF: 세 과립도의 분해 평가

성능 표 하나만 보면 “PEEU가 더 높다”는 결론으로 끝나기 쉽다. TDHAF는 그 뒤를 파고든다. 작업을 low, middle, high 세 수준으로 나누고, 학습 세트와 테스트 세트를 조합해 세 가지 일반화 방향을 만든다. low-level task는 클릭, 입력, element 선택처럼 atomic action에 가깝고, middle-level task는 몇 개의 atomic action을 묶은 부분 목표다. high-level task는 사용자가 실제로 말하는 복합 목표에 가깝다.

TDHAF의 첫 번째 축은 ID bottom-up generalization이다. low 수준으로 학습한 모델이 middle과 high 수준 테스트를 풀 수 있는지 본다. 두 번째 축은 ID top-down generalization이다. high 수준으로 학습한 모델이 middle과 low 수준으로 내려와 실행할 수 있는지 본다. 세 번째 축은 OOD multi-level generalization으로, 학습 사이트와 다른 trajectory와 다른 웹사이트에서 세 수준 모두를 평가한다. 이 세 축이 있어야 atomic skill 학습과 planning skill 학습의 차이가 명확해진다.

Figure 3: Task Decomposition Hierarchical Analysis Framework의 ID/OOD trajectory와 세 수준 task 구조.

Figure 3은 TDHAF가 왜 단순 정확도보다 많은 정보를 주는지 보여 준다. 위쪽은 같은 trajectory에서 파생한 ID 분할이고 아래쪽은 다른 trajectory와 다른 웹사이트에서 온 OOD 분할이다. 각 domain에는 low, middle, high task가 있으며, bottom-up, top-down, OOD multi-level 세 방향으로 일반화를 재조합한다. 이 구조 덕분에 “저수준을 잘하면 고수준도 되는가”라는 질문을 직접 테스트할 수 있다.

TDHAF의 분할 규칙은 아래처럼 정리된다. 표에서 L, M, H는 각각 low, middle, high 수준을 뜻한다. 같은 trajectory에서 task를 다시 쓰면 ID 평가가 되고, 다른 trajectory와 다른 웹사이트에서 가져오면 OOD 평가가 된다. 중요한 점은 top-down과 bottom-up이 대칭적이지 않다는 것이다. 논문 결과는 high-level task training이 아래 수준으로 내려오는 데 강하지만, low-level training이 위 수준 계획으로 올라가지는 못한다는 쪽에 무게를 둔다.

일반화 축	Training set	Test set	질문
ID bottom-up	Train-ID-L	Test-ID-L, Test-ID-M, Test-ID-H	atomic skill 학습이 더 긴 계획으로 올라가는가
ID bottom-up	Train-ID-M	Test-ID-M, Test-ID-H	부분 목표 학습이 고수준 task로 확장되는가
ID top-down	Train-ID-H	Test-ID-L, Test-ID-M, Test-ID-H	고수준 목표 학습이 세부 실행까지 내려오는가
OOD multi-level	Train-ID-L	Test-OOD-L, Test-OOD-M, Test-OOD-H	저수준 학습이 다른 웹사이트로 이동하는가
OOD multi-level	Train-ID-M	Test-OOD-L, Test-OOD-M, Test-OOD-H	중간 과립도 학습이 사이트 변화에 견디는가
OOD multi-level	Train-ID-H	Test-OOD-L, Test-OOD-M, Test-OOD-H	high-level planning 신호가 OOD에서도 유지되는가

WebVoyager를 쓰는 이유는 실제 웹사이트의 노이즈가 들어오기 때문이다. synthetic GUI benchmark는 action space와 element id가 깔끔하게 정의될 수 있지만, 실제 사이트는 layout 변화, 광고 영역, lazy loading, 검색 결과 편차를 포함한다. PEEU가 OOD 사이트에서 성능을 올렸다는 것은 단순한 HTML form 조작보다 어려운 조건에서 planning signal이 작동했다는 뜻이다. 다만 benchmark가 정보 탐색 중심이므로, 상태 변경이 큰 업무 자동화까지 직접 일반화한다고 보기는 어렵다.

평가 metric은 trajectory-level success rate다. 이 metric은 최종 task 성공을 직접 반영한다는 장점이 있지만, 실패한 trajectory 안에서도 어느 planning step이 잘못되었는지 자동으로 설명하지는 않는다. TDHAF가 필요한 이유가 여기에 있다. 전체 성공률이 낮아도 low-level grounding이 좋은지, middle-level subgoal 연결이 약한지, high-level decomposition이 무너지는지 분해해야 다음 데이터 생성 전략을 정할 수 있다.

비교군에 GPT-4o와 Claude 3 Opus가 들어간 것도 해석상 중요하다. PEEU는 작은 모델을 상용 frontier model 수준으로 끌어올렸다고 주장하지 않는다. 대신 작은 모델이 충분히 정렬된 경험 데이터로 더 큰 vanilla open model을 넘는 구간을 보여 준다. 이 구간은 실제 배포에서 의미가 있다. 모든 작업을 frontier API에 맡기기 어려운 조직은 제한된 domain에서 작은 모델을 훈련시켜 비용과 privacy를 조절하려 하기 때문이다.

TDHAF는 실험 설계를 분석 도구로 확장한다. 논문이 제시한 low, middle, high task는 단순 label taxonomy를 넘어, 학습 데이터 제작의 의사결정 기준으로 작동한다. 개발자가 GUI agent dataset을 만들 때 atomic click만 모을지, full trajectory만 모을지, 사용자가 말할 법한 high-level goal을 만들지 결정해야 한다. TDHAF 결과는 high-level goal을 무시한 데이터 수집이 planning 성능을 제한할 수 있음을 보여 준다.

5. 주요 실험 결과: 작은 모델이 큰 모델을 넘어서는 조건

5.1 WebVoyager OOD 성능

가장 눈에 띄는 결과는 2k trajectory 규모에서 Qwen2.5-VL-7B + PEEU-SFT가 전체 30.6% 정확도를 기록한다는 점이다. 이는 Qwen2.5-VL-32B vanilla의 22.7%, Qwen2.5-VL-72B vanilla의 29.3%보다 높다. 물론 GPT-4o 59.0%와 Claude 3 Opus 56.1%에는 한참 못 미치지만, 작은 오픈소스 모델이 학습 데이터 변환만으로 훨씬 큰 vanilla 모델을 넘어설 수 있다는 점은 실용적으로 크다. 비용과 개인정보 제약이 있는 GUI 자동화에서는 이 차이가 곧 배포 가능성으로 이어진다.

0.1k trajectory 조건에서도 패턴은 뚜렷하다. 3B 모델은 vanilla가 0.2%에 머물고, prompt retrieval 계열은 0.0%에 가까운 실패를 보인다. 반면 PEEU-GRPO는 11.1%까지 올라간다. 7B 모델에서도 vanilla 7.8%에서 PEEU-GRPO 19.9%로 오른다. 이 결과는 작은 모델이 긴 경험 prompt를 읽어 즉석에서 추론하는 것보다, 정렬된 task로 직접 훈련받을 때 더 강해진다는 논문 주장을 뒷받침한다.

사이트별로 보면 Amazon, arXiv, Coursera, Map처럼 UI와 정보 구조가 크게 다른 곳에서 개선 폭이 두드러진다. 특히 2k PEEU-SFT 7B는 Amazon 53.6%, Coursera 35.7%, Map 48.7%를 보인다. 이는 Allrecipes에서 출발한 경험이 그대로 UI를 암기한 결과라기보다, 조건 검색과 결과 선택이라는 계획 구조가 다른 사이트로 어느 정도 옮겨 갔음을 시사한다. 다만 Apple이나 Github처럼 일부 사이트에서는 큰 모델과의 간격이 남아 있어, PEEU가 모든 UI 변이를 해결한 것은 아니다.

아래 표는 WebVoyager OOD 성능에서 핵심 비교만 뽑은 것이다. 논문의 원표는 사이트별 세부 수치를 모두 담고 있지만, 여기서는 모델 크기와 학습 방식에 따른 전체 평균 변화를 중심으로 본다. PEEU가 가장 강한 지점은 같은 데이터 규모에서 coarse나 atomic training보다 높은 평균을 만든다는 점이다.

모델 / 규모	방법	Allrecipes	Amazon	arXiv	Coursera	Map	Overall
GPT-4o	Vanilla	56.3	53.7	60.5	65.1	56.9	59.0
Claude 3 Opus	Vanilla	45.9	58.6	55.0	68.2	55.3	56.1
Qwen2.5-VL-72B	Vanilla	6.6	58.5	32.5	21.4	36.5	29.3
Qwen2.5-VL-32B	Vanilla	0.0	39.0	32.5	19.0	34.1	22.7
Qwen2.5-VL-3B / 0.1k	PEEU-GRPO	6.6	24.3	23.2	7.1	0.0	11.1
Qwen2.5-VL-7B / 0.1k	PEEU-GRPO	4.4	26.8	20.9	33.3	12.1	19.9
Qwen2.5-VL-3B / 2k	PEEU-SFT	8.8	46.3	13.9	14.2	21.9	19.8
Qwen2.5-VL-7B / 2k	PEEU-SFT	17.7	53.6	25.2	35.7	48.7	30.6

5.2 Prompt retrieval보다 training이 더 강한 이유

Atomic-Prompt와 Trajectory-Prompt가 약한 결과는 GUI 에이전트 prompt engineering에 중요한 경고를 준다. 경험을 잘 모았더라도 작은 MLLM이 그 경험을 매번 prompt에서 읽고 현재 화면에 맞게 재해석할 능력이 충분하지 않으면 성능은 올라가지 않는다. 3B 모델은 prompt-based method에서 거의 0%에 머무르고, 7B에서도 일부 방식은 vanilla보다 낮다. 이는 작은 모델의 병목이 지식 부족에 더해, 긴 컨텍스트 안의 사례를 현재 계획으로 변환하는 reasoning capacity 부족과도 연결됨을 보여 준다.

반대로 PEEU-SFT와 PEEU-GRPO는 experience를 학습 데이터로 바꾼다. 모델은 inference 시점에 긴 사례를 해석하는 대신, 훈련 중에 high-level 목표와 실행 trajectory의 정렬 패턴을 반복적으로 본다. GRPO가 0.1k 조건에서 강한 이유도 여기와 맞물린다. 적은 데이터에서 모방 학습만 하면 잘못 정렬된 사례의 영향이 크지만, 성공 보상 기반 업데이트는 목표 달성 trajectory를 상대적으로 강화한다. 다만 2k 조건에서는 PEEU-SFT 7B가 30.6%로 가장 좋게 나타나, 충분히 정렬된 high-level 데이터가 쌓이면 supervised signal만으로도 큰 개선을 만들 수 있음을 보인다.

Table 1의 수치를 더 자세히 보면 PEEU의 개선은 모든 사이트에서 균등하지 않다. 7B 2k PEEU-SFT는 Amazon과 Map에서 강한 반면, Apple과 arXiv에서는 상대적으로 낮은 편이다. 이는 사이트 구조와 task type의 차이가 여전히 중요하다는 뜻이다. 쇼핑과 지도는 필터, 정렬, 위치 선택처럼 goal constraint가 비교적 명시적인 반면, Apple이나 GitHub류 사이트는 product hierarchy나 repository context를 더 길게 따라가야 할 수 있다.

3B 모델의 결과는 더 극단적이다. vanilla와 prompt 방식은 거의 작동하지 않지만, PEEU-GRPO는 일부 사이트에서 두 자리 수 성능을 만든다. 이는 3B 규모에서 inference-time retrieval을 기대하기보다, 훈련 중에 planning template를 직접 형성하는 편이 낫다는 신호다. 작은 모델은 prompt에 들어온 경험을 meta-reasoning 자료로 쓰기 어렵지만, 반복 학습된 목표-행동 mapping은 더 안정적으로 사용할 수 있다.

Coarse-GRPO와 Atomic-GRPO도 성능을 올리지만 PEEU-GRPO에는 미치지 못한다. Coarse 방식은 목표가 실제 trajectory와 느슨하게 붙는 문제가 있고, Atomic 방식은 실행 grounding에는 유리해도 복합 목표 표현이 약하다. PEEU는 둘 사이에서 trajectory가 실제로 달성한 제약을 high-level task로 다시 묶는다. 이 중간 지점이 planning generalization에 더 잘 맞았다고 볼 수 있다.

한편 GPT-4o와 Claude 3 Opus의 성능은 여전히 압도적이다. 따라서 PEEU의 실용 가치는 “frontier model을 대체했다”는 주장보다, 특정 비용·보안 조건에서 작은 모델의 baseline을 끌어올리는 데 있다. GUI 자동화 시스템을 설계할 때는 frontier model을 teacher, verifier, fallback으로 쓰고, 작은 모델을 반복 업무의 주 실행자로 쓰는 hybrid 구조가 현실적일 수 있다.

이 결과는 블로그 운영 관점에서도 흥미롭다. 최근 agent 논문들은 test-time search, memory, tool contract, runtime verification 등 inference 구조를 많이 다뤘다. PEEU는 상대적으로 data pipeline 쪽에 초점을 둔다. agent 성능을 올리는 방법이 prompt와 orchestrator에만 묶이지 않고, 경험을 어떤 과립도의 training target으로 바꾸는가에도 달려 있음을 보여 준다.

6. 추가 분석 및 Ablation Study: 과립도와 강화학습의 상호작용

6.1 Low-level skill은 high-level planning을 보장하지 않는다

TDHAF 분석의 핵심 메시지는 명확하다. low-level atomic skill을 잘한다고 해서 high-level planning이 자동으로 따라오지 않는다. 3B 모델을 low-level data로 학습하면 Test-ID-Low Step SR은 80.5%까지 올라가지만, Test-ID-High Step SR은 9.1%에 그친다. 7B 모델도 low-level 학습에서 Test-ID-Low 89.6%를 기록하지만, high-level 테스트에서는 18.8%에 머문다. 클릭, 입력, 값 선택을 잘하는 모델이 복합 목표 분해까지 잘하는 것은 별개의 문제라는 뜻이다.

이는 GUI 에이전트 평가에서 자주 생기는 착시를 줄여 준다. 액션 단위 정확도나 element grounding만 보면 모델이 많이 배운 것처럼 보일 수 있다. 그러나 실제 사용자는 “검색창을 클릭하라”보다 “조건에 맞는 결과를 찾아라”를 요구한다. high-level 목표에서는 어떤 필터를 먼저 확인할지, 중간 결과가 조건을 충족하는지, 필요한 경우 다른 상세 페이지로 넘어갈지를 결정해야 한다. TDHAF는 이 차이를 수치로 분리해 보여 준다.

아래 표는 Table 2에서 Step SR만 뽑아 과립도 효과를 읽기 쉽게 만든 것이다. 같은 base model 안에서 low, middle, high 학습 데이터가 각 테스트 과립도에 어떻게 작동하는지 비교하면, high-level training이 아래로 내려오는 top-down 일반화에서 더 안정적이라는 결론이 나온다.

모델	학습 과립도	Test-ID-Low Step SR	Test-ID-Middle Step SR	Test-ID-High Step SR	해석
3B	Low	80.5	22.7	9.1	저수준 실행은 강하지만 고수준 계획으로 상승하지 못함
3B	Middle	71.4	63.6	29.2	중간 수준은 middle에는 유리하나 high-level에는 제한적
3B	High	75.3	54.5	63.0	high-level 학습이 세 수준을 더 고르게 덮음
7B	Low	89.6	16.2	18.8	크기가 커져도 bottom-up 병목은 남음
7B	Middle	86.4	72.7	43.5	중간 과립도는 부분 계획에 강함
7B	High	83.1	63.6	72.1	고수준 계획 신호가 가장 넓은 coverage를 만듦

Figure 4: Qwen2.5-VL-3B의 generalization distribution pie chart.

Figure 4는 3B 모델에서 학습 과립도가 바뀔 때 good generalization 영역이 어떻게 변하는지 보여 준다. low-level 학습은 해당 수준 성공률을 높이지만 다른 수준으로 넓게 퍼지지 못한다. middle과 high로 올라갈수록 성공 조합의 면적이 커지고, 특히 high-level task training은 ID와 OOD 양쪽에서 더 넓은 task 조합을 덮는다. 작은 모델일수록 목표 과립도의 영향이 크게 보인다. 원형 차트가 보여 주는 것은 단일 평균 정확도보다 세밀하다. 어떤 학습 과립도가 여러 테스트 과립도를 동시에 통과하는지 보이기 때문에, atomic success가 planning coverage로 확장되는지를 한눈에 비교할 수 있다.

Figure 5: TDHAF 데이터 분포.

Figure 5는 TDHAF 데이터가 low, middle, high와 ID/OOD 조건으로 어떻게 나뉘는지 보여 준다. 이 분포가 중요한 이유는 모델이 특정 한 수준의 task만 많이 본 결과를 전체 planning 능력으로 오해하지 않도록 막아 주기 때문이다. 학습과 테스트를 같은 과립도에만 묶으면 atomic skill 향상이 과대평가될 수 있는데, TDHAF는 데이터 분할 자체에서 그 위험을 줄인다. 논문이 성능을 단일 사이트 평균으로만 보지 않고 ID와 OOD, 그리고 세 task level로 다시 나누는 이유가 여기에 있다. 이 분포는 데이터셋 구성 자체가 분석 프레임워크라는 점을 드러낸다.

6.2 High-level task training의 coverage 효과

논문은 good generalization coverage라는 관점도 사용한다. 모든 수준에서 성공하는 task 비율을 보면, 3B 모델의 ID coverage는 low-level 학습 3.2%, middle-level 22.7%, high-level 44.8%로 증가한다. 7B 모델에서도 9.1%, 36.4%, 51.9%로 같은 방향이다. OOD에서도 3B는 high-level 33.8%, 7B는 high-level 37.8%로 가장 높다. 숫자 차이는 크지만 결론은 일관된다. 고수준 목표를 정렬해 학습시키면 모델이 더 낮은 실행 수준까지 상대적으로 잘 포괄한다.

이 결과는 “상위 목표를 잘 쓰면 하위 실행이 자연히 된다”는 단순 낙관으로 읽으면 곤란하다. high-level training도 low-level action supervision을 완전히 대체하지는 않는다. 실제 표에서 high-level 학습의 low-level Step SR이 항상 최고는 아니다. 다만 제품 관점에서 중요한 것은 한 수준의 만점보다 여러 수준을 함께 견디는 coverage다. 실제 사용자 요청은 high-level로 들어오고, 실행은 low-level action으로 나가기 때문에 양쪽을 연결하는 task representation이 필요하다.

모델	평가 domain	Low 학습 coverage	Middle 학습 coverage	High 학습 coverage	핵심 해석
3B	ID	3.2%	22.7%	44.8%	high-level task가 같은 사이트 내 세 수준 성공 조합을 가장 넓힘
7B	ID	9.1%	36.4%	51.9%	모델이 커져도 high-level coverage 우위가 유지됨
3B	OOD	18.9%	24.3%	33.8%	다른 웹사이트에서도 high-level 학습이 가장 안정적
7B	OOD	25.7%	29.7%	37.8%	OOD에서는 격차가 줄지만 방향은 동일함

Figure 6: Qwen2.5-VL-7B의 generalization distribution pie chart.

Figure 6은 7B 모델에서도 3B와 같은 방향의 패턴이 나타난다는 점을 확인한다. 모델 크기가 커지면 일부 low-level 성공률은 높아지지만, high-level task training의 coverage 이점은 사라지지 않는다. 이는 PEEU의 효과가 단순히 작은 모델의 결함 보정에 그치지 않고, 웹 task decomposition 자체의 구조와 관련된다는 해석을 가능하게 한다. 7B에서도 high-level 조건의 면적이 커지는 패턴은 유지되며, 이는 capacity 증가만으로 bottom-up 일반화가 해결되지 않는다는 해석을 강화한다. planning task의 표현 방식이 모델 크기와 별개의 축으로 작동한다.

6.3 GRPO reward와 적은 데이터 조건

0.1k trajectory 조건에서 GRPO가 강하게 작동한 점도 눈여겨볼 만하다. 3B 모델은 PEEU-SFT가 5.7%, PEEU-GRPO가 11.1%이고, 7B 모델은 PEEU-SFT 15.6%, PEEU-GRPO 19.9%다. 적은 데이터에서는 supervised target만으로는 trajectory noise와 목표 불일치를 충분히 상쇄하기 어렵다. GRPO는 rollout 결과를 통해 더 성공적인 action sequence를 상대적으로 강화하므로, 정렬된 high-level task가 적을 때 보완 역할을 한다.

반면 2k trajectory에서는 논문 표가 PEEU-SFT 결과를 중심으로 제시하고, 7B에서 30.6%까지 오른다. 이는 데이터가 충분히 늘면 hindsight로 정렬한 high-level task 자체가 강한 지도 신호가 된다는 뜻이다. 실제 운영에서 이 차이는 중요하다. 많은 rollout과 reward 계산을 감당하기 어려운 환경에서는 먼저 PEEU-SFT를 구축하고, 데이터가 부족하거나 목표 달성 기준이 명확한 task에는 GRPO를 추가하는 전략이 합리적일 수 있다.

Figure 7: GRPO 학습에서 사용되는 reward 구성.

Figure 7은 RL training reward의 구성 요소를 보여 준다. GUI 에이전트 보상은 최종 성공 여부만으로는 너무 희소해지기 쉬워, action 형식, element 선택, 값 입력, step-level 성공 같은 중간 신호가 필요하다. 이 그림은 PEEU가 단순 데이터 합성 논문에 그치지 않고, 정렬된 high-level task를 실제 policy optimization으로 연결하려는 설계를 갖고 있음을 보여 준다. 특히 reward가 최종 answer correctness에만 묶이지 않고 action format과 step-level execution에도 닿아야 긴 웹 task의 credit assignment가 가능하다. PEEU task는 이 reward가 평가할 수 있는 구체적 목표를 제공한다.

Ablation을 읽을 때 주의할 점은 Step SR과 coverage가 서로 다른 질문에 답한다는 것이다. Step SR은 특정 test split에서 action sequence가 성공했는지를 본다. Coverage는 여러 level 조합을 동시에 성공하는 비율에 더 가깝다. low-level 학습은 특정 low-level Step SR을 높일 수 있지만, coverage에서는 약할 수 있다. 사용자의 실제 요청은 대부분 high-level로 들어오므로, 운영 관점에서는 coverage가 더 민감한 지표가 된다.

High-level task training이 좋은 이유는 모델에게 subgoal ordering을 함께 보여 주기 때문이다. low-level task는 개별 action의 correctness를 강조한다. middle-level task는 몇 개 action을 묶지만 전체 목표 조건까지는 약할 수 있다. high-level task는 “조건을 확인하고 필요한 정보를 찾아 최종 답을 만든다”는 긴 dependency를 포함한다. 작은 모델이 이 dependency를 여러 번 보면, 다른 사이트에서도 어떤 정보가 아직 확인되지 않았는지 추적하는 prior가 생긴다.

그렇다고 high-level 데이터만 모으면 된다는 결론도 조심해야 한다. 실제 GUI agent는 element grounding이 약하면 고수준 계획을 세워도 클릭에서 실패한다. PEEU가 잘 작동한 것은 high-level task가 exploration trajectory와 연결되어 있어, 목표 문장만 떠 있는 데이터가 아니었기 때문이다. 즉 좋은 high-level 데이터는 반드시 관찰 상태, history, action과 함께 묶여야 한다. 단순 goal list는 같은 효과를 내기 어렵다.

Figure 4와 Figure 6의 pie chart는 이런 해석을 시각적으로 돕는다. low-level 학습에서 특정 조각이 커질 수는 있지만, all-level success에 해당하는 good generalization 영역은 제한적이다. high-level 학습은 일부 세부 step에서 최고가 아니어도 전체 면적을 넓힌다. 이것이 제품형 agent에서 더 중요한 성질이다. 사용자는 한 단계 성공보다 task completion을 원한다.

GRPO reward 그림은 또 다른 설계점을 암시한다. GUI agent reward는 final answer matching만으로는 희소하고, action-level exact match만으로는 계획을 보지 못한다. 따라서 step format, element id, value match, trajectory success를 적절히 섞는 reward shaping이 필요하다. PEEU가 만든 정렬 task는 이런 reward가 무엇을 평가해야 하는지 더 명확하게 만든다.

7. 한계점 및 향후 연구 방향: 실제 웹 운영으로 가기 전 남은 공백

논문이 명시한 한계는 평가 범위다. 현재 실험은 정보 탐색과 navigation 중심의 웹사이트를 다루며, 로그인, CAPTCHA, 실제 결제, 개인정보 입력처럼 민감한 operation은 포함하지 않는다. 이는 안전상 타당한 선택이지만, 실제 GUI 에이전트 배포에서 가장 어려운 부분이 빠져 있다는 뜻이기도 하다. 특히 쇼핑, 금융, 업무 시스템에서는 목표 달성 여부가 단순 페이지 도착보다 권한, 인증, 취소 가능성, 사용자 확인 절차와 얽힌다.

또 다른 한계는 exploration agent와 summarizer의 품질 의존성이다. PEEU는 GPT-4o를 사용해 browser state 변화와 경험을 요약한다. 이 상위 모델이 잘못된 경험을 추출하거나 중요한 제약을 빠뜨리면, 작은 모델은 그 오류를 학습하게 된다. 논문은 작은 오픈소스 MLLM을 강화하는 것을 목표로 하지만, 데이터 생성 단계에는 여전히 강한 모델과 환경 접근이 필요하다. 따라서 완전한 open pipeline으로 보려면, experience extraction 자체를 어떻게 검증하고 self-correct할지 추가 연구가 필요하다.

TDHAF 역시 강력한 분석틀이지만, task granularity를 세 수준으로 나누는 방식이 모든 웹 task에 자연스럽게 적용되는지는 더 확인해야 한다. 예를 들어 문서 편집, spreadsheet 조작, 멀티탭 리서치, 장기 account setting 변경 같은 작업은 low-middle-high보다 dependency graph나 permission boundary가 더 중요한 축일 수 있다. PEEU의 high-level task training이 이런 장기 workflow에서도 같은 coverage 이점을 보일지 아직은 열린 질문이다.

향후 연구 방향은 세 갈래로 보인다. 첫째, PEEU task의 자동 품질 검증이다. 목표-trajectory 정렬이 맞는지 별도 verifier가 확인해야 한다. 둘째, 민감 행동에 대한 human confirmation boundary를 학습 데이터에 포함하는 것이다. 에이전트가 계획을 세우더라도 결제, 삭제, 전송 전에는 반드시 멈춰야 한다. 셋째, VISUALSKILL 같은 시각 증거 기반 skill memory와 PEEU post-training을 결합하는 것이다. 화면 증거를 저장하고, 그 증거에서 훈련 task를 만들고, 다시 실행 로그로 검증하는 폐루프가 필요하다.

실제 서비스로 옮길 때 첫 번째 과제는 안전한 exploration이다. PEEU는 사이트를 자유롭게 탐색한다고 설명하지만, 운영 환경에서는 탐색 action에도 권한 경계가 필요하다. 검색, 필터, 페이지 이동은 허용할 수 있어도 주문, 제출, 삭제, 메시지 전송은 사용자의 명시 확인 없이는 금지되어야 한다. 따라서 PEEU를 민감 도메인에 적용하려면 exploration policy 자체에 allowlist와 stop rule을 넣어야 한다.

두 번째 과제는 데이터 freshness다. 웹사이트 UI는 자주 바뀐다. 오늘 추출한 experience가 한 달 뒤에도 맞는다는 보장이 없다. PEEU task가 특정 사이트의 오래된 UI 제약을 모델에 학습시키면, 이후에는 오히려 잘못된 prior가 될 수 있다. 이를 막으려면 학습 데이터에 collection date와 site version 정보를 넣고, periodic re-exploration 또는 failure-triggered refresh를 운영해야 한다.

세 번째 과제는 multilingual GUI다. 논문 평가 사이트는 주로 영어 웹 환경을 전제로 하지만, 실제 사용자는 한국어 쇼핑몰, 일본어 예약 사이트, 중국어 교육 플랫폼을 다룰 수 있다. 버튼 텍스트와 정보 구조가 언어별로 달라지면 atomic experience extraction prompt도 영향을 받는다. PEEU를 다국어 환경으로 확장하려면 화면 OCR, 번역, element semantics를 함께 검증해야 한다.

네 번째 과제는 verifier 비용이다. PEEU가 강력한 teacher model을 사용해 경험을 추출한다면 데이터 제작 비용이 완전히 사라지는 것은 아니다. 다만 teacher가 모든 inference를 직접 수행하는 것보다, 주기적으로 경험을 추출해 작은 모델을 업데이트하는 방식은 장기적으로 비용을 줄일 수 있다. 핵심은 teacher call을 어느 단계에 집중할지 정하는 것이다. 논문은 그 위치를 exploration summarization과 task rewriting에 둔다.

마지막으로, TDHAF를 다른 도메인에 옮기려면 과립도 정의를 재설계해야 한다. 모바일 앱에서는 screen transition과 permission prompt가 중요하고, desktop automation에서는 file state와 application focus가 중요하다. low-middle-high만으로 충분하지 않을 수 있다. 하지만 task를 한 가지 평균 성공률로 보지 않고 decomposition level별로 나눠야 한다는 원칙은 유지될 가능성이 높다.

8. 내 해석: GUI 에이전트 학습 데이터를 보는 한 가지 기준

나는 이 논문에서 가장 설득력 있는 부분이 “작은 모델은 atomic skill만 많이 배워도 planning이 생긴다”는 기대를 수치로 꺾은 지점이라고 본다. 실제 서비스에서 GUI 에이전트 실패를 보면 클릭 자체를 못해서 죽는 경우도 있지만, 더 자주 보이는 것은 목표의 조건을 중간 화면에서 잊거나, 검색 결과를 확인하지 않고 첫 번째 항목을 고정하거나, 사이트가 바뀌었을 때 같은 절차를 반복하는 문제다. TDHAF의 bottom-up 결과는 이 경험과 잘 맞는다. low-level 성공률이 높아져도 high-level Step SR이 낮게 남는다는 것은, action grounding과 planning decomposition을 별도 학습 목표로 설계해야 함을 말한다.

다만 약점도 분명하다. PEEU는 high-level task를 더 엄격하게 정렬한다고 설명하지만, 그 정렬 품질이 어느 정도로 안정적인지 독립 감사하는 실험은 상대적으로 약하다. 예를 들어 GPT-4o가 추출한 atomic experience 중 얼마나 많은 비율이 실제 UI 변화와 정확히 대응하는지, aggregation prompt가 원래 trajectory에서 달성하지 못한 조건을 과도하게 보존하는지, 웹사이트별로 어떤 유형의 제약을 자주 누락하는지까지 정량화되면 주장이 더 강해졌을 것이다. 내가 이 방법을 확장한다면 PEEU task마다 provenance trace를 붙이고, task 문장의 각 조건이 어떤 screenshot transition에서 왔는지 자동으로 역추적하는 verifier를 먼저 만들 것 같다.

이전에 리뷰한 VISUALSKILL과 연결해 보면 후속 방향이 더 뚜렷하다. VISUALSKILL은 GUI agent skill을 문서화할 때 screenshot evidence를 함께 저장해, 에이전트가 텍스트 절차만 외우지 않도록 했다. PEEU는 탐색 경험을 high-level training task로 바꾼다. 두 접근을 합치면 “스킬 문서 → 탐색 trajectory → hindsight task → post-training → 실패 trace로 스킬 갱신”이라는 순환 구조를 만들 수 있다. 이 순환이 생기면 GUI 에이전트는 한 번의 학습 데이터셋으로 고정되는 대신, 사이트 변화와 실패 사례를 계속 흡수하는 운영형 학습 시스템에 가까워진다.

PEEU를 운영 pipeline으로 옮기면 데이터 artifact가 여러 층으로 생긴다. 첫째는 raw browser trace다. 여기에는 screenshot, action, observation, timestamp, URL, scroll state가 들어간다. 둘째는 atomic experience다. 여기에는 전후 화면 변화와 element 의미가 들어간다. 셋째는 aggregated high-level task다. 여기에는 사용자가 실제로 요구할 법한 목표와 사이트에서 확인된 제약이 들어간다. 넷째는 training example이다. 여기에는 상태, history, task, 다음 action이 묶인다. 이 층을 분리해야 어느 지점에서 오류가 들어왔는지 나중에 추적할 수 있다.

논문은 이 artifact lineage를 완전한 감사 시스템으로 만들지는 않았지만, 구조상 그 가능성을 남긴다. 예를 들어 high-level task에 “20분 이하 preparation time”이라는 조건이 들어갔다면, 해당 조건이 어떤 screenshot transition에서 등장했는지 역링크를 붙일 수 있다. 이후 모델이 그 조건을 무시하고 다른 레시피를 선택하면, 실패 분석은 task wording 문제인지, visual grounding 문제인지, action policy 문제인지 나눠 볼 수 있다. provenance-aware training으로 확장하기 좋은 설계다.

데이터 품질 관점에서는 negative evidence도 중요하다. 웹 탐색 중 어떤 필터가 없는지, 어떤 페이지가 조건을 제공하지 않는지, 어떤 클릭이 같은 결과만 반복하는지도 planning에는 유용하다. 현재 PEEU는 의미 있는 UI 변화와 달성된 constraint를 중심으로 경험을 만든다. 다음 단계에서는 실패한 branch나 dead-end transition을 별도 experience로 저장해, 모델이 불필요한 탐색을 줄이도록 학습시킬 수 있다. 이는 long-horizon 웹 task의 비용을 줄이는 데 직접 연결된다.

TDHAF를 학습 curriculum으로 쓰는 방법도 생각할 수 있다. 처음에는 low-level grounding data로 element 선택을 안정화하고, 이후 middle-level subgoal data로 작은 절차를 연결하며, 마지막에 PEEU high-level task로 목표 분해를 강화하는 식이다. 논문 결과는 high-level이 coverage에 유리하다고 말하지만, 실제 학습은 모든 수준을 적절히 섞는 curriculum이 더 안정적일 가능성이 있다. granularity curriculum은 PEEU의 자연스러운 후속 실험이다.

또한 reward 설계는 task level별로 달라져야 한다. low-level task에서는 element id와 action type이 강한 보상이 될 수 있다. middle-level task에서는 부분 목표 완료와 상태 변화가 더 중요하다. high-level task에서는 최종 조건 만족, 불필요한 step 수, 잘못된 중간 선택 회피가 함께 들어가야 한다. 하나의 reward로 모든 과립도를 평가하면, 모델이 특정 수준에 과적합할 수 있다. TDHAF는 reward shaping을 level별로 점검하는 데도 쓸 수 있다.

실제 제품팀이 이 논문을 적용한다면 처음부터 대규모 웹 전체를 탐색하기보다, 반복 사용 빈도가 높은 내부 업무 20~50개를 골라 PEEU loop를 작게 시작하는 편이 좋다. 예를 들어 고객 관리 dashboard에서 검색, 필터, 상세 확인, 상태 변경 전 확인 단계까지를 대상으로 삼을 수 있다. 성공·실패 trace를 모아 high-level task를 만들고, 사용자 확인이 필요한 action은 항상 stop action으로 라벨링한다. 이렇게 하면 안전 경계를 유지하면서도 planning data를 축적할 수 있다.

블로그 독자 입장에서 특히 볼 만한 포인트는 표와 그림이 서로 보완된다는 점이다. Table 1은 최종 OOD 성능을 보여 주고, Table 2와 coverage 수치는 왜 그런 성능이 나왔는지 설명한다. Figure 2는 데이터 변환 pipeline을, Figure 3은 분석 framework를, Figure 4와 6은 granularity별 success distribution을 보여 준다. 따라서 이 논문은 결과표 하나만 보고 넘기기보다, “데이터 생성 방식과 평가 분해 방식이 서로 맞물린다”는 구조로 읽어야 한다.

PEEU가 제안하는 high-level task는 일반 instruction tuning 데이터와도 다르다. 일반 instruction tuning은 텍스트 지시와 응답을 맞추는 경우가 많지만, GUI task는 지시가 화면 상태와 직접 연결된다. 같은 문장이라도 현재 화면에 필터가 열려 있는지, 검색 결과가 로딩됐는지, 상세 페이지인지에 따라 다음 action이 달라진다. 그래서 training example에는 task text만이 아니라 visual state와 interaction history가 반드시 함께 있어야 한다.

마지막으로, 이 논문은 작은 모델의 한계를 비관적으로 보지 않는다는 점에서도 의미가 있다. 3B와 7B 모델은 vanilla 상태에서는 약하지만, 경험을 정렬해 주면 일정 수준의 웹 planning을 배운다. 이때 중요한 것은 model scaling만 반복하는 것이 아니라, 작은 모델이 처리할 수 있는 supervision boundary를 맞추는 일이다. 경험을 raw log로 던져 주는 대신, 화면에서 확인된 제약과 목표를 결합한 task로 바꾸는 작업이 그 boundary를 만든다.

운영 로그를 쌓는 방식에서도 PEEU는 쓸모가 있다. 많은 팀은 에이전트 실패를 “모델이 틀렸다” 정도로 기록하고 넘어간다. 그러나 PEEU식으로 trace를 보면 실패가 탐색 목표 생성 단계에서 생겼는지, 화면 변화 요약에서 생겼는지, high-level task 재작성에서 생겼는지, action policy에서 생겼는지 나눌 수 있다. 이 구분은 다음 iteration의 비용을 줄인다. 실패가 목표 재작성 문제라면 모델을 다시 훈련하기 전에 prompt와 verifier를 고쳐야 하고, action policy 문제라면 더 많은 state-action supervision이 필요하다.

또한 PEEU는 synthetic data 생성과 real interaction data 사이의 균형을 잡는 방법으로 볼 수 있다. 완전히 synthetic task만 만들면 웹사이트 내부 제약이 빠지고, 실제 trajectory만 그대로 쓰면 목표 불일치와 잡음이 남는다. PEEU는 real interaction에서 나온 제약을 사용하되, task 문장은 모델이 배우기 좋은 high-level instruction으로 다시 정제한다. 이 조합이 작은 MLLM에게는 특히 중요하다. 작은 모델은 잡음 많은 긴 trajectory를 스스로 정리할 여력이 적기 때문에, 학습 전에 데이터가 충분히 구조화되어야 한다.

논문이 ACL 2026 Main에 채택된 것도 이 맥락에서 이해할 수 있다. 웹 GUI 에이전트는 vision-language modeling, planning, reinforcement learning, data generation이 겹치는 영역이다. PEEU는 새 benchmark를 하나 더 만드는 데 그치지 않고, 데이터 생성 방법과 분석 프레임워크를 함께 제시한다. 그래서 단일 숫자 개선보다 “어떤 과립도의 task가 어떤 일반화를 만든다”는 질문을 논문 안에 남겼다. 이 질문은 후속 GUI agent 연구에서 계속 재사용될 가능성이 높다.

마지막으로 데이터 재사용성 관점에서 PEEU는 한 사이트에서 얻은 경험을 다른 사이트로 옮길 때 무엇을 남겨야 하는지 알려 준다. 좌표와 DOM 구조는 오래가지 않지만, 목표 조건을 확인하는 순서, 필터와 결과를 대조하는 절차, 중간 상태를 검산한 뒤 다음 action을 고르는 패턴은 비교적 오래간다. 이 패턴이 바로 planning abstraction이다. 논문 결과에서 high-level task training이 OOD coverage를 넓힌 것은, 모델이 특정 UI의 모양보다 이런 추상 절차를 더 많이 보았기 때문으로 해석할 수 있다.

따라서 이 논문은 GUI 에이전트를 만들 때 데이터 수집, 경험 요약, 과제 재작성, 정책 학습을 하나의 연속된 품질 관리 문제로 다루어야 함을 보여 준다.

9. 결론: 경험 정렬이 계획 성능으로 이어지는 경로

이 논문은 GUI 에이전트 성능을 모델 크기 경쟁으로만 보지 않는다. 작은 MLLM이 약한 이유를 계획 경험의 부재와 목표-trajectory 불일치에서 찾고, 탐색 경험을 사후적으로 재작성해 high-level task training으로 연결한다. 결과적으로 PEEU는 Qwen2.5-VL-7B를 2k trajectory 조건에서 30.6%까지 끌어올려, 훨씬 큰 Qwen2.5-VL-32B와 72B vanilla 기준선을 넘어서는 사례를 만든다.

분석적으로 더 중요한 성과는 TDHAF다. 논문은 low-level, middle-level, high-level task를 분리하고 bottom-up, top-down, OOD multi-level 일반화를 따로 본다. 이 틀을 통해 atomic skill 학습이 high-level planning으로 충분히 올라가지 않는다는 점, high-level task training이 더 넓은 coverage를 만든다는 점을 보여 준다. GUI 에이전트 학습 데이터 설계에서 “어떤 행동을 많이 보여 줄 것인가”보다 “어떤 수준의 목표를 어떤 경험 근거와 함께 보여 줄 것인가”가 중요하다는 메시지가 남는다.

실무적으로는 PEEU가 곧바로 모든 웹 자동화를 해결하지는 못한다. 민감 행동, 로그인, 장기 workflow, verifier 없는 experience extraction은 여전히 과제다. 그럼에도 이 논문은 작은 오픈소스 GUI 에이전트를 실제로 키우려는 팀에게 유용한 설계 기준을 준다. 먼저 탐색하게 하고, 실제로 드러난 제약을 경험으로 추출하고, 원래 목표와 trajectory를 맞춘 뒤, 고수준 계획 task로 훈련시켜야 한다. 이 순서가 지켜질 때 작은 모델도 웹사이트 변화에 조금 더 강한 planning policy를 배울 수 있다.

PEEU의 기여를 한 문장으로 줄이면, “웹 탐색 경험을 작은 MLLM이 배울 수 있는 high-level planning data로 재가공했다”라고 할 수 있다. 이 재가공은 단순 paraphrase가 아니다. trajectory가 실제로 보여 준 조건, 화면 변화, 성공 또는 부분 성공 결과를 보고 목표를 다시 붙인다. 그래서 같은 경험이라도 raw log, prompt memory, training task라는 세 가지 형태 중 어떤 형태로 쓰느냐에 따라 모델 성능이 달라진다.

블로그에서 다루어 온 agent 연구들과 나란히 놓으면, PEEU는 agent data engineering의 중요성을 잘 보여 준다. LedgerAgent가 상태 변경을 schema로 고정하고, VISUALSKILL이 화면 증거를 skill에 붙이고, TRACE류 연구가 runtime rule을 컴파일한다면, PEEU는 탐색 경험을 post-training task로 고정한다. 모두 agent를 “한 번 답하는 모델”로 제한하지 않고, 실행 환경과 artifact를 함께 관리해야 하는 시스템으로 본다는 공통점이 있다.

향후에는 이 방법이 automatic curriculum과 결합될 가능성이 있다. 모델이 어느 task level에서 실패하는지 TDHAF로 진단하고, 부족한 과립도의 PEEU task를 더 생성해 다음 round training에 넣는 식이다. 이렇게 하면 데이터 수집이 무작위로 늘어나는 대신, planning failure mode별로 targeted refresh가 가능해진다. 작은 GUI 에이전트를 꾸준히 개선하려면 이런 진단-탐색-재학습 루프가 필요하다.

10. 요약 정리

• PEEU는 GUI 에이전트가 URL에서 스스로 탐색 목표를 만들고, 실제 화면 전이를 바탕으로 경험을 추출한 뒤, high-level training task로 재작성하는 방법이다.
• 논문은 작은 오픈소스 MLLM의 약점을 단순 모델 크기 문제에 묶지 않고 planning experience와 목표-trajectory 정렬 문제로 정의한다.
• 0.1k trajectory 조건에서 PEEU-GRPO는 Qwen2.5-VL-3B를 11.1%, 7B를 19.9%까지 끌어올려 prompt retrieval 방식보다 훨씬 강한 결과를 낸다.
• 2k trajectory 조건에서 Qwen2.5-VL-7B + PEEU-SFT는 WebVoyager OOD 평균 30.6%를 기록해 Qwen2.5-VL-32B와 72B vanilla 기준선을 넘어선다.
• TDHAF는 low, middle, high task와 ID/OOD 분할을 조합해 bottom-up, top-down, OOD multi-level planning 일반화를 분해해 평가한다.
• 실험은 low-level atomic skill 학습이 high-level planning을 보장하지 않으며, high-level task training이 더 넓은 coverage를 만든다는 점을 보여 준다.
• 이 논문은 VISUALSKILL 같은 시각 증거 기반 GUI agent memory 연구와 연결되며, screenshot evidence를 post-training task로 바꾸는 다음 단계의 설계를 암시한다.
• 한계는 로그인, CAPTCHA, 결제 같은 민감 조작이 평가에서 빠져 있고, experience extraction 품질이 GPT-4o 요약과 prompt 설계에 크게 의존한다는 점이다.
• 실제 적용에서는 PEEU task마다 provenance trace와 verifier를 붙여, 학습 목표의 각 조건이 어떤 화면 변화에서 왔는지 확인하는 장치가 필요하다.