LLM 추출이 더 이상 돈값을 하지 못할 때

LLM 추출이 더 이상 돈값을 하지 못할 때

Firecrawl은 페이지를 scrape하는 데 1 크레딧을 청구하고, 동일한 페이지에서 구조화된 필드를 추출하는 데 5 크레딧을 청구합니다 (Firecrawl pricing, 2026). 이는 모델을 거치는 동일한 HTML에 대해 5배의 마크업을 적용하는 것입니다.

광고 문구는 사실입니다. 원하는 것을 설명하면 JSON을 돌려받고, 유지 관리할 selector도 없습니다. 불안정한 레이아웃과 일회성 대상의 경우, 이 마크업은 제값을 합니다. 하지만 동일한 5개 소매업체에서 하루에 50만 개의 상품 페이지를 가져오는 프로덕션 파이프라인의 경우에는 그렇지 않습니다.

저희는 여러 팀이 LLM 기본 추출 방식을 배포했다가, 청구서가 나오는 달에 직면하여 탈출구를 찾기 시작하는 모습을 보았습니다. 해결책은 대개 LLM을 포기하는 것이 아닙니다. 파이프라인의 올바른 위치에 LLM을 배치하는 것입니다.

계산이 빠르게 끔찍해집니다

저렴한 편에 속하는 Firecrawl을 예로 들어보겠습니다. crawl을 제외한 scrape와 AI 추출은 페이지당 6 크레딧이고, crawl을 포함하면 7 크레딧입니다 (ScrapeGraphAI breakdown, 2026). 이들의 growth 티어에서 하루에 10만 페이지를 처리하면 재시도 비용을 제외하고, 단 하나의 proxy 비용도 지불하기 전에 매월 대략 21,000달러가 소요됩니다.

자체 LLM 파이프라인을 운영하면 계산이 달라지긴 하지만 비용이 적어지지는 않습니다. GPT-4o는 입력 토큰 100만 개당 2.50달러, 출력 토큰 100만 개당 10달러입니다 (PricePerToken, 2026). 마크다운 변환 후의 상품 페이지는 4,000~8,000개의 입력 토큰을 소모합니다. JSON 블롭을 위해 입력 6,000개, 출력 200개라고 가정해 보겠습니다. 하루 10만 페이지 기준, 이는 매일 360달러, 매월 11,000달러에 달하며, 이는 한 번의 설정만으로 CSS selector가 무료로 처리할 수 있는 작업입니다.

이것이 저렴한 모델의 경우입니다. Claude Sonnet 4.6(입력 3달러, 출력 15달러)으로 전환하면 비용이 두 배로 늘어납니다 (PE Collective, 2026). 추론 모델로 전환하면 답변하기 전에 생각하는 양에 따라 3~10배의 페널티가 추가됩니다.

이 중 어느 것도 실패 사례를 계산에 넣지 않은 것입니다. 35%의 환각 비율은 직접 계산해 보기 전까지는 무해해 보입니다. 하루 10만 페이지 기준, 이는 3,0005,000개의 잘못된 레코드가 데이터 웨어하우스로 유입됨을 의미하며, 모델이 확신을 가지고 결과를 반환했기 때문에 올바른 레코드와 똑같이 보입니다. DataHen이 언급했듯이 "AI가 가끔 틀리는 것이 문제가 아닙니다. 확신을 가지고 틀리는 것이 문제입니다." (DataHen, 2026).

경험 많은 팀들이 실제로 하는 일

프로덕션 환경에서 실제로 scraper를 운영하는 벤더들의 문서를 읽어보면 패턴은 일관적입니다. 바로 하이브리드 방식입니다. LLM을 사용하여 페이지를 한 번 파악한 다음, 이후의 모든 작업에는 저렴하고 결정론적인 코드를 실행하는 것입니다.

Zyte는 자체 문서에서 이를 명확히 설명합니다. "페이지당 LLM을 사용하는 대신, 첫 페이지의 raw HTML이 주어졌을 때 원하는 필드에 대한 CSS selector를 생성하도록 LLM을 사용하고, 해당 selector를 사용하여 다른 모든 페이지를 파싱하십시오." (Zyte LLM guide, 2026). Apify도 2026년 가이드에서 동일한 흐름을 권장합니다. 먼저 CSS selector를 시도하고, 실패할 경우 LLM으로 대체하는 것입니다 (Apify 2026 guide). 프로덕션 배포에 대한 DEV Community의 글은 이 아키텍처를 정확히 포착했습니다. 캐싱된 selector 경로는 비용이 들지 않으며, 검증이 실패할 때만 LLM이 실행됩니다 (DEV.to, 2026).

따라서 프로덕션에서의 분할 방식은 다음과 같습니다.

