본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 28. 11:12

당신의 AI 에이전트는 스크래핑을 못 하는 것이 아니라, 읽기에 실패하고 있는 것입니다

요약

현대적인 SPA 환경에서 AI 에이전트가 단순 HTTP 요청만으로는 데이터를 제대로 읽지 못하는 문제를 지적합니다. 이를 해결하기 위해 브라우저 엔진을 활용하여 JavaScript 실행과 DOM 렌더링이 완료된 상태의 데이터를 추출하는 방식의 중요성을 강조합니다.

핵심 포인트

  • 단순 HTTP 요청은 클라이언트 사이드 렌더링(CSR) 데이터를 가져오지 못함
  • AI 에이전트에게는 단순 페처가 아닌 브라우저 엔진이 필요함
  • Playwright나 Browserless 같은 도구를 통해 브라우저 생명주기를 제어해야 함
  • 데이터 추출을 넘어 브라우저 상태를 조작하는 변이 패턴이 핵심임

데이터가 전혀 포함되지 않은 200 OK 응답을 멍하니 바라보고 있었습니다. 그저 뼈대뿐인 구조, 로딩 스피너, 그리고 HTML의 신에게 바치는 소리 없는 기도뿐이었습니다.

Claude나 Cursor가 표준 HTTP 요청을 사용하여 현대적인 웹 엔드포인트에 접속하는 에이전트 워크플로우 (agentic workflow)를 구축하려고 시도해 본 적이 있다면, 여러분도 이 벽에 부딪혀 보았을 것입니다. 요청은 성공적입니다. 연결은 견고합니다. 하지만 그 페이로드 (payload) 내부에는 무엇이 있을까요? 하이드레이션 (hydration)을 기다리는 <div id="app"></div>와 무거운 React 번들 외에는 아무것도 없습니다.

문제는 LLM이나 여러분의 프롬프트 (prompt)가 아닙니다. 문제는 여러분의 도구 세트가 웹이 여전히 2005년에 서비스되던 정적 HTML 파일로 구성되어 있다고 가정한다는 점입니다. 우리는 더 이상 그런 세상에 살고 있지 않습니다. 우리는 복잡하고 상태를 유지하며, 클라이언트 사이드 렌더링 (client-side rendered)되는 싱글 페이지 애플리케이션 (SPA)의 시대에 살고 있습니다. 여기서 여러분이 실제로 원하는 데이터는 JavaScript 루프가 실행을 마치고 DOM을 채우기 전까지는 존재조차 하지 않습니다.

사람들이 'AI 에이전트에게 손을 달아주는 것'에 대해 이야기할 때, 보통 단순한 API 통합이나 기본적인 웹 스크래퍼 (web scraper)를 떠올립니다. 하지만 그 손이 정적인 스냅샷만을 잡을 수 있다면, 현대 웹의 90% 앞에서는 무용지물입니다. QA 테스트, 경쟁 가격 인텔리전스 (competitive pricing intelligence), 또는 실시간 데이터 추출과 같이 의미 있는 무언가를 실제로 자동화하려면, 에이전트에게는 HTTP 클라이언트 이상의 것이 필요합니다. 브라우저 엔진 (browser engine)이 필요합니다.

단순한 페처 (Fetcher)의 오류

현재 GitHub를 떠도는 대부분의 MCP 서버들은 기본적으로 미화된 curl 래퍼 (wrapper)에 불과합니다. URL에 접속하여 원시 텍스트를 가져온 뒤 컨텍스트 윈도우 (context window)에 밀어 넣습니다. 이는 문서나 Wikipedia의 경우에는 잘 작동합니다. 하지만 이커머스 사이트, 대시보드, 또는 Vue, React, Next.js를 사용하는 기술 스택을 마주하는 순간 처참하게 실패합니다.

제가 Vinkius에서 Playwright Cloud를 통해 Browserless를 사용하기 시작했을 때, 가능해진 것들의 변화는 즉각적으로 분명해졌습니다. 여러분은 단순히 요청을 보내는 것이 아닙니다. 원격의 헤드리스 Chromium (headless Chromium) 인스턴스를 구동하는 것입니다. 여러분은 응답을 요청하는 것이 아니라, 브라우저 생명주기 (browser lifecycle) 전체를 명령하고 있는 것입니다.

이것이 바로 get_html_content와 같은 도구들이 표준 페처 (fetcher)와 근본적으로 다른 이유입니다. 에이전트가 이를 호출할 때, 단순히 응답의 첫 번째 바이트를 가져오는 것이 아닙니다. 앞서 언급한 하이드레이션 루프 (hydration loop)가 안정화될 때까지 기다리는 것입니다. 엔진이 스크립트 실행과 요소 렌더링이라는 힘든 작업을 처리하므로, 데이터가 마침내 여러분의 LLM 컨텍스트 (context)에 도달했을 때는 실행이 완료된 최종적인 DOM 상태가 됩니다.

