trafilatura, Readability보다 불필요한 보일러플레이트를 더 적게 남겼다

trafilatura는 브라우저 없이 돌아가는 Python 콘텐츠 추출기다. 이 글에서 쓴 라벨링된 테스트 샘플 기준으로 보면, 같은 HTML 추출 품질을 놓고 겨뤄볼 만한 경쟁자는 Mozilla Readability 정도뿐이다. trafilatura는 17개의 주석 처리된 boilerplate 단위 중 1개를 놓쳤고, Readability는 5개를 남겼다. 브라우저 기반 도구들은 배포 환경의 무게감 비교에서만 언급했고, 이 페이지들에서는 품질 테스트를 따로 돌리지 않았다.

이 도구의 핵심 역할은 본문 추출이다. HTML을 넣으면 기사 중심의 텍스트와 메타데이터를 뽑아내고, 페이지 주변 요소는 규칙 기반 휴리스틱으로 걸러낸다. JSON 같은 여러 형식으로 결과를 내보낼 수는 있지만, 사용자가 정의한 행 구조나 반복되는 타입화된 카탈로그 레코드를 만들어 주지는 않는다. 테스트한 버전은 2.1.0이었고, JavaScript는 실행하지 않는다. 또 Readability와의 비교 결과는 범용 완승이라기보다, 정밀도와 보존율 사이의 trade-off에 가깝다.

trafilatura가 적합한 영역, 그리고 하지 않는 일

trafilatura는 웹에서 텍스트와 메타데이터를 수집하는 Python 및 명령줄 도구라고 설명한다. 크롤링, 스크래핑, 추출까지 폭넓게 내세우며, CSV, JSON, HTML, Markdown, TXT, XML로 출력할 수 있다. 설명만 보면 범위가 꽤 넓다. 하지만 실제로 이 도구가 맡는 일은 더 좁고 분명하다. HTML 문서를 받아서 주변 장식을 걷어낸 주요 콘텐츠를 돌려주는 것이다.

이 도구를 이해하려면 이 그림처럼 생각하면 된다. 강점과 한계가 동시에 보이기 때문이다. 보통 페이지에 붙이는 스크래퍼는 selector 기반이다. 예를 들어 “product-price 클래스를 가진 요소를 가져와”라고 지정하면, 그 위치의 값을 그대로 가져온다. 반면 trafilatura는 반대로 움직인다. 문서 전체를 읽고, 사용자가 쓴 selector 대신 콘텐츠 휴리스틱을 바탕으로 어떤 블록이 진짜 기사 본문인지, 어떤 블록이 boilerplate인지 판단한다. 그래서 사이트마다 따로 규칙을 만들 필요가 없다. 하지만 바로 그 이유 때문에 구조화된 카탈로그를 손에 쥐여 줄 수는 없다. 스키마도 없고, 타입화된 행도 없다. 그냥 “의미 있는 텍스트는 여기 있다”가 전부다. 즉, 지정하는 파서가 아니라 추출기다.

또한 별도로 내려받는 브라우저 런타임도 필요하지 않다. 의존성 트리에는 lxml 같은 플랫폼 wheel이 들어 있으므로, “브라우저를 따로 설치하지 않는다”는 말은 소스만으로 설치된다거나 네이티브 코드가 전혀 없다는 뜻으로 받아들이면 안 된다.

설치: 의존성은 가볍고, 브라우저 설치는 없음

Python 3.14의 새 virtualenv에서 pip install trafilatura를 실행하니 17개 패키지가 설치됐다. 기록된 가장 큰 wheel은 pip-install-trafilatura.log 기준으로 lxml 8.6 MB였다. 별도의 브라우저 설치나 설치 후 브라우저 명령은 필요하지 않았다.

