3편에서 네이버 크롤링의 딜레이+백오프가 막힘 자체는 해결했지만 속도가 너무 느리다는 걸 확인했다. 재시도가 항상 성공한다는 게 오히려 답답했다 — 매번 5초씩 확실히 걸리니까. 그 실험이 진행되던 중, 완전히 다른 방향의 아이디어가 나왔다.
프록시로 집 IP를 쓰면 어떨까 — 네이버 크롤링 IP 차단 우회
이 VPS 말고, 집에 있는 PC의 회선(주거용 IP)을 우회 경로로 쓰면 어떻겠냐는 제안이었다. 마침 이 회선은 다른 프로젝트의 크롤러가 SSH 터널로 이미 연결해서 쓰고 있던 것이었다 — VPS IP가 어떤 사이트에 막혔을 때 우회하는 용도로.
즉석에서 비교해봤다. 정확히 같은 순간에, VPS는 여전히 403 백오프를 도는 중인데, 그 집 프록시로 똑같은 검색 쿼리를 던지니 2.16초 만에 200으로 바로 성공했다(334킬로바이트).
이건 중요한 신호였다. 네이버가 이 검색어나 이 서비스를 전면 차단한 게 아니라, VPS의 이 특정 IP가 지금 거의 소진된 상태일 뿐이라는 뜻이었다.
프록시 폴백을 코드에 붙이다
이미 다른 프로젝트에 있던 프록시 경유 요청 패턴을 그대로 가져와 붙였다. 직접 요청이 403 재시도까지 전부 소진하면, 마지막 수단으로 딱 한 번 이 집 프록시를 시도하는 구조였다.
재검증 — 그런데 프록시는 한 번도 안 쓰였다
같은 커맨드를 다시 돌렸다. 30분 동안 403이 374번 떴는데, 이번에도 전부 다시 1번째 재시도(직접, 5초 대기)에서 성공했다. 프록시 폴백은 단 한 번도 발동하지 않았다 — 직접 재시도만으로 매번 충분히 뚫렸다는 뜻이다. 진행 속도도 이전 편과 거의 같았고, 30분 동안 여전히 “로봇” 키워드 하나에만 머물러 있어서 다시 멈췄다.
재해석 — 네이버 크롤링 병목은 차단이 아니라 물량이었다
이 두 번의 실험으로 원래 질문(“차단을 어떻게 우회하나”)의 성격 자체가 달라졌다.
- 직접 재시도(5초 대기)만으로도 사실상 항상 뚫린다 — 진짜 장기 차단이 아니라, 요청 하나하나에 아주 짧은 쿨다운만 있으면 통과되는 수준의 약한 rate-limit으로 보였다.
- 그래서 프록시가 아직 한 번도 필요하지 않았다 — 폴백 코드 자체가 나쁜 게 아니라, 지금까지의 조건에서 발동할 상황 자체가 안 생긴 것이다.
- 진짜 병목은 “로봇” 같은 초고빈도 키워드의 순수 페이지 물량이었다 — 날짜구간 하나당 캡(2,000건)까지 채우면 200페이지, 페이지마다 사실상 5초 이상 걸리니 키워드 하나만으로도 시간이 오래 걸릴 수밖에 없었다.
요청 물량이 그렇게 많았나
이 결론을 듣고 자연스러운 질문이 하나 나왔다 — “현대차 로봇이 진짜 그렇게 많이 나오나?” 캡까지 찬 검색 결과가 정말로 그만큼 관련 기사가 많아서인지, 아니면 다른 이유가 있는지 실제 응답 내용을 직접 열어보기로 했다.
"현대차" "로봇"으로 2025년 7월 한 달치를 검색한 1페이지 10건을
전부 읽어봤다. 전부 제목이나 본문 어딘가에 두 단어를 포함하긴
했다 — 네이버의 AND 매칭 자체는 정상이었다. 그런데 내용을 보면
“SOL 코리아메가테크액티브 ETF, 순자산 1,000억 돌파”, “[한미 관세
타결] 몸푸는 삼성·SK·현대차 전략은?” 같은 증시 다이제스트나 ETF
구성종목 나열 기사뿐이었다. “현대차가 로봇을 만든다”는 진짜 주제
기사는 10개 중 딱 1개(“현대차, CES2026서 ‘휴머노이드로봇’ 첫
공개”)뿐이었다.
돌이켜보면 이건 이미 알고 있던 패턴이었다. 이 파이프라인의 가이드 문서에는 “회사명과 키워드가 각자 다른 맥락으로 등장하는 것(종합 뉴스 다이제스트, 실적/증시 코멘트 기사)은 해당하지 않는다”는 설명이 이미 적혀 있었다. 원래 이런 노이즈는 뒤에 있는 LLM 분류 단계에서 걸러지도록 설계돼 있었던 것이다 — 다만 그 노이즈까지 전부 페이지네이션 캡까지 가져오느라 시간을 쓰고 있었을 뿐이었다.
field=1로 물량 자체를 줄이다 — 네이버 뉴스 검색 API 제목 검색
네이버 뉴스 검색이 UI에서 지원하는 “제목만 검색” 옵션을 URL 파라미터로 직접 시도해봤다(공식 문서화가 안 된 값이라 실측으로 확인). 같은 쿼리, 같은 기간으로 비교하니 결과가 확연히 달랐다 — 이 파라미터 없이는 여전히 ETF나 다이제스트 위주였는데, 이 파라미터를 붙이니 “현대차, CES2026서 ‘휴머노이드로봇’ 첫 공개”, “로봇이 미래…현대차그룹, 보스턴 다이내믹스에 1조 투자” 같은, 전부 진짜 관련 기사만 나왔다.
실제 총 건수도 극적으로 줄었다. 같은 조건으로 끝까지 페이지네이션해보니, 이 파라미터 없이는 캡(2,000건, 사실상 노이즈로 가득)까지 채워지던 게, 붙이고 나니 실제 227건에서 자연스럽게 끝났다 — 88퍼센트 감소였다.
이걸 코드에 반영했다. 페이지 수가 대폭 줄어드니, 실행 시간뿐 아니라 403에 노출되는 빈도(요청 수 자체가 줄어드니)와 뒤에서 LLM이 걸러내야 할 노이즈까지 셋 다 같이 줄어드는 효과가 있었다.
남는 생각
프록시라는 우회로를 만들어놓고, 정작 그 우회로는 한 번도 안 쓰였다. 대신 그 과정에서 나온 질문(“정말 그렇게 많이 나오나?”) 하나가 진짜 병목을 찾아냈다. 문제를 해결하는 방법을 고민하는 것과, 문제 자체가 진짜 어디에 있는지를 다시 확인하는 것은 다른 작업이다. 이번엔 후자가 훨씬 더 큰 걸 가져다줬다 — 차단을 우회할 방법이 아니라, 애초에 그렇게까지 많이 요청할 필요가 없었다는 것.