Heritrix 리뷰: WARC 충실도와 아카이브 크롤링의 운영 비용

Heritrix는 Internet Archive의 오픈소스 아카이브 크롤러입니다. Wayback Machine의 소프트웨어 계보를 잇는 도구로, 20년 동안 현장에서 꾸준히 쓰여 왔습니다. 이 도구의 역할은 사이트가 실제로 응답한 내용을 그대로 WARC 파일에 담아 두고, 나중에 똑같이 재생할 수 있게 만드는 것입니다. 내부적으로는 Java 엔진이고, 각 크롤 작업은 XML로 작성된 Spring 빈 그래프로 구성되며, 전체 작업 수명 주기는 REST API로 제어됩니다. 이건 스크래퍼가 아닙니다. 선택자 문법도, 필드 매핑도, 마지막에 나오는 행도 없습니다.

저는 3.16.0 버전을 통제된 로컬 테스트 환경에 올려서, 실제로 무엇을 기록하는지 레코드 단위로 하나씩 세어 봤습니다. 눈에 띈 건 완성도였습니다. 20개의 가져온 URI가 61개의 WARC 레코드를 만들어냈고, 모든 응답에는 페이로드 다이제스트와 캡처 IP가 들어갔으며, 모든 요청은 자신이 속한 응답과 연결돼 있었습니다. 이 모든 게 별도 설정 손질 없이 돌아갔습니다. 반면 운영 난도는 완전히 반대였습니다. 41MB 배포본, 114개의 jar(lib/에는 142개 파일이 있고, 나머지 28개는 LICENSE 및 NOTICE 문서), 그리고 첫 fetch 전에 약 750줄짜리 작업 설정이 필요합니다. 다만 이번 테스트의 모든 크롤은 웹 UI를 전혀 건드리지 않고 curl만으로 헤드리스 실행했습니다.

저장 결과에서는 덜 눈에 띄는 기본값 하나가 드러났습니다. 테스트용 두 URL이 바이트 단위로 완전히 같은 내용을 반환했는데, 기본 프로필은 둘 다 그대로 가져와 전부 아카이브했습니다. 즉, 응답 레코드 2개와 revisit 레코드 0개였고, 두 응답은 같은 페이로드 다이제스트를 가졌습니다. Content-digest 중복 제거는 관련 히스토리 프로세서를 추가한 뒤에야 동작합니다. 기본 프로필에서는 켜져 있지 않으며, 저장 공간은 아껴주지만 대역폭은 줄여주지 않습니다.

Heritrix가 실제로 무엇인지

아카이빙은 스크래핑이 아닙니다. 이 둘을 헷갈리기 쉬운데, 바로 그 점을 분명히 해둘 필요가 있습니다. Heritrix는 행 단위 데이터를 넘겨주지 않습니다. CSV도 없습니다. 출력물은 HTTP 대화 그 자체입니다. 즉, 헤더와 본문, 그리고 캡처 메타데이터가 보존용 포맷에 저장되며, 이것이 이 분야 전체의 기준 구현입니다. Heritrix에 상품 가격표를 기대하는 건 속기사에게 요약본을 요구하는 것과 같습니다.

2026-07-27 기준 수치는 다음과 같습니다. 이 저장소는 별 3,285개, 열린 이슈 36개를 기록하고 있고, 3.16.0은 2026-07-03에 공개된 최신 릴리스입니다. 제가 테스트한 빌드가 바로 이 버전이므로, 여기서 말하는 내용은 낡은 버전에 대한 불평이 아닙니다. 라이선스에는 약간의 함정이 있습니다. LICENSE 파일 자체는 일반적인 Apache-2.0인데, GitHub의 감지 결과는 일부 포함된 서드파티 파일에 별도 조건이 있어 "Other"로 표시됩니다. Heritrix를 상용 제품에 넣을 생각이라면, 사이드바 배지 한 번 훑어보는 수준이 아니라 법무 검토 몇 분이 더 맞습니다.

