수집 대상 사이트가 무한 스크롤이라 목록을 다 가져오려면 계속 스크롤을 해야 했다. 그래서 브라우저를 띄우는 수밖에 없다고 보고 그 전제로 설계를 시작했다.
Table of contents
Open Table of contents
직렬화라는 최대 제약
브라우저로 수집할 때의 가장 큰 문제는 직렬화였다. 한 세션에서 한 페이지씩 열어야 하므로 여러 대상을 동시에 처리할 수가 없다.
대상과 분류를 곱하면 조합이 열여덟 개인데 그것을 전부 하나씩 순서대로 해야 했다. 이 직렬화가 이 설계에서 가장 큰 제약이었다.
관찰이 찾은 내부 API
브라우저를 띄우고 실제로 스크롤을 유발하면서 나가는 네트워크 요청을 관찰했다. 화면의 항목이 20건씩 늘어날 때마다 내부 API를 부르고 있는 것이 보였다.
채널과 분류와 마지막 항목 식별자를 넘기는 커서 페이지네이션이었다. 페이지만 열었으면 초기 요청만 보였을 것이므로 동작을 유발한 것이 이 발견의 조건이었다.
봉투 안의 조각
그 응답을 열어 보니 JSON 봉투 안에 HTML 조각이 들어 있는 형태였다. 순수 JSON은 아니지만 봉투를 벗기고 안의 조각을 파싱하면 되는 구조였다.
이것으로 목록 수집을 브라우저 없이 HTTP 요청만으로 할 수 있게 됐다. 브라우저 세션 하나로 열여덟 조합을 직렬 처리하던 것이 요청 열여덟 개를 병렬로 보내는 것이 됐고 브라우저는 쿠키 공급원으로만 남았다.
같이 나온 부가 API
같은 관찰에서 유료 콘텐츠 권한 조회와 댓글 수 조회 API도 함께 나왔다. 그중 앞의 것이 특히 유용했는데 화면에 뜨는 잠금 표시의 실체였기 때문이다.
문서 객체 통계로 판정하던 것을 API로 직접 얻을 수 있게 됐다. 관찰 한 번에서 목록 수집과 잠금 판정 둘 다 나온 셈이다.
성격이 다른 문서
수집하는 중에 한 대상의 글이 성격이 다르다는 것을 발견했다. 일반 글이 항목 하나에 8천 자 정도인데 그 대상은 항목이 열셋에 3만 자가 넘고 표가 여럿이었다.
한 항목이 한 요약이라는 파이프라인에 안 맞으므로 별도 처리 경로가 필요하다고 적었다. 표를 단순 텍스트로 뽑으면 행과 열이 뭉개지므로 구조를 살려 변환해야 하고 매 글에 반복되는 면책 조항과 채널 소개는 요약 입력에서 빼야 한다. 관찰 한 번이 브라우저를 띄워야 한다는 제약을 없애면서 아키텍처를 바꿨다.
정리
- 무한 스크롤은 내부 API를 쓰므로 요청을 관찰하면 찾을 수 있다
- 동작을 유발해야 추가 요청이 보인다
- 페이지만 열면 초기 요청만 보인다
- 응답이 봉투 안 조각이어도 파싱할 수 있다
- 브라우저를 빼면 직렬화 제약이 사라진다
- 관찰에서 부가 API도 나와 화면 판정을 대체한다
- 문서 성격이 다르면 별도 처리 경로가 필요하다
- 표는 구조를 살려 변환하고 반복 문구는 입력에서 뺀다