Google Sheets의 IMPORTXML이 한계에 부딪혔습니다: 다음에 무엇을 해야 할까요?

Wildberries, Ozon 또는 Avito에서 IMPORTXML을 통해 경쟁사의 가격을 모니터링하고 있다면, 언젠가는 시트가 #N/A 오류를 발생시키고, 데이터가 몇 시간 동안 지연되거나 아예 업데이트되지 않을 수 있습니다. 이는 버그가 아니라 Google Sheets의 한계와 동일한 IP 주소에서의 대량 요청을 방어하기 위한 웹사이트의 보호 조치입니다. 이 기사에서는 시트가 자원을 소진했음을 알 수 있는 징후와 프록시를 사용한 자체 파서로 무리 없이 전환하는 방법을 살펴보겠습니다.

IMPORTXML의 작동 원리와 사용 이유

IMPORTXML은 Google Sheets의 내장 함수로, XPath 쿼리를 통해 페이지에서 데이터를 가져와 셀에 직접 삽입합니다. =IMPORTXML("URL"; "//span[@class='price']")와 같은 형태의 수식은 코드 한 줄 없이 Wildberries 또는 Ozon의 상품 카드에서 가격을 추출하고 매시간 자동으로 업데이트할 수 있게 해줍니다.

판매자와 마케팅 담당자에게 이는 완벽한 해결책처럼 보입니다: 개발자가 필요 없고, 서버도 필요 없으며, 모든 것이 익숙한 시트에서 작동합니다. 20-30개의 상품을 가진 작은 상점은 실제로 수년 동안 하나의 IMPORTXML로 문제를 인식하지 못하고 운영할 수 있습니다. 그러나 추적해야 할 SKU의 수가 몇 백 개를 초과하고 업데이트 빈도가 하루에 한 번이 아니라 매시간 필요해지면, 시스템 오류가 발생하기 시작하고, 함수의 설정으로는 이를 해결할 수 없습니다.

문제는 모든 IMPORTXML 요청이 귀하의 컴퓨터가 아닌 Google 서버에서 발생한다는 것입니다. Google은 이러한 요청을 위한 제한된 IP 주소 풀을 가지고 있으며, 마켓플레이스는 이러한 범위를 잘 알고 있습니다. 요청이 많아지면 웹사이트의 보호 장치가 작동하여 셀에 가격 대신 오류나 빈 값이 표시됩니다.

IMPORTXML이 더 이상 작동하지 않는 7가지 징후

더 복잡한 솔루션으로 전환하기 전에 문제가 한계 때문인지 수식의 오타 때문인지 확인하세요. 다음은 이를 판단할 수 있는 구체적인 증상입니다:

대량의 #N/A — 동시에 30-50%의 수식이 작동을 멈추며, 어제는 괜찮았고 페이지 구조도 변경되지 않았습니다.
업데이트 지연이 증가 — 이전에는 데이터가 5-10분 안에 업데이트되었으나, 이제는 시트가 30-40분 동안 "생각"하거나 수동으로 재계산하지 않으면 아예 업데이트되지 않습니다.
"Resource at url contacted too many times" 오류 — 한 도메인에 대한 내부 요청 한계에 도달했음을 알리는 Google의 직접적인 메시지입니다.
데이터가 오래됨 — 시트의 가격이 웹사이트의 실제 가격과 다르며, Google이 최신 페이지 대신 캐시된 버전을 반환하기 때문입니다.
행 수가 300-500을 초과 — 하나의 문서에서 IMPORTXML 수식이 많을수록 도메인에 대한 집단 차단의 가능성이 높아집니다.
1시간 이내의 빈도가 필요 — IMPORTXML은 실시간 모니터링을 위해 설계되지 않았으며, IP 회전 메커니즘이 없습니다.
웹사이트가 인증 또는 CAPTCHA를 요구 — Wildberries와 Ozon은 점점 더 JavaScript 검사를 요구하는 페이지를 표시하며, IMPORTXML은 이를 통과할 수 없습니다.

목록에서 2-3개 항목이 일치한다면, 이는 Google Sheets의 일시적인 오류가 아니라 기술의 구조적 한계입니다. 수식을 무한히 수정하고 IFERROR를 추가하며 수동으로 재계산할 수 있지만, 수작업의 양은 유용한 데이터의 양보다 더 빨리 증가할 것입니다.

웹사이트가 Google Sheets의 요청을 차단하는 이유

Wildberries 및 Ozon과 같은 마켓플레이스는 매일 경쟁자, 분석 서비스 및 봇으로부터 수백만 개의 자동 요청을 받습니다. 서버를 과부하하지 않고 가격 데이터의 대량 파싱으로부터 보호하기 위해 여러 수준의 보호 장치를 도입합니다:

