지난 주말, Amazon 베스트셀러 페이지 하나를 네 가지 방식으로 긁어보느라 커피 한 주전자를 다 비웠어요. 둘은 제법 잘 됐고, 하나는 IP 차단 직전까지 갔으며, 하나는 클릭 두 번으로 끝났어요. 그 과정에서 배운 걸 전부 정리해봤어요.
Amazon은 규모가 어마어마해요. 상품 등록 6억 개, 활성 고객 계정 3억 1천만 개, 매시간 갱신되는 Best Sellers Rank(BSR)까지 갖췄죠. FBA 상품 리서치, 경쟁 가격 분석, 경쟁사보다 한발 먼저 트렌드 잡기 — 어느 쪽이든 베스트셀러 데이터는 그야말로 금맥이에요.
그런데 이 데이터를 Amazon 밖으로 꺼내 스프레드시트에 담는 순간부터 일이 꼬여요. 그래서 이번엔 requests + BeautifulSoup, Selenium, 스크래핑 API, 그리고 Thunderbit(노코드 AI 웹 스크래퍼)까지 직접 돌려보며, 어떤 방식이 실제로 먹히고 어떤 방식이 CAPTCHA 화면만 남기는지 확인했어요.
Amazon 베스트셀러란 무엇이고, 왜 중요할까?
Amazon Best Sellers Rank(BSR)는 카테고리별로 판매량을 기준 삼아 상품 순위를 매기는 실시간 랭킹이에요. 최근 판매와 누적 판매를 함께 반영해 매시간 갱신되는 인기 순위라고 보면 돼요. Amazon의 설명은 이래요.
"Amazon Best Sellers 계산은 Amazon 판매 데이터를 기반으로 하며, Amazon에서 판매된 모든 상품의 최근 및 과거 판매를 반영하기 위해 매시간 업데이트돼요." — Amazon Seller Central
베스트셀러 페이지는 카테고리별 상위 100개 상품을 50개씩 두 페이지로 나눠 보여줘요. 1페이지는 150위, 2페이지는 51100위예요. Amazon은 페이지 조회수나 고객 리뷰가 BSR에 영향을 주지 않는다고 못 박았어요. 오직 판매량만 봐요.
이 데이터가 필요한 사람은 누굴까요? FBA 상품을 찾는 이커머스 셀러, 경쟁사 동향을 쫓는 세일즈팀, 가격 변동을 살피는 운영팀, 카테고리 성장세를 분석하는 시장 조사 담당자죠. 제 경험상 Amazon에서 팔든 Amazon과 경쟁하든, 결국 이 데이터를 스프레드시트로 정리해야 하는 순간이 와요.
왜 Python으로 Amazon 베스트셀러를 스크래핑할까?
수작업 상품 조사는 시간을 잡아먹어요. McKinsey 연구에 따르면 직원들은 주당 9.3시간을 정보 검색과 수집에 쓴다고 해요. 이커머스 팀이라면 Amazon 페이지를 하나씩 열어 상품명과 가격을 복사해 붙여넣는 데 몇 시간을 보내고, 다음 주에 똑같은 일을 또 반복하게 되죠.
베스트셀러 스크래핑이 실제로 쓸모 있는 대표 사례를 정리하면 이래요.
| 활용 사례 | 얻을 수 있는 것 | 도움이 되는 대상 |
|---|---|---|
| FBA 상품 리서치 | BSR과 리뷰 수를 기반으로 수요는 높고 경쟁은 낮은 상품 식별 | Amazon 셀러, 드랍쉬퍼 |
| 경쟁 가격 분석 | 카테고리 내 주요 상품들의 가격 변동 추적 | 이커머스 팀, 가격 분석가 |
| 시장 트렌드 모니터링 | 상승 중인 카테고리와 계절성 변화 포착 | 제품 관리자, 시장 조사 담당자 |
| 리드 생성 | 잘 팔리는 브랜드와 제품군 목록 구축 | 세일즈팀, B2B 아웃리치 |
| 경쟁사 분석 | 자사 제품을 카테고리 리더와 비교 | 브랜드 매니저, 전략팀 |
ROI도 뚜렷해요. Salesforce 조사에서 커머스 전문가 2,700명은 AI 도구로 주당 평균 6.4시간을 아낀다고 답했어요. 자동 가격 추적을 쓰는 판매자의 Buy Box 점유율은 67%로, 수동 추적의 42%를 크게 웃돌았어요. 가격 변화에 더 빨리 반응한 덕에 매출이 37% 늘어난 셈이에요.
Python으로 Amazon 베스트셀러를 긁는 4가지 방법: 한눈에 비교
단계별 설명에 들어가기 전에, 제가 처음 테스트할 때 미리 있었으면 했던 비교표부터 보여드릴게요. 상황에 맞는 방법을 고르는 데 도움이 될 거예요.
| 기준 | requests + BS4 | Selenium | 스크래핑 API (예: Scrape.do) | Thunderbit (노코드) |
|---|---|---|---|---|
| 설정 난이도 | 중간 | 높음(드라이버, 브라우저) | 낮음(API 키) | 매우 낮음(Chrome 확장 프로그램) |
| 지연 로딩 처리 | 불가 | 가능(스크롤 시뮬레이션) | 가능(렌더링된 HTML) | 가능(AI가 렌더링 처리) |
| 봇 차단 대응력 | 낮음(IP 차단) | 중간(탐지 가능) | 높음(프록시 자동 전환) | 높음(클라우드 + 브라우저 모드) |
| 유지보수 부담 | 높음(셀렉터 깨짐) | 높음(드라이버 업데이트 + 셀렉터) | 낮음 | 매우 낮음(AI가 레이아웃 변화에 적응) |
| 비용 | 무료 | 무료 | 유료(요청당 과금) | 무료 티어 + 유료 플랜 |
| 최적 용도 | 단발성 스크래핑, 학습용 | JS가 많은 페이지, 로그인 필요 페이지 | 대규모/프로덕션 | 비개발자, 빠른 리서치, 반복 모니터링 |
Python 스크래핑 기초를 익히려면 1번이나 2번부터 시작하세요. 프로덕션 수준 안정성이 필요하면 3번이 맞아요. 코드 한 줄 없이 클릭 두 번으로 결과를 보고 싶다면 바로 4번으로 가면 돼요.
시작하기 전에
- 난이도: 초급~중급(방법에 따라 다름)
- 소요 시간: Thunderbit 약 15분, Python 방식 약 45분
- 준비물: Python 3.8+(방법 1~3), Chrome 브라우저, Thunderbit Chrome 확장 프로그램(방법 4), 그리고 대상 Amazon 베스트셀러 카테고리 URL
방법 1: requests + BeautifulSoup으로 Amazon 베스트셀러 스크래핑하기
가장 가볍고 입문자 친화적인 방식이에요. 브라우저 자동화 없이 HTTP 요청과 HTML 파싱만 써요. 동시에 Amazon의 반스크래핑 방어가 얼마나 매서운지 가장 절절히 느끼게 해준 방법이기도 했어요.
1단계: 환경 설정
필요한 패키지를 깔아요.
pip install requests beautifulsoup4 pandas
그다음 import를 잡아요.
import requests
from bs4 import BeautifulSoup
import pandas as pd
import random
import time
2단계: 현실적인 헤더로 요청 보내기
Amazon은 봇 티가 나는 요청을 막아요. 가장 기본적인 방어선은 실제 브라우저처럼 보이게 하는 User-Agent 헤더예요. 아래는 지금 쓸 수 있는 현실적인 User-Agent 묶음이에요(Geekflare 기준, 2026년 3월).
USER_AGENTS = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 15.7; rv:149.0) Gecko/20100101 Firefox/149.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 15_7_5) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15",
]
headers = {"User-Agent": random.choice(USER_AGENTS)}
url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
response = requests.get(url, headers=headers)
print(response.status_code) # 200이어야 함
상태 코드가 200이면 성공이에요. 503이 뜨거나 CAPTCHA 페이지로 넘어가면 Amazon이 요청을 막은 거예요.
3단계: BeautifulSoup으로 상품 데이터 파싱하기
브라우저 개발자 도구로 Amazon 페이지 HTML을 들여다보세요(우클릭 → 검사). 상품 컨테이너는 gridItemRoot ID를 써요. 각 컨테이너 안에서 상품명, 가격, 평점, URL을 찾을 수 있어요.
soup = BeautifulSoup(response.text, "html.parser")
products = []
for item in soup.find_all("div", id="gridItemRoot"):
title_tag = item.find("div", class_="_cDEzb_p13n-sc-css-line-clamp-3_g3dy1")
price_tag = item.find("span", class_="_cDEzb_p13n-sc-price_3mJ9Z")
link_tag = item.find("a", class_="a-link-normal")
title = title_tag.get_text(strip=True) if title_tag else "N/A"
price = price_tag.get_text(strip=True) if price_tag else "N/A"
url = "https://www.amazon.com" + link_tag["href"] if link_tag else "N/A"
products.append({"Title": title, "Price": price, "URL": url})
주의:
_cDEzb_로 시작하는 클래스명은 Amazon이 주기적으로 다시 생성하는 CSS 모듈 해시예요.gridItemRootID와a-link-normal클래스는 비교적 안정적이지만, 스크래퍼를 돌리기 전에는 항상 DevTools로 셀렉터를 다시 확인하세요.
4단계: CSV로 내보내기
df = pd.DataFrame(products)
df.to_csv("amazon_best_sellers.csv", index=False)
print(f"{len(products)}개의 상품을 스크래핑했습니다")
결과와 한계
제 테스트에서는 이 방식이 50개가 아니라 30개쯤만 가져왔어요. 코드 오류가 아니라 Amazon의 지연 로딩 탓이에요. 초기 로딩 시점엔 약 30개만 렌더링되고, 나머지는 스크롤 후 JavaScript가 실행돼야 나오는데 requests는 그걸 못 다뤄요.
그 밖의 한계도 있어요.
- 프록시 전환이 없으면 IP 차단이 빨리 옵니다(저는 짧은 시간에 15번쯤 요청한 뒤 막혔어요)
- Amazon이 레이아웃을 바꾸면 CSS 셀렉터가 깨져요. 그리고 이런 일이 자주 일어나요
- 기본적으로 페이지네이션 처리가 없어요
Python 스크래핑을 배우기엔 좋지만, 프로덕션에는 취약해요.
방법 2: Selenium으로 Amazon 베스트셀러 스크래핑하기
Selenium은 실제 브라우저를 띄워 지연 로딩 문제를 풀어요. 설정은 더 무겁지만, 페이지당 50개 상품을 전부 가져올 수 있어요.
1단계: Selenium 설치하기
pip install selenium pandas
반가운 소식은 Selenium 4.6+부터 webdriver-manager가 필요 없다는 점이에요. Selenium Manager가 드라이버 다운로드를 알아서 처리해요.
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
import time
import pandas as pd
options = Options()
options.add_argument("--headless=new")
options.add_argument("--window-size=1920,1080")
options.add_argument("--disable-blink-features=AutomationControlled")
driver = webdriver.Chrome(options=options)
--headless=new 플래그(Chrome 109+ 도입)는 일반 Chrome과 같은 렌더링 파이프라인을 써서 Amazon이 탐지하기 더 어렵게 만들어요.
2단계: 지연 로딩을 넘기 위해 스크롤하기
이 단계가 바로 Selenium을 쓸 가치예요. Amazon 베스트셀러는 처음에 약 30개만 불러오고, 나머지는 스크롤해야 나타나요.
def scroll_page(driver, scrolls=5, delay=2):
for _ in range(scrolls):
driver.find_element(By.TAG_NAME, "body").send_keys(Keys.PAGE_DOWN)
time.sleep(delay)
driver.get("https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/")
time.sleep(3)
scroll_page(driver)
스크롤이 끝나면 50개 상품이 모두 DOM에 렌더링돼야 해요. 제 경우엔 2초 딜레이로 5번 페이지 다운하면 충분했지만, 네트워크 속도에 따라 조정이 필요할 수 있어요.
3단계: 상품 데이터 추출하기
items = driver.find_elements(By.ID, "gridItemRoot")
products = []
for item in items:
try:
title = item.find_element(By.CSS_SELECTOR, "div._cDEzb_p13n-sc-css-line-clamp-3_g3dy1").text
except:
title = "N/A"
try:
price = item.find_element(By.CSS_SELECTOR, "span._cDEzb_p13n-sc-price_3mJ9Z").text
except:
price = "N/A"
try:
url = item.find_element(By.CSS_SELECTOR, "a.a-link-normal").get_attribute("href")
except:
url = "N/A"
products.append({"Title": title, "Price": price, "URL": url})
각 항목을 try/except로 감싸는 게 중요해요. 품절 상품이거나 필드가 비어 있는 경우가 있어서, 요소 하나 때문에 전체 스크래핑이 멈추면 안 되거든요.
4단계: 페이지네이션 처리하기
Amazon은 100개 베스트셀러를 서로 다른 URL 구조의 두 페이지로 나눠요.
urls = [
"https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/",
"https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/ref=zg_bs_pg_2_electronics?_encoding=UTF8&pg=2"
]
all_products = []
for url in urls:
driver.get(url)
time.sleep(3)
scroll_page(driver)
# ... 위와 같은 방식으로 상품 추출 ...
all_products.extend(products)
driver.quit()
결과
제 테스트에서 Selenium은 페이지당 50개 상품을 전부 가져왔어요. requests + BS4보다 확실히 낫죠. 단점은 페이지당 약 45초가 걸렸고(스크롤 대기 포함), 프록시 전환 없이 너무 자주 돌리니 여전히 차단됐다는 점이에요. Selenium도 anti-detection 플래그를 써도 Amazon 봇 탐지에 걸릴 수 있어요. 규모가 크면 추가 대응이 필요해요(아래 Anti-Ban 가이드 참고).
그 외 거슬리는 점도 있어요.
- Selenium Manager 덕에 많이 줄긴 했지만, 여전히 WebDriver 버전 불일치가 가끔 터져요
- Amazon이 DOM을 바꾸면 CSS 셀렉터를 다시 맞춰야 해요
- 메모리를 많이 먹어요. 브라우저 인스턴스 하나당 200~400MB RAM을 차지해요
방법 3: 스크래핑 API로 Amazon 베스트셀러 스크래핑하기
스크래핑 API는 "어려운 건 남한테 맡기자"는 방식이에요. Scrape.do, Oxylabs, ScrapingBee 같은 서비스가 프록시 전환, JavaScript 렌더링, 봇 방어를 대신 처리해요. 사용자는 URL만 보내고 HTML이나 JSON을 받으면 돼요.
동작 방식
대상 URL을 API 엔드포인트로 보내면, API가 자체 인프라의 실제 브라우저로 페이지를 렌더링하고, 프록시를 바꾸고, CAPTCHA를 처리한 뒤 깨끗한 HTML을 돌려줘요. 그다음은 평소처럼 BeautifulSoup으로 파싱하면 끝이에요.
1단계: API를 통해 요청 보내기
아래는 Scrape.do 예시예요(요금은 150,000 크레딧에 월 $29부터 시작하며, 렌더링 여부와 상관없이 1크레딧 = 1요청이에요).
import requests
from bs4 import BeautifulSoup
api_token = "YOUR_API_TOKEN"
target_url = "https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/"
api_url = f"https://api.scrape.do?token={api_token}&url={target_url}&render=true&geoCode=us"
response = requests.get(api_url)
soup = BeautifulSoup(response.text, "html.parser")
이후 파싱은 방법 1과 똑같아요. 셀렉터도 같고, 추출 로직도 같아요.
가격 현실 점검
주요 API들의 Amazon 요청 1,000건당 비용을 최저 요율 기준으로 정리하면 이래요.
| 제공업체 | 1,000건당 비용 | 비고 |
|---|---|---|
| Scrape.do | 약 $0.19 | 크레딧 배수 없음, 정액형 |
| Oxylabs | 약 $1.80 | JS 렌더링 시 5배 배수 |
| ScrapingBee | 약 $4.90 | 프리미엄 기능에 따라 5~25배 배수 |
| Bright Data | $5.00+ | 데이터 범위는 가장 넓음(상품당 686개 필드) 하지만 가장 느림(요청당 약 66초) |
장단점
장점: 높은 안정성(Amazon 기준 상위 제공업체의 성공률 약 99%), 드라이버 유지보수 불필요, 봇 차단 자동 대응, 대규모 확장에 유리해요.
단점: 요청당 과금이라 규모가 커지면 비용이 쌓여요. 파싱 코드는 여전히 직접 짜야 하고, CSS 셀렉터 변경에도 취약해요. 월 100,000페이지 기준으로 보면 총비용 차이가 꽤 커요. 자체 구축은 3년 기준 약 $1,028,000, 외부 제공업체는 약 $293,000으로 71% 절감되거든요.
손익분기점은 보통 월 50만~100만 요청 수준이에요. 그 아래라면 API가 주는 시간 절약이 비용을 한참 앞서요.
방법 4: Thunderbit으로 Amazon 베스트셀러 스크래핑하기(Python 불필요)
먼저 밝혀둘게요. 저는 Thunderbit에서 일해요. 그러니 이 섹션은 그 점을 감안해서 봐주세요. 다만 네 가지 방법을 연달아 직접 돌려봤고, 데이터가 나오기까지 걸린 시간 차이는 정말 컸어요.
Thunderbit은 Chrome 확장 프로그램 형태의 AI 웹 스크래퍼예요. 핵심 발상은 이거예요. CSS 셀렉터나 Python 코드를 직접 쓰는 대신, AI가 페이지를 읽고 어떤 데이터를 뽑을지 판단해요. 특히 Amazon 베스트셀러는 원클릭으로 바로 쓰는 사전 제작 템플릿이 있어요.
1단계: Thunderbit Chrome 확장 프로그램 설치하기
Chrome 웹 스토어로 가서 "Chrome에 추가"를 누르세요. 무료 계정에 가입하면 테스트하기 충분한 크레딧을 받아요.
2단계: Amazon 베스트셀러 페이지 열기
Chrome에서 아무 Amazon 베스트셀러 카테고리 페이지나 열어요. 예를 들면 이런 식이에요.
https://www.amazon.com/Best-Sellers-Electronics/zgbs/electronics/
3단계: "AI Suggest Fields" 클릭하기
Thunderbit 사이드바를 열고 "AI Suggest Fields"를 누르세요. AI가 페이지 구조를 분석해 Product Name, Price, Rating, Image URL, Vendor, Product URL, Rank 같은 열을 제안해요. 제 테스트에서는 약 3초 만에 관련 필드를 전부 정확히 잡아냈어요.
열 이름을 바꾸거나 지우거나 더할 수 있어요. 각 필드에 맞춤 AI 프롬프트도 넣을 수 있는데, 예를 들어 "Electronics/Apparel/Home로 분류" 같은 지시를 넣어 상품마다 카테고리 태그를 붙일 수도 있어요.
4단계: "Scrape" 클릭하기
"Scrape" 버튼을 누르세요. Thunderbit가 페이지의 모든 상품 데이터를 구조화된 표로 채워줘요. 클라우드 모드에서는 최대 50페이지까지 병렬로 돌리면서 지연 로딩과 페이지네이션도 알아서 다뤄요.
5단계: 무료로 내보내기
"Export"를 누르고 대상 형식을 고르세요. Excel, Google Sheets, Airtable, Notion으로 보낼 수 있어요. 모든 플랜에서 내보내기는 무료예요. 숨은 비용도 없어요.
페이지를 연 순간부터 완성된 스프레드시트를 손에 쥐기까지 전체 과정이 약 90초밖에 안 걸렸어요. 비교하면 방법 1은 약 20분(지연 로딩 디버깅 포함), 방법 2는 약 35분(Selenium 설정 포함), 방법 3은 약 15분(API 계정 설정 포함)이었어요.
Thunderbit이 Amazon에 강한 이유
AI가 매번 페이지를 새로 읽으니 레이아웃이 바뀌어도 자동으로 적응해요. 즉, 관리할 CSS 셀렉터가 없어요. 이건 스크래핑 포럼에서 가장 흔한 불만, 즉 "기본 웹 스크래퍼로는 부족하고, 요소가 바뀔 때마다 예외 처리를 잔뜩 넣어야 한다"는 문제를 정면으로 풀어줘요. Amazon이 DOM을 바꿔도(실제로 자주 바뀌죠) 따로 손볼 필요가 없어요.
클라우드 스크래핑 모드는 프록시 전환, 렌더링, 봇 방어를 투명하게 처리해요. "그냥 됐으면 좋겠다"는 사용자에게는 이게 가장 큰 장점이에요. 차단 걱정을 거의 덜어주니까요.
Anti-Ban 플레이북: Amazon 차단을 피하는 방법
Amazon의 봇 탐지는 꽤 공격적이에요. 테스트 중에 제 IP도 잠깐 막혔고, 포럼 사용자들도 비슷한 얘기를 해요. "오류가 여기저기서 터지고, Amazon이 아예 홈으로 리디렉션하기 시작했다"는 식이죠. Python 방식(방법 1~3)을 쓴다면 이 섹션이 중요해요.
기본부터 고급까지 단계별 대응 전략을 정리할게요.
1. User-Agent 문자열을 번갈아 사용하기
같은 User-Agent를 반복하면 바로 수상하게 보여요. 방법 1 코드처럼 5개 이상 문자열 풀을 만들고, 요청마다 랜덤으로 고르세요.
headers = {"User-Agent": random.choice(USER_AGENTS)}
2. 요청 사이에 랜덤 지연 추가하기
고정 딜레이는 패턴으로 잡혀요. 랜덤 딜레이가 더 안전해요.
time.sleep(random.uniform(2, 5))
제 테스트에서는 요청 사이를 25초로 두면 소규모 배치(50건 미만)에서는 비교적 안전했어요. 더 큰 작업이라면 37초로 늘리는 편이 나아요.
3. 프록시 전환 사용하기
이게 가장 중요해요. Proxyway 벤치마크에 따르면 Amazon에서 residential proxy는 평균 약 94% 성공률을 보인 반면, 데이터센터 프록시는 약 59%에 그쳤어요. 무려 35%p 차이예요. Amazon의 탐지 스택에는 TLS fingerprinting, 행동 분석, IP별 rate limiting이 들어 있어서 일반 데이터센터 IP는 몇 초 만에 걸릴 수 있어요.
Residential proxy는 더 비싸지만(제공업체에 따라 GB당 $2~$12) 신뢰성이 훨씬 높아요. 예시는 이래요.
proxies = {
"http": "http://user:pass@residential-proxy.example.com:8080",
"https": "http://user:pass@residential-proxy.example.com:8080"
}
response = requests.get(url, headers=headers, proxies=proxies)
4. 브라우저 지문을 더 자연스럽게 만들기(Selenium)
options.add_argument('--disable-blink-features=AutomationControlled')
options.add_experimental_option("excludeSwitches", ["enable-automation"])
options.add_experimental_option('useAutomationExtension', False)
# 드라이버 초기화 후 navigator.webdriver 플래그 제거
driver.execute_cdp_cmd('Page.addScriptToEvaluateOnNewDocument', {
'source': "Object.defineProperty(navigator, 'webdriver', {get: () => undefined})"
})
5. 세션과 쿠키 관리하기
요청 사이에 쿠키를 유지하면 스크래퍼가 실제 사용자 세션처럼 보여요.
session = requests.Session()
# 먼저 홈페이지만 방문해 현실적인 쿠키 확보
session.get("https://www.amazon.com", headers=headers)
time.sleep(2)
# 그다음 대상 페이지 스크래핑
response = session.get(target_url, headers=headers)
6. 아예 번거로움을 건너뛰기
이런 걸 하나하나 챙기기 싫다면, Thunderbit의 클라우드 스크래핑이 프록시 전환, 렌더링, 봇 방어를 투명하게 처리해요. 스크래핑 API도 대부분의 문제를 기본으로 해결해줘요. 제 경험상 anti-ban 문제를 디버깅하는 시간이 정작 스크래핑 코드 짜는 시간보다 길어지는 경우가 많아요. 그래서 "그냥 되는" 방식은 실제로 ROI가 있어요.
서브페이지 확장: 더 풍부한 데이터를 위해 상품 상세페이지 스크래핑하기
베스트셀러 목록 페이지에는 상품명, 가격, 평점, 순위 같은 기본 정보만 나와요. 정작 FBA 리서치에서 진짜 값진 정보는 개별 상품 상세페이지에 있어요. 목록 페이지만 긁으면 놓치는 항목을 정리하면 이래요.
| 필드 | 목록 페이지 | 상품 상세페이지 |
|---|---|---|
| 상품명 | ✅ | ✅ |
| 가격 | ✅ | ✅ |
| 평점 | ✅ | ✅ |
| BSR 순위 | ✅ | ✅(하위 카테고리 순위 포함) |
| 브랜드 | ❌ | ✅ |
| ASIN | ❌ | ✅ |
| 최초 판매일 | ❌ | ✅ |
| 크기/무게 | ❌ | ✅ |
| 판매자 수 | ❌ | ✅ |
| 핵심 기능 항목 | ❌ | ✅ |
| Buy Box 보유자 | ❌ | ✅ |
특히 "최초 판매일"이 아주 유용해요. 상품이 시장에 얼마나 오래 있었는지 보여주니 경쟁 분석의 핵심 신호가 돼요. 판매자 수와 Buy Box 보유자를 알면 특정 상품군에 진입할 만한지 판단하는 데도 도움이 돼요(Amazon 자체가 Buy Box의 30% 이상을 차지한다면 경쟁이 상당히 빡빡해요).
Python 방식: 상품 URL을 돌면서 상세 정보 수집하기
목록 페이지에서 상품 URL을 모은 뒤, 각 URL을 지연을 두고 순회해요.
for product in products:
time.sleep(random.uniform(3, 6))
detail_response = session.get(product["URL"], headers={"User-Agent": random.choice(USER_AGENTS)})
detail_soup = BeautifulSoup(detail_response.text, "html.parser")
# 브랜드 추출
brand_tag = detail_soup.find("a", id="bylineInfo")
product["Brand"] = brand_tag.get_text(strip=True) if brand_tag else "N/A"
# 페이지 소스 또는 URL에서 ASIN 추출
# 상품 상세 정보 표에서 최초 판매일 추출
# ... 추가 필드 ...
주의할 점은, 개별 상품 페이지 100개를 연속으로 긁으면 차단 위험이 확 올라간다는 거예요. 프록시 전환과 더 긴 지연 시간을 예산에 미리 넣어두세요.
Thunderbit 방식: 원클릭 서브페이지 스크래핑
목록 페이지를 표로 만든 뒤 Thunderbit에서 "Scrape Subpages"를 누르세요. AI가 각 상품 URL을 방문해 브랜드, ASIN, 사양, 기능 같은 추가 열을 자동으로 채워줘요. 추가 코드도, 셀렉터도, 설정도 필요 없어요. 소싱 결정을 위해 전체 그림이 필요하지만 상세페이지 파서를 직접 만들고 유지하긴 싫은 이커머스 팀에 특히 유용해요.
반복 스크래핑 자동화: 시간에 따라 베스트셀러 모니터링하기
한 번 긁는 것도 쓸모 있지만, 진짜 경쟁 우위는 꾸준한 모니터링에서 나와요. 어떤 상품이 오르내리는지, 트렌드가 언제 시작되는지, 수주~수개월에 걸친 가격 변화를 쫓는 것 — 이게 단순 리서치와 데이터 기반 의사결정을 가르는 차이예요.
Python 방식: cron으로 예약 실행하기
Linux/Mac에서는 cron으로 Python 스크립트를 예약할 수 있어요. 매일 오전 8시 실행하는 crontab 예시는 이래요.
0 8 * * * /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1
매주 월요일 오전 9시 실행은 이래요.
0 9 * * 1 /usr/bin/python3 /home/user/amazon_scraper.py >> /home/user/logs/scrape.log 2>&1
Windows에서는 Task Scheduler를 쓰면 돼요. 노트북을 켜두지 않고 계속 돌리고 싶다면 VPS나 AWS Lambda에 배포할 수도 있지만, 그만큼 인프라 복잡도가 늘어나요.
로그와 오류 알림도 꼭 넣으세요. 스크래퍼가 2주 전에 조용히 망가진 걸 나중에 발견하는 것만큼 답답한 일도 없거든요.
Thunderbit 방식: 자연어로 쓰는 Scheduled Scraper
Thunderbit의 Scheduled Scraper는 자연어로 간격을 지정할 수 있어요. "매주 월요일 오전 9시"나 "매일 오전 8시"처럼 입력하면 AI가 일정을 해석해요. 스크래핑은 Thunderbit 클라우드 서버에서 돌기 때문에 브라우저나 컴퓨터를 켜둘 필요가 없고, 데이터는 Google Sheets나 Airtable로 자동 내보내기 돼요. 서버 관리 없이 실시간 모니터링 대시보드를 만들 수 있어서, DevOps 부담 없이 꾸준한 관찰이 필요한 운영팀에 잘 맞아요.
Amazon 스크래핑 시 법적·윤리적 고려사항
저는 변호사가 아니고, 이 내용은 법률 자문이 아니에요. 그래도 스크래핑 튜토리얼에서 법적 이슈를 빼는 건 무책임하죠. 포럼 사용자들도 ToS 문제를 분명히 제기하는데, 그럴 만한 이유가 있어요.
Amazon robots.txt: 2026년 기준 Amazon의 robots.txt에는 구체적인 Disallow 경로가 80개 넘게 있지만, /gp/bestsellers/는 표준 사용자 에이전트 기준으로 명시적으로 막혀 있지 않아요. 다만 ClaudeBot, GPTBot, Scrapy 등 35개 이상 AI 전용 사용자 에이전트에는 Disallow: /가 일괄 적용돼요. 특정 경로가 안 막혔다고 해서 Amazon이 스크래핑을 허락한다는 뜻은 아니에요.
Amazon 이용 약관: Amazon의 Conditions of Use(2025년 5월 업데이트)는 서면 허가 없이 "Amazon 웹사이트의 일부에 접근, 수집, 복사 또는 모니터링하기 위해 자동화된 프로세스나 기술을 사용하는 것"을 명시적으로 금지해요. 이론에 그치는 얘기가 아니에요. Amazon은 2025년 11월 Perplexity AI를 상대로 소송을 냈고, 무단 자동 접근과 관련해 예비금지명령도 받아냈어요.
hiQ v. LinkedIn 판례: hiQ Labs v. LinkedIn(제9순회항소법원, 2022)에서는 공개 데이터 스크래핑이 CFAA(컴퓨터 사기 및 남용 방지법)를 위반하지 않을 가능성이 높다고 봤어요. 하지만 hiQ는 결국 합의했고 스크래핑을 중단하기로 했어요. CFAA에서 이긴다고 계약 위반 책임까지 사라지는 건 아니에요.
실무 가이드라인:
- 공개된 데이터만 스크래핑하세요(가격, BSR, 상품명 등. PII는 제외)
- 요청 속도를 지키고 서버에 과부하를 주지 마세요
- 정당한 경쟁 정보 수집 목적에만 쓰세요
- 대규모 스크래핑 전에는 반드시 법률 자문을 받으세요
- 미국 20개 이상의 주가 이미 포괄적 개인정보보호 법제를 갖췄다는 점을 인지하세요
Thunderbit의 클라우드 스크래핑은 일반 브라우저와 비슷한 요청 패턴을 쓰지만, 그래도 적법성은 항상 자체 법률 자문과 함께 확인하세요.
어떤 방법을 써야 할까? 빠른 결정 가이드
짧게 정리하면 이래요.
- "Python을 배우는 중이고 주말 프로젝트를 하고 싶다." → 방법 1(requests + BeautifulSoup). HTTP 요청, HTML 파싱, Amazon의 봇 방어를 많이 배울 수 있어요.
- "JavaScript가 많은 페이지나 로그인 세션을 스크래핑해야 한다." → 방법 2(Selenium). 더 무겁지만 동적 콘텐츠를 다룰 수 있어요.
- "대규모 프로덕션 스크래핑을 운영 중이다." → 방법 3(스크래핑 API). 프록시와 렌더링 관리는 남한테 맡기세요. 총소유비용도 월 50만 요청 이하라면 API 쪽이 유리해요.
- "개발자가 아니고 2분 안에 데이터를 보고 싶다." → 방법 4(Thunderbit). 코드도, 셀렉터도, 유지보수도 없어요.
- "서버 관리 없이 계속 모니터링하고 싶다." → Thunderbit Scheduled Scraper. 설정해두고 잊어버리면 돼요.
결론과 핵심 요약
주말 동안 테스트해본 뒤 실제로 남은 결론은 이래요.
requests + BeautifulSoup는 배우기엔 좋지만, 지연 로딩 제한(50개 중 약 30개만 표시)과 깨지기 쉬운 CSS 셀렉터 때문에 프로덕션에는 안 맞아요.
Selenium은 지연 로딩 문제를 풀고 페이지당 50개 상품을 다 가져오지만, 느리고 메모리를 많이 쓰며 여전히 Amazon 봇 방어에 걸릴 수 있어요.
스크래핑 API는 프로덕션 규모 스크래핑에서 가장 안정적이에요. Amazon 기준 약 99% 성공률을 주지만, 비용이 쌓이고 파싱 코드는 여전히 직접 짜야 해요.
Thunderbit는 데이터를 손에 쥐기까지 압도적으로 가장 빨랐어요. AI가 레이아웃 변화, 지연 로딩, 페이지네이션, 봇 방어를 별도 설정 없이 처리해요. 비개발자나 DevOps 부담 없이 반복 데이터가 필요한 팀에게 가장 실용적인 선택이에요.
가장 큰 교훈은 하나예요. Amazon의 매서운 봇 방어와 잦은 레이아웃 변경을 생각하면, 유지보수가 거의 없는 솔루션이 길게 보면 가장 많은 시간을 아껴줘요. 깨진 셀렉터를 고치고 프록시를 돌리는 데 쓰는 한 시간은, 원래 분석에 써야 할 한 시간이거든요.
노코드 방식을 직접 써보고 싶다면 Thunderbit 무료 티어로 베스트셀러 카테고리 몇 개를 긁어 결과를 확인해보세요. Python 방식을 선호한다면 위 코드 예시로 시작하면 돼요. 어느 쪽이든, Amazon 베스트셀러 데이터가 브라우저 탭에만 머무르지 않고 스프레드시트에 들어가 있게 될 거예요.
웹 스크래핑 방식을 더 알고 싶다면 Amazon 상품과 리뷰 스크래핑 방법, 웹사이트 데이터를 Excel로 추출하는 방법, 최고의 AI 웹 스크래퍼 가이드를 참고하세요. Thunderbit YouTube 채널에서 단계별 시연 영상도 볼 수 있어요.
더 읽어보기
