자신의 포지션 트래커: 1000개의 키워드에 대한 비용 계산

SEO 에이전시와 내부 마케팅 담당자는 언젠가 같은 질문을 하게 됩니다: 왜 순위 추적기 구독료를 지불해야 하는가, 직접 스크래퍼를 만들 수 있는데? 답은 생각보다 간단하지 않습니다. 자가 모니터링의 비용은 서버뿐만 아니라 프록시, CAPTCHA 및 스크립트 유지 관리에 소요되는 시간으로 구성됩니다. 이 기사에서는 하루에 1000개의 키워드 검사를 예로 들어 실제 수치를 분석해 보겠습니다.

에이전시가 자신의 순위 추적기를 만드는 이유

Topvisor, Serpstat, SE Ranking 또는 Rush Analytics와 같은 기존 서비스는 편리합니다: 프록시, CAPTCHA 및 서버에 대해 걱정할 필요 없이 키워드를 입력하고 보고서를 받을 수 있습니다. 그러나 이러한 편리함에는 비용이 따르며, 이는 확인할 키워드와 지역의 수에 비례하여 증가합니다. 에이전시가 15-20명의 고객을 관리하고 각 고객이 500-2000개의 키워드를 보유하고 있다면, 구독료는 빠르게 주니어 직원의 급여와 비슷한 금액에 도달합니다.

두 번째 이유는 유연성입니다. 기존 서비스에서는 개별 키워드에 대한 확인 빈도를 변경하거나 사용자 정의 로직을 추가할 수 없습니다(예: 위치뿐만 아니라 스니펫, 빠른 링크 또는 리뷰의 존재를 추적). 자신의 추적기는 이러한 문제를 해결하지만 인프라가 필요합니다: 서버, 데이터베이스, 스크래핑 스크립트 및 가장 중요한 것은 검색 엔진의 자동 요청에 대한 보호를 우회하기 위한 프록시입니다.

세 번째 이유는 데이터에 대한 통제입니다. NDA에 따라 대규모 고객과 작업하는 에이전시는 종종 외부 클라우드 서비스에 키워드 및 도메인 목록을 제공하는 것을 꺼립니다. 자신의 추적기는 모든 것을 자체 인프라에 저장할 수 있게 해줍니다.

순위 확인 비용의 구성 요소

돈을 계산하기 전에 메커니즘을 이해해야 합니다: 특정 키워드에 대한 사이트의 위치를 확인하기 위해 스크래퍼는 Yandex 또는 Google에 요청을 보내고 결과의 HTML 페이지를 받아 필요한 도메인을 찾아야 합니다. 하루에 1000개의 키워드에 대해 최소 1000개의 요청이 필요하며, 두 검색 엔진과 여러 지역을 확인하는 경우 이 숫자는 2-4배 증가합니다.

검색 엔진은 하나의 IP에서 자동 요청을 공격적으로 차단합니다: 하나의 주소에서 20-50개의 연속 요청 후 Yandex는 CAPTCHA를 표시하기 시작하고 Google은 IP를 몇 시간 동안 일시적으로 차단합니다. 따라서 각 요청은 별도의 프록시 또는 자주 변경되는 프록시를 통해 이루어져야 합니다. 여기서 주요 비용 항목이 발생합니다 — 서버나 스크립트가 아니라 바로 프록시 인프라입니다.

전체 비용 구조는 다음과 같습니다:

IP 회전을 위한 프록시 — 주요 변동 비용 항목, 요청량에 따라 달라짐
스크립트를 일정에 따라 실행하기 위한 서버 또는 VPS — 고정된 소액
CAPTCHA 해결 (안티 CAPTCHA 서비스) — 프록시 품질이 충분하지 않을 경우 추가 비용
스크래퍼 작성 및 유지 관리에 필요한 개발자 시간 — 일회성 및 주기적 비용
데이터 저장 및 시각화 — 데이터베이스, 대시보드, 일반적으로 최소 비용

구독 vs 자신의 추적기: 비용 항목 비교

자신의 추적기가 구독보다 더 유리한 시점을 평가하기 위해 비용 항목을 직접 비교하는 것이 편리합니다. 아래는 특정 요금제에 구애받지 않는 요약 표로, 선택 논리를 보여줍니다.