모든 것을 좌우하는 구조적 사실 하나가 있습니다. Heritrix는 브라우저를 구동하지 않습니다. HTTP로 가져오고, 응답 바이트에서 링크를 추출합니다. 현대 아카이빙에서 가까운 동생 격인 Browsertrix Crawler는 정반대입니다. 실제 Chromium을 사용해 브라우저가 수행한 동작을 기록합니다. 둘 다 WARC를 쓰지만, 이번 리뷰는 Heritrix의 비브라우저 경로만 측정했습니다. 어느 쪽도 대규모 처리량이나 확장성을 비교하지는 않았습니다.

체인, 빈, SURT: 크롤이 실제로 조립되는 방식

내부적으로 Heritrix 작업은 Spring 애플리케이션 컨텍스트입니다. 단순히 Spring으로 "설정되는" 수준이 아니라, XML로 작성된 Spring 빈 그래프 그 자체이며, 크롤의 모든 구성 요소가 교체 가능한 빈입니다.

Frontier는 URI 큐를 보관하며, 호스트 단위로 나뉩니다. 바로 이 분할 방식 때문에 politeness 동작이 결정되고, 이 점은 뒤에서 중요해집니다.

Processor chain은 세 단계로 일을 처리합니다. 후보 체인에서는 새로 발견한 URI를 예약할지 판단하고, fetch 체인에서는 DNS, robots, HTTP fetch, 링크 추출을 수행하며, disposition 체인에서는 WARC 기록과 상태 업데이트를 합니다. Heritrix에 기능을 추가할 때는 보통 적절한 체인의 적절한 위치에 processor bean을 끼워 넣는 방식으로 구현합니다. 제가 dedup을 활성화한 것도 정확히 그 방식이었습니다.

Scope는 SURT(Sort-friendly URI Reordering Transform) 위에서 작동하는 DecideRule 스택입니다. 예를 들어 http://www.example.com/a를 http://(com,example,www,)/a로 바꿔, 호스트 접두사가 계층적으로 정렬되게 만듭니다. 기본 scope는 seed의 SURT 접두사로 생성됩니다. 규칙은 순서대로 허용/거부를 판단하며, 마지막으로 일치한 규칙이 이깁니다.

WARC writer는 disposition 체인에 있고, politeness는 frontier 안에서 delayFactor, minDelayMs, maxDelayMs 세 숫자로 관리됩니다. Robots 준수는 fetcher의 policy 문자열로 제어됩니다.

그리고 이 모든 것은 REST API로 제어할 수 있는데, 이 점이 제가 예상한 것보다 훨씬 중요했습니다.

설정이 전체 경험에서 가장 무거운 부분이다

첫 fetch 전에 배포해야 하는 것들:

이 작업 설정의 대부분은 손댈 일이 없습니다. 하지만 아예 건너뛸 수는 없고, 크롤러가 아무 것도 가져오기 전에 반드시 채워야 하는 두 필드가 있습니다. 바로 seed와 metadata.operatorContactUrl입니다. 기본값은 자리표시자이며, 실제 크롤을 수행하는 운영자를 식별할 수 있는 진짜 URL로 바꾸기 전에는 크롤이 시작되지 않습니다.

이 요구사항은 책임 추적 장치를 만듭니다. 운영자는 크롤 실행 전에 반드시 연락 가능한 URL을 제공해야 합니다. 물론 이것만으로 신원 진위, 크롤 권한, 또는 관련 규정 준수를 증명하진 못합니다. 하지만 연락처 정보를 선택 사항이 아니라 작업의 일부로 강제한다는 의미는 분명합니다.

설정 과정에서 두 가지는 정말 예상 밖이었습니다.

문서의 최소 요구보다 더 최신 JDK에서도 동작했습니다. Getting Started 문서는 Java 17 이상을 요구합니다. 그런데 Heritrix 3.16.0은 OpenJDK 26.0.1에서 정상 부팅했고, REST API를 제공했으며, 이 환경의 모든 크롤을 --add-opens, --enable-preview, Security Manager 우회 없이 완료했습니다. 이건 macOS arm64 단일 결과이지 호환성 매트릭스는 아니지만, 이번 테스트 빌드가 이 호스트에서 JDK 17에만 묶여 있지 않다는 점은 확인해 줍니다.

