Web Agent

• Web Agent는 LLM이 웹 브라우저를 자율적으로 제어하여 목표를 달성하는 AI 에이전트 시스템
• 사용자의 자연어 지시를 받아 관찰-추론-행동(Observe-Think-Act) 루프로 웹 작업을 수행하는 브라우저 자동화 패러다임
• 기존 스크립트 자동화(Selenium, Puppeteer)와 달리 웹사이트 구조 변경에 적응할 수 있는 의미 기반(semantic) 접근 방식

해당 개념이 필요한 이유

• 기존 브라우저 자동화는 XPath/CSS 셀렉터에 의존하여 웹사이트 구조가 바뀌면 즉시 깨짐
• API가 없는 웹 서비스에서 데이터를 수집하거나 작업을 자동화해야 하는 수요 증가
• LLM의 추론 능력이 웹 페이지의 맥락을 이해할 수 있는 수준에 도달 (GPT-4o, Claude, Gemini 등)
• 사용자의 인증된 세션(쿠키, 로그인)을 활용하여 개인화된 웹 작업 가능

AS-IS: 기존 스크립트 자동화

# Selenium — 셀렉터 기반, 구조 변경 시 실패
driver.find_element(By.XPATH, '//*[@id="search-box"]').send_keys("query")
driver.find_element(By.CSS_SELECTOR, '.btn-submit').click()
# 웹사이트 리디자인 → XPATH 변경 → 스크립트 전체 수정 필요

TO-BE: Web Agent (LLM 기반)

sequenceDiagram
    autonumber
    participant User as 사용자
    participant LLM as LLM (추론 엔진)
    participant Browser as 브라우저

    User->>LLM: "Google에서 'AI agent' 검색해줘"
    loop Observe-Think-Act
        LLM->>Browser: 페이지 상태 요청 (Accessibility Tree)
        Browser-->>LLM: 페이지 구조 + 요소 참조 ID
        Note over LLM: 추론: 검색창은 ref=e5, 역할=textbox
        LLM->>Browser: type_text(ref=e5, "AI agent")
        Browser-->>LLM: 입력 완료, DOM 변화 감지
        LLM->>Browser: press_key("Enter")
        Browser-->>LLM: 페이지 네비게이션 완료
    end
    LLM-->>User: "검색 결과를 정리했습니다: ..."

Web Agent의 3가지 인식 방식

1. DOM 기반 인식

HTML Document Object Model을 파싱하여 페이지 구조를 이해하는 방식. 요소의 태그, 속성, 텍스트 콘텐츠를 직접 분석한다.

• 장점: 정확한 요소 식별, 빠른 처리
• 단점: 시각적 레이아웃 정보 부족, JavaScript 렌더링 후 DOM과 실제 화면 괴리

2. Accessibility Tree 기반 인식

브라우저의 접근성 트리를 활용하여 요소의 역할(role), 이름(name), 상태(state) 를 파악. 스크린 리더가 사용하는 것과 동일한 구조를 에이전트가 활용한다.

• 장점: 의미론적(semantic) 이해 가능, CSS/레이아웃 변경에 강건
• 단점: 접근성 마크업이 빈약한 사이트에서는 정보 부족
• 핵심 인사이트: “스크린 리더가 사이트를 못 읽으면, AI 에이전트도 못 읽는다”

3. Vision(스크린샷) 기반 인식

페이지 스크린샷을 Computer Vision/멀티모달 LLM에 입력하여 시각적으로 요소를 인식하는 방식.

• 장점: DOM 구조에 의존하지 않음, 복잡한 시각적 레이아웃 이해 가능
• 단점: 처리 속도 느림, 비용 높음, 정밀한 요소 지정 어려움

실무에서는 Accessibility Tree + Vision 하이브리드 방식이 가장 보편적이다.

Observe-Think-Act 루프

Web Agent의 실행 핵심 패턴. 모든 웹 작업은 이 루프의 반복으로 수행된다.

