들어가며
평소 웹 접근성이라는 주제에 흥미가 있어 Dev Korea에서 주최한 웹 접근성 세션, Accessibility, live에 참석하게 되었습니다.
웹 접근성(Web Accessibility)은 장애 유무나 사용 환경에 관계없이 누구나 웹에서 제공하는 정보와 기능을 이용할 수 있도록 웹사이트와 서비스를 설계하고 개발하는 것을 의미합니다. 실제 사용자가 웹을 인지하고 탐색하고 상호작용할 수 있는지를 함께 고려하는 것을 뜻합니다.
이번 세션은 시각장애인과 저시력 개발자 및 전문가들이 실제로 앱과 웹사이트, AI 도구를 어떻게 사용하는지 직접 보여주며, 일반적으로 익숙한 웹 사용 방식과 시각장애인·저시력 사용자의 실제 웹 이용 경험이 어떻게 다른지 살펴볼 수 있는 자리였습니다. 또한 스크린 리더를 이용한 웹 탐색과 Aside를 활용한 Agentic Browsing 사례를 통해, 접근성을 위해 웹의 구조와 의미를 명확하게 표현하는 일이 사람뿐 아니라 Browser Agent가 웹을 이해하고 상호작용하는 데에도 도움이 될 수 있다는 점을 함께 살펴볼 수 있었습니다.
저는 Claude in Chrome을 이용해 온라인 강의 내용을 확인하게 하거나 간단한 웹 작업을 맡겨본 경험은 있었지만, Browser Agent를 본격적으로 사용해본 적은 없었습니다. Agentic Browsing이라는 개념이나 동작 방식에 대해서도 잘 알지 못했고, 주로 편리한 AI 기능 정도로 사용하고 있었습니다. 이번 세션을 통해 같은 기술이 단순히 반복 작업을 줄이는 생산성 기능을 넘어, 사용자에 따라서는 웹과 상호작용하는 방식 자체를 바꿀 수도 있다는 점에 관심이 생겼습니다.
이를 계기로 몇 가지 궁금증이 생겼습니다.
- Agentic Browsing은 기존 웹 브라우징과 무엇이 다른가?
- Browser Agent는 웹페이지를 어떤 방식으로 이해하고 작업을 수행하는가?
- 웹 접근성을 위해 사용되어 온 기술과 구조는 Browser Agent와도 연결될 수 있는가?
- Accessible Web과 Agent-Friendly Web은 어떤 관계가 있는가?
이러한 궁금증을 바탕으로 관련 기술과 개념을 조사하고, 세션에서 소개된 Aside를 직접 사용해보았습니다.
1. Agentic Browsing이란?
일반적인 웹 브라우징에서는 대부분의 과정을 사용자가 직접 수행합니다.
검색어를 입력하고, 적절한 링크를 선택하고, 페이지 안에서 필요한 정보를 찾은 뒤 버튼을 클릭하거나 입력창에 값을 입력합니다. 여러 웹사이트의 정보를 비교해야 한다면 각 페이지를 직접 이동하며 필요한 내용을 확인합니다.
Agentic Browsing에서는 이러한 과정의 일부를 AI Agent가 담당합니다.
사용자가 모든 클릭과 입력을 하나씩 지시하기보다 달성하고 싶은 목표를 전달하면, Agent가 현재 웹의 상태를 파악하고 다음 행동을 결정합니다. 필요한 페이지로 이동하고, 버튼을 클릭하거나 값을 입력한 뒤, 그 결과를 다시 확인하면서 작업을 이어갑니다.
단순화하면 다음과 같은 반복 구조로 볼 수 있습니다.
사용자의 목표
↓
Observe
현재 웹 상태 파악
↓
Reason / Plan
다음 행동 판단
↓
Act
Click / Type / Navigate
↓
결과 확인
↓
목표 달성까지 반복즉, Agentic Browsing의 핵심은 단순히 브라우저의 클릭을 자동화하는 것이 아니라 사용자의 목표를 기준으로 현재 상태를 관찰하고 다음 행동을 판단하며 작업을 이어가는 것에 있습니다.
2. 직접 Agentic Browsing을 사용해보기
앞에서 살펴본 Agentic Browsing이 실제로 어떻게 동작하는지 확인하기 위해, 세션에서 소개된 Aside를 직접 사용해보았습니다. 세션에서는 웹 접근성의 관점에서 Aside가 소개되었지만, 직접 사용하면서 쇼핑부터 Memory, 여러 출처를 활용한 리서치까지 몇 가지 활용 방식을 함께 살펴보았습니다.
2-1. 원하는 조건의 상품을 찾아 장바구니에 담기
먼저 세션에서 보았던 웹 탐색 사례와 비슷하게, 온라인 쇼핑 과정을 Aside에게 맡겨보았습니다.
10만 원 이하의 무선 키보드 중에서 블루투스를 지원하고 Mac과 Windows에서 모두 사용할 수 있는 제품을 찾아줘.
조건에 맞는 제품 3개를 비교한 뒤 가장 적합한 제품 하나를 선택해서 장바구니에 담아줘.
이번 테스트에서는 Aside가 요청을 받은 뒤 작업을 여러 단계의 Todo로 나누어 진행했습니다. 상품을 탐색하고, 조건에 맞는 후보를 비교한 뒤, 최종 제품을 선택해 장바구니에 담는 순서였습니다.
스크린샷에서처럼 하나의 요청을 그대로 실행하는 것이 아니라, 필요한 하위 작업을 나누고 여러 후보의 정보를 확인하면서 다음 단계로 진행하는 모습을 볼 수 있었습니다.
최종적으로는 가격, Bluetooth 지원 여부, Mac·Windows 호환성을 확인해 후보 제품을 비교하고, 그중 로지텍 K380S를 선택해 실제 장바구니에 담았습니다.
검색창의 위치나 어떤 상품 페이지를 열어야 하는지, 어떤 버튼을 눌러야 하는지를 하나씩 지시하지 않았지만, Aside가 상품 탐색 → 조건 확인 → 비교 → 선택 → 장바구니 담기까지 이어서 수행했습니다.
이번 테스트를 통해 사용자가 웹페이지의 구조를 직접 하나씩 탐색하는 대신, 원하는 목표를 자연어로 전달하고 Agent가 중간 단계를 수행하는 Agentic Browsing의 방식을 직접 확인해볼 수 있었습니다.
2-2. 이전 작업의 맥락을 기억하기
Aside에는 이전 작업에서 확인한 정보와 사용자 맥락을 이후에도 활용할 수 있도록 하는 Memory 기능이 있습니다.
실제로 앞에서 작업 과정에서 확인했던 내용들이 별도의 기록으로 저장되어 있었습니다.
예를 들어 쿠팡 상품 가격을 해석하면서 확인한 내용이나 키보드 호환성을 검증한 과정처럼 이전 작업에서 얻은 정보가 기록되어 있는 것을 확인할 수 있었습니다.
이처럼 이전 작업의 맥락이 남아 있기 때문에 새로운 작업을 시작할 때 모든 배경 정보를 매번 처음부터 설명하지 않고 이전 작업에서 얻은 정보를 이어서 활용할 수 있습니다.
2-3. 여러 출처를 탐색해 정보 비교하기
이번에는 Aside에게 여러 공식 문서를 확인해야 하는 기술 리서치를 맡겨보았습니다.
AWS 공식 문서만 이용해서 Amazon Bedrock Agents와 AgentCore를 비교해줘. 주요 목적, 주요 기능, 적합한 사용 사례, 제한사항으로 나눠서 정리하고 각 내용의 출처를 함께 알려줘.
Aside는 관련 AWS 공식 문서를 찾아 내용을 비교하고, 요청한 항목에 맞춰 출처와 함께 정리했습니다.
단일 페이지의 내용을 요약하는 것과 달리, Search를 활용하면 여러 출처를 탐색해 필요한 정보를 모으고 비교한 뒤 하나의 결과로 정리하는 작업을 진행합니다. 기술 문서 조사처럼 여러 페이지를 직접 오가며 확인해야 하는 작업에서 활용하기 좋은 방식입니다.
3. Browser Agent는 웹을 어떻게 이해할까?
앞에서 Aside가 실제 웹에서 상품을 찾고, 여러 정보를 비교하고, 버튼을 눌러 작업을 수행하는 모습을 확인했습니다. 이 과정을 보면서 Browser Agent는 웹페이지를 어떤 방식으로 이해하고 다음 행동을 결정하는 것일까라는 한 가지 궁금증이 생겼습니다.
사용자의 목표를 대신 수행하려면 Agent는 먼저 현재 페이지에 어떤 정보와 기능이 있는지 파악해야 합니다. 어떤 요소가 검색창이나 버튼인지, 입력창에는 무엇을 입력해야 하는지, 작업 이후 페이지의 상태가 어떻게 바뀌었는지 등을 이해해야 다음 행동을 결정할 수 있습니다.
Browser Agent가 이러한 웹페이지의 상태를 파악하는 방법은 하나로 정해져 있지 않습니다. 대표적으로 HTML/DOM, 화면 이미지와 Vision Model, Accessibility Tree를 활용할 수 있으며, 필요에 따라 여러 정보를 함께 사용하기도 합니다.
HTML / DOM
첫 번째는 페이지의 HTML과 DOM(Document Object Model)을 읽는 방식입니다.
브라우저는 HTML 문서를 DOM이라는 트리 구조로 표현합니다. Agent는 이를 통해 어떤 요소가 어떤 요소 안에 포함되어 있는지, element 사이에 어떤 계층 관계가 있는지, 각 요소에 어떤 attribute와 텍스트가 포함되어 있는지 파악할 수 있습니다.
여기서 중요한 개념 중 하나가 Semantic HTML입니다.
HTML 요소는 단순히 화면의 모양을 구성하는 역할만 하는 것이 아니라, 요소가 어떤 의미와 기능을 가지고 있는지도 표현할 수 있습니다.
예를 들어 <button>은 해당 요소가 사용자와 상호작용하는 버튼이라는 의미를 가지고 있고, <nav>는 페이지의 주요 탐색 영역, <h1>부터 <h6>는 콘텐츠의 제목과 계층을 나타냅니다.
이처럼 목적에 맞는 HTML 요소를 사용하면 웹페이지의 구조와 의미가 코드 자체에 함께 표현됩니다.
Browser Agent가 DOM을 활용하는 경우 이러한 의미 정보는 페이지의 구조와 기능을 파악하는 데 중요한 단서가 될 수 있습니다.
다만 실제 웹페이지의 DOM에는 화면을 구성하고 동작시키기 위한 많은 요소와 정보가 포함되어 있습니다. 이 중에는 Agent가 현재 수행하려는 작업과 직접적인 관련이 없는 정보도 많기 때문에, 필요한 정보만 효과적으로 찾아내는 과정이 필요합니다.
Screenshot + Vision
두 번째는 현재 웹페이지를 화면 이미지로 보고 Vision Model을 이용해 해석하는 방식입니다.
사람이 웹 화면을 보는 것처럼 요소의 위치와 크기, 색상, 아이콘, 주변 UI와의 관계 등 시각적인 정보를 활용할 수 있습니다.
예를 들어 화면 우측 상단에 돋보기 모양의 아이콘이 있다면 주변 UI와 배치를 함께 보고 검색 기능일 가능성을 판단할 수 있습니다. 구조적인 정보만으로는 의미를 파악하기 어려운 UI에서도 시각적인 맥락을 활용할 수 있다는 장점이 있습니다.
반면 화면 전체를 이미지로 분석해야 하기 때문에 구조화된 정보에 비해 처리해야 할 정보가 많고, 화면 크기나 배치가 달라지면 동일한 기능도 다른 위치와 형태로 나타날 수 있습니다.
Accessibility Tree
또 다른 방법은 Accessibility Tree를 활용하는 것입니다.
브라우저는 DOM을 바탕으로 웹페이지의 접근성 관련 정보를 별도의 구조로 구성합니다. Accessibility Tree에는 요소의 역할(Role), 이름(Name), 상태(State) 등 해당 요소가 무엇이고 어떤 상태에 있는지를 나타내는 정보가 포함됩니다.
이 정보는 원래 스크린 리더와 같은 보조 기술이 웹페이지의 구조와 의미를 파악할 수 있도록 제공되는 정보입니다.
예를 들어 다음과 같은 HTML이 있다면,
<button>결제하기</button>Accessibility Tree에서는 개념적으로 다음과 같은 정보를 얻을 수 있습니다.
role: button
name: 결제하기DOM이 웹페이지의 전체 구조와 다양한 속성을 담고 있다면, Accessibility Tree는 그중에서도 요소의 역할과 의미, 상태와 같이 상호작용에 필요한 의미 정보를 중심으로 표현합니다.
Browser Agent는 이러한 정보를 통해 해당 요소가 단순히 화면에 표시된 텍스트가 아니라 결제하기라는 이름을 가진 button이라는 점을 파악할 수 있습니다. 이를 바탕으로 현재 페이지에 어떤 기능이 존재하는지 판단하고 다음 행동을 결정할 수 있습니다.
이번에 직접 사용해본 Aside도 공개된 기술 자료에 따르면 페이지의 현재 상태를 Agent에게 전달하기 위해 자체적으로 가공한 Accessibility Tree를 사용한다고 설명하고 있습니다. 중간 요소를 줄이고 focus 상태, iframe ID, clickable 여부처럼 Agent가 판단하는 데 필요한 정보를 추가하는 방식이며, 구조적인 정보만으로 제어하기 어려운 웹사이트에서는 화면 이미지와 좌표를 활용하는 방식도 함께 사용합니다.
Browser Agent가 웹을 이해하는 데 활용하는 정보 중 Semantic HTML을 통해 표현된 의미 구조와 Accessibility Tree는 웹 접근성에서도 오래전부터 중요하게 다뤄져 온 요소들입니다.
그렇다면 접근성을 고려해 구조와 의미가 잘 표현된 웹은 Browser Agent에게도 더 이해하기 좋은 웹이 될 수 있을까요?
4. 웹 접근성을 위한 구조는 Browser Agent에게도 도움이 될까?
앞에서 살펴본 것처럼 Browser Agent가 웹에서 작업을 수행하려면 페이지에 어떤 요소가 있고, 각각 어떤 역할과 의미를 가지고 있는지 파악하는 과정이 필요합니다.
웹 접근성에서는 웹페이지의 시각적인 표현뿐 아니라, 구조와 의미가 코드에도 명확하게 표현되어 있는지를 중요하게 다룹니다. 대표적인 예로 Semantic HTML, label, heading 구조 등을 들 수 있습니다.
예를 들어 Form에서는 입력창의 목적이 코드에 명확하게 표현되어 있는지가 중요합니다.
<label for="email">이메일</label>
<input id="email" type="email">이처럼 label과 input의 관계가 명확하게 연결되어 있으면 해당 입력창이 무엇을 위한 것인지 구조적으로 표현됩니다.
이는 스크린 리더와 같은 보조 기술이 사용자에게 입력창의 목적을 전달하는 데 도움이 됩니다. 동시에 DOM이나 Accessibility Tree와 같은 구조화된 정보를 활용하는 Browser Agent에게도 이메일이라는 label과 해당 input의 관계는 어느 필드에 어떤 값을 입력해야 하는지 판단할 수 있는 단서가 됩니다.
반대로 입력창의 목적이 화면상의 위치나 시각적인 표현에만 의존하고 코드에는 관계가 명확하게 표현되어 있지 않다면, 보조 기술뿐 아니라 구조적인 정보를 활용하는 Agent 역시 추가적인 맥락을 바탕으로 기능을 판단해야 할 수 있습니다.
Heading 구조에서도 비슷한 점을 확인할 수 있습니다.
<h1>상품 상세</h1>
<h2>제품 정보</h2>
<h2>배송 안내</h2>
<h2>리뷰</h2>Heading이 논리적인 계층으로 구성되어 있다면 사용자는 페이지 전체를 순서대로 확인하지 않고도 콘텐츠의 구조를 파악하고 필요한 영역을 찾을 수 있습니다.
Browser Agent에게도 heading은 페이지에 어떤 정보가 있고 각 콘텐츠가 어떤 관계로 구성되어 있는지 파악하기 위한 구조적인 단서가 될 수 있습니다. 예를 들어 배송 관련 정보를 찾는 작업이라면 배송 안내라는 heading을 기준으로 관련 콘텐츠를 탐색할 수 있습니다.
이처럼 웹 접근성에서 중요하게 다뤄온 여러 요소는 Browser Agent가 웹의 구조와 기능을 이해하는 데에도 유용한 정보를 제공할 수 있습니다.
- 목적에 맞는 Semantic HTML
- 명확한 label과 accessible name
- 논리적인 heading 구조
- 요소의 role과 state를 명확하게 표현하는 방식
- 일관되고 예측 가능한 interaction
이 요소들은 서로 다른 기술처럼 보이지만 공통적으로 웹페이지가 가진 의미와 기능을 명확하게 표현한다는 것에 초점을 두고 있습니다.
Accessible Web과 Agent-Friendly Web
Accessible Web과 Agent-Friendly Web은 우선적으로 고려하는 대상은 다르지만, 웹의 구조와 의미를 명확하게 표현한다는 공통된 기반 위에서 서로 연결되어 있다고 볼 수 있습니다.
Accessible Web은 장애가 있는 사용자를 포함한 다양한 사람이 웹의 정보와 기능을 인지하고, 탐색하고, 상호작용할 수 있도록 하는 데 초점을 둡니다.
반면 Agent-Friendly Web은 AI Agent가 웹페이지의 구조와 기능을 이해하고 사용자를 대신해 필요한 작업을 안정적으로 수행할 수 있도록 하는 데 초점을 둡니다.
두 개념의 목적은 다르지만, 실제 웹을 구성하는 방식에서는 상당한 접점이 있습니다.
Semantic HTML과 명확한 label은 보조 기술을 사용하는 사람에게 웹 요소의 의미를 전달하는 동시에, Browser Agent가 해당 요소의 역할과 기능을 파악하는 단서가 될 수 있습니다. 논리적인 heading 구조 역시 사람이 페이지를 효율적으로 탐색하도록 도와주는 동시에 Agent에게는 콘텐츠의 구조와 관계를 이해할 수 있는 정보를 제공합니다.
결국 두 방향이 공유하는 중요한 기반 중 하나는 웹의 의미를 기계가 해석할 수 있는 형태로 명확하게 표현하는 것입니다. 이러한 정보는 보조 기술을 통해 사람에게 전달될 수도 있고, Browser Agent가 웹페이지의 상태를 이해하고 다음 행동을 결정하는 데 활용될 수도 있습니다.
앞으로 Agent가 사용자를 대신해 웹을 탐색하고 작업하는 경우가 늘어난다면, 접근성을 고려해 잘 구조화된 웹은 사람이 직접 웹을 이용하는 데 도움이 되는 것뿐만 아니라 Agent가 웹을 이해하고 사용자를 보조하는 데에도 중요한 기반이 될 수 있습니다
마치며
처음 가졌던 질문으로 돌아가 보면, Agentic Browsing은 사용자가 웹의 모든 과정을 직접 수행하는 대신 목표를 전달하고 Agent가 그 사이의 탐색과 행동을 이어가는 방식이라고 볼 수 있습니다. Browser Agent는 이를 위해 HTML/DOM, 화면 이미지와 Vision Model, Accessibility Tree 등 다양한 정보를 활용해 웹페이지를 이해합니다.
그 과정에서 웹 접근성과의 접점도 확인할 수 있었습니다. Semantic HTML을 통해 표현된 의미 구조와 Accessibility Tree처럼 웹 접근성에서 중요하게 다뤄온 정보가 Browser Agent에게도 웹을 이해하기 위한 단서가 될 수 있기 때문입니다.
웹 접근성 세션과 Aside 사용을 통해, 사람이 접근하기 좋은 웹을 만들기 위해 중요하게 다뤄온 원칙들이 Agent가 웹을 이해하고 상호작용하는 환경에서도 중요한 기반이 될 수 있다는 점을 살펴볼 수 있었습니다.