추출을 넘어: 변이 패턴 (The Mutation Pattern)

이 지점이 대부분의 개발자들—심지어 시니어 개발자들조차—이 실제 가치를 놓치는 부분입니다. 그들은 무엇을 _읽을 수 있는지_에 대해서만 생각합니다. 하지만 그들은 읽기 전에 무엇을 _할 수 있는지_를 생각해야 합니다.

이 특정 MCP에서 가장 강력한 도구 중 하나는 scrape_with_js입니다. 이것은 단순히 텍스트를 파싱하는 방법이 아니라, 브라우저 상태를 조작하라는 명령형 명령 (imperative command)입니다. 여러분이 에이전트에게 결제 흐름 (checkout flow)을 감사하도록 지시한다고 상상해 보십시오. 표준 스크래퍼는 페이지에 접속하지만 아무것도 보지 못합니다. 왜냐하면 '할인 코드' 필드는 특정 토글을 클릭한 후에만 나타나기 때문입니다.

scrape_with_js를 사용하면, 에이전트는 원격 브라우저 내부에서 자체적인 로직을 실행할 수 있습니다. 토글을 클릭하고, 애니메이션을 기다리고, DOM과 상호작용한 다음, 그제서야 업데이트된 상태를 추출할 수 있습니다. 여러분은 사실상 LLM에게 run_custom_function을 통해 실제 Chrome DevTools Protocol (CDP) 환경에서 실행되는 작고 정밀한 스크립트를 작성할 수 있는 방법을 제공하는 것입니다.

저는 에이전트가 복잡한 다단계 양식을 탐색하는 임무를 맡은 유스케이스 (use cases)를 보았습니다. 이것은 단순히 '요소를 스크래핑하는 것'이 아닙니다. 버튼을 찾기 위한 scrape_elements, 버튼을 클릭하기 위한 scrape_with_js, 그리고 그 결과를 확인하는 일련의 DOM 조작 과정을 수행하는 것입니다. 그것은 스크래핑이 아닙니다. 그것은 자동화된 상호작용 (automated interaction)입니다.

쫓고 쫓기는 게임: 스텔스(Stealth)와 프록시(Proxies)

대규모 크롤러 (crawler)를 운영해 본 적이 있다면, 웹이 당신을 차단하기 위해 적극적으로 움직이고 있다는 사실을 알고 있을 것입니다. Cloudflare, Data Dome, Akamai 등은 모두 헤드리스 브라우저 (headless browser)의 지문 (fingerprints)을 찾고 있습니다. 이들은 특정 헤더 (headers), 일관되지 않은 TLS 지문 (TLS fingerprints), 또는 알려진 데이터 센터 IP 범위 (IP ranges)를 탐색합니다.

이것이 바로 제가 신뢰성을 원한다면 기본적인 Docker 컨테이너에서 직접 Playwright 클러스터를 관리하는 것을 권장하지 않는 이유입니다. 실제 제품을 만드는 시간보다 프록시 로테이션 (proxy rotation)과 헤더 스푸핑 (header spoofing)을 관리하는 데 더 많은 시간을 쓰게 될 것입니다.

Browserless MCP는 scrape_with_stealth를 제공함으로써 이 문제를 해결합니다. 이는 특화된 플러그인 (plugins)을 사용하여 브라우저가 헤드리스 상태라는 사실을 숨기고, 인간과 유사한 환경을 에뮬레이션 (emulating)하여 표준 WAF (Web Application Firewall) 도전을 우회합니다. 만약 IP 기반의 속도 제한 (rate limiting)에 부딪힌다면, scrape_with_proxy를 사용하여 주거용 엔드포인트 (residential endpoints)를 통해 요청을 전달할 수 있습니다.

스텔스 모드 (stealth mode)와 프록시 (proxying)를 결합하면, 당신의 에이전트는 더 이상 '봇 (bot)'이 아니라 매우 분산된 사용자 기반처럼 행동하기 시작합니다. 이는 대상 사이트가 데이터를 적극적으로 방어하고 있는 환경에서 진지한 시장 조사나 경쟁 정보 (competitive intelligence)를 수행하는 모든 이들에게 매우 중요합니다.

시각적 감사 (Visual Auditing): get_screenshot의 힘

텍스트 전용 에이전트에게 부족한 검증 요소도 존재합니다. UI 회귀 (UI regressions)를 확인하기 위해 스테이징 사이트 (staging site)를 모니터링하는 용도로 에이전트를 사용한다면, HTML을 읽는 것만으로는 충분하지 않습니다. 레이아웃 시프트 (layout shift)를 직접 보아야 합니다.

