버튼 이름과 DOM 구조가 바뀌는 화면에서는 MolmoWeb의 시각 접근이 유리할 수 있지만, 결정론적인 웹 자동화에서 DOM을 완전히 버릴 이유는 없습니다. 픽셀은 실제로 보이는 상태를 알려 주고, DOM은 정확한 값과 빠른 조작을 제공하므로 작업에 따라 선택하거나 함께 써야 합니다.
AI2의 MolmoWeb 저장소는 Molmo 2 기반 8B 시각 언어 모델이 브라우저 스크린샷을 보고 행동하도록 설계됐습니다. 입력은 화면 이미지와 URL, 페이지 제목, 최근 행동 이력입니다. 숨겨진 노드까지 읽는 대신 사람이 보는 좌표를 예측해 클릭하거나 입력합니다.
DOM에는 존재하지만 팝업 뒤에 가려졌거나 display 속성으로 숨은 요소가 있을 수 있습니다. 선택자 기반 스크립트는 노드를 찾았다는 이유로 성공처럼 보일 수 있지만, 스크린샷 기반 모델은 렌더링된 화면을 기준으로 판단합니다. Canvas나 오래된 사내 UI처럼 접근성 트리가 빈약한 환경도 시도할 수 있습니다.
그 대가는 매 단계 이미지 인코딩입니다. 작은 텍스트와 낮은 대비에서는 OCR 오류가 나고, 드래그, 슬라이더처럼 연속 좌표가 필요한 동작은 클릭보다 어렵습니다. 페이지 값 하나를 정확히 읽거나 API로 처리할 수 있는 작업까지 픽셀 추론으로 바꾸면 느리고 불확실해질 수 있습니다.
원문은 1,100개가 넘는 웹사이트에서 3만 개 이상의 인간 작업 궤적과 59만 개 하위 작업 데모를 모은 MolmoWebMix를 소개합니다. 상용 모델 결과만 증류하지 않고 실제 조작 데이터를 확보했다는 점이 중요합니다. 그래도 학습 사이트와 다른 언어, 해상도, 로그인 흐름에서는 성능이 달라질 수 있습니다.
WebVoyager에서 보고한 Pass@4 94.7%는 최대 네 번의 후보 또는 시도 중 하나가 성공하는 조건입니다. 한 번의 실행 성공률이나 비용과 같은 숫자가 아닙니다. Best-of-N을 늘리면 성공 가능성과 함께 GPU 시간, 브라우저 세션, 위험한 행동 후보도 늘어납니다.
8B는 폐쇄형 거대 모델보다 작지만 고해상도 스크린샷을 반복 처리하기에는 여전히 가속기 메모리와 시간이 필요합니다. 실시간 사용자 흐름에서는 한 단계의 지연이 전체 작업 길이에 누적됩니다. 4B와 8B 선택, 이미지 해상도, 최근 행동 이력 길이, 병렬 후보 수를 함께 측정해야 합니다.
원문 의사 코드는 캡처, 생성, 실행 루프를 설명할 뿐, 설치와 모델 로딩, 브라우저 권한, 성공 판정을 갖춘 완전 실행법이 아닙니다. 프로젝트의 데이터와 구조는 AI2 소개에서 확인하되 현재 저장소 릴리스와 맞춰야 합니다.
첫 시험은 공개 페이지에서 링크 찾기나 화면 요소 확인처럼 되돌릴 수 있는 일로 제한하는 편이 좋습니다. 좌표 정확도, OCR 숫자 오류, 평균 단계 수와 실패 후 복구를 기록하고 DOM 기반 기준선과 비교합니다. 결제, 삭제, 메시지 전송에는 실행 직전 화면을 다시 캡처하고 사람 승인을 받아야 합니다.
MolmoWeb은 DOM 변경에 덜 민감한 자동화 수단을 열지만, 사람이 보는 화면만으로 모든 웹 상태를 알 수 있는 것은 아닙니다. 관련 공개 보도와 기술 소개도 참고할 수 있으나, 도입 결론은 자체 사이트의 성공률과 실패 비용으로 내려야 합니다.
두 접근은 서로를 없애는 대체재보다 관측 수단이 다른 도구에 가깝습니다. API나 DOM에서 주문 번호, 가격, 상태값을 안정적으로 읽을 수 있다면 구조화된 값을 쓰는 편이 정확하고 저렴합니다. 반대로 Canvas, 원격 데스크톱, 잦은 A/B 테스트처럼 선택자가 계속 바뀌고 사용자가 보는 화면 자체가 판단 근거라면 시각 모델의 이점이 커집니다.
| 작업 조건 | 우선할 방식 | 이유 |
|---|---|---|
| 정형 입력 폼과 고정 API | DOM, API 자동화 | 값 검증과 재실행이 쉽다 |
| Canvas, 이미지형 UI | 화면 기반 에이전트 | 구조화된 노드가 부족하다 |
| 결제, 삭제, 권한 변경 | DOM 검증 + 화면 확인 + 사람 승인 | 잘못된 좌표의 피해가 크다 |
| 여러 사이트를 빠르게 탐색 | 화면 기반 후보 + 규칙 기반 확정 | 사이트별 선택자 유지비를 줄일 수 있다 |
실무에서는 먼저 DOM이나 API로 상태를 읽고, 찾지 못한 요소만 화면 모델에 넘기는 하이브리드 구성이 현실적입니다. 모델이 좌표를 제안하면 실행기는 클릭 직전의 스크린샷과 URL이 여전히 같은지 확인해야 합니다. 클릭 뒤에는 단순히 화면이 변했다는 사실이 아니라 예상한 문구, URL, 데이터가 나타났는지를 별도 규칙으로 판정합니다.
Pass@4는 최대 네 후보 가운데 하나라도 성공하면 통과하는 지표이므로, 사용자가 한 번 눌러 얻는 성공률과 다릅니다. 운영 평가에서는 첫 시도 성공률, 네 번 안의 성공률, 성공까지 걸린 평균 단계와 총 추론 시간을 나눠 적어야 합니다. 네 후보를 병렬로 실행할 수 없는 결제나 메시지 전송은 사실상 Pass@1이 더 중요한 업무입니다.
평가 세트도 무작위 페이지 몇 개로 끝내면 안 됩니다. 작은 글자, 팝업, 스크롤이 긴 페이지, 한국어와 영어 혼합 화면, 해상도 변화, 로그인 만료를 각각 묶어야 어떤 조건에서 성능이 무너지는지 보입니다. 학습에 포함됐을 가능성이 높은 유명 사이트와 사내 고유 UI도 분리합니다. 성공 여부는 모델 스스로 채점하게 두지 말고 URL, 백엔드 상태 또는 사람이 만든 정답으로 판정해야 합니다.
화면에 보이는 텍스트에는 외부 사용자가 심어 둔 지시문이 포함될 수 있습니다. 페이지의 문장을 시스템 지시처럼 따르지 않도록 입력과 정책을 분리하고, 허용한 도메인과 동작 목록 밖의 행동은 실행기가 차단해야 합니다. 비밀번호, 토큰, 개인정보가 있는 영역은 캡처 단계에서 가리거나 모델을 신뢰 경계 안에서 실행합니다.
재시도는 같은 좌표를 기계적으로 반복하지 않게 설계합니다. 실패하면 새 화면을 캡처하고, 페이지가 바뀌었는지 확인한 뒤, 정해진 횟수에서 중단해야 합니다. 작업별 최대 단계와 최대 시간, 클릭 금지 영역, 사람이 승인해야 할 동작을 정책으로 남기면 모델 교체 뒤에도 같은 기준으로 회귀 테스트할 수 있습니다.
좌표 실행기에는 화면 배율과 viewport를 함께 전달해야 합니다. 모델이 본 캡처와 실제 클릭 시점의 창 크기, 브라우저 zoom이나 sticky header가 달라지면 올바른 좌표도 다른 요소를 누를 수 있습니다. 캡처 id와 행동을 묶고, resize가 발생하면 예측을 폐기해 다시 판단하는 규칙이 필요합니다. 여러 tab을 쓰는 작업은 활성 tab과 origin을 매 단계 확인해야 잘못된 session에 값을 입력하는 사고를 막을 수 있습니다.
첫째, 현재 DOM 자동화가 자주 깨지는 읽기 전용 작업 20~50개를 고릅니다. 둘째, 기존 스크립트와 MolmoWeb 계열 모델을 같은 브라우저, 해상도에서 실행해 첫 시도 성공률과 복구율을 비교합니다. 셋째, 이미지 처리 시간과 GPU 비용을 단계별로 기록합니다. 넷째, 팝업과 네트워크 지연을 일부러 넣어 잘못된 클릭 뒤 중단되는지 확인합니다.
시각 방식이 더 높은 성공률을 보여도 유지보수 비용까지 바로 낮아졌다고 결론 내리면 안 됩니다. 모델과 브라우저 버전이 바뀔 때 다시 돌릴 평가 세트, 실패 화면 보관, 민감정보 마스킹과 승인 UI가 새 운영 비용으로 생깁니다. 그 비용까지 포함해 반복적으로 깨지는 선택자 관리보다 싼지 판단해야 합니다.
릴리스 전에는 같은 작업을 브라우저 배율, viewport, 언어와 계정 상태를 바꿔 반복합니다. 한 조건에서만 성공한다면 일반적인 웹 이해보다 화면 배치 기억에 의존했을 수 있습니다. 각 실행의 캡처 id, 선택한 좌표, 실행 뒤 URL과 검증 결과를 함께 남기면 실패를 재현하고 모델 교체 전후를 같은 기준으로 비교할 수 있습니다.
아닙니다. 모델은 다음 행동을 고르는 역할을 하고, 실제 브라우저 실행, 세션, 다운로드, 네트워크 제어에는 여전히 자동화 런타임이 필요합니다. 기존 도구 위에 시각적 판단 계층을 얹는 구성이 일반적입니다.
모델 크기만으로 판단할 수 없습니다. 양자화, 화면 해상도, 가속기 메모리와 한 작업의 단계 수에 따라 체감 지연이 크게 달라집니다. 대상 장치에서 캡처부터 행동까지의 p50, p95 시간을 직접 재야 합니다.
접근성 트리가 부족한 화면을 조작할 가능성은 넓히지만, 작은 글자, 낮은 대비를 안정적으로 읽는다는 뜻은 아닙니다. 오히려 접근성 속성을 이용할 수 있을 때는 화면 정보와 함께 쓰는 편이 정확합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.