AI 에이전트로 웹 데이터 수집 가능 여부 자동 검증하기

웹사이트에서 데이터 수집 가능 여부는 보통 크롬 개발자 도구의 Network 탭에서 시작합니다. 페이지를 새로고침한 뒤 XHR/Fetch 요청을 살펴보며 상품·검색 데이터를 담은 엔드포인트를 찾는 방식입니다. 이 작업에는 화면을 사람이 직접 확인한다는 전제가 깔려 있습니다.

AI 코딩 에이전트에게 같은 작업을 맡기면 이 전제가 성립하지 않습니다. 에이전트는 개발자 도구 화면을 눈으로 볼 수 없으므로, DevTools GUI가 해주던 역할을 코드로 대체해야 하기 때문입니다. 즉, 브라우저를 코드로 구동하고 네트워크 트래픽을 프로그래밍 방식으로 가로채 텍스트 로그로 받아야 합니다. 다만 이 제약은 오히려 작업을 재현 가능한 절차로 만드는 조건이 됩니다. 사람의 즉흥적인 확인 대신, 정해진 절차와 판정 기준을 통해 객관적인 결과를 얻을 수 있기 때문입니다.

이 글에서는 특정 사이트의 데이터를 스크래핑하는 방법 대신, 수집 가능 여부를 기술적으로 검증(실측)하는 방법을 다룹니다. 이 과정을 6 단계로 나누어 설명하겠습니다.

⚠️ 법적·기술적 준수 사항 – 자동화된 환경 검증을 진행하기 전, 분석하고자 하는 사이트의 robots.txt 파일 규약과 이용약관(Terms of Service)을 반드시 선제적으로 확인하고 준수해야 합니다. 본 방법론은 무단 데이터 스크래핑을 유도하는 것이 아니며, 허용된 범위 내에서 시스템 인터페이스의 기술적 유효성을 실측하는 안전한 프로세스를 지향합니다.

1. 데이터 렌더링 아키텍처 분석

가장 먼저 수행해야 할 작업은 타겟 페이지의 데이터 렌더링 방식을 기술적으로 식별하는 것입니다. 렌더링 방식은 여러 갈래가 있지만, 여기서는 수집 난이도를 가르는 대표적인 두 방식, 즉 서버 사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)을 기준으로 살펴봅니다. 이는 데이터가 결합하는 시점과 위치를 파악하여, 이후 접근 프로토콜을 결정하는 기초 단계가 됩니다.

판정 메커니즘은 브라우저 초기 진입 시 반환되는 순수 HTML 원본(Raw HTML)을 분석하는 방식으로 진행됩니다.

서버 사이드 렌더링(SSR): 초기 수신된 HTML 소스 코드 내에 핵심 데이터(예: 식별자, 텍스트 콘텐츠 등)가 정적으로 이미 포함되어 있는 상태입니다. 이 경우 별도의 비동기 API 통신을 추적할 필요 없이, 정적 마크업 파싱(Markup Parsing) 기술만으로 데이터 추출 로직을 설계할 수 있습니다.
클라이언트 사이드 렌더링(CSR): 초기 HTML 원본에 <div id="root">와 같은 최소한의 플레이스홀더(Placeholder) 구조만 존재하고 본문 레이어가 비어 있으며, 인라인 JSON(__NEXT_DATA__, window.__INITIAL_STATE__ 등) 데이터 블록도 발견되지 않는 상태입니다. 즉, 페이지 로드 이후 브라우저 런타임 환경에서 자바스크립트를 통해 데이터를 동적으로 채워 넣는 구조입니다. 이 아키텍처에서는 최종 데이터를 실어 나르는 데이터 인터페이스(API 엔드포인트)를 역추적하는 것이 기술적 실측의 핵심 과제가 됩니다.

이처럼 타겟 사이트의 렌더링 구조를 명확히 정의해야만, 후속 단계에서 불필요한 리소스 낭비 없이 네트워크 트래픽 가로채기나 데이터 흐름 추적을 위한 정밀한 자동화 설계를 진행할 수 있습니다.

2. 런타임 네트워크 트래픽 인터셉트 및 캡처