웹 UI를 아예 만질 필요가 없습니다. 전체 작업 수명 주기는 REST로 돌아가며, 저는 curl만으로 전 과정을 자동화했습니다. 작업 생성, beans 파일 PUT, build, launch, unpause, controller state가 FINISHED가 될 때까지 폴링, terminate, teardown까지 전부입니다. 이것이 "Heritrix를 파이프라인에서 운영할 수 있는가"에 대한 진짜 답입니다. 네, 가능합니다. 완전 헤드리스이며, 브라우저 클릭은 전혀 필요 없습니다. 많은 글이 Jetty UI를 캡처하고 그것이 인터페이스인 것처럼 보이게 하지만, 실제로는 편의 기능일 뿐 필수는 아닙니다.

호스트 특이적 배포 메모 하나를 덧붙이자면, 이 Mac은 Surge로 시스템 전체 HTTP 프록시를 사용합니다. Heritrix의 Java 클라이언트는 그 프록시 설정을 그대로 물려받아, NO_PROXY와 OS 예외 목록에도 불구하고 127.0.0.1 테스트 트래픽까지 프록시를 통해 보냈습니다. 그 결과 503 응답이 발생했습니다. JVM을 -Djava.net.useSystemProxies=false로 시작하자 결과는 2개의 503에서 18개의 200으로 바뀌었습니다. 이건 Heritrix 결함이 아니라 환경 상호작용이었고, 이 플래그는 시스템 프록시 설정 상속이 바람직하지 않을 때만 의미가 있습니다.

실제로 아카이브에 남는 것

기본 프로필을 통제된 테스트 환경에 적용했습니다. 이 환경은 HTML 페이지, 3단계 깊이의 링크 체인, robots.txt와 sitemap, 그리고 의도적으로 넣은 404 및 500 경로를 포함한 로컬 서버였습니다. 결과는 요약 줄을 믿지 않고 레코드 단위로 직접 파싱했습니다.

20개의 가져온 URI는 61개의 레코드를 만들었습니다.

URI 하나당 response / request / metadata가 1:1:1로 깔끔하게 기록됐고, 별도 설정 없이 기본 상태에서 이 비율이 유지됐습니다. 레코드별 완성도도 확인되었습니다.

HTTP 상태도 그대로 보존됐습니다. 보기 싫은 상태도 예외가 아닙니다. 200 OK, 404 Not Found, 500 Internal Server Error가 모두 실제 상태줄 그대로 저장되어, 실패로 버려지지 않았습니다.

이 마지막 지점이 아카이빙과 스크래핑을 가장 분명하게 갈라놓습니다. 스크래퍼는 500을 재시도하거나 건너뛰어야 할 오류로 봅니다. 반면 아카이버는 그것을 그 순간 서버가 말한 내용으로 봅니다. 보존할 가치가 있는 사실인 셈입니다. Heritrix Output 위키는 이 레코드 구조를 설명합니다. 하지만 제가 어디에서도 보지 못한 것은, 알려진 엔드포인트 세트에서 측정한 multiplicity와 20/20 연결 결과였습니다. 실제로는 문서대로 동작했습니다.

dedup 결과를 양쪽에서 측정해 본 결과

테스트 환경에서는 /dup/one과 /dup/two가 바이트까지 동일한 본문을 반환했습니다. URL은 다르지만 내용은 같았고, 바로 이런 경우를 콘텐츠 다이제스트 dedup으로 줄이려고 합니다. 저는 두 번 실행했습니다. 한 번은 기본 프로필로, 한 번은 digest-history 체인(BdbContentDigestHistory에 더해 fetch 체인에 ContentDigestHistoryLoader, WARC writer 뒤에 ContentDigestHistoryStorer)을 넣은 뒤였습니다.

기본 상태에서는 두 응답 모두 같은 다이제스트를 받았지만, 이를 처리할 히스토리 프로세서는 작동하지 않았고 두 페이로드가 모두 그대로 기록됐습니다. 체인을 추가하자 두 번째 캡처는 동일한 페이로드 다이제스트를 가리키는 WARC revisit 레코드로 바뀌었고, 이것이 WARC 1.1 사양이 revisit에 대해 정의한 동작입니다.

