에이전트가 코드를 쓰고 API를 부르는 일은 이제 흔하다. 그런데 실제 업무는 여전히 API가 없는 데스크톱 앱, 로그인된 브라우저, OS 대화상자 사이에서 끝나는 경우가 많다. 오늘 GitHub Trending 일간 목록에 오른 trycua/cua는 이 마지막 구간, 즉 “에이전트에게 실제로 쓸 수 있는 컴퓨터를 준다”는 문제를 드라이버·샌드박스·VM·벤치마크·소형 모델까지 한 저장소로 묶어 푸는 프로젝트다. 이 글은 실무자 관점에서 구조와 설계 결정, 직접 돌려 본 결과, 라이선스 함정까지 정리한다.
한눈에 보는 프로젝트 현황
| 항목 | 확인한 값 (10/8 KST 기준) | 해석 |
|---|---|---|
| 저장소 | trycua/cua (주 언어 Rust) |
드라이버·SDK·VM·벤치·모델 연구 코드가 한 모노레포에 있다 |
| 별 / 포크 | 28,804 / 2,041 (11:58 KST, Trending 페이지) | 같은 시각 일간 Trending 10위, ‘오늘 +228’ |
| main 상태 | HEAD 7b3a8ee (10/8 11:10 KST) |
얕은 클론으로 받은 최근 커밋 50개가 전부 10/7 0시 이후일 만큼 변경이 잦다 |
| 최근 릴리스 | cua-driver-rs v0.34.0 (10/6 07:30), cua-sdk v0.4.1 (10/5 21:19), cua-spaces v0.7.2 (10/5 18:08), lume v0.6.1 (10/5 03:47) | 컴포넌트별로 태그가 따로 붙는다. Lume은 매일 nightly가 나온다 |
| PyPI 패키지 | cua 0.4.1, cua-driver 0.34.0, cua-bench 0.3.0, cua-sandbox 0.9.0 |
cua-bench만 Python 3.12~3.13 범위로 좁다 |
| 라이선스 | 기본 MIT, Cua Spaces 계열은 FSL-1.1-MIT | 선택 확장 cua-perception은 AGPL 모델을 포함해 MIT가 아니다 |
README는 스스로를 ‘Computer-Use 2.0’이라고 부른다. 에이전트가 한 과제 안에서 코드, API, 그래픽 UI를 자유롭게 오가야 한다는 뜻이다. 홍보 문구를 걷어 내면 구조는 분명하다. 모델과 루프는 각자 쓰는 에이전트 하네스(Claude Code, Codex, Cursor 등)가 맡고, cua는 그 아래에서 관찰·행동·실행 환경·평가를 맡는다. 문서의 한 줄 요약도 model → agent harness → Cua Driver → OS 접근성·입력 → 앱이다.
구성 요소 지도: 여섯 덩어리, 세 가지 라이선스
| 구성 요소 | 역할 | 주요 기술 | 라이선스 |
|---|---|---|---|
| Cua Driver | 실제 데스크톱 앱을 관찰·조작하는 ‘손과 눈’. MCP(stdio)·CLI·SDK로 노출 | Rust 워크스페이스 16개 크레이트, macOS AX / Windows UIA / Linux AT-SPI·X11 | MIT |
| cua SDK·CLI·daemon | 로컬 VM·컨테이너·클라우드 샌드박스를 같은 API로 만들고 붙는다 | Rust 42개 크레이트, UniFFI로 Python·TS·Swift·Kotlin 바인딩, gRPC 계약 | MIT |
| Lume | Apple Silicon에서 macOS·Linux VM 생성·관리 | Apple Virtualization.Framework | MIT |
| Cua Bench | 컴퓨터 유즈 과제 작성·평가·궤적(trajectory) 내보내기 | Python, 로컬 gVisor·QEMU 또는 클라우드 풀 | MIT |
| CUA-S1 | 폼 입력 같은 좁은 결정을 맡는 소형 전문 모델 연구 | ~855K 파라미터 분류기, Qwen3.5-4B LoRA 어댑터 | 코드 MIT, 가중치는 각 카드 기준 |
| Cua Spaces | 에이전트용 전체 데스크톱(Space) 앱, 텔레포트·멀티플레이어 | SwiftUI·Tauri 앱, 샌드박스 내부 데몬 cua-spacesd | FSL-1.1-MIT |
저장소 루트에는 libs/(라이브러리), apps/(Spaces 앱), docs/, rfcs/, evidence/, tests/가 있고, Nix flake와 uv·pnpm 락파일이 함께 있다. 실무에서 먼저 볼 곳은 libs/cua-driver(드라이버), libs/cua(SDK·CLI·데몬·proto 계약), libs/cua-bench(평가) 세 곳이다. 예전 Python 패키지인 cua-computer, cua-computer-server, cua-agent, cua-som은 더 이상 관리하지 않는다고 README가 밝힌다. 특히 npm cuabot은 “알려진 보안 문제가 있으니 실행하지 말고 제거하라”고 적혀 있으니, 옛 튜토리얼을 따라가다 이 패키지를 설치하지 않도록 주의해야 한다.
Cua Driver: 관찰은 트리와 픽셀을 함께, 행동은 대상 하나씩
Driver의 핵심 호출은 get_window_state(pid, window_id)다. 한 번에 접근성 트리와 스크린샷을 함께 돌려준다. 트리는 무엇을 누를 수 있는지(역할·라벨·요소마다 element_token)를, 스크린샷은 그중 어느 것인지와 트리가 빠뜨리거나 틀린 부분을 보여 준다. 화면 전체가 필요하면 get_desktop_state를 쓴다.
모든 입력 도구(click, type_text, press_key, hotkey, scroll, drag 등)는 호출마다 대상을 명시한다. 창 대상이면 {kind: "window", pid, window_id}, 화면 대상이면 {kind: "desktop", display_id: "primary"}이고 후자는 포그라운드 전용이다. 대상이 잘못됐거나 모호하면 아무것도 보내기 전에 실패한다. 세션에 대상을 묶어 두지 않는 이 방식은 멀티 윈도 작업에서 ‘엉뚱한 창에 타이핑’하는 사고를 줄인다.
배경 우선 ‘행동 사다리’
| 단계 | 방식 | 포커스·포인터 | 스스로 검증 가능? |
|---|---|---|---|
| 1. Element (배경) | element_token으로 접근성 액션 실행 (AXPerformAction, UIA Invoke, AT-SPI) |
건드리지 않음 | 가능 — 유일하게 접근성 재조회로 verified: true |
| 2. Pixel (배경) | 같은 스크린샷의 x, y 좌표로 창에 이벤트 전달 | 건드리지 않음 | 불가 — 다시 관찰해서 확인 |
| 3. Page | 브라우저 탭은 CDP로 DOM에 직접 작용 | 건드리지 않음 | 페이지 상태로 확인 |
| 4. Foreground | 해당 동작만 창을 앞으로 올려 실행 후 이전 앱 복원 | 잠시 가져감 | 불가 — 게임·Blender 같은 캔버스 앱용 |
여기서 가장 중요한 설계는 “이벤트를 보냈다”와 “상태가 바뀌었다”를 구분하는 점이다. 응답에는 effect(confirmed, unverifiable, suspected_noop, partial, refused)와, 다음 단계가 있으면 escalation(px·page·foreground 중 추천과 이유)이 붙는다. 문서는 Electron·Catalyst·웹 콘텐츠가 실제로 적용하지 않은 쓰기를 마치 적용한 것처럼 되돌려 주기도 하므로, 이런 경우를 unverifiable로 보고하고 다음 단계를 권한다고 설명한다. 하네스 쪽에서는 confirmed가 아니면 다시 관찰하고 확인하는 루프를 기본으로 짜야 한다는 뜻이다.
플랫폼별 메커니즘과 경계
| 플랫폼 | 의미 기반 경로 | 배경 입력·캡처 | 문서가 밝힌 주된 한계 |
|---|---|---|---|
| macOS | Accessibility API | CoreGraphics·SkyLight 이벤트, 창 단위 ScreenCaptureKit | 다른 Space의 SwiftUI 창은 트리를 잃음, TCC 권한 필요 |
| Windows | UI Automation | 대상 HWND로 창 메시지 | 데몬이 대화형 세션에 있어야 함(Session 0 불가) |
| Linux X11 | AT-SPI | 창 주소 지정 X11 입력·캡처 | 합성 배경 이벤트를 거부하는 툴킷이 있음 |
| Linux Wayland | AT-SPI | 컴포지터별로 다름 | 가려진 창에 대한 raw 키 입력은 거부. Sway는 ‘제한적 지원’, KDE·Hyprland는 실험적 |
Wayland에 대한 태도가 특히 보수적이다. 창 위치를 안다고 해서 컴포지터가 그 창으로 입력을 보내 주지는 않으므로, 잘못된 앱에 타이핑할 위험을 감수하느니 background_unavailable로 거부한다. 문서는 이 구조화된 거부를 “숨겨야 할 실패가 아니라 계약의 일부”라고 부른다. 네이티브 Wayland 경로는 CUA_DRIVER_RS_ENABLE_WAYLAND=1로 켜야 하고, 기본값은 XWayland 경로다.
프로세스·세션·권한 모델
런타임(권한, 세션, 요소 캐시, 녹화, 브라우저 연결)이 어디에 사는지는 연결 방식이 정한다. SDK의 CuaDriver.create()는 내 프로세스 안에, Windows·Linux의 cua-driver mcp는 MCP 프로세스 자체에(stdin EOF에서 종료), macOS의 cua-driver mcp는 CuaDriver.app 데몬으로 프록시한다. 데몬이 존재하는 이유는 신원이다. macOS의 접근성·화면 기록 권한은 실행한 터미널이 아니라 CuaDriver.app(com.trycua.driver)에 귀속되고, Windows에서는 Session 0의 SSH 프로세스가 데스크톱을 볼 수 없기 때문이다.
- 권한 모드: 기본
standard(프롬프트 없음), 검토된 매니페스트의 도구·리소스만 허용하는bounded,--dangerously-bypass-approvals가 필요한unrestricted. 모드는 실행 시점에 고정되며 에이전트가 넓힐 수 없다. 바꾸려면 데몬을 재시작해야 한다. - 로그인된 Chromium 프로필에 붙는 것은
--grant existing-profile로 명시해야 한다. - 세션: 연결마다 암묵 세션 하나가 생기고 5분 유휴 후 정리된다. 만료 후의 요소 토큰은 무효이므로 다시 관찰해야 한다. 모든 세션은 화면·키보드·포커스를 공유하며 네이티브 입력은 한 번에 하나씩만 허용된다.
- HTTP MCP는 기본 꺼짐이다.
CUA_DRIVER_RS_MCP_HTTP_PORT를 설정하면 32~4096자 bearer 토큰(CUA_DRIVER_RS_MCP_HTTP_TOKEN)이 필수다.
검증 방식도 눈여겨볼 만하다. 지원 동작 하나하나가 ‘동작 × 요소/픽셀 × 배경/포그라운드 × 창/데스크톱 × 표면’ 조합의 셀로 Rust 카탈로그에 있고, 소스로 빌드한 픽스처 앱을 실제 데스크톱 세션에서 돌린다. 앱이나 데스크톱이 소유한 상태가 실제로 바뀌어야 통과이고, 배경 셀은 포커스·z-순서·실제 커서·전면 앱이 그대로여야 한다. 정확한 거부는 통과, 조용한 성공은 실패로 친다. 에이전트 도구 품질을 이렇게 정의한 프로젝트는 드물다.
cua SDK·샌드박스: 계약 우선, 런타임은 갈아 끼우기
libs/cua는 42개 크레이트로 된 Cargo 워크스페이스다. 이 중 UniFFI로 외부에 노출되는 크레이트는 cua-sdk 하나뿐이고, 여기서 Python(pip install cua), TypeScript(@trycua/cua), Swift, Kotlin(생성만, 배포 아티팩트는 아직 없음) 바인딩이 생성된다. 같은 API를 Cua.embedded()로 내 프로세스 안에서 돌리거나, Cua.connect()로 cua daemon(UDS ~/.cua/cua.sock, 권한 0600)에 붙어 여러 프로세스가 샌드박스·터널·스트림·자격 증명을 공유하게 할 수 있다.
샌드박스 안쪽에는 포트 3211에서 gRPC로 프로세스·파일·스크린샷·입력을 제공하는 cua-spacesd가 있다(입력은 내부적으로 cua-driver를 쓴다). 다만 README는 “샌드박스 안에 에이전트가 없어도 된다”고 강조한다. 생명주기와 준비 상태 판정은 런타임과 선택적 포트 프로브로 하고, spacesd가 필요한 기능만 SpacesdNotAvailable로 깔끔하게 실패한다. 로컬 런타임은 macOS에서 lume serve, 없으면 QEMU를 받아 오고, 컨테이너는 Docker/Podman에 가능하면 gVisor runsc를 쓴다.
# CLI: gVisor 컨테이너 샌드박스 하나를 만들고 지우기
cua sb create ubuntu --name dev
cua sb exec dev uname -a
cua sb screenshot dev
cua sb rm dev
# Python: 같은 샌드박스를 코드로
from cua_sandbox import Image, Sandbox
async with Sandbox.ephemeral(Image.linux(), local=True) as sb:
print((await sb.shell.run("uname -a")).stdout)proto 계약은 운영 관점에서 신뢰를 주는 부분이다. cua.env.v1에 System·Process·Filesystem·Computer·Windows·Accessibility·Driver·Stream·Presence·Teleport·Tunnel·Volume 12개 서비스, cua.daemon.v1에 Sandbox·Space·Runtime·Daemon 4개 서비스가 있다. 규칙도 명확하다. 네이티브 gRPC와 gRPC-Web을 한 포트에서 제공하고, gRPC-Web이 클라이언트 스트림을 못 싣기 때문에 모든 클라이언트 스트리밍 RPC에 단항(unary) 청크 대체 경로를 두며(빠지면 테스트 실패), 양방향 RPC는 금지한다. 변경은 추가만 허용되고 buf breaking이 머지 기준선과 비교한다. 영상·음성은 gRPC 밖(별도 미디어 경로, QUIC 3212)으로 뺐다.
Cua Bench: 과제를 만들고, 돌리고, 궤적을 남긴다
Cua Bench(cb)는 공인 리더보드라기보다 자기 업무용 컴퓨터 유즈 과제를 만들고 반복 측정하는 도구에 가깝다. 과제는 main.py가 있는 디렉터리이고, 환경은 computer.setup_config(OS, 이미지, 컨테이너/VM 선호)로 선언한다. 실행 위치·종류·엔진은 --on local|cloud, --kind auto|container|vm, --runtime auto|gvisor|runc|qemu|lume|kubevirt로 고르고, 존재하지 않는 조합은 유효 값을 나열하며 에러를 낸다. Windows·macOS·Android는 VM 전용이다.
uv tool install 'cua-bench[browser]'
cb dataset list
cb run example_tasks/hello_file_env # 로컬 gVisor 컨테이너(기본)
cb run my_task --attempts 5 # summary.json에 pass@k
cb run datasets/cua-bench-basic -j 8 --on cloud # 클라우드 풀에서 8개 병렬
CUA_BENCH_HARNESS=claude-code CUA_BENCH_HARNESS_KEYS=ANTHROPIC_API_KEY \
cb run example_tasks/hello_file_env --agent harness결과는 실행별 디렉터리에 result.json(백엔드, 이미지 다이제스트, 보상, 단계별 시간), ATIF-v1.8 형식 trajectory.json(스크린샷 포함), summary.json으로 남는다. cb dataset build로 궤적을 aguvis-stage-1·gui-r1 형식으로 내보낼 수 있어 학습 데이터 파이프라인과 바로 이어진다. --agent harness는 Claude Code, Codex, Gemini CLI, OpenCode, Goose 같은 코딩 에이전트 하네스를 과제 샌드박스 안에서 돌리고 과제의 evaluate로 채점한다. 사내에서 “어느 하네스·모델 조합이 우리 업무 과제를 더 잘 하나”를 비교하는 용도로 실용적이다.
한 가지 문서 불일치가 있다. 루트 README는 “VM·Docker·모델 API 키 없이 돌아가는 시뮬레이션 과제로 시작하라”고 안내하지만, libs/cua-bench README는 0.3에서 시뮬레이션(Playwright) 프로바이더가 사라졌고 해당 과제는 경고와 함께 Linux 컨테이너에서 돈다고 적는다. 현재 PyPI 최신은 0.3.0이므로, 실제로는 컨테이너 런타임을 먼저 준비해야 한다고 보는 편이 안전하다.
CUA-S1: ‘시스템 1’ 소형 모델이 주는 교훈
CUA-S1은 범용 에이전트가 아니라 “이 필드에 어떤 값이 들어가나”, “이 요소는 건드리지 말아야 하나” 같은 빠르고 범위가 정해진 결정을 맡는 소형 전문 모델 연구다. 체크포인트는 네 개다. 처음부터 학습한 약 85.5만 파라미터의 옵션-어텐션 분류기 cua-s1-nano-0.1, 그 파인튜닝인 폼 전용 cua-s1-form-v0, 그리고 동결된 Qwen/Qwen3.5-4B 위의 LoRA 어댑터 cua-s1-4b-0.1·0.2다. 4B 어댑터는 187~272MB이지만 기반 모델이 9.34GB다. 저장소는 가중치를 포함하지 않고, Hugging Face 리비전 SHA로 고정해 받도록 안내한다. pickle 체크포인트는 거부하고 safetensors+JSON만 받는다.
| 체크포인트 / 평가 조건 | 결과 | 읽는 법 |
|---|---|---|
cua-s1-forms — 학습 분포와 같은 합성 에피소드 3,070건 |
97.5% (2,993/3,070) | 분포 안에서는 강하다 |
cua-s1-forms — 어휘 밖 라벨의 보류 폼 41건(5개 폼) |
29.3% (12/41), 41건 중 36건을 평균 신뢰도 0.974의 skip으로 답함 |
모르면 기권하지 않고 ‘자신 있게 건너뜀’. 실행기가 폼 전체를 조용히 no-op할 수 있다 |
cua-s1-4b-0.2 — 교차 데이터셋 보류 텍스트 분할 |
전체 0.875 (ECE 0.121), pagination 행만 0.429 | pagination 행은 라벨 오류라고 카드가 스스로 밝힘 |
cua-s1-4b-0.2 — 보류 멀티모달 분할(접근성 트리 제거) |
전체 0.929 (ECE 0.069) | 스크린샷만으로도 단일 위젯 결정은 꽤 맞춘다 |
cua-s1-4b-0.2 — 실제 cua-bench-basic 환경, 20스텝 제한 |
에피소드 성공률 텍스트 0.944 / 멀티모달 0.722 | 13개 단일 위젯 연구 환경 기준. 무감독 다단계 운용의 근거가 아니라고 명시 |
이 모델 카드가 좋은 이유는 숫자보다 실패 방식을 적어 둔 데 있다. 폼 모델은 어휘 밖 라벨을 만나면 낮은 신뢰도로 기권하지 않고 높은 신뢰도의 skip을 낸다. 실행기가 skip을 “할 일 없음”으로 해석하면 폼 전체를 조용히 건너뛸 수 있다는 경고다. 소형 결정 모델을 붙일 때는 적용 범위 검사와 완료 검증을 모델 밖에 두라는 일반 원칙으로 받아들이면 된다. 또 4B 추론용 four-b extra(Transformers 5)는 학습·RL extra(Transformers 4)와 한 환경에 섞을 수 없고, 학습 레시피는 아직 Qwen3.5를 그대로 학습하지 못한다고 README가 밝힌다.
직접 돌려 본 결과
이번 글을 쓰며 Linux 박스(x86_64, X11 데스크톱)에서 공개 패키지와 저장소 테스트를 가볍게 확인했다. 모든 실행은 DO_NOT_TRACK=1로 텔레메트리를 끈 상태였다. macOS·Windows 실기, GUI 조작(클릭·입력), 클라우드 실행은 하지 않았다.
| 점검 항목 (박스: Linux x86_64, X11) | 결과 | 메모 |
|---|---|---|
pip install cua-driver |
0.34.0 설치, 바이너리 동봉 휠 | cua-driver doctor: X11 연결 OK, 텔레메트리는 DO_NOT_TRACK으로 꺼짐 확인 |
| 접근성 버스 | 경고: AT-SPI 버스에 닿지 못함 | 헤드리스·최소 데스크톱에서는 get_window_state 같은 트리 기반 기능이 제한된다 |
cua-driver list-tools |
Linux 빌드에서 도구 62개 | 클릭·입력부터 브라우저(CDP)·녹화·verify_state·replay_trajectory까지 |
cua-driver call (데몬 없이) |
‘daemon is not running’ 안내 후 종료 | CLI 원샷 호출은 cua-driver serve 데몬이 먼저 떠 있어야 한다 |
serve 후 list_windows / get_desktop_state |
창 목록 정상, 1920×1200 캡처 약 0.3초(JSON 약 2.5MB) | get_screen_size는 이번 환경에서 20초 타임아웃 — 원인 미확인 |
cua runtime doctor (cua 0.4.1) |
lume: macOS Apple Silicon 필요 / qemu: 설치 가능 / 컨테이너: 엔진 없음 | 로컬 샌드박스는 런타임 준비가 선행 조건임을 바로 알려 준다 |
cua-bench 밀폐 테스트 (uv run pytest) |
320 통과 / 2 건너뜀, 약 51초 | 인메모리 가짜 샌드박스로 돌아 컨테이너·VM·클라우드를 띄우지 않는다 |
export DO_NOT_TRACK=1 # 모든 Cua 프로그램의 사용 통계 끄기
pip install cua-driver cua
cua-driver doctor # 디스플레이 서버, AT-SPI, 텔레메트리 상태
cua-driver serve & # CLI 원샷 호출 전에 데몬부터
cua-driver call list_windows '{}'
claude mcp add --transport stdio cua-driver -- cua-driver mcp # 에이전트에 MCP로 연결
cua runtime doctor # 로컬 샌드박스 런타임 준비 상태정리하면 Linux에서 Driver의 ‘관찰’ 경로는 설치 직후 바로 쓸 만했고, 트리 기반 기능을 제대로 쓰려면 AT-SPI가 살아 있는 실제 데스크톱 세션이 필요하다. 샌드박스 쪽은 Docker/Podman(가능하면 gVisor)이나 QEMU를 먼저 갖춰야 한다. Bench의 밀폐 테스트가 외부 자원 없이 1분 안에 끝난다는 점은 기여나 사내 포크 유지에 유리하다.
대안과 비교
| 선택지 | 강점 | 약점 | cua와의 관계 |
|---|---|---|---|
| 브라우저 전용 자동화 (Playwright 기반 MCP, browser-use 류) | DOM 단위로 정확하고 생태계가 성숙 | 네이티브 앱·OS 대화상자·파일 선택기 밖으로 못 나감 | Driver도 CDP 브라우저 도구를 갖고 있어 웹+네이티브를 한 세션에서 오갈 수 있다 |
| 모델 벤더의 스크린샷+좌표형 computer-use 도구 | 붙이기 쉽고 모델과 함께 튜닝됨 | 픽셀 위주, 보통 포커스를 가져가며 결과 검증을 모델에 맡김 | Driver는 접근성 트리와 스크린샷을 함께 주고 effect로 적용 여부를 따로 보고한다 |
| VM + VNC + pyautogui 직접 구축 | 완전한 통제 | 검증·세션·권한·궤적을 모두 직접 만들어야 함 | SDK·Driver·Bench가 그 배관을 계약과 테스트로 제공 |
| 관리형 클라우드 데스크톱 샌드박스 | 운영 부담이 적음 | 비용과 벤더 종속, 내부망 앱 접근이 까다로움 | 로컬(Lume·QEMU·gVisor), 자기 클라우드 계정(AWS·GCP·Modal), Cua 클라우드를 같은 API로 선택 |
| 학술 벤치마크 (OSWorld 류) | 논문 간 비교 가능 | 자기 업무 과제를 추가하기 어렵다 | Cua Bench는 과제 작성·pass@k·궤적 내보내기에 초점. 공인 리더보드를 대신하진 않는다 |
cua의 차별점은 개별 기능보다 계약과 검증의 일관성이다. Driver는 거부와 미검증을 구조화된 값으로 돌려주고, SDK는 proto 계약을 추가 전용으로 관리하며, Bench는 같은 샌드박스 위에서 과제를 반복 측정한다. 반대로 브라우저 안에서만 끝나는 업무라면 DOM 기반 자동화가 더 단순하고 정확하다. 기존 vendor computer-use 도구로 충분히 돌아가는 파일럿이라면, 우선 Driver를 MCP로만 붙여 관찰 품질과 배경 실행이 실제로 차이를 만드는지부터 재 보는 편이 낫다.
라이선스·보안·운영 주의점
- MIT와 FSL의 경계: Driver, SDK·CLI·daemon, Lume, Bench는 MIT다. Cua Spaces 앱,
cua-spacesd, Keyvault, 텔레포트, 스트리밍 클라이언트·코덱 등은 FSL-1.1-MIT(source-available)이다. 자체 호스팅과 사내 사용은 자유지만, Spaces나 그 위에 만든 제품을 호스팅·관리형 서비스로 남에게 제공하려면 상용 라이선스가 필요하다. 각 릴리스는 2년 뒤 MIT로 전환된다. 저장소는 “MIT 패키지는 FSL 패키지에 의존하지 않는다”를 CI 스크립트로 강제한다. - AGPL 선택 확장: 화면을 영역으로 파싱하는
cua-perception은 AGPL-3.0-only OmniParser 아티팩트를 포함한다. 재배포하거나 네트워크로 제공하면 소스 공개 의무가 생길 수 있어, AGPL을 받지 않는 조직은 설치하지 말라고 README가 직접 경고한다. 폐기된cua-som도 AGPL-3.0-or-later다. - 모델 가중치: CUA-S1 코드는 MIT지만 가중치 라이선스는 각 카드에 따른다(4B 어댑터·nano는 Apache-2.0, forms는 MIT로 표기). 기반 Qwen3.5-4B는 별도 라이선스다.
- 텔레메트리: SDK·CLI·daemon·Spaces·Driver는 익명 사용 통계를 PostHog(EU)로 보낸다. 문서상 콘텐츠는 보내지 않고 속성은 닫힌 어휘로 제한되며, 첫 실행 안내가 표시되기 전에는 아무것도 보내지 않는다. CI 환경은 기본 꺼짐이고
DO_NOT_TRACK=1,CUA_TELEMETRY=0,cua telemetry off로 끌 수 있다. 사내 도입이면 이미지에 기본값으로 박아 두자. - 설치 방식: 공식 빠른 시작은
curl … | sh,irm … | iex형태다. 운영 환경에서는 버전 고정된 PyPI/npm 패키지나 서명된 릴리스 아티팩트를 쓰고,cua auth login단계가 에이전트에 스킬·MCP 서버를 설치하겠다고 제안하는 점도 검토 대상에 넣어야 한다. - 권한과 프롬프트 인젝션: 컴퓨터 유즈 에이전트는 화면에 보이는 모든 텍스트를 입력으로 받는다. CUA-S1 보안 문서의 권고(호스트와 무관한 계정에서 격리, 필요한 자격 증명·앱·네트워크만 부여, 되돌릴 수 없는 동작은 사람 확인, 즉시 중지 수단)는 cua 전체에 그대로 적용된다. 운영에서는 Driver를
bounded모드와 리뷰된 매니페스트로 띄우고, 로그인된 브라우저 프로필 연결은 꼭 필요한 경우에만 허용하자. - 변경 속도: 컴포넌트별로 며칠 간격의 릴리스가 이어지고 0.x 버전이 많다. CLI 플래그 이름이 바뀐 이력(cua-bench 0.2.11 → 0.3)도 있으니 버전을 고정하고 업그레이드 노트를 확인하는 습관이 필요하다.
누가 도입하면 좋은가
- API 없는 사내 데스크톱 업무를 에이전트로 옮기려는 팀: ERP 클라이언트, 레거시 Windows 앱, 사내 Electron 도구처럼 접근성 트리가 살아 있는 앱이라면 Driver의 배경 실행과
effect보고가 바로 효용을 낸다. - 컴퓨터 유즈 에이전트·모델을 평가하거나 학습 데이터를 만드는 팀: 같은 과제를 로컬 gVisor에서 만들고 클라우드에서 병렬로 돌리며, 궤적을 학습 형식으로 내보내는 흐름이 한 도구에 있다.
- macOS 중심 개발 조직: Lume으로 Apple Silicon에서 macOS VM을 만들고, Spaces로 에이전트용 데스크톱을 분리하는 구성이 가장 매끄럽게 맞물린다(Spaces 앱 설치는 macOS 26 이상, 개인은 무료이고 Pro·Teams 요금제는 ‘준비 중’이라고 README가 밝힌다). Spaces를 외부 서비스로 재판매할 계획이라면 FSL 조건부터 확인해야 한다.
- 신중해야 할 경우: Wayland 위주(특히 KDE·Hyprland) Linux 데스크톱, AGPL·source-available을 허용하지 않는 조직, 브라우저 안에서 끝나는 단순 자동화.
정리하면 cua는 “에이전트가 마우스를 움직이게 해 준다”보다 “에이전트의 화면 조작을 검증 가능한 계약으로 만든다”에 가까운 프로젝트다. 확인되지 않은 동작은 확인되지 않았다고 말하고, 위험한 경로는 조용히 시도하는 대신 거부한다. 도입한다면 버전을 고정하고, 텔레메트리와 권한 모드를 먼저 정한 뒤, Driver를 MCP로 붙여 읽기 전용 관찰부터 시작하는 순서를 권한다.