규모를 비교해 보면, 같은 연구 베이스의 Scrapling pack은 fetcher를 돌리는 데만 pip를 4번 따로 실행해야 했고, 최종적으로 26개 패키지를 설치했으며 그중 2개는 42.2 MB짜리 Playwright driver wheel이었다(tools/scrapling/artifacts/logs/pip-install-scrapling.log). 물론 이는 브라우저 바이너리를 내려받기 전 이야기다. Crawlee pack은 별도의 Chromium 다운로드만 약 81.7 MiB로 측정됐다(tools/crawlee/research-materials.md). 이런 도구들은 더 큰 일을 하니 기능 비교만으로는 공정한 승부가 아니다. 다만 디스크와 CI 캐시가 실제로 보는 모습은 이렇다. 그리고 pip가 설치한 버전이 2.1.0, 즉 최신 릴리스와 같았기 때문에 아래 수치들에 대해 “오래된 버전을 테스트했다”는 단서도 없다.

실전 테스트: 실제로 무엇을 반환했는가

이 도구가 가장 잘하는 상황과 가장 약한 상황을 모두 잡아내도록 만든 샘플에 적용했고, 원본 결과는 benchmark repo에 저장했다. 기사 테스트 결과가 특히 인상적이었다.

로컬 기사 샘플 하나를 가져와 실제 본문 주변에 잡음들을 둘러쌌다. 로그인 안내, “Subscribe” 유도 문구, 탐색 링크, 저작권 푸터 등 흔한 boilerplate를 섞어 넣은 것이다. naive scraper라면 본문과 함께 몽땅 가져올 요소들이다. trafilatura는 제목과 본문 3개 문단 전부를 반환했고, Login, Subscribe, Copyright 같은 boilerplate 표시는 출력에서 전부 사라졌다. 텍스트뿐 아니라 페이지 메타데이터에서 author와 date도 정확히 추출했다. .txt, .md, .json 전체 결과는 results/local_article.json에 있다.

같은 저장된 HTML은 일반 텍스트, Markdown, JSON으로 각각 내보냈다. 다만 이 글이 세 형식이 하나의 동시 호출에서 나왔다고 말하는 건 아니다. 이는 추출 경로의 대체 직렬화 방식들이다. 여기서 JSON은 추출된 텍스트와 메타데이터를 담을 뿐, 사용자가 정의한 반복 레코드를 만들지는 않는다.

아래는 첫 번째 실행 결과를 한눈에 볼 수 있게 정리한 표다. 직접 확인해 보자.

각 행은 trafilatura pack의 artifacts/raw/trafilatura-test-summary.json에서 가져왔다. trafilatura 2.1.0, Python 3.14, macOS arm64 환경에서 한 번, 한 대의 머신으로 실행한 결과다. 시간은 벤치마크라기보다 관찰값으로 보는 편이 맞다.

500 샘플에서는 가까운 로컬 엔드포인트들이 빠르게 응답했는데도 fetch_url이 약 30초 뒤에 None을 반환했다. 이 실행은 지연이 있었다는 사실만 보여 줄 뿐, 재시도/백오프 때문인지, 고정 타임아웃 때문인지, 아니면 다른 내부 경로 때문인지는 밝히지 못한다. 이 글에서는 fetch_url에 대해 호출 단위 타임아웃 파라미터가 지원되는지도 검증하지 않았다. 입증된 제어 방법은 호출자가 직접 제어하는 클라이언트로 가져온 뒤, 그 HTML을 trafilatura에 넘기는 방식이다.

같은 테스트는 세 가지 경계도 드러낸다.

첫째이자 가장 중요한 점: trafilatura는 구조화 스크래퍼가 아니라 콘텐츠 추출기다. 제품 카탈로그 샘플에 적용해 봤더니 12개 제품명을 텍스트로는 전부 반환했지만 구조화된 행은 정확히 0개였다(results/local_catalog_extraction.txt 기준 478자의 평문). 가격도 함께 나왔고, 각 제품명 아래 줄에 $18.00부터 $51.00까지 정리되어 있었다. 원하는 정보는 출력 안에 들어 있긴 하지만, 필드 형태는 아니다. [{name, price, rating}, …] 같은 구조가 필요하다면 이 도구는 맞지 않는다. 설정을 아무리 바꿔도 달라지지 않는다. 그건 버그가 아니라 설계다.

둘째: JavaScript를 렌더링하지 않는다. 정적 HTML만 읽는다. 클라이언트 렌더링 페이지를 넣으면, JS가 실행되기 전에 서버가 보낸 내용만 받게 되는데, 그게 종종 쓸모없는 내용일 수 있다. 대상 사이트가 JS 중심이라면 렌더러를 별도로 붙여야 한다. trafilatura가 그 절반을 대신해 주지는 않는다.