매개변수	기존 서비스 (구독)	자신의 순위 추적기
하루에 1000개의 키워드 비용	요금제에 비례하여 증가하며, 고정된 월간 금액	프록시 트래픽 + 서버 임대료로 구성되며, 부드럽게 확장됨
설정의 유연성	서비스 기능에 제한됨	완전한 유연성 — 모든 빈도, 지역, 깊이
개발자 필요 여부	아니오	예, 시작 시와 주기적으로 지원을 위해 필요
차단/CAPTCHA 위험	서비스가 책임짐	귀하에게 부담되며, 프록시와 지연으로 해결됨
손익 분기점	—	보통 하루에 3000-5000개의 키워드 이상

표에서의 결론은 간단합니다: 적은 양의 키워드(하루에 2000-3000개 이하)에서는 구독이 거의 항상 더 유리합니다. 왜냐하면 자신의 솔루션 개발 및 지원 비용이 회수되지 않기 때문입니다. 그러나 대량의 키워드(하루에 수천 개)에서는 특히 하루에 여러 번 또는 다양한 지역에서 확인해야 하는 경우, 자체 인프라가 경제적으로 유리해지기 시작합니다.

하루에 1000개의 키워드에 대한 프록시 계산

비용의 주요 질문은 차단 및 CAPTCHA 없이 하루에 1000개의 요청을 처리하기 위해 얼마나 많은 프록시가 필요한가입니다. 스크래핑에서 실제로 사용하는 평균 안전 한계는 다음과 같습니다:

Yandex: 하루에 하나의 IP에서 30-50개의 요청, 요청 간의 무작위 지연이 10-30초일 때 CAPTCHA 위험 없음
Google: 하루에 하나의 IP에서 15-25개의 요청, 시스템이 더 엄격하고 빠르게 차단함

만약 Yandex에서만 1000개의 키워드를 확인한다면, IP당 40개의 요청 한도에서 최소 25개의 고유한 주소가 필요합니다. 실패한 요청에 대한 재시도와 일시적인 차단에 대비하여 30-40개의 IP를 준비하십시오. 두 검색 엔진을 모두 확인하는 경우 숫자는 두 배가 되어 하루에 약 60-80개의 IP가 필요합니다.

중요한 점: 요청에 따라 IP 풀을 통해 작업할 때(세션이 아닌) 동일한 물리적 프록시 서버는 제공자가 동적 회전을 제공하는 경우 훨씬 더 많은 IP 주소를 "닫을" 수 있습니다. 이 경우 계산은 주소 수가 아니라 트래픽 양에 따라 이루어집니다 — 일반적으로 하나의 위치 확인은 50-200KB의 HTML을 차지하므로, 하루에 1000개의 요청은 50-200MB의 트래픽을 의미하며, 이는 평균 요금제에서도 전혀 심각한 부하가 아닙니다.

하루에 1000개의 키워드에 대한 계산 예시 (Yandex + Google):

하루에 2000개의 요청 ÷ (IP당 평균 30개의 요청) ≈ 65-70개의 고유한 IP. 검색 결과 페이지의 평균 크기가 100KB일 경우, 총 트래픽은 하루에 약 200MB가 되며, 또는 한 달에 약 6GB — 이 수치는 프록시 제공업체의 트래픽 요금제를 선택할 때 고려해야 할 수치입니다.

Yandex와 Google에 필요한 프록시 종류

프록시의 종류는 CAPTCHA와 차단의 수에 직접적인 영향을 미치며, 이는 순위 확인의 실제 비용에 영향을 미칩니다. 세 가지 옵션을 살펴보겠습니다.

데이터 센터 프록시 — 트래픽 비용이 가장 저렴한 옵션이지만, 검색 엔진 데이터베이스에서 평판이 좋지 않습니다: 데이터 센터 IP는 대량으로 스크래핑에 사용되므로 Yandex와 Google은 이를 빠르게 인식하고 몇 번의 요청 후 CAPTCHA를 표시합니다. 낮은 빈도로 소수의 키워드를 확인하는 경우 데이터 센터 프록시를 사용할 수 있지만, 하루에 1000개 이상의 요청에서는 CAPTCHA 비율이 너무 높아져 트래픽 비용 절감이 안티 CAPTCHA 비용으로 상쇄됩니다.

레지던셜 프록시 — 실제 가정 사용자의 IP 주소로, 검색 엔진은 이를 일반 트래픽으로 인식합니다. CAPTCHA 비율이 훨씬 낮아 대량 확인 시 중요합니다. 하루에 1000개 이상의 키워드에 대한 스크래핑을 위해 레지던셜 프록시는 일반적으로 비용과 안정성의 최적 비율을 제공합니다, 특히 Google과 작업할 때 데이터 센터 주소를 가장 엄격하게 차단합니다.

