page-agent, 스크립트 한 줄로 웹페이지 안에 AI 에이전트를 심는다

웹 자동화 도구는 오랫동안 밖에서 안을 들여다보는 구조였다. Selenium이든 Playwright든, 별도 프로세스가 브라우저를 원격 조종하는 방식이었다. browser-use가 여기에 LLM을 얹었지만 Python 서버가 필요하다는 점은 동일했다. 알리바바가 공개한 page-agent¹는 이 전제를 뒤집었다. 에이전트가 웹페이지 안에 산다.

안에서 밖으로: page-agent의 핵심 발상

page-agent의 제작자 simon_luv_pho는 Hacker News Show HN 게시글에서 이렇게 설명했다.

“I’m experimenting with an ‘inside-out’ paradigm. By dropping the library into a page, you get a client-side agent that interacts natively with the live DOM tree and inherits the user’s active session out of the box.” — simon_luv_pho, HN²

기존 도구들이 헤드리스 브라우저를 띄우고 외부에서 DOM을 조작했다면, page-agent는 <script> 태그 하나로 현재 페이지에 직접 주입된다. 이 차이는 단순한 배포 편의성을 넘어 아키텍처적 전환이었다.

<script src="https://cdn.jsdelivr.net/npm/page-agent@1.5.7/dist/iife/page-agent.demo.js" crossorigin="true"></script>

이 한 줄이면 페이지에 AI 에이전트 UI가 나타난다. 사용자는 자연어로 “로그인 버튼을 클릭해줘”라고 입력하면, 에이전트가 DOM을 파싱해 해당 버튼을 찾아 클릭한다.

[!KEY] page-agent는 서버도 브라우저 확장도 필요 없다. 인페이지 자바스크립트만으로 동작하며, 스크린샷 대신 텍스트 기반 DOM 조작을 사용해 멀티모달 LLM 없이도 작동한다.

작동 원리: 텍스트 기반 DOM 처리

page-agent는 스크린샷을 찍지 않는다. 대신 페이지의 HTML 구조를 텍스트로 파싱해 버튼, 입력 필드, 링크 등 상호작용 가능한 요소를 식별한다. 이 DOM 처리 계층은 browser-use의 코드를 기반으로 했다(MIT 라이선스)¹.

graph TD
    A[사용자 자연어 입력] --> B[page-agent 코어]
    B --> C[DOM 파싱<br/>텍스트 추출]
    C --> D[LLM에 전송<br/>행동 결정]
    D --> E[DOM 조작 실행]
    E --> F[Human-in-the-loop<br/>승인/거부 UI]
    F -->|승인| G[작업 완료]
    F -->|거부| A

이 방식의 장점은 명확했다. 첫째, 스크린샷을 LLM에 전송하는 것보다 토큰 비용이 현저히 낮았다. 둘째, 이미지 분석 없이 텍스트만 처리하므로 응답 속도가 빨랐다. 셋째, GPT-4 Vision 같은 멀티모달 모델이 아닌 일반 텍스트 LLM만으로 충분했다.

BYO LLM: 원하는 모델을 연결한다

page-agent는 BYO LLM(Bring Your Own LLM) 철학을 채택했다. OpenAI API 호환 형식이면 어떤 모델이든 연결할 수 있었다. GPT-4, Claude, Qwen, Mistral, 심지어 로컬에서 돌리는 오픈소스 모델까지.

import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
  apiKey: 'YOUR_API_KEY',
  language: 'ko-KR',
})

await agent.execute('주문서의 배송지 주소를 서울시 강남구로 변경해줘')

npm 패키지 크기는 224kB였다³. 프론트엔드 라이브러리치고 가벼운 편은 아니지만, UI 컴포넌트와 DOM 처리 로직을 모두 포함한 점을 감안하면 합리적인 수준이었다.

기존 도구와 무엇이 다른가

웹 자동화 생태계는 2025–2026년 사이 급격히 팽창했다. Playwright, browser-use, Stagehand, 그리고 page-agent. 각각 접근 방식이 근본적으로 달랐다.

핵심 차이는 포지셔닝이었다. Playwright와 Selenium은 외부에서 브라우저를 제어하는 테스트 도구였다. browser-use는 그 위에 AI 레이어를 얹었지만 여전히 서버 사이드였다. Stagehand는 Playwright를 확장해 act(), extract(), observe() 같은 AI 프리미티브를 추가했다⁴.

page-agent만이 클라이언트 사이드에서 태어난 도구였다. 이 말은 곧 SPA(Single Page Application) 개발자가 자기 제품에 AI 코파일럿을 몇 줄 만에 내장할 수 있다는 뜻이었다. ERP 시스템의 20단계 클릭을 한 문장으로 줄이거나, 관리자 페이지에 자연어 인터페이스를 덧씌우는 식이었다.

이전에 다룬 agent-browser 스킬 리뷰에서도 브라우저 자동화 도구의 토큰 효율성 문제를 살펴본 적이 있다. page-agent는 스크린샷을 아예 사용하지 않으므로 이 문제를 원천적으로 우회했다.