셋째는 내 증거 자체에 대한 주의사항이다. 첫 번째 공개 페이지 추출 테스트는 실제 뉴스 기사가 아니라 product-description 블록을 사용했다. 공개 샌드박스에는 뉴스 페이지가 없었기 때문이다. 위의 기사 정리 결과는 통제된 로컬 샘플에서 나온 것이다. boilerplate 제거는 분명했기 때문에 그 결과는 신뢰하지만, product 페이지를 뉴스룸급 추출의 증거처럼 포장하고 싶지는 않았다. 그래서 그 패키지에는 그 부분을 열린 공백으로 남겨두었다. 2026-07-14에 후속 실행을 진행해 이 공백을 메웠고, 결과는 다음 섹션에 있다.

실제 페이지 boilerplate 검증

실제 페이지 두 개를 한 번씩 가져와 SHA-256 해시가 붙은 오프라인 샘플로 저장한 뒤, 네트워크 없이 다시 실행했다. 시간이나 라벨이 있는 정답 데이터는 기록하지 않았다. 이것은 fidelity 점수가 아니라, 실제 페이지에서 boilerplate가 잘 빠지는지 확인하는 sanity check다.

두 행 모두 artifacts/results/trafilatura-fidelity-summary.json에서 가져왔다. 확인한 마커는 Wikipedia의 경우 “Jump to content”, “Privacy policy”, “Powered by MediaWiki”, “This page was last edited”였고, Wikinews 페이지에는 “free news source”도 포함했다. 두 페이지 모두에서 전부 제거되었고 누출은 없었다.

본문/원본 비율은 정확도가 아니라 감소율을 나타낸다. 누락된 기사 내용은 채점하지 않았다. 두 MediaWiki 템플릿에서는 author와 sitename이 null이었고, 반면 통제된 로컬 샘플에는 author가 있었다. 이는 테스트에서 관찰된 MediaWiki 특화 누락이지, 일반적인 byline 신뢰성을 증명하는 것은 아니다. 추출된 date는 반환된 그대로 보고했으며, 정답과 대조해 검증하지는 않았다.

같은 HTML 바이트, 두 추출기, 하나의 스코어링 스크립트

이 연구 베이스에서 trafilatura를 놓고 같은 테스트베드 비교를 한 사례는 딱 하나뿐인데, trafilatura 자신의 pack이 아니라 mozilla-readability pack이 그 역할을 했다. 이것은 control arm으로 구성된 22개의 수작업 라벨 샘플이다. 각 텍스트 블록은 ARTICLE 또는 BOILERPLATE로 태그되어 있고, 각 단어에는 고유한 sentinel 토큰이 붙어 있어서 추출된 단어가 정확히 하나의 라벨 블록으로 되돌아갈 수 있다. 두 도구는 완전히 동일한 HTML 바이트를 받았다. Readability는 jsdom 29.1.1과 Node v22.22.3에서 실행됐고, trafilatura는 자체 파서를 사용했다.

출처: 이 연구 베이스의 tools/mozilla-readability/artifacts/raw/comparison.json — content-fidelity 세트의 11개 샘플, 40개 기사 단위, 17개 boilerplate 단위다. 이 샘플들은 adversarial case 쪽에 일부러 무게를 둔 합성 데이터이므로, 실제 코퍼스의 순위표라기보다 메커니즘을 보여 주는 자료로 읽는 게 맞다.

둘 다 완벽하진 않지만, 차이는 꽤 흥미롭다. trafilatura는 화면 장식 요소를 더 잘 걷어낸다. Readability의 5개 누출에 비해 1개 블록만 새어 나갔고, 오염된 토큰도 41개에 비해 3개뿐이었다. 이게 바로 “깔끔한 기사 텍스트”의 precision 측면이며, LLM 컨텍스트 윈도우가 사이드바 링크로 채워질지 여부를 가르는 부분이기도 하다. 하지만 Readability는 trafilatura가 버린 콘텐츠를 더 잘 살려낸다. 비서술형 샘플에서는 trafilatura가 <figcaption>을 떨어뜨렸지만 Readability는 유지했고, 매우 짧은 기사에서는 trafilatura가 0.571, Readability가 0.800이었다. 강한 정리는 공짜 승리가 아니다. 코퍼스가 짧은 단문, 캡션, 표 중심 페이지로 가득하다면 그 trade-off는 오히려 불리하게 작용할 수 있다.