모바일 프록시 — 모바일 운영자의 IP를 사용하며, 수천 명의 실제 가입자(NAT)에서 자주 변경됩니다. 따라서 동일한 주소는 하루 동안 여러 사용자에게 "속할" 수 있습니다. 이는 공격적인 스크래핑 시 최대의 생존력을 제공합니다, 하지만 비용이 더 비쌉니다. 모바일 프록시는 모바일 검색 결과에서 순위를 확인하거나 특히 까다로운 지역 요청을 처리할 때 정당화됩니다.

프록시 유형	1000개의 요청에 대한 CAPTCHA 비율	언제 사용해야 하는가
데이터 센터	높음	하루에 200-300개의 키워드, 낮은 빈도
레지던셜	낮음	하루에 1000개 이상의 키워드, Google 및 Yandex
모바일	최소	모바일 검색 결과, 복잡한 지역

자신의 추적기 설정 단계별 안내

자신의 순위 추적기를 구성하는 과정을 단계별로 살펴보겠습니다 — 코드에 깊이 들어가지 않고 솔루션 아키텍처 수준에서 설명합니다.

데이터 소스 선택. 검색 엔진의 결과를 HTTP 요청을 통해 직접 스크래핑할 것인지, 아니면 실제 사용자를 시뮬레이션하기 위해 headless 브라우저(예: Puppeteer/Playwright)를 사용할 것인지 결정합니다. 후자는 안티봇 보호에 대해 더 신뢰할 수 있지만, 서버 자원 측면에서 더 느리고 비쌉니다.
프록시 풀 설정. 요청에 따라 IP를 회전하는 프록시 제공업체를 연결합니다. Yandex와 Google에는 서로 다른 프록시 풀을 사용하는 것이 좋습니다, 왜냐하면 시스템의 차단 한도가 다르기 때문입니다.
재시도 로직. 요청이 CAPTCHA 또는 오류를 반환하면 스크립트는 IP를 자동으로 변경하고 요청을 반복해야 하며, 단순히 오류를 기록해서는 안 됩니다.
결과 스크래핑. 수신한 HTML에서 필요한 도메인의 위치를 추출합니다 — 일반적으로 링크 태그를 검색하고 클라이언트 도메인과 비교하여 수행합니다.
이력 저장. 결과는 확인 날짜와 함께 데이터베이스에 저장되어 위치 동향 그래프를 작성할 수 있습니다.
실행 일정. 스크립트는 cron 또는 작업 스케줄러를 통해 하루에 한 번(또는 더 자주) 실행되며, 1000개의 요청을 시간에 고르게 분배하여 프록시 풀에 피크 부하를 주지 않도록 합니다.

Python으로 순위 확인 코드 예시

아래는 프록시와 회전을 통해 검색 결과에 요청하는 간단한 로직 예시입니다. 이는 작동 원리를 보여주는 데모 프레임워크이며, 완전한 솔루션이 아닙니다.

import requests
import random
import time

PROXY_LIST = [
    "http://user:[email protected]:8000",
    "http://user:[email protected]:8000",
    # ... 수백 개의 주소로 구성된 프록시 풀
]

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

def check_position(keyword, domain, search_engine="yandex"):
    proxy = random.choice(PROXY_LIST)
    proxies = {"http": proxy, "https": proxy}

    if search_engine == "yandex":
        url = f"https://yandex.ru/search/?text={keyword}"
    else:
        url = f"https://www.google.com/search?q={keyword}"

    try:
        response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=10)
        if "captcha" in response.text.lower():
            return None  # IP 회전 및 요청 반복 필요
        position = find_domain_position(response.text, domain)
        return position
    except requests.RequestException:
        return None

def find_domain_position(html, domain):
    # 결과에서 도메인의 위치를 찾는 간단한 로직
    results = extract_links(html)
    for i, link in enumerate(results, start=1):
        if domain in link:
            return i
    return None

for keyword in keyword_list:
    pos = check_position(keyword, "example.com")
    save_to_db(keyword, pos)
    time.sleep(random.uniform(5, 15))  # 요청 간의 무작위 지연

실제 프로젝트에서는 수동으로 HTML을 스크래핑하는 대신 사용자 에이전트와 핑거프린트를 변경한 headless 브라우저를 사용하는 경우가 많으며, 프록시 풀은 자동 회전을 제공하는 공급자를 통해 연결됩니다 — 이는 주소 목록을 수동으로 저장할 필요를 없애고 하루에 수천 개의 요청으로 확장하는 것을 용이하게 합니다.

