AI는 웹페이지를 어떻게 이해하는가
우리는 흔히 "AI가 사람처럼 브라우저를 쓴다"라고 말합니다. 하지만 이 표현을 그대로 받아들이면 중요한 차이를 놓치게 됩니다. AI는 사람의 눈과 뇌를 그대로 복제해 웹페이지를 읽는 것이 아닙니다. 대신 브라우저가 이미 갖고 있는 여러 중간 표현, 즉 구조 정보와 의미 정보, 시각 정보, 실행 중 상태를 조합해 페이지를 이해합니다.
사람은 버튼의 색, 위치, 문구, 문맥을 거의 동시에 파악합니다. 반면 AI는 보통 DOM, 접근성 트리, 스크린샷, 상호작용 가능한 요소 목록 같은 표상을 차례로 또는 함께 받아 해석합니다. 최신 브라우저 에이전트는 이들을 상황에 따라 섞어 씁니다.15
이 장의 핵심은 단순합니다. AI가 브라우저를 잘 쓴다는 말은, 결국 웹페이지를 기계가 다루기 좋은 형태로 바꿔 읽는다는 뜻입니다. 그 중간 표현이 무엇인지 이해하면, 왜 어떤 사이트에서는 에이전트가 매끄럽게 동작하고 어떤 사이트에서는 갑자기 헤매는지도 훨씬 선명하게 보이기 시작합니다.
웹페이지는 한 겹이 아니라 여러 겹이다
우리가 브라우저에서 보는 한 화면 뒤에는 여러 층이 겹쳐 있습니다.
HTML과 DOM은 페이지의 구조와 속성을 담고 있습니다.
접근성 트리는 그중 의미 있는 요소를 추려 "이건 버튼, 이건 링크, 이건 입력창"처럼 정리합니다.
스크린샷은 실제로 렌더링된 결과, 즉 눈에 보이는 화면을 보여줍니다.
실행 중 상태는 현재 포커스, 로딩 여부, 팝업 등장, 비활성화 상태 같은 동적 변화를 말합니다.
사람은 이 층을 따로 의식하지 않습니다. 그냥 "오른쪽 아래에 로그인 버튼이 있네" 하고 넘어갑니다. 하지만 에이전트는 이 층들을 따로 읽고 다시 합쳐야 합니다. 그래서 브라우저 에이전트의 성능은 모델 자체의 능력뿐 아니라, 어떤 층을 어떤 순서와 밀도로 읽게 하느냐에도 크게 좌우됩니다.
DOM: 정보는 풍부하지만 잡음도 많다
DOM은 브라우저가 HTML 문서를 내부적으로 표현하는 트리 구조입니다. 요소, 속성, 텍스트 노드가 모두 들어 있고, 자바스크립트가 페이지를 바꾸면 DOM도 함께 바뀝니다.1 개발자 입장에서는 거의 모든 것을 담은 원본에 가깝습니다.
문제는 바로 그 "거의 모든 것"입니다. 현대 웹페이지는 수많은 래퍼 div, 스타일용 span, 프레임워크가 만든 보조 노드, 숨겨진 템플릿, 장식용 요소를 품고 있습니다. 에이전트에게 정말 중요한 것은 몇 개 안 됩니다. 눌러야 할 버튼, 읽어야 할 제목, 입력해야 할 필드, 선택해야 할 메뉴 정도입니다. 그런데 DOM에는 핵심 정보와 잡음이 한데 섞여 있습니다.4
예를 들어 회원가입 페이지를 떠올려 봅시다. 사람 눈에는 이름, 이메일, 비밀번호, 가입 버튼이면 충분합니다. 하지만 DOM에는 레이아웃용 컨테이너, 아이콘 래퍼, 애니메이션 요소, 숨겨진 템플릿 노드까지 길게 따라붙을 수 있습니다. AI가 DOM 전체를 통째로 읽는다면, 중요한 문장 몇 줄을 찾기 위해 장황한 소스코드를 처음부터 끝까지 훑는 셈이 됩니다.
그래서 많은 브라우저 에이전트는 DOM을 그대로 보내지 않습니다. 먼저 필터링하고, 중요한 속성만 남기고, 상호작용 가능한 요소를 추린 뒤, 짧은 참조 ID를 붙여 더 다루기 쉬운 형태로 바꿉니다. DOM은 원재료이지, 그대로 먹는 완성 요리는 아닌 셈입니다.
접근성 트리: AI가 특히 좋아하는 의미 요약본
접근성 트리는 브라우저가 DOM을 바탕으로 다시 만드는 의미 중심 트리입니다. 원래는 스크린 리더 같은 보조기술을 위해 존재합니다. 브라우저는 DOM을 보고, 접근성 측면에서 의미 있는 요소를 골라 별도의 트리를 만듭니다.1
이 트리의 핵심 속성은 보통 이름(name), 설명(description), 역할(role), 상태(state)로 설명됩니다.1
이름: 이 요소를 무엇이라고 부를까
역할: 버튼인가, 링크인가, 입력창인가
상태: 체크됨, 펼쳐짐, 비활성화됨 같은 현재 상태
설명: 이름만으로 부족할 때 붙는 추가 정보
예를 들어 DOM에서 다음 요소를 봅시다.
<div class="primary-action" onclick="submitForm()">
제출
</div>사람은 모양을 보고 이게 버튼처럼 느껴질 수 있습니다. 하지만 DOM만 읽는 AI는 우선 div라는 사실부터 마주합니다. 이게 진짜 버튼인지, 단순 박스인지, 자바스크립트로 클릭이 연결된 장식 요소인지 추가 판단이 필요합니다. 반면 접근성 트리에서는 적절히 구현된 경우 대략 이런 식의 의미로 정리됩니다.
role=button
name=제출
state=enabled이 표현은 훨씬 기계 친화적입니다. 에이전트는 "제출 버튼을 클릭하라"는 지시를 받았을 때 CSS 클래스 이름을 해석할 필요 없이, role=button이고 name=제출인 대상을 찾으면 됩니다.4
여기서 중요한 점이 하나 더 있습니다. 접근성 트리는 DOM의 단순 복사본이 아닙니다. 브라우저는 의미가 약한 노드를 생략하거나 ignored로 처리하기도 하고, 보조기술이 이해하기 좋도록 구조를 다시 정리하기도 합니다.2 즉, 접근성 트리는 "페이지 안에 무엇이 있는가"보다 "사용자와 도구가 실제로 무엇을 다룰 수 있는가"에 더 가깝습니다.
브라우저 에이전트가 이 표현을 선호하는 이유도 분명합니다. 토큰을 아끼면서 의미를 더 직접적으로 전달하고, 프론트엔드 구현 세부사항의 변화에도 상대적으로 덜 흔들리기 때문입니다.45
하지만 접근성 트리만으로 끝나지는 않는다
여기서 자연스럽게 이런 질문이 나옵니다. "그럼 접근성 트리만 읽으면 되는 것 아닌가?" 아쉽게도 현실은 조금 더 복잡합니다.
첫째, 접근성 트리의 품질은 사이트 구현 품질에 크게 좌우됩니다. 버튼에 라벨이 없고, 입력창에 label이 없고, 클릭 가능한 요소를 전부 div로만 만들어 놓았다면 접근성 트리도 빈약해집니다. 사람은 모양과 맥락으로라도 짐작하지만, 에이전트는 이름 없는 클릭 대상 앞에서 멈칫할 수 있습니다.5
둘째, 브라우저나 구현 방식에 따라 접근성 트리 구성이 조금씩 달라질 수 있습니다. 어떤 노드를 포함하고 제외할지, Shadow DOM이나 CSS 영향을 어떻게 반영할지는 완전히 단순한 문제가 아닙니다.3
셋째, 시각적 맥락을 충분히 전달하지 못하는 경우가 있습니다. 예를 들어 "빨간 경고 배너가 화면 맨 위에 떠 있다", "버튼이 회색이라 실제로는 비활성처럼 보인다", "모달이 화면을 덮고 있다" 같은 정보는 접근성 트리만으로는 놓치기 쉽습니다.
즉, 접근성 트리는 의미 이해에는 매우 강하지만, 시각적 현실 전체를 대신하지는 못합니다.
스크린샷과 비전 모델: AI의 두 번째 눈
이 한계를 보완하는 것이 스크린샷 기반 인식입니다. 브라우저 화면을 이미지로 캡처하고, 멀티모달 모델이 그 이미지를 보고 무엇이 보이는지 해석하는 방식입니다. 이 방법은 인간의 화면 인식과 가장 비슷한 쪽에 있습니다. 버튼의 위치, 색상, 크기, 레이아웃, 차트, 캔버스 UI, 이미지 안 텍스트까지 한 번에 볼 수 있기 때문입니다.56
비전 모델이 특히 강한 영역은 다음과 같습니다.
접근성 정보가 빈약한 시각 요소 읽기
차트, 다이어그램, 캔버스 UI처럼 DOM만으로 이해하기 어려운 화면 해석
팝업, 오버레이, 오류 배너, 시각적 비활성 상태 파악
Google의 ScreenAI 같은 연구도 UI 요소의 종류, 위치, 설명을 함께 다루는 방향으로 발전해 왔습니다.6 즉 모델은 단순히 "화면을 본다"를 넘어서, "어디에 무엇이 있고 그것이 무슨 역할을 하는가"를 구조화하려고 합니다.
물론 스크린샷 방식에도 한계는 있습니다. 이미지 해석은 비용이 더 들고, 작은 글씨나 복잡한 레이아웃에서 실수할 수 있으며, 공간 관계를 헷갈리는 경우도 있습니다. 실제 웹페이지 스크린샷 해석 사례에서도 전체 흐름은 잘 잡으면서 좌우 배치나 세부 위치를 틀리는 일이 보고됩니다.7
쉽게 말해 스크린샷은 "보이는 현실"에는 강하지만, 내부 프로그래밍 의미나 상태를 곧바로 주지는 않습니다. 반대로 접근성 트리는 "의미"에는 강하지만, 시각적 현실을 모두 담지는 못합니다. 그래서 실제 에이전트는 둘을 함께 쓰는 하이브리드 방식으로 가는 경우가 많습니다.
상호작용 요소 추출: 페이지를 클릭 가능한 지도로 바꾸기
브라우저 에이전트가 실제로 행동하려면, 페이지를 길게 설명받는 것만으로는 부족합니다. 클릭할 대상, 입력할 칸, 선택할 메뉴를 바로 집어낼 수 있어야 합니다. 이때 많이 쓰이는 기법이 상호작용 요소 추출입니다.
아이디어는 단순합니다. 페이지 전체를 보내는 대신, 행동과 직접 관련된 요소만 뽑아 작은 목록으로 만드는 것입니다. 예를 들면 이런 식입니다.
@e1: link "홈"
@e2: textbox "이메일"
@e3: textbox "비밀번호"
@e4: button "로그인"이 표현은 아주 강력합니다. 에이전트는 더 이상 "왼쪽 아래 파란 버튼처럼 보이는 무언가"를 찾을 필요가 없습니다. 그냥 @e4를 클릭하면 됩니다. 이름과 역할이 함께 붙어 있으니 실수도 줄어듭니다. 실제 도구들이 접근성 스냅샷이나 ref 시스템을 채택하는 이유가 바로 여기에 있습니다.5
이 추출 단계에서 흔히 함께 하는 일은 다음과 같습니다.
클릭, 입력, 선택이 가능한 요소만 남기기
각 요소에 짧고 안정적인 참조 ID 부여하기
주변 문맥 붙이기
현재 상태 함께 기록하기
여기서 문맥도 중요합니다. button "계속"이라는 이름은 한 페이지에 여러 개 있을 수 있습니다. 이럴 때 "결제 폼 안의 계속 버튼", "배송 섹션 아래의 계속 버튼"처럼 문맥이 붙으면 훨씬 안전해집니다.
AI는 이 표상들을 어떻게 합쳐서 쓸까
현실의 브라우저 에이전트는 보통 한 가지 입력만 쓰지 않습니다. 상황에 따라 여러 층을 조합합니다.
가장 흔한 흐름은 이렇습니다. 우선 접근성 트리나 정제된 DOM으로 현재 페이지의 핵심 요소를 파악합니다. 그다음 필요할 때만 스크린샷으로 시각적 단서를 확인합니다. 그리고 클릭이나 입력을 수행한 뒤에는 새 상태를 다시 읽습니다. 즉, 한 번 보고 끝나는 것이 아니라 계속 다시 관찰합니다.
로그인 페이지를 예로 들어 보겠습니다.
에이전트는 현재 페이지에서
textbox "이메일",textbox "비밀번호",button "로그인"을 추출합니다.스크린샷을 함께 보면 상단 쿠키 배너가 버튼 일부를 가리고 있다는 사실을 발견할 수 있습니다.
그러면 먼저 쿠키 배너의 닫기 버튼을 누릅니다.
다시 상태를 읽고, 이메일과 비밀번호를 입력합니다.
로그인 버튼을 클릭합니다.
새 페이지에서 오류 문구, 로딩 상태, 대시보드 진입 여부를 다시 확인합니다.
이 흐름에서 드러나는 핵심은, 웹페이지 이해가 정적인 독해가 아니라는 점입니다. 관찰하고, 추론하고, 행동하고, 다시 관찰하는 반복입니다. 브라우저 에이전트에게 페이지 이해는 정답지라기보다 행동을 위한 실시간 지도에 가깝습니다.
사람이 보는 웹과 AI가 보는 웹의 차이
사람은 목적 중심으로 봅니다. "검색창이 있네." "이 버튼은 비활성화돼 있네." "이 화면은 결제 마지막 단계구나." 이런 판단을 거의 동시에 합니다.
AI도 비슷한 결과에 도달할 수 있지만, 내부 과정은 다릅니다. 예를 들면 이런 식입니다.
role=searchbox인 요소가 있다accessible name은
검색이다현재 값은 비어 있다
아래에
검색버튼이 있다화면 상단에 모달은 없다
페이지 제목상 현재 단계는
배송 정보다
즉 사람의 직관을, 구조화된 속성과 상태의 묶음으로 다시 조립하는 셈입니다. 그래서 "AI가 사람처럼 웹을 쓴다"는 표현은 절반만 맞습니다. 더 정확히 말하면, AI는 사람이 웹에서 사용하는 의미 단서와 시각 단서를 기계가 다루기 좋은 형태로 바꾼 뒤 조합해 사람과 비슷한 행동을 흉내 냅니다.
좋은 웹페이지일수록 AI도 읽기 쉽다
여기서 흥미로운 결론이 나옵니다. 접근성이 좋은 웹사이트는 대체로 AI 에이전트에게도 읽기 쉽습니다.5 버튼은 버튼답게, 입력창은 라벨과 함께, 제목은 계층을 갖고, 상태는 명확하게 드러날수록 에이전트의 성공률도 높아집니다.
반대로 겉보기만 화려하고 의미 구조가 빈약한 페이지, 클릭은 되지만 이름이 없는 아이콘 버튼, 자바스크립트로만 겨우 움직이는 커스텀 위젯은 사람뿐 아니라 AI에게도 어렵습니다.
미래의 브라우저 에이전트는 더 똑똑해지겠지만, 여전히 좋은 입력을 좋아할 것입니다. 잘 만든 웹은 사람에게 친절하고, 동시에 에이전트에게도 친절합니다. 이 둘은 점점 더 같은 방향을 바라보고 있습니다.
정리
AI는 웹페이지를 하나의 방식으로 보지 않습니다. DOM으로 구조를 읽고, 접근성 트리로 의미를 압축하고, 스크린샷으로 시각 상태를 확인하고, 상호작용 요소 추출로 행동 가능한 목록을 만듭니다. 그리고 이 표현들은 한 번 쓰고 버리는 것이 아니라, 행동할 때마다 다시 갱신됩니다.
결국 브라우저 에이전트의 눈은 하나가 아닙니다. 구조를 보는 눈, 의미를 보는 눈, 화면을 보는 눈이 따로 있고, 그 셋을 잘 합칠수록 더 사람답게 웹을 사용할 수 있습니다.
다음 장에서는 이 인식 위에서 실제 에이전트가 어떻게 움직이는지, 즉 관찰-추론-행동의 내부 루프를 본격적으로 살펴보겠습니다.
참고
2Full accessibility tree in Chrome DevTools
3Accessibility Object Model: Accessibility Tree
4Accessibility Tree vs DOM - Which Approach Works Better for Browser Agents?
5How AI Agents See Your Website and How To Build For Them
6ScreenAI: A visual language model for UI and visually-situated language understanding
7Understand Website Screenshots with a Multimodal Vision Model
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.