trafilatura ließ auf denselben Testseiten weniger markierte Boilerplate durch als Readability

trafilatura은 브라우저 없이 돌아가는 Python 기반 콘텐츠 추출 도구입니다. 이 글에서 표시한 테스트 케이스 기준으로, 같은 HTML에서 trafilatura와 비슷한 수준의 추출 품질을 보여준 건 Mozilla Readability뿐이었습니다. trafilatura는 17개의 주석 처리된 boilerplate 단위 중 1개만 놓쳤고, Readability는 5개를 놓쳤습니다. 브라우저 기반 도구들은 여기서 품질이 아니라 배포 규모라는 맥락에서만 언급됐고, 이 페이지들에서는 품질 테스트를 따로 하지 않았습니다.

핵심 역할은 본문 추출입니다. HTML을 넣으면 기사 중심의 텍스트와 메타데이터를 뽑아내고, 주변 페이지 요소는 휴리스틱으로 걸러냅니다. 출력은 JSON과 다른 형식들로 직렬화할 수 있지만, 사용자가 자유롭게 정의하는 표 스키마나 반복되는 타입화된 레코드는 만들어주지 않습니다. 테스트한 버전은 2.1.0이며, JavaScript는 실행하지 않습니다. Readability와의 비교는 전반적인 승패라기보다 정밀도와 완전성 사이의 트레이드오프를 보여줍니다.

Wo trafilatura passt – und was es bewusst nicht tut

trafilatura는 웹에서 텍스트와 메타데이터를 모으는 Python 및 CLI 도구라고 설명합니다. Crawling, Scraping, Extraktion을 지원하고, CSV, JSON, HTML, Markdown, TXT, XML로 출력할 수 있습니다. 처음 보면 꽤 넓어 보이지만, 실제로 중요한 범위는 훨씬 더 좁고 분명합니다. 이 도구는 HTML 문서를 받아서 그 주변 구조를 걷어낸 뒤 Hauptinhalt만 돌려줍니다.

이 방식은 강점과 한계를 동시에 설명해줍니다. 보통 페이지에 적용하는 scraper는 selector 기반으로 움직입니다. 예를 들어 “product-price 클래스를 가진 요소를 가져와”라고 지시하면 그 위치의 값을 돌려줍니다. trafilatura는 반대로 작동합니다. 문서 전체를 읽고 나서 어떤 블록이 실제 기사인지, 어떤 부분이 boilerplate인지 스스로 판단합니다. 사용자가 쓴 selector가 아니라 콘텐츠 휴리스틱을 쓰는 방식입니다. 그래서 페이지별 규칙 없이도 정리된 결과를 얻을 수 있습니다. 하지만 그만큼 구조화된 카탈로그를 바로 주지는 못합니다. 스키마도 없고, 타입이 정해진 행도 없습니다. 그냥 “여기에 관련 텍스트가 있다”는 식입니다. 즉, 정밀하게 지시하는 parser가 아니라 extractor입니다.

별도의 브라우저 런타임을 내려받을 필요도 없습니다. 다만 의존성 트리에는 lxml 같은 플랫폼 wheel이 포함됩니다. 그래서 “브라우저 다운로드가 없다”는 말은 source-only나 완전 네이티브 설치와는 다르다는 점을 함께 봐야 합니다.

Einrichtung: kleine Abhängigkeitsmenge, keine Browser-Installation

새 가상환경의 Python 3.14에서 pip install trafilatura를 실행하니 17개 패키지가 설치됐고, 가장 큰 wheel은 lxml의 8.6 MB였습니다. 자세한 내용은 pip-install-trafilatura.log에 있습니다. 별도의 브라우저 설치나 설치 후 브라우저 실행 단계는 필요하지 않았습니다.

