1편에서 세 번의 통제 실험이 전부 무차단으로 끝나면서, 남은 후보는 네이버 뉴스 크롤링 파이프라인의 실전 사고와 똑같은 조건(동시성 10, 딜레이 없음)뿐이었다. 그런데 그 실험을 준비하기 전에, 전혀 다른 방향의 질문이 나왔다.
”403이었다”는 전제부터 의심하다 — 네이버 크롤링 차단 원인 재검증
“문제 정의를 잘못하고 있는 거 아니냐”는 질문이었다. 지금까지 계속 “403으로 막혔다”는 걸 전제로 실험을 설계해왔는데, 그 전제 자체를 원본 증거로 확인한 적이 있었나 되짚어봤다.
없었다.
실전 사고 당시 결과가 무너진 것 자체는 확실했다 — 정상 실행이면 30여 메가바이트가 나와야 할 출력 폴더가, 그 실행에서는 몇십 바이트 ~ 20킬로바이트 수준이었고, 회사별 리포트 파일 하나는 “수집된 기사 정보 없음”이라고 적혀 있었다. 하지만 그 실행의 실제 stderr 로그는 디스크 어디에도 남아있지 않았다. 근거는 딱 하나, 그날 남긴 커밋 메시지뿐이었는데, 그 메시지조차 “rate-limit/backoff 없음이 원인으로 추정”이라고 스스로 헤지하고 있었다. 그날도 확정이 아니라 추정이었던 것이다.
게다가 1~3편에서 한 실험은 전부 새로 짠 별도 진단 스크립트였다. 실제 파이프라인 코드는 한 번도 직접 돌려본 적이 없었다.
실제 파이프라인으로 재현해보니
진단 전용 가이드를 하나 만들었다. 실전 가이드에서 삼성전자(키워드 12개), 현대자동차(키워드 26개) 딱 두 타깃만 그대로 복사한 것. 이걸 실제 운영 커맨드로 돌렸다.
이번엔 진짜 403이 원본 로그로 확인됐다. 그것도 이 프로세스의 첫 번째 요청부터였다. 점진적으로 막힌 게 아니라, 시작하자마자 이미 막혀있는 상태였다 — 로그 95줄이 전부 403이었고, 두 타깃의 38개 키워드를 여러 날짜 구간에 걸쳐 훑는 동안 단 한 건도 성공하지 못한 채 매번 즉시 실패했다.
그런데 몇 분 뒤 손으로 재현하니 멀쩡했다
파이프라인 프로세스를 죽인 직후, 정확히 같은 조건을 최소 단위로 다시 만들어봤다.
- 단발 요청 1건(같은 User-Agent, 같은 엔드포인트, 다른 날짜 구간): 성공.
- 동시 요청 2건(파이프라인이 시작하던 순간과 똑같이 — 삼성전자 키워드와 현대차 키워드를 정확히 동시에, 같은 날짜 구간까지 그대로): 둘 다 성공.
파이프라인을 실패시켰던 것과 완전히 같은 조건(동시 2개, 서로 다른 쿼리, 같은 날짜 구간)을 몇 분 뒤 그대로 재현했는데, 아무 문제가 없었다.
재해석 — 패턴이 아니라 그 순간의 누적 상태
이 결과는 “동시성 2가 트리거다” 같은 단순한 설명과 안 맞는다. 방금 그 조건 자체를 재현해서 반증한 셈이니까. 대신 훨씬 설득력 있는 설명이 떠올랐다.
차단이 “이 요청의 패턴” 때문이 아니라 “이 시점의 누적 상태” 때문이었을 가능성. 어떤 시간창(분 단위인지 시간 단위인지는 모른다) 안의 누적 요청량이 임계값을 넘으면 일정 시간 그 IP를 막고, 시간이 지나면 자동으로 풀리는 rate-limit이라는 가설이다. 그날 1~3편의 실험만으로 이미 900건 가까이 이 IP로 요청을 보낸 상태였고, 마지막 실험이 끝난 지 80분 뒤 파이프라인을 돌렸는데 그 시점엔 막혀 있었고, 다시 몇 분 뒤엔 풀려 있었다 — 누적량이 임계값을 넘겨 일시적으로 막혔다가, 시간이 지나 다시 풀렸다는 그림과 앞뒤가 맞는다.
이 해석이 맞다면, 애초의 실전 사고(21개 타깃, 수천 건의 요청이 짧은 시간에 집중)도 “동시성 10이라서”가 아니라 “짧은 시간 안에 너무 많은 총 요청을 보내서 시간창 기반 rate-limit에 걸렸다”는 쪽으로 다시 읽는 게 더 앞뒤가 맞는다. 순수 동시성이나 딜레이 유무보다, 일정 시간 안의 총 요청 수가 진짜 변수일 가능성이 높아진 것이다.
물론 아직 확정은 아니었다. 정확한 시간창 크기와 임계값은 여전히 몰랐고, 이날의 결론 자체도 “이미 하루 종일 실험해서 IP가 어느 정도 지쳐있는 상태”라는 조건 위에서 나온 것일 수 있었다. 완전히 깨끗한 IP로 처음부터 다시 테스트해야 확실해질 문제였다. 다만 이 가설이 맞다면 실무적으로 중요한 결론이 하나 따라 나온다 — 동시성 제한이나 요청 딜레이보다, “일정 시간 안의 총 요청 수를 제한하는 글로벌 레이트 리미터”와 “403이 뜨면 일정 시간 대기 후 재시도하는 백오프”가 더 맞는 방향일 수 있다는 것.
남는 생각
“동시성 10만 재현하면 끝날 것”이라고 생각했던 다음 실험은, 결국 하지 않았다. 그 대신 “우리가 겪은 게 정확히 뭐였지”라는 질문 하나가 실험 설계 전체를 다시 짜게 만들었다. 지금까지 세운 모든 가설이 “403으로 막혔다”는 전제 위에 있었는데, 그 전제 자체가 원본 증거 없이 3일 전 헤지된 커밋 메시지 하나에 의존하고 있었다는 걸 그제야 알았다. 실험을 더 정교하게 설계하는 것보다, 가끔은 지금까지 당연하게 여겨온 전제 자체를 다시 확인하는 게 먼저다.