크롤러 개발자의 본능은 속도입니다. 더 빨리 수집하면 더 빨리 끝나니까요. 그런데 장기 운영을 전제로 하면 이 본능은 정확히 거꾸로입니다. 빠른 수집은 대상 서버에 부담을 주고 부담은 차단으로 돌아오며 차단된 크롤러의 수집 속도는 0입니다. 야구 데이터 수집기를 만들며 우리가 설계한 것은 "얼마나 빨리"가 아니라 "얼마나 적절히"였습니다. 수집 속도 페이싱의 설계 요소들을 정리합니다.
수집 속도 페이싱의 기준: 사람의 열람
페이싱의 기준선은 명확합니다. 사람이 그 사이트를 열람하는 속도보다 서버에 부담을 덜 줄 것. 사람은 페이지를 읽는 데 수 초에서 수십 초를 쓰고 하루에 수백 페이지를 넘기지 않습니다. 크롤러가 이 범위 안에 있다면 서버 입장에서 특별한 부하가 아닙니다.
이 기준은 윤리이자 실리입니다. 공개 데이터를 수집하더라도 상대 서버의 자원을 쓰는 것은 사실이고 과한 요청은 차단·법적 시비·서비스 저하라는 형태로 되돌아옵니다. 오래 수집하고 싶다면 조용히 수집해야 합니다.
요소 1: 지연 배수와 하한 강제
우리 수집기는 요청 간 지연을 배수(multiplier)로 설정합니다. 기본 동선의 지연 시간에 사용자가 배수를 곱해 조절하는 방식인데, 중요한 것은 하한입니다. 설정 화면에서 아무리 내려도 최소 배수 아래로는 내려가지 않게 강제했습니다.
하한을 코드로 강제한 이유는 운영 현실 때문입니다. 수집이 느리다고 느끼는 사용자는 언젠가 지연을 0으로 만들고 그 순간 계정과 수집기 전체가 위험해집니다. "빠르게 설정할 수 없는" 도구가 사용자를 보호합니다. 반대로 대상 사이트가 민감하게 반응하는 시기에는 배수를 올려 더 조심스럽게 다닐 수 있습니다.
요소 2: 작업 단위 사이의 쿨다운
요청 간 지연만으로는 부족합니다. 한 경기 분량의 수집은 수십 페이지의 연속 접근이라, 경기 다섯 개를 연달아 돌리면 사이트 입장에서는 꽤 긴 세션이 됩니다. 그래서 작업 단위(경기와 경기) 사이에 삼십 분의 쿨다운을 두었습니다. 하루 다섯 경기의 일괄 수집이 두 시간 넘게 걸리는 설계인데, 어차피 분석은 저녁 경기 전까지만 끝나면 되므로 사용자에게는 비용이 아닙니다.
쿨다운은 페이싱을 "요청 간격"에서 "세션 패턴" 수준으로 끌어올립니다. 짧은 접근 뭉치와 긴 휴지의 반복은 사람의 이용 패턴과 닮아 있고 서버 부하 관점에서도 훨씬 순합니다.
요소 3: 가장 좋은 요청은 안 보내는 요청
페이싱의 다음 단계는 요청 자체를 줄이는 것입니다.
- 세션 재사용: 로그인이 필요한 사이트에서 매 실행마다 로그인하면 인증 요청이 반복됩니다. 우리는 로그인 세션 쿠키를 보존해 유효 기간(한 달 남짓) 동안 재사용했습니다. 로그인 화면을 다시 볼 일이 없으니 요청도 줄고, 인증 실패 리스크도 줄었습니다.
- 가벼운 경로 우선: 화면 렌더링 없이 데이터를 주는 JSON 엔드포인트가 있으면 그쪽을 씁니다. 같은 정보를 얻는 데 드는 요청 수와 전송량이 몇 분의 일이 됩니다.
- 실행 단위 캐시: 한 실행 안에서 같은 정보(선수 상세 등)가 여러 번 필요하면 첫 조회를 캐시해 재사용합니다.
| 페이싱 요소 | 장치 | 효과 |
|---|---|---|
| 요청 간격 | 지연 배수 + 하한 강제 | 순간 부하 억제, 실수 방지 |
| 세션 패턴 | 작업 간 쿨다운 | 사람과 닮은 이용 리듬 |
| 요청 총량 | 세션 재사용 · 경량 경로 · 캐시 | 부하와 노출 자체를 축소 |
실패했을 때: 물러서고, 포기한다
페이싱의 마지막 조각은 실패 대응입니다. 요청이 실패했을 때 즉시 재시도하는 것은 부하를 더하는 일입니다. 우리는 짧은 재시도 후에도 실패하면 해당 항목을 건너뛰고 다음으로 넘어가게 했습니다. 전체 수집이 한 항목에 매달려 요청을 반복하는 것보다, 빠진 항목을 기록하고 완주하는 쪽이 데이터와 서버 모두에 낫습니다. 이 실패 격리와 재시도 백오프의 일반론은 대규모 크롤러 운영 안정성에서 자세히 다룹니다.
이 페이싱 설계가 적용된 수집기의 전체 그림은 야구 데이터 수집 자동화 사례에서, 수집 방식 선택의 전략은 스포츠 데이터 크롤링에서 볼 수 있습니다.
자주 묻는 질문
수집 속도는 어느 정도가 적당한가요?
사이트가 명시한 정책이 있으면 그것이 기준이고 없다면 사람의 열람 속도보다 완만하게 잡는 것이 안전합니다. 요청 간 수 초 이상의 지연, 작업 뭉치 사이의 긴 휴지, 하루 총량의 상한을 함께 설계하면 장기 운영에서 문제가 생길 확률이 크게 줄어듭니다.
수집이 너무 오래 걸리면 어떻게 하나요?
속도를 올리기 전에 요청 총량을 줄일 방법부터 찾는 것이 순서입니다. 세션 재사용, JSON 엔드포인트 직접 호출, 실행 내 캐시로 같은 데이터를 더 적은 요청으로 얻을 수 있는 경우가 많습니다. 그래도 오래 걸린다면 수집 시간대를 사용 목적에 맞춰 앞당기는 운영적 해법이 속도 인상보다 안전합니다.
페이싱 설정을 사용자에게 열어 줘도 되나요?
열어 주되 하한을 강제하는 것을 권합니다. 도구를 오래 쓰다 보면 지연을 줄이고 싶은 유혹이 생기는데, 과속의 대가(차단·계정 제재)는 사용자가 감당하기 어렵습니다. "안전 범위 안에서만 조절되는" 설정이 사용자와 도구를 함께 지킵니다.