Computer-Use 2.0: Agents Just Got Multi-Cursor — Francesco Bonacci, Cua

1. 핵심 주장 (Core Claims)

• Cua(발표 중 자동자막에는 "Quad" 계열로 오기됨, 회사명 Cua)는 "컴퓨터 사용 에이전트(Computer-Use Agent)"의 패러다임을 1.0에서 2.0으로 전환시켰다고 주장한다. 1.0은 사람의 화면을 그대로 빼앗아 스크린샷 기반으로 클릭/타이핑/스크롤을 흉내 내는 "인간형 에이전트 루프"였다면, 2.0은 에이전트가 사용자 화면을 점유하지 않고 백그라운드에서 조용히 동작하는 방식이다.
• 이 전환을 가능케 한 핵심 제품이 "Cua Driver"다. macOS의 비공식(undocumented) 접근성 API를 활용해 만들어졌고, macOS뿐 아니라 Windows, Linux까지 지원하는 최초의 백그라운드 드라이버라고 소개한다. 어떤 에이전트든 이 드라이버를 통해 운영체제 하위 레벨(접근성 트리 또는 스크린샷)에 연결할 수 있다.
• "에이전트에게 손을 줬으니, 이제는 그 손을 신뢰할 수 있는지 검증해야 한다"는 문제의식 아래, GUI 전용 벤치마크 "Cua Bench(자막상 Kua Bench)"를 구축했다. 이는 터미널 전용 벤치마크(terminal-bench, Harbor)의 GUI 버전에 해당하며, 태스크는 setup / oracle(골든 트래젝토리) / evaluator 세 요소로 구성된다.
• 실제 데이터로 보여준 가장 충격적인 주장: 전기공학(EE) 실무 소프트웨어 기반 벤치마크(Cua Bench Kyad, Snorkel AI와 공동 구축)에서 최고 성능 에이전트조차 25개 태스크 중 6개만 완전 통과했고, 백지 상태 회로도에서 시작하면 성공률이 0%로 떨어진다. 모든 모델의 리더보드가 30% 보상을 넘지 못해 "평평하다."
• 반면 같은 벤치마크에서 에이전트의 컴퓨터 툴을 기본 스크린샷 방식에서 Cua Driver로 바꾸기만 해도 통과율이 62%→80%로 오르고, 토큰 사용량은 34% 줄어든다. 이는 Cua Driver가 데스크톱 전체가 아니라 활성 "창(window)" 단위로 관찰 범위를 좁히기 때문이라는 것이 핵심 주장이다.
• RL 학습 인프라 관점에서는, 컴퓨터 사용 에이전트의 RL 트레이닝 시 GPU가 샌드박스 스핀업/리셋을 기다리며 유휴 상태로 낭비되는 비용이 크다는 문제를 지적하고, 이를 "수요 기반 오토스케일링 풀(demand-based autoscaling pool)"로 해결했다는 "Cua Fleet" 인프라를 소개한다.

2. 근거와 사례 (Evidence & Examples)

발표자 구성

• Francesco Bonacci — Cua CEO (오프닝 + 클로징, Cua Driver 파트)
• Dylan — 공동창업자/CTO (Cua Bench, 인텔리전스/벤치마킹 파트)
• Robert(Rob) — Chief Infra Officer (Cua Fleet, RL 인프라 파트)

팀 배경

• 팀은 Microsoft 출신으로, "예전 방식의 GUI 에이전트(Guey agents)"를 그 시절부터 다뤄온 경험이 있다고 언급. 청중 대상으로 "컴퓨터 사용을 1년/2년째 다뤄본 사람?" 질문을 던지며 이 분야가 매우 최근(1~2년) 등장한 개념임을 강조.

Cua Driver 출시 배경

• 약 2개월 전, 코덱스(자막상 "Codex" — OpenAI 계열 컴퓨터 사용 모델 릴리스로 추정되는 문맥) 쪽에서 컴퓨터 사용 모델을 릴리스한 것을 계기로, 한 주말 만에 팀이 뭉쳐 Cua Driver를 만들었다고 함.
• 이미 백그라운드 컴퓨터 사용 기술을 다루고 있었기에 빠르게 대응 가능했다.
• macOS의 "라이브 데모"에서 보여준 것처럼, 에이전트가 실제로 사용자의 노트북 화면/제어권을 빼앗지 않고 동작.
• 동작 방식(액션 실행 사다리): ① get window state 호출 → 접근성 트리(accessibility tree) 표현 + 스크린샷 획득 → ② 접근성 트리 기반 백그라운드 실행 시도 → ③ 실패 시 픽셀 레벨 백그라운드 클릭으로 폴백. 단, 이 폴백은 아직 macOS/Windows/Linux에서 동일하게 동작하지 않는 "현 단계 최선"이라고 솔직히 인정.
• 릴리스 간 회귀(regression) 방지를 위해 8개의 서로 다른 애플리케이션 하네스(harness)로 지속적으로 테스트.
• 초기 도입 사례로 Clicky, (자막 불분명: Massimo/Mass Queno 계열), H Company, Droid Factory를 언급하며 이들이 업스트림 기여를 해줬다고 감사 표시.