sequenceDiagram
    autonumber
    participant Agent as Agent (LLM)
    participant Env as Browser Environment

    loop 목표 달성까지 반복
        Agent->>Env: Observe — 현재 페이지 상태 수집
        Note over Env: DOM / Accessibility Tree / Screenshot
        Env-->>Agent: 페이지 구조 + 요소 참조 반환
        Note over Agent: Think — 목표 대비 현재 상태 분석, 다음 행동 결정
        Agent->>Env: Act — 행동 실행 (click, type, scroll, navigate...)
        Env-->>Agent: 행동 결과 + 페이지 변화 피드백
    end

단계	설명	예시
Observe	현재 페이지 상태를 수집	Accessibility Tree 추출, 스크린샷 캡처
Think	LLM이 목표 대비 상태를 분석하고 다음 행동을 계획	”검색창을 찾았으니 텍스트를 입력해야 한다”
Act	브라우저에 구체적 행동을 실행	click(ref=e14), type_text(ref=e5, "query")

Action Space (행동 공간)

Web Agent가 브라우저에서 수행할 수 있는 원자적 행동(primitive) 목록:

Action	설명
navigate(url)	특정 URL로 이동
click(element)	요소 클릭 (버튼, 링크, 체크박스 등)
type_text(element, value)	입력 필드에 텍스트 입력
scroll(direction)	페이지 또는 요소 스크롤
press_key(key)	키보드 키 입력 (Enter, Escape, Tab 등)
extract_page()	페이지 콘텐츠 추출
screenshot()	현재 화면 캡처
done()	작업 완료 선언 및 세션 정리

Playwright — Web Agent의 기반 기술

Playwright는 Microsoft가 개발한 오픈소스 브라우저 자동화 프레임워크로, 원래는 E2E 테스트 도구로 설계되었으나 현재 Web Agent의 핵심 인프라로 진화하고 있다.

Playwright 핵심 구조

sequenceDiagram
    autonumber
    participant Code as Playwright API
    participant BT as BrowserType
    participant B as Browser (Chromium/Firefox/WebKit)
    participant BC as BrowserContext (격리된 세션)
    participant P as Page (탭)

    Code->>BT: chromium.launch()
    BT->>B: 브라우저 프로세스 생성
    B->>BC: browser.newContext()
    Note over BC: 독립된 쿠키, 스토리지, 세션
    BC->>P: context.newPage()
    P->>P: page.goto(), page.click(), page.fill()...

계층	역할
BrowserType	Chromium, Firefox, WebKit 중 브라우저 엔진 선택 및 실행
Browser	실행 중인 브라우저 인스턴스
BrowserContext	격리된 브라우저 프로필 (쿠키, 세션 독립). 하나의 Browser에서 여러 Context 생성 가능
Page	하나의 탭. DOM 조작, 네비게이션, 이벤트 처리의 실제 단위

Playwright의 강점

• Auto-waiting: 요소가 조작 가능한 상태가 될 때까지 자동 대기 (인위적 sleep 불필요)
• Trusted Events: 실제 사용자 입력과 구분 불가능한 브라우저 네이티브 이벤트 생성
• Cross-browser: Chromium, Firefox, WebKit을 단일 API로 제어
• 격리(Isolation): BrowserContext 단위로 세션 완전 격리, 밀리초 단위 생성
• Shadow DOM 관통: Shadow DOM, iframe을 자연스럽게 통과하는 셀렉터

Playwright → Web Agent로의 진화: Playwright MCP

Playwright 자체는 코드로 작성된 시나리오를 실행하는 도구이다. 여기에 MCP(Model Context Protocol)를 결합하면, LLM이 Playwright의 브라우저 제어 능력을 도구(tool)로 호출할 수 있게 된다.

sequenceDiagram
    autonumber
    participant LLM as LLM Agent
    participant MCP as MCP Server (Playwright)
    participant PW as Playwright Engine
    participant Browser as Browser

    LLM->>MCP: tool_call: navigate("https://example.com")
    MCP->>PW: page.goto("https://example.com")
    PW->>CDP: CDP 명령 전송
    CDP->>Browser: 브라우저 내부 실행
    Browser-->>CDP: 페이지 로드 완료
    CDP-->>PW: 결과 반환
    PW-->>MCP: Accessibility Snapshot 반환
    MCP-->>LLM: 페이지 구조 (역할, 이름, 참조 ID)
    Note over LLM: 추론 후 다음 행동 결정

