과제
순위 추적기, SEO 대시보드 또는 경쟁사 분석 도구를 구축하는 팀이라면, 2026년은 귀사의 유닛 이코노믹스를 무너뜨린 해가 되었을 것입니다. Google은 올해 Google Search에서 num=100 URL 매개변수를 조용히 중단했습니다. 이는 모든 SERP 스크래퍼가 단 한 번의 request로 100개의 결과를 가져오기 위해 사용하던 트릭이었습니다. 이제 동일한 범위를 커버하려면 한 번이 아니라 열 번의 request가 필요합니다.
이것이 눈에 보이는 비용입니다. 숨겨진 비용은 훨씬 더 까다롭습니다.
순위 추적은 실제 검색자가 올바른 국가, 지역, 도시에서 보게 될 SERP를 그대로 확인할 수 있을 때만 유효합니다. 런던에서 4위인 키워드가 에든버러에서는 11위, 벨파스트에서는 19위일 수 있습니다. 로컬 3팩, 쇼핑 캐러셀, 뉴스 박스, 지식 패널, AI Overviews. 모든 SERP 기능은 지리적 위치와 기기에 따라 달라집니다. (Scrape.do의 측정에 따르면 2026년 초 기준 쿼리의 약 36%에서 AI Overview 텍스트가 나타났습니다.) 스크래퍼가 잘못된 도시의 proxy를 거치도록 라우팅되면, 귀사의 순위 데이터는 확신에 찬 거짓말에 불과하게 됩니다.
따라서 2026년에 경쟁력 있는 SERP 제품을 만들려면 세 가지가 함께 작동해야 합니다. 와이어 레벨에서 실제 브라우저처럼 보이는 request, 모니터링하려는 정확한 도시에 위치한 proxy, 그리고 Google이 결과의 절반을 클라이언트 사이드에서 로드하기로 결정했을 때 JavaScript를 렌더링할 수 있는 기능입니다. 이 세 가지 중 하나라도 놓치면 데이터의 품질이 소리 없이 저하됩니다.
FourA의 접근 방식
대규모 SERP 스크래핑의 병목 현상은 request가 아닙니다. 바로 라우팅입니다.
자체 구축한 대부분의 파이프라인은 고정된 proxy 풀로 시작하여 쿼리를 변수로 취급합니다. 하지만 Google의 지리적 타겟팅을 고려하면 그 반대가 되어야 합니다. 쿼리는 이미 가지고 있는 것입니다. 제대로 확보해야 하는 것은 proxy입니다.
여러 팀이 FourA를 기반으로 다음과 같은 패턴으로 이를 구현하는 것을 확인했습니다.
Proxy Finder는 최신 liveness check를 통해 검증되고 국가, 지역, 도시, ASN 태그가 지정된 proxy 풀을 실시간으로 유지합니다. 맨체스터, 보스턴 또는 상파울루에서 request를 보내야 할 때, Proxy Finder는 실제로 해당 지역에 존재하며 마지막 검사에서 활성 상태였던 proxy를 선택합니다. 이 선택은 fetch 도중이 아니라 fetch 전에 이루어집니다. 이러한 라우팅 레이어가 중요한 이유에 대해 자세히 알아보려면 Smart Proxy Routing에 관한 글을 참조하세요.
Single은 SERP fetch 자체를 처리합니다. 표준 오가닉 결과의 경우 raw HTML로도 충분합니다.
unblocker: true로 설정하면, Google이 그 주에 어떤 시그니처를 검사하고 있는지 알 필요 없이 핸드셰이크 레벨의 anti-bot 방화벽을 통과하여 request가 전달됩니다. 해당 플래그가 네트워크 상에서 실제로 어떤 역할을 하는지는 Web Unblocker post에서 자세히 설명했습니다.Browser는 JavaScript가 실행된 후에 중요한 콘텐츠가 나타나는 SERP를 처리합니다. AI Overviews, 확장된 쇼핑 팩, 지식 패널 콘텐츠, 고정된 로컬 3팩 등이 이에 해당합니다. 동일한 URL, 동일한 타겟이지만, request가 전체 브라우저 세션을 거쳐 실행되며 완전히 페인팅된 페이지를 반환합니다. (스크린샷도 함께 제공되므로, SEO 팀장이 대시보드에는 3위라고 나오는데 왜 본인 브라우저에서는 6위로 보이는지 묻는 곤란한 상황을 방지할 수 있습니다.)
proxy 라우팅이 적용된 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 작업(Proxy Finder), request 자체(Single), 필요할 때 작동하는 JavaScript 렌더링(Browser)이라는 세 가지 관심사가 깔끔하게 분리됩니다. 개발자의 코드가 proxy 상태 관리 로직을 포함하거나 새벽 3시에 어떤 IP가 아직 활성화되어 있는지 추측할 필요가 없습니다. 그것은 다른 시스템의 몫입니다.
그리고 모든 response를 (keyword, location, device, timestamp)를 키로 하여 저장하십시오. 이것이 순위 추적을 위한 실제 신뢰의 단위입니다. "오늘 이 키워드로 이 순위를 기록했다"가 아니라, "이 도시에서, 이 기기로, 이 시간에, 이 키워드로 이 순위를 기록했다"가 되어야 합니다. 이 정도 수준의 어트리뷰션이 없다면, 이틀간의 데이터가 서로 모순되어도 어느 쪽이 맞는지 확인할 방법이 없습니다. 규제가 엄격한 버티컬 영역을 모니터링하는 SEO 팀들은 이미 이러한 방식으로 작업하고 있습니다. 저희는 또한 bot detection went behavioral에 관한 글을 통해, 개별 request 신호가 아닌 request 시퀀싱을 분석하는 사이트들을 위한 네 번째 축(세션 연속성)에 대해 다룬 바 있습니다.
결과
기존 num=100 체제에서는 12개 도시에서 5,000개 키워드를 하루에 두 번 모니터링하는 순위 추적기의 경우 하루 약 120,000개의 request가 필요했습니다. 이제는 단순한 페이지네이션 계산법에 따르면 120만 개에 가깝습니다 (업계 벤치마크에 기반한 예시 시나리오).
이러한 구조를 3개 제품 스택으로 전환한 팀들은 대개 다음과 같은 성과를 보고합니다.
- 자체 proxy 풀을 운영할 때보다 request당 비용 40~60% 절감: 주로 proxy churn, 비활성 IP 비용, 로테이션 유지 관리를 위한 엔지니어링 리소스 소모가 사라졌기 때문입니다.
- 도시 수준의 위치 정확도가 약 70%에서 95% 이상으로 향상: Proxy Finder가 도시별로 필터링하고 proxy를 전달하기 직전 마지막 검사에서 liveness를 확인하기 때문입니다.
- AI Overviews를 위한 별도의 경로 불필요. Single을 통해 가져오던 키워드를 파이프라인 재작성 없이 Browser로 업그레이드할 수 있습니다. contract는 동일합니다. URL을 넣으면 response가 나옵니다.
노트북 한 대와 키워드 10개만 다룬다면 이런 복잡한 시스템은 필요하지 않습니다. 하지만 파이프라인이 여러 국가에 걸쳐 수만 개의 키워드를 모니터링하고, 고객들이 월요일 오전 9시에 대시보드를 새로고침할 때 실제 순위 데이터를 보여주어야 한다면 반드시 필요합니다.
핵심 요약
SERP 모니터링에서 어려운 부분은 이미 오래전에 request 자체가 아니게 되었습니다. 핵심은 라우팅이었습니다. 어느 도시에서 데이터를 가져오고 있습니까? 해당 IP가 활성 상태입니까? Google이 해당 위치의 실제 검색자가 보게 될 레이아웃을 반환했습니까, 아니면 스크래퍼를 감지했을 때 제공하는 빈 레이아웃을 반환했습니까?
자체 구축한 스택으로 순위 추적을 수행하는 SEO 팀이라면, 2026년의 질문은 Google을 스크래핑할 것인가 여부가 아닙니다. 이미 하고 계실 테니까요. 진짜 질문은 예고 없이 규칙이 바뀔 때 귀사의 인프라가 신뢰할 수 있는 순위를 계속해서 생성해낼 수 있는지, 그리고 이를 유지하기 위해 엔지니어링 팀의 리소스를 얼마나 투입할 의향이 있는지입니다.