CUAWright가 bash 하나로 컴퓨터 사용 에이전트 성능을 높인다

무엇인가

컴퓨터 사용 에이전트의 주류 설계는 모델과 도메인 특화 하네스를 결합하는 방식이다. 브라우저나 데스크톱 환경에 사람이 미리 만들어 두고 과제 실행 전에 고정되는 도구를 붙인다. 논문은 이 구조가 모델의 코딩 능력이 좋아진 지금 오히려 발목을 잡는다고 본다. GUI 네이티브이고 정적인 하네스는 시스템 상태에 대한 직접적·프로그램적 조작을 막고, 과제 수행 중 도구를 유연하게 새로 만드는 것도 불가능하게 한다. 스크린샷은 환경 상태 정보를 제한적으로만 노출하고, 키보드·마우스 같은 원시 동작은 하부 시스템 상태로 가는 길을 우회하게 만든다. GUI 조작과 코드 실행을 서로 다른 서브 에이전트에 나눠 맡기는 하이브리드 시도들도 도메인 특화·GUI 중심이라 미리 정의된 고정 도구 집합에 묶여 있다.

어떻게 동작하나

제안 시스템 CUAWright는 약 3천 줄 규모의 최소 터미널 하네스다. 모델의 모든 행동이 터미널 명령 하나로 통일되며, bash가 유일한 행동 인터페이스다. 논문은 이 과제를 부분 관측 마르코프 결정 과정으로 정식화한다. 환경 상태는 s_t=(x_t, f_t)로 분해되는데, x_t는 애플리케이션과 시스템의 하부 상태이고 f_t는 에이전트 워크스페이스와 상호작용 중 만들어진 산출물을 포함하는 지속적 파일시스템 상태다. 행동 공간 A_term은 과제 도메인과 환경이 바뀌어도 고정된다. 브라우저 과제는 디버깅 프로토콜에 맞춰 에이전트가 생성한 코드로 구동되고, 데스크톱 과제는 터미널 명령이나 CLI 도구, 또는 소스 파일 직접 편집으로 처리된다. 프로그램적 제어가 진짜로 불가능한 표면에 한해서만 xdotool이나 pyautogui 명령으로 키보드·마우스 동작을 흉내 낸다.

무엇과 다른가

관찰 방식도 기존 하네스와 다르다. GUI 기반 에이전트는 매 스텝 스크린샷과 접근성 트리를 관찰에 붙여 장기 과제에서 컨텍스트가 빠르게 불어난다. CUAWright의 기본 관찰은 터미널 출력뿐이고, 시각 정보는 필요할 때만 두 단계로 요청한다. 먼저 저장 경로를 지정해 스크린샷 파이썬 CLI 도구를 호출하고, 그 경로로 이미지 로딩 CLI 도구를 호출해 스크린샷을 컨텍스트에 넣는다. 메모리도 별도 상태나 전용 인터페이스로 두지 않는다. 기억하고 싶은 값, 중간 결과, 진행 상황, 로그, 이전 실패 기록을 워크스페이스 w_t에 파일로 외부화하며, 이 파일 조작은 외부 애플리케이션을 다루는 것과 같은 A_term 행동 공간으로 수행된다. 워크스페이스는 모델의 활성 컨텍스트 윈도우와 독립적이라 컨텍스트 압축이 일어난 뒤에도 파일은 남고 필요하면 다시 읽으면 된다. 같은 워크스페이스가 새 실행 능력을 만드는 기반도 된다. 실행 환경이 제공한 프로그램 집합 P_env에, 에이전트가 워크스페이스에 만든 실행 산출물 집합 P_agent(w_t)가 더해져 유효 프로그램 집합 P_t를 이룬다. 에이전트는 스크립트를 쓰고 실행하고 출력을 보고 구현을 고친 뒤 새 인자로 다시 호출할 수 있다.

어떻게 쓰나

실험은 웹·데스크톱·CAD에 걸친 6개 벤치마크에서 이뤄졌다. OSWorld 2.0에서는 공개 108개 과제 중 105개를 최대 300 스텝으로 평가했는데, 사용할 수 없는 GitLab 서버가 필요한 과제 026과 041, 중첩 도커가 필요해 평가 환경이 안정적으로 지원하지 못하는 과제 082는 제외했다. 단일 에이전트 설정에서 GPT-5.5 xhigh로 63.2%, GPT-5.6 Sol Max로 67.9%를 기록해 공식 리더보드 베이스라인을 크게 앞섰다. GPT-5.5 xhigh에서는 해당 OpenAI 베이스라인보다 15.7점 높은 성능을 내면서 과제당 비용을 6.0달러 줄였고, GPT-5.6 Sol Max는 부분 점수를 5.2점 올리면서 과제당 약 9.5달러를 절감했다. 초록 기준으로는 OSWorld 2.0에서 부분 보상이 33.2% 상대 개선되고 추정 비용이 37.5% 줄었다.

전제와 한계