get_screenshot 도구를 사용하면 에이전트가 전체 페이지 스크린샷 (full-page screenshots)을 찍을 수 있습니다. Browserless 고유의 'Full Page' 수정자 (modifier)를 사용하기 때문에, 단순히 작은 뷰포트 (viewport)에 보이는 것만 캡처하는 것이 아니라, 계산 프레임 (computational frame)을 확장하여 맨 위부터 맨 아래까지 모든 픽셀을 캡처합니다.

저는 이를 고충실도 (high-fidelity) 감사에 사용합니다. 저는 에이전트에게 다음과 같이 요청할 수 있습니다: "우리 랜딩 페이지의 스크린샷을 찍고, 모바일 뷰포트 (mobile viewports)에서 히어로 이미지가 왜곡되어 보이는지 알려줘." 에이전트는 CSS 속성 (properties)을 기반으로 추측하는 것이 아니라, 렌더링된 .png 아티팩트 (artifact)를 직접 보고 있는 것입니다. 이는 그림에 대한 설명을 읽는 것과 실제로 그림 앞에 서 있는 것의 차이와 같습니다.

프로덕션 환경을 위한 엔지니어링: 왜 Vinkius인가?

제가 MCPFusion을 구축한 이유는 프로덕션 (production) 환경에 진입하는 순간 산산조각이 나는 '멋진' 프로토타입을 만드는 개발자들을 너무 많이 보았기 때문입니다. 그들은 API 키를 하드코딩하거나, 셀렉터 (selector)가 변경되었을 때의 에러 핸들링 (error handling)을 무시하거나, 혹은 가장 최악의 경우로, 에이전트가 원하는 모든 URL에 접근하게 함으로써 로컬 환경을 SSRF (Server-Side Request Forgery, 서버 측 요청 위조)에 노출시키곤 했습니다.

Vinkius를 통해 Browserless MCP를 사용할 때, 여러분은 단순히 연결 문자열 (connection string)만 얻는 것이 아닙니다. 여러분은 프로덕션급 인프라 (infrastructure)를 얻는 것입니다. 모든 실행은 격리된 V8 샌드박스 (sandboxes)에서 이루어집니다. 저희는 DLP (Data Loss Prevention, 데이터 손실 방지) 및 HMAC 감사 체인 (audit chains)을 포함하여 8가지의 별도 거버넌스 정책 (governance policies)을 구현했습니다.

AI 에이전트에게 자바스크립트 (JavaScript)를 실행할 수 있는 능력(scrape_with_js)이나 임의의 URL에 접속할 수 있는 권한을 부여하는 것은, 본질적으로 에이전트에게 여러분의 내부 네트워크를 탐색할 수 있는 방법을 주는 것과 같습니다. 이를 극도로 주의하여 처리하지 않는다면, 여러분은 스스로 회사에 보안 취약점을 구축한 셈입니다. Vinkius는 우리가 이 에이전트들에게 부여하는 '손'이 킬 스위치 (kill switches), 샌드박싱 (sandboxing), 그리고 제어된 실행 컨텍스트 (execution contexts)와 같은 엄격한 정책에 의해 구속되도록 보장합니다.

골치 아픈 일 없이 실제로 사용하는 방법

설정 과정은 의도적으로 마찰을 최소화했습니다. 저는 개발자들이 단 하나의 기능을 테스트하기 위해 OAuth 콜백 (callbacks)을 설정하는 데 세 시간을 허비하는 것을 보는 것이 정말 싫습니다.

  1. 연결 토큰 (connection token)을 가져옵니다.
  2. 이를 Claude 또는 Cursor에 붙여넣습니다.

그게 끝입니다. Puppeteer 인스턴스 (instances) 군단을 관리하거나 로컬 Node 프로세스 (process)의 메모리 누수 (memory leaks)를 걱정할 필요가 없습니다. 힘든 작업은 클라우드 (cloud)에서 수행되며, 여러분은 그저 MCP 프로토콜 (protocol)을 통해 결과물을 소비하기만 하면 됩니다.

전체 문서(documentation)를 확인하고 즉시 연결을 시작하려면 여기를 방문하세요: https://vinkius.com/mcp/browserless-playwright-cloud

핵심 요약 (The Bottom Line)

'가져오기 (fetching)'의 시대가 끝나가고 있습니다. 우리는 '상호작용 (interacting)'의 시대로 진입하고 있습니다. 만약 여러분의 에이전트 워크플로우 (agentic workflows)가 여전히 정적 문자열 (static strings)을 파싱 (parsing)하는 사고방식에 머물러 있다면, 여러분은 웹 가치의 90%를 놓치고 있는 것입니다. 스크레이퍼 (scrapers)를 만드는 것을 멈추세요. 브라우저 (browsers)를 만들기 시작하세요.

MCP는 AI 에이전트 (AI Agents)의 음악입니다. 우리는 카탈로그를 구축했습니다. Vinkius MCP Catalog를 확인해 보세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0