voxl은 AI 모델이 아니라 화면 전송 계층입니다. VNC 대신 H.264와 WebSocket 하나로 60fps를 내고, 에이전트가 화면 변화를 기다리는 /wait API를 제공한다는 점이 핵심입니다.
AI 에이전트가 브라우저나 데스크톱 앱을 직접 조작하는 컴퓨터 사용(computer use) 작업이 늘면서, 에이전트가 일하는 원격 화면을 사람과 에이전트가 함께 보는 인프라가 병목으로 떠올랐습니다. 개발 플랫폼 기업 Tembo가 공개한 오픈소스 voxl은 이 지점을 겨냥한 원격 데스크톱 스트리밍 서버입니다. 저장소 설명은 “extremely fast web remote desktop streaming”이고, 2026년 11월 4일 기준 GitHub 스타는 약 770개입니다.
이 글은 voxl의 README와 소스 코드를 직접 확인해 구조, 에이전트용 API, 한계를 정리합니다. 소셜 미디어에 퍼진 소개와 다른 부분도 함께 짚습니다.
기본 사양: Rust, 3개 운영체제, CPU x264
| 항목 | 내용 |
|---|---|
| 언어 | Rust(axum·tokio 기반 서버), 웹 클라이언트는 JavaScript |
| 지원 OS | Linux(X11·Xvfb, Wayland는 작업 중), macOS, Windows 10 이상 |
| 화면 캡처 | Linux XShm·XDamage, macOS ScreenCaptureKit, Windows DXGI Desktop Duplication |
| 인코딩 | CPU x264 H.264(기본 preset ultrafast, CRF 24), 비트레이트 2~30Mbps 적응형 |
| 전송·디코딩 | WebSocket 하나(/ws), 브라우저 WebCodecs로 디코드 |
| 기본 프레임 | 60fps(--framerate 60) |
| 라이선스 | 소스는 MIT, 단 GPL-2.0인 x264를 링크하므로 배포 바이너리는 GPL |
| 최신 릴리스 | v0.3.2(2026-11-02), crates.io 패키지명 voxl-server |
라이선스는 도입 전에 꼭 확인할 부분입니다. README는 “voxl은 GPL-2.0인 x264를 링크하므로 voxl 바이너리와 이를 번들한 모든 것은 GPL로 배포된다”고 명시합니다. 자사 제품에 바이너리를 묶어 배포하려는 기업이라면 법무 검토가 필요합니다.
하드웨어 인코딩은 아직 쓰지 않습니다. README는 macOS 하드웨어 인코딩을 작업 중이라고 밝혔고, 2560×1600 해상도의 바쁜 화면에서 X 서버를 포함해 1.3~1.7코어를 쓴다고 적었습니다.
왜 VNC가 아니라 H.264와 WebSocket인가
현재 에이전트 샌드박스의 사실상 기본값은 VNC 계열입니다. Anthropic의 computer use 레퍼런스 데모도 Docker 안에서 Xvfb, x11vnc, noVNC를 씁니다. VNC는 화면 변경 영역을 사각형 단위로 보내는 방식이라, 영상이나 스크롤처럼 화면 전체가 자주 바뀌는 작업에서 프레임이 크게 떨어집니다. README는 그 원인을 “x11vnc가 화면을 폴링하기 때문”이라고 설명합니다.
voxl은 화면을 동영상 스트림으로 다룹니다. 운영체제가 알려주는 변경 영역 정보로 캡처하고, H.264로 압축해 WebSocket으로 보내며, 브라우저가 WebCodecs로 하드웨어 디코딩합니다. 화면이 멈추면 “paintover”로 선명한 프레임을 다시 그려 압축 흔적을 지웁니다.
WebRTC 대신 WebSocket을 고른 이유도 README에 나옵니다. WebSocket은 HTTP 프록시, 터널, 샌드박스 미리보기 URL을 그대로 통과합니다. 클라우드 샌드박스처럼 네트워크 경로를 통제하기 어려운 환경에서는 이 점이 배포 편의성을 크게 좌우합니다. 대가도 분명히 적었습니다. 패킷 손실이 있는 회선에서는 잃어버린 패킷이 뒤 프레임을 붙잡아 두지만, WebRTC는 건너뛸 수 있다는 것입니다. 즉 데이터센터 안이나 안정적인 회선에 최적화된 선택입니다.
성능 수치는 Tembo가 직접 잰 벤치마크입니다. 16 vCPU EPYC VM, GPU 없음, 2560×1600 Xvfb 환경에서 voxl은 평균 60fps, 중앙값 지연 12~99ms였고 noVNC는 평균 8fps 미만이었습니다. selkies, KasmVNC, Neko와의 비교에서도 느린 회선(5Mbps, 60ms) 조건에서 voxl이 앞섰다고 밝혔습니다. 다만 독립 기관의 재현 결과는 아직 없습니다.
에이전트용 API: screenshot, record, wait
voxl이 일반 원격 데스크톱 도구와 갈리는 지점은 에이전트와 스크립트가 쓰는 HTTP API입니다. 문서화된 엔드포인트는 세 가지입니다.
curl -u ":$VOXL_PASSWORD" -o shot.png localhost:6901/screenshot
curl -u ":$VOXL_PASSWORD" -o clip.mp4 "localhost:6901/record?seconds=10"
curl -u ":$VOXL_PASSWORD" "localhost:6901/wait?idle=1000&timeout=30000"
curl -u ":$VOXL_PASSWORD" "localhost:6901/wait?change®ion=0,0,800,600"
# {"changed":true,"timed_out":false,"seq":812,"waited_ms":340}- /screenshot: 현재 화면을 PNG로 받습니다.
- /record: 시청자에게 이미 보내고 있는 H.264 스트림을 재인코딩 없이 MP4로 저장합니다. 그래서 추가 CPU 비용이 없습니다. 기본 최대 길이는 300초이고, 커서는 녹화에 들어가지 않습니다.
- /wait: 화면이 일정 시간 멈추거나(idle), 특정 영역이 바뀔 때(change, region)까지 기다립니다.
실무적으로 가장 의미 있는 것은 /wait입니다. 지금까지 에이전트는 “페이지 로딩이 끝났는가”를 알기 위해 고정 시간을 기다리거나, 스크린샷을 반복해서 찍어 비교해야 했습니다. 고정 대기는 느리고, 반복 스크린샷은 비쌉니다. voxl은 운영체제가 이미 보고하는 변경 영역 정보(XDamage, ScreenCaptureKit, DXGI)를 그대로 쓰기 때문에 README 표현대로 “스크린샷도 폴링도 필요 없이” 기다릴 수 있습니다. 에이전트의 한 단계마다 걸리는 대기 시간과 모델 호출 비용을 동시에 줄일 수 있는 구조입니다.
알려진 것과 다른 점 두 가지
1. 조작용 HTTP API는 없습니다
voxl은 “AI 에이전트가 원격 화면을 보고 작업하게 돕는 도구”로 소개되곤 합니다. 입력 주입 기능 자체는 있습니다. Linux는 XTEST, macOS는 CGEvent, Windows는 SendInput으로 마우스와 키보드를 넣습니다. 하지만 이 입력은 브라우저 클라이언트가 WebSocket 메시지로 보내는 것이고, 클릭이나 키 입력을 보내는 HTTP 엔드포인트는 문서화돼 있지 않습니다. 코드 안의 도움말도 에이전트용 API를 screenshot, record, wait 세 가지로 안내합니다. 에이전트가 화면을 조작하려면 별도 도구(예: xdotool, 각 플랫폼의 computer use 도구)를 함께 써야 합니다.
2. Tembo 서비스 적용은 간접 확인 수준입니다
Cargo.toml에는 “Tembo CLI의 tembo voxl에 내장하는 라이브러리”라는 주석이 있습니다. Tembo가 9월 15일 발표한 Tembo Computer도 “60fps 데스크톱”을 내세웠고, 글쓴이가 voxl 주 개발자입니다. 다만 그 발표문에 voxl이라는 이름은 나오지 않습니다. “실제 서비스에서 쓰고 있다”는 설명은 정황상 타당하지만 공식 문장으로 확인된 사실은 아닙니다.
보안과 운영 시 주의점
- TLS가 없습니다. 기본은 비밀번호(Basic auth) 인증이고, 비밀번호를 지정하지 않으면 시작할 때 128비트 무작위 값을 만듭니다. 그러나 전송은 평문 HTTP이므로 원격 접속에는 TLS 리버스 프록시나 SSH 터널이 필요합니다. WebCodecs도 HTTPS 또는 localhost에서만 동작합니다.
- Linux 기본 수신 주소는 0.0.0.0입니다. macOS와 Windows는 127.0.0.1이 기본입니다. 클라우드 VM에 띄울 때 방화벽 규칙을 먼저 확인해야 합니다.
- 보기 전용 모드가 있습니다.
--read-only로 입력을 막을 수 있어, 사람이 에이전트 작업을 지켜보기만 하는 용도에 적합합니다. Host·Origin 검사로 DNS rebinding도 막습니다. - 브라우저 조건: Chromium 94+, Firefox 130+(데스크톱), Safari 16.4+가 필요하고 Firefox Android는 지원하지 않습니다.
어디에 쓰면 맞는가
| 도구 | 성격 | voxl과의 관계 |
|---|---|---|
| Anthropic computer use | 스크린샷을 보고 행동을 정하는 모델 도구 | 모델은 그대로 두고, 데모의 x11vnc+noVNC 자리를 voxl로 바꿀 수 있음 |
| VNC·noVNC | 범용 원격 화면 프로토콜 | 같은 역할의 대체재, 에이전트용 API는 voxl만 제공 |
| Moonlight·Sunshine, RustDesk | 게임 스트리밍, 개인 원격 지원 | README가 용도를 구분. voxl은 서버·VM·샌드박스 데스크톱용 |
정리하면 voxl은 에이전트를 똑똑하게 만드는 도구가 아니라, 에이전트가 일하는 화면을 빠르고 싸게 보여 주고 기다리게 해 주는 인프라입니다. 클라우드 샌드박스에서 브라우저 에이전트를 여러 개 돌리며 사람이 실시간으로 감독해야 하는 팀, 또는 에이전트 작업 과정을 영상 증거로 남겨야 하는 팀에 특히 맞습니다. 반대로 패킷 손실이 잦은 원격 회선, Wayland 기반 Linux, 바이너리를 상용 제품에 번들해야 하는 경우라면 아직 신중하게 볼 필요가 있습니다.
자주 묻는 질문
Q. voxl만 설치하면 AI가 컴퓨터를 조작하나요?
A. 아닙니다. voxl은 화면 전송·녹화·대기 기능을 주는 서버입니다. 무엇을 클릭할지 정하는 모델과 입력을 보내는 도구는 따로 필요합니다.
Q. 상용 서비스에 써도 되나요?
A. 소스는 MIT지만 x264를 링크한 바이너리는 GPL이 적용됩니다. 내부 서버에서 쓰는 것과 바이너리를 묶어 배포하는 것은 의무가 다르므로 법무 검토를 권합니다.
Q. GPU가 있어야 하나요?
A. 현재는 CPU x264로 인코딩하므로 GPU가 없어도 됩니다. 하드웨어 인코딩은 macOS부터 작업 중입니다.
출처: tembo/voxl GitHub 저장소(README, src/server.rs, src/input.rs, Cargo.toml), Tembo 블로그 (2026-09-15), Anthropic computer-use-demo
대표 이미지: tembo/voxl 저장소 소셜 프리뷰(흑백 변환)
