올해 주목받는 스크래핑 도구들 대부분은 브라우저를 구동하려고 한다. trafilatura는 그렇지 않다. 이 도구는 순수 Python 라이브러리로, 정적 HTML을 읽고 그중 실제 기사에 해당하는 블록을 판별한 뒤 나머지는 버린다. 핵심 콘텐츠만 뽑아내는 이 좁은 역할이 바로 trafilatura의 존재 이유이며, 그 목적을 예전부터 충실히 해온 도구다. 심지어 “LLM-ready markdown”이라는 표현이 유행하기 전부터 말이다.
나는 Python 3.14 환경에서 2.1.0 버전을 정해진 테스트 픽스처 세트에 돌려봤는데, 가장 인상적이었던 건 기사 테스트였다. 실제 본문 텍스트를 일반적인 페이지 장치들로 둘러쌌다. 로그인 안내, “Subscribe” 알림, 네비게이션 링크, 저작권 푸터 같은 것들이다. 그런데 trafilatura는 제목과 본문 3개 문단 전부, 작성자, 날짜를 그대로 돌려주면서도 이런 군더더기 표시는 모두 제거했다. 브라우저도 없고, 사이트별 규칙도 없고, 함수 호출 한 번이면 끝난다. 다만 한 가지 제약은 있다. 구조화된 데이터를 요구하는 순간 드러난다. 이 부분은 아래에서 더 다루겠다. 결함이라기보다 설계 철학에 가깝다.
trafilatura가 무엇인지, 그리고 내려놓아야 할 전제
공식 소개문은 이 도구를 “웹에서 텍스트와 메타데이터를 수집하는 Python 및 명령줄 도구: 크롤링, 스크래핑, 추출”이라고 설명하며, 출력 형식으로 CSV, JSON, HTML, Markdown, TXT, XML을 지원한다고 말한다. 범위는 넓지만, 실제로 이 도구를 구분 짓는 핵심을 다소 약하게 표현한 셈이다. 진짜 가치는 크롤링 보조 기능이나 여섯 가지 출력 형식이 아니다. 바로 콘텐츠 추출이다. HTML 문서를 넣으면, 본문만 뽑아내고 페이지의 외형 요소는 걷어낸다.
이 도구를 이해하는 데 가장 중요한 사고방식을 하나 정리해보자. 페이지를 대상으로 하는 대부분의 스크래퍼는 셀렉터 기반이다. “클래스가 product-price인 요소를 가져와라”라고 지정하면, 해당 위치에 있는 값을 그대로 반환한다. 반대로 trafilatura는 문서 전체를 읽고, 콘텐츠 휴리스틱을 이용해 어떤 블록이 기사 본문이고 어떤 부분이 군더더기인지 판단한다. 그래서 한 번도 본 적 없는 페이지도 사이트별 설정 없이 깨끗하게 정리할 수 있다. 동시에, 이 방식 때문에 구조화된 카탈로그를 반환할 수는 없다. 스키마도 없고 필드 매핑도 없고, 단지 무엇을 콘텐츠로 볼지에 대한 판단만 있기 때문이다. 즉, 이 도구는 파서가 아니라 추출기다.
가볍다는 점도 정말 장점이다. 순수 Python, 헤드리스 브라우저 없음, 캐시 안에 chromium 바이너리도 없음, 첫 실행 때 기습하는 Playwright 설치도 없다. 이 특성은 처음엔 별것 아닌 것처럼 보일 수 있지만, 수천 개 URL을 대상으로 추출을 돌려보면 얘기가 달라진다. 의존성 용량 하나, 서브프로세스 하나도 모두 운영 부담이 되기 때문이다. 이 글을 쓰는 2026-07-09 기준으로 이 프로젝트는 약 6.26k 스타를 가진 규모이며(adbar/trafilatura), 브라우저/크롤러 프레임워크들보다 훨씬 작은 저장소다. 다만 이는 품질에 대한 평가가 아니라, 이 도구의 범위를 설명하는 맥락이다.
설치는 짧고, 그게 바로 리뷰 포인트다
설치는 한 줄이면 끝이고, 따로 경고할 만한 것도 없다. 그리고 그 점 자체가 리포트할 가치가 있다. 새 virtualenv에서 pip install trafilatura를 실행하니 Python 3.14 환경에 깔끔한 패키지 트리가 한 번에 들어왔다. 브라우저 다운로드도 없고, 설치 후 추가 단계도 없고, 복잡한 전이 의존성도 없었다. 이런 라이브러리를 여럿 검토하다 보면 보통 두 번째 신발이 떨어지길 기다리게 된다. 첫 실행 시 드러나는 150MB짜리 브라우저 번들, 빌드가 안 되는 네이티브 확장, 아무도 설명해주지 않은 [fetchers] 추가 그룹 같은 것들 말이다. 그런데 trafilatura에서는 그런 일이 없었다.
pip이 설치해준 버전은 2.1.0이었고, 이는 2026-06-07에 공개된 최신 릴리스와 일치한다. 따라서 아래 수치들에는 “오래된 버전을 테스트했다”는 꼬리표가 붙지 않는다. 이 카테고리에서는 흔치 않은 일이다. 내가 본 많은 무거운 도구들은 테스트할 즈음 이미 메이저 버전 하나쯤 뒤처져 있었다. 여기서는 테스트한 빌드와 배포 중인 빌드가 같다.
실사용 테스트: 실제로 무엇을 돌려줬는가
나는 trafilatura를, 이 도구가 가장 잘하는 일과 가장 약한 지점을 모두 건드리도록 만든 픽스처에 적용해봤다. 그리고 내 판단을 결정한 건 기사 테스트였다.
로컬 기사 픽스처 하나를 가져와 실제 본문을 노이즈 속에 묻었다. 로그인 안내, “Subscribe” CTA, 네비게이션 링크, 저작권 푸터를 넣었다. 이런 건 순진한 스크래퍼가 본문과 함께 덜어오는 전형적인 군더더기다. 그런데 trafilatura는 제목과 본문 3개 문단 전부를 돌려주었고, Login/Subscribe/Copyright 같은 고유한 군더더기 표시는 출력에서 모두 사라졌다. 텍스트뿐 아니라 페이지 메타데이터에서 작성자와 날짜도 정확히 추출했다. 결과는 한 번의 호출로 .txt, .md, .json 세 형식으로 나왔다.
이 다중 형식 출력은 잠깐 짚을 가치가 있다. 한 번의 추출이 일반 텍스트, Markdown, JSON으로 모두 빠져나왔다. 여기서 Markdown 경로는 요즘 모두가 찾는 “LLM-ready text” 단계다. 지저분한 페이지를 넣으면 구조가 보존된 깔끔한 문장을 얻고, 이를 모델에 넘기면 된다. trafilatura는 이 과정을 브라우저 없이 해낸다. 브라우저 기반 도구들이 렌더링 스택 전체를 띄워서 만들어내는 것과 같은 결과를, 훨씬 조용하게 얻는 방식이다.
그다음은 공개 페이지 검사였다. Books to Scrape의 상품 페이지를 넣어봤더니, 1,324자의 깔끔한 텍스트와 Markdown이 나왔다. 페이지 장식 없이 읽기 쉬운 설명 블록만 남았다. 그리고 HTTP 500을 응답하는 페이지를 넣었을 때 fetch_url은 예외를 던지는 대신 None을 반환했다. 크래시도 없고, 추적해야 할 스택 트레이스도 없었다. 이런 밋밋하지만 올바른 실패 방식은 스케줄로 무인 실행되는 작업에서는 정확히 원하는 동작이다.
한계
세 가지가 있고, 각각 이 도구가 맞는 자리를 좁힌다.
첫째이자 가장 중요한 점: trafilatura는 구조화 스크래퍼가 아니라 콘텐츠 추출기다. 12개 상품이 있는 카탈로그 픽스처에 돌려봤더니, 상품명 12개를 텍스트로는 모두 가져왔지만 구조화된 행은 정확히 0개였다(평평한 텍스트 478자). 이름과 가격은 출력 안에 들어있지만, 필드는 아니다. [{name, price, rating}, …] 같은 결과가 필요하다면 이건 잘못된 도구다. 어떤 설정 플래그를 바꿔도 달라지지 않는다. 이것은 버그가 아니라 설계 선택이다.
둘째, JavaScript 렌더링을 하지 않는다. 정적 HTML만 읽는다. 클라이언트 렌더링 SPA에 넣으면, JS가 실행되기 전에 서버가 내려준 HTML만 받게 된다. 보통 그 내용은 쓸모가 없다. 대상 사이트가 JS 의존도가 높다면 별도의 렌더러를 붙여야 한다. trafilatura가 그 부분까지 해주지는 않으며, 그런 기능을 주장하지도 않는다.
셋째는 내 테스트 근거에 대한 주의사항이다. 위의 공개 추출 테스트는 실제 뉴스 기사 대신 상품 설명 블록에 의존했다. 내가 사용한 공개 샌드박스(toscrape 계열)는 모두 카탈로그뿐이고 뉴스 페이지가 없었기 때문이다. 깔끔한 기사 정리 결과는 통제된 로컬 픽스처에서 나온 것이다. 결과 자체는 신뢰한다. 군더더기 제거가 명확하고 재현 가능했기 때문이다. 다만 상품 페이지 하나를 가지고 뉴스룸 수준의 추출을 입증했다고 보기는 어려우므로, 그렇게 주장하진 않겠다.
이 간극을 어느 정도 메우기 위해, 저장된 픽스처를 읽는 별도의 비채점 데모를 두 개의 실제 기사 페이지로 돌렸다. 실행이 결정론적이도록 만든 방식이다. Wikipedia의 “Web scraping” 문서에서는 raw HTML 230,049바이트가 추출 콘텐츠 26,673바이트로 줄었고(본문 대비 원본 비율 0.116), 확인한 사이트 장식 표시 4개 — “Jump to content”, “Privacy policy”, “Powered by MediaWiki”, “This page was last edited” — 가 모두 사라졌다. 아카이브된 Wikinews 기사에서는 79,716바이트에서 2,200바이트로 줄었고(비율 0.028), 체크한 표시 5개가 모두 없어졌다. 두 페이지 모두 제목, 날짜, 호스트명은 채워졌고, 작성자와 사이트명은 둘 다 null이었다. 이 누락도 숨기지 않고 그대로 보고한다. 여기서 두 가지를 분명히 해두자. 이 바이트 비율은 마크업과 장식이 얼마나 제거됐는지를 보여줄 뿐, 추출 정확도를 의미하지는 않는다. 또 두 페이지 모두 같은 MediaWiki 계열이라, 이것은 실제 기사에 대한 데모이지 대표적인 코퍼스는 아니다.
정확도 자체에 대해서는, 내가 직접 측정했다고 하지 않고 외부 근거를 보겠다. trafilatura는 자체 평가 페이지를 공개하고 있으며, ScrapingHub article-extraction benchmark에서는 readability-lxml(~0.887) 같은 비교군보다 높은 오픈소스 최고 F1(약 0.945)을 보고한다. 다만 이 수치에 대해 정직하게 덧붙일 점이 두 가지 있다. 하나는 내 테스트가 아니라 해당 벤치마크에서 나온 수치라는 점, 다른 하나는 보고된 ~0.945가 내가 돌린 2.1.0이 아니라 더 오래된 0.5.1 계열에 연결되어 있다는 점이다. 그러니 이것은 이 도구가 왜 좋은 평판을 얻었는지 보여주는 외부 벤치마크 증거로 읽어야지, 이 리뷰의 측정값으로 보면 안 된다.
장단점
장점:
- 내가 테스트한 집합에서 가장 깔끔한 기사 추출 결과 — 제목과 3개 문단 전부, Login/Subscribe/Copyright 등 모든 군더더기 표시 제거
- 본문과 함께 작성자, 날짜 메타데이터도 정확히 추출
- 한 번의 호출로 txt, Markdown, JSON을 모두 출력 — Markdown은 진짜 LLM-ready text 단계
- 가볍고 순수 Python 기반 설치 — 브라우저 없음, 바이너리 다운로드 없음, 의존성 장벽 없음
- 우아한 실패 처리: HTTP 500에서
fetch_url이 예외 대신None반환 - 테스트한 버전이 현재 릴리스(2.1.0)와 동일 — 버전 차이 없음
- Apache-2.0 라이선스 — 관대하고 상업적으로도 쓰기 좋음
단점:
- 구조화 스크래퍼가 아님: 카탈로그 테스트에서 12개 이름은 텍스트로 가져왔지만 타입이 있는 행은 0개
- JavaScript 렌더링 없음 — 정적 HTML만 처리, 클라이언트 렌더링 페이지에는 별도 렌더러 필요
- 일부 사이트에서는 메타데이터가 불완전함: 실제 기사 픽스처 두 개 모두에서 author와 sitename이 null
- 공개 텍스트 테스트는 실제 뉴스 기사가 아니라 상품 설명 블록을 사용함
- 내장 크롤/사이트맵 스파이더와 CSV/XML 출력 형식은 이번 테스트에서 다루지 않음
누구에게 맞고, 누가 건너뛰어야 하는가
trafilatura는 “URL은 있는데, 네비게이션 바나 쿠키 배너, 뉴스레터 알림 없이 깔끔한 기사 텍스트만 원한다”는 문제를 가진 사람에게 딱 맞다. 텍스트 코퍼스를 만들거나, 페이지를 모델에 넣거나, 읽기 쉬운 콘텐츠를 보관하거나, 웹 기사에 NLP를 돌리는 작업이라면 이 도구가 제격이다. 브라우저를 띄우지 않고도 지저분한 HTML을 깔끔한 Markdown이나 JSON으로 바꾸는 가벼운 단계가 필요하다면 설치해서 바로 쓰면 된다.
반대로, 진짜로 필요한 것이 구조화 추출이라면 건너뛰는 게 맞다. 예를 들면 가격이 포함된 상품 행, 타입이 있는 레코드, key: value 필드 같은 것들이다. 이 도구는 표가 아니라 텍스트를 준다. 카탈로그 테스트에서도 이름은 복원됐지만 행은 복원되지 않았고, 그건 바뀌지 않는다. 또 대상 페이지가 브라우저에서 렌더링되고, 별도의 렌더러를 붙일 생각이 없다면 이것도 맞지 않는다. trafilatura는 정적 HTML만 읽고 거기서 멈춘다. 실패 양상은 극적이지 않다. 그냥 결과가 비거나 얇게 나와서 왜 그런지 궁금해질 뿐이다. 도구를 작업에 맞춰 써야 한다. 기사 텍스트는 가능, 구조화 JSON이나 JS 렌더링 페이지는 다른 선택지를 보자.
대안, 그리고 Thunderbit이 들어가는 자리
먼저 공정하게 말하자. trafilatura는 무료이고, Apache-2.0 라이선스이며, 직접 호스팅해서 쓰는 라이브러리다. 코드를 직접 소유하고, 페이지당 비용은 없으며, 운영 부담도 작아 어떤 파이프라인에도 쉽게 넣을 수 있다. 기사에서 본문만 깔끔하게 걷어내는 일만 놓고 보면, 이 조합은 정말 강력하다. 유료 서비스라고 해서 이 판단이 바뀌지는 않는다.
비교가 흥미로워지는 지점은 trafilatura가 의도적으로 선을 긋는 곳이다. 구조화 데이터와 JavaScript다. 이 두 가지는 trafilatura가 하지 않는 일이고, 반대로 관리형 추출 API가 가장 잘 맡는 영역이기도 하다. 바로 그 경계 반대편에 Thunderbit의 개발자용 스택이 있다. 정적 HTML 기사 텍스트를 두고 trafilatura와 경쟁하는 것이 아니라, 보완하는 위치다. /distill 엔드포인트는 trafilatura와 같은 형태의 작업, 즉 페이지를 깨끗한 LLM-ready Markdown으로 바꾸는 일을 해주지만, JavaScript 렌더링은 서버 측에서 처리한다. 이건 trafilatura가 건너뛰는 정확히 그 반쪽이다. 그리고 /extract는 사용자가 정의한 스키마에 맞춰 구조화된 JSON을 반환한다. 이는 설계상 trafilatura가 거부하는 반쪽이다. 478자의 평평한 텍스트로 돌아온 카탈로그는 바로 /extract를 써야 하는 사례다. AI 에이전트와 코딩 어시스턴트를 위한 MCP 서버도 있고, 필드 제안 도구는 무료로 시험해볼 수 있다. 터미널, CI, 크론 작업에는 npx @thunderbit/thunderbit-cli 형태의 CLI도 있다. 이 모든 것은 10만 명 이상이 쓰는 Thunderbit Chrome Extension과 같은 엔진 위에서 돌아간다. 그래서 비기술 사용자용 경로도 존재하지만, 이 독자층에게 중요한 표면은 API, MCP, CLI다.
그러니 진짜 트레이드오프는 텍스트 추출 품질이 아니었다. 적어도 trafilatura가 잘 맞는 페이지에서는 이 도구가 이긴다, 그리고 나는 그걸 분명히 말하겠다. 쟁점은 범위와 브라우저를 누가 돌리느냐다. 정적 HTML에서 깔끔한 기사 텍스트를 뽑고 싶고, 직접 호스팅하며, 호출당 비용이 0이길 원한다면 trafilatura가 더 가볍고 더 날카로운 도구다. 반대로 스키마에 맞춘 구조화 JSON이 필요하거나, JavaScript가 실행된 뒤에야 내용이 보이는 페이지라면 관리형 스택의 영역이다. 그리고 그건 trafilatura가 겨루려는 싸움이 아니다. 관리형 쪽의 가격은 Thunderbit pricing page에서 확인할 수 있다. 직접 렌더러를 운영하는 비용과 비교해보면 된다.
전체 카테고리에서 선택지를 비교하고 있다면, 나는 실제로 쓰는 웹 스크래핑 도구 비교 모음을 계속 업데이트하고 있다. 이런 라이브러리와 브라우저 기반/관리형 대안들을 함께 비교할 수 있다.
결론
trafilatura를 써야 할까? 그렇다 — 작업이 지저분한 HTML을 깔끔한 기사 텍스트로 바꾸는 일이라면, 그리고 이 도구가 의도적으로 하지 않는 두 가지를 명확히 이해하고 있다면 말이다. 이 도구는 단 하나의 가벼운 설치만으로 페이지에서 모든 군더더기 표식을 걷어내고, 제목과 본문 3개 문단, 작성자와 날짜를 돌려줬다. 게다가 txt, Markdown, JSON을 함께 내보내므로 진짜로 쓸 수 있는 LLM-ready text 단계다. 헤드리스 브라우저와 AI 크롤러 없이는 아무것도 못 한다고 믿는 분야에서, 브라우저를 전혀 열지 않는 도구가 내가 중요하게 여기는 정리를 해냈다.
다만 크기를 정확히 파악해야 한다. 이건 추출기지, 구조화 스크래퍼가 아니다. 카탈로그는 12개 이름의 텍스트와 0개 행으로 돌아왔다. 정적 HTML만 읽고 JavaScript는 실행하지 않는다. 메타데이터 추출은 어떤 페이지에서는 강하고, 어떤 페이지에서는 부분적이다(내가 확인한 실제 기사 픽스처 두 개에서는 author와 sitename이 null이었다). 그리고 공개 텍스트 테스트는 실제 뉴스 기사가 아니라 상품 설명 블록을 사용했으므로, 뉴스룸급 추출이라는 주장은 아직 가능성을 보여준 수준으로 받아들여야 한다. 이 범위 안에서는 trafilatura가 내가 비교한 더 무거운 도구들보다 한 가지 일을 더 깔끔하게 해낸다. 그리고 그것도 거의 아무것도 설치하지 않은 상태에서 말이다.
웹 데이터 추출용 Thunderbit 체험하기 Get Started Free
자주 묻는 질문
trafilatura는 페이지에서 실제로 무엇을 추출하나요? 본문, 제목, 그리고 작성자와 날짜 같은 메타데이터를 추출하며, 군더더기는 제거합니다. 내 테스트에서는 네비게이션, 로그인, 구독, 저작권 잡음으로 둘러싸인 페이지에서 제목과 본문 3개 문단 전부를 돌려주었고, 그런 표식들은 출력에서 모두 사라졌습니다. 콘텐츠가 무엇인지 휴리스틱으로 판단하므로, 처음 보는 페이지도 사이트별 셀렉터 없이 정리할 수 있습니다.
trafilatura로 상품 카탈로그를 구조화된 행으로 스크래핑할 수 있나요? 아니요. 이건 구조화 스크래퍼가 아니라 콘텐츠 추출기입니다. 12개 상품 카탈로그 픽스처에서는 12개 상품명을 평평한 텍스트(478자)로만 가져왔고, 구조화된 행은 0개였습니다. 이름은 출력에 들어있지만 필드는 아닙니다. name/price/rating 같은 타입 있는 레코드가 필요하다면 셀렉터 기반 파서나 스키마 기반 추출 API를 쓰세요.
trafilatura는 JavaScript를 렌더링하나요? 아니요. 정적 HTML만 처리합니다. 클라이언트 렌더링 페이지를 넣으면, JavaScript가 실행되기 전에 서버가 보낸 HTML만 받게 되며, 보통 원하는 내용이 아닙니다. 대상 사이트가 JS 의존도가 높다면 별도의 렌더러와 함께 써야 합니다. trafilatura는 정적 문서를 읽고 거기서 멈춥니다.
trafilatura 설치는 어렵나요?
아니요. 오히려 이 도구의 강점 중 하나입니다. Python 3.14의 새 virtualenv에서 pip install trafilatura를 실행하니 브라우저 다운로드도, 설치 후 추가 단계도, 숨은 extras 그룹도 없이 깔끔한 패키지 트리가 한 번에 설치됐습니다. pip이 설치한 버전(2.1.0)은 2026-06-07에 공개된 최신 릴리스와 같습니다.
다른 추출기와 비교했을 때 trafilatura의 정확도는 어떤가요? 이번 리뷰에서는 정확도를 직접 벤치마크하지 않았으므로, 대신 외부 근거를 보겠습니다. trafilatura는 자체 평가 페이지를 공개하고 있으며, ScrapingHub article-extraction benchmark에서는 readability-lxml(~0.887) 같은 비교군보다 높은 오픈소스 최고 F1(약 0.945)을 보고합니다. 다만 그 수치는 내가 테스트한 2.1.0이 아니라 더 오래된 0.5.1 계열의 벤치마크 결과이므로, 이 글의 측정값이 아니라 도구의 평판을 보여주는 외부 증거로 읽어야 합니다.