Cua Bench 구조와 데이터

• 태스크 3요소: setup function(초기 상태 세팅) / oracle function(골든 트래젝토리 제공, GUI 액션 기반이라는 점이 terminal-bench와의 차이) / evaluator(환경을 프로빙해 성공 여부 판정).
• 5개 이상의 데스크톱 플랫폼을 대상으로 하며, Cua Bench SDK를 쓰면 단일 Python 파일로 여러 플랫폼에서 동작하는 GUI를 작성 + 프로빙할 수 있다고 주장.
• 현재 카탈로그: 130개 이상 검증 가능한 태스크, 42개 환경, 5개 플랫폼. CLI로 손쉽게 재현 가능.
• Snorkel AI와 협업한 "Cua Bench Kyad"(전기공학 회로 설계 태스크, 실제 회로 시뮬레이션 평가자 사용): 최고 에이전트가 25개 중 6개만 풀 패스. 그 6개 전부가 "기존 회로도 수정" 유형이었고, "백지 회로도"부터 시작하는 태스크는 성공률 0%. 전체 모델 중 30% 보상을 넘긴 모델 없음.
• Cua Bench 기본 데이터셋을 4천 개 규모로 확장해 테스트했을 때, 기본 내장 컴퓨터 툴 사용 시 약 62% 통과율. 동일 에이전트의 컴퓨터 툴만 Cua Driver로 교체하면 통과율 80%, 토큰 사용량은 34% 감소 — 이유는 Cua Driver가 전체 데스크톱이 아니라 활성 창(window)에 집중하기 때문.
• 평가 신뢰성 확보 방법: 에이전트로 구성된 "리워드 해킹 시도 매트릭스"로 태스크/환경을 먼저 스스로 공격해보고, 그 결과를 "코드리뷰(CodeRabbit 스타일)"처럼 정리해, 이 검증을 통과한 태스크만 데이터셋에 편입. 발표자는 이를 "결국 에벌류에이션이 끝까지 이어지는 구조(evals all the way down)"라고 표현.
• 에이전트의 "세계 모델(world model)" 측정: 기록된 모든 실행(run)을 트래젝토리의 임의 시점에서 포크(fork)할 수 있게 만들고, 그 시점에서 모델에게 보상/내부 상태/기타 관측치를 예측하게 한 뒤 실제 포크 결과와 비교 — 이 예측 정확도가 에이전트가 가진 "세계 모델"의 수준을 나타낸다는 설명.

Cua Fleet (RL 인프라)

• 문제의식: RL 트레이닝에서 컴퓨터 사용 에이전트용 샌드박스가 새로 뜨거나 리셋되는 동안 GPU가 아무 일도 하지 않고 대기 — "매우 비싼 유휴 비용."
• 샌드박스 스타트업 시간을 줄이는 것도 방법이지만, 컴퓨터 사용 환경(예: 40GB짜리 환경 이미지)은 원천적으로 무겁고 실용적이지 않은 경우가 많다.
• 해결책: "수요 기반 오토스케일러(demand-based autoscaler)"가 현재 얼마나 많은 GPU가 샌드박스를 필요로 하는지 감지해 풀(pool) 크기를 그에 맞춰 실시간으로 조정. 사전에 warm pool 크기를 미리 알 필요가 없고, 다중 일(multi-day) 트레이닝 도중에도 (초반엔 샌드박스 다수 필요 → 생성 길이가 길어지면 후반엔 덜 필요) 크기가 계속 변한다.
• 이 풀에 쓰이는 머신은 GPU보다 2~4배 저렴해서, 약간의 redundancy(여분)를 유지해도 전체적으로 비용을 절감 — 스타트업 대기 비용을 GPU가 아니라 저렴한 인프라 쪽으로 이전시키는 구조.
• 결과: GPU 워커의 활용률(utilization)이 최대화되고, Windows/Linux/Android용 즉시 사용 가능한 샌드박스를 제공하며 macOS 지원은 준비 중.

Q&A (모바일/Android)

• Android는 ARM 팀과 협업 중이며, ARM 쪽에 이미 Android용 하네스가 존재.
• Android에서는 워크로드를 컨테이너화(Ubuntu/GUI 도커 컨테이너 등)해 백그라운드 형태로 동작시킬 여지가 iOS보다 훨씬 크다.
• 다만 이는 진짜 "GUI 컨트롤"이라기보다는 "툴 유즈(tool use)"에 가까운 형태 — Activity 프레임워크를 활용해 백그라운드 툴 유즈를 구현 중이라고 답변.