이건 비밀도 아닙니다. Duplication Reduction Processors 위키 페이지에는 skipIdenticalDigests 기본값이 false이고, URL에 상관없는 dedup을 쓰려면 해당 loader와 storer 빈이 필요하다고 명시돼 있습니다. 숨겨진 동작을 발견한 게 아닙니다. 여기서 측정한 거의 모든 것처럼, 문서화된 Heritrix 동작에 실제 수치를 붙인 것입니다. 차이는 문서와 사람들이 믿는 것 사이에 있습니다. 제 경험상 사람들은 대체로 "Heritrix는 dedup한다"고만 생각하고, 설정이 필요한지에 대한 별표는 놓치곤 합니다.

기억해 둘 만한 결론 두 가지가 있습니다.

Dedup은 전송 시점이 아니라 기록 시점에 작동합니다. 별도 계측을 한 것은 아니지만, 콘텐츠 다이제스트의 원리를 생각하면 분명합니다. 해시를 비교하려면 먼저 바이트가 도착해야 하므로, 두 번째 URL은 어쨌든 원본 서버에서 가져와야 합니다. 체인을 켠다고 줄어드는 것은 저장량이지, 전송량이나 대상 서버의 응답 부담이 아닙니다. dedup을 예의나 대역폭 절감 수단으로 예산에 넣는다면 방향을 잘못 잡은 겁니다.

"어차피 dedup 되겠지"라는 가정으로 저장 용량을 계산하면 크게 틀릴 수 있습니다. 템플릿 중복이 심한 사이트, 예를 들어 미러링된 PDF, 반복 문구가 많은 랜딩 페이지, 같은 기사들의 인쇄용 보기 버전 등을 아카이빙하면서 동일 본문이 자동으로 접힌다고 가정하고 디스크를 산정하면, 기본 프로필은 그 추정보다 훨씬 많은 저장 공간을 사용할 수 있습니다. 두 URL짜리 테스트는 기본 동작을 보여줄 뿐, 수백만 URI 규모에서의 효과를 증명하는 것은 아닙니다. 그 효과는 중복률, 페이로드 크기, 재크롤 설계에 따라 달라집니다.

Scope와 robots는 약속한 대로 정확히 작동했다

크롤러가 "무엇을 가져오지 않았는지"에 대한 자기 진술은 신뢰 가치가 낮습니다. 그래서 두 가지 모두 서버 측 hit counter로 측정했습니다. 즉, Heritrix의 로그와 무관하게 대상 서버가 자체적으로 요청 수를 세게 했습니다.

Scope. 반면 in-scope 호스트는 정상적으로 크롤링됐습니다. 즉, 크롤 자체가 고장 난 것이 아니라 범위가 엄격하게 적용된 것입니다. 다만 여기서는 기본 scope만 테스트했고, 범위를 넓힌 양성 대조군은 따로 두지 않았습니다. 따라서 이것은 문서화된 설계의 확인으로 읽는 것이 맞고, 양방향 증명으로 읽으면 안 됩니다.

Robots. 링크 자체는 항상 접근 가능했습니다. robots 정책만 그 경로를 막았습니다. 준수는 실제로 작동하고, 예외 경로도 실제로 존재합니다. 이 조합이 올바른 구조입니다. 어떤 아카이빙 의무는 robots를 정당하게 우회해야 하며, 그 경우에는 config 파일에 ignore를 의도적으로 입력해야 합니다.

Politeness: 로컬 20페이지 크롤에 57.7초가 걸린 이유

Heritrix가 당신 프로젝트에 맞는지 여부를 결정하는 숫자 하나가 있습니다.

같은 테스트 환경, 같은 3회 실행, 단일 로컬 호스트, 서브밀리초 수준의 지연 환경입니다.

실제 지연은 거의 그대로 minDelayMs 하한에 붙습니다. 서브밀리초 수준의 원본에서는 delayFactor × fetch-time가 사실상 무시 가능하고, 구조적으로 최소값이 지배합니다. 두 행의 비율은 의미가 크지 않습니다. politeness를 0으로 한 경우의 분모가 수십 밀리초 수준이라 실행마다 흔들리기 때문입니다. 더 안정적인 결과는 절대 하한입니다. 즉, 이 테스트 환경에서 기본 Heritrix는 같은 호스트에 대해 요청 사이에 약 3초를 기다렸고, 그 결과 20페이지 크롤이 대략 1분이 걸렸습니다.