이 비교를 선택 테스트로 바꾸는 방법

먼저 파이프라인에서 어떤 오류가 더 비싼지 정하자. 페이지 장식이 downstream 토큰을 잡아먹거나 검색 결과를 오염시킨다면, boilerplate 단위 누출과 오염 토큰 수에 더 큰 가중치를 둬야 한다. 반대로 캡션, 짧은 글, 비서술 블록을 놓치는 것이 허용되지 않는다면, 페이지 형태별 콘텐츠 recall에 더 큰 비중을 둬야 한다. 공유 샘플 세트는 이 trade-off를 보여 주지만, 뉴스룸 아카이브, 문서 코퍼스, 검색 파이프라인에 맞는 가중치까지 대신 정해 주지는 않는다.

더 넓은 스트레스 테스트 맥락은 10개 라이브러리의 메모리 및 malformed HTML 비교에 있다.

라이브 URL이 아니라 저장된 HTML로 비교를 구성해야 두 추출기가 완전히 동일한 바이트를 받는다. 일반적인 장문 기사, 짧은 공지, 캡션이 많은 글, 표나 코드가 많은 문서, 그리고 실제로 수집하는 각 퍼블리셔의 템플릿을 포함하자. 두 도구를 돌리기 전에 반드시 필요한 콘텐츠 단위와 알려진 boilerplate 블록을 소량 라벨링해 두는 것이 좋다. 그런 뒤 empty output, 필수 단위 복원, 불필요한 단위 누출, 메타데이터 필드를 각각 따로 점수화하라. 단일 aggregate “quality” 점수는 운영상 가장 중요한 실패 모드를 가릴 수 있다.

또한 downstream에서 출력 계약도 검증해야 한다. trafilatura의 JSON은 추출된 콘텐츠와 메타데이터를 담을 수 있지만, JSON 직렬화가 곧 타입화된 행 스키마와 같은 뜻은 아니다. 기사 텍스트의 경우에는 비어 있지 않은 출력이면 무조건 받아들이지 말고 최소 본문 길이와 필수 마커를 확인하자. 메타데이터는 누락과 잘못된 값을 구분하고, 소스 URL과 추출 버전을 함께 보관해 나중에 재현할 수 있게 하라.

가져오는 단계는 별도로 테스트해야 한다. 30초짜리 로컬 실패 관찰은 추출이 아니라 fetch_url에 대한 것이며, 내부 메커니즘은 확인되지 않았다. deadline, retry, authentication, proxy 정책이 중요하다면, 동작을 직접 제어할 수 있는 클라이언트를 쓰고 최종 응답 바이트를 기록한 뒤 그 바이트를 extractor에 넘겨라. 이렇게 해야 수집 실패와 콘텐츠 선택 실패를 분리할 수 있고, 비교도 반복 가능해진다.

마지막으로, 실제 배포 플랫폼에서 배포 특성을 측정하자. 17개 패키지의 Python 3.14 설치는 별도 브라우저를 요구하지 않았지만, 그렇다고 처리량, 메모리 증가, 모든 아키텍처에서의 wheel 가용성, 동시 워커에서의 동작까지 설명해 주는 것은 아니다. 이 글은 Readability와의 유용한 precision/retention 메커니즘을 보여 주지만, 프로덕션 적합성은 여전히 코퍼스와 런타임 테스트에 달려 있다.

이 연구 베이스 자체가 아닌 외부 교차 검증이 필요하다면, trafilatura의 공식 평가 페이지와 공개 ScrapingHub article-extraction-benchmark 모두 약 181개의 실제 페이지에서 word-F1 기준으로 readability-lxml보다 앞선다고 보고한다. 위 표와 같은 방향이다. 다만 그 벤치마크를 인용하는 많은 글이 빠뜨리는 주의사항이 하나 있다. 널리 알려진 trafilatura F1 약 0.945는 여기서 테스트한 2.1.0이 아니라 더 오래된 0.5.1 계열에 붙어 있다는 점이다.

