컴퓨터 사용 에이전트의 성능을 올리는 통상적 방법은 “더 잘 보게 만드는 것”이다. StateAct는 정반대로 접근한다: 스크린샷은 버리고, 프로그램의 내부 상태(files, DOM, application backends)에 직접 코드로 접근하라. Salesforce AI Research가 발표한 이 하네스는 Claude Opus 4.8을 OSWorld 2.0에서 20.6% → 26.9% 바이너리 성공률로 끌어올리며, 동일 모델의 스크린샷 기반 베이스라인을 비용은 9배 적게, 성능은 더 높게 압도한다.
핵심 통찰: 스크린샷은 손실 압축이다
StateAct의 출발점은 단순하지만 날카롭다. 데스크톱 작업의 진짜 산출물은 “화면에 보이는 것”이 아니라 “프로그램 상태(state)의 변화”다.
- 스프레드시트 셀이 화면에
42를 표시할 때, 그것이 리터럴42인지 수식=SUM(B1:B6)의 결과인지 스크린샷만으로는 알 수 없다 - 숨겨진 행이나 화면 밖의 데이터는 렌더링되지 않는다
- 파일이 제대로 저장되었는지, 올바른 경로에 저장되었는지 화면만 보고 판단할 수 없다
형식적으로, 렌더링 함수 f_render(s)는 단사 함수(injective)가 아니다. 서로 다른 상태가 같은 픽셀을 만들어낸다. 따라서 어떤 완벽한 인식 모델도 픽셀만으로 원래 상태 s를 복원할 수 없다. 반면 코드 기반 상태 채널(load_workbook(...)["B7"].value)은 정확한 값을 직접 읽어온다.
이 손실은 한 번에는 무해해 보이지만, 긴 호라이즌 작업에서는 치명적으로 누적된다. 수백 단계의 의존적 연산에서 매 단계 작은 오읽기가 쌓이면 최종 결과물이 어긋난다. StateAct는 바로 이 지점을 공략한다.
StateAct 아키텍처: 코드가 주도하고, GUI는 예외다
StateAct는 세 가지 핵심 컴포넌트로 구성된다:
1. 상태 기반 행동 (State-Grounded Action)
메인 에이전트의 행동 공간은 코드와 구조적 조작이다: 지속적인 bash 세션, 파일 에디터, view_image(읽기 전용), 계획 체크리스트, finish 액션, 그리고 에이전트 위임 도구. 마우스나 키보드 같은 직접적인 화면 조작은 메인 에이전트에게 노출되지 않는다.
GUI 조작이 필요할 때는 전용 GUI 서브에이전트에게 위임한다. 이 서브에이전트는 108개 작업 중 단 28개, 메인 에이전트 스텝의 1.1%에서만 호출된다. 브라우저 작업도 전용 웹 서브에이전트가 담당하는데, 이 역시 스크린샷이 아닌 DOM 직렬화와 CSS 셀렉터로 그라운딩한다.
상태 발견(State Discovery) 과정이 흥미롭다. 에이전트는 모델의 사전 지식(“메일은 보통 sqlite DB에 저장된다”, “엑셀은 OOXML 포맷이다”)과 능동적 탐색(find, ls, grep, sqlite3)을 결합하여 어디에 상태가 저장되어 있는지 찾아낸다. 단, “어디에”만 찾고 “정답값”은 찾지 않는다는 점이 중요하다.
2. 상태 기반 검증 (Independent Finish Gate)
finish가 호출되면 (최소 3단계의 비-finish 스텝 이후), 독립적인 finish gate가 새로운 컨텍스트에서 실행된다. 이 게이트는:
- 내레이션 블라인드: 메인 에이전트의 메시지 히스토리, 계획, finish 이유를 보지 못한다. 오직 작업 지시문과 머신 접근 권한만 받는다
- 상태 그라운딩: 실제 저장된 파일, 앱 백엔드, 스프레드시트 셀 수식을 직접 확인한다
- 안티 캡처: 에이전트가 자체적으로 만든 사이드 파일이 아닌, 작업이 명시한 실제 산출물 위치에서 검증한다
- 제한된 수정: 최대 3라운드까지 피드백을 제공한다
이 설계는 Reflexion이나 Self-Refine 같은 자기 반성(self-reflection)과 근본적으로 다르다. 자기 반성은 에이전트가 자신의 궤적을 돌아보며 동의하는 과정이다. StateAct의 게이트는 정반대다: 에이전트의 주장을 보지도 않고 독립적으로 확인한다. 내레이션 조건부 판별자의 편향(agreement bias)을 원천적으로 차단하는 것이다.
3. 긴 호라이즌 유지 (Context Management)
최대 200턴의 메인 에이전트 턴에 서브에이전트 위임까지 합치면 작업당 ~155 모델 턴에 도달한다. 이를 세 가지 메커니즘으로 관리한다:
- 신선한 컨텍스트 전문가: 각 위임은 자체 컨텍스트 윈도우에서 실행되고, 간결한 보고서만 반환한다
- 자동 압축: 컨텍스트 한계에 가까워지면 가장 오래된 접두사를 요약하고 이미지를 제거한다
- 외부화된 계획: 메시지 히스토리 밖에 체크리스트를 유지하고 매 턴 재주입하여 압축을 견딘다
실험 결과: OSWorld 2.0에서 압도적
메인 결과
OSWorld 2.0 (108개 장호라이즌 작업)에서 StateAct + Claude Opus 4.8:
| 지표 | 참조 (스크린샷 기반) | StateAct | 향상 |
|---|---|---|---|
| 바이너리 성공률 | 20.6% | 26.9% | +6.3pp |
| 평균 부분 점수 | 54.8% | 61.6% | +6.8pp |
| 작업당 비용 | ~$72 | ~$7.8 | ~9배 절감 |
| 출력 토큰 | 224K | 100K | 2.2배 절감 |
StateAct는 OSWorld 2.0에서 21% 공개 프론티어를 넘는 유일한 시스템이다.
제거 실험 (Ablation)
어떤 컴포넌트가 핵심인가?
- act-on-state 제거 → 가장 큰 하락 (55.8% 부분). 상태 기반 행동이 가장 중요
- finish gate 제거 → 57.5% 부분
- 컨텍스트 관리 제거 → 58.7% 부분
- bash-only (GUI 서브에이전트 없음) → 45.9% 부분, 베이스라인(54.8%)보다도 낮음
코드만으로는 충분하지 않다. GUI 서브에이전트라는 안전망이 있어야 상태 기반 접근이 완전해진다.
작업당 턴 분석
실패 분석: 병목이 인식에서 추론으로 이동했다
StateAct의 가장 중요한 진단 결과는 실패의 본질이 바뀌었다는 것이다.
79개의 비완벽 작업을 감사한 결과:
- 추론 오류 (Reasoning errors): 38개 (지배적)
- 검증 약점 / 잘못된 경로 저장: 14개
- 모달리티 병목 (오디오, 비디오, 실시간 상호작요): ~20%
- 모호한 지시: 일부
- 미분해: 5개
상태 기반 행동이 인식(perception) 실패를 대부분 제거했다. read cell B7이나 list the calendar store 같은 코드 명령은 정확하다. finish gate가 구조적 결함(잘못된 경로, 미저장, 포맷 불일치)을 잡아낸다. 하지만 추론 오류는 어떤 하네스로도 직접 해결할 수 없다.
Finish Gate의 한계
게이트가 처리한 76개의 비완벽 작업 중 올바르게 거부한 것은 8개, 잘못 통과시킨 것은 68개(≈90% 오류율). 이는 게이트가 구조만 검사하기 때문이다. 값의 정확성(value correctness)은 소스에 대한 해석이 같으면 같은 오류를 재생산한다. 이것은 편향이 아니라 **공통 모드 실패(common-mode failure)**다: 동일한 소스에 대한 동일한 해석.
“상태 그라운딩은 정확도의 벽을 인식에서 추론으로 옮긴다. 벽을 제거하는 것이 아니다.”
GUI 서브에이전트는 강력할 필요가 없다
StateAct는 GUI 조작을 서브에이전트에 격리하기 때문에 메인 에이전트는 거의 화면 기반 제어에 의존하지 않는다. 연구진은 Claude의 컴퓨터 사용 모델을 31B 파라미터의 경량 SFR-CUA 모델로 교체해 보았다.
| 벤치마크 | Claude Opus 4.8 서브에이전트 | SFR-CUA (31B) 서브에이전트 |
|---|---|---|
| OSWorld-Verified | 81.9% | 81.1% |
| WindowsAgentArena | 50.6% | 51.2% |
| AndroidWorld | 81.9% | 84.1% |
| MobileWorld | 70.1% | 68.4% |
| OSWorld 2.0 | 61.6% | 43.2% |
네 개 벤치마크에서는 차이가 거의 없다. 하지만 OSWorld 2.0(가장 긴 호라이즌)에서는 18.5% 차이로 급락한다. 결론: 메인 에이전트가 상태 기반으로 작업을 끌고 가면, 짧은 호라이즌에서는 경량 GUI 모델로 충분하지만, 가장 어려운 장호라이즌 데스크톱 작업에서는 여전히 프론티어급 GUI 모델이 필요하다.
실증된 세 가지 기여
- 아키텍처: 프로그램 상태를 주 인터페이스로, GUI를 위임된 예외로, 동일한 원칙을 검증과 메모리로 확장
- 경험적 성과: 동일 모델(Claude Opus 4.8)에서 하네스만으로 20.6% → 26.9% 바이너리 성공, 9배 비용 절감
- 진단: 성과의 원천은 관찰 대상(상태 vs 스크린샷)이지, 추가된 에이전트 깊이가 아니다 (재귀는 108개 중 7개에서만 발화, 중첩된 적 없음)
더 실습해보고 싶은 분들께
이 포스트의 핵심은 “에이전트가 어디를 보고 어떻게 행동하는가”를 다시 설계하는 것이 모델 교체 없이도 성능을 바꿀 수 있다는 점입니다. 하네스 설계, 컨텍스트 관리, 그리고 루프 엔지니어링의 실전 감각을 더 키우고 싶다면 아래 두 가지를 추천합니다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 에이전트 하네스와 자동화 루프를 직접 만져보며 익히는 실전 가이드
- 「모두를 위한 루프 엔지니어링」 — 긴 호라이즌 에이전트의 컨텍스트·메모리·검증 루프를 체계적으로 설계하는 강좌
📄 논문: StateAct: Program State, before Pixels, for Long-Horizon Computer-Use Agents — Yan Yang, Xiangru Jian, Ziyang Luo et al., Salesforce AI Research, 2026