[리뷰] 화면을 '이해'하는 AI의 등장: 셀레니움의 시대에 종말을 고할 바이트댄스 UI-TARS 아키텍처 딥다이브
개발자로 10년 구르다 보면, ‘자동화’라는 단어에 묘한 애증이 생기기 마련입니다. 다들 깊이 공감하시죠? 어제까지만 해도 CI/CD 파이프라인에서 완벽하게 돌아가던 E2E 테스트 스크립트가, 프론트엔드 신입 개발자가 무심코 추가한 div 태그 하나 때문에 시뻘건 에러를 뿜어내던 아침. Selenium이나 Appium으로 QA 테스트를 짜거나 데이터를 크롤링해 본 분들이라면, 화면 UI가 아주 조금만 바뀌어도 산산조각 나버리는 XPath와 CSS Selector 유지보수에 밤을 지새운 경험이 있을 겁니다.
최근 몇 년간 Playwright나 Cypress 같은 훌륭한 도구들이 등장했고, 심지어 LLM(대형 언어 모델)이 웹페이지의 DOM(Document Object Model)을 파싱해서 요소를 자동으로 찾아주는 프레임워크들도 우후죽순 쏟아졌습니다. 하지만 현업의 근본적인 갈증은 전혀 해소되지 않았습니다. DOM 트리가 미치도록 복잡하게 얽혀있는 사내 레거시 ERP나, 보안 이슈로 아예 DOM을 읽어올 수 없는 데스크톱 앱, 모바일 앱, 혹은 게임 화면 앞에서는 기존의 텍스트 기반 AI 에이전트들이 여전히 무력했으니까요.
그러던 중 작년 말, 앤스로픽(Anthropic)이 ‘Computer Use’ 기능을 발표했을 때 업계는 꽤 큰 충격을 받았습니다. AI가 사람처럼 눈으로 화면을 보고 마우스를 직접 움직인다는 개념은 훌륭했지만, 값비싼 API 호출 비용과 내부 로직을 알 수 없는 블랙박스라는 한계 때문에 엔터프라이즈 실무 환경에 당장 도입하기엔 망설여졌죠. 그런데 최근 틱톡의 모회사인 바이트댄스(ByteDance)와 칭화대학교 연구진이 꽤 무서운 물건을 오픈소스로 풀어버렸습니다. 바로 UI-TARS(User Interface - Task Automation and Reasoning System)입니다. 단순한 자동화 툴이 아니라, 인간과 컴퓨터의 상호작용 ‘생태계’ 자체를 장악하려는 야심이 엿보이더군요. 오늘은 공식 문서나 깃허브 리드미에 적힌 뻔한 마케팅 용어는 걷어내고, 이 녀석이 대체 내부적으로 어떻게 돌아가길래 무서운 기세로 GPT-4o와 Claude를 벤치마크에서 찍어 누르고 있는지, 현업 시니어 개발자의 시선에서 아주 딥(Deep)하게 파헤쳐 보겠습니다.
TL;DR (바쁜 현대인을 위한 핵심 요약)
UI-TARS는 복잡하고 깨지기 쉬운 DOM 파싱 없이, 사용자가 보는 ‘순수 화면(Screenshot)’ 자체를 인식하여 스스로 생각하고 사람처럼 마우스와 키보드를 제어하는, Qwen-2-VL 기반의 오픈소스 네이티브 GUI 에이전트(Native GUI Agent)입니다.
Deep Dive: Under the Hood (핵심 아키텍처 분석)
기존의 LLM 기반 에이전트들은 주로 ‘프롬프트 엔지니어링’과 ‘외부 툴(Wrapper)’의 결합에 의존했습니다. 화면의 HTML DOM을 엄청난 길이의 텍스트로 변환해서 LLM에게 던져주면, LLM이 “id가 ‘submit-btn’인 요소를 클릭해”라고 텍스트로 응답하고, 외부의 파이썬 스크립트가 그걸 받아 Playwright 로직으로 실행하는 식이죠. 이 방식의 치명적인 단점은 DOM 텍스트가 컨텍스트 윈도우(Context Window)를 엄청나게 낭비한다는 것과, 시각적 레이아웃(이 버튼이 화면 왼쪽 위에 있는지, 아니면 팝업창 뒤에 숨겨져 있는지)을 텍스트만으로는 직관적으로 알기 어렵다는 점입니다.
반면, UI-TARS는 외부 컴포넌트를 덕지덕지 이어 붙인 프레임워크를 거부합니다. 인지(Perception), 추론(Reasoning), 접지(Grounding), 기억(Memory)이라는 에이전트의 4대 핵심 요소를 단 하나의 시각-언어 모델(Vision-Language Model) 내부에 완전히 통합해버렸습니다. 이를 ‘네이티브 GUI 에이전트’라고 부릅니다.
1. 텍스트가 아닌 ‘순수 픽셀’ 기반의 인지 (VLM Perception) UI-TARS의 뼈대는 Qwen-2-VL 모델입니다. 최근 발표된 UI-TARS-2 아키텍처를 뜯어보면, 532M 파라미터 수준의 강력한 비전 인코더(Vision Encoder)를 포함한 Mixture-of-Experts (MoE) 트랜스포머를 채택했습니다. 즉, 시스템은 HTML 소스코드를 읽는 게 아니라 여러분이 모니터로 보는 스크린샷 이미지 자체를 입력받습니다. 여기서 기술적 난이도가 가장 높은 부분이 바로 GUI Grounding(객체 위치 지정)입니다. 화면 속 ‘로그인’이라는 글자나 돋보기 모양의 아이콘을 모델이 시각적으로 이해하고, 화면상의 정확한 절대 좌표(Absolute Coordinates, x와 y)를 출력해 내는 능력입니다. 바이트댄스 연구진은 수많은 GUI 화면 데이터를 학습시켜, UI-TARS-1.5 버전에서 어려운 난이도로 악명 높은 ScreenSpotPro 벤치마크 점수를 61.6%까지 끌어올렸습니다. 이는 Claude 3.7(27.7%)이나 GPT-4o(23.4%)를 압도적으로 상회하는 수치입니다.
2. 생각하고 행동하라: System-2 추론과 다중 턴 강화학습 (Reasoning & RL) 개인적으로 아키텍처를 뜯어보며 가장 감탄했던 부분이 바로 이 지점입니다. UI-TARS는 일반적인 VLM처럼 스크린샷을 보고 반사적으로 click(x:150, y:300)을 뱉어내지 않습니다. 대신 ‘행동 전 사고(Thought-before-action)’ 메커니즘을 강화학습(Reinforcement Learning)으로 깊게 녹여냈습니다.
내부적으로 모델은 System-1(빠르고 직관적인 판단)과 System-2(느리지만 논리적인 계획 수립)를 병행합니다. 예를 들어, “다음 달 5일 서울에서 뉴욕 가는 가장 저렴한 왕복 항공편을 예매해 줘”라는 자연어 명령을 받으면, 모델은 액션을 취하기 전에 아래와 같은 <Thought> 토큰을 생성하며 스스로 태스크를 잘게 쪼개고 반성(Reflection)합니다.
[Thought]
- 사용자가 내일 서울(SEL)에서 뉴욕(NYC)으로 가는 항공편을 찾고 있다.
- 현재 화면은 바탕화면이다. 우선 브라우저를 열어야 한다.
- 크롬 브라우저 아이콘이 좌표 [452, 910]에 위치해 있다. 더블클릭하자.
[Action]double_click(452, 910)
이러한 구조 덕분에, 추론 시간(Inference-time)을 길게 허용할수록 모델이 더 깊게 생각하고 전략을 수정하며, 게임이나 복잡한 웹 환경에서 성공률이 비약적으로 상승하는 ‘스케일링 법칙(Scaling Law)’을 증명해냈습니다. 마치 실력 있는 시니어 개발자가 디버깅할 때 무작정 코드를 고치는 게 아니라, 로그를 보고 가설을 세운 뒤에 키보드에 손을 올리는 것과 같은 이치입니다.
3. 통합된 액션 공간 (Unified Action Space) 기존 프레임워크들은 브라우저용, 윈도우용, 안드로이드용 드라이버를 각각 따로 관리해야 했습니다. 하지만 UI-TARS는 플랫폼의 경계를 허물었습니다. 클릭, 드래그, 스와이프, 키보드 타이핑 등 인간의 물리적 인터페이스 액션을 표준화된 시맨틱으로 통합하여 데스크톱, 브라우저, 심지어 모바일(Android World) 환경에서도 동일한 정책(Policy)으로 동작하게 만들었습니다.
| 비교 항목 | 기존 DOM 기반 에이전트 (예: LangChain + Playwright) | UI-TARS (Native GUI Agent) |
|---|---|---|
| 입력 및 인지 방식 | HTML DOM Tree, Accessibility Tree 파싱 의존 | 순수 화면 픽셀 (스크린샷) + 사용자의 자연어 지시 |
| 위치 파악 (Grounding) | CSS Selector, XPath, ID 등 텍스트 메타데이터 의존 | VLM이 시각적 요소를 직접 분석해 화면 절대 좌표(x, y) 도출 |
| 플랫폼 유연성 | DOM이 난독화되거나 Canvas, Flash 기반 환경에서는 무용지물 | 화면에 보이기만 하면 제어 가능 (데스크톱 앱, 원격 환경, 게임 모두 가능) |
| 아키텍처 구조 | LLM + 외부 스크립트 도구의 느슨한 결합 (결합도 낮으나 유지보수 어려움) | 인지-추론-행동이 단일 모델에 내재화된 종단간(End-to-End) 통합 모델 |
Hands-on / Pragmatic Use Cases (그래서 실무에 어떻게 쓰는데?)
아무리 이론이 훌륭해도 실무에 쓸 수 없으면 장난감에 불과하죠. UI-TARS는 단순 논문 발표에 그치지 않고, UI-TARS-desktop이라는 오픈소스 앱과 데스크톱 에이전트 스택을 GitHub에 공개했습니다. 이를 현업에 창의적으로 적용할 수 있는 시나리오를 고민해 보았습니다.
1. 지옥의 레거시 시스템 RPA (로봇 프로세스 자동화)의 진화 금융권이나 공공기관 프로젝트를 뛰어보신 분들은 아실 겁니다. API는 당연히 제공되지 않고, 화면은 구형 XPlatform이나 투사체로 렌더링되어 있어 DOM 접근 자체가 원천 봉쇄된 시스템들. 기존의 RPA 툴들은 화면 좌표를 하드코딩하거나 템플릿 매칭 이미지 인식에 의존했기 때문에, 모니터 해상도나 테마가 조금만 바뀌어도 파업을 선언했습니다. 반면, UI-TARS는 시각적 문맥(Context)을 이해하고 버튼을 찾기 때문에, UI 레이아웃이 유동적으로 변해도 유연하고 끈질기게 목표를 달성해 냅니다.
2. 멀티 디바이스를 넘나드는 End-to-End QA 테스트 가장 기대되는 분야입니다. ‘웹 브라우저에서 상품을 주문하고 -> 모바일 앱에서 푸시 알림을 확인한 뒤 -> 관리자용 데스크톱 클라이언트(C# WPF 등)에서 승인 처리를 하는’ 복잡한 시나리오를 상상해 보세요. 기존에는 Web, Android, Windows 용 자동화 환경을 각각 구축해야 했습니다. 하지만 UI-TARS-desktop 앱과 최근 통합된 MCP(Model Context Protocol) 툴을 활용하면, 하나의 에이전트에게 플랫폼을 넘나드는 지시를 내릴 수 있습니다. “웹에서 결제하고 로컬 폴더에 영수증 PDF 다운받아서 메일로 보내줘” 같은 통합 워크플로우가 단일 스택에서 가능해진 것이죠.
Honest Review (진짜 장단점: 칭찬만 하면 AI 같습니다)
물론, 아직 핑크빛 미래만 펼쳐진 것은 아닙니다. 기술 칼럼니스트로서 로컬 환경에서 테스트해보며 느낀 뼈아픈 한계와 트레이드오프(Trade-off)를 날카롭게 짚고 넘어가겠습니다.
1. 무자비한 하드웨어 요구사항 (VRAM 킬러) UI-TARS는 2B, 7B, 72B의 세 가지 파라미터 모델을 제공합니다. 당연히 벤치마크에서 SOTA를 갱신하며 GPT-4o를 이긴 모델은 72B 버전입니다. 하지만 72B 모델을 로컬에서 구동하려면 막대한 VRAM을 갖춘 초고가 GPU 서버가 필요합니다. 일반적인 개발자의 맥북 프로나 적당한 그래픽카드로는 2B나 7B 모델을 겨우 띄우는 수준인데, 이 소형 모델들은 종종 심각한 환각(Hallucination)에 빠집니다. 예를 들어 “장바구니 버튼 클릭해”라고 지시했는데, 엉뚱한 배경 텍스처를 버튼으로 착각하거나, 자신이 무슨 행동을 했는지 까먹고 무한 클릭 루프(Thought Loop)에 빠지는 현상이 잦았습니다.
2. 절대 좌표 방식이 가지는 치명적인 딜레이와 불안정성 모델이 출력하는 값은 화면의 ‘절대 좌표’입니다. 만약 해상도가 동적으로 변하거나, 사용자가 중간에 창 크기를 조절해 버리면 모델이 내뱉은 좌표는 완전히 무용지물이 됩니다. 모델이 스크린샷을 분석하고, 내부적으로 System-2 추론을 거쳐 좌표를 계산해 내는 데까지 수 초의 딜레이가 발생하는데, 그 사이 UI에 애니메이션이 있거나 로딩 스피너가 돌고 있으면 에이전트는 허공에 헛클릭을 하게 됩니다. 사람처럼 마우스 커서를 실시간으로 피드백 받으며 움직이는 동적인 제어가 아니라, [정지 화면 분석 -> 긴 사색 -> 즉시 이동 및 클릭] 방식이기 때문에 발생하는 아키텍처적 한계입니다.
3. 과연 이 비용을 태울 가치(ROI)가 있는가? 결정적으로, 여전히 Playwright나 Selenium으로 0.1초 만에 끝날 확정적인(Deterministic) 테스트나 크롤링을, 굳이 무거운 VLM을 메모리에 띄워가며 매 턴마다 5초씩 기다려서 수행할 필요가 있을까요? 에이전트의 유연성은 압도적이지만, 그 대가로 지불해야 하는 추론 지연(Latency)과 컴퓨팅 비용은 현업 기획자와 개발자가 치열하게 저울질해야 할 숙제입니다.
Closing Thoughts: 프레임워크의 시대가 저물고, 모델의 시대가 온다
이러한 초기 버전의 뚜렷한 한계들에도 불구하고, UI-TARS가 우리 생태계에 던지는 묵직한 메시지는 명확합니다. “AI 에이전트의 발전은 여러 외부 툴과 코드를 이어 붙인 조립식 프레임워크에서, 모든 인지능력과 추론 능력이 내재된 통합 모델(Integrated Model)로 이동하고 있다”는 것입니다.
시니어 개발자로서 우리는 이제 ‘어떤 Selector를 써서 요소를 찾고, 예외 처리를 어떻게 할까’를 고민하던 시대를 지나, ‘에이전트에게 어떤 맥락(Context)과 운영 환경을 제공해야 실수 없이 컴퓨터를 자율적으로 제어하게 만들까’를 설계하는 상위 수준의 아키텍트로 넘어가야 할 때가 왔습니다.
비록 지금 당장은 로컬 환경에서 버벅대며 엉뚱한 곳을 클릭하는 에이전트를 보며 헛웃음이 나올지언정, 향후 1~2년 뒤 VLM의 추론 속도와 최적화가 극한으로 이뤄진다면 우리의 일상은 완전히 바뀔 것입니다. 아마 우리는 터미널을 열고 파이썬 스크립트를 짜는 대신, 컴퓨터 모니터 앞에서 커피를 마시며 UI-TARS 기반 에이전트에게 이렇게 말하고 있을지도 모릅니다.
“어제 빌드된 릴리즈 버전 서버에 올리고, 데스크톱 클라이언트랑 안드로이드 앱 켜서 결제 프로세스 한 번 쭉 테스트해 줘. 터지면 로그 분석해서 슬랙으로 쏴주고, 난 좀 쉴게.”
셀레니움과 작별할 준비가 되셨나요? 새로운 패러다임의 파도는 이미 밀려오고 있습니다. 다가오는 주말, 먼지 쌓인 개인 GPU 서버를 켜서 깃허브에 올라온 UI-TARS 7B 모델이라도 한 번 직접 로컬에 띄워보시는 건 어떨까요? 언제나 그렇듯, 백 번의 공식 문서 읽기보다 한 번의 삽질이 더 확실한 트렌드 분석이니까요.
References
- https://github.com/bytedance/UI-TARS
- https://github.com/bytedance/UI-TARS-desktop
- https://ui-tarsai.com/
- https://seed-tars.com/