CSR 환경에서 은닉된 데이터 인터페이스를 식별하려면 브라우저 런타임에서 발생하는 모든 네트워크 트래픽을 프로그래밍 방식으로 가로채야 합니다. 이 단계에서는 자동화 프레임워크인 Playwright를 활용합니다.

AI 에이전트 환경에서는 프레임워크가 자체적으로 내려받는 내장(번들) 브라우저를 쓰는 대신, 호스트 시스템에 이미 설치된 정식 상용 브라우저 인프라를 직접 지정하여 구동하는 방식을 채택합니다.

const { chromium } = require('playwright-core');
// 시스템에 내장된 정식 Chrome 바이너리를 호출하여 실행 지문(Fingerprint) 일치화
const browser = await chromium.launch({ channel: 'chrome', headless: true });

playwright-core는 브라우저 바이너리를 포함하지 않는 경량 패키지입니다. 여기에 channel: 'chrome' 옵션을 사용하면 별도의 번들 브라우저를 내려받지 않고 시스템에 설치된 정식 Chrome을 재사용하므로, 설치 볼륨을 최소화할 수 있습니다. 또한, Chromium 대신 실제 사용자가 쓰는 Chrome 바이너리로 구동하기 때문에 브라우저 핑거프린트(Fingerprint)의 차이도 어느 정도 좁혀집니다. 다만 이것만으로 자동화 흔적(navigator.webdriver 등)이 완전히 제거되는 것은 아니며, 고도화된 안티봇 대응은 4단계에서 별도로 다룹니다.

트래픽 캡처의 핵심 메커니즘은 Playwright의 응답 이벤트(page.on('response'))에 비동기 리스너를 바인딩하는 것입니다. 이미지나 스타일시트 같은 정적 자원은 제외하고, 오직 데이터를 실어 나르는 XHR·Fetch 유형의 요청만 필터링하여 응답 데이터의 스키마와 인증 상태를 아티팩트(Artifact)로 기록합니다.

page.on('response', async (resp) => {
  const req = resp.request();
  // 비동기 데이터 통신 요청만 선별하여 기록 (정적 자원 제외)
  if (req.resourceType() !== 'xhr' && req.resourceType() !== 'fetch') return;

  const contentType = (resp.headers()['content-type'] || '').toLowerCase();
  // 파싱 아티팩트 메타데이터 구조화 타겟:
  // - 인프라 식별자: URL, HTTP Method, HTTP Status
  // - 컨텍스트 상태값: 보안 토큰(Authorization, Custom Token), 세션 쿠키(Cookie)
  // - 페이로드 및 응답 구조: Request PostData, Content-Type, Response Body 스키마 트리
});

// 타겟 데이터 플로우 트래킹 (인덱스 진입 및 상호작용 지점 라우팅)
await page.goto(homeUrl,   { waitUntil: 'domcontentloaded' });
await page.waitForTimeout(4000);
await page.goto(searchUrl, { waitUntil: 'domcontentloaded' });
await page.waitForTimeout(4000);

이와 같이 메인 엔트리포인트와 데이터 조회 엔드포인트(검색/목록)를 순차적으로 시뮬레이션하면, 화면 렌더링 과정에서 오간 모든 API 통신 레이어가 정형화된 데이터셋(Text Log)으로 전환되어 자동화 시스템에 축적됩니다. 참고로 위 예시의 waitForTimeout 고정 대기는 구현이 간단한 대신 응답 타이밍에 취약하므로(느린 응답은 놓치고 빠른 페이지는 시간을 낭비함), 실제 파이프라인에서는 특정 응답을 기다리는 page.waitForResponse()나 명시적 조건 대기로 대체하는 편이 안정적입니다.

3. 데이터 인터페이스 식별 및 프로토콜 분류

인터셉트된 트래픽 아티팩트에는 데이터 외에 이미지, 폰트, 광고, 분석용 트래킹 픽셀 등 다양한 노이즈가 혼재되어 있습니다. 이 단계에서는 응답의 Content-Type이 application/json인 데이터 스트림을 필터링하고(정확히 application/json만 보면 application/graphql-response+json 등을 놓칠 수 있습니다), 도메인 핵심 컨텍스트(상품 목록, 검색 결과, 랭킹, 연관 키워드 등)를 포함한 엔드포인트만 추출하여 중복을 제거합니다.