비교해보면, 같은 연구 기반에서 Scrapling 패키지는 fetcher가 동작할 때까지 pip를 네 번 따로 돌려야 했고, 총 26개 패키지가 설치됐습니다. 그중 두 개는 42.2 MB짜리 Playwright driver wheel이었습니다 (tools/scrapling/artifacts/logs/pip-install-scrapling.log). 이건 브라우저 binary 다운로드 전 이야기입니다. Crawlee 패키지에서는 Chromium 다운로드만 약 81.7 MiB였습니다 (tools/crawlee/research-materials.md). 이런 도구들은 더 많은 일을 하기 때문에 공정한 기능 비교는 아니지만, 적어도 디스크와 CI cache에 어떤 부담이 오는지는 보여줍니다. 그리고 pip가 내려준 버전이 2.1.0이라 현재 release와 같기 때문에, 아래 수치들은 “오래된 버전을 테스트했다”는 예외 없이 봐도 됩니다.

Praxis: Was der Extraktor tatsächlich zurückgegeben hat

이 도구를 장점과 한계가 모두 드러나도록 설계한 테스트 케이스에 돌려봤고, 원본 데이터는 Benchmark-Repo에 있습니다. 그중 기사 테스트가 가장 인상적이었습니다.

로컬 기사 테스트 케이스에 로그인 안내, “Subscribe” 문구, 내비게이션 링크, copyright footer 같은 잡음을 잔뜩 넣었습니다. 보통 이런 boilerplate는 naive scraper가 본문과 함께 주워 담기 쉽습니다. 그런데 trafilatura는 제목과 3개의 본문 단락 전체를 반환했고, login, subscribe, copyright 같은 boilerplate 표시는 전부 사라졌습니다. 게다가 author와 date도 페이지 메타데이터에서 정확히 가져왔습니다. .txt, .md, .json 전체 결과는 results/local_article.json에 있습니다.

같은 HTML을 plain text, Markdown, JSON으로 내보냈습니다. 다만 이것이 세 형식이 하나의 단일 동시 호출에서 나온다는 뜻은 아닙니다. 같은 extraction 경로의 대체 serialisation일 뿐입니다. JSON은 여기서 추출된 텍스트와 메타데이터를 묶는 용도이지, 자유롭게 정의된 반복 레코드를 만드는 방식은 아닙니다.

아래는 첫 번째 실행 결과를 한눈에 볼 수 있게 정리한 것입니다. 직접 확인할 수 있도록 그대로 둡니다.

각 행은 trafilatura 패키지의 artifacts/raw/trafilatura-test-summary.json에서 나온 것입니다. trafilatura 2.1.0, Python 3.14, macOS arm64, 단일 머신 실행 기준입니다. 시간은 벤치마크 값이 아니라 관찰값으로 봐야 합니다.

500 테스트 케이스에서는 인접한 로컬 엔드포인트가 빠르게 응답했는데도, fetch_url이 약 30초 후에 None을 돌려줬습니다. 이 실행은 지연만 보여줄 뿐, retry/backoff인지, 고정 timeout인지, 다른 내부 경로인지까지는 알려주지 않습니다. 이 글에서는 fetch_url에 대한 호출별 timeout 파라미터를 따로 검증하지 않았습니다. 확인된 제어 방법은 직접 관리하는 client로 가져온 뒤 결과 HTML을 trafilatura에 넘기는 방식입니다.

같은 테스트는 세 가지 한계도 보여줍니다.

첫째, 가장 중요하게: trafilatura는 content extractor이지, 구조화된 scraper가 아닙니다. 제품 카탈로그 테스트에 적용해보니, 12개 제품명은 텍스트로 모두 나왔지만 구조화된 행은 정확히 0개였습니다(results/local_catalog_extraction.txt 기준 478자 plain text). 가격도 $18.00부터 $51.00까지 각각 이름 아래 한 줄씩 함께 나왔습니다. 원하는 정보는 출력 안에 있지만, 필드 형태는 아닙니다. [{name, price, rating}, …] 같은 결과가 필요하다면 이건 맞는 도구가 아니고, 설정을 바꿔도 달라지지 않습니다. 설계 자체가 그렇기 때문이지, 버그가 아닙니다.

둘째, JavaScript를 렌더링하지 않습니다. 이 도구는 정적 HTML만 처리합니다. client-side rendering이 필요한 페이지에 쓰면, 서버가 JS 실행 전에 보낸 내용만 받게 되며, 그게 보통은 쓸모없을 수 있습니다. 목표 사이트가 JS 의존도가 높다면 renderer와 함께 써야 하고, 그 부분은 trafilatura가 맡지 않습니다.