장단점

장점:

• 공유 샘플 세트에서 Readability보다 라벨링된 boilerplate 누출이 적다: 17개 중 1개 대 5개.
• 로컬 샘플에서 author와 date를 정확히 가져왔고, 실제 기사 페이지 2개에서는 title/date/hostname을 잘 추출했다.
• 같은 HTML을 text, Markdown, JSON으로 직렬화할 수 있다.
• 17개 패키지 설치로 끝나며 별도 브라우저 런타임이 필요 없다.
• 실패가 조용하다: HTTP 500에서는 예외 대신 None을 반환한다.
• 테스트한 버전이 최신(2.1.0)이라 버전 차이 문제가 없다.
• Apache-2.0 라이선스로, 관대하고 상업적으로도 쓰기 좋다.

단점:

• 구조화 스크래퍼가 아니다: 카탈로그 테스트에서 12개 이름과 12개 가격을 텍스트로만 돌려줬고, 타입화된 행은 0개였다. 스키마도, 필드도 없다.
• JavaScript 렌더링을 하지 않는다. 정적 HTML만 다루므로 클라이언트 측 페이지에는 별도 렌더러가 필요하다.
• 두 실제 MediaWiki 페이지 모두에서 author와 sitename이 null이었다. byline 추출이 항상 보장되는 것은 아니다.
• 강한 정리는 대가가 있다. Readability가 유지한 <figcaption>을 떨어뜨렸고, 매우 짧은 기사에서는 Readability의 0.800에 비해 0.571을 기록했다.
• 조용한 500 응답이 None으로 돌아오기까지 30.012초가 걸렸다. deadline 제어가 중요하면 호출자가 제어하는 fetcher를 쓰는 편이 좋다.
• 내장 크롤러/sitemap spider와 CSV/XML 출력 형식은 이번 패스에서 다루지 않았으므로, 그것들에 대해서는 판단하지 않는다.

누구를 위한 도구이고, 누가 피해야 하나

trafilatura는 기사 중심의 본문 추출을 목표로 한다. 정적 HTML에서 텍스트 코퍼스, 읽기 쉬운 아카이브, NLP 입력을 만들 때 적합하며, 휴리스틱 기반 정리가 허용되는 경우에 후보가 된다. 공유 샘플 비교에서는 Readability보다 boilerplate 누출이 적었지만, Readability는 더 짧거나 비서술적인 경우를 더 많이 살렸다.

실제로 필요한 것이 구조화 추출이라면 이 도구를 피하자. 가격이 붙은 상품 행, 타입화된 레코드, key: value 필드가 필요하다면, trafilatura는 텍스트만 줄 뿐 표를 주지 않는다(카탈로그 테스트에서 12개 이름과 12개 가격은 복원했지만 행은 0개였다). 대상이 브라우저 안에서 렌더링되는 페이지이고 별도 렌더러를 붙일 생각이 없다면 역시 피하는 게 낫다. trafilatura는 정적 HTML을 읽고 거기서 멈추기 때문이다. 또 코퍼스가 짧은 단문, 이미지 캡션, 표가 많은 페이지 위주라면 두 번 생각해야 한다. 라벨링된 샘플에서 정확히 그 부분이 실제 콘텐츠를 잘라내는 지점이었기 때문이다(매우 짧은 기사에서 F1 0.571, <figcaption> 누락). 도구를 작업에 맞춰라: 전체 기사 텍스트에는 적합하지만, 구조화 JSON, JS 페이지, 100단어짜리 단문에는 다른 선택지가 낫다.

대안, 그리고 Thunderbit이 들어가는 위치

trafilatura는 Apache-2.0 라이선스의 자체 호스팅 라이브러리이며, 호출당 벤더 비용은 없다. 대신 연산, 대역폭, 수집, 모니터링, 유지보수 비용은 운영자가 부담한다. 공급된 HTML로 기사 중심 추출은 잘하지만, 브라우저 실행이나 사용자가 정의한 반복 행 스키마는 다루지 않는다.

