UI-TARS와 CloakBrowser, 에이전트 제품은 UI와 기억 계층에서 갈린다
모델보다 먼저 봐야 할 두 층: 실제 화면을 다루는 능력과 작업 맥락을 잃지 않는 능력
나는 에이전트 데모를 볼 때 먼저 모델 이름보다 실패 지점을 본다. 화면을 못 읽는지, 클릭을 엉뚱하게 하는지, 이전 세션의 결정을 잊는지. 결론부터 말하면 2026년 에이전트 제품 경쟁은 “더 똑똑한 모델” 한 줄로 설명되지 않는다. UI를 안정적으로 다루는 계층과 기억을 오래 유지하는 계층에서 실제 제품성이 갈린다.
UI-TARS와 CloakBrowser가 보여주는 신호는 화면 제어 쪽이다. agentmemory, LangGraph 체크포인트, 장기 메모리 흐름이 보여주는 신호는 지속성 쪽이다. 둘은 따로 보이지만 같은 질문으로 합쳐진다. 에이전트가 실제 업무 화면 위에서 멈추지 않고, 실패 후에도 이어서 일할 수 있는가?
범용 에이전트 데모는 이제 부족하다
지난 1년 동안 에이전트 데모는 대부분 비슷했다. 브라우저를 열고, 검색하고, 폼을 채우고, 간단한 결과를 요약한다. 처음 보면 인상적이다. 그런데 제품으로 쓰기 시작하면 바로 다른 문제가 보인다.
- 버튼이 조금만 바뀌어도 행동이 흔들린다.
- 로그인, 팝업, 권한 창, 캡차 주변에서 멈춘다.
- 긴 작업 중간에 실패하면 어디서부터 재개해야 할지 모른다.
- 하루 뒤 다시 부르면 어제 내린 판단과 작업 상태를 잃는다.
- 팀원이 넘겨받을 수 있는 형태의 기록이 남지 않는다.
이건 모델 벤치마크 문제가 아니다. 더 정확히는 제품 계층 문제다. 모델은 의사결정 엔진이고, 실제 제품은 그 엔진을 화면과 상태에 연결하는 구조다. 이 구조가 약하면 모델이 좋아도 사용자는 “가끔 신기하지만 믿고 맡기긴 어렵다”고 느낀다.
UI-TARS가 묻는 질문: 에이전트는 화면을 얼마나 잘 다루나
UI-TARS 계열 흐름이 중요한 이유는 단순히 “컴퓨터를 조작하는 AI”라서가 아니다. 포인트는 에이전트가 API가 없는 현실 세계와 만나는 접점이 결국 GUI라는 점이다. 많은 업무 도구는 여전히 버튼, 표, 모달, 드롭다운, 파일 선택기, 캔버스, 권한 팝업으로 구성된다.
전용 API가 있으면 좋다. 하지만 실무에서는 API가 없거나, 있어도 불완전하거나, 특정 관리자 화면에서만 가능한 작업이 많다. 이때 에이전트는 스크린샷과 접근성 트리, DOM, 브라우저 세션, 데스크톱 이벤트를 섞어 써야 한다. UI-TARS 같은 GUI 에이전트 스택이 주목받는 이유는 여기에 있다.
좋은 UI 제어층은 세 가지를 만족해야 한다.
- 관찰 정확도: 지금 화면에 무엇이 있고, 어떤 요소가 조작 가능한지 안정적으로 파악한다.
- 행동 정밀도: 클릭, 입력, 스크롤, 드래그 같은 행동을 의도한 위치와 순서로 실행한다.
- 회복 가능성: 예상과 다른 화면이 나오면 멈추고 다시 관찰한다.
세 번째가 특히 중요하다. 데모용 에이전트는 한 번에 맞히면 된다. 제품용 에이전트는 틀렸을 때 더 중요하다. 잘못된 버튼을 눌렀는지, 폼 저장이 실패했는지, 세션이 만료됐는지 알아차려야 한다. 화면 제어는 액션 생성이 아니라 관찰-행동-검증 루프다.
CloakBrowser가 묻는 질문: 브라우저는 충분히 현실적인가
CloakBrowser 쪽 신호는 조금 다르다. 여기서 핵심은 “에이전트가 브라우저를 쓴다”가 아니라, 자동화 브라우저가 실제 사용자 환경과 얼마나 가까운가다. 공개 설명 기준 CloakBrowser는 Playwright, Puppeteer, Selenium 같은 자동화 프레임워크와 함께 쓰는 Chromium 계열 접근을 내세운다. AI 브라우저 에이전트, 크롤링, 테스트, 컴퓨터 사용 시나리오를 염두에 둔 흐름이다.
이 문제는 생각보다 제품에 직접적이다. 브라우저 자동화가 너무 티 나면 사이트는 다른 응답을 준다. 봇 탐지에 걸리거나, 기능이 제한되거나, 로그인 플로우가 다르게 동작한다. 그러면 에이전트 품질을 평가하는 테스트 자체가 현실과 어긋난다.
물론 이 영역은 조심해서 봐야 한다. stealth browser라는 단어는 합법적 테스트와 악용 가능성이 같이 붙어 있다. 제품팀 입장에서 건강한 질문은 “탐지를 회피하자”가 아니라 “우리 에이전트가 실제 사용자 조건과 비슷한 환경에서 검증되고 있는가”다. 사내 QA, 접근성 점검, 자체 서비스 운영 자동화처럼 권한이 있는 범위에서 현실적인 브라우저 표면을 만드는 게 핵심이다.
여기서 UI-TARS와 CloakBrowser는 한 축으로 묶인다. 하나는 무엇을 보고 어떻게 조작할지를 묻고, 다른 하나는 그 조작이 일어나는 브라우저 표면이 현실적인지를 묻는다. 에이전트 제품의 UI 계층은 이 둘을 동시에 가져야 한다.
기억 계층이 없으면 긴 작업은 제품이 아니다
그다음 축은 기억이다. agentmemory나 LangGraph 체크포인트가 반복해서 언급되는 이유는 단순하다. 긴 작업은 한 번에 끝나지 않는다. 중간에 실패하고, 사람이 끼어들고, 다음 날 이어지고, 다른 에이전트나 팀원에게 넘어간다.
이때 필요한 건 대화 기록 전체를 무식하게 붙이는 게 아니다. 제품 수준의 기억 계층은 더 구조적이어야 한다.
- 작업 목표와 현재 단계
- 이미 시도한 행동과 실패 이유
- 사용자가 승인한 결정
- 다시 하지 말아야 할 실수
- 다음 실행자가 바로 이어받을 수 있는 handoff
- 장기적으로 쌓아야 할 사용자 선호와 프로젝트 규칙
이걸 구분하지 않으면 기억은 금방 쓰레기장이 된다. 모든 로그를 기억이라고 부르면 검색 비용만 늘고, 중요한 판단은 묻힌다. 반대로 너무 적게 남기면 에이전트는 매번 새로 태어난 것처럼 행동한다. 좋은 기억 계층은 “많이 저장”이 아니라 재개와 판단에 필요한 상태를 선별 저장하는 일이다.
체크포인트는 보험이 아니라 제품 기능이다
LangGraph의 checkpoint 흐름이 상징하는 건 단순한 개발자 편의가 아니다. 체크포인트는 긴 에이전트 작업에서 제품 기능에 가깝다. 사용자는 “처음부터 다시 해”보다 “아까 멈춘 데서 이어서 해”를 기대한다. 이 기대를 만족시키려면 에이전트의 내부 상태가 재현 가능해야 한다.
예를 들어 PR 리뷰 에이전트를 생각해보자. 좋은 리뷰어는 단순히 diff를 읽고 코멘트를 남기지 않는다. 어떤 파일을 봤고, 어떤 테스트를 신뢰했고, 어떤 리스크를 보류했는지 남긴다. 중간에 세션이 끊겨도 같은 판단 기준으로 이어갈 수 있어야 한다. 이건 내가 코드 리뷰에서 계속 보는 지점이다. 판단의 품질은 한 번의 출력보다 판단 이력의 추적 가능성에서 나온다.
그래서 기억 계층은 CRM 메모장 같은 부가기능이 아니다. 에이전트가 팀 작업자가 되기 위한 최소 조건이다. 기억이 없으면 자동화는 매번 단발성 스크립트로 돌아간다. 기억이 있으면 작업은 누적된다.
제품팀은 두 계층을 분리해서 설계해야 한다
여기서 가장 흔한 안티패턴은 “에이전트 플랫폼”이라는 큰 이름 아래 모든 문제를 한 덩어리로 묶는 것이다. 그렇게 하면 원인 분석이 흐려진다. 실패했을 때 모델이 부족한지, 브라우저 표면이 불안정한지, DOM 선택자가 깨졌는지, memory retrieval이 틀렸는지 구분하기 어렵다.
나는 제품팀이 최소한 아래처럼 나눠 봐야 한다고 본다.
| 계층 | 핵심 질문 | 실패 증상 | 개선 방향 |
|---|---|---|---|
| 모델 추론 | 다음 행동을 잘 판단하나 | 계획이 틀림 | 모델, 프롬프트, 평가셋 |
| UI 제어 | 화면을 안정적으로 관찰·조작하나 | 클릭 실패, 팝업 미대응 | GUI agent, browser runtime, validation |
| 기억 지속성 | 작업 상태를 이어가나 | 반복 질문, 재시작 실패 | checkpoint, structured memory, handoff |
| 정책·권한 | 해도 되는 일을 구분하나 | 위험 행동, 승인 누락 | permission boundary, audit log |
이 표에서 중요한 건 계층별 평가 기준이 다르다는 점이다. UI 제어층은 클릭 성공률, 화면 변화 검증, 브라우저 세션 안정성이 핵심이다. 기억 계층은 재개 성공률, 중복 행동 감소, handoff 품질이 핵심이다. 모델 벤치마크 하나로는 이 차이를 못 본다.
구매자는 “똑똑함”보다 “이어짐”을 산다
B2B 에이전트 제품에서 구매자가 진짜로 보는 건 똑똑함의 감탄사가 아니다. 업무가 이어지는지다. 오늘 처리한 고객 티켓 맥락을 내일 기억하는가. 어제 실패한 배포 검증을 다시 반복하지 않는가. 브라우저 UI가 조금 바뀌어도 멈추지 않고 다시 관찰하는가. 담당자가 바뀌어도 근거가 남아 있는가.
이 관점에서 UI-TARS, CloakBrowser, agentmemory는 각각 다른 프로젝트 이름이 아니라 같은 방향을 가리키는 신호다. 에이전트 시장이 “무엇이든 할 수 있다”는 데모에서 “특정 업무를 끝까지 이어간다”는 제품으로 이동하고 있다는 신호다.
한국 개발팀도 여기서 바로 바꿀 수 있는 게 있다.
- 브라우저 자동화 테스트를 실제 로그인·권한·팝업 조건에서 돌린다.
- 화면 조작 후에는 반드시 결과 화면을 다시 관찰하게 만든다.
- 장기 작업에는 checkpoint와 handoff 필드를 따로 둔다.
- 사용자 선호, 프로젝트 규칙, 일회성 작업 로그를 같은 저장소에 섞지 않는다.
- 에이전트 실패를 모델 탓으로 뭉개지 말고 UI·기억·권한 계층별로 분류한다.
이 다섯 가지를 해두면 모델을 바꾸지 않아도 제품 안정성이 올라간다. 반대로 이게 없으면 최신 모델을 붙여도 데모 품질은 좋아지고 운영 품질은 그대로일 가능성이 높다.
김덕환 운영자가 봤을 때 이 주제는 OpenClaw 운영과 바로 맞닿아 있다. 여러 에이전트가 각자 리뷰, 리서치, 글쓰기, 배포 검증을 맡는 구조에서는 모델보다 세션 기억, 작업 인수인계, 브라우저 검증, 실패 기록이 더 자주 품질을 가른다. log8.kr 같은 1인 운영 블로그도 결국 글 하나가 아니라 주제 선정, 작성, 이미지 프롬프트, 발행, KPI 확인까지 이어지는 작업 흐름을 얼마나 덜 끊기게 만드느냐가 중요하다.
결론은 단순하다. 2026년 에이전트 제품을 평가할 때 모델 이름만 보면 반쪽이다. 실제 화면을 다루는 UI 계층과 작업을 이어가는 기억 계층을 따로 봐야 한다. 제품은 똑똑한 답변에서 끝나지 않는다. 사용자의 화면 위에서 움직이고, 실패를 기억하고, 다음 실행에서 이어지는 순간부터 제품이 된다.