셋째는 제 증거에 관한 제한입니다. 첫 번째 공개 추출 테스트는 실제 뉴스 기사 대신 제품 설명 텍스트를 사용했습니다. 공개 sandbox 환경에는 뉴스 사이트가 없었기 때문입니다. 위의 기사 정리 결과는 통제된 로컬 테스트 케이스에서 나온 것입니다. boilerplate 제거가 분명하게 드러나므로 결과 자체는 신뢰할 만하다고 봅니다. 다만 제품 페이지를 newsroom 수준의 추출 증거로 내세우고 싶지는 않았습니다. 그래서 그 공백은 그대로 남겨뒀고, 2026-07-14의 후속 실행에서 그 부분을 채웠습니다. 결과는 다음 섹션에 있습니다.

Plausibilitätscheck auf echten Seiten

실제 페이지 두 개를 한 번 가져와 오프라인 테스트 케이스로 SHA-256 해시와 함께 저장한 뒤, 네트워크 없이 다시 실행했습니다. 시간값이나 라벨이 붙은 ground truth 데이터는 따로 수집하지 않았습니다. 여기서는 실제 페이지에서 boilerplate를 얼마나 잘 걷어내는지 보는 plausibility check이고, 정확도 점수는 아닙니다.

두 행 모두 artifacts/results/trafilatura-fidelity-summary.json에서 왔습니다. 검사한 마커는 “Jump to content”, “Privacy policy”, “Powered by MediaWiki”, “This page was last edited”였고, Wikinews 페이지에서는 추가로 “free news source”도 포함됐습니다. 두 페이지 모두에서 전부 제거됐고, 하나도 새지 않았습니다.

Body/raw 비율은 내용의 정확도가 아니라 축소 정도를 나타냅니다. 빠진 기사 내용이 따로 평가되지는 않았습니다. author와 sitename은 이 두 MediaWiki 템플릿에서는 모두 null이었고, 반면 통제된 로컬 테스트 케이스에서는 author가 나왔습니다. 이는 테스트에서 관찰된 MediaWiki 특유의 누락이지, byline 전반의 신뢰성을 뜻하는 것은 아닙니다. 추출된 데이터는 나온 그대로 표시됐고, ground truth와 대조되지는 않았습니다.

Zwei Extraktoren, dieselben HTML-Bytes, ein Scoring-Skript

이 연구 기반에서는 trafilatura를 같은 테스트 베드에서 비교한 사례가 딱 하나이고, 그 비교를 만든 것도 trafilatura 패키지가 아니었습니다. 대조군은 mozilla-readability 패키지였습니다. 22개의 수작업 라벨 테스트 케이스에서 각 텍스트 블록은 ARTICLE 또는 BOILERPLATE로 표시됐고, 각 단어에는 고유한 sentinel token이 붙어서 추출된 단어를 정확히 어떤 라벨 블록에서 왔는지 추적할 수 있었습니다. 두 도구는 동일한 HTML 바이트를 받았습니다. Readability는 Node v22.22.3에서 jsdom 29.1.1로 실행됐고, trafilatura는 자체 parser를 사용했습니다.

출처는 이 연구 기반의 tools/mozilla-readability/artifacts/raw/comparison.json입니다. Content-Fidelity-Set에는 11개 테스트 케이스가 있고, 40개 Article Units와 17개 Boilerplate Units가 포함됩니다. 이건 adversarial한 경우에 일부러 무게를 둔 synthetic fixture이므로, 실제 코퍼스의 순위표라기보다 메커니즘을 보는 자료로 읽어야 합니다.

두 도구 모두 모든 걸 제거하지는 못했고, 바로 그 차이가 흥미롭습니다. trafilatura는 페이지 장식 요소를 더 잘 막아냅니다. Readability의 5개 대비 1개만 새어 나왔고, 오염시키는 token도 41개 대비 3개였습니다. 이것이 바로 “깨끗한 기사 텍스트”의 정밀도 측면이고, LLM context window를 sidebar link로 채울지 말지를 가르는 지점입니다. 반대로 Readability는 trafilatura가 지우는 내용을 더 많이 살립니다. Non-prose 테스트에서는 trafilatura가 <figcaption> 하나를 놓쳤지만 Readability는 유지했고, 아주 짧은 기사에서는 0.571 대 0.800이었습니다. 강한 정리는 공짜가 아닙니다. 짧은 글, 캡션, 표 위주의 페이지가 많은 코퍼스라면 그 trade-off가 오히려 불리하게 작동할 수 있습니다.

