Computer Use Agent는 화면을 보고 클릭하고 입력하는 에이전트입니다. 브라우저 자동화만 생각하면 Playwright나 Selenium과 비슷해 보이지만, 실제 방향은 더 넓습니다. 웹, 데스크톱 앱, 모바일 화면, 사내 도구까지 사람이 눈으로 보고 조작하던 GUI를 모델이 처리하는 쪽으로 가고 있습니다. H Company가 공개한 Holo3.1은 이 흐름에서 중요한 포인트를 보여줍니다. 성능 경쟁만이 아니라 로컬 실행, 모바일 지원, 다양한 agent harness 호환성이 전면에 나왔습니다.
Holo3.1은 0.8B, 4B, 9B, 35B-A3B 네 가지 크기로 공개됐고, 35B-A3B에는 FP8, Q4 GGUF, NVFP4 같은 양자화 체크포인트가 제공됩니다. 발표 내용에서 가장 실무적인 숫자는 AndroidWorld 성능 개선입니다. 35B-A3B 모델은 67%에서 79.3%로, 4B와 9B 변형은 58%에서 72%로 개선됐다고 설명합니다. 또 DGX Spark 기준 NVFP4 W4A16은 FP8 대비 1.41배, BF16 대비 1.74배 토큰 처리량을 보였고, agent harness 최적화와 결합했을 때 평균 step time이 6.8초에서 3.3초로 줄었다고 합니다.
GUI 자동화는 개인정보와 사내 데이터에 바로 닿습니다. 브라우저에 로그인된 관리자 콘솔, CRM, 회계 시스템, 고객 지원 도구를 에이전트가 조작한다면 화면 스크린샷과 입력값이 외부 API로 나가는 구조는 부담이 큽니다. 클라우드 모델을 쓰더라도 마스킹, 프록시, 감사 로그, 권한 분리가 필요합니다.
로컬 실행은 이 문제를 줄이는 선택지입니다. 모델과 agent harness가 같은 네트워크 또는 같은 장비에서 돌면 화면 데이터가 외부로 나가지 않습니다. 물론 로컬이라고 자동으로 안전해지는 것은 아닙니다. 권한 분리와 로그, 사용자 승인 단계는 여전히 필요합니다. 하지만 개인정보가 많은 업무에서는 “성능이 조금 낮아도 내부에서만 실행”이 더 합리적인 요구가 됩니다.
첫째, 환경 범위가 넓어졌습니다. 기존 computer-use 모델은 웹 벤치마크에서 강해도 모바일이나 데스크톱 앱에서는 흔들리는 경우가 많았습니다. Holo3.1은 웹, 데스크톱, 모바일 환경을 명시적으로 다룹니다. 이는 배포팀 입장에서 중요합니다. 실제 업무 자동화는 브라우저 하나로 끝나지 않습니다. Slack, ERP, 내부 Electron 앱, 모바일 관리자 앱이 섞이는 경우가 많습니다.
둘째, agent harness 호환성을 봅니다. 모델이 JSON을 잘 내는 것만으로는 충분하지 않습니다. 어떤 프레임워크에서는 function calling이 표준이고, 어떤 프레임워크는 별도 action schema를 씁니다. Holo3.1은 function-calling protocol 지원을 추가했고, OSWorld와 내부 벤치마크에서 native execution과 function calling이 near-parity에 가까워졌다고 설명합니다. 실무에서는 이게 도입 비용을 줄입니다.
셋째, 작은 모델과 양자화가 제품 요구사항이 됐습니다. 0.8B, 4B, 9B 모델은 최고 성능용이 아니라 비용과 지연 시간을 맞추기 위한 선택지입니다. 자주 호출되는 화면 인식, 단순 클릭 판단, 폼 입력 같은 단계는 거대한 모델보다 작은 모델이 더 맞을 수 있습니다.
가장 먼저 떠오르는 영역은 반복적인 백오피스 작업입니다. 예를 들어 고객 정보 조회, 티켓 분류, CRM 필드 업데이트, 정산 화면 대조, 관리자 콘솔 설정 변경입니다. API가 잘 정리된 조직이라면 API 자동화가 먼저입니다. 하지만 현실에서는 API가 없거나, 권한이 제한되거나, 오래된 웹 관리자 화면만 있는 경우가 많습니다. 이때 GUI agent가 임시 다리 역할을 할 수 있습니다.
두 번째는 QA 자동화입니다. 기존 E2E 테스트는 selector가 조금만 바뀌어도 깨집니다. Computer Use Agent는 화면 의미를 보고 작업하므로 selector 의존도를 낮출 수 있습니다. 다만 테스트 자동화에 쓰려면 결과 판정은 별도 deterministic check로 해야 합니다. 에이전트가 “성공한 것 같다”고 말하는 것을 테스트 통과로 보면 안 됩니다.
세 번째는 개인 로컬 워크플로우입니다. 개발자 PC에서 브라우저, 터미널, 문서, 이슈 트래커를 오가며 반복 작업을 처리하는 agent가 여기에 해당합니다. 이 경우 로컬 실행은 지연 시간과 프라이버시 측면에서 장점이 큽니다.
가장 위험한 방식은 관리자 권한이 있는 브라우저를 에이전트에게 그대로 맡기는 것입니다. 화면 조작 agent는 실수했을 때 write action을 수행합니다. 잘못된 버튼 클릭, 잘못된 고객 선택, 잘못된 저장은 단순 답변 오류보다 복구 비용이 큽니다.
또 하나는 관측 없이 자동화를 돌리는 방식입니다. Computer Use Agent는 반드시 action log, screenshot diff, tool call trace, 사용자 승인 지점을 남겨야 합니다. Holo3.1 같은 모델 성능이 좋아져도 제품 설계에서는 “어디서 멈출 것인가”가 더 중요합니다. 결제, 삭제, 권한 변경, 고객 통지처럼 되돌리기 어려운 액션은 자동 실행이 아니라 승인 대기 단계로 남기는 편이 안전합니다.
Holo3.1의 의미는 특정 모델 하나가 아니라 computer-use agent가 로컬과 실무 배포 조건을 갖추기 시작했다는 데 있습니다. 이제 개발팀은 “화면을 조작할 수 있나”보다 “어떤 권한과 검증 아래 조작하게 할 것인가”를 설계해야 합니다.
실행 체크리스트입니다.
