ReTrace로 컴퓨터 사용 에이전트의 복구 능력을 측정한다

무엇인가

이 논문은 컴퓨터 사용 에이전트가 긴 작업에서 초반 실수를 이후 단계로 전파하고, 실행한 행동이 사용자가 원치 않는 부작용을 남기는 문제를 다룬다. 기존 대응은 환경 초기화, 전체 행동 재생, 웹 API 기반 되돌리기에 치우쳐 있었고, 운영 환경에서는 초기화가 불가능하거나 재생 비용이 커지며 데스크톱까지 포괄하기 어렵다. 저자들은 그래서 에이전트 스스로 이전 상태를 복원하는 모델 수준 복구가 필수 능력인데도 체계적으로 연구되지 않았다고 보고, 복구가 필요한 이유, 현재 에이전트가 복구 능력을 갖는지, 정확한 복구가 실제 작업 성공으로 이어지는지를 묻는다.

어떻게 동작하나

제안하는 ReTrace는 복구 성공을 전이 일관성 복구로 형식화한다. 상태를 은닉 구성요소와 관측으로 나누고, 화면이 같아 보여도 설정 파일 같은 은닉 상태가 달라질 수 있으므로 픽셀 유사도만으로 복구 성공을 판정하지 않는다. 대신 복구된 상태와 목표 상태에서 동일한 후속 행동을 실행했을 때 같은 결과가 나오는지를 본다. 이를 목표 지향 행동 재생으로 운영해, 원래 궤적의 남은 행동을 복구된 상태에서 재생해 원래 작업 결과가 재현되는지 확인한다. 관측 수준 일치도 함께 요구해 화면 자체가 목표와 어긋나는 경우를 걸러낸다.

무엇과 다른가

평가 파이프라인은 세 단계다. 먼저 각 정책을 실제로 굴려 성공한 온폴리시 궤적을 모으고, 같은 행동 시퀀스를 N번 재생해 N번 모두 성공한 경우만 남겨 결정론적 전이에 가까운 데이터셋을 만든다. 다음으로 중간 상태를 목표로 삼고, 오류 주입 정책으로 궤적을 오류 상태로 표류시킨 뒤 LLM 검증기와 작업 오라클로 실제 오류 상태임을 확인한다. 마지막으로 오류 상태에서 복구 정책이 최대 r스텝 동안 행동하고, 원래 궤적의 남은 행동을 재생해 작업 오라클이 성공을 내는지 측정한다. 복구 정책은 전방 정책을 그대로 쓰는 암시적 복구와, 목표 관측·복구 문맥·행동 이력을 받는 별도 명시적 복구로 나뉜다. 실험 설정은 짧은 지평에서 복구 거리 1, 긴 지평에서 5를 쓰고 복구 스텝 예산은 1, 3, 10으로 바꾼다.

어떻게 쓰나

실험은 OSWorld와 WindowsAgentArena에서 Claude Sonnet 4.6, GPT-5.4-Computer-Use, EvoCUA-32B, UI-TARS-1.5-7B, Qwen3.5-9B-Thinking을 대상으로 했다. 사전 실험에서 EvoCUA-32B의 OSWorld 실패 과제를 대상으로 초기 상태 재시작, 오류 직전, 무작위 과거, LLM이 고른 복구 지점을 비교했고, 모든 비영점 복구 전략이 전체 환경 초기화보다 나았으며 재시도 예산이 작을수록 격차가 컸다. 본 실험에서는 가장 강한 모델들도 복구 능력이 제한적이었고, EvoCUA-32B는 평균 복구율이 1% 미만이었다. 명시적 모델 기반 복구는 암시적 복구보다 리눅스와 윈도우 환경에서 평균 17.86%p 높은 성과를 냈고, 복구 성공은 10배 이상으로 뛰었다. 일반 목적 에이전트에서 개선이 컸고, 전방 작업 완료 궤적으로 많이 후속 학습된 전문 에이전트에서는 개선이 작았다. 사람 평가에서도 ReTrace의 복구 판정은 이미지 매칭만 쓰거나 전이 일관성만 쓰는 절제 실험, GPT-5.4보다 사람 판단과 더 자주 일치했고, 평가자 간 일치도는 82%, 코헨 카파는 0.45였다.

전제와 한계

종단 평가에서는 Qwen3.5-9B가 모델 기반 복구를 적용한 모든 설정에서 복구 없음보다 평균 2.12% 향상했다. 복구 성공률이 아직 낮은데도 얻은 이득이라, 불완전한 복구도 잠재 능력을 일부 끌어낸다고 저자들은 해석한다. 반면 복구 능력이 약한 UI-TARS-1.5-7B와 EvoCUA-32B는 종단 추론에서 성능이 오히려 떨어졌다. 복구 시도 횟수를 늘리면 Qwen3.5-9B와 UI-TARS-1.5-7B에는 추가 이득이 있었지만, EvoCUA-32B는 시도가 늘수록 궤적을 더 오류 쪽으로 밀어냈다. 질적 분석은 두 실패 유형을 든다. 하나는 복구된 화면에서 커서가 우연히 올라가 있는 정렬 버튼을 보고 먼저 해야 할 텍스트 드래그를 건너뛰는 허위 지각이고, 다른 하나는 터미널에 가려져 사라진 폰트 선택 UI가 아직 열려 있다고 착각하는 상태 추적 실패다.

개발자에게 이 논문의 핵심은 GUI 에이전트의 복구를 전방 정책이 알아서 해주리라고 가정하지 말라는 점이다. 복구는 별도 명시적 모듈로 두고 목표 상태의 관측뿐 아니라 은닉 상태를 복원할 문맥을 유지해야 하며, 성공 판정은 스크린샷 비교가 아니라 후속 행동 재생으로 확인하는 편이 안전하다. 또한 성공 궤적만으로 후속 학습을 하면 복구 성향이 약해질 수 있으므로, 오류 상태와 목표 상태, 교정 행동을 포함한 복구 인지 학습 데이터가 필요하다. 재시도 예산을 무작정 늘리는 것도 위험하다. 복구 품질이 낮은 모델은 추가 시도가 궤적을 더 망칠 수 있어, 복구 성공을 먼저 검증하고 계속 진행할지 결정하는 가드레일이 필요하다.

저자들이 밝힌 한계는 분명하다. ReTrace는 복구 능력을 측정하고 분석하는 프레임워크이지 복구 능력 자체를 직접 개선하지 않는다. 명시적 복구 설정도 모델에 이미 있는 능력을 끌어내는 수준이며, GUI 이해나 상태 추적, 행동 계획의 근본 결함을 보상하지 못한다. 복구 능력이 약한 전문 에이전트가 부정확하게 복구하면 추가적인 궤적 표류와 작업 성공률 하락을 유발할 수 있다. 향후 방향으로는 오류 상태와 목표 상태, 교정 궤적을 활용한 복구 인지 후속 학습, 은닉 환경 상태 추적과 행동 유발 전이 예측 보조 목표를 제안한다. 실험은 공개 벤치마크를 쓰는 샌드박스 가상 환경에서 수행됐고 실제 사용자 계정이나 개인 데이터와 상호작용하지 않았다.