북마크릿으로 페이지 전환과 수집해보자

북마크릿으로 페이지 전환과 수집해보자

SPA에서 다음 페이지로 이동해도 URL이 바뀔 뿐 실제 페이지 로드가 없었다. document.addEventListener('DOMContentLoaded')는 작동하지 않았다. history.pushState를 직접 감시해야 했다.

1. 서론 (Introduction)

• 문제/상황 (Problem): SPA는 <a href> 클릭 시 URL만 바뀌고 JavaScript가 DOM을 업데이트한다. 전통적인 페이지 로드 이벤트가 발생하지 않아 수집 트리거가 작동하지 않았다.
• 목적 (Purpose): SPA에서 페이지 전환을 감지하고, URL이 바뀔 때마다 수집 신호를 서버로 보내는 구조를 만든다.
• 대상 (Target Audience): SPA 사이트 수집에서 페이지 전환 감지에 막힌 개발자.

2. 방법 및 과정 (Methods & Process)

• 배경 조사 및 데이터 (Data Collection): SPA는 history.pushState, history.replaceState로 URL을 바꾼다. 이 두 메서드는 기본적으로 이벤트를 발생시키지 않는다. 원본 메서드를 래핑해서 호출될 때마다 커스텀 이벤트를 발생시키면 URL 변경을 감지할 수 있고, 이후 window.addEventListener('locationchange', handler)로 구독할 수 있다.
• 접근 방법 (Approach Methods):
  • [방법 1]: History API 몽키패치. history.pushState와 history.replaceState를 원본 함수를 감싸는 래퍼로 교체해, 호출될 때마다 locationchange 커스텀 이벤트를 window에 dispatch한다.
  • [방법 2]: 전환 감지 후 Beacon 전송. locationchange 리스너 안에서 현재 URL과 타임스탬프를 navigator.sendBeacon으로 서버에 즉시 전송해, 클릭마다 별도 트리거 없이 전환 이력이 쌓이게 한다.
• 분석 및 해결 프로세스 (Analysis Flow):
  • 도구/기술: 북마크릿 JS 문자열, 파이썬 쪽 정적 구조 검증 스크립트.
  • 주요 단계: history.pushState/replaceState 래핑 $\rightarrow$ locationchange 이벤트 발생 $\rightarrow$ 리스너에서 URL·타임스탬프 수집 $\rightarrow$ Beacon으로 서버 전송.
  • 결과 도출 및 검증: 북마크릿 JS 문자열에 history.pushState, history.replaceState, dispatchEvent, addEventListener, sendBeacon 다섯 개 필수 API 호출이 모두 포함됐는지, 괄호 짝이 맞는지 파이썬 쪽에서 정적 검사한 결과 누락 없이 통과했다.

3. 결과 (Results)

• 분석 결과 요약: SPA 사이트에서 URL이 바뀔 때마다 locationchange 이벤트가 발생해 수집 트리거로 쓸 수 있음을 확인했다. DOMContentLoaded에 의존하던 기존 방식과 달리 History API 래핑은 전통적인 페이지 로드 없이도 전환을 잡아냈다. 북마크릿 문자열의 필수 API 포함 여부를 정적 검사로 사전에 확인할 수 있었다.

4. 인사이트 및 액션 (Insights & Action)

• 인사이트 (Insight): SPA는 URL이 바뀌는 순간과 실제 콘텐츠가 갱신되는 순간이 분리되어 있다. History API 래핑은 “URL이 바뀐 순간”을 잡는 것이지 “콘텐츠가 다 그려진 순간”을 보장하지 않는다는 점을 구분해야 한다.
• 실행 방안 (Action Plan): Beacon 전송 시점과 실제 DOM 갱신 시점 사이에 지연이 있을 수 있으므로, 수집 대상 데이터가 URL만으로 충분한지 아니면 렌더링된 본문까지 필요한지에 따라 전송 시점을 조정해야 한다.
• 한 줄 결론 (Key Takeaway): SPA 수집의 핵심은 URL 변경 시점을 잡는 History API 래핑이다. 샘플 코드
• 다음 스텝 (Next Step): 이번 구현은 URL 변경 시점에만 반응한다. 콘텐츠가 비동기로 늦게 그려지는 페이지에서는 DOM 변경 자체를 감시하는 별도 관찰자를 조합해야 렌더링 완료 시점까지 정확히 잡을 수 있다.

---