Wie man den Vergleich in einen Auswahltest übersetzt

먼저 파이프라인에서 어떤 오류가 더 비싼지 정하세요. 페이지 요소가 downstream token을 잡아먹거나 검색 결과를 더럽힌다면, boilerplate leakage와 오염 token에 더 높은 가중치를 둬야 합니다. 반대로 이미지 캡션, 짧은 글, non-prose 블록을 잃는 게 치명적이라면, 페이지 유형별 content recall을 더 중요하게 봐야 합니다. 이 공용 fixture set은 그 트레이드오프를 드러내주지만, 뉴스 아카이브나 문서 코퍼스, retrieval pipeline에 맞는 가중치까지 정해주지는 않습니다.

더 넓은 부하 테스트 맥락은 메모리 사용량과 잘못된 HTML에 대한 10개 라이브러리 비교에 있습니다.

직접 비교할 때는 live URL 대신 저장된 HTML 파일을 사용해야 합니다. 그래야 두 extractor가 완전히 같은 바이트를 받습니다. 일반적인 긴 기사, 짧은 안내문, 캡션이 많은 글, 표나 코드 블록이 많은 문서, 그리고 실제로 읽을 퍼블리셔 템플릿들을 포함시키세요. 실행 전에 필수 콘텐츠 단위와 알려진 boilerplate 블록을 소수만 라벨링해두면 좋습니다. 그다음에는 빈 출력, 필수 단위 복원, 원치 않는 단위 통과, 메타데이터 필드를 각각 따로 평가하세요. 하나의 통합 “quality” 점수만 보면 운영에서 중요한 오류 유형이 가려질 수 있습니다.

다운스트림에서 출력 계약도 검증해야 합니다. trafilatura의 JSON은 추출된 콘텐츠와 메타데이터를 담을 수 있지만, JSON 직렬화는 타입이 정해진 행 스키마와 다릅니다. 기사 텍스트는 아무 비어 있지 않은 출력도 통과시키지 말고, 본문 최소 길이와 필요한 marker를 확인하세요. 메타데이터는 누락값과 잘못된 값을 구분하고, source URL과 extraction version을 함께 보관해야 나중에 오류를 재현할 수 있습니다.

fetch 단계는 별도의 계층으로 테스트해야 합니다. 로컬 오류에서 관찰된 30초 응답 지연은 이미 존재하는 HTML을 추출하는 단계가 아니라 fetch_url에 해당합니다. 내부 메커니즘은 확인되지 않았습니다. 데드라인, retries, 인증, proxy 정책이 중요하다면, 동작을 직접 제어할 수 있는 client를 쓰고, 최종 response bytes를 기록한 뒤 그 bytes를 extractor에 넘기세요. 그래야 fetch 오류와 content selection 오류를 분리할 수 있고, 비교도 재현 가능해집니다.

마지막으로 배포 특성도 대상 플랫폼에서 측정하세요. Python 3.14에서 17개 패키지 설치에 별도 브라우저는 필요 없었지만, 그 사실만으로 처리량, 메모리 증가, 모든 아키텍처에서의 wheel 가용성, 병렬 worker에서의 동작까지 알 수는 없습니다. 이 글은 Readability 대비 유용한 precision/completeness 메커니즘을 보여주지만, 실제 운영 적합성은 여전히 코퍼스와 런타임 테스트에 달려 있습니다.

이 연구 기반 밖의 외부 확인으로는, trafilatura 자체 평가 페이지와 공개 ScrapingHub article-extraction-benchmark 모두에서 trafilatura가 180여 개 실제 페이지에서 word-F1 기준으로 readability-lxml보다 앞서는 결과를 보여줍니다. 위 표와 같은 방향입니다. 다만 많은 소개글이 놓치는 점 하나가 있습니다. 자주 인용되는 trafilatura F1 값(약 0.945)은 여기서 테스트한 2.1.0이 아니라 더 이전의 0.5.1 계열을 가리킨다는 점입니다.