체감하기 쉬운 예를 들어보겠습니다. 대학 도서관이 50,000페이지짜리 정부 사이트를 폐쇄 전에 아카이브해야 하고, 모두 한 호스트에 있다고 합시다. 호스트당 3초 하한이면 강제 대기 시간만 150,000초입니다. fetch 시간을 빼더라도 대략 42시간, 즉 거의 이틀에 가까운 시간이 걸립니다. 이 숫자는 제가 측정한 3,036ms 하한에서 나온 산술입니다. 50,000 × 3.036초 = 151,800초 = 42.2시간입니다. 설정값인 3,000ms만 써도 41.7시간이므로, 반올림하면 41이 아니라 42가 맞습니다. 실제 크롤이 아니라, 프로젝트 계획에 필요한 계산입니다.

공정하게 말하면, Heritrix의 politeness는 호스트 단위입니다. frontier가 호스트별로 큐를 나누기 때문입니다. 수천 개 도메인을 넓게 크롤하면 그 큐들 사이에서 병렬화가 일어나고, 이 상한이 전역적으로 그대로 적용되지는 않습니다. 제 테스트 환경은 단일 호스트였기 때문에, 이 숫자에 대해 가장 불리한 경우였습니다. 아카이빙 대상이 하나의 큰 사이트라면, 그 최악의 상황이 곧 당신의 상황입니다.

그리고 이것은 기능입니다. 이 지연이 있어야 아카이브 크롤러가 사이트 소유자에게 차단당하는 대신 허용될 수 있습니다. 이를 낮추는 것은 남의 서버에 대한 결정이며, 도구는 그것을 과격함이 아니라 명시적인 선택으로 드러냅니다.

제가 테스트하지 않은 것

이 측정은 통제된 테스트 환경에서의 크롤 규율만 다루며, 그 바깥은 포함하지 않습니다.

• 크로스 크롤 dedup 및 recrawl. 저는 한 크롤 내부의 content-digest dedup만 측정했습니다. 별도의 크롤 간 URI 히스토리 DB를 유지하는 방식(FetchHistoryProcessor + PersistLog)은 다른 메커니즘이며 테스트하지 않았습니다.
• 대규모 및 장기 안정성. 100만 URI frontier도, 체크포인트 복구도, 며칠짜리 실행도 없었습니다. 이번 테스트는 내구성이 아니라 규율을 측정한 것입니다.
• JavaScript 렌더링 캡처. Heritrix의 기본 캡처는 비브라우저 방식이며, 제가 측정한 것도 이것입니다. 선택적인 브라우저 기반 동작은 여기서 다루지 않았습니다.
• 고지연 원본에서의 politeness. 로컬 지연은 서브밀리초 수준이라 minDelayMs가 구조적으로 지배했습니다. 느린 실제 서버에서 delayFactor가 어떻게 작동하는지는 이 데이터만으로 분리해 볼 수 없습니다.
• sitemap 회수율. robots.txt는 요청됐고 sitemap 지시도 따라갔지만, <loc> 항목을 전부 회수했는지는 별도로 검증하지 않았습니다.

첫 운영 작업 전에 반드시 명시해야 할 것

기본 프로필은 길지만, 아카이브의 의미를 바꾸는 결정은 꽤 압축적입니다. 먼저 scope부터 시작하세요. Seeds는 기본 SURT 접두사를 만들고, DecideRule은 순서대로 범위를 넓히거나 좁힐 수 있습니다. 대표적인 in-scope / out-of-scope URL로 최종 규칙 순서를 검토한 뒤, 서버 측 트래픽이나 별도의 독립 요청 로그로 다시 확인하세요. 크롤 리포트만으로는 제외된 호스트가 실제로 전혀 접촉되지 않았는지 증명할 수 없습니다.

