클래스명이나 부모 구조가 조금 바뀐 경우 Scrapling이 이전 요소의 DOM 지문으로 새 위치를 찾을 수 있지만, 사이트가 크게 개편되면 엉뚱한 데이터를 조용히 수집할 수 있습니다. 자동 복구 성공률보다 false positive를 잡는 검증 규칙이 먼저입니다.
Scrapling 저장소는 정적 fetcher와 브라우저 기반 fetcher, 적응형 요소 추적을 한 프레임워크에 묶습니다. BeautifulSoup, Scrapy, Playwright를 모두 대체한다기보다 페이지 성격에 따라 가벼운 요청과 동적 렌더링을 고르는 구조입니다.
처음 정상 요소를 찾을 때 auto_save로 태그, 속성, 부모, 자식 관계와 주변 구조의 fingerprint를 저장합니다. 이후 기존 selector가 실패하면 현재 DOM에서 유사도가 높은 노드를 찾습니다. product-card가 item-box_v2로 바뀌는 정도의 수정에는 유지보수 시간을 줄일 수 있습니다.
문제는 유사도가 의미의 동일성을 보장하지 않는다는 점입니다. 추천 상품과 실제 상품 카드의 구조가 비슷하면 잘못된 쪽을 선택할 수 있습니다. 가격 범위, 필수 필드, 항목 수와 고유 ID를 후단 schema로 검사하고 갑작스러운 분포 변화에 알림을 걸어야 합니다.
fingerprint에 어떤 attribute와 주변 구조가 들어가는지 version별로 확인해야 합니다. 자동 생성 class는 자주 바뀌지만 data-product-id는 안정적일 수 있고, text는 번역, 개인화로 달라질 수 있습니다. 모든 특징을 같은 신뢰도로 보지 말고 업무상 identity를 나타내는 key를 후단에서 다시 확인합니다. Tracking state를 저장한 시점과 site version도 함께 기록합니다.
예를 들어 기존 article.product-card가 사라졌을 때 adaptive가 비슷한 article.recommend-card를 선택하면 title, price는 모두 존재해 단순 schema를 통과할 수 있습니다. URL pattern, canonical product ID, listing 영역과 항목 간 중복까지 검사해야 합니다. 이전 날 대비 상품 수, 가격 median, null 비율 변화도 오류를 조기에 찾는 신호입니다.
정적 HTML은 비동기 Fetcher로 처리하고 JavaScript 렌더링이 필요한 일부 페이지만 Dynamic, Stealthy 계열을 쓰는 것이 메모리에 유리합니다. 브라우저 바이너리를 포함하면 Docker 이미지와 시작 시간이 커지고 서버리스 제한에 걸릴 수 있습니다.
원문의 파이썬은 adaptive 흐름을 보여 주지만 실제 대상 URL, 저장 경로, 버전과 데이터 검증이 빠진 예시입니다. 타사 사이트에 그대로 실행하는 완전한 수집 절차가 아닙니다. 현재 API는 문서와 PyPI 패키지를 같은 버전으로 맞춰 확인해야 합니다.
fetcher 선택은 domain이 아니라 page type별로 정합니다. 먼저 일반 HTTP 응답에서 필요한 field가 있는지 확인하고, hydration 전 shell만 오는 URL에만 browser를 사용합니다. static 실패 때 browser fallback을 한 번 허용하되, 403, 429를 rendering 문제로 오해해 반복하지 않습니다. status, content type, response byte와 실제 field 존재를 분리해 기록합니다.
browser pool에는 동시성, page lifetime, navigation timeout과 memory 상한이 필요합니다. popup, infinite scroll과 요청이 끝나지 않는 analytics 때문에 networkidle을 무한히 기다리지 않도록 업무 완료 조건을 selector, API response로 정의합니다. 실패한 page는 같은 session을 계속 재사용하지 않고 cookie, cache가 결과를 개인화하는지도 확인합니다.
과거 DOM 스냅샷에 소규모, 대규모 변경을 만들어 selector 회복률, 잘못된 노드 선택률과 처리 시간을 측정합니다. 기존 selector가 실패하면 멈추는 정책과 adaptive가 추정값을 내는 정책의 비용을 비교해야 합니다. 금융, 가격 모니터링처럼 틀린 값이 큰 피해를 내면 자동 추정보다 fail-closed가 낫습니다.
MCP로 핵심 노드만 에이전트에 보내면 토큰을 줄일 수 있지만 잘못 찾은 노드도 더 그럴듯하게 요약될 수 있습니다. Scrapling은 깨진 selector의 후보를 찾는 도구로 유용하며, 검증 없는 자생형 크롤러로 보기는 어렵습니다.
정상 page snapshot 20~50개와 과거 layout을 모으고 class rename, wrapper 삽입, section 이동, 추천 card 추가와 전면 개편을 재생합니다. strict selector, adaptive와 사람이 갱신한 selector를 비교해 true recovery, false match, fail-closed와 처리 시간을 분류합니다. “무언가를 찾음”을 성공으로 세지 않고 정확한 entity, field가 맞아야 통과시킵니다.
변경 정도와 adaptive confidence에 따라 정책을 나눌 수 있습니다. 높은 confidence이고 ID, schema, 분포가 모두 맞으면 임시 결과로 사용하고, 핵심 selector가 새 위치로 이동하거나 confidence가 낮으면 quarantine합니다. 자동으로 새 fingerprint를 영구 저장하기 전 diff와 대표 screenshot을 review해야 한 번의 오탐이 이후 기준으로 굳지 않습니다.
운영 metric은 page success, selector fallback 비율, false-match 표본, field null, duplicate, browser 전환율, p95 시간과 request, CPU 비용입니다. 갑자기 adaptive 비율이 오르면 “자가 치유 성공”이 아니라 site 변화 경보로 취급합니다. 원본 HTML과 추출 version을 제한 기간 보존해야 잘못 수집한 값을 재처리할 수 있습니다.
수집 허용 범위도 코드와 별도 register로 관리합니다. domain owner, 이용 조건 검토일, 요청 속도, 보존 data와 삭제 경로를 기록합니다. 로그인 우회나 탐지 회피를 성공 지표로 삼지 않고 공식 API, export가 생기면 그 경로로 전환합니다. 기술적 복원력은 데이터 권리와 정확성 검토를 대신하지 않습니다.
아닙니다. 작은 DOM 변화의 후보를 찾을 수 있지만 의미가 비슷한 다른 node를 고를 수 있어 schema, ID, 분포 검증과 사람 review가 필요합니다.
중요 데이터라면 권장하지 않습니다. 낮은 confidence나 핵심 field 변경은 quarantine하고 이전 snapshot, screenshot과 비교한 뒤 승인해야 합니다.
그렇지 않습니다. memory, startup, timeout과 차단 위험이 커지므로 static HTML로 충분한 page는 가벼운 fetcher를 우선해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.