이때 효율적인 데이터 연동을 위해 데이터 인터페이스의 아키텍처 규격을 분류하여 기록합니다.

REST API: URI 경로와 쿼리 파라미터가 리소스와 조회 조건을 식별합니다.
- 예) GET /api/v1/search/products?keyword=...
GraphQL: 리소스의 식별은 URL이 아닌 요청 페이로드(Request Payload)의 operationName 및 query 필드를 통해 수행됩니다. 예) POST /graphql (Payload 내 operationName: "GetSearchResult")

이와 함께 검색 질의어를 담는 파라미터 키(예: q, keyword, query)와 페이지네이션 제어 방식(오프셋 기반 또는 커서 기반 토큰)의 메타데이터를 함께 구조화합니다. 이 정보는 후속 재현 단계에서 데이터 요청 규격을 정확히 복제하는 명세서 역할을 합니다.

4. 보안 컨텍스트 검증 및 안티봇(Anti-Bot) 프로파일링

수집 대상 인터페이스(API 엔드포인트)를 식별했다고 해서 해당 자원을 즉시 외부에서 직접 호출할 수 있는 것은 아닙니다. 요청 헤더의 구성 요소와 안티봇 솔루션의 개입 여부를 정밀하게 분석하여, 데이터가 정상적으로 반환되는 최소 요구 조건(보안 컨텍스트)을 프로파일링해야 합니다.

데이터 인터페이스 인증 메커니즘 분류

데이터 수집 가능 여부와 리소스 투입 비용을 결정하는 가장 큰 변수는 인증 방식의 복잡도입니다. 프로그래밍 방식의 접근을 제어하는 인증 유형은 크게 네 가지 수준으로 분류할 수 있습니다.

인증 유형	기술적 특징	실측 및 우회 난이도
무인증 (Public)	특수 헤더나 세션 상태값 없이, 엔드포인트 URL 호출만으로 `HTTP 200 OK` 및 유효 페이로드를 반환하는 상태	최저 (Low)
익명 세션 토큰 (Anonymous Token)	비로그인 상태의 브라우저 진입 시 런타임에서 발급되는 임시 토큰. `Authorization: Bearer <JWT>` 또는 `X-Anonymous-Token` 등 커스텀 헤더에 바인딩됨	보통 (Medium)
사용자 인증 세션 (Authenticated Session)	정식 회원 가입 및 로그인 프로세스를 거쳐 발급되는 세션 쿠키 또는 OAuth 기반 Access Token이 필수적으로 요구되는 상태	높음 (High)
동적 서명 구조 (Dynamic Sign/HMAC)	요청 페이로드, 타임스탬프, 클라이언트 비밀키를 조합하여 실시간으로 계산된 해시 서명(`Signature`) 헤더를 요구하며, 재생 공격(Replay Attack)을 차단함	매우 높음 (Critical)

익명 세션 토큰의 핵심 구조: 익명 세션 토큰은 무상태(Stateless) 검증을 위해 JWT(JSON Web Token) 형태를 채택하는 경우가 흔하지만, 서버가 보관·조회하는 불투명(Opaque) 토큰일 수도 있습니다. 어느 쪽이든 로그인 없이 발급되므로 수집 자동화가 가능하지만, 토큰의 만료 주기(TTL)를 추적하여 실시간으로 갱신(Refresh)하는 로직이 동반되어야 합니다.

안티봇(Anti-Bot) 및 WAF 방어 계층 프로파일링

인증 메커니즘 외에도 타겟 인프라 전면에서 트래픽을 필터링하는 안티봇 솔루션의 존재 여부를 식별해야 합니다.

네트워크 레이어 방어 (Cloudflare, Akamai, AWS WAF 등): 비정상적인 User-Agent나 자동화 프레임워크의 브라우저 fingerprint가 감지되면, 엔드포인트는 HTTP 403 Forbidden을 반환하거나 챌린지 페이지(때로는 200/503 상태로 내려옴)로 응답을 대체합니다. 한편 HTTP 429 Too Many Requests는 지문 감지가 아니라 짧은 시간에 요청이 과도하게 몰렸을 때(rate limit) 반환되는 코드로, 원인이 다르므로 구분해서 기록해야 합니다.
챌린지 기반 방어 (CAPTCHA / Turnstile): 자바스크립트 런타임 무결성 검증을 강제하는 인터스티셜(Interstitial) 페이지나 챌린지가 개입하는 경우, 초기 응답 본문(Response Body)에 데이터 대신 복잡한 난독화 스크립트가 포함되어 반환됩니다.