다음으로 robots 정책과 운영자 신원이 수집에서 무엇을 의미하는지 정하세요. 이번 테스트의 기본값은 테스트 환경의 차단 규칙을 따랐고, robotsPolicyName을 ignore로 바꾸자 차단 경로가 가져와졌습니다. 이 스위치는 기술적으로는 단순하지만, 기관 운영상으론 매우 중요합니다. 실제 operatorContactUrl과 함께 누가 왜 승인했는지 기록하세요. 필수 URL은 사이트 운영자가 운영자에게 연락할 경로를 제공할 뿐, 승인 근거를 대신해 주지는 않습니다.

저장 계획도 별도 명시가 필요합니다. 동일 본문을 revisit 레코드로 바꾸고 싶다면, 아카이브 크기를 정하기 전에 content-digest 히스토리 프로세서를 추가하고 검토하세요. 이번 테스트의 체인은 fetch 이후 표현 방식만 바꿨기 때문에, 원본 서버 트래픽은 두 URL 모두에 대해 예산을 잡아야 합니다. 크로스 크롤 dedup은 별도 메커니즘이며, 이번 두 URL/단일 크롤 결과에서 추정하면 안 됩니다. 중복 본문이 있는 작은 검증 크롤은 배포된 빈 그래프가 원하는 레코드 유형을 만드는지 확인하는 저렴한 방법입니다.

마지막으로 politeness를 마지막 순간 조정값이 아니라 스케줄링 입력으로 다루세요. 로컬 단일 호스트 테스트에서는 minDelayMs가 전체 시간을 지배했습니다. 실제 프로젝트에서는 목표 호스트 수와 수집 마감 시점을 기준으로 구성된 호스트별 하한을 계산하고, 대표적인 지연 환경에서 테스트해야 합니다. 넓은 크롤과 단일 사이트 크롤은 host-partitioned frontier에 서로 다른 부담을 줍니다. 이번 리뷰는 후자만 측정했습니다. 운영 절차에는 REST 수명 주기도 넣으세요. build, launch, unpause, poll, terminate, teardown은 자동화에서 각기 관찰할 가치가 있는 별도 상태입니다.

장단점

장점

• 기본 상태에서 아카이브 완성도가 매우 높음: 20/20 응답이 payload digest, capture IP, request↔response 연결까지 포함해 기록되며, 별도 설정이 필요 없음.
• 200, 404, 500 같은 오류 응답도 사실로서 그대로 보존함.
• 서버 측 카운터로 scope 규율을 검증 가능: 범위 밖 fetch는 0건이었고, 범위 안 호스트는 정상 크롤링됨.
• robots 준수가 실제로 fetch를 막으며, 의무적 아카이빙을 위한 ignore 우회 경로도 있음.
• REST로 완전 헤드리스 운용 가능: 생성, 빌드, 실행, 폴링, 종료, 정리까지 전부 curl로 처리 가능.
• OpenJDK 26.0.1에서도 JVM 플래그 없이 깔끔하게 실행됨. 20년 된 코드베이스로서는 꽤 좋은 현대 Java 위생 상태입니다.
• 필수 operator contact URL 덕분에 크롤이 익명으로 실행될 수 없음.
• 크롤의 모든 요소가 교체 가능한 빈이라, dedup 활성화가 포크 작업이 아니라 빈 3개 추가로 끝남.

단점

• content-digest dedup은 기본값으로 꺼져 있고, 동일 페이로드도 전부 기록함. 저장 용량 계획에서 큰 함정이 될 수 있음.
• 배포가 무겁다: 41MB 배포본, 114개 jar, Java 엔진 + Jetty, 약 750줄짜리 Spring 작업 설정.
• 기본 politeness가 호스트당 약 3초 하한을 적용하므로, 단일 호스트 20 URI 크롤이 57.7초 걸림.
• 기본 경로에는 JavaScript 렌더링이 없어, 클라이언트 렌더링 전용 콘텐츠는 수집되지 않음.
• 설정 범위가 넓고, 익숙하지 않은 사용자에게는 진입 장벽이 큼. 5분 만에 첫 크롤을 만드는 흐름은 아님.
• 출력물에는 구조화 데이터가 없음. WARC에서 필드를 뽑는 일은 별도 프로젝트입니다.