IP에 대한 속도 제한 — 한 주소에서 분당 N 이상의 요청이 들어오면 IP가 일시적으로 차단됩니다.
User-Agent 분석 — IMPORTXML을 위한 Google 봇의 요청은 일반 브라우저와 헤더에서 쉽게 구별됩니다.
JavaScript 렌더링 — 일부 콘텐츠는 스크립트를 통해 동적으로 로드되며, IMPORTXML은 JS 실행 없이 원본 HTML만 볼 수 있습니다.
지리적 필터링 — Google의 서버 IP에서 오는 요청은 종종 "실제 구매자와 다름"이라는 필터에 걸립니다.

모든 IMPORTXML 사용자가 전 세계적으로 기술적으로 동일한 제한된 Google 서버 IP 주소 풀을 사용한다는 것이 주요 문제입니다. 수천 개의 시트가 동시에 동일한 Wildberries 도메인을 호출하면, 웹사이트의 보호 장치는 특정 사용자가 아닌 전체 범위를 차단하며, 이로 인해 모든 사용자가 피해를 입습니다.

IMPORTXML vs 노코드 파서 vs 자체 파서: 비교 표

Google Sheets의 내장 기능에서 전환하는 것이 반드시 프로그래머를 고용해야 한다는 것을 의미하지는 않습니다. 중간 옵션이 있습니다. 주요 매개변수에 따라 세 가지 접근 방식을 비교해 보겠습니다:

기준	IMPORTXML	노코드 파서 (Octoparse, ParseHub)	프록시가 있는 자체 파서
코드 필요	아니요	아니요	예 (또는 계약자)
요청 한계	엄격하고 숨겨져 있음	요금제에 따라 다름	직접 제어 가능
IP 회전	사용 불가	부분적으로 내장됨	프록시를 통한 완전한 제어
JS 페이지 작업	아니요	예	예 (Selenium/Playwright 사용)
업데이트 빈도	1시간에 한 번 또는 그 이하	조정 가능	실시간까지 모든 빈도 가능
규모 (SKU)	200-300개까지	수천 개까지	실질적인 제한 없음

노코드 파서는 개발자 없이 빠르게 문제를 해결해야 할 때 좋은 중간 단계입니다. 그러나 가격 모니터링이 일회성이 아닌 지속적인 비즈니스 프로세스라면, 프록시가 있는 자체 파서는 데이터에 대한 제어와 외부 서비스 및 그 한계에 대한 의존성의 부재로 인해 비용을 회수할 수 있습니다.

마켓플레이스 파싱에 필요한 프록시 종류

자체 파서가 IMPORTXML보다 안정적으로 작동하는 주요 이유는 Google의 단일 서버 풀 대신 다양한 IP 주소 간에 요청을 분산할 수 있기 때문입니다. 그러나 프록시의 종류도 중요합니다:

데이터 센터 프록시 — 시작하기에 가장 빠르고 저렴한 옵션입니다. 마켓플레이스가 자동 요청 패턴을 인식하지 못하는 경우에 적합합니다. 파서의 초기 테스트와 소수의 SKU에 적합합니다.
주거용 프록시 — 실제 가정용 ISP의 IP 주소를 사용하므로 Wildberries와 Ozon에 일반 구매자처럼 보입니다. 이는 대규모 가격 모니터링에 대한 주요 옵션으로, 지리적 차단이나 트래픽 패턴에 걸리지 않는 것이 중요합니다.
모바일 프록시 — 마켓플레이스가 극도로 잘 차단하지 않는 모바일 운영자의 IP입니다. 하나의 모바일 IP 뒤에는 종종 수천 명의 사용자가 동시에 존재합니다. 모바일 버전의 웹사이트나 애플리케이션을 통해 파싱이 필요한 경우에 적합합니다.

Wildberries와 Ozon의 가격 모니터링을 시작하기에 가장 적합한 조합은: 각 요청마다 또는 몇 분마다 IP 회전이 있는 주거용 프록시입니다. 이는 rate limit에 걸릴 위험을 줄이고 수천 개의 요청을 수백 개의 서로 다른 주소에 분산시켜 다양한 지역의 일반 사용자 행동을 모방할 수 있게 해줍니다.

자체 파서로 전환하기 위한 단계별 계획

IMPORTXML에서 전환하는 것은 작업을 완전히 중단할 필요가 없습니다. 새 파서가 테스트되는 동안 시트를 백업 채널로 남겨둘 수 있습니다.

