- Published on
Holo3.1: GUI 에이전트 경쟁이 클라우드 데모에서 로컬 실행으로 넘어간다
- Authors
- Name
- Kyunghyun Park
- @devkhpark
Holo3.1 · Computer Use Agent · Local Inference
H Company가 공개한 Holo3.1은 “GUI를 조작하는 모델이 더 좋아졌다” 정도로 읽으면 핵심을 놓친다. 이번 발표의 더 중요한 메시지는 computer-use agent의 경쟁축이 벤치마크 점수에서 배포 위치, 실행 비용, 프라이버시, 에이전트 하니스 호환성으로 이동하고 있다는 점이다.
Holo3.1은 Holo3의 후속 computer-use 모델군이다. H Company는 2026년 6월 2일 Hugging Face 블로그에서 Holo3.1을 공개하며, 웹·데스크톱·모바일 환경, 다양한 agent framework, 그리고 클라우드부터 완전 로컬 실행까지의 배포 대상을 모두 겨냥한다고 설명했다. 특히 처음으로 FP8, Q4 GGUF, NVFP4 같은 양자화 체크포인트를 함께 내놓은 점이 중요하다.
이 글은 Holo3.1 발표 글, Holo3 이전 발표, Holo3.1 컬렉션, 그리고 Hugging Face의 최근 로컬/도구형 에이전트 흐름을 보여주는 Reachy Mini 로컬 실행·MCP 도구 추가 글을 바탕으로, 한국 개발자와 AI 운영자가 실제로 무엇을 읽어야 하는지 정리한다.
기준 시점: 2026-06-04에 확인한 Hugging Face 및 H Company 공개 자료 기준이다. 모델 카드, 체크포인트, 벤치마크 수치, 라이선스와 사용 조건은 이후 바뀔 수 있으니 실제 도입 전 원문을 다시 확인해야 한다.
Holo3.1의 핵심은 “더 높은 점수”보다 “어디서든 돌릴 수 있는 GUI 에이전트”다
Holo3는 이미 2026년 4월 발표에서 OSWorld-Verified 78.85%를 내세우며 computer-use benchmark 선두권을 주장했다. H Company는 당시 Holo3가 10B active parameters, 122B total parameters 구조이고, synthetic enterprise environment와 agentic learning flywheel을 통해 실제 업무형 GUI 작업에 맞게 학습됐다고 설명했다.
Holo3.1은 그 다음 질문으로 넘어간다. “잘한다”는 것은 이제 출발점이고, 실제 도입에서는 아래 문제가 더 중요해진다.
- 브라우저 자동화에서는 잘하는데 데스크톱 앱에서는 흔들리지 않는가?
- 데스크톱에서는 되는데 모바일 UI에서는 실패하지 않는가?
- 특정 하니스에서는 잘하는데 다른 agent framework로 옮기면 깨지지 않는가?
- 모든 스크린샷과 액션 로그를 클라우드로 보내야만 하는가?
- 사내망, 개발자 노트북, 엣지 장비에서도 충분히 빠르게 돌릴 수 있는가?
Holo3.1 발표가 “environments, agent frameworks, deployment targets” 세 축을 반복해서 강조하는 이유가 여기에 있다. GUI 에이전트는 모델 하나가 아니라 환경 적응성 + 실행 하니스 + 배포 전략의 합으로 제품 품질이 결정된다.
모바일과 크로스-하니스 성능이 중요한 이유
Holo3.1에서 가장 눈에 띄는 공개 수치는 AndroidWorld다. H Company는 35B-A3B 모델이 AndroidWorld에서 67%에서 79.3%로 개선됐고, 4B·9B 계열도 58%에서 72%로 올라갔다고 밝혔다. 단순히 모바일 점수가 올랐다는 말이 아니다. 이것은 computer-use agent가 “브라우저 자동화 도구”에서 “일반 GUI 조작 계층”으로 넓어지고 있다는 신호다.
개발자 입장에서 이 변화는 꽤 실무적이다. 많은 내부 업무는 하나의 웹앱 안에서 끝나지 않는다. 사용자는 브라우저, 사내 SaaS, 네이티브 데스크톱 앱, 모바일 인증 앱, 메신저, PDF 뷰어, 스프레드시트 사이를 왔다 갔다 한다. GUI 에이전트가 이 흐름을 따라가려면 모델이 화면을 보는 능력만으로는 부족하고, 서로 다른 실행 환경의 미묘한 분포 차이를 버텨야 한다.
Holo3.1은 또 structured JSON output뿐 아니라 function-calling protocol 지원을 강조한다. 이 점도 중요하다. 실제 에이전트 시스템은 모델을 단독으로 부르는 것이 아니라 다음 계층과 붙는다.
- 화면 관찰과 스크린샷 캡처
- 좌표·DOM·접근성 트리 해석
- 클릭, 입력, 스크롤, 앱 전환 액션 실행
- 실패 감지와 재시도
- 도구 호출 및 워크플로 로그
여기서 모델 출력 형식이 특정 구현에 갇혀 있으면 도입 비용이 커진다. function-calling과 native execution의 성능이 가까워졌다는 H Company의 주장은, 모델을 기존 agent stack에 더 쉽게 끼울 수 있게 만들겠다는 방향으로 읽힌다.
양자화 체크포인트는 “비용 최적화”가 아니라 “프라이버시 아키텍처”다
이번 발표에서 가장 실무적인 대목은 양자화다. Holo3.1은 35B-A3B에 대해 FP8, Q4 GGUF, NVFP4 체크포인트를 공개했다. H Company는 NVFP4 W4A16 구성이 BF16 대비 OSWorld 점수 하락은 약 2포인트 수준이고, DGX Spark에서 FP8 대비 1.41배, BF16 대비 1.74배 total token throughput을 냈다고 설명한다. 또한 agent harness 최적화와 NVFP4를 결합하면 FP8 baseline 대비 end-to-end 평균 step time을 6.8초에서 3.3초로 줄이는 약 2배 개선을 보였다고 썼다.
이 수치를 마케팅 문장으로만 보면 아깝다. GUI 에이전트에서 latency는 단순 응답 시간이 아니다. 한 작업은 보통 “관찰 → 판단 → 액션 → 재관찰” 루프를 여러 번 돈다. 한 step이 7초에서 3초대로 내려가면 10단계 작업의 체감 시간은 완전히 달라진다. 실패 후 재시도까지 고려하면 더 그렇다.
더 중요한 건 프라이버시다. Holo3.1 발표는 Windows나 Mac에서 agent 자체를 로컬로 실행하고, 모델도 같은 머신 또는 같은 네트워크의 DGX Spark에서 돌릴 수 있다고 설명한다. 이 경우 실행은 private and local이며, 사용자 네트워크 밖으로 나가지 않는다는 것이다.
이건 기업 도입에서 결정적이다. GUI 에이전트는 보통 민감한 화면을 본다.
- 사내 ERP와 CRM
- 고객 정보가 들어간 티켓 시스템
- 회계·청구·계약 화면
- 브라우저 세션과 로그인 상태
- 내부 문서, 이메일, 메신저
이런 화면을 매 step 클라우드 모델로 보내는 구조는 보안 검토에서 막히기 쉽다. 반대로 로컬·사내망 실행 옵션이 있으면 “어떤 작업은 클라우드, 어떤 작업은 사내망, 어떤 작업은 완전 로컬”처럼 정책을 나눌 수 있다. Holo3.1의 양자화 체크포인트는 비용 절감 카드이기도 하지만, 더 본질적으로는 GUI 에이전트를 보안 경계 안으로 들여오기 위한 배포 카드다.
작은 모델군의 의미: 에이전트도 tiering이 필요해진다
Holo3.1 모델군은 네 가지 크기로 공개됐다.
| 모델 | 발표상 포지셔닝 |
|---|---|
| Holo3.1-0.8B | ultra-lightweight local agents |
| Holo3.1-4B | cost-efficient deployment |
| Holo3.1-9B | balanced performance and latency |
| Holo3.1-35B-A3B | state-of-the-art performance |
이 구성이 중요한 이유는 GUI 에이전트 작업이 모두 같은 난이도가 아니기 때문이다. 예를 들어 “정해진 웹 콘솔에서 상태 확인 후 버튼 누르기”와 “여러 앱을 오가며 계약 조건을 비교하고 메일을 작성하기”는 같은 모델로 처리할 필요가 없다.
실무에서는 다음처럼 나눠야 한다.
- 반복적이고 좁은 업무: 작은 모델 또는 로컬 모델
- 실패 비용이 낮은 보조 작업: 비용 효율 모델
- 긴 컨텍스트와 다중 앱이 필요한 업무: 큰 모델 또는 클라우드/엣지 고성능 모델
- 민감 데이터가 걸린 업무: 네트워크 밖으로 나가지 않는 로컬·사내망 모델
이런 tiering이 없으면 GUI 에이전트는 둘 중 하나가 된다. 너무 비싸서 파일럿을 못 벗어나거나, 너무 약해서 실제 업무에 못 들어간다. Holo3.1의 0.8B·4B·9B·35B-A3B 라인업은 “모든 작업을 최고 모델로 때리는 방식”에서 벗어나, 업무 난이도와 보안 요구에 따라 모델을 고르는 방향을 제안한다.
Hugging Face의 최근 흐름과 같이 보면 더 선명하다
Holo3.1만 따로 보면 H Company의 모델 발표다. 하지만 Hugging Face의 최근 글들을 같이 보면 더 큰 패턴이 보인다.
Reachy Mini 관련 글에서 Hugging Face는 로봇 대화 스택을 완전 로컬로 돌리는 방법을 소개했다. VAD, STT, LLM, TTS를 cascade로 묶고, llama.cpp·vLLM·Inference Endpoints·OpenAI-compatible provider를 선택할 수 있게 하는 식이다. 핵심은 “모델 하나”가 아니라 로컬 실행 가능한 전체 대화 루프다.
또 다른 Reachy Mini 글은 MCP를 통해 Hugging Face Spaces에 올라간 원격 도구를 로봇 앱에 붙이는 흐름을 설명한다. built-in robot tools는 로컬에 두고, 날씨·검색 같은 stateless capability는 Spaces로 빼며, profile별 tools.txt로 활성 도구를 통제한다. 여기서도 핵심은 모델 성능이 아니라 도구 경계, 배포 위치, 프로필 기반 권한 제어다.
Holo3.1은 이 흐름의 GUI 에이전트 버전으로 볼 수 있다. 즉 Hugging Face 생태계에서 반복되는 방향은 다음과 같다.
- 에이전트는 클라우드 API만이 아니라 로컬·엣지에서도 돌아가야 한다.
- 도구와 모델은 한 덩어리로 묶이지 않고 교체 가능해야 한다.
- 실시간/대화형/GUI 조작 루프에서는 latency가 제품 품질이다.
- 보안 경계 안에서 실행할 수 있어야 기업 도입이 가능하다.
이 관점에서 Holo3.1은 “또 하나의 오픈 모델”이라기보다, open AI infrastructure가 computer-use agent를 운영 가능한 제품 계층으로 밀어 올리는 사례다.
개발자와 운영자가 지금 확인해야 할 체크리스트
Holo3.1류 모델을 검토한다면, 벤치마크 표만 보고 판단하면 안 된다. 최소한 아래 질문을 먼저 던져야 한다.
1) 우리 업무는 어느 GUI 환경에 가까운가?
웹앱 중심인지, 데스크톱 앱이 많은지, 모바일 인증·승인 플로우가 섞이는지에 따라 평가 데이터가 달라져야 한다. OSWorld나 AndroidWorld 점수는 참고 지표일 뿐, 실제 내부 업무의 분포를 대체하지 못한다.
2) 에이전트 하니스는 무엇인가?
모델만 바꿔서는 제품이 되지 않는다. 관찰, 액션 실행, 재시도, 중단, 로그, 권한, human-in-the-loop를 어떻게 처리할지가 더 중요하다. Holo3.1이 function calling을 강조하는 것도 이 계층과 붙기 위해서다.
3) 민감 화면을 클라우드로 보낼 수 있는가?
보낼 수 없다면 로컬·사내망 inference가 필수다. 이 경우 Q4 GGUF, FP8, NVFP4 같은 체크포인트는 “있으면 좋은 최적화”가 아니라 도입 가능성을 좌우하는 조건이 된다.
4) 작업별 모델 tiering이 가능한가?
모든 작업을 35B-A3B로 돌릴 필요는 없다. 반대로 모든 작업을 4B로 처리하려고 하면 실패율이 운영 비용으로 돌아온다. 업무 난이도별 routing 정책이 필요하다.
5) 실패를 어떻게 감지하고 멈출 것인가?
GUI 에이전트는 틀린 답을 말하는 챗봇보다 위험할 수 있다. 실제 버튼을 누르고, 데이터를 수정하고, 메일을 보낼 수 있기 때문이다. 따라서 로그, 승인 단계, sandbox, rollback, rate limit, 권한 축소가 초기 설계에 들어가야 한다.
실무적 해석: GUI 에이전트의 승부처는 모델명이 아니라 운영 경계다
Holo3.1 발표에서 가장 중요한 변화는 “local”이라는 단어의 무게다. 지금까지 많은 GUI 에이전트 데모는 멋있지만 도입하기 어려웠다. 화면 데이터가 민감하고, step latency가 길고, 실패 처리 비용이 크고, 특정 브라우저 환경에만 맞춰져 있었기 때문이다.
Holo3.1은 이 병목을 정면으로 건드린다. 크기별 모델군, 양자화 체크포인트, local/private execution, cross-harness 지원, 모바일 성능 개선을 한 번에 묶었다. 이것은 computer-use agent가 실험실 데모에서 운영 시스템으로 넘어가려면 무엇이 필요한지를 꽤 명확하게 보여준다.
물론 아직 그대로 믿고 프로덕션에 넣을 단계는 아니다. 공개 수치는 H Company의 벤치마크와 설명에 기반하며, 실제 조직의 UI·권한·네트워크·업무 복잡도에서는 전혀 다른 실패가 나올 수 있다. 그러나 방향은 분명하다.
GUI 에이전트 경쟁은 “누가 가장 똑똑한가”에서 “누가 우리 보안 경계 안에서, 우리 업무 화면을, 충분히 빠르고 싸게, 반복 가능하게 조작하는가”로 이동하고 있다.
한 줄 결론
Holo3.1은 computer-use agent가 클라우드 데모를 넘어 로컬·엣지·사내망 배포를 요구받기 시작했다는 신호다. 한국 개발자와 AI 운영자에게 중요한 질문은 “이 모델이 몇 점인가”가 아니라, 우리 업무의 GUI·보안·지연시간 조건 안에서 어느 크기의 모델을 어디에 배치할 것인가다.