SERP API 가격은 단순해 보인다. 천 건의 검색당 가격, 몇 가지 월간 플랜이 전부다. 하지만 실제로 청구되는 금액은 팀이 예상한 것과 다른 경우가 많은데, 프로젝트에 필요한 검색 건수가 눈치채지 못한 채 쉽게 내려지는 여러 결정의 곱으로 결정되기 때문이다. 도시 몇 개를 더 추적하고, 모바일을 추가하고, 한 페이지 더 들어가고, 주간 대신 일간으로 확인하면 물량은 곱절로 늘어난다.
이 가이드는 SERP API 청구서를 구성 요소별로 분해하고, 2025년에 심층 순위 추적 비용을 10배로 만든 변화를 설명하며, 필요한 데이터만 구매하고 사용하지 않는 데이터에 비용을 치르지 않도록 워크로드를 계획하는 방법을 보여준다. 여러분 자신의 수치와 어떤 공급업체의 가격표에도 적용해볼 수 있는 작은 계산기도 포함되어 있다.
핵심 요약
- 월간 검색 건수는 키워드 수 곱하기 페이지 수 곱하기 위치 수 곱하기 기기 수 곱하기 검색엔진 수 곱하기 월간 확인 횟수다. 모든 요인이 서로를 곱한다.
- 심도(depth)가 지금은 가장 비용이 큰 요인이다. 2025년 9월 Google이 한 페이지에 100개의 결과를 반환하던 파라미터를 더 이상 인정하지 않게 되면서, 상위 100위까지 추적하려면 한 번이 아니라 열 번의 요청이 필요해졌다.
- 가장 쉽게 절약할 수 있는 부분은 대개 빈도다. 변동성이 크고 가치가 높은 키워드는 매일 확인하고, 롱테일 키워드는 매주 확인한다.
- 공급업체를 비교할 때는 겉으로 보이는 요율뿐 아니라 실제로 무엇에 과금되는지를 비교하라. 실패한 요청과 캐시된 요청이 집계되는지, 모든 검색엔진이 포함되는지, 초과분은 어떻게 처리되는지를 확인해야 한다.
- 워크로드를 먼저 계획한 다음 플랜을 선택하라. 예시에서 계층화된 일정은 우선순위 키워드에 대해 상위 100위까지의 커버리지를, 모든 것을 매일 100위까지 추적하는 경우의 약 8분의 1의 물량으로 제공했다.
실제로 무엇에 대해 비용을 지불하는가
우리를 포함한 대부분의 SERP API는 검색 요청당 과금한다. 요청이란 하나의 쿼리, 하나의 위치, 하나의 기기, 하나의 검색엔진, 한 시점에 대한 하나의 결과 페이지를 말한다. 나머지 모든 것은 이 단위로부터 비롯된다.
| 요인 | 의미 | 일반적인 범위 |
|---|---|---|
| 키워드 | 추적하는 쿼리 | 수십 개에서 수십만 개 |
| 심도 | 필요한 순위 범위; 결과 10개마다 한 페이지, 페이지마다 하나의 요청 | 10에서 100 |
| 위치 | 별도로 추적하는 국가, 지역, 도시 | 1개에서 수백 개 |
| 기기 | 데스크톱과 모바일 결과는 다르므로, 둘 다 추적하면 물량이 두 배가 된다 | 1 또는 2 |
| 검색엔진 | Google, Bing, Yandex 등, 각각 별도의 요청 | 1에서 3 |
| 빈도 | 각 조합을 확인하는 주기 | 월간에서 하루에 여러 번 |
이를 곱해보면 규모가 금세 분명해진다. 키워드 500개, 기기 2개, 도시 5개, 일일 확인이면 첫 페이지를 넘어가기도 전에 월 150,000건의 요청이 된다.
심도 비용이 10배로 늘어난 이유
오랫동안 순위 추적 도구들은 num=100이라는 URL 파라미터를 사용해 Google에 한 페이지에 100개의 결과를 요청했다. 요청 한 번으로 상위 100위 전체를 받을 수 있었다. 2025년 9월 중순, Google은 이 파라미터를 더 이상 인정하지 않게 되었고, 이에 의존하던 도구들은 결과를 10개씩 페이지로 넘겨가며 받도록 전환하기 전까지 빈틈을 보이기 시작했다.
비용에 미치는 영향은 직접적이다. 이제 키워드 하나의 상위 100위를 추적하려면 열 번의 요청이 필요하므로, 같은 심도의 비용이 10배가 된다. 많은 팀에게 이는 질문을 “얼마나 깊이 추적할 수 있는가”에서 “실제로 얼마나 깊이 추적해야 하며, 어떤 키워드에 대해 그런가”로 바꾼다. 대부분의 클릭은 첫 페이지로 향하며, 대부분의 키워드에서 첫 페이지에 있는지, 대략 어디쯤인지를 아는 것이 의사결정에 필요한 사실이다.
자신의 워크로드를 위한 계산기
아래 모듈은 하나 이상의 추적 일정에 대한 월간 요청 수를 계산한다. 결과에 어떤 공급업체든 천 건당 가격을 곱하면 플랜을 비교할 수 있다.
import math
from dataclasses import dataclass
RESULTS_PER_PAGE = 10 # Google stopped honouring num=100 in September 2025, so every 10 results is a call
@dataclass
class Workload:
keywords: int
depth: int # how many positions you need: 10, 20, 100...
locations: int = 1
devices: int = 1 # 2 if you track desktop and mobile separately
engines: int = 1
checks_per_month: float = 30.0
def calls_per_month(self):
pages = math.ceil(self.depth / RESULTS_PER_PAGE)
return math.ceil(self.keywords * pages * self.locations * self.devices * self.engines * self.checks_per_month)
def summarise(name, workloads):
calls = sum(w.calls_per_month() for w in workloads)
return f"{name}: {calls:,} calls a month"네 가지 일반적인 워크로드에 대해 실행해보자:
from serpcost import Workload, summarise
WEEKLY = 52 / 12 # checks per month for a weekly schedule
print(summarise("500 keywords, top 10, daily", [Workload(500, 10)]))
print(summarise("500 keywords, top 100, daily", [Workload(500, 100)]))
print(summarise("Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords",
[Workload(500, 10), Workload(100, 100, checks_per_month=WEEKLY)]))
print(summarise("200 local keywords, 5 cities, desktop and mobile, weekly",
[Workload(200, 10, locations=5, devices=2, checks_per_month=WEEKLY)]))500 keywords, top 10, daily: 15,000 calls a month
500 keywords, top 100, daily: 150,000 calls a month
Tiered: top 10 daily, plus top 100 weekly for 100 priority keywords: 19,334 calls a month
200 local keywords, 5 cities, desktop and mobile, weekly: 8,667 calls a month두 번째와 세 번째 줄이 핵심이다. 500개 키워드를 매일 상위 100위까지 추적하면 월 150,000건의 요청이 필요하다. 모든 키워드를 매일 첫 페이지까지만 추적하고, 가장 중요한 100개만 매주 상위 100위까지 추적하면 19,334건, 즉 약 8분의 1에 그치면서도 순위 리포트가 사용되는 거의 모든 질문에 여전히 답할 수 있다.
비용을 줄이는 일곱 가지 방법
- 심도를 의사결정에 맞춰라. 대부분의 키워드는 첫 페이지까지만 추적하고, 40위에서 15위로 이동하는 것이 행동을 바꾸는 키워드에 대해서만 더 깊이 들어가라.
- 빈도를 계층화하라. 가치가 높고 변동성이 큰 키워드는 매일 확인하고, 안정적인 롱테일 키워드는 매주 확인하라. SERP 변동성 감지 가이드는 자신의 데이터로 어느 쪽인지 판단하는 방법을 보여준다.
- 차이가 나는 위치만 추가하라. 도시 단위 추적은 로컬 의도에는 중요하지만 정보성 쿼리에는 훨씬 덜 중요하다. 도시 단위 타겟팅이 중요한 경우에서 결정 방법을 설명한다.
- 차이가 나는 경우에만 두 기기 모두 추적하라. 먼저 표본으로 데스크톱과 모바일을 측정하라. 순위가 비슷하게 일치한다면 하나만 추적하고 다른 하나는 간헐적으로 확인하라.
- 클라이언트와 팀 간 중복을 제거하라. 에이전시는 종종 여러 클라이언트에 대해 같은 위치에서 같은 키워드를 추적한다. 한 번만 가져와서 결과를 공유하라.
- 당일 내에는 캐시하라. 여러 시스템이 같은 결과 페이지를 필요로 한다면, 첫 응답을 저장해두고 다시 요청하지 말고 재사용하라.
- 시도가 아니라 결과에 비용을 지불하라. 실패한 요청, 재시도, 캐시된 응답이 과금되는지 확인하라. 실패는 모든 청구서에서 숨겨진 비중을 차지하기 때문이다.
공급업체를 공정하게 비교하기
천 건당 겉으로 보이는 가격은 단위가 일치할 때만 비교할 수 있다. SERP API를 비교할 때는 다음을 확인하라.
| 질문 | 왜 중요한가 |
|---|---|
| ”검색” 한 건이 결과 페이지 하나인가, 아니면 더 깊은 페이지네이션에 추가 크레딧이 드는가? | 심도의 실제 비용을 결정한다 |
| 실패하거나 비어 있거나 재시도된 요청이 과금되는가? | 실패는 모든 청구서에서 숨겨진 비중을 차지한다 |
| 모든 검색엔진과 결과 유형이 포함되는가, 아니면 별도로 가격이 책정되는가? | Google 웹 결과를 넘어선 추적 비용을 결정한다 |
| 위치 및 기기 타겟팅이 같은 요율로 포함되는가? | 도시 단위나 모바일 추적이 요율을 바꾸는지를 결정한다 |
| 플랜을 초과하면 어떻게 되는가: 완전 중단, 초과 요율, 자동 업그레이드인가? | 바쁜 달에 실제로 드는 비용을 결정한다 |
| 결과가 실시간인가, 캐시에서 제공되는가, 그리고 그것이 표시되는가? | 데이터의 신선도를 결정한다 |
클린 레코드당 비용 원칙이 여기에도 적용된다. 의미 있는 숫자는 요청당 정가가 아니라, 실패와 재시도, 중복을 제거한 후 사용 가능한 결과 페이지당 실제로 지불하는 금액이다.
직접 구축할 것인가, 구매할 것인가
프록시를 통해 직접 수집을 운영하는 것은 매우 많은 물량에서는 더 저렴할 수 있지만, 파싱과 유지보수, 그리고 num=100의 종료 같은 변화에 대응하는 작업이 뒤따른다. SERP API는 그 작업을 공급업체에게 넘긴다. SEO 플랫폼이 SERP API를 사용하는 방법은 일반적으로 그 경계가 어디에 그어지는지를 다루며, 일일 키워드 순위 모니터링 자동화는 그 위에 구축된 완전한 파이프라인을 보여준다.
결론
SERP API 청구서는 키워드, 심도, 위치, 기기, 검색엔진, 빈도의 곱이며, Google이 한 페이지에 100개의 결과를 반환하지 않게 된 이후로 심도가 가장 빠르게 곱해지는 요인이다. 비용을 줄이는 방법은 천 건당 가장 낮은 요율을 찾는 것이 아니라, 의사결정을 바꾸는 요청만 구매하는 것이다. 대부분의 키워드는 첫 페이지, 중요한 소수는 더 깊이, 순위가 움직이는 곳은 매일, 그렇지 않은 곳은 매주.
플랜을 선택하기 전에 자신의 워크로드로 계산기를 돌려보고, 각 공급업체의 요율을 곱해 동등한 조건으로 비교하라.
출처 및 참고자료
- Search Engine Journal, Google이 검색 결과 파라미터를 수정하여 SEO 도구에 영향을 미치다, 2025년 9월.