IMPORTXML 수식에서 이미 사용된 SKU 및 XPath 선택자의 목록을 기록하세요 — 이는 새로운 솔루션을 위한 데이터 맵입니다.
파서 형식을 선택하세요: 프로그래머 없이 빠르게 시작할 수 있는 노코드 서비스 (Octoparse, ParseHub, Apify) 또는 팀에 개발자나 프리랜서가 있다면 Python/Node.js 스크립트를 선택하세요.
IP 회전이 있는 프록시를 연결하세요. 이를 하지 않으면 새 파서는 IMPORTXML과 동일한 차단에 직면하게 되며, 단지 조금 늦게 발생할 뿐입니다.
요청 간에 작은 무작위 지연을 설정하세요 (2-5초) — 이는 패턴에 따른 보호 장치가 작동할 가능성을 줄입니다.
Google Sheets API 또는 Zapier/Make와 같은 서비스를 통해 데이터를 Google Sheets로 다시 출력하세요 — 팀의 익숙한 보고서와 대시보드를 깨지 않도록 합니다.
10-15%의 상품에 대해 테스트하세요 — 이전 IMPORTXML 수식의 데이터와 정확성을 비교하며 일주일 동안 진행합니다. 완전히 전환하기 전에 확인하세요.
오류 알림을 설정하세요 — 파서가 CAPTCHA 또는 403 코드를 받기 시작하면 즉시 프록시를 변경하거나 요청 빈도를 줄일 수 있도록 Telegram 또는 이메일로 알림을 받습니다.

프록시를 사용한 Python의 최소 파서

팀에 개발자가 있다면, 기본 버전의 파서는 불과 몇십 줄의 코드로 구성됩니다. 아래는 requests 라이브러리를 사용하여 프록시를 통해 상품 페이지를 요청하는 단순화된 예입니다:

import requests
import time
import random

proxies = {
    "http": "http://login:password@proxy_host:port",
    "https": "http://login:password@proxy_host:port",
}

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36"
}

urls = [
    "https://example-marketplace.com/product/12345",
    "https://example-marketplace.com/product/67890",
]

for url in urls:
    try:
        response = requests.get(url, headers=headers, proxies=proxies, timeout=10)
        if response.status_code == 200:
            # 이후 BeautifulSoup 또는 lxml을 통해 가격 파싱
            print(f"OK: {url}")
        else:
            print(f"{url}의 상태 {response.status_code}")
    except requests.exceptions.RequestException as e:
        print(f"요청 오류: {e}")

    time.sleep(random.uniform(2, 5))  # 요청 간의 대기 시간

JavaScript를 통해 가격이 동적으로 로드되는 페이지 (Wildberries 및 Ozon에서 일반적)에서는 일반 requests 대신 Selenium 또는 Playwright가 필요합니다. 이들은 실제 브라우저처럼 페이지를 렌더링할 수 있으며, 프록시를 실행 매개변수를 통해 전달하는 것을 지원합니다.

시작 전 체크리스트

URL 목록과 데이터 선택자가 이전 IMPORTXML 수식에서 옮겨졌습니다.
프록시가 IP 회전과 함께 연결되었습니다 (마켓플레이스를 위한 주거용 또는 모바일).
요청 간의 무작위 지연이 설정되었습니다 (2-5초).
각 요청에 대해 현실적인 User-Agent와 브라우저 헤더가 설정되었습니다.
오류 로깅과 403/CAPTCHA 알림이 설정되었습니다.
데이터가 익숙한 형식으로 출력됩니다 (Google Sheets, CRM, BI 대시보드).
완전 전환 전에 상품의 하위 집합에서 1-2주 동안 테스트가 수행되었습니다.

결론

IMPORTXML은 상품 목록이 작고 업데이트 빈도가 중요하지 않을 때 훌륭한 도구입니다. 그러나 대량의 #N/A, 증가하는 지연 및 한계 오류 메시지가 나타나기 시작하면, 이는 Google Sheets의 내장 기능이 아키텍처적 한계에 도달했음을 나타냅니다. 기술적으로 이는 시트의 설정으로 해결할 수 없으며, 문제는 Google의 제한된 IP 주소 풀에 있습니다. 마켓플레이스는 이를 전체적으로 차단합니다.

자체 파서로 전환하는 것은, 노코드 서비스이든 Python 스크립트이든 요청의 IP 주소를 제어함으로써 문제를 해결합니다. Wildberries, Ozon 또는 Avito에서 대규모로 가격 모니터링을 계획하고 있다면, 주거용 프록시로 시작하는 것을 권장합니다 — 이는 실제 구매자 트래픽과의 유사성 덕분에 차단 위험이 가장 낮습니다. 초기 테스트를 위해서는 더 저렴한 데이터 센터 프록시로도 충분하며, 모바일 버전의 웹사이트를 위한 시나리오에서는 모바일 프록시를 고려해 볼 수 있습니다.