실제로 얼마나 절약할 수 있는가

절약에 대한 질문에 답하기 위해서는 키워드 수가 증가함에 따라 두 가지 비용 모델을 비교해야 합니다.

적은 양의 키워드(하루에 1000-2000개)에서는 기존 추적기의 구독 비용이 일반적으로 자신의 솔루션 개발 및 지원에 드는 총 비용과 비슷하거나 더 낮습니다. 최소한의 생존 가능한 스크래퍼를 처음부터 개발하는 데는 며칠에서 몇 주가 걸리며, 검색 결과의 레이아웃 변경에 따른 주기적인 지원도 필요합니다 — Yandex와 Google은 결과의 레이아웃을 자주 변경합니다.

전환점은 확인량이 하루에 수천 개로 증가하거나 여러 번 확인해야 할 필요가 있을 때 발생합니다. 이 경우 기존 구독의 비용은 양에 따라 선형적으로 또는 점진적으로 증가하며, 자신의 추적기의 비용은 훨씬 느리게 증가합니다 — 주요 비용 항목(프록시 트래픽)은 SaaS 서비스의 요금제가 다음 수준으로 넘어갈 때보다 급격히 오르지 않습니다.

에이전시를 위한 실용적인 기준: 동시에 5-10명 이상의 고객의 순위를 추적하는 경우, 총량은 일반적으로 하루에 5000-10000개의 키워드를 초과합니다 — 이 규모에서는 자신의 추적기가 거의 항상 기존의 구독보다 유리합니다, 단 팀에 스크래퍼를 지원할 수 있는 사람이 있어야 합니다.

자가 스크래핑 시 흔한 실수

실제로 자신의 순위 추적기와 관련된 대부분의 문제는 코드와 관련된 것이 아니라 인프라의 세부 사항을 과소평가하는 것과 관련이 있습니다.

프록시 비용 절감. 저렴한 데이터 센터 프록시에서 비용을 절감하려는 시도는 대량의 CAPTCHA를 초래하며, 이는 외부 안티 CAPTCHA 서비스로 해결해야 합니다 — 결국 총 비용이 더 높은 품질의 프록시를 처음부터 사용하는 것보다 더 높아집니다.
요청 간 지연 없음. 하나의 IP에서 너무 빠른 연속 요청은 안티봇 시스템의 주목을 즉시 끌며, IP가 품질이 좋더라도 마찬가지입니다.
지역성 무시. Yandex는 사용자의 지역에 따라 다른 검색 결과를 표시합니다 — 올바른 지리적 위치가 없으면 순위 데이터가 부정확해집니다.
스크래퍼 상태 모니터링 없음. 검색 엔진은 주기적으로 검색 결과 페이지의 레이아웃을 변경하며, 파싱 성공률이 떨어졌을 때 경고가 없으면 수주 동안 빈 데이터나 부정확한 데이터를 수집할 수 있습니다.
모바일 검색 결과 무시. 데스크톱과 모바일 검색 결과는 종종 다르며, 고객이 모바일 순위에 특히 중요하다면, 해당하는 사용자 에이전트와 모바일 IP를 사용하는 별도의 스크래핑 경로가 필요합니다.

결론

자신의 순위 추적기는 하루에 수천 개의 키워드를 확인할 때 경제적으로 타당해지며, 팀에 스크래퍼를 지원할 수 있는 리소스가 있을 때 가능합니다. 더 적은 양에서는 기존 구독이 개발에 숨겨진 비용을 고려할 때 거의 항상 더 저렴합니다. 자신의 솔루션의 주요 변동 비용 항목은 서버나 코드가 아니라 프록시 인프라로, 이는 CAPTCHA 비율과 데이터의 안정성을 결정합니다.

하루에 1000개 이상의 키워드에 대한 순위 추적기를 구축할 계획이라면, 트래픽과 요청 샘플에 대한 테스트 프록시 풀을 계산하는 것부터 시작하십시오. Yandex와 Google에서 안정적인 스크래핑을 위해서는 레지던셜 프록시를 즉시 고려하는 것이 합리적입니다 — 이는 허용 가능한 트래픽 비용으로 최소한의 CAPTCHA 비율을 제공하며, 추적하는 고객 수가 증가함에 따라 잘 확장됩니다.