3. 구조화된 시사점 (Structured Insights)

• 패러다임 전환의 축: "화면을 점유하는 에이전트"에서 "백그라운드에서 조용히 동작하는 에이전트"로. 이는 컴퓨터 사용 에이전트가 사람의 작업을 방해하지 않고 동시에(멀티태스킹처럼) 실행될 수 있어야 한다는 요구를 반영한다 — 발표 제목의 "Multi-Cursor"가 가리키는 지점.
• 관찰 범위를 좁히면 성능과 효율이 동시에 오른다: 데스크톱 전체가 아니라 "활성 창(window)"만 관찰 대상으로 좁혔더니 통과율 62%→80%, 토큰 34% 절감이라는 결과는, 에이전트 설계에서 "관측 공간(observation space)의 최소화"가 정확도와 비용 모두에 직결된다는 일반 원칙을 보여준다.
• 접근성 트리 우선, 픽셀은 폴백: 접근성 트리 기반 조작 → 실패 시 픽셀 클릭이라는 계층적 실행 전략은, 구조화된 정보(접근성 트리)가 있을 때는 그것을 우선 활용하고 구조화된 정보가 없을 때만 비용이 큰 저수준(픽셀) 방식으로 폴백하는 것이 실용적임을 시사한다.
• 벤치마크의 "난이도 절벽" 현상: EE 회로 설계 태스크에서 "기존 회로 수정"은 어느 정도 가능해도 "백지에서 새로 설계"는 0%로 완전히 붕괴한다는 사실은, 현재 에이전트들이 기존 상태를 국소적으로 편집하는 데는 강하지만 백지 상태에서 목표를 향한 계획을 스스로 구성하는 데는 근본적으로 취약함을 보여준다. 이는 EE 도메인에 국한된 문제가 아니라 코딩 에이전트 등 다른 영역에서도 흔히 관찰되는 패턴과 일치한다.
• 평가 신뢰성 자체를 벤치마킹 대상으로 삼는 메타 접근: "에이전트가 태스크를 잘 푸는가"뿐 아니라 "그 태스크(eval) 자체를 신뢰할 수 있는가"를 리워드 해킹 시도로 먼저 검증하는 프로세스는, 벤치마크 산업이 성숙해지면서 벤치마크 자체의 무결성 검증이 새로운 표준 관행이 되어가고 있음을 보여준다.
• 세계 모델 측정이라는 새 평가축: 단순히 "액션을 성공적으로 수행했는가"가 아니라 "환경 상태를 얼마나 정확히 예측하는가"를 트래젝토리 포크/비교 방식으로 측정하는 것은, 에이전트 평가가 행동 성능(behavioral performance)에서 내부 표상 품질(world model quality) 평가로 확장되고 있다는 흐름을 보여준다.
• RL 인프라 비용 최적화는 컴퓨트가 아니라 오케스트레이션 문제: GPU 유휴 비용 문제의 해법이 "더 빠른 샌드박스"가 아니라 "수요에 따라 신축적으로 조정되는 저비용 풀"이라는 점은, 에이전트 RL 트레이닝의 병목이 순수 컴퓨트가 아니라 워크로드 오케스트레이션/스케줄링에 있다는 시사점을 준다.

4. 실행 포인트 (Action Points)

• 컴퓨터 사용 에이전트를 도입/평가할 때, 스크린샷 전체가 아니라 활성 창(active window) 단위로 관찰 범위를 좁히는 아키텍처를 우선 검토할 것 — 정확도와 토큰 비용 모두에 이득이 크다는 실증 데이터가 있음.
• 접근성 트리(accessibility tree)를 지원하는 플랫폼/앱이라면 픽셀 기반 클릭보다 접근성 트리 기반 액션을 1순위로 사용하고, 픽셀 클릭은 폴백으로만 설계.
• 에이전트 벤치마크를 자체 제작하거나 도입할 때, "골든 트래젝토리 + evaluator" 구조와 함께 "리워드 해킹 매트릭스로 먼저 태스크 자체를 공격해보는" 검증 단계를 넣을 것 — 벤치마크 신뢰성 확보에 실질적 도움.
• 백지 상태에서 새로 만들어야 하는 태스크(제로에서 설계)와 기존 상태를 수정하는 태스크의 성공률 차이를 구분해서 측정할 것 — 현재 에이전트 역량을 과대평가하지 않기 위한 최소한의 체크.
• RL 트레이닝 인프라를 직접 운영한다면, 고정된 warm pool 크기 대신 수요 기반 오토스케일링 풀을 검토해 GPU 유휴 비용을 인프라(저비용 머신) 쪽으로 흡수시키는 구조를 고려할 것.
• Cua Driver / Cua Bench / Cua Fleet 프로젝트(오픈소스로 공개됨)를 팀 내 컴퓨터 사용 에이전트 실험의 참조 구현체로 검토해볼 가치가 있음 — 특히 크로스플랫폼(macOS/Windows/Linux) 지원과 8개 애플리케이션 하네스 기반 회귀 테스트 방식은 자체 QA 파이프라인 설계에 참고할 만함.

