핵심 요약
AI가 화면을 클릭하는 시대가 온다는 말은 절반만 맞다. 더 어려운 문제는 클릭 자체가 아니라, 웹·데스크톱·모바일·로컬 PC·기업용 하네스가 모두 다른 조건에서 같은 일을 안정적으로 끝내는 것이다.
H Company는 2026년 6월 2일 Hugging Face 공식 블로그를 통해 Holo3.1 모델군을 공개했다. Holo3.1은 computer-use agents, 즉 화면을 보고 버튼·메뉴·폼·앱 흐름을 조작하는 에이전트용 비전-언어 모델군이다. 이번 발표의 핵심은 모델 하나가 더 좋아졌다는 이야기가 아니다. H Company는 0.8B, 4B, 9B, 35B-A3B 네 가지 크기와 FP8, Q4 GGUF, NVFP4 양자화 체크포인트를 함께 내놓으며 “클라우드 API뿐 아니라 로컬·엣지에서도 컴퓨터 유즈를 돌리겠다”는 방향을 분명히 했다. 출처: Hugging Face 공식 블로그.
이 글은 개발자, AI 도구 도입을 검토하는 실무자, 그리고 로컬 AI 흐름을 따라가는 독자를 위한 글이다. Holo3.1의 숫자를 그대로 받아쓰기보다, 왜 모바일과 하네스 호환성이 중요해졌는지, 로컬 실행이 개인정보와 비용 구조를 어떻게 바꾸는지, 실제 팀이 어떤 기준으로 실험해야 하는지를 중심으로 보겠다.
이미지 출처: H Company / Hugging Face 공식 블로그. 첫 번째 본문 이미지로, 카드 썸네일에서도 Holo3.1의 핵심 주제인 computer-use 벤치마크 경쟁이 드러난다.
무슨 일이 있었나
H Company는 Holo3.1을 “Fast & Local Computer Use Agents”라는 제목으로 공개했다. Holo3가 브라우저 자동화, 비즈니스 소프트웨어, 내부 도구, 데스크톱 앱에서 쓰이기 시작하면서 단순 성능만으로는 부족하다는 판단을 했고, Holo3.1은 세 가지 축을 개선했다고 설명한다.
첫째는 환경이다. Holo3.1은 웹과 데스크톱뿐 아니라 모바일 자동화를 전면에 세운다. 공식 발표에 따르면 AndroidWorld에서 35B-A3B 모델은 67%에서 79.3%로 개선됐고, 4B와 9B 모델은 58%에서 72%로 올라갔다. 스마트폰 화면은 데스크톱 브라우저보다 작고, 앱별 UI 패턴이 다르고, 터치 조작과 권한 팝업이 자주 끼어든다. 이 환경에서 성능이 오른 것은 “브라우저 데모용 모델”에서 “실제 기기 자동화용 모델”로 가려는 신호다.
둘째는 하네스다. H Company는 Holo3.1이 기존 structured JSON output뿐 아니라 function-calling protocol도 지원한다고 밝혔다. 에이전트 하네스가 달라지면 모델이 같은 화면을 보더라도 도구 호출 형식, 클릭 좌표, 재시도 방식, 상태 저장 방식이 달라진다. 한 데모 환경에서 잘한 모델이 다른 하네스에서 무너지는 일이 생긴다. Holo3.1은 이 간극을 줄이려는 업데이트다.
셋째는 배포 위치다. Holo3.1은 35B-A3B 모델의 FP8, Q4 GGUF, NVFP4 체크포인트를 제공한다. 특히 Q4 GGUF는 소비자 하드웨어에서의 로컬 배포를 겨냥하고, NVFP4는 NVIDIA DGX Spark 같은 장비에서 빠른 추론을 노린다. H Company는 로컬 Windows 또는 Mac에서 에이전트가 실행되고, 모델은 같은 기기 또는 같은 네트워크의 DGX Spark에서 돌 수 있으며, 이 경우 사용자의 네트워크 밖으로 데이터가 나가지 않는다고 설명했다.
사람들이 실제로 겪는 문제
컴퓨터 유즈 모델이 어려운 이유는 화면을 “볼 수 있다”와 일을 “끝낼 수 있다” 사이에 큰 차이가 있기 때문이다.
예를 들어 사내 구매 시스템에서 장비 신청을 처리한다고 해보자. 모델은 PDF 견적서를 읽고, 웹앱의 예산 잔액을 확인하고, 승인 또는 반려 메일을 보내야 한다. 이 과정에는 계산, 문서 이해, 웹 UI 조작, 메일 작성, 실패 복구가 모두 들어간다. H Company가 Holo3 발표 때 소개한 H Corporate Benchmarks도 이런 현실 업무를 겨냥한다. 486개 multi-step task를 e-commerce, business software, collaboration, multi-app setup으로 나눠 만들었다는 설명이다. 출처: H Company Holo3 공식 페이지.
개발자에게도 문제는 비슷하다. 로컬 앱 버그를 재현하려면 브라우저, IDE, 터미널, 시뮬레이터, 디자인 미리보기 창을 오가야 한다. OpenAI Codex의 Windows Computer Use와 원격 제어를 다룬 이전 글에서도 핵심은 “휴대폰에서 코딩한다”가 아니라, 실제 Windows PC에 남아 있는 파일·셸·앱 상태를 에이전트가 다루는 구조였다. Holo3.1은 같은 질문을 모델 배포 쪽에서 던진다. 모델이 브라우저 하나가 아니라 여러 화면 환경과 하네스에서 버틸 수 있는가.
로컬 실행 요구도 현실적이다. 회사 문서, 고객 정보, 내부 도구 화면, 로그인된 브라우저 세션을 외부 API로 매번 보내기 어려운 팀은 많다. 반대로 완전 로컬 실행은 속도와 운영 난도가 문제다. GPU 메모리, 양자화 품질, 화면 캡처 파이프라인, 도구 호출 지연, 로그 저장 정책까지 직접 봐야 한다. 그래서 Holo3.1의 진짜 의미는 “오픈 모델이 나왔다”보다 “로컬 컴퓨터 유즈를 실험할 재료가 더 구체화됐다”에 가깝다.
벤치마크는 좋지만, 그대로 도입 결정은 어렵다
공식 표에서 Holo3.1 35B-A3B는 overall performance 78.3%, OSWorld 80.0%, AndroidWorld 79.3%, ScreenSpot-Pro 71.5%, OSWorld-G 78.8%를 기록한다. H Company는 Holo3.1과 Qwen 3.5 계열의 비용 대비 성능 그래프도 제시했다. 4B와 9B 모델은 35B보다 작지만 비용 대비 성능 곡선에서 의미 있는 위치를 차지한다.
다만 읽는 방식이 중요하다. OSWorld, AndroidWorld, ScreenSpot-Pro는 공개적으로 알려진 GUI·모바일·화면 grounding 평가 축이지만, H Corporate는 H Company가 만든 내부 벤치마크다. 공식 표에는 H Corporate 항목이 e-commerce, business software, collaboration, multi-apps로 나뉘어 있고, 실제 업무 흐름을 더 닮았다는 장점이 있다. 그러나 내부 벤치마크는 문제 구성, 검증 스크립트, 경쟁 모델 실행 조건을 외부에서 완전히 재현하기 어렵다.
또 하나의 주의점은 별표다. 공식 표 하단에는 일부 baseline 수치가 원 출처에서 가져온 값이고, OSWorld 수치는 내부 구현 기준으로 보고됐다는 설명이 붙어 있다. 이런 표는 방향을 보는 데 유용하지만, “우리 회사 업무에서도 80% 성공한다”로 번역하면 안 된다. 실제 도입에서는 우리 앱, 우리 계정, 우리 권한, 우리 하네스에서 다시 재야 한다.
왜 중요한가: 로컬 에이전트 경쟁의 기준이 바뀐다
지난 몇 달 동안 AI 에이전트 경쟁은 크게 두 방향으로 움직였다. 하나는 OpenAI Codex, Google Antigravity, Claude Code처럼 개발자가 쓰는 실제 작업 도구 안으로 들어가는 방향이다. 다른 하나는 RTX Spark, DGX Spark, 오픈웨이트 모델처럼 클라우드 밖 실행 환경을 넓히는 방향이다.
Holo3.1은 이 두 흐름의 교차점에 있다. 앞서 RTX Spark 기반 Windows AI PC 글에서 봤듯 로컬 에이전트는 하드웨어만으로 완성되지 않는다. PC 안에서 큰 모델을 돌릴 수 있어도, 모델이 화면을 보고 앱을 조작하며 실패를 복구하는 하네스가 없으면 실제 업무 자동화는 어렵다. 반대로 좋은 하네스가 있어도 모델이 모바일 화면, 데스크톱 앱, 여러 도구 호출 형식을 견디지 못하면 제품이 불안정해진다.
Holo3.1이 function-calling protocol과 structured JSON output을 함께 이야기하는 이유도 여기에 있다. 에이전트 제품을 만드는 팀은 모델 하나만 고르지 않는다. 화면 캡처, OCR 또는 VLM 입력, 도구 호출 스키마, 클릭·입력 실행기, human approval, rollback, 로그 저장, 평가 환경을 함께 고른다. Holo3.1은 이 전체 묶음에서 모델이 더 다양한 하네스에 붙을 수 있게 하려는 시도다.
NVIDIA의 Nemotron 3 Ultra 글에서 정리했듯 오픈웨이트 경쟁도 이제 “다운로드 가능한가”에서 끝나지 않는다. 어떤 하네스에서, 어떤 추론 서버에서, 어떤 보안 런타임으로, 얼마나 오래 일을 끝내는지가 더 중요해졌다. Holo3.1은 규모는 다르지만 같은 방향의 발표다. 모델 품질과 실행 스택을 같이 봐야 한다.
로컬 실행은 개인정보 장점만 있는 게 아니다
Holo3.1 발표에서 가장 눈에 띄는 숫자는 양자화와 속도다. H Company는 DGX Spark에서 NVFP4 W4A16이 FP8 대비 1.41배, BF16 대비 1.74배 total token throughput을 보였다고 설명했다. OSWorld 점수는 FP8과 NVFP4가 같고, BF16 full precision보다 약 2점 낮은 수준이라고도 밝혔다.
이미지 출처: H Company / Hugging Face 공식 블로그.
또 다른 공식 그래프에서는 로컬 추론의 agent request rate를 보여준다. DGX Spark에서 vLLM과 NVFP4 조합이 가장 높은 요청률을 냈고, fast harness에서는 average step time이 FP8 baseline 6.8초에서 3.3초로 줄었다고 설명한다. 이는 단순 토큰 속도보다 중요하다. 컴퓨터 유즈 에이전트는 한 번 답하고 끝나는 챗봇이 아니라, 화면을 보고 결정하고 클릭하고 다시 화면을 보는 루프를 반복하기 때문이다. 한 스텝이 7초 걸리는지 3초 걸리는지는 사용자가 “쓸 만하다”고 느끼는 기준을 바꾼다.
이미지 출처: H Company / Hugging Face 공식 블로그.
하지만 로컬 실행은 자동으로 안전해지지 않는다. 데이터가 외부 네트워크로 나가지 않는다는 점은 분명 장점이다. 그러나 모델이 사용자의 실제 화면, 브라우저 세션, 로컬 파일, 업무 앱을 조작한다면 위험은 더 가까워진다. 잘못된 클릭, 민감 정보 캡처, 결제 또는 삭제 작업, 프롬프트 인젝션, 로그에 남은 스크린샷이 모두 로컬 환경 안에서 발생할 수 있다.
즉 로컬은 “위험이 없다”가 아니라 “위험의 위치가 바뀐다”다. 클라우드 전송 리스크는 줄지만, 기기 권한과 화면 조작 리스크는 커진다. 그래서 Holo3.1 같은 모델을 실험할 때는 모델 점수만 보지 말고 권한 모델과 감사 루프를 먼저 설계해야 한다.
어떻게 써야 하나: 팀 도입 체크리스트
Holo3.1은 바로 제품에 꽂기보다 파일럿으로 검증하는 편이 맞다. 특히 컴퓨터 유즈는 실패 비용이 텍스트 생성보다 크다. 다음 기준을 먼저 정하자.
- 조작 가능한 앱 범위: 테스트 브라우저, 로컬 개발 서버, 데모 계정처럼 허용 앱을 좁힌다. 메일, 결제, 관리자 콘솔, 비밀번호 관리자, 고객 데이터 화면은 기본 금지로 둔다.
- 실행 위치: Holo Models API를 쓸지, Hugging Face 체크포인트를 내려받아 로컬 또는 사내 장비에서 돌릴지 구분한다. API는 빠르게 시작하기 좋고, 로컬은 데이터 경계와 운영 책임을 직접 가져간다.
- 하네스 기준: structured JSON output, function calling, 좌표 클릭, accessibility tree, screenshot loop 중 어떤 방식으로 도구를 호출할지 정한다. 모델 교체보다 하네스 교체가 더 큰 리스크가 될 수 있다.
- 승인 단계: 읽기 작업, 클릭 작업, 입력 작업, 제출 작업, 삭제·결제·권한 변경 작업을 나눠 사람이 승인해야 할 단계를 둔다.
- 로그 정책: 스크린샷, 도구 호출, 모델 응답, 실패 이유, 사용자 승인 기록을 어디에 저장하고 언제 지울지 정한다. 화면 캡처에는 개인정보가 들어갈 수 있다.
- 롤백 절차: 에이전트가 잘못 저장하거나 잘못 제출했을 때 되돌릴 수 있는 테스트 계정, 백업 데이터, dry-run 모드를 준비한다.
- 평가 세트: 공개 벤치마크 대신 우리 팀의 반복 업무 20~50개를 작은 평가 세트로 만든다. 성공률뿐 아니라 평균 스텝 수, 사람 개입 횟수, 실패 유형을 같이 본다.
개인 개발자라면 시작점을 더 작게 잡으면 된다. 로컬 웹앱 QA, 사내 데이터가 없는 데모 앱, 반복 클릭이 많은 설정 화면, 모바일 앱 테스트 계정처럼 실패해도 피해가 작은 작업부터 실험하는 편이 낫다.
지금 당장 쓸 수 있나
쓸 수 있는 경로는 두 가지다. H Company의 Holo Models API 페이지에는 holo3-1-35b-a3b 모델 ID, 65,536 토큰 컨텍스트, 최대 5개 이미지 입력, Apache 2.0 라이선스, 무료 tier 10 RPM, 100만 토큰당 입력 0.25달러와 출력 1.80달러 가격이 표시돼 있다. API로 빠르게 시험하려는 팀은 이 경로가 쉽다. 출처: Holo Models API.
오픈웨이트 실험은 Hugging Face 컬렉션에서 시작할 수 있다. 2026년 6월 4일 확인 기준 컬렉션에는 Holo-3.1-0.8B, 4B, 9B, 35B-A3B, 35B-A3B-NVFP4, 35B-A3B-GGUF, 35B-A3B-FP8 항목이 올라와 있다. 출처: Holo3.1 Hugging Face 컬렉션.
다만 일반 사용자가 “내 노트북에서 바로 ChatGPT처럼 편하게 쓴다”고 기대하기에는 아직 이르다. Holo3.1은 모델과 체크포인트 공개에 가깝고, 완성된 소비자 앱이라기보다 개발자와 기업이 하네스에 붙여 실험할 재료다. 로컬 컴퓨터 유즈의 대중화는 모델 공개만으로 오지 않는다. 설치, 권한, 화면 캡처, 승인 UI, 로그, 실패 복구가 제품 수준으로 정리되어야 한다.
관전 포인트
첫 번째 관전 포인트는 독립 검증이다. Holo3.1의 공식 수치는 인상적이지만, 내부 벤치마크와 특정 하네스 최적화가 섞여 있다. OSWorld, AndroidWorld, 실제 기업 앱, 오픈소스 하네스에서 외부 재현 결과가 쌓여야 한다.
두 번째는 small model의 실용성이다. 0.8B, 4B, 9B 모델이 정말 반복 업무의 일부를 맡을 만큼 안정적이라면 로컬 에이전트 비용 구조가 크게 바뀐다. 모든 작업에 35B나 122B급 모델을 쓰는 대신, 화면 grounding이나 단순 조작은 작은 모델이 처리하고 어려운 판단만 큰 모델로 넘기는 구조가 가능해진다.
세 번째는 하네스 표준화다. Holo3.1은 function calling과 JSON output을 모두 강조하지만, 실제 제품에서는 각 하네스의 좌표 체계, 실패 복구, 도구 호출 스키마가 다르다. 앞으로 컴퓨터 유즈 모델 경쟁은 모델 점수만이 아니라 “어떤 하네스와 함께 배포되는가”의 싸움이 될 가능성이 크다.
결론은 분명하다. Holo3.1은 AI가 내 PC와 스마트폰 화면을 직접 조작하는 방향으로 한 걸음 더 나아간 발표다. 하지만 핵심은 클릭 능력이 아니라 운영 능력이다. 화면을 보는 모델, 도구를 호출하는 하네스, 로컬 추론 인프라, 권한 관리, 감사 로그가 함께 맞물릴 때만 컴퓨터 유즈는 데모를 넘어 업무 도구가 된다.
출처와 더 읽을 거리
- Hugging Face Blog: Holo3.1: Fast & Local Computer Use Agents: Holo3.1 공개 원문으로, 모델 크기, AndroidWorld 개선 수치, 하네스 지원, FP8·Q4 GGUF·NVFP4 체크포인트, 로컬 추론 그래프를 확인할 수 있다.
- Holo3.1 Hugging Face Collection: Holo3.1 0.8B·4B·9B·35B-A3B와 GGUF·FP8·NVFP4 모델 항목을 직접 확인하고 다운로드 경로로 이동할 수 있는 공식 컬렉션이다.
- H Company: Holo Models API: Holo 모델 API의 모델 ID, 입력·출력 가격, 컨텍스트 길이, 이미지 입력 수, 무료 tier 조건을 확인할 수 있는 공식 제품 페이지다.
- H Company: Holo3: Holo3의 OSWorld-Verified 수치, H Corporate Benchmarks 구성, synthetic environment factory 설명을 통해 Holo3.1의 배경을 이해할 수 있는 공식 이전 발표다.
- OSWorld 공식 GitHub: 데스크톱 GUI 에이전트를 평가하는 OSWorld 벤치마크의 문제 설정과 평가 환경을 확인할 수 있는 원본 저장소다.
- AndroidWorld 논문: Android 앱 환경에서 멀티모달 에이전트를 평가하는 AndroidWorld 벤치마크의 설계와 한계를 확인할 수 있는 원문 논문이다.