누가 써야 하고, 누가 피해야 하는가

Heritrix는 산출물이 아카이브 자체인 기관과 팀을 위한 도구입니다. 도서관, 국가기록원, 법무·컴플라이언스 보존, 웹을 1차 자료로 수집하는 연구팀, 그리고 5년 뒤 특정 날짜에 어떤 URL이 무엇을 제공했는지 증명해야 하는 모든 경우가 여기에 해당합니다. "WARC", "replay", "provenance"라는 단어가 이미 익숙하다면, 이것은 당신의 생태계가 본래부터 둘러싸고 있던 도구이며, 그 무게는 상호운용성을 얻기 위한 대가입니다.

호스트 단위 frontier와 오랜 웹 아카이빙 사용 이력은, 많은 도메인에 걸친 넓은 크롤에 그럴듯한 후보가 되게 만듭니다. 다만 이것은 이 테스트 환경에서 측정한 규모 결과가 아니라 아키텍처와 프로젝트 역사에 대한 판단입니다. 장기 처리량, 체크포인트 복구, 100만 URI 동작은 여기서 아직 검증되지 않았습니다.

데이터가 아니라 아카이브가 필요한 게 아니라면 건너뛰세요. 목적이 상품, 리스트, 연락처의 스프레드시트라면 Heritrix는 페이지를 아주 정교하게 캡처한 뒤, 이를 파싱하는 별도 파이프라인을 또 작성해야 하는 상황을 만들어줄 뿐입니다. 그리고 그 대가로 Java 엔진, Spring 설정, 3초짜리 politeness 하한을 떠안게 됩니다. 또한 대상이 클라이언트 렌더링 SPA라면, 비브라우저 fetcher는 콘텐츠가 아니라 껍데기만 캡처합니다. 그런 경우에는 브라우저 기반 아카이버가 맞는 도구입니다. 오늘 당장 첫 결과가 필요하다면, 이 설정 곡선도 건너뛰는 편이 낫습니다.

대안과 관리형 API가 들어갈 자리

아카이빙 범주 안에서 직접적인 현대 대안은 Browsertrix Crawler입니다. Chromium을 구동하는 브라우저 기반 아카이버로, 브라우저가 실제로 수행한 작업을 기록합니다. Heritrix의 기본 HTTP 응답에는 없는 JavaScript 생성 콘텐츠를 캡처할 수 있지만, 그만큼 브라우저 배포와 런타임 오버헤드가 추가됩니다. 이번 리뷰는 정면 비교 벤치마크를 하지는 않았으므로, 판단은 캡처 요구사항에서 시작해야 합니다. 브라우저가 생성한 상태가 필요하다면 브라우저 아카이버를, 일반 HTTP 리소스라면 Heritrix의 기본 경로를 선택하세요.

관련 리뷰: Browsertrix Crawler 리뷰.

완전히 다른 문제를 다룬다면, 즉 아카이브가 아니라 페이지에서 구조화된 데이터를 뽑고 싶은 경우라면, Heritrix를 추출 시스템과 같은 범주로 취급하지 말고 출력 기준으로 비교해야 합니다. Heritrix는 무료이며 자체 호스팅 방식입니다. JVM을 직접 운영하고, beans 파일을 관리하고, 디스크 용량을 계산하고, politeness를 조정해야 합니다. 보존 자체가 산출물일 때 이 모델이 잘 맞습니다.

고지: Thunderbit는 발행사 제품이며, 이 Heritrix 테스트 환경에서는 검증하지 않았습니다. Thunderbit는 관리형 추출 범주에 속합니다. 출력은 보존용 WARC 파일이 아니라 페이지 콘텐츠 또는 구조화 레코드입니다. 재생 가능한 캡처와 provenance가 필요하면 아카이버를 선택하고, 산출물이 행 데이터나 문서 텍스트이며 관리형 운영이 허용된다면 추출 서비스를 고려하세요.