Vor- und Nachteile

Vorteile:

• 공동 fixture set에서 Readability보다 훨씬 적은 boilerplate leakage: 17개 중 1개, Readability는 5개.
• 로컬 테스트에서 author와 date를 정확히 추출했고, 두 실제 기사 페이지에서는 title, date, hostname이 정확했습니다.
• 같은 HTML 콘텐츠를 text, Markdown, JSON으로 serialise할 수 있습니다.
• 별도 브라우저 스택 없이 17개 패키지만 설치하면 됩니다.
• 오류가 조용하게 처리됩니다. HTTP 500에서는 fetch_url이 예외 대신 None을 반환합니다.
• 테스트한 버전이 최신 버전인 2.1.0이라 버전 차이 걱정이 없습니다.
• Apache-2.0 라이선스로, 상업적으로도 비교적 자유롭게 사용할 수 있습니다.

Nachteile:

• 구조화된 scraper가 아닙니다. 카탈로그 테스트에서 12개 이름과 12개 가격은 텍스트로 나왔지만, 타입화된 행은 0개였습니다. 스키마나 필드가 없습니다.
• JavaScript 렌더링을 하지 않습니다. 정적 HTML만 다루므로 client-side 페이지에는 별도 renderer가 필요합니다.
• 두 실제 MediaWiki 페이지에서 author와 sitename은 null이었습니다. byline 추출이 항상 되는 건 아닙니다.
• 강한 정리는 대가가 있습니다. Readability가 유지한 <figcaption>을 지웠고, 아주 짧은 기사에서는 0.571로 Readability의 0.800보다 낮았습니다.
• 조용한 500 응답은 None을 돌려주기까지 30.012초가 걸렸습니다. deadline 제어가 중요하면 직접 제어하는 fetcher를 써야 합니다.
• 내장 crawl/sitemap spider와 CSV/XML 출력 형식은 이번 실행에서 테스트하지 않았습니다. 이에 대해서는 판단하지 않습니다.

Für wen es gedacht ist — und wer es besser lässt

trafilatura는 기사형 콘텐츠에서 본문을 뽑아내는 데 맞춰져 있습니다. 정적 HTML에서 텍스트 코퍼스, 읽기 쉬운 아카이브, NLP 입력을 만들고 싶고, 휴리스틱 기반 정리를 받아들일 수 있다면 잘 맞습니다. 공동 fixture 비교에서도 Readability보다 boilerplate leakage가 적었습니다. 반면 Readability는 짧고 비산문적인 사례를 더 많이 살렸습니다.

반대로 구조화 추출이 필요하다면, 즉 가격이 있는 제품 행이나 타입화된 레코드, key: value 필드가 필요하다면 이 도구는 맞지 않습니다. 텍스트는 주지만 표는 주지 않기 때문입니다(카탈로그 테스트에서 12개 이름과 12개 가격은 얻었지만 0행이었습니다). 목표 페이지가 브라우저에서만 내용을 렌더링하고, 별도 renderer를 붙일 생각이 없다면 이것도 피하세요. trafilatura는 정적 HTML만 읽고 거기서 끝납니다. 또 코퍼스가 짧은 스니펫, 캡션, 표 중심 페이지 위주라면 한 번 더 생각해보세요. 그 영역에서는 정리가 실제 콘텐츠를 잘라내기 때문입니다(아주 짧은 기사에서 0.571 F1, 삭제된 <figcaption>). 즉, 도구는 작업에 맞아야 합니다. 완전한 기사 본문에는 좋지만, 구조화된 JSON, JS 페이지, 100단어짜리 스니펫에는 다른 선택지가 낫습니다.

Alternativen, einschließlich der Einordnung von Thunderbit

trafilatura는 사용량 기반 공급자 요금이 없는 self-hosted Apache-2.0 라이브러리입니다. 계산 자원, 대역폭, fetch, monitoring, maintenance는 모두 운영 비용으로 남습니다. 이 도구는 전달된 HTML에서 article-oriented extraction을 처리하지만, browser execution이나 사용자 정의 반복 행 스키마는 다루지 않습니다.

같은 fixture를 여섯 개 extractor 전체로 비교한 내용은 six extraction libraries compared에서 볼 수 있습니다.