비교	Playwright 단독	Playwright MCP (Web Agent)
지시 방식	코드 (page.click('#btn'))	자연어 (“검색 버튼 클릭해줘”)
적응력	셀렉터 변경 시 코드 수정 필요	LLM이 의미로 요소를 찾아 적응
인식 방식	개발자가 셀렉터 지정	Accessibility Snapshot 자동 분석
사용 주체	개발자/QA 엔지니어	AI 에이전트 (비개발자도 활용 가능)

Playwright MCP는 스크린샷 대신 Accessibility Snapshot을 사용하여 비전 모델 없이도 빠르고 정확한 페이지 인식이 가능하다.

통신 아키텍처

Web Agent가 실제 브라우저를 제어하기 위한 통신 방식은 크게 두 가지로 나뉜다.

방식 1: Chrome Extension + Native Messaging

데스크톱 앱이 사용자의 기존 Chrome 세션(로그인, 쿠키)을 그대로 활용해야 할 때 사용하는 방식이다.

sequenceDiagram
    autonumber
    participant App as Host Application
    participant NMH as Native Messaging Host
    participant Ext as Chrome Extension
    participant CS as Content Script
    participant Tab as Web Page

    App->>NMH: IPC/Socket 명령 전송
    NMH->>Ext: stdin → JSON 메시지 전달
    Ext->>CS: Content Script 주입
    CS->>Tab: DOM 조작 (클릭, 입력, 추출)
    Tab-->>CS: 실행 결과
    CS-->>Ext: 결과 JSON
    Ext-->>NMH: stdout ← JSON 응답
    NMH-->>App: 응답 전달

Native Messaging이란?

Chrome이 제공하는 API로, 브라우저 확장 프로그램이 사용자 컴퓨터에 설치된 로컬 애플리케이션과 통신할 수 있게 해주는 메커니즘이다.

왜 필요한가?

• Chrome Extension은 보안 샌드박스 안에서 동작하여 로컬 파일, 프로세스에 직접 접근 불가
• Web Agent의 호스트 앱(백엔드 서버)은 로컬에서 실행됨
• 이 둘을 연결하는 공식적이고 안전한 브릿지가 Native Messaging

동작 원리:

1. Host Manifest 등록: 로컬 앱이 JSON 매니페스트 파일을 OS 지정 경로에 등록

   {
     "name": "com.example.webagent",
     "description": "Web Agent Native Host",
     "path": "/usr/local/bin/web-agent-host",
     "type": "stdio",
     "allowed_origins": ["chrome-extension://abcdef12345/"]
   }

2. 연결 수립: Extension이 chrome.runtime.connectNative("com.example.webagent") 호출
3. 메시지 교환: stdin/stdout을 통한 JSON 통신 (32-bit 길이 프리픽스 + UTF-8 JSON)
4. 보안: allowed_origins에 명시된 Extension ID만 연결 허용 (와일드카드 불가)

속성	값
인바운드 메시지 최대 크기	1 MB
아웃바운드 메시지 최대 크기	64 MB
연결 방식	영구 연결(connectNative) 또는 단발성(sendNativeMessage)
Content Script에서 직접 사용	불가 — Service Worker를 통해 중계 필요

Host Manifest 등록 경로:

OS	경로
macOS	~/Library/Application Support/Google/Chrome/NativeMessagingHosts/
Linux	~/.config/google-chrome/NativeMessagingHosts/
Windows	레지스트리 HKCU\Software\Google\Chrome\NativeMessagingHosts\

방식 2: Playwright (CDP 직접 제어)

Playwright MCP 등이 사용하는 방식. 브라우저 프로세스를 직접 실행하고 제어한다.