• LLM이 selector를 부트스트랩합니다 (대상당 1회 호출, 1센트 미만)
• selector가 모든 페이지에 대해 실행됩니다 (무료)
• 검증기(보통 regex 또는 존재 여부 확인)가 변화(drift)를 감지합니다
• 변화가 감지되면 몇 주 또는 몇 달 후에 재부트스트랩을 트리거합니다

페이지당 비용이 약 0.005달러에서 0.0001달러 미만으로 급감합니다. 결정론적 파싱은 환각을 일으키지 않으므로 품질이 향상됩니다. 그리고 이미 매핑한 구조를 흉내 내는 것이 아니라 새로운 구조를 읽는 것과 같이 LLM이 실제로 잘하는 작업에 token을 사용하게 됩니다.

그럼에도 LLM이 제값을 하는 경우

이 글은 LLM에 반대하는 글이 아닙니다. 수많은 추출 작업에서 모델이 적절한 도구이며 크레딧 계산이 합리적으로 작동합니다.

• 매주 변경되는 불안정한 레이아웃. 매주 화요일마다 깨지는 selector는 LLM 추출에 드는 token 비용보다 더 많은 엔지니어링 시간을 소모합니다. 모델을 실행하십시오.
• 두 번 다시 방문하지 않을 롱테일 대상. selector를 작성할 실익이 없습니다. 모델을 실행하십시오.
• 출력 자체가 요약인 비구조화된 콘텐츠. 채용 공고에서 기술 추출, 기사에서 주장 추출, 리뷰에서 감정 분석 등. selector는 도움이 되지 않습니다. 모델을 실행하십시오.
• 레이아웃 변형에 따라 선택적 필드가 분산되어 있는 페이지. 20개의 조건부 렌더링이 있는 단일 템플릿은 LLM이 regex 체인보다 확실히 우위에 있는 영역입니다.

파이프라인을 살펴보십시오. 대상을 처리량 기준으로 정렬해 보십시오. 요청 수 기준 상위 20%는 거의 항상 안정적인 구조를 가지고 있습니다 (이것이 상위 20%인 이유이기도 합니다. 의도적으로 통합했기 때문입니다). 이들은 selector 후보입니다. 롱테일 영역이야말로 모델이 활약할 곳입니다.

이것이 여러분의 스택에 의미하는 바

2026년의 벤더 광고는 여러분이 LLM 추출을 기본값으로 사용하도록 유도합니다. 크레딧 요금제는 소규모 프로젝트에서는 합리적으로 보입니다. 하지만 규모를 확장하면 더 이상 합리적이지 않게 됩니다. 이는 근본적인 신호가 깨진 후 proxy pool 크기가 실제 성공을 예측하지 못하게 된 것과 마찬가지입니다.

실제 파이프라인을 구축하는 팀을 위한 세 가지 시사점은 다음과 같습니다.

1. 가져오기(fetch)와 파싱(parse)을 분리하십시오. 스크래핑 벤더가 LLM으로 추출된 JSON만 반환한다면, 청구서가 도착했을 때 selector로 대체할 수 없습니다. HTML을 전달하여 추출 경로를 직접 선택할 수 있는 인프라를 선택하십시오.
2. selector 수준에서 적극적으로 캐싱하십시오. 생성된 selector는 수천 개의 페이지에서 재사용할 수 있습니다. 비용이 많이 드는 호출은 사용이 아니라 생성 단계입니다.
3. 페이지당 비용이 아닌 레코드당 비용을 측정하십시오. 페이지당 0.001달러가 들지만 5%의 잘못된 레코드를 전송하는 파이프라인은, 페이지당 0.005달러가 들지만 깨끗한 데이터를 전송하는 파이프라인보다 더 많은 비용이 듭니다. 스토리지, 다운스트림 쿼리, 그리고 결국 수행해야 하는 정리 작업 모두가 비용 부담으로 작용합니다.

지루한 쪽을 선택하십시오

LLM 추출 기본값은 데모에는 적합하지만 프로덕션에는 적합하지 않은 형태입니다. 이를 올바르게 활용하는 팀들은 LLM을 페이지를 읽는 도구가 아니라 페이지를 이해하는 도구로 취급하는 팀들입니다. 2026년에도 지루한 결정론적 코드가 처리량 싸움에서 여전히 승리하며, 모델은 새로움과의 싸움에서 승리합니다. 두 가지 모두 스택에 필요합니다.

FourA에서는 Single 및 Browser가 raw response(HTML, 렌더링된 DOM, headers, body)를 반환하고 거기서 멈춥니다. selector로 파싱할지, 모델로 보낼지, 아니면 둘 다 할지는 여러분의 선택입니다. 저희는 저희가 수행하지 않은 추출 작업에 대해 크레딧 배수를 추가로 청구하지 않습니다.