관리형 서비스는 fetch, rendering, schema shaping을 공급자 경계 뒤로 넘길 수 있습니다. 우리는 Thunderbit를 만들고 있지만, 이 fixture들에 대해 직접 돌려보지는 않았기 때문에 이 글에서는 품질, rendering, latency, anti-bot, 비용에 대한 판단을 하지 않습니다. 결국 선택지는 self-hosted HTML-to-content 제어냐, 아니면 호스팅된 fetch 및 구조화 추출 경계냐의 문제입니다.

관련 벤치마크 분석으로는 open-source scraper 전체 비교, Crawl4AI의 browser-based Markdown 분석, Firecrawl의 self-hosted Markdown 분석이 있습니다.

Thunderbit로 웹 데이터 추출해보기

Fazit

trafilatura는 정적 HTML에서 기사형 콘텐츠를 뽑아내는 작업에 잘 맞고, 라벨된 boilerplate를 안정적으로 걷어내는 게 중요할 때 특히 좋습니다. 공동 fixture에서는 Readability보다 주석 처리된 boilerplate 단위를 1개만 통과시켰습니다. 다만 이 장점은 아주 짧거나 비산문적인 fixture에서 완전성이 떨어지는 대가를 동반했습니다. 그래서 코퍼스 구조가 선택을 좌우해야 합니다.

JavaScript를 실행하지 않고, 자유롭게 정의한 반복 행도 만들지 않습니다. 두 MediaWiki 페이지에서는 author와 sitename이 null이었습니다. 이건 해당 템플릿에서 관찰된 결과입니다. Readability는 trafilatura가 지운 캡션을 남겼고, fixture f3_short_120에서는 더 높은 점수를 받았습니다. 따라서 눈에 보이는 증거는 “아주 짧은 fixture에서 F1이 더 낮다”는 점을 뒷받침할 뿐, 문자 수나 출력이 쓸모없었다는 주장까지는 뒷받침하지 않습니다.

Thunderbit로 웹 데이터 추출해보기 Get Started Free

FAQs

trafilatura는 어떤 구조를 반환하나요? 추출된 콘텐츠와 메타데이터를 JSON, Markdown, Text, HTML, XML, CSV로 직렬화할 수 있습니다. 하지만 이것은 구조화된 직렬화일 뿐이고, 제품명·가격·평점처럼 자유롭게 정의한 반복 행 스키마는 아닙니다. 카탈로그 테스트에서는 값이 플레인 텍스트로 나왔지, 타입화된 행으로 나오지 않았습니다.

trafilatura로 제품 카탈로그를 구조화된 행으로 스크랩할 수 있나요? 아니요. 콘텐츠 추출기이지 구조화 scraper가 아닙니다. 카탈로그 테스트에서는 12개 제품명이 모두 플레인 텍스트로 나왔고, 구조화된 행은 0개였습니다. 이름은 출력 안에 들어 있지만 필드는 아닙니다. Name/Price/Rating 같은 타입화된 레코드가 필요하면 selector 기반 parser나 schema-oriented extraction API를 쓰세요.

trafilatura는 JavaScript를 렌더링하나요? 아니요. 정적 HTML만 처리합니다. client-rendered 페이지를 넣으면 JavaScript 실행 전에 서버가 보낸 내용만 받게 되고, 그게 원하는 콘텐츠가 아닌 경우가 많습니다. JS 의존도가 높다면 별도 renderer와 함께 써야 합니다.

trafilatura 설치가 어렵나요? 테스트한 Python 3.14 가상환경에서는 17개 패키지만 설치됐고, 별도 브라우저 스택은 필요하지 않았습니다. 가장 큰 wheel은 lxml 8.6 MB였습니다. 다만 로컬 500 호출은 None을 돌려주기까지 30.012초가 걸렸으니, deadline이 중요하면 직접 제어하는 HTTP client를 쓰는 게 좋습니다.

trafilatura는 상업적으로 무료인가요? 네. Apache-2.0 라이선스라 비교적 자유롭게 상업적으로 사용할 수 있습니다. 다만 실제로 도입하기 전에는 항상 repo에서 최신 라이선스를 다시 확인하세요.