sequenceDiagram
    autonumber
    participant Agent as Agent / MCP Server
    participant PW as Playwright Engine
    participant CDP as Chrome DevTools Protocol
    participant Browser as Browser Process

    Agent->>PW: API 호출 (navigate, click, extract...)
    PW->>CDP: WebSocket CDP 명령
    CDP->>Browser: 브라우저 내부 실행
    Browser-->>CDP: 실행 결과
    CDP-->>PW: 결과 반환
    PW-->>Agent: 구조화된 응답

두 방식 비교

비교 항목	Extension + Native Messaging	Playwright (CDP)
사용자 세션	기존 로그인/쿠키 활용 가능	새 브라우저 프로필 (기본값)
“Debugger” 경고	없음	”Chrome is being controlled by automated test software” 표시
설치 복잡도	Extension + Native Host 설치 필요	npm install playwright
브라우저 호환	Chrome 전용	Chromium, Firefox, WebKit
적합한 사용처	인증된 인트라넷, 개인화된 웹 작업	공개 웹사이트, 테스트, 스크래핑

안전장치 (Guard Mechanisms)

Web Agent는 자율적으로 동작하므로 반드시 안전장치가 필요하다:

위험	안전장치	설명
무한 루프	반복 행동 감지	동일 행동 N회 반복 시 자동 차단
정체(Stale) 상태	페이지 변화 모니터링	여러 행동 후 페이지 변화 없으면 경고
Prompt Injection	입력 검증	웹 페이지 콘텐츠가 에이전트 지시를 오염시키는 공격 방어
세션 폭주	TTL 및 최대 세션 수	유휴 세션 자동 정리, 리소스 보호
민감 작업	사용자 확인	결제, 삭제 등 되돌리기 어려운 작업 전 확인 요청

주요 도전 과제

• 신뢰성: LLM의 추론 오류(hallucination)로 잘못된 요소를 클릭하거나 엉뚱한 작업 수행 가능. WebVoyager 벤치마크 기준 최고 성공률은 약 89%
• 보안: 웹 페이지에 숨겨진 악의적 지시(Prompt Injection)가 에이전트를 조작할 수 있음. Anthropic 연구에서 공격 성공률을 23.6% → 11.2%로 낮췄으나 완전 해결은 미완
• 비용 및 지연: 매 행동마다 LLM API 호출 → 비용과 응답 시간의 트레이드오프
• 동적 콘텐츠: SPA, 무한 스크롤, CAPTCHA, 클라이언트 사이드 렌더링 등은 여전히 난제
• 법적 이슈: 에이전트의 자동화된 웹 접근이 서비스 약관(ToS)을 위반할 수 있는지에 대한 법적 논쟁 진행 중 (Amazon vs. Perplexity 소송, 2025)

주요 프레임워크 및 도구 (2025-2026)

프레임워크	유형	특징
browser-use	오픈소스	Python/TS SDK, WebVoyager 89.1% 달성
Playwright MCP	오픈소스	Accessibility Snapshot 기반, MCP 표준
Stagehand	오픈소스	자연어 명령, 자가 복구(self-healing)
Skyvern	상용	CV + LLM 하이브리드, 코드 불필요
Perplexity Comet	소비자용	Chromium 기반 AI 브라우저
ChatGPT Atlas	소비자용	탭별 에이전트 모드

미래 방향: WebMCP

2026년 2월 Google이 Chrome Canary에 WebMCP 프리뷰를 탑재. 웹사이트가 AI 에이전트를 명시적으로 지원하는 표준을 제안:

• Declarative API: HTML 폼의 구조화된 설명 제공
• Imperative API: 동적 상호작용을 위한 프로그래밍 인터페이스
• W3C를 통해 Google + Microsoft 공동 표준화 추진

에이전트가 웹사이트를 “스크래핑”하는 시대에서, 웹사이트가 에이전트를 “초대”하는 시대로의 전환

참고 문서

• Playwright Official Documentation
• Chrome Native Messaging API
• AI Web Agents: Complete Guide - Skyvern
• The Agentic Browser Landscape in 2026 - No Hacks Podcast
• Browser AI Automation with LLM Agents - deepsense.ai
• The State of AI & Browser Automation in 2026 - Browserless