6. 따라 해보고 싶으시면 — 가장 작은 형태부터
전체 수 집기를 옮길 필요는 없습니다. 원리만 확인하는 가장 작은 형태는 이렇습니다.
대상 커뮤니티가 어떤 주소로 데이터를 받아오는지 봅니다. 브라우저에서 글 하나를 열고, 개발자 도구의 네트워크 탭에서 가장 크거나 자주 불리는 요청 주소를 찾습니다.
그 주소가 방문자 토큰을 허용하는지 시험합니다. 로그인 없이 커뮤니티 식별자만으로 토큰을 주는 조회가 있는지 확인합니다.
목록 조회 한 번에 본문까지 딸려 오는지 봅니다. 딸려 온다면 페이지를 통째로 받을 이유가 사라집니다.
수집한 총수를, 그 조회가 알려주는 전체 개수와 맞춰봅니다. 두 숫자가 어긋나면 무언가를 빠뜨린 것입니다.
작게 확인한 뒤, 되면 배치를 키우고 안 되면 거기서 멈춥니다.
7. 판정은 네 가지로 나누십시오 (두 가지로는 부족합니다)
수집이 "됐다/안 됐다"로 끝나면, 판정 불가가 조용히 "됐다"로 넘어갑니다. 네 단으로 나누면 그 사고를 막습니다.
PASS 수집 총수 = 플랫폼 신고 총수 = 독립 열거치, 세 값이 일치
PASS_WITH_NOTE 값은 일치하나 범위 한정 (예: 공개 글로 범위 한정 후 일치)
HOLD 차이가 있으나 원인을 확정 못 함 (예: 댓글 4건 · 삭제 추정)
FAIL 총수가 어긋나고 빠진 자리를 특정이 시리즈의 수집은 글이 PASS, 댓글이 PASS_WITH_NOTE 에 네 건의 HOLD 를 답니다.
8. 한계와 대가 (얻은 것 옆에 잃은 것)
빠르고 가벼워진 대신 분명히 잃은 것이 있습니다.
방문자 토큰은 공개 글만 봅니다. 비공개 글, 삭제된 글, 회원 전용 영역은 이 통로로 애초에 조회 범위 밖입니다. 그러니 이 수집은 "커뮤니티 전체"가 아니라 "커뮤니티의 공개 표면 전체"입니다. 이 구분을 흐리면 산출물이 실제보다 넓어 보입니다.
토큰은 네 시간마다 만료되어, 긴 수집은 재발급을 견뎌야 합니다. 이번에는 12.5분이라 문제가 없었지만, 더 큰 커뮤니티라면 재발급 중 끊김을 다루는 비용이 붙습니다.
그리고 첫 설계를 버렸습니다. 사이트맵으로 주소를 모아 페이지를 통째로 받는 21기가바이트 경로를 처음에 절반쯤 만들었다가 버렸습니다. 페이지의 96퍼센트가 화면용 데이터라는 것을 실측하고 나서였습니다. 버린 코드가 아깝지 않았던 것은, 버리는 근거를 숫자로 쥐고 있었기 때문입니다.
한 가지 더 자랑하지 않겠습니다. 토큰이 만료돼도 사람 개입 없이 스스로 재발급받는 자동 갱신은 설계까지만 했고 긴 수집으로 검증하지는 못했습니다. 짧은 수집에서는 발동할 일이 없었기 때문입니다. 이 부분은 미실행으로 남깁니다.
9. 결론 — 가져가실 규칙 세 개
첫째, "안 된다"는 결론은 문 하나에 대한 것일 수 있습니다. 게시가 막힌 것을 열람도 막혔다고 함께 묶으면, 열려 있는 문 앞에서 돌아섭니다. 막힌 것이 정확히 무엇인지 다시 물으면 다른 문이 보입니다.
둘째, 무거운 페이지를 받기 전에 그 무게가 어디서 오는지 보십시오. 화면을 그리는 데이터와 실제 내용은 다른 통로로 옵니다. 내용만 주는 통로가 있으면 페이지를 통째로 받을 이유가 없습니다.
셋째, 수집이 옳은지는 수집기 밖에서 확인하십시오. 수집기가 "다 받았다"고 말하는 것과, 서로 다른 두 경로가 같은 총수를 내는 것은 다른 무게의 증거입니다. 후자만이 빠뜨린 글이 없다는 것을 말해줍니다. 이번 수집에서 조용히 데이터를 깎던 세 곳 — 댓글 트리 22퍼센트 누락, 100건에서 잘리던 댓글, 본문 0자 693건 — 은 모두 총수를 맞춰보는 과정에서 드러났습니다. 수를 세지 않았다면 셋 다 그럴듯한 결과 속에 묻혔을 것입니다.
지식베이스는 채우는 속도보다 채운 것이 원본과 같다는 확신이 먼저입니다. 그 확신은 수집기의 보고가 아니라, 수집기 밖의 독립된 숫자에서 옵니다.
10. 참고
이 글에서 자격증명 없이 열린 열람 통로는 커뮤니티가 방문자에게 제공하는 정상 기능이며, 공개된 글만을 대상으 로 합니다. 수집 총수를 두 경로로 교차 검증하는 방식은 데이터 파이프라인에서 흔히 쓰는 조정(reconciliation)의 작은 형태입니다.
