num=100 이후 대규모 SERP 모니터링

과제

순위 추적기, SEO 대시보드, 또는 경쟁 인텔리전스 도구를 구축하는 팀이라면 2026년은 단위 경제성(unit economics)이 무너진 해입니다. Google은 올해 Google Search에서 num=100 URL 매개변수를 조용히 지원 중단했습니다. 모든 SERP 스크레이퍼가 단일 요청으로 100개의 결과를 가져오는 데 사용하던 방식이었습니다. 이제 동일한 범위를 처리하려면 1개가 아닌 10개의 요청이 필요합니다.

이는 눈에 보이는 비용일 뿐입니다. 숨겨진 비용은 더 까다롭습니다.

순위 추적은 올바른 국가, 지역, 도시의 실제 검색자에게 표시되는 SERP를 확인할 수 있을 때만 유효합니다. 런던에서 4위인 키워드가 에든버러에서는 11위, 벨파스트에서는 19위일 수 있습니다. 로컬 3-팩, 쇼핑 캐러셀, 뉴스 박스, 지식 패널, AI Overview까지. 모든 SERP 기능은 지리적 위치와 기기에 따라 달라집니다. (Scrape.do의 측정에 따르면 2026년 초 기준 약 36%의 쿼리에 AI Overview 텍스트가 표시되었습니다.) 스크레이퍼가 잘못된 도시의 프록시를 통해 라우팅되면 순위 데이터는 신뢰할 수 없는 허구가 됩니다.

따라서 2026년에 경쟁력 있는 SERP 제품을 만들려면 세 가지가 함께 작동해야 합니다. 네트워크 레벨에서 실제 브라우저처럼 보이는 요청, 모니터링하려는 정확한 도시에 위치한 프록시, 그리고 Google이 결과의 절반을 클라이언트 사이드에서 로드하기로 결정했을 때 JavaScript를 렌더링하는 기능입니다. 세 가지 중 하나라도 놓치면 데이터 품질이 은밀하게 저하됩니다.

FourA의 접근 방식

대규모 SERP 스크래핑의 병목 현상은 요청 자체가 아닙니다. 라우팅입니다.

자체 구축한 대부분의 파이프라인은 고정된 프록시 풀로 시작하여 쿼리를 변수로 취급합니다. Google의 지역 타겟팅 환경에서는 그 반대여야 합니다. 쿼리는 이미 주어진 값이며, 정확하게 맞춰야 하는 것은 프록시입니다.

FourA를 기반으로 구축하는 팀들의 패턴은 대체로 다음과 같습니다.

Proxy Finder는 최신 활성 상태 검사로 검증되고 국가, 지역, 도시, ASN 태그가 지정된 프록시 풀을 유지합니다. 맨체스터, 보스턴, 상파울루에서 요청이 발생해야 할 때, Proxy Finder는 실제로 해당 지역에 존재하며 최근 검사에서 활성 상태인 프록시를 선택합니다. 이 선택은 fetch 도중이 아니라 fetch 전에 발생합니다. 해당 라우팅 계층이 중요한 이유에 대한 자세한 내용은 스마트 프록시 라우팅 글을 참조하세요.
Single은 SERP fetch 자체를 처리합니다. 표준 자연 검색 결과의 경우 원시 HTML로 충분합니다. unblocker: true을 설정하면 해당 주에 Google이 확인 중인 서명을 일일이 파악할 필요 없이 최신 브라우저 서명이 요청에 포함됩니다. 이 플래그가 네트워크 상에서 수행하는 작업은 웹 언블로커 포스트에서 자세히 다루었습니다.
Browser는 JavaScript 실행 후에 핵심 콘텐츠가 나타나는 SERP를 처리합니다. AI Overview, 확장된 쇼핑 팩, 지식 패널 콘텐츠, 고정된 로컬 3-팩 등이 이에 해당합니다. 동일한 URL, 동일한 타겟에 대해 요청이 전체 브라우저 세션을 통해 실행되고 완전히 렌더링된 페이지를 반환합니다. (또한 SEO 리드가 대시보드에는 3위로 표시되는데 브라우저에서는 왜 6위로 보이는지 문의할 때 유용한 스크린샷도 제공합니다.)