웹과 CAD 결과도 구체적이다. 300개 과제·136개 실제 웹사이트로 구성된 Online-Mind2Web에서 GPT-5.4를 쓴 CUAWright는 중간·어려움 난이도 과제에서 좌표 예측 기반 스크린샷 에이전트보다 큰 향상을 보였고, 초록은 GUI 네이티브 하네스 대비 성공률 4.7% 향상을 보고한다. 장기 브라우징 과제 200개로 이뤄진 Odysseys에서는 같은 GPT-5.4로 성공률 77.5%, 평균 76.1 스텝을 기록해 동일 모델의 GUI 기반 33.5%를 크게 앞섰다. 8개 업무 도메인의 장기 과제 114개를 담은 WeaveBench에서는 Codex CLI를 CUAWright로 교체해 114개 중 61개를 통과, PassRate를 35.1%에서 53.5%로, 전체 점수를 49.9에서 66.4로 올렸다. BenchCAD는 4개 정투영도에서 3D 솔리드를 복원하는 과제로, 전체 17,900개 중 난이도별로 균등 샘플링한 212개(쉬움 72, 보통 72, 어려움 68)를 평가했다. 도구 사용 설정에서 평균 IoU 79.0%를 기록해 GPT-5.5 기준 OpenAI 리더보드 보고치 55.8%를 크게 넘었고, 도구 없는 단일 턴 설정에서는 재현 점수 43.8%로 보고치 44.4%와 비슷해 평가 부분집합 난이도가 대등하거나 조금 더 어렵다는 것을 보였다. CadGenBench에서는 공개 픽스처 81개에서 Codex 하네스 대비 GPT-5.5 3.7%, GPT-5.6 Sol 2.5% 점수가 올랐다.

절제 실험은 두 가지가 눈에 띈다. 멀티 에이전트 대 단일 에이전트 비교에서는 단일 에이전트가 멀티 에이전트만큼 좋은 성능을 냈고, 멀티 에이전트는 중간 턴 수만 늘렸다(GPT-5.6 Sol 101→151, GPT-5.5 73→137). 저자들은 GPT-5.5, GPT-5.6 Sol 같은 프런티어 모델이 별도 검증 에이전트 없이도 스스로 답을 검증하는 행동을 이미 학습했다고 본다. 파일시스템 절제에서는 터미널 명령으로 파일을 확인·편집·생성하는 프로그램적 접근을 프롬프트로 금지했더니 GPT-5.6 Sol 성능이 12.1점 떨어졌다. 정성 분석에서는 OSWorld 2 평가의 89개(84.8%) 과제에서 GPT-5.6 Sol이 실행 가능한 파일을 최소 하나 만들었고, 총 776개 실행 파일 중 192개(24.7%)가 서로 다른 실행 명령 이벤트에서 재사용됐다. 또 xdotool·pyautogui 같은 OS 입력 호출이 전혀 없는 터미널 전용 과제가 터미널과 GUI를 섞은 과제보다 성능이 유의하게 좋았다. 실패 유형은 모델별로 갈렸는데, GPT-5.5는 과제를 잘못 읽는 비율이 19.4%로 가장 높았고 GPT-5.6 Sol은 맞아 보이지만 정밀도가 부족한 출력(19.0%), 내용은 맞지만 위치가 틀린 경우(10.5% 대 3.9%), 과제 일부를 끝내지 않은 경우(7.6% 대 5.8%)가 더 많았다. 검증되지 않은 가정은 두 모델 모두 약 5.8%로 비슷했다.

개발자 관점에서 이 논문의 실무적 주장은 명확하다. 에이전트 하네스를 만들 때 GUI 조작 도구를 미리 고정된 집합으로 제공하는 대신, bash와 파일시스템을 기본 행동 공간으로 열어 주면 모델이 스스로 필요한 도구를 스크립트로 만들어 재사용하고, 컨텍스트가 아니라 파일에 상태를 쌓는다. 스크린샷도 매 스텝 기본 관찰로 붙이지 말고 요청 시에만 로드하는 편이 비용과 성능 양쪽에 낫다는 것이 이 실험의 요지다. 다만 이 이득은 모델의 코딩 능력에 의존하므로, 어떤 모델을 쓰는지와 파일시스템 접근 권한을 어떻게 샌드박싱할지를 함께 확인해야 한다. 또한 터미널 전용으로 처리되지 않는 표면에서는 결국 xdotool·pyautogui 같은 GUI 폴백이 필요하다.

논문은 별도의 한계 절을 두지 않지만 본문에 전제가 드러나 있다. OSWorld 2.0 평가에서 외부 GitLab 서버와 중첩 도커가 필요한 과제 3개를 제외했고, BenchCAD는 계산 예산 제약 때문에 17,900개 중 212개만 균등 샘플링해 평가했으며 OpenAI 보고 수치와 평가 부분집합이 달라 직접 비교에는 제약이 있다. 멀티 에이전트 구성은 이 하네스에서 이득을 주지 못했고, 파일시스템에 대한 프로그램적 접근이 성능의 핵심 전제라는 점도 절제 실험으로 확인된 조건이다.