모든 여섯 개 extractor를 같은 샘플로 비교한 결과는 여섯 라이브러리 추출 비교를 참고하라.

관리형 서비스는 acquisition, rendering, schema shaping을 벤더 경계 뒤로 숨길 수 있다. 우리는 Thunderbit을 만들지만, 이 샘플들로는 테스트하지 않았다. 따라서 이 글은 품질, 렌더링, latency, anti-bot, 비용 비교를 제공하지 않는다. 결국 선택은 self-hosted HTML-to-content 제어와 hosted acquisition/structured-extraction 경계 사이의 차이다.

관련 벤치마크 리뷰: 오픈소스 스크래퍼 전체 비교, Crawl4AI의 브라우저 기반 Markdown 리뷰, Firecrawl의 self-hosted Markdown 리뷰.

웹 데이터 추출을 위해 Thunderbit 사용해 보기

결론

정적 HTML에서 기사 중심 추출이 필요하고, 라벨링된 boilerplate를 최대한 잘 거르는 게 우선이라면 trafilatura를 고려할 만하다. 공유 샘플에서는 Readability의 5개에 비해 주석 처리된 boilerplate 단위 1개만 새어 나갔다. 다만 매우 짧은 기사와 비서술형 샘플에서는 보존율이 낮아졌으니, 코퍼스 형태가 선택을 좌우해야 한다.

JavaScript를 실행하지도 않고, 사용자가 정의한 반복 행도 내보내지 못한다. 두 MediaWiki 페이지에서는 author와 sitename이 null이었다. 이는 템플릿 범위에서 관찰된 결과다. Readability는 trafilatura가 떨어뜨린 캡션을 유지했고, f3_short_120으로 표시된 샘플에서는 더 높은 점수를 받았다. 눈에 보이는 증거가 말해 주는 것은 “매우 짧은 샘플에서 F1이 더 낮았다”는 사실이지, 문자 수가 얼마였는지나 출력이 망가졌다는 주장은 아니다.

웹 데이터 추출을 위해 Thunderbit 사용해 보기 Get Started Free

자주 묻는 질문

trafilatura는 어떤 구조를 반환하나요? 추출된 콘텐츠와 메타데이터를 JSON, Markdown, text, HTML, XML, CSV로 직렬화할 수 있다. 이는 구조화된 직렬화이긴 하지만, 상품명/가격/평점처럼 사용자가 정의한 반복 행 스키마와는 다르다. 카탈로그 샘플에서는 값들이 타입화된 행이 아니라 평문 콘텐츠로 반환됐다.

trafilatura로 제품 카탈로그를 구조화된 행으로 스크래핑할 수 있나요? 아니요. 콘텐츠 추출기이지 구조화 스크래퍼가 아니다. 카탈로그 샘플에서 12개 제품명을 평문으로 반환했지만 구조화된 행은 0개였다. 이름은 출력 안에 있지만 필드는 아니다. name/price/rating 같은 타입화된 레코드가 필요하다면 selector 기반 파서나 스키마 기반 추출 API를 사용해야 한다.

trafilatura는 JavaScript를 렌더링하나요? 아니요. 정적 HTML만 처리한다. 클라이언트 렌더링 페이지를 넣으면 JavaScript가 실행되기 전에 서버가 보낸 내용만 받게 되며, 그 내용이 원하는 본문이 아닌 경우가 많다. JS 비중이 큰 대상이라면 별도 렌더러와 함께 사용해야 한다.

trafilatura 설치는 어렵나요? 테스트한 Python 3.14 virtualenv에서는 17개 패키지만 설치됐고, 별도 브라우저 런타임도 필요하지 않았다. 가장 큰 wheel은 lxml 8.6 MB였다. 다만 별도로, 로컬 500 응답 1건이 None으로 돌아오기까지 30.012초가 걸렸다. 검증된 deadline이 필요하다면 호출자가 제어하는 HTTP 클라이언트를 쓰는 편이 좋다.

trafilatura는 상업적으로 무료인가요? Apache-2.0 라이선스라 관대하고 상업적 사용에도 유리하다. 다만 직접 활용하기 전에 repo에서 현재 라이선스를 다시 확인하자.