이 단계에서는 가로챈 응답의 상태 코드와 헤더, 그리고 본문의 HTML 패턴을 정규식 및 키워드 매칭으로 실측하여, 단순 프로토콜 시뮬레이션(Axios/Fetch API)이 가능한지 혹은 완벽한 브라우저 런타임 가상화(Playwright Full Automation)가 필수적인지 판정합니다.

5. 순수 HTTP 프로토콜 재현 및 세션 독립성 테스트

실측 프로세스의 최종 기술적 판정은 이 단계에서 결정됩니다. 앞선 단계에서 식별한 데이터 인터페이스(API 엔드포인트)와 보안 컨텍스트(헤더 및 토큰)를 기반으로, 무거운 브라우저 가상화 인프라를 완전히 배제한 채 순수 HTTP 요청(Raw HTTP Request)만으로 대상 자원을 독립적으로 호출할 수 있는지 검증합니다.

프로토콜 시뮬레이션 메커니즘

재현 테스트는 외부 라이브러리 의존성을 최소화하기 위해 Node.js 18부터 전역에 내장된 글로벌 Fetch API를 활용하여 수행합니다(18~20에서는 experimental, 21부터 stable로 제공됩니다).

const response = await fetch(endpointUrl, {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'user-agent': 'Mozilla/5.0 ...', // 실측된 브라우저 fingerprint에 맞춘 UA
    'authorization': 'Bearer ' + capturedToken // 4단계에서 실측한 인증 토큰 주입
  },
  body: JSON.stringify(payload),
});

const statusCode = response.status;
const responseBody = await response.json();

이 테스트의 목적은 브라우저의 쿠키 스토리지(Cookie Storage)나 복잡한 자바스크립트 실행 환경 없이 오직 네트워크 레이어의 파라미터 제어만으로 데이터 컨텍스트를 확보할 수 있는지 판정하는 것입니다. 판정 기준은 반환되는 HTTP 상태 코드(Status Code)의 명세에 따라 명확히 갈립니다.

HTTP 200 OK (성공): 유효한 비즈니스 페이로드(상품/검색 데이터)가 손상 없이 반환되는 상태입니다. 이는 대상 사이트가 브라우저 가상화 없이 최소 비용의 순수 HTTP 프로토콜만으로 데이터 수집이 가능한 ‘최적 구조’임을 증명합니다. 다만 상태 코드가 200이라도 응답 본문에 실제 데이터 대신 챌린지 HTML이나 빈 결과가 담겨 내려오는 경우가 있으므로, 상태 코드만으로 성공을 단정하지 말고 목표 데이터가 본문에 실제로 존재하는지까지 확인해야 합니다.
HTTP 401 Unauthorized / 403 Forbidden (제한): 요청이 거부되었거나 접근 권한이 없음을 나타냅니다. 정적인 상태 코드 재현만으로는 우회할 수 없으며, 동적으로 가변하는 보안 토큰이나 활성 세션 컨텍스트의 누락이 대표적인 원인입니다. 다만 토큰 문제 외에도 User-Agent 및 필수 헤더 누락, IP 차단, 안티봇의 지문 탐지 등 원인이 다양할 수 있으므로, 단정 짓기보다는 요청 헤더를 하나씩 보강해가며 재현 가능성을 탐색해야 합니다.

익명 토큰 부트스트랩(Bootstrap) 아키텍처 분석

HTTP 401/403 상태 코드가 반환된다고 해서 프로토콜 기반 수집이 원천적으로 불가능한 것은 아닙니다. 비로그인 기반의 클라이언트 사이드 렌더링(CSR) 환경은 대개 초기 진입 시점에 자동화된 익명 토큰 유효화 단계를 거치는데, 이는 크게 두 가지 아키텍처 패턴으로 분류할 수 있습니다.