아카이빙에는 별도의 권한 문제가 있고, 이는 스크래핑과 동일하지 않습니다. Heritrix는 기본적으로 robots.txt를 따르며, 바이트를 가져오기 전에 자신을 식별하도록 요구합니다. 이는 좋은 기본값입니다. 그러나 robots를 준수하는 크롤이 곧바로 승인된 크롤을 뜻하는 것은 아닙니다. 저작권, 이용약관, 개인정보, 그리고 기관 자체의 임무 범위는 그 위에 얹혀 있습니다. ignore 정책은 법적 근거가 있는 조직을 위한 것이지, 편의용 토글이 아닙니다. 아카이빙 프로그램을 시작하려는 경우, 디스크가 가득 차기 전에 승인 범위를 먼저 정리하세요. 이 분야가 처음이라면 웹 스크래핑과 아카이빙의 법적 쟁점도 참고하시기 바랍니다.

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

결론

Heritrix를 써야 할까요? 네 — 출력물이 아카이브이고, Spring bean을 배울 의지가 있는 사람이 있다면 그렇습니다.

이번 테스트 환경은 판단을 분명하게 만들어 줍니다. 기본 프로필은 response, request, capture metadata를 일관되게 보존했고, scope와 robots 제어는 설정대로 서버 측 fetch에 영향을 주었으며, 전체 작업 수명 주기가 REST로 실행됐습니다. 단일 호스트라는 작은 범위 안에서는 아카이빙 파이프라인에 유용한 특성들입니다.

운영 비용도 마찬가지로 분명합니다. Java 배포본과 큰 Spring 설정, 로컬 크롤에서 시간을 지배한 호스트별 지연 설정, 그리고 추가 히스토리 프로세서가 필요한 content-digest dedup. WARC 충실도가 필요한 팀은 이 비용을 감수할 수 있고, 추출된 필드가 필요한 팀은 다른 범주에서 시작해야 합니다.

운영 크롤 전에 dedup 체인, politeness 설정, scope, robots 정책, 운영자 신원, 저장 가정을 실제 작업 설정과 대조해 확인하세요. 기본 프로필은 출발점일 뿐, 이러한 운영 선택을 암묵적으로 대신해 주지는 않습니다.

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

자주 묻는 질문

operatorContactUrl이 크롤을 승인된 것으로 만들어 주나요? 아니요. 작업에 연락 가능한 URL을 포함하게 만들어 사이트 운영자가 책임 추적 경로를 갖게 할 뿐, 허가, 신원 정확성, 저작권 상태, 규제 준수를 보장하지는 않습니다. 이 부분은 모두 크롤러 밖의 배포 결정입니다.

content-digest deduplication이 원본 서버 요청 수를 줄이나요? 이번 테스트 구성에서는 그렇지 않았습니다. 두 URL은 각 페이로드 다이제스트를 비교하기 전에 모두 가져와졌습니다. 히스토리 체인은 두 번째 페이로드가 WARC 저장에서 어떻게 표현되는지만 바꿨고, 두 번째 URL을 네트워크 요청 생략으로 바꾸지는 않았습니다.

Heritrix는 웹 UI 없이 실행할 수 있나요? 네. 이번 테스트의 수명 주기 — 생성, 설정 업로드, 빌드, 실행, 일시정지 해제, 폴링, 종료, 정리 — 는 모두 curl을 사용한 REST API로 처리됐습니다. 내장 Jetty UI는 필요하지 않았습니다.

기본 Heritrix 프로필은 동일 페이로드를 dedup하나요? 이번 테스트 구성에서는 그렇지 않았습니다. 기본 프로필은 동일한 두 응답을 모두 전체 response 레코드로 저장했습니다. content-digest history 체인을 추가하자 두 번째 캡처가 revisit 레코드로 바뀌었습니다. 즉, dedup은 자동 기본값이 아니라 직접 설정하고 검증해야 하는 파이프라인 선택입니다.

politeness 지연은 어떻게 정해야 하나요? 여기 나온 로컬 타이밍은 메커니즘 확인용으로 보아야지, 운영 권고로 보면 안 됩니다. 대상 사이트 규칙, 운영자 합의, 서버 용량, 크롤 목적, 그리고 자신의 재시도/동시성 정책을 기준으로 지연을 정한 뒤, 로그에서 실제 같은 호스트 요청 간격을 확인하세요.