UI-TARS는 DOM을 읽기 어려운 데스크톱, 캔버스, 모바일 화면에서는 유용하지만, 빠르고 결정적인 웹 테스트까지 Selenium이나 Playwright에서 모두 옮길 이유는 없습니다. 픽셀 기반 유연성이 필요한 구간과 절대 좌표 오작동의 비용을 함께 보고 써야 합니다.
UI-TARS는 Selenium을 대체할까: 픽셀 좌표 에이전트의 강점과 실패
화면을 픽셀로 보고 좌표를 고른다
기존 웹 자동화는 CSS 선택자, XPath와 접근성 트리로 요소를 찾습니다. UI-TARS는 스크린샷을 입력받아 로그인 글자나 아이콘을 시각적으로 인식하고 클릭할 절대 x, y 좌표를 출력합니다. DOM을 제공하지 않는 앱에서도 사람이 보는 요소를 대상으로 삼을 수 있다는 것이 가장 큰 차이입니다.
원문은 인지, 추론, grounding과 기억을 하나의 비전, 언어 모델에 통합한 “native GUI agent”로 설명합니다. 웹, 데스크톱과 모바일에서 클릭, 드래그, 스와이프와 키보드 입력을 공통 행동 공간으로 표현해 플랫폼마다 별도의 요소 선택 규칙을 만드는 부담을 줄이려는 구조입니다.
언제 픽셀을 보고 언제 DOM을 볼까
HTML 요소와 접근성 이름이 안정적인 로그인 폼, 회귀 테스트와 대량 입력은 선택자 기반 자동화가 재현성과 속도에서 유리합니다. 실패하면 어떤 요소를 못 찾았는지 구조적으로 알 수 있고 같은 상태에서 같은 행동을 반복하기 쉽습니다. 화면을 매 단계 모델로 해석하는 비용도 들지 않습니다.
반면 원격 데스크톱, 게임 캔버스, 이미지로 그린 버튼이나 여러 데스크톱 앱을 오가는 흐름은 DOM 선택자를 쓸 수 없습니다. 이때 UI-TARS 같은 픽셀 기반 방식이 사람이 보는 화면을 공통 인터페이스로 다루는 장점이 생깁니다. 하지만 유연한 인식과 결정적 실행은 같은 장점이 아니므로 각 구간의 실패 비용을 따로 봐야 합니다.
실무에서는 한쪽을 전부 고르기보다 안정적인 웹 구간은 기존 도구, 구조가 없는 구간만 화면 에이전트로 연결하는 혼합 흐름을 비교합니다. 경계에서 어떤 상태를 넘기는지 명확히 하고, 픽셀 단계가 실패하면 DOM 단계까지 반복 실행하지 않게 작업 ID를 둡니다. 대체라는 구호보다 구간별 도구 선택이 운영 위험을 줄입니다.
행동 전에 계획하고 결과를 다시 본다
UI-TARS는 화면을 보자마자 클릭만 내는 대신 목표를 하위 단계로 나누고 현재 화면과 다음 행동을 연결하는 thought-before-action 방식을 사용합니다. 다중 턴 강화학습을 통해 행동 결과를 새 화면에서 관찰하고 전략을 수정하는 흐름입니다. 긴 작업에서 이전 행동과 현재 상태를 이어 가는 메모리도 이 반복에 포함됩니다.
이 구조는 복잡한 목표를 다룰 여지를 주지만 생각 시간이 길수록 응답 지연과 계산량이 늘어납니다. 설명이 길고 논리적으로 보여도 좌표가 맞다는 보장은 없으므로 최종 행동과 화면 변화로 평가해야 합니다. 모델의 내부 서술을 성공 근거로 삼으면 안 됩니다.
좌표가 낡기 전에 무엇을 확인할까
스크린샷을 찍은 시점과 클릭을 실행하는 시점 사이에 로딩 표시, 광고나 팝업이 나타나면 같은 좌표가 다른 대상을 가리킬 수 있습니다. 화면 확대, 다중 모니터와 원격 세션의 해상도 변화도 좌표계를 바꿉니다. 모델이 버튼을 정확히 찾았더라도 실행 지연 때문에 행동은 실패할 수 있습니다.
행동 직전에 화면이 같은지 짧은 재확인을 하고, 클릭 후에는 예상한 텍스트, 창, 상태가 나타났는지 관찰합니다. 예상 변화가 없으면 같은 좌표를 무한 반복하지 않고 새 화면을 인식하거나 사람에게 넘깁니다. 드래그나 스와이프는 시작점뿐 아니라 경로 중간에 대상이 움직이는 실패도 별도로 시험합니다.
좌표 오류를 줄이려 화면을 고정해도 운영 환경이 달라지면 다시 실패할 수 있습니다. 여러 해상도, 확대 비율, 밝은, 어두운 테마와 언어에서 같은 작업을 반복합니다. 한 환경에 맞춘 성공률과 일반적인 GUI 이해 능력을 구분해야 합니다.
벤치마크와 로컬 모델 규모를 범위와 함께 읽는다
원문은 UI-TARS-1.5가 ScreenSpotPro에서 61.6%를 기록했고 Claude 3.7의 27.7%, GPT-4o의 23.4%보다 높았다고 보고합니다. 이 비교는 해당 버전과 벤치마크의 GUI grounding 결과이지, 실제 업무 전체 성공률이나 모든 경쟁 모델의 현재 성능을 뜻하지 않습니다.
또한 2B, 7B와 72B 모델 선택지를 소개하며 높은 성능의 큰 모델은 상당한 VRAM을 요구하고 작은 모델은 좌표 환각과 반복 클릭에 더 취약할 수 있다고 지적합니다. UI-TARS 저장소와 데스크톱 앱 저장소에서 자신이 쓸 버전, 모델과 실행 환경을 먼저 맞춰야 합니다.
벤치마크를 내 업무 성공률로 옮기려면
ScreenSpotPro의 grounding 점수는 화면에서 지시한 지점을 찾는 능력을 보여 주지만 로그인부터 파일 저장까지 여러 단계가 이어지는 업무 성공률과 같지 않습니다. 단계별 정확도가 높아도 긴 작업에서는 한 번의 오작동이 전체 실패로 이어질 수 있습니다. 벤치마크 수치는 해당 모델과 설정의 보고값으로 두고 자신의 작업 길이와 상태 변화를 다시 측정해야 합니다.
대표 업무를 짧은 단일 클릭, 여러 화면 탐색, 텍스트 입력, 스크롤과 되돌리기로 나눕니다. 작업 완료율, 단계당 지연, 잘못된 클릭, 반복 횟수와 사람 개입을 기록합니다. 쉬운 화면의 평균보다 결제, 삭제처럼 중요한 단계의 오작동률을 별도 공개해야 합니다.
큰 모델이 정확해도 지연과 GPU 비용 때문에 데스크톱 상호작용이 답답할 수 있고, 작은 모델이 빨라도 재시도가 늘어 총비용이 커질 수 있습니다. 같은 장비에서 모델 크기별 작업당 성공과 시간을 비교하고, 어려운 화면에만 큰 모델을 호출하는 라우팅도 기준선에 넣습니다.
실패하기 쉬운 화면부터 시험한다
절대 좌표는 스크린샷을 읽은 뒤 창 크기, 해상도, 애니메이션이나 팝업이 바뀌면 낡아집니다. 다음 시험을 고정된 성공 데모보다 먼저 해 보는 편이 좋습니다.
- 버튼이 이동하거나 같은 이름의 요소가 두 개일 때
- 로딩 중 화면이 바뀌고 클릭 대상이 사라질 때
- 해상도와 확대 비율을 바꿨을 때
- 한 단계가 실패한 뒤 무한 반복을 멈추는지
- 결제, 삭제 직전에 사람 승인을 기다리는지
정해진 웹 경로는 기존 도구로 빠르게 실행하고 DOM이 없거나 자주 변하는 일부 단계만 UI-TARS에 맡기는 혼합 구조가 합리적입니다. 화면 자동화의 성패는 데모 한 번이 아니라 작업당 성공률, 평균 단계, 잘못된 클릭, 지연과 복구 가능성으로 판단해야 합니다.
위험 행동에는 어떤 승인선을 둘까
텍스트 입력과 탐색은 잘못되어도 되돌리기 쉽지만 결제, 삭제, 메시지 전송과 권한 변경은 외부 상태를 바꿉니다. 이런 단계에서는 모델의 자연어 설명이 아니라 대상 계정, 금액, 파일 이름과 실행 행동을 구조적으로 다시 보여 주고 사람 승인을 기다려야 합니다. 승인 전에 마우스를 위험 버튼 위에 두지 않는 것도 오작동 가능성을 줄입니다.
한 번 승인된 행동을 재시도할 때는 새 승인이 필요한지 정합니다. 응답 화면을 잘못 읽고 결제 버튼을 두 번 누르는 식의 중복 부작용을 막기 위해 완료 상태와 작업 ID를 확인합니다. 예상 화면이 나타나지 않으면 더 공격적으로 클릭하는 대신 중단하고 스크린샷과 마지막 행동을 남겨야 합니다.
권한도 작업별로 나눕니다. 시험 계정과 샌드박스 문서에서 시작하고 운영 계정, 관리자 화면은 허용 목록 밖에 둡니다. 화면에 비밀이나 개인정보가 보이면 모델 입력과 로그에 어떻게 처리되는지 확인합니다. GUI를 볼 수 있다는 능력이 그 화면의 모든 행동 권한을 의미하지는 않습니다.
운영 로그에는 전체 화면을 무기한 쌓기보다 작업 ID, 모델 버전, 행동 전후의 필요한 상태와 승인 결과를 보존합니다. 스크린샷에 개인정보가 포함될 수 있으므로 접근 권한과 보존 기간을 정해야 합니다. 오류를 재현할 만큼의 근거와 화면 데이터 최소화 사이의 균형도 GUI 에이전트 도입 비용에 포함됩니다.
함께 읽으면 이해가 이어지는 글
- Bytebot은 Selenium을 대체할까: 1~3초 클릭 지연과 전체 데스크톱 권한 — Ubuntu 데스크톱을 화면, 마우스, 키보드로 조작하는 Bytebot의 장점과 클릭당 1~3초 지연, 모델 비용, 전체 계정 권한의 위험을 비교합니다.
- Browser-use는 셀렉터 자동화를 대체할까: 비용, 권한, 실패 복구 기준 — Browser-use가 LLM과 Playwright로 웹 작업을 수행하는 방식, 고정 셀렉터 자동화와의 차이, 토큰 비용, 권한, 재현성, 복구 기준을 정리합니다.
- 웹 스크래핑에 Chrome이 너무 무겁다면? Lightpanda가 맞는 작업 — 렌더링 화면을 버리고 DOM, JavaScript 실행에 집중한 Lightpanda의 구조, 벤치마크 수치와 스크린샷, 웹 API 호환성 한계를 정리합니다.
자주 묻는 질문
UI-TARS가 Selenium이나 Playwright를 완전히 대체하나요?
아닙니다. DOM과 접근성 트리가 안정적인 웹 테스트는 기존 도구가 더 빠르고 결정적일 수 있으며, 픽셀 기반 에이전트는 데스크톱, 캔버스처럼 구조를 읽기 어려운 구간에 선택적으로 쓰는 편이 좋습니다.
스크린샷에서 버튼을 찾으면 왜 잘못 클릭할 수 있나요?
모델이 좌표를 계산한 뒤 창 크기, 확대 비율, 애니메이션이나 팝업이 바뀌면 대상이 이동할 수 있으므로 행동 직전 화면 재확인과 클릭 후 상태 검증이 필요합니다.
결제나 삭제도 UI-TARS에 맡겨도 되나요?
최종 실행을 자동화하기보다 대상과 금액을 구조적으로 다시 확인하고 사람 승인을 받은 뒤 한 번만 행동하도록 제한하며, 반복 클릭과 실패 시 즉시 중단해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.