명시적 토큰 발급형 (Explicit Issuance): 클라이언트 앱이 구동되면서 POST /api/v1/auth/anonymous와 같은 특수 인증 엔드포인트를 명시적으로 호출하여 세션 토큰을 교환하는 구조입니다. 이 패턴은 발급 API의 자격 증명 조건을 분석하면 토큰 갱신부터 데이터 호출까지의 전 과정을 순수 HTTP 파이프라인으로 일원화할 수 있습니다.
인프라 주입형 부트스트랩 (Infrastructure Bootstrap): 타겟 사이트의 메인 도메인(Home URL)에 초기 진입하는 순간, 게이트웨이나 WAF 계층에서 Set-Cookie 또는 커스텀 응답 헤더를 통해 익명 컨텍스트를 강제로 주입하는 구조입니다. 이 아키텍처에서는 경량 헤드리스 브라우저를 일시적으로 구동하여 초기 영속성 계층(Session/Cookie)을 확보하는 ‘부트스트랩 시퀀스’가 선행되어야 합니다.

// 인프라 주입형 부트스트랩: 초기 진입 시 응답으로 주입되는 익명 컨텍스트를 확보
let bootstrapToken = null;

// 커스텀 응답 헤더로 토큰을 내려주는 경우
page.on('response', (response) => {
  const token = response.headers()['x-anonymous-token'];
  if (token) bootstrapToken = token;
});

// 메인 엔트리포인트 진입을 통해 세션 컨텍스트 활성화 유도
await page.goto(homeUrl, { waitUntil: 'domcontentloaded' });


// 확보된 부트스트랩 토큰을 독립 Fetch 모듈의 헤더로 이식하여 프로토콜 재현
if (bootstrapToken) {
  const apiResponse = await fetch(endpointUrl, {
    headers: { 'X-Anonymous-Token': bootstrapToken }
  });
}

이와 같이 주입형 부트스트랩 상태를 식별하면, 전체 수집 파이프라인을 100% 브라우저 자동화로 유지할 필요 없이 ‘초기 1회 컨텍스트 확보(Playwright) -> 고속 데이터 파싱(Fetch API)’ 구조의 하이브리드 자동화 모델을 설계하여 인프라 컴퓨팅 리소스를 절감할 수 있습니다.

6. 최종 실측 데이터 기반 수집 난이도 및 인프라 아키텍처 분류

자동화 검증 프로세스의 마지막 단계는 이전 과정에서 실측된 검증결과를 결합하여 타겟 사이트의 수집 난이도를 정량적으로 분류하는 것입니다. 이 분류 표준은 특정 웹 레지스트리를 정기적으로 동기화하거나 대규모 데이터 파이프라인을 구축할 때, 어떤 자동화 전략을 채택해야 하는지와 인프라 컴퓨팅 비용이 얼마나 발생할지를 결정하는 최종 의사결정 산출물이 됩니다.

수집 매트릭스 및 비용 산출 분류표

수집 분류 계층	기술적 실측 지표 및 상태	채택 자동화 아키텍처	인프라 리소스 비용
정적 HTML 파싱 (Static SSR)	초기 `Raw HTML` 수신 시점에 도메인 핵심 컨텍스트가 정적 텍스트로 결합되어 전송되는 상태	Axios / Node-Fetch + Cheerio (정적 마크업 파싱)	최저 (Low) 브라우저 및 JS 엔진 구동 전면 배제
프로토콜 직접 호출 (Direct API)	CSR 환경이나 보안 솔루션의 개입이 없으며, `HTTP 200 OK`와 함께 구조화된 JSON 데이터 스트림을 반환하는 상태	글로벌 Fetch API 기반 독립 프로토콜 시뮬레이션	최저 (Low) 네트워크 IO 레이어의 비용만 발생
컨텍스트 부트스트랩 (Token Bootstrap)	초기 접근 시 401/403이 반환되나, 메인 엔트리포인트 진입을 통해 익명 토큰 또는 영속성 세션 주입이 가능한 상태	Playwright (초기 세션 갱신 1회) + 내장 Fetch (실제 데이터 파싱) 하이브리드 모델	보통 (Medium) 세션 만료 주기에 따른 스케줄러 리소스 요구
동적 브라우저 렌더링 (Dynamic Dom Parsing)	내부 데이터 인터페이스가 암호화되거나 페이로드 난독화로 프로토콜 복제가 불가능해, 최종 DOM에 의존해야 하는 상태	Playwright Headless / Headful 런타임 상시 구동 및 클라이언트 렌더링 대기	높음 (High) 메모리 및 CPU 인프라 낭비 심화
접근 제한 인프라 (Anti-Bot Blocked)	고도화된 WAF(Cloudflare Bot Management 등)의 실시간 챌린지 및 동적 HMAC 서명 토큰 검증으로 자동화 지문이 완전 차단된 상태	Playwright + Stealth 플러그인 랩핑, 고비용 프록시(Residential Proxy) 및 CAPTCHA 솔버 연동	최고 (Critical) 우회 성공률 불확실 및 솔루션 비용 극대화