크롬 확장: 단일 페이지의 한계를 넘어서

page-agent의 가장 큰 제약은 기본적으로 현재 페이지에서만 동작한다는 점이었다. 다른 탭으로 이동하거나, 여러 사이트를 오가는 워크플로는 불가능했다.

이를 보완하기 위해 별도의 크롬 확장이 제공되었다⁵. 확장을 설치하면 웹페이지 에이전트가 다른 탭을 열고, 정보를 추출하고, 다시 원래 페이지로 돌아오는 식의 멀티페이지 작업이 가능했다. 흥미로운 점은 방향이 역전되었다는 것이었다. 일반적인 브라우저 자동화 도구는 외부 프로그램이 브라우저를 제어하지만, page-agent에서는 웹 앱이 브라우저를 제어했다.

다만 이 확장은 사용자가 직접 설치해야 했으므로, “스크립트 한 줄이면 끝”이라는 page-agent의 핵심 장점이 멀티페이지 시나리오에서는 희석되었다.

실전 활용 시나리오

page-agent 문서와 커뮤니티에서 제시하는 주요 활용 사례는 세 가지였다.

SaaS AI 코파일럿 — 자사 웹 제품에 AI 어시스턴트를 내장하는 가장 직접적인 용도였다. 백엔드를 다시 작성할 필요 없이, 프론트엔드에 스크립트를 추가하는 것만으로 자연어 기반 UI 제어가 가능했다. CRM이나 ERP처럼 복잡한 폼이 많은 시스템에서 특히 유용했다.

접근성 향상 — 시각 장애인이나 운동 장애가 있는 사용자가 음성 명령이나 자연어로 웹 앱을 조작할 수 있었다. 기존 접근성 도구가 정적 라벨에 의존했다면, page-agent는 LLM의 자연어 이해 능력을 활용해 더 유연한 상호작용을 제공했다.

스마트 폼 작성 — 관리자 화면에서 20번 클릭해야 할 작업을 “서울 지역 3월 주문 건을 모두 발송 완료로 변경해줘” 한 문장으로 처리하는 식이었다.

한계와 주의점

page-agent가 만능은 아니었다. 몇 가지 구조적 한계가 존재했다.

보안 우려 — API 키가 클라이언트 사이드에 노출되었다. 프로덕션 환경에서는 프록시 서버를 통해 키를 숨기는 추가 작업이 필요했다. 데모용 테스트 LLM API도 알리바바 클라우드 공식 제품이 아니며, 언제든 중단될 수 있다고 명시되어 있었다⁶.

DOM 구조 의존성 — 텍스트 기반 DOM 파싱이라는 것은 결국 HTML 구조가 깔끔해야 잘 동작한다는 뜻이었다. 심하게 난독화된 페이지나 Canvas/WebGL 기반 UI에서는 제대로 작동하기 어려웠다.

단일 페이지 제약 — 크롬 확장 없이는 현재 페이지에 갇혔다. browser-use나 Playwright가 기본적으로 멀티페이지를 지원하는 것과 대비되었다.

LLM 품질 의존 — 에이전트의 정확도는 전적으로 연결한 LLM의 성능에 달려 있었다. 저품질 모델을 연결하면 잘못된 요소를 클릭하거나 엉뚱한 동작을 수행할 수 있었다.

초기 단계 — 2024년 말 공개 이후 빠르게 성장해 GitHub 스타 9,300개를 넘겼지만, 버전이 1.5.7까지 올라오는 동안에도 API가 계속 변경되고 있었다. data-browser-use-ignore가 data-page-agent-ignore로 바뀌는 등 browser-use 흔적을 지우는 과정이 진행 중이었다⁷.

그래서 누가 써야 하는가

page-agent는 모든 웹 자동화를 대체하는 도구가 아니었다. 서버에서 대량의 스크래핑을 돌리거나 CI/CD 파이프라인에서 E2E 테스트를 실행하는 용도라면 Playwright가 여전히 정답이었다. 복잡한 멀티사이트 자동화 에이전트를 구축한다면 browser-use가 더 적합했다.

page-agent가 빛나는 지점은 명확했다. 자사 웹 제품에 AI 코파일럿을 빠르게 내장하고 싶은 프론트엔드 개발자. 백엔드 인프라 변경 없이, npm 패키지 하나로 기존 SPA에 자연어 제어 기능을 추가할 수 있었다. human-in-the-loop UI가 기본 내장되어 있어 프로덕션 환경에서의 안전성도 확보되었다.

알리바바의 이 실험은 GUI 에이전트의 미래에 대한 흥미로운 질문을 던졌다. 에이전트가 반드시 밖에서 브라우저를 조종해야 하는가? 아니면 웹 앱 자체가 에이전트가 될 수 있는가? page-agent는 후자에 걸었고, 그 방향이 어디까지 갈 수 있는지는 아직 열린 문제였다.