커서는 그대로, 앱만 움직인다… HN이 본 background computer-use의 기반

Hacker News가 Cua를 본 시선은 “멋진 데모”보다 “드디어 빠진 배관을 채웠다”에 가까웠다. Show HN 스레드에서 Francesco Bonacci는 문제를 아주 직접적으로 설명했다. 지금의 GUI 자동화는 대체로 사람 세션을 통째로 빼앗는다. 커서가 튀고, 포커스가 바뀌고, 창이 앞으로 오고, 사용자는 에이전트가 클릭을 끝낼 때까지 손을 놓아야 한다. 코딩 에이전트와 computer-use 도구가 늘어나는 2026년 맥락에서 이건 사소한 UX 문제가 아니다. 한 대의 머신을 사람과 여러 에이전트가 안전하게 같이 쓰지 못하게 만드는 핵심 제약이다.

cua-driver는 그 제약을 정면으로 깨려는 macOS용 오픈소스 드라이버다. 목표는 간단하다. 에이전트가 실제 Mac 앱을 클릭하고 입력하고 읽되, 사용자는 앞에서 계속 일한다. 하지만 구현은 전혀 간단하지 않았다. 작성자가 공개한 기술 글을 보면 CGEventPost는 HID 스트림으로 들어가 커서를 움직이고, CGEvent.postToPid는 커서는 안 건드려도 Chromium이 신뢰하지 않는 이벤트로 보고 클릭을 버린다. 그렇다고 대상 창을 먼저 활성화하면 포커스를 빼앗고 Space까지 끌고 와서 문제를 원점으로 되돌린다.

Cua가 꺼낸 해법은 macOS 내부로 더 깊게 들어가는 방식이다. 핵심은 SkyLight의 SLEventPostToPid, yabai에서 가져온 focus-without-raise 패턴, 그리고 가려진 Electron 창에서도 접근성 트리가 살아 있게 만드는 private AX 훅이다. 여기에 (-1, -1) 위치로 한 번 보내는 primer click까지 붙는다. Chromium의 user-activation gate를 먼저 틱 올리고, 진짜 클릭은 창을 앞으로 끌어오지 않은 채 뒤에서 맞히는 식이다. Bonacci가 반복해서 강조한 것도 이 부분이다. background computer-use는 특정 벤더의 쇼케이스 기능이 아니라, 어떤 에이전트 하네스든 붙일 수 있는 공용 기반이 돼야 한다는 주장이다.

HN 반응도 그 틀을 대체로 받아들였다. 전직 Apple 엔지니어는 구현이 탄탄해 보인다고 했고, 여러 UI 자동화 플로를 동시에 돌릴 수 있다는 점을 실전 이득으로 짚었다. 다른 댓글은 곧바로 다음 질문으로 넘어갔다. telemetry 기본값은 어떤가, Windows나 Linux도 비슷한 primitive가 필요해지지 않겠나, 감사 추적은 어떻게 설명하나 같은 질문들이다. 기술 글이 스스로 인정한 한계도 눈에 띈다. Chromium의 right-click 문제, Blender 같은 canvas 앱은 여전히 frontmost activation이 필요하다는 점이다. 그래도 HN은 이 프로젝트를 “Mac에서 돌아가는 신기한 것”으로 보지 않았다. agent가 진짜 데스크톱을 백그라운드에서 함께 쓰기 시작할 때 필요한 첫 기반 중 하나로 읽었다.