프록시 라우팅된 API에 대한 단일 호출 예시:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

이는 세 가지 관심사를 명확히 분리한 구조입니다. 위치 기반 프록시 처리(Proxy Finder), request 자체의 실행(Single), 필요 시 JavaScript 렌더링(Browser)입니다. 코드에 프록시 헬스 체크 로직을 포함하거나 새벽 3시에 어떤 IP가 살아있는지 추측할 필요가 없습니다. 이는 인프라 레이어에서 처리됩니다.

또한 모든 response는 (keyword, location, device, timestamp)를 키로 저장해야 합니다. 이것이 랭크 트래킹에서 신뢰할 수 있는 실제 데이터 단위입니다. 단순히 "오늘 이 키워드에서 이 순위를 기록했다"가 아니라, "이 키워드에 대해, 이 도시에서, 이 디바이스로, 이 분에 이 순위를 기록했다"여야 합니다. 이러한 수준의 속성 정의가 없으면 이틀 간의 데이터가 서로 모순되더라도 어느 쪽이 맞는지 확인할 방법이 없습니다. 보호된 버티컬을 모니터링하는 SEO 팀은 이미 이러한 문제를 겪고 있습니다. 우리는 봇 탐지가 행동 기반으로 진화한 방식에 대해서도 다룬 바 있으며, 이는 개별 request 신호가 아닌 request 시퀀스를 분석하는 사이트에 대해 네 번째 축(세션 연속성)을 추가합니다.

Results

12개 도시에서 5,000개 키워드를 하루 두 번 모니터링하는 랭크 트래커는 기존 num=100 체제에서 하루 약 120,000건의 request를 생성했습니다. 이제는 단순 페이지네이션 계산만으로도 약 120만 건에 달합니다 (업계 벤치마크 기반 예시 시나리오).

이러한 아키텍처를 3개 제품 스택으로 전환한 팀들은 주로 다음과 같은 성과를 보고합니다.

자체 프록시 풀을 운영하는 방식 대비 request당 비용 40-60% 절감. 프록시 교체 비용, 비활성 IP 낭비, 로테이션 관리에 투입되던 엔지니어링 리소스가 제거되었기 때문입니다.
도시 단위 위치 정확도가 약 70%에서 95% 이상으로 향상. Proxy Finder가 도시별로 필터링하고 프록시를 전달하기 직전에 활성 상태를 검증하기 때문입니다.
AI Overviews를 위한 별도 경로 불필요. Single을 통해 가져오던 키워드는 파이프라인을 재작성할 필요 없이 Browser로 승격할 수 있습니다. URL 입력, response 출력이라는 인터페이스 규격은 동일합니다.

키워드 10개를 노트북에서 처리하는 환경에는 이러한 시스템이 필요하지 않습니다. 하지만 여러 국가에 걸쳐 수만 개의 키워드를 모니터링하고, 월요일 오전 9시에 고객이 대시보드를 새로고침할 때 정확한 순위 데이터를 보장해야 하는 파이프라인이라면 반드시 필요합니다.

Key Takeaway

SERP 모니터링에서 가장 까다로운 문제는 이미 오래전에 request 자체에서 라우팅 문제로 전환되었습니다. 어느 도시에서 데이터를 수집하고 있는가? 해당 IP가 살아있는가? Google이 해당 위치의 실제 사용자에게 보이는 레이아웃을 반환했는가, 아니면 스크래퍼를 감지했을 때 반환하는 빈 화면을 보냈는가?

자체 구축한 스택으로 랭크 트래킹을 운영하는 SEO 팀에게 2026년의 핵심 질문은 Google을 스크래핑할 것인가가 아닙니다. 이는 이미 진행 중입니다. 진정한 질문은 규칙이 예고 없이 변경될 때 인프라가 신뢰할 수 있는 순위 데이터를 지속적으로 생성할 수 있는지, 그리고 이를 유지하기 위해 엔지니어링 팀의 리소스를 얼마나 투입할 것인가입니다.