Claude를 사용하여 웹 스크래퍼를 구축할 때 참고해야 할 컨텍스트

만약 Claude를 사용해서 웹 스크래퍼를 만들고 있다면, Playwright 코드를 또 800줄 쓰게 하기 전에 이 컨텍스트를 먼저 제공해 주세요.

흥미롭게 파고들 만한 몇 가지 주제들이 있습니다:

HAR diffing
두 개의 네트워크 세션을 캡처하고, 그 사이에 단 하나의 변수만 변경한 뒤 Claude에게 요청 본문(request bodies), 매개변수(parameters), 응답 구조(response structures), 그리고 의존성 순서(dependency order)를 비교하게 하세요.
이것을 검색, 필터링, 페이지네이션 등 여러 상황에 걸쳐 반복할 수 있습니다.
이렇게 하면 브라우저를 통해 모든 상호작용을 자동화하지 않고도 근본적인 쿼리 모델(query model)을 조립해 나갈 수 있습니다.

AST 분석 (Abstract Syntax Tree analysis)
40,000줄에 달하는 컴파일된 JavaScript 코드를 수동으로 파헤치는 대신, Babel이나 Acorn을 사용하여 관련 번들(bundles)을 추상 구문 트리(abstract syntax tree)로 파싱하게 하세요.
요청 생성자(request constructors), 공유 API 클라이언트(shared API clients), 페이지네이션 핸들러(pagination handlers), 응답 변환(response transformations) 등을 추적하세요. Claude에게 발견한 내용을 HAR 캡처와 상호 연관시키도록 요청해 보세요.

소스맵 (source maps)
sourcesContent를 포함하는 노출된 .js.map 파일을 확인하세요.
빌드 설정에 따라 이 파일들은 원래의 읽기 쉬운 프론트엔드 소스(frontend source) 일부를 재구성할 수 있습니다.
복구한 모듈들을 네트워크 캡처와 함께 Claude에게 제공하고, API 클라이언트, 필드 변환, 애플리케이션 상태 매핑을 하도록 요청하세요.

최소화(minification) ≠ 암호화(encryption).

하이드레이션 페이로드 (hydration payloads)
초기 HTML에서 __NEXT_DATA__, Nuxt 페이로드, 그리고 React Server Component의 플라이트 데이터(flight data)를 검사하세요.
일부 프레임워크는 애플리케이션 상태를 초기 문서에 직렬화(serialize)하므로, 찾고 있는 기록들이 클라이언트 측 하이드레이션(client-side hydration)이 시작되기 전에도 이미 존재할 수 있습니다.
Claude에게 이러한 데이터를 이후의 네트워크 응답과 비교하게 하세요.

스키마 추론 (schema inference)
20~30개의 서로 다른 JSON 응답을 캡처하세요. 검색, 기록 유형, 필터 등 다양해야 합니다.
Claude가 유니온 스키마(union schema)를 생성하고, 선택적 필드(optional fields), 중첩 속성(nested attributes), 일관되지 않은 타입(inconsistent types), 그리고 null 동작 방식을 식별하게 하세요.
가장 피하고 싶은 것은 처음 100개 기록에서는 완벽하게 작동하지만 다음 백만 개 기록에서는 유용한 속성을 조용히 누락시키는 추출기(extractor)입니다.

응답 변환 (response transformations)

실제 UI에 표시되는 기록과 비교하여 원본 서버 응답을 비교하세요.

프론트엔드 코드는 렌더링 전에 객체를 병합하거나, 속성 이름을 변경하거나, 추가 값을 계산하거나, 필드를 완전히 폐기할 수 있습니다.

Claude에게 이러한 변환 과정을 재구성하고 원래의 응답 필드에 매핑하도록 하세요.

때로는 인터페이스가 서버가 실제로 반환한 것보다 훨씬 적은 정보를 보여줄 때도 있습니다.

증분적 획득(incremental acquisition)

ETags, Last-Modified, 업데이트 타임스탬프, 안정 식별자 및 콘텐츠 해싱을 확인하세요.

이러한 방법들은 지원되는 경우, 매번 실행할 때마다 동일한 데이터셋을 수집하고 처리하는 대신 실제로 어떤 기록이 변경되었는지 식별하는 데 도움이 될 수 있습니다.

특히 백만 개의 기록을 다루고 반복적인 새로 고침 작업을 할 때는 더욱 흥미합니다.

데이터 조정(data reconciliation)

여러 출처에서 샘플을 가져와 Claude에게 표준 스키마를 구성하도록 하세요.

회사 도메인과 식별자를 정규화하고, 타임스탬프를 비교하며, 필드 수준의 출처(provenance)를 보존하고, 정보가 충돌하는 경우 신뢰도 점수를 할당하세요.

또한 이름만으로 회사 중복 제거를 멈춰주세요. Apex Solutions라는 이름의 관련 없는 14개 사업체를 하나의 개체로 병합할 것입니다.

추출 관찰 가능성(extraction observability)

Claude에게 스키마 드리프트, 비정상적인 null 비율, 예상치 못한 페이지네이션 동작, 중복 증가 및 기록 수의 갑작스러운 변화에 대한 검사 기능을 구축하도록 하세요.

스크래퍼가 충돌하는 것은 아무것도 아닙니다.

3주 동안 성공적으로 실행되면서 조용히 불완전한 데이터셋을 생성하는 스크래퍼가 훨씬 더 비싼 문제입니다.

또한 성공적인 종료 코드에 의존하기보다는 매 획득 후에 작은 검증 보고서를 생성하도록 하는 것도 가치가 있습니다.

스크래핑에는 브라우저가 버튼을 클릭하는 것보다 훨씬 많은 것이 있습니다.

자동화하기 전에 데이터 파이프라인을 이해하세요.[image: https://pbs.twimg.com/media/HTwrfg7WAAARao7.jpg}