인프라 설계 가이드: ‘프로토콜 직접 호출’과 ‘컨텍스트 부트스트랩’ 단계는 전체 웹 생태계의 CSR 사이트 중 상당수를 차지합니다. 이 구간을 정확히 식별해 내는 것만으로도, 무조건적인 브라우저 자동화(Playwright 상시 구동) 대비 인프라 유지 비용을 크게 절감할 수 있습니다. 절감 폭은 대상 사이트 구성과 트래픽 규모에 따라 달라지므로, 구체적인 수치는 실제 파이프라인에서 측정해 산정하는 것이 정확합니다.

가드레일: 기술적 실현 가능성과 정책적 준수성의 분리

해당 실측 프로세스가 지향하는 핵심 목적은 오직 하나, 즉 ‘기술적으로 대상 데이터에 도달할 수 있는가’를 검증하는 것입니다. 기술적 가부와 별개로, 실제 데이터를 영속적으로 수집해도 되는지에 대한 정책적 판단은 실측 아티팩트와 철저히 분리하여 독립적으로 다루어야 합니다.

정책 및 법적 규약의 독립적 검토: robots.txt 규약 확인과 대상 서비스의 이용약관(ToS) 저촉 여부는 기술적 실측과 별개의 트랙으로 진행합니다. 기술적 우회가 가능하다고 해서 정책적 수집이 허용됨을 의미하지 않습니다.
안티봇 솔루션의 반복 우회 지양: Cloudflare 등의 WAF 계층에서 강한 챌린지나 CAPTCHA 유효성 검증이 반복될 경우, 우회 스크립트를 고도화하기보다 즉시 실측을 중단하고 ‘해당 환경 기준 수집 불가’ 아티팩트로 최종 기록합니다.
실측 컨텍스트의 한계성 명시: 데이터센터 IP 대역, 헤드리스 구동 환경 등 실측 당시의 인프라 컨텍스트에 따라 결과는 언제든 변동될 수 있습니다. 따라서 산출물에는 항상 ‘해당 시점 및 인프라 환경 한정’이라는 단서를 명시합니다.
타겟 인프라 부하 최소화: 검증 과정에서의 요청량은 철저히 제한합니다. 화면당 1회 진입, 단일 대표 검색어 쿼리 송신을 원칙으로 삼아 대상 서버에 가해지는 트래픽 노이즈를 최소화합니다.

마치며

이 글에서 다룬 내용을 요약하면 핵심은 크게 두 가지입니다.

첫째, ‘AI 에이전트가 브라우저 화면을 직접 볼 수 없다’는 제약은 오히려 수집 프로세스를 정형화하고 재현 가능한 코드로 전환하는 계기가 됩니다. page.on('response') 기반의 네트워크 인터셉트와 글로벌 Fetch API를 통한 순수 HTTP 재현 과정은, 인간의 직관이나 개발자 도구 조작에 의존하는 기존 방식보다 일관되고 재현 가능한 실측 지표를 제공합니다.

둘째, 이처럼 표준화된 절차와 판정 기준을 구조화된 런북(Runbook) 프롬프트로 정립할 때 자동화의 완성도가 높아집니다. 파편화되던 실측 업무를 에이전트가 즉시 실행 가능한 규격으로 패키징하면, 대상 사이트가 바뀌더라도 항상 동일한 품질의 결과물을 반복해서 얻을 수 있습니다. 에이전트를 일회성 코딩 도구로 쓰는 데 그치지 않고, 수집 난이도를 진단하는 파이프라인의 핵심 주체로 활용하는 것이 이 가이드의 목적입니다.

참고

최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.

비즈스프링 뉴스레터 구독하기 →