핵심 요약 (20줄)

1. Cua의 CEO Francesco Bonacci, CTO Dylan, Chief Infra Officer Robert 세 명이 함께 발표한 세션으로, Cua Driver·Cua Bench·Cua Fleet 세 제품을 순서대로 소개했다.
2. 기존 컴퓨터 사용 에이전트("1.0")는 스크린샷을 찍고 추론한 뒤 클릭/타이핑/스크롤로 화면을 직접 점유하는 "인간 흉내형 루프"였다.
3. Cua Driver는 사용자 화면을 빼앗지 않고 백그라운드에서 조용히 동작하는 최초의 크로스플랫폼(macOS·Windows·Linux) 드라이버라고 소개됐다.
4. macOS의 비공식(undocumented) 접근성 API를 활용해 만들었으며, 약 2개월 전 경쟁사의 컴퓨터 사용 모델 출시를 계기로 한 주말 만에 만들어졌다.
5. 액션 실행은 계층적으로 이뤄진다: 먼저 접근성 트리 기반 백그라운드 실행을 시도하고, 실패하면 픽셀 레벨 백그라운드 클릭으로 폴백한다.
6. 릴리스 간 회귀를 막기 위해 8개의 서로 다른 애플리케이션 하네스로 지속 테스트하며, Clicky·H Company·Droid Factory 등이 초기 도입 및 업스트림 기여 사례로 언급됐다.
7. Cua Bench는 터미널 전용 벤치마크(terminal-bench, Harbor)의 GUI 버전으로, 태스크가 setup·oracle(골든 트래젝토리)·evaluator 세 요소로 구성된다.
8. 단일 Python 파일로 5개 이상 데스크톱 플랫폼에서 동작하는 GUI를 작성·검증할 수 있는 SDK를 제공하며, 현재 130개 이상 검증 태스크와 42개 환경을 갖췄다.
9. Snorkel AI와 공동 구축한 전기공학(EE) 특화 벤치마크 "Cua Bench Kyad"에서 최고 에이전트조차 25개 태스크 중 6개만 완전 통과했다.
10. 통과한 6개는 전부 "기존 회로도 수정" 유형이었고, 백지 상태에서 새 회로를 설계하는 태스크는 성공률이 0%로 떨어졌다.
11. 테스트한 모든 모델 중 30% 보상을 넘긴 모델이 없어 리더보드가 "평평하다"고 평가됐다.
12. Cua Bench 기본 데이터셋을 4천 태스크로 확장한 결과, 기본 컴퓨터 툴 사용 시 통과율이 약 62%였다.
13. 동일 에이전트의 컴퓨터 툴을 Cua Driver로 교체하자 통과율이 80%로 오르고 토큰 사용량은 34% 줄었으며, 이는 관찰 범위를 데스크톱 전체가 아닌 활성 창(window)으로 좁혔기 때문이다.
14. 벤치마크 신뢰성 확보를 위해 에이전트들로 구성된 매트릭스가 먼저 리워드 해킹을 시도해 환경을 공격해보고, 그 결과를 코드리뷰 형태로 정리해 통과한 태스크만 데이터셋에 편입시킨다.
15. 발표자는 이 과정을 "결국 평가가 끝까지 이어지는 구조(evals all the way down)"라고 표현했다.
16. 에이전트의 "세계 모델" 수준은 기록된 실행을 임의 시점에서 포크한 뒤, 모델에게 보상/내부 상태를 예측하게 하고 실제 결과와 비교하는 방식으로 측정한다.
17. Robert는 RL 트레이닝 중 샌드박스 스핀업/리셋을 기다리며 GPU가 유휴 상태로 낭비되는 비용 문제를 지적했다.
18. 해결책으로 수요 기반 오토스케일러가 필요한 만큼 샌드박스 풀 크기를 실시간 조정하는 "Cua Fleet"을 소개했으며, 사전에 warm pool 크기를 정할 필요가 없다.
19. 풀에 쓰이는 인프라가 GPU보다 2~4배 저렴해 약간의 여분을 유지해도 전체 비용이 절감되고, GPU 활용률이 최대화된다고 설명했다.
20. Q&A에서는 Android가 ARM 팀과 협업 중이며 컨테이너화를 통한 백그라운드 작업이 가능하지만, 이는 GUI 제어보다는 "툴 유즈"에 가까운 형태라고 답했다.