UI-TARS-desktop와 GUI 에이전트의 두 갈래 — ByteDance가 연 OS 레이어의 균열
UI-TARS-desktop와 GUI 에이전트의 두 갈래 — ByteDance가 연 OS 레이어의 균열
GUI 에이전트는 API 에이전트의 보조 카테고리인가, 아니면 결국 OS 레이어 자체를 다시 그리는 별개의 카테고리인가. 그리고 그 카테고리가 닫힌 SaaS가 아니라 데스크톱 오픈소스로 먼저 자리 잡는다면, 우리가 지금 평가해야 할 위험은 무엇인가.
도입 — 33,599개의 별이 의미하는 것
2026년 5월 첫 주 GitHub 트렌딩 위클리 상단을 ByteDance의 UI-TARS-desktop 저장소가 차지했다. 2025년 1월 19일에 공개된 이 저장소는 5월 3일 기준 33,599개의 스타와 3,334개의 포크를 기록 중이다. 1년 4개월 만에 기록한 숫자다. 같은 기간 GitHub에 올라온 수만 개의 AI 에이전트 프로젝트 중에서 이 정도 흡수력을 보인 것은 LangChain, AutoGPT, Claude Code 정도다. 단순한 데모 프로젝트가 아니라는 신호다.
저장소의 한 줄 설명은 의도적으로 광범위하다. “오픈소스 멀티모달 AI 에이전트 스택 — 최첨단 AI 모델과 에이전트 인프라를 잇는다(The Open-Source Multimodal AI Agent Stack: Connecting Cutting-Edge AI Models and Agent Infra).” 그러나 실제 제공물은 두 가지로 압축된다. 하나는 비전·언어 모델인 UI-TARS(현재 1.5-7B와 비공개 풀 사이즈), 다른 하나는 이 모델을 데스크톱에서 직접 마우스·키보드 제어로 변환해 주는 Electron 기반 런타임 UI-TARS-desktop이다. 모델은 Apache 2.0 라이선스로 Hugging Face에 공개되어 있고, 런타임 또한 같은 라이선스의 오픈소스다.
이 조합이 만들어 내는 카테고리는 지금까지 닫힌 SaaS로만 존재했던 것이다. OpenAI Operator는 2025년 초 공개된 이래 ChatGPT Pro 구독자에게만 접근이 열렸고, Anthropic의 Computer Use API는 Claude 모델을 클라우드에서만 호출 가능했다. 두 회사 모두 모델 가중치를 공개하지 않았고, 사용자의 화면 캡처는 자사 인프라를 거쳐 처리됐다. UI-TARS-desktop은 이 모든 가정을 뒤집는다. 모델을 로컬 GPU에 띄울 수 있고, 화면 캡처는 사용자의 머신 안에서만 흐르며, 어떤 액션이 실행되는지 코드 레벨에서 감사할 수 있다.
문제는 여기서부터다. GUI 에이전트가 클라우드 SaaS의 안전한 샌드박스를 떠나 사용자의 OS에 직접 손을 대기 시작하면, 우리가 지난 18개월간 “에이전트 안전”이라고 부르며 다뤄 온 시나리오들이 모두 다른 위상으로 이동한다. 프롬프트 인젝션은 더 이상 채팅창의 사고가 아니라 운영체제 권한의 사고가 되고, 잘못된 클릭은 더 이상 환불 가능한 거래가 아니라 복구 불가능한 파일 삭제가 된다. ByteDance가 연 이 균열은, 그래서 단순한 오픈소스 마케팅의 성공이 아니라 산업 카테고리의 분기점이다.
본문 1 — UI-TARS-desktop의 해부: 모델, 런타임, 벤치마크
먼저 무엇이 들어 있는지부터 정리하자. 저장소의 README와 Hugging Face 모델 카드를 교차 확인하면, UI-TARS-desktop은 세 개의 층으로 구성된다.
가장 아래는 모델이다. UI-TARS-1.5-7B는 70억 파라미터의 비전·언어 모델로, 2025년 4월 17일 v0.1.0 릴리스와 함께 공개됐다. 베이스는 ByteDance 내부의 Seed-VL 시리즈이고, 그 위에 GUI 스크린샷 대규모 데이터셋과 강화학습이 얹혀 있다. 논문 “UI-TARS: Pioneering Automated GUI Interaction with Native Agents”(arXiv:2501.12326, Yujia Qin 외 34인)에서 저자들은 이 모델을 “프레임워크가 아니라 네이티브 에이전트(native agent)“라고 부른다. 즉, GPT-4o를 외부에서 호출하면서 프롬프트와 도구 정의로 GUI 작업을 시키는 종래 방식이 아니라, 모델 자체가 스크린샷을 입력으로 받고 액션 토큰을 출력으로 뱉도록 처음부터 학습됐다는 뜻이다. 시스템 2형 추론, 작업 분해, 마일스톤 인식, 반성 사고가 학습 데이터에 포함됐다고 명시되어 있다.
벤치마크 수치는 카테고리 자체의 무게중심을 흔든다. OSWorld 100스텝 기준에서 UI-TARS-1.5-7B는 42.5점을 기록했고, OpenAI CUA는 36.4점, Claude 3.7은 28점이었다. ScreenSpot-V2에서는 94.2점으로 OpenAI 87.9, Claude 87.6을 앞섰다. 그라운딩 난도가 가장 높은 ScreenSpotPro에서는 격차가 더 극적이다. UI-TARS 61.6점에 OpenAI 23.4점, Claude 27.7점이다. 안드로이드 환경의 AndroidWorld에서도 64.2점으로 종전 최고치 59.5점을 갱신했다. 7B 파라미터의 오픈소스 모델이 클라우드 폐쇄 모델 두 곳을 한꺼번에 밀어낸 첫 사례다.
수치만 봐서는 의심이 들 수 있다. 벤치마크는 잘 받지만 실제 사용에서는 무너지는 모델은 흔하다. 그러나 v0.3.0 릴리스 노트(2025년 11월 5일)와 그 이후 베타 변경 로그를 따라가면, 이 프로젝트는 단순한 모델 데모가 아니라 운영을 위한 시스템이라는 점이 분명해진다. 스트리밍 도구 호출, 런타임 타이밍 통계, Event Stream Viewer, AIO 에이전트 샌드박스 지원, 원격 컴퓨터·브라우저 오퍼레이터까지 — 항목 자체가 “데모 영상용 시각 효과”가 아니라 “프로덕션에서 디버깅하려면 필요한 기능들”이다. 메인테이너 ulivz가 단독으로 677커밋을 기록하고 있고, 상위 5명 컨트리뷰터의 합산 커밋은 1,000건을 넘어선다. 한 사람의 사이드 프로젝트가 아니라 ByteDance 내부의 정식 팀이 운영한다.
두 번째 층은 **런타임 (UI-TARS-desktop 본체)**이다. Node.js 22 이상을 요구하고, Electron으로 패키징되며, npm·npx로 글로벌 설치한다. 핵심 동작은 단순하다. 사용자가 자연어로 작업을 지시하면, 런타임이 화면 캡처 → 모델 추론 → 좌표·키 액션 실행 → 다음 캡처라는 루프를 돈다. 모델은 로컬에 띄울 수도 있고, ByteDance Volcengine, Anthropic, 사용자 자체 엔드포인트 등 외부 API로도 연결할 수 있다. 즉, 모델 제공자에 대한 의존을 추상화한 멀티 백엔드 구조다. 이 점이 OpenAI Operator나 Claude Computer Use API와 결정적으로 다르다. 후자들은 모델과 런타임이 분리 불가능한 상태로 묶여 있다.
세 번째 층은 Agent TARS라 불리는 상위 프레임워크다. CLI와 웹 UI 두 가지 진입점을 제공하고, MCP(Model Context Protocol) 서버 통합을 기본으로 깔았다. 데모로 제시된 시나리오들은 항공권 비교 예약, 호텔 검색, VS Code 설정 자동화, GitHub 이슈 추적, 차트 생성 같은 현실적 워크플로다. 즉, 한 가지 모달리티에 매몰되지 않고 GUI·DOM·MCP를 하이브리드로 섞을 수 있는 브라우저 에이전트로 설계됐다.
이 세 층의 조합이 의미하는 바는 분명하다. ByteDance는 모델 가중치, 런타임 코드, 상위 프레임워크를 한 저장소에서 동시에 풀었다. 어느 한 층만 떨어트려서 다른 회사의 인프라에 끼워 넣는 것이 가능하고, 반대로 세 층을 그대로 받아 자체 데스크톱 에이전트로 출시하는 것도 가능하다. 닫힌 SaaS 진영이 한 번도 허용하지 않은 모듈성이 처음으로 산업에 등장한 것이다.
본문 2 — 두 진영의 트레이드오프: 닫힌 SaaS와 열린 데스크톱
GUI 에이전트는 이제 명확히 두 진영으로 갈라진다. 한쪽은 OpenAI Operator와 Anthropic Computer Use API로 대표되는 닫힌 SaaS 진영이고, 다른 한쪽은 UI-TARS-desktop과 그 파생물(Open Interpreter, Self-Operating Computer 등)이 형성하는 열린 데스크톱 진영이다. 양쪽의 트레이드오프는 단순한 기술적 선호의 문제가 아니라 책임과 비용의 분배 문제다.
닫힌 SaaS의 가장 큰 강점은 격리다. Anthropic의 Computer Use API는 Claude가 사용자의 실제 머신을 만지지 않는다. 클라우드의 Docker 컨테이너 안에서 가상 데스크톱을 돌리고, 그 화면을 캡처해 모델에게 입력하며, 액션은 그 컨테이너 안에서만 실행된다. OpenAI Operator도 마찬가지로 자체 클라우드 브라우저를 돌린다. 사용자의 로컬 환경은 안전하다. 잘못된 클릭이 사용자의 비밀번호 매니저를 건드릴 수 없고, 프롬프트 인젝션이 성공해도 사용자의 git 저장소를 망가뜨릴 수는 없다. 책임은 SaaS 제공자가 진다. SOC 2 보고서, 데이터 처리 약관, 안전성 평가 — 이 모든 것이 계약의 형태로 제공자에게 귀속된다.
대가는 명확하다. 첫째, 비용. Anthropic의 Computer Use는 입력 토큰당 표준 Claude 가격에 더해 화면 캡처 처리 비용이 누적된다. 평균적인 작업 한 건이 수십 회의 스크린샷·추론 루프를 돌기 때문에, 한 작업의 비용이 1달러를 우습게 넘긴다. 둘째, 응답 시간. 클라우드 왕복 + 모델 추론 + 가상 데스크톱 렌더링이 누적되어, 한 액션당 5초 이상이 일반적이다. 셋째, 폐쇄성. 사용자가 어떤 워크플로를 가지고 있는지가 모두 클라우드에 노출되고, 그 워크플로가 SaaS 제공자의 학습 데이터로 쓰이는지 여부는 약관에 의존한다. 넷째, 제한된 환경. 사용자의 실제 데스크톱·브라우저 확장·로그인 세션·로컬 파일에 접근하지 못하기 때문에, 격리된 가상 데스크톱에서 시연 가능한 것 외에는 거의 쓸모가 없다.
열린 데스크톱 진영은 이 네 가지 문제를 정확히 뒤집는다. UI-TARS-desktop을 로컬 GPU와 함께 운용하면 토큰 비용이 0에 수렴한다. 응답 시간은 화면 캡처와 추론을 거치지만 네트워크 왕복이 사라지므로 1-2초 수준으로 떨어진다. 사용자의 워크플로는 사용자의 머신을 떠나지 않는다. 그리고 가장 결정적으로, 사용자의 실제 브라우저 세션, 실제 파일 시스템, 실제 IDE에 직접 손을 댈 수 있다. 데모 영상에서 UI-TARS가 VS Code의 settings.json을 직접 편집하고 GitHub 이슈를 검색해 답글을 달 수 있는 이유가 여기 있다.
이 카테고리의 위험을 가장 잘 표현한 것은 GitHub 트렌딩 코멘트가 아니라, 같은 카테고리에 있는 다른 프로젝트의 메인테이너들이다. Open Interpreter의 Killian Lucas는 일찍이 “당신은 LLM에게 셸을 주는 것이 아니라, 당신의 셸을 당신이 통제할 수 없는 외부 텍스트의 함수로 만들고 있는 것이다(You are not giving the LLM a shell — you are making your shell a function of external text you do not control)“라고 적었다. UI-TARS-desktop의 경우 이 진단은 더 강하게 적용된다. 셸이 아니라 마우스·키보드 그 자체이기 때문이다. 사용자가 화면에 띄워 둔 어떤 텍스트(이메일 본문, 슬랙 메시지, 웹페이지 광고, PDF 본문)도 모델의 입력으로 흘러 들어가고, 그 입력은 다음 액션의 결정 근거가 된다. 즉, 화면에 보이는 모든 외부 텍스트가 잠재적 인젝션 벡터다.
ByteDance가 이 위험을 모르는 것은 아니다. README의 보안 권고는 짧지만 분명하다. “별도의 사용자 계정 또는 가상 머신에서 실행할 것을 강력히 권장(Strongly recommend running in a separate user account or VM).” 그러나 이 권고가 실제로 지켜지는 비율은 낮을 것이다. v0.1.0의 데모 영상은 모두 사용자의 메인 데스크톱에서 직접 시연됐고, 트위터·X 데모도 마찬가지였다. 권고와 실제 사용 사이의 이 간극이, 닫힌 SaaS 진영이 “그래서 우리는 클라우드에 가둔다”고 말하는 근거다.
여기서 GitHub Actions의 보안 청구서가 떠오른다. 지난주 nesbitt.io의 분석은 PyPI 패키지의 91%가 변경 가능한 태그로 외부 액션을 참조한다는 수치를 들이밀었고, 그 이유는 GitHub Actions의 기본값이 위험하기 때문이라고 진단했다. UI-TARS-desktop도 같은 함정을 향해 가고 있다. 기본 설치는 권한 분리를 강제하지 않고, 가상 머신 격리를 강제하지 않으며, 액션 화이트리스트도 없다. “권장한다(recommend)“는 문장은 GitHub의 permissions: {} 권고와 같은 운명을 맞을 가능성이 높다. 즉, 거의 아무도 따르지 않을 것이다.
그러나 이 위험을 이유로 카테고리 자체를 부정할 수는 없다. 닫힌 SaaS의 격리는 반대로 그 격리가 만든 무력함을 안고 있고, 사용자가 진짜로 원하는 것은 자신의 IDE와 브라우저에서 직접 도와주는 에이전트다. ByteDance가 33,000개의 스타를 모은 이유는 마케팅이 아니라, 개발자들이 그것을 원했기 때문이다.
본문 3 — OS 레이어의 충돌: Recall, AppleScript, 그리고 에이전트 런타임
GUI 에이전트가 데스크톱으로 내려오면 곧바로 다른 OS 통합 시도와 충돌한다. 가장 직접적인 충돌은 Microsoft의 Windows Recall이다. 2024년 처음 발표됐다가 보안 우려로 연기됐고, 2025년 말 ARM·x86 일부 기기에서 옵트인으로 다시 공개된 이 기능은, OS가 사용자의 모든 화면을 주기적으로 캡처해 인덱싱하고, 자연어 질의로 과거 작업을 검색할 수 있게 한다. UI-TARS-desktop은 같은 머신에서 거의 동일한 전제를 사용한다. 화면 캡처가 동작의 시작점이라는 전제다. 차이는 Recall이 검색용 인덱스를 만들고 멈추는 반면, UI-TARS는 캡처를 본 뒤 마우스·키보드를 움직인다는 것이다.
이 두 가지가 같은 머신에서 동시에 동작하는 미래는 어렵지 않게 그릴 수 있다. Recall이 만든 과거 화면 인덱스를 UI-TARS가 컨텍스트로 받아, “지난 화요일에 봤던 그 PR 다시 열어 줘”라는 명령을 실행하는 시나리오다. OS 벤더 입장에서는 두 기능을 분리할 이유가 없다. 그러나 사용자 입장에서는 화면 캡처와 액션 실행이 같은 OS 컴포넌트에 통합되는 순간, “에이전트의 실수”와 “OS의 결함”의 구분이 사라진다.
macOS 쪽은 다른 경로를 걷는다. AppleScript와 Accessibility API는 25년 가까이 OS 자동화의 표준이었지만, 두 가지 모두 정적 스크립트와 명시적 권한 부여를 전제로 한다. UI-TARS는 이 둘을 모두 우회한다. Accessibility API의 권한 다이얼로그를 한 번 통과하면, 그 이후 모든 동작은 모델의 추론에 위임된다. Apple은 2025년 6월 WWDC에서 “On-Device Foundation Model”을 공개하며 Apple Intelligence를 OS 차원으로 끌어올렸지만, 그 모델은 외부 액션을 직접 실행하지 않는다. 즉, Apple은 GUI 에이전트의 OS 통합을 의도적으로 늦추고 있다. 그 빈자리를 ByteDance와 같은 외부 프로젝트가 채우는 형국이다.
리눅스 데스크톱 쪽은 가장 자유롭고 가장 위험하다. Wayland와 X11 모두 화면 캡처와 가상 입력을 차단하기보다 허용하는 쪽으로 설계됐고, 사용자가 한 번 권한을 주면 끝이다. UI-TARS-desktop의 Linux 빌드가 가장 빠른 속도로 늘어나는 이유다.
이 세 OS의 그림을 합치면, GUI 에이전트가 사실상 새로운 OS 레이어가 되고 있다는 결론이 나온다. 운영체제 위에 동작하는 응용 프로그램이 아니라, 사용자와 운영체제 사이에 끼어드는 중간 레이어다. 이 위치는 이전에 셸, 윈도 매니저, 데스크톱 환경이 차지했던 자리다. 그리고 셸이 그러했듯이, 이 위치를 누가 차지하느냐가 향후 10년의 사용자 경험을 결정한다. ByteDance가 오픈소스로 먼저 자리를 잡았다는 것은, Microsoft·Apple·Google이 자사 OS에서 같은 자리를 다른 방식으로 공급하기 전에, 사용자들이 이미 ByteDance의 추상화에 길들여질 가능성을 만든 것이다.
실무자가 지금 평가해야 할 점은 다섯 가지로 압축된다. 첫째, 격리 정책. UI-TARS-desktop을 로컬 머신에 직접 설치할 것인지, 별도 사용자 계정에서 실행할 것인지, 가상 머신·컨테이너 안에 가둘 것인지부터 정해야 한다. 가상 머신을 권장한다. 둘째, 모델 백엔드 선택. 로컬 GPU에 7B 모델을 띄울 것인지, ByteDance Volcengine의 풀 사이즈 모델을 호출할 것인지, Anthropic·OpenAI의 모델을 같은 런타임으로 호출할 것인지. 각각 비용·지연·데이터 거버넌스가 다르다. 셋째, 액션 화이트리스트. 어떤 애플리케이션·디렉토리·URL에 대한 액션만 허용할 것인지를 명시적으로 정의해야 한다. README는 이 기능을 제공하지 않는다. 직접 구현하거나 외부 샌드박스에 의존해야 한다. 넷째, 감사 로그. v0.3.0의 Event Stream Viewer가 이 영역의 출발점이지만, 사고 이후 분석이 가능한 형태로 저장되는지를 별도로 확인해야 한다. 다섯째, 롤백 전략. 잘못된 액션이 실행됐을 때 무엇을 어떻게 되돌릴 것인지의 시나리오. 파일 시스템 스냅샷, git stash, 데이터베이스 트랜잭션 — 어떤 것이든, 에이전트의 액션이 시작되기 전에 정의되어 있어야 한다.
결론
처음의 질문으로 돌아가자. GUI 에이전트는 API 에이전트의 보조 카테고리인가, 아니면 별개의 카테고리인가. UI-TARS-desktop의 33,599 스타와 OSWorld 42.5점이 답한다. 별개의 카테고리다. API 에이전트(Claude Code, Cursor, Codex)는 텍스트와 도구 호출이라는 협소한 인터페이스 안에서 강력하지만, 화면이 본질인 작업 — 디자인, 레거시 GUI 애플리케이션 조작, 비표준 웹 인터페이스 — 에서는 무력하다. GUI 에이전트는 이 빈자리를 채우며, 그 채움의 방식은 OS 레이어 자체에 내려앉는 형태다.
그리고 그 카테고리가 닫힌 SaaS가 아니라 데스크톱 오픈소스로 먼저 자리 잡는다는 점이, 이번 ByteDance 사건의 핵심이다. OpenAI와 Anthropic이 세운 안전성 가드레일은 클라우드라는 격리 위에 서 있었다. 그 격리를 벗어난 진영이 산업의 표준이 되면, 가드레일은 사용자 개인이 직접 설치하고 검증해야 한다. GitHub Actions의 91% 미적용 통계가 가르쳐 준 것은, “권장한다”는 문장이 실제 안전을 만들지 못한다는 사실이다. UI-TARS-desktop의 가상 머신 권고도 같은 운명을 맞을 가능성이 매우 높다.
지금 평가해야 할 위험은 그래서 두 층이다. 단기적으로는 격리 없이 메인 데스크톱에 설치된 GUI 에이전트가 프롬프트 인젝션·잘못된 추론·악성 화면 콘텐츠로 일으킬 사고. 중기적으로는 OS 벤더(Microsoft Recall, Apple Intelligence, Google의 Gemini Nano)와 외부 에이전트 런타임(UI-TARS, Open Interpreter, Self-Operating Computer) 사이의 OS 레이어 쟁탈전, 그리고 그 과정에서 사용자가 떠안게 될 보안 책임의 재분배. 이 두 층을 동시에 보지 않으면, 우리는 또다시 “기본값이 위험한” 인프라를 18년치 청구서로 받아 들게 된다. ByteDance가 연 균열은 우리에게 그 청구서가 도착하기 전에 격리 정책과 액션 화이트리스트를 직접 설계할 시간을 잠시 벌어 준 것뿐이다. 그 시간이 얼마나 길지는 다음 분기 OpenAI Operator의 가격표와 Apple WWDC의 자동화 발표가 결정할 것이다.