CSS 선택기를 사용하는 파서는 사이트가 레이아웃을 변경할 때 고장납니다. LLM 기반 파서는 고장나지 않지만, 각 페이지마다 비용이 발생합니다. 2026년에는 이들 사이의 선택이 취향의 문제가 아니게 되었습니다: 모델의 가격이 수십 배 차이나고, 동일한 페이지는 모델에 보낸 내용에 따라 3,000 또는 20,000 토큰의 비용이 발생할 수 있습니다. 아래는 비용, 신뢰성 및 프록시 트래픽 측면에서 세 가지 접근 방식을 비교한 것입니다. 1,000 페이지와 1백만 페이지를 기준으로 계산했습니다.
간단히: 무엇을 선택할까
- 선택기 (CSS/XPath) — 하나의 페이지 템플릿, 대량 처리, 안정적인 레이아웃. 추출 비용은 거의 제로에 가깝지만, 지원은 개발자에게 달려 있습니다.
- LLM 추출 — 다양한 사이트, 불안정한 레이아웃, 일회성 작업. 각 페이지마다 토큰을 지불해야 하며, 응답을 검증해야 합니다.
- 하이브리드 — LLM이 한 번 선택기를 작성하고, 이후에는 선택기가 작동하며, 데이터 검증이 실패할 때만 모델을 호출합니다. 대부분의 지속적인 파서에게는 최적의 선택입니다.
비교 기준
최종 비용과 데이터 품질에 실제로 영향을 미치는 다섯 가지 항목을 비교합니다:
- 1,000 페이지당 추출 비용;
- 레이아웃 변경 시 동작;
- 정확성과 허위 값의 위험;
- 속도와 지연;
- 프록시 트래픽 소비 — 이는 방법 선택에 거의 영향을 받지 않습니다.
LLM 추출 비용: 2026년 10월 가격 기준으로 계산
표준 요금제에서 백만 토큰(입력/출력)의 공식 가격:
- Gemini 2.5 Flash-Lite — $0.10 / $0.40;
- Gemini 3.1 Flash-Lite — $0.25 / $1.50;
- Claude Haiku 4.5 — $1 / $5;
- Gemini 3.5 Flash — $1.50 / $9.
Google과 Anthropic은 응답이 즉시 필요하지 않은 파싱을 위한 입력 및 출력에 50% 할인된 배치 API를 제공합니다. 이는 첫 번째 절약 수단입니다.
주요 변수는 모델이 아니라 당신이 보내는 내용입니다
모델에 전달되는 원시 HTML 페이지는 일반적으로 10,000~40,000 토큰을 차지합니다. Cloudflare는 에이전트를 위한 Markdown 기능을 시작하면서 예를 들었습니다: 동일한 블로그 게시물은 HTML에서 16,180 토큰, Markdown에서 3,150 토큰으로 80% 감소합니다. 뉴스, 문서 및 상품 카드에 대한 다른 측정치는 67%에서 94%까지 감소합니다.
계산을 위해 가정을 해보겠습니다: 원시 페이지는 20,000 토큰, Markdown으로 정리된 페이지는 3,000 토큰, 지침 및 스키마에 500 토큰, 출력은 300 토큰 JSON입니다. 1,000 페이지에 대해 다음과 같은 결과를 얻습니다:
| 모델 | 원시 HTML (20.5M 입력) | Markdown (3.5M 입력) |
|---|---|---|
| Gemini 2.5 Flash-Lite | ≈ $2.17 | ≈ $0.47 |
| Gemini 3.1 Flash-Lite | ≈ $5.58 | ≈ $1.33 |
| Claude Haiku 4.5 | ≈ $22.00 | ≈ $5.00 |
| Gemini 3.5 Flash | ≈ $33.45 | ≈ $7.95 |
최악의 경우와 최상의 경우 사이의 차이는 동일한 결과에 대해 70배입니다. 이 차이의 3분의 2는 입력 정리에서 발생하며, 모델 선택이 아닙니다. 월 1백만 페이지의 경우 이는 약 $470 또는 $33,000 이상입니다.
또한 한 가지 사항: Claude 모델은 4.7 버전부터 새로운 토크나이저를 사용하며, 이는 Anthropic의 데이터에 따르면 동일한 텍스트에 대해 약 30% 더 많은 토큰을 제공합니다. 다양한 세대 모델의 청구서를 비교할 때 이를 고려해야 합니다 — Haiku 4.5는 오래된 토크나이저에서 작동합니다.
선택기: 사이트가 변경되지 않는 한 거의 무료
이미 다운로드된 페이지에서 CSS 또는 XPath 선택기를 실행하는 데 걸리는 시간은 CPU의 밀리초의 일부입니다. ScrapingBee 가이드에 따르면, 안정적인 레이아웃에서 일반 선택기는 LLM 추출보다 약 10배 저렴하고 빠릅니다. 실제로는 선택기가 모델 API에 대한 네트워크 요청이 없기 때문에 차이가 더 큽니다.
선택기의 가격은 지원에 있습니다:
- 사이트가 클래스를 이름 변경하거나 블록을 새로운 div로 감싸면 파서는 조용히 빈 필드를 반환합니다;
- A/B 테스트가 다른 방문자에게 서로 다른 템플릿을 보여주면 일부 페이지가 파싱되지 않습니다;
- 50개의 서로 다른 사이트에서 50세트의 선택기를 지원해야 합니다.
가장 위험한 시나리오는 고장이 아니라 데이터의 조용한 손상입니다: 선택기가 인접 요소를 잡아내어 데이터베이스에 몇 주 동안 현재 가격 대신 오래된 가격이 기록됩니다.
LLM: 레이아웃에 강하지만 허위 값을 생성할 수 있음
모델은 요소에 대한 정확한 경로가 필요하지 않으며, 의미에 따라 "가격"을 찾습니다. 이는 이름이 변경된 클래스와 다양한 템플릿 문제를 해결합니다. 그러나 실제로 이러한 파서를 운영한 모든 사람들이 설명하는 세 가지 전형적인 오류가 발생합니다:
- 허위 값 — 모델이 페이지에 없는 가격이나 품목을 "추측"합니다;
- 누락된 필드 — 일부 데이터가 추출되지 않았습니다;
- 구조의 드리프트 — 숫자 대신 문자열, 다른 키 이름.
보호는 필수입니다: 엄격한 응답 스키마, 검증(예: Pydantic), temperature = 0 및 오류 발생 시 재시도. 온도를 0으로 설정하면 변동성이 줄어들지만 환각을 완전히 없애지는 않습니다. 가격 및 재고에 대해서는 "값이 페이지 텍스트에 실제로 존재하는지 확인"하는 검증을 추가하는 것이 합리적입니다.
지연도 더 높습니다: 프록시를 통한 페이지 로드 시간에 모델 응답이 추가됩니다 — 몇 초에서 수 초까지 걸릴 수 있습니다. 하루에 한 번 모니터링하는 데는 중요하지 않지만, 드롭을 추적하는 데는 치명적입니다.
하이브리드: LLM이 선택기를 작성하고 데이터를 추출하지 않음
세 번째 방법은 인기 있는 라이브러리에서 직접 지원됩니다. Crawl4AI에는 스키마 생성 기능이 있습니다: 모델이 HTML 샘플을 한 번 보고 CSS/XPath 선택기 세트를 반환한 후, 추출은 LLM 호출 없이 진행됩니다. 문서에서는 이것이 일회성 비용이며, 스키마는 제한 없이 재사용할 수 있다고 강조합니다; 여러 샘플이 있을 경우 모델은 종종 취약한 위치 기반 선택기 대신 속성에 따라 더 안정적인 선택기를 선택합니다.
하이브리드의 작동 스키마:
- LLM이 동일한 템플릿의 3-5 샘플에 대해 선택기를 생성합니다.
- 파서는 선택기로 작동하며, 각 레코드를 검증기가 확인합니다: 필드가 제자리에 있고, 유형이 올바르며, 가격이 합리적인 범위에 있습니다.
- 유효하지 않은 레코드의 비율이 임계값(예: 2-5%)를 초과하면 페이지는 LLM 추출로 넘어가고, 스키마는 재생성됩니다.
- 새 스키마는 검증 샘플에서 실행된 후에만 이전 스키마를 대체합니다.
이렇게 하면 레이아웃 변경 시에만 모델에 비용을 지불하고, 백만 페이지마다 비용을 지불하지 않게 됩니다.
요약 표
| 기준 | 선택기 | LLM 추출 | 하이브리드 |
|---|---|---|---|
| 추출 비용 | 거의 제로 | $0.5–33 (1,000 페이지당) | 거의 제로 + 일회성 호출 |
| 레이아웃 변경 | 고장, 종종 조용히 | 보통 견딘다 | 자동으로 수정됨 |
| 허위 데이터의 위험 | 없음 (하지만 "잘못된 요소"는 있음) | 있음, 검증 필요 | 최소화됨 |
| 속도 | 최대 | + 각 페이지에서 모델 응답 | 선택기와 동일 |
| 다양한 사이트 | 유지 비용이 비쌈 | 강점 | 좋음, 각 템플릿에 대한 스키마 |
| 프록시 트래픽 | 동일 — 모델이 다운로드된 바이트를 줄이지 않음 | ||
프록시에 대해: LLM은 트래픽을 절약하지 않음
계산에서 흔히 발생하는 오류는 "스마트" 파서가 네트워크에서 더 저렴하다고 생각하는 것입니다. 아닙니다: HTML을 Markdown으로 변환하는 것은 다운로드 후에 발생하므로, 어떤 추출 방법을 사용하든 프록시를 통해 전체 페이지가 전달됩니다. 예외는 소유자가 Accept: text/markdown 헤더에 따라 Markdown을 제공하도록 설정한 사이트입니다 (Cloudflare 기능처럼), 하지만 이는 사이트의 결정이지 당신의 결정이 아닙니다.
규모를 위해: HTML 크기가 200KB이고 이미지가 없을 경우 1,000 페이지는 약 0.2GB 또는 약 $0.54입니다 주거용 프록시에서 GB당 $2.70입니다. 위 표와 비교해보세요: 원시 HTML을 Claude Haiku 4.5에 보내면 모델 비용이 프록시 비용의 40배가 될 것이고, Markdown 및 Flash-Lite의 경우는 비슷할 것입니다. 헤드리스 브라우저로 페이지를 렌더링하면 트래픽이 몇 배로 증가합니다 — 우리의 비교에서 Playwright, Puppeteer 및 requests의 1,000 페이지에 대한 트래픽 소비에 대한 측정이 있습니다.
어떤 방법을 사용하든 트래픽에 실제로 영향을 미치는 것은:
- 필요하지 않은 경우 이미지, 글꼴 및 분석을 다운로드하지 마십시오;
- HTML 대신 내부 JSON API를 찾으십시오;
- 불필요한 반복을 피하십시오: 각 차단 및 재시도는 비용이 발생하는 바이트입니다. GB당 가격이 속이는 이유에 대한 자세한 내용은 실제 성공적인 기록의 비용 분석에서 확인하십시오.
엄격한 안티봇 보호가 없는 간단한 카탈로그의 경우 데이터 센터 프록시가 GB당 $1.50이면 충분합니다; 주거용 프록시는 호스팅 IP가 들어오는 것을 차단하는 곳에서 필요합니다.
시나리오에 대한 권장 사항
- 하나 또는 세 개의 마켓플레이스 가격 모니터링, 수십만 카드. 하이브리드 또는 검증기가 있는 순수 선택기. 스키마 재생성을 위해서만 LLM을 연결하십시오.
- 수백 개의 이질적인 사이트에서 데이터 수집 (리드, 채용, 연락처). 배치 모드에서 저렴한 모델을 통한 Markdown의 LLM 추출. 엄격한 스키마와 검증 없이 실행하지 마십시오.
- 수천 페이지에 대한 일회성 연구. LLM: 몇 달러로 선택기를 작성하는 데 며칠을 절약할 수 있습니다.
- 오류가 비용이 드는 데이터 (재가격 책정을 위한 가격, 재고). 선택기 또는 하이브리드와 페이지의 원본 텍스트와 값을 비교하십시오.
- RAG 및 지식 베이스. 여기서는 구조가 아니라 순수한 텍스트가 필요합니다: 필드 추출 없이 Markdown으로 변환하고, 모델은 응답 단계에서만 사용됩니다.
결론
LLM 추출은 선택기를 대체하지 않았고, 선택의 기준점을 이동시켰습니다. 가장 저렴한 것은 하이브리드입니다: 모델이 선택기를 작성하고 수정하며, 각 페이지를 읽지 않습니다. 모델 없이 각 페이지를 처리할 수 없다면, 먼저 입력을 Markdown으로 정리하고 배치를 사용하십시오: 이 두 단계는 모델을 선택하기 전에 비용을 5-10배 줄입니다. 그리고 추출 방법에 따라 프록시 트래픽이 달라지지 않는다는 점을 기억하십시오: 다운로드하는 내용에서 절약해야 하며, 어떻게 분석하는지는 중요하지 않습니다.