Amazon 튜토리얼을 그대로 따라 했는데 CAPTCHA, 503 오류, 텅 빈 결과만 받았다면, 그건 당신 잘못이 아니에요. 검색에 걸리는 Python Amazon 스크래핑 글의 상당수는 2022~2023년에 쓰였고, Amazon이 이미 막은 셀렉터와 방식을 그대로 쓰고 있거든요.
Thunderbit에서 몇 년째 데이터 추출 도구를 만들면서 확실히 느낀 게 하나 있어요. 안정적으로 긁기 가장 까다로운 사이트 중 하나가 Amazon이에요. HTML 구조가 수시로 바뀌고, 6단계 anti-bot 방어를 돌리고, A/B 테스트로 사용자마다 다른 레이아웃을 보여주기까지 하죠. 이 글은 2025년에도 실제로 도는 Python Amazon 스크래퍼를 다뤄요. 검증된 CSS 셀렉터, 여러 겹의 차단 회피, 그리고 대부분 튜토리얼이 통째로 빼먹는 스케줄링과 내보내기까지요. Python을 직접 안 만지고 데이터만 바로 받고 싶은 분께는 Thunderbit로 같은 일을 클릭 몇 번에 끝내는 방법도 보여드릴게요.
Amazon 상품 스크래핑이란?
상품 상세 페이지나 검색 결과에서 상품명, 가격, 평점, 리뷰 수, 이미지, 재고 같은 공개 데이터를 프로그램으로 뽑아내는 작업이에요. 수백 개 상품을 일일이 손으로 복사하는 대신, 스크래퍼가 페이지를 돌며 HTML을 읽고 원하는 값을 CSV, Excel, 데이터베이스 같은 형식으로 정리해 줘요.
커피 한 잔 마시는 사이에 상품 페이지 천 개를 대신 확인해 주는, 지치지 않는 인턴 한 명을 두는 셈이에요. 오타도 없고 점심시간도 안 챙겨도 되는 인턴이죠.
왜 Python으로 Amazon 상품을 스크래핑할까요?
Amazon에는 30개 넘는 카테고리에 걸쳐 약 3억 5천만~6억 개의 상품이 올라와 있고, 약 970만 개의 셀러 계정이 이 판을 돌려요. 전체 GMV의 69%가 이제 서드파티 셀러 몫이에요. 이 규모를 사람 손으로 일부라도 추적하는 건 사실상 불가능해요. 그래서 많은 팀이 Amazon을 긁는 거예요.
| 활용 사례 | 도움이 되는 사람 | 추출하는 데이터 |
|---|---|---|
| 가격 모니터링 및 재가격 조정 | 이커머스 운영팀, 마켓플레이스 셀러 | 가격, 재고 여부, 셀러 정보 |
| 경쟁사 분석 | 제품 매니저, 브랜드 팀 | 상품 기능, 평점, 리뷰 수 |
| 시장 조사 | 분석가, 신제품 팀 | 카테고리 트렌드, 가격 분포 |
| 리드 생성 | 영업팀 | 셀러 이름, 브랜드 정보, 연락처 |
| 제휴 마케팅 | 콘텐츠 제작자, 딜 사이트 | 가격, 할인 정보, 상품 상세 |
| 재고 추적 | 공급망, 구매팀 | 재고 상태, 배송 예상 |
가격이 바뀌는 속도만 봐도 자동화는 선택이 아니에요. Amazon은 하루 250만 회 이상 가격을 바꾸고, 평균 상품은 약 10분마다 값이 갱신돼요. Best Buy나 Walmart는 한 달에 5만 회쯤이고요. 이 속도를 사람이 손으로 따라잡을 방법은 없어요.
Python의 장점은 통제권이에요. 무엇을 뽑을지, 오류를 어떻게 다룰지, 어디에 저장할지 전부 직접 정해요. 대신 유지보수, 차단 회피, Amazon의 잦은 HTML 변경 대응도 전부 본인 몫이고요.
Amazon에서 무엇을 스크래핑할 수 있고, 무엇은 피해야 할까요?
공개된 상품 페이지에서 보통 뽑을 수 있는 항목이에요.
- 상품명(이름, 브랜드)
- 가격(현재가, 정가, 할인 가격)
- 평점(별점 평균)
- 리뷰 수
- 상품 이미지(메인 이미지 URL)
- 재고 / 판매 여부
- ASIN(Amazon Standard Identification Number)
- 상품 설명 및 핵심 포인트
- 셀러 정보
- 상품 옵션(사이즈, 색상 등)
반면 이런 건 손대지 마세요.
- 로그인 벽 뒤의 데이터: 확장 리뷰 페이지, 개인 계정 정보, 주문 내역
- 개인 정보: 구매자 이름, 주소, 결제 정보
- 재배포용 저작권 콘텐츠: 상품 설명과 이미지는 분석용으로는 괜찮지만, 내 콘텐츠인 양 다시 뿌리면 안 돼요
Amazon robots.txt는 GPTBot, Scrapy, ClaudeBot을 포함해 봇 50개 이상을 막고, 계정·장바구니·위시리스트 경로도 금지해요. 상품 상세 페이지 자체는 대놓고 막혀 있진 않지만, 서비스 약관은 자동 접근을 금지하죠. 법원은 보통 약관 위반(민사)과 CFAA에 따른 형사 위반을 구분해 왔어요. 이 얘기는 글 마지막에서 다시 다룰게요.
필요한 도구와 라이브러리
이 튜토리얼에서 쓸 Python 스택이에요.
| 라이브러리 | 용도 | 사용 이유 |
|---|---|---|
requests | HTTP 요청 | 간단하고 널리 지원됨 |
beautifulsoup4 | HTML 파싱 | CSS 셀렉터 기반 추출이 쉬움 |
lxml | 빠른 HTML 파서 | BeautifulSoup의 파서 백엔드로 사용 |
curl_cffi | TLS 지문 위장 | Amazon 탐지를 우회하는 데 핵심 |
pandas | 데이터 정리 및 내보내기 | DataFrame, CSV/Excel 출력 |
선택 사항(JavaScript 렌더링 콘텐츠용):
selenium또는playwright— 헤드리스 브라우저 자동화
Python 환경 설정하기
터미널을 열고 아래 명령을 실행하세요.
mkdir amazon-scraper && cd amazon-scraper
python -m venv venv
source venv/bin/activate # Windows: venv\Scripts\activate
pip install requests beautifulsoup4 lxml curl_cffi pandas
제대로 깔렸는지 확인해 볼게요.
import requests, bs4, curl_cffi, pandas
print("All good!")
오류 없이 "All good!"가 찍히면 준비 끝이에요.
대부분의 Amazon 스크래핑 튜토리얼이 실패하는 이유와, 이 글이 다른 점
여기가 다른 가이드들이 건너뛰는 대목이에요. 아마 지금 이 글을 보고 계신 이유이기도 하겠죠.
Amazon은 HTML 구조, 클래스 이름, 요소 ID를 수시로 바꿔요. 업계에선 DOM과 지문(fingerprint) 변화 탓에 매주 크롤러의 10~15%가 손봐야 한다고 봐요. 가장 유명한 희생양은 #priceblock_ourprice예요. 2018~2023년 튜토리얼 수백 개에 등장했지만, 지금 상품 페이지엔 이 ID가 아예 없어요.
무엇이 깨졌고 지금은 무엇이 도는지 비교해 볼게요.
| 데이터 항목 | 깨진 셀렉터(2024년 이전) | 2025년 작동 셀렉터 |
|---|---|---|
| 가격 | #priceblock_ourprice | div#corePriceDisplay_desktop_feature_div span.a-price .a-offscreen |
| 제목 | #productTitle | span#productTitle (여전히 작동) |
| 평점 | span.a-icon-alt (때때로 문맥 오류) | #acrPopover span.a-icon-alt |
| 리뷰 수 | #acrCustomerReviewCount | span#acrCustomerReviewText |
| 재고 여부 | #availability span | div#availability span.a-size-medium |
이 글의 코드 예시는 전부 2025년 실제 Amazon 페이지에서 돌려봤어요. 2022년식 복붙이 아니라, 실제로 도는 CSS 셀렉터와 예상 결과를 같이 보여드려요.
시작하기 전에
- 난이도: 중급 (기본 Python 지식 필요)
- 소요 시간: 전체 약 30~45분, 기본 스크래퍼만이면 약 10분
- 준비물: Python 3.9+, Chrome 브라우저(Amazon 페이지 확인용), 터미널, 그리고 노코드 방식과 비교해 보고 싶다면 Thunderbit Chrome Extension
1단계: Amazon에 첫 요청 보내기
브라우저에서 아무 상품 페이지나 열고 URL을 복사해요. 일단 단순한 requests.get()부터 가볼게요.
import requests
url = "https://www.amazon.com/dp/B0DGNFM9YJ"
response = requests.get(url)
print(response.status_code)
print(response.text[:500])
이걸 돌리면 거의 무조건 503 상태 코드가 뜨거나, "To discuss automated access to Amazon data please contact…" 같은 문구가 든 페이지가 나와요. Amazon WAF(Web Application Firewall)가 Python 스크립트를 잡아낸 거예요. 헤더도 없이 그냥 던진 requests.get()의 Amazon 성공률은 약 2%에 불과해요.
보통 503과 차단 페이지 HTML이 찍힐 거예요. 정상이에요. 다음 단계에서 풀어요.
2단계: 사용자 정의 헤더와 TLS 지문 위장 설정하기
이제 User-Agent 하나 추가하는 걸로는 어림없어요. Amazon은 HTTP 헤더와 TLS 지문을 짝 맞춰 봐요. Chrome 120이라고 우기면서 TLS 핸드셰이크엔 Python requests 흔적이 남으면, 곧장 차단 대상으로 찍혀요.
2025년 기준 가장 믿을 만한 건 브라우저 위장을 지원하는 curl_cffi예요.
from curl_cffi import requests as cfreq
headers = {
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
"Accept-Encoding": "gzip, deflate, br",
"Referer": "https://www.google.com/",
"DNT": "1",
"Connection": "keep-alive",
"Upgrade-Insecure-Requests": "1",
}
url = "https://www.amazon.com/dp/B0DGNFM9YJ"
response = cfreq.get(url, headers=headers, impersonate="chrome124")
print(response.status_code)
print(len(response.text))
curl_cffi로 Chrome 124를 위장하면 성공률이 약 94%까지 올라가요. 일반 requests보다 47배 나아진 셈이죠. 이제 200 상태 코드와 한참 긴 HTML(10만 자 이상)이 보일 거예요.
그래도 503이 뜨면 impersonate 값을 "chrome131" 같은 걸로 바꿔 다시 시도하거나, 잠깐 쉬었다 재시도하세요.
3단계: HTML 파싱 후 상품 데이터 추출하기
전체 HTML을 확보했으니, 검증된 2025년 셀렉터로 데이터를 뽑아볼게요.
from bs4 import BeautifulSoup
soup = BeautifulSoup(response.text, "lxml")
# 상품 제목
title_el = soup.select_one("span#productTitle")
title = title_el.get_text(strip=True) if title_el else None
# 가격
price_el = soup.select_one(
"div#corePriceDisplay_desktop_feature_div span.a-price .a-offscreen"
)
if not price_el:
price_el = soup.select_one("span.priceToPay .a-offscreen")
if not price_el:
price_el = soup.select_one(".apexPriceToPay .a-offscreen")
price = price_el.get_text(strip=True) if price_el else None
# 평점
rating_el = soup.select_one("#acrPopover span.a-icon-alt")
rating = rating_el.get_text(strip=True) if rating_el else None
# 리뷰 수
reviews_el = soup.select_one("span#acrCustomerReviewText")
reviews = reviews_el.get_text(strip=True) if reviews_el else None
# 재고 상태
avail_el = soup.select_one("div#availability span")
availability = avail_el.get_text(strip=True) if avail_el else None
# 메인 이미지 URL
img_el = soup.select_one("#landingImage")
image_url = img_el.get("src") if img_el else None
print(f"Title: {title}")
print(f"Price: {price}")
print(f"Rating: {rating}")
print(f"Reviews: {reviews}")
print(f"Availability: {availability}")
print(f"Image: {image_url}")
예상 출력은 이런 식이에요.
Title: Apple AirPods Pro (2nd Generation) with USB-C
Price: $189.99
Rating: 4.7 out of 5 stars
Reviews: 98,432 ratings
Availability: In Stock
Image: https://m.media-amazon.com/images/I/61SUj2...
가격에 대체 셀렉터를 여러 개 둔 이유가 있어요. Amazon이 상품 유형, 할인 여부, A/B 테스트 버전에 따라 다른 컨테이너를 쓰거든요. 각 추출을 조건문으로 감싸 두면, 셀렉터가 안 맞아도 스크래퍼가 멈추지 않아요.
4단계: 검색 결과에서 여러 상품 스크래핑하기
진짜 데이터셋을 만들려면 검색 결과 페이지에서 ASIN을 모은 뒤, 각 상품 상세 페이지를 긁어야 해요.
import time
import random
def get_search_asins(keyword, max_pages=1):
"""Amazon 검색 결과에서 ASIN을 수집합니다."""
asins = []
for page in range(1, max_pages + 1):
search_url = f"https://www.amazon.com/s?k={keyword}&page={page}"
resp = cfreq.get(search_url, headers=headers, impersonate="chrome124")
if resp.status_code != 200:
print(f"Search page {page} returned {resp.status_code}")
break
search_soup = BeautifulSoup(resp.text, "lxml")
results = search_soup.select('div[data-component-type="s-search-result"]')
for r in results:
asin = r.get("data-asin")
if asin:
asins.append(asin)
print(f"Page {page}: found {len(results)} products")
time.sleep(random.uniform(2, 5)) # 예의 있는 지연
return asins
asins = get_search_asins("wireless+earbuds", max_pages=2)
print(f"Collected {len(asins)} ASINs")
ASIN마다 https://www.amazon.com/dp/{ASIN} 형태의 깔끔한 상품 URL이 만들어져요. 세션 파라미터가 붙기 쉬운 검색 결과 전체 URL보다 훨씬 안정적이고요.
5단계: 페이지네이션 처리와 대량 스크래핑
검색 수집과 상세 페이지 스크래핑을 하나의 파이프라인으로 묶어볼게요.
import pandas as pd
def scrape_product(asin):
"""단일 Amazon 상품 상세 페이지를 스크래핑합니다."""
url = f"https://www.amazon.com/dp/{asin}"
try:
resp = cfreq.get(url, headers=headers, impersonate="chrome124")
if resp.status_code != 200:
return None
soup = BeautifulSoup(resp.text, "lxml")
title_el = soup.select_one("span#productTitle")
price_el = (
soup.select_one("div#corePriceDisplay_desktop_feature_div span.a-price .a-offscreen")
or soup.select_one("span.priceToPay .a-offscreen")
or soup.select_one(".apexPriceToPay .a-offscreen")
)
rating_el = soup.select_one("#acrPopover span.a-icon-alt")
reviews_el = soup.select_one("span#acrCustomerReviewText")
avail_el = soup.select_one("div#availability span")
img_el = soup.select_one("#landingImage")
return {
"asin": asin,
"title": title_el.get_text(strip=True) if title_el else None,
"price": price_el.get_text(strip=True) if price_el else None,
"rating": rating_el.get_text(strip=True) if rating_el else None,
"reviews": reviews_el.get_text(strip=True) if reviews_el else None,
"availability": avail_el.get_text(strip=True) if avail_el else None,
"image_url": img_el.get("src") if img_el else None,
"url": url,
}
except Exception as e:
print(f"Error scraping {asin}: {e}")
return None
# 수집한 ASIN 전체 스크래핑
products = []
for i, asin in enumerate(asins):
print(f"Scraping {i+1}/{len(asins)}: {asin}")
product = scrape_product(asin)
if product:
products.append(product)
time.sleep(random.uniform(2, 5)) # 요청 사이 무작위 지연
df = pd.DataFrame(products)
print(f"\nScraped {len(df)} products successfully")
print(df.head())
2~5초 무작위 지연이 핵심이에요. 매번 정확히 3초처럼 일정한 간격은 Amazon의 행동 분석에서 수상하게 보여요. 무작위 간격이 사람의 브라우징을 더 그럴듯하게 흉내 내죠.
6단계: 스크래핑한 Amazon 데이터를 CSV로 저장하기
df.to_csv("amazon_products.csv", index=False, encoding="utf-8-sig")
print("Saved to amazon_products.csv")
이제 ASIN, 제목, 가격, 평점, 리뷰, 재고, 이미지 URL, 상품 URL이 담긴 깔끔한 CSV가 생겼어요. 대부분 튜토리얼은 여기서 끝나지만, 실제 업무 흐름을 짜려면 CSV는 시작일 뿐이에요.
차단 회피 심화: 스크래퍼를 오래 살리는 방법
Python으로 Amazon을 긁으려는 사람들의 1순위 골칫거리는 차단이에요. Amazon의 6단계 방어엔 IP 평판 분석, TLS 지문 채집, 브라우저 환경 검사, 행동 생체 인식, CAPTCHA, ML 기반 이상 탐지가 들어가요. 아래에서 각각에 맞붙는 계층형 전략을 정리할게요.
User-Agent와 전체 헤더를 순환하기
고정된 User-Agent 하나는 금세 들켜요. 최신 브라우저 문자열을 여러 개 두고 번갈아 쓰세요.
import random
USER_AGENTS = [
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15",
]
def get_headers():
return {
"User-Agent": random.choice(USER_AGENTS),
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
"Accept-Encoding": "gzip, deflate, br",
"Referer": "https://www.google.com/",
"DNT": "1",
"Connection": "keep-alive",
}
놓치기 쉬운 포인트 하나. Accept-Language는 IP의 지리적 위치와 맞아야 해요. 독일 IP에서 Accept-Language: en-US를 보내면 위험 신호로 보일 수 있어요.
curl_cffi로 TLS 지문 위장하기
2단계에서 이미 다뤘지만, 효과만큼은 다시 강조할 만해요. 이 한 가지가 성공률을 가장 크게 끌어올려요. 일반 Python requests는 Amazon 성공률 약 2%, curl_cffi 위장을 쓰면 약 94%예요. 도는 스크래퍼냐, 고장 난 스크래퍼냐를 가르는 지점이죠.
from curl_cffi import requests as cfreq
# 위장 대상 브라우저도 번갈아 사용
BROWSERS = ["chrome120", "chrome124", "chrome131"]
response = cfreq.get(
url,
headers=get_headers(),
impersonate=random.choice(BROWSERS),
)
프록시 순환하기
몇 페이지 넘게 긁으려면 프록시 순환이 필요해요. Amazon은 IP를 추적하고, 한 IP에서 요청이 몰리면 차단하거든요.
PROXIES = [
"http://user:pass@proxy1.example.com:8080",
"http://user:pass@proxy2.example.com:8080",
"http://user:pass@proxy3.example.com:8080",
]
proxy = random.choice(PROXIES)
response = cfreq.get(
url,
headers=get_headers(),
impersonate="chrome124",
proxies={"http": proxy, "https": proxy},
)
데이터센터 프록시보다 주거용 프록시가 잘 먹혀요. Amazon이 데이터센터 IP 대역을 미리 차단하는 편이거든요. 대신 비용은 더 비싸고요. 작은 프로젝트라면 유료 프록시 서비스부터 시작해 필요할 때 늘리면 돼요.
속도 제한과 지수 백오프
경쟁 글에선 거의 안 다루지만 정말 중요해요. 503이나 CAPTCHA를 받았을 때 곧장 다시 던지지 마세요. 그건 영구 차단으로 가는 지름길이에요.
import time
import random
def fetch_with_backoff(url, max_retries=3):
"""실패 시 지수 백오프로 URL을 가져옵니다."""
for attempt in range(max_retries):
response = cfreq.get(
url,
headers=get_headers(),
impersonate=random.choice(BROWSERS),
)
if response.status_code == 200:
return response
# 지터가 포함된 지수 백오프
wait = min(2 ** attempt + random.uniform(0, 1), 30)
print(f"Attempt {attempt+1} failed ({response.status_code}). Waiting {wait:.1f}s...")
time.sleep(wait)
return None # 재시도 종료
wait = min(2^attempt + jitter, max_delay) 공식은 지연을 2초, 4초, 8초로 늘리되 한없이 길어지진 않게 해요. 무작위 지터는 재시도 패턴이 기계처럼 보이지 않게 막아주고요.
JavaScript 렌더링 콘텐츠를 위한 Selenium 또는 Playwright 대체 수단
동적 가격 위젯이나 옵션 선택기가 붙은 일부 페이지는 JavaScript 렌더링이 필요해요. curl_cffi가 반쪽짜리 HTML만 돌려줄 때는 헤드리스 브라우저가 대안이 돼요.
from playwright.sync_api import sync_playwright
def scrape_with_browser(url):
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.goto(url, wait_until="domcontentloaded")
page.wait_for_timeout(3000) # JS 렌더링 대기
html = page.content()
browser.close()
return html
이 방식은 느려요. 페이지당 3~5초가 걸리는데, curl_cffi는 1초도 안 걸려요. 꼭 필요할 때만 쓰세요.
제 경험으론 curl_cffi만으로도 상품 페이지의 90% 이상은 브라우저 없이 처리됐어요.
차단 회피 요약
| 기법 | 난이도 | 효과 | 대부분의 튜토리얼에서 다루는가? |
|---|---|---|---|
| 맞춤 User-Agent | 쉬움 | 낮음(Amazon이 패턴을 감지함) | 예 |
| 전체 헤더 순환 | 쉬움 | 중간 | 드묾 |
| TLS 위장(curl_cffi) | 중간 | 높음(~94% 성공률) | 거의 없음 |
| 프록시 순환 | 중간 | 높음 | 아주 짧게 언급하거나 아예 없음 |
| 속도 제한 + 지수 백오프 | 쉬움 | 중간 | 아님 |
| Selenium/Playwright 대체 | 중간 | 높음(JS 콘텐츠용) | 언급만 하고 시연은 안 함 |
CSV를 넘어: Google Sheets, Airtable 등으로 내보내기
제가 본 튜토리얼은 죄다 CSV 내보내기에서 멈춰요. 그런데 실무에선 데이터가 Google Sheets, 데이터베이스, Airtable, Notion 같은 곳으로 흘러가야 해요.
gspread로 Google Sheets에 내보내기
먼저 Google 서비스 계정을 한 번만 설정해요.
- Google Cloud Console → APIs & Services → Credentials로 이동
- 서비스 계정을 만들고 JSON 키 파일 다운로드
~/.config/gspread/service_account.json에 저장- 대상 스프레드시트를 JSON 파일의
client_email과 공유
그다음:
import gspread
from gspread_dataframe import set_with_dataframe
gc = gspread.service_account()
sh = gc.open("Amazon Scrape Data")
worksheet = sh.sheet1
set_with_dataframe(worksheet, df)
print("Data exported to Google Sheets!")
이 코드는 DataFrame 전체를 Google Sheet에 바로 써요. 실시간 공유가 되고, 대시보드용으로도 그대로 쓸 수 있어요.
로컬 분석용 SQLite 저장
더 큰 데이터셋이나 이력 추적엔 SQLite가 딱이에요. 서버 설정 없이 파일 하나면 끝이거든요.
import sqlite3
conn = sqlite3.connect("amazon_products.db")
df.to_sql("products", conn, if_exists="append", index=False)
print(f"Stored {len(df)} products in SQLite")
# 나중에 조회:
historical = pd.read_sql_query(
"SELECT * FROM products WHERE price IS NOT NULL ORDER BY rowid DESC LIMIT 100",
conn,
)
노코드 대안
Python 내보내기 스크립트를 직접 관리하기 싫다면, Thunderbit는 Google Sheets, Airtable, Notion, Excel, CSV, JSON으로 무료 내보내기를 지원해요. Airtable과 Notion에서 바로 렌더링되는 이미지 필드까지요. gspread 설정도, API 자격 증명도, 코드도 필요 없어요. 기존 도구로 데이터를 흘려보내야 하는 팀이라면 시간을 크게 아낄 수 있어요.
자동 Amazon 스크래핑 예약하기 — 빠진 한 장
가격 모니터링과 재고 추적은 한 번 돌리고 끝낼 일이 아니라 반복 실행이 필요한 작업이에요. 그런데 경쟁 글 중 예약 실행을 다루는 곳은 거의 없었어요. Python 스크래퍼를 자동으로 돌리는 법을 정리할게요.
Cron 작업(Linux/macOS)
crontab을 열어요.
crontab -e
매일 오전 6시에 스크래퍼를 돌리는 줄을 추가해요.
0 6 * * * cd /path/to/amazon-scraper && /path/to/venv/bin/python scraper.py >> ~/scraper.log 2>&1
또는 6시간마다 실행:
0 */6 * * * cd /path/to/amazon-scraper && /path/to/venv/bin/python scraper.py >> ~/scraper.log 2>&1
Windows 작업 스케줄러
run_scraper.bat 파일을 만들어요.
@echo off
cd /d "C:\path\to\amazon-scraper"
call venv\Scripts\activate
python scraper.py
deactivate
그다음 작업 스케줄러에서 기본 작업 만들기 → 트리거(Daily, Hourly 등) 설정 → 작업으로 "Start a program" 선택 → run_scraper.bat 지정.
GitHub Actions(무료 플랜)
인프라 없이 클라우드에서 예약 실행하고 싶다면:
name: Amazon Scraper
on:
schedule:
- cron: "0 6 * * *" # UTC 기준 매일 오전 6시
workflow_dispatch: # 수동 실행
jobs:
scrape:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: "3.11"
- name: Install dependencies
run: pip install -r requirements.txt
- name: Run scraper
run: python scraper.py
- name: Commit results
run: |
git config user.name 'GitHub Actions'
git config user.email 'actions@github.com'
git add data/
git diff --staged --quiet || git commit -m "Update scraped data"
git push
프록시 자격 증명을 GitHub Secrets에 넣으면 무료 자동 스크래핑 파이프라인이 완성돼요.
노코드 대안: Thunderbit의 Scheduled Scraper
cron 문법이나 클라우드 인프라를 만지기 싫은 팀은 Thunderbit 내장 Scheduled Scraper를 쓰면 돼요. "매일 오전 8시"나 "매주 월요일"처럼 자연어로 일정을 적고, Amazon URL을 넣은 뒤 "Schedule"을 누르면 끝이에요. 터미널도, YAML도, 배포 파이프라인도 필요 없어요. 가격·재고를 꾸준히 모니터링해야 하는 이커머스 팀에 특히 잘 맞아요.
Python 직접 구현 vs. 스크래퍼 API vs. 노코드: 어떤 방법을 써야 할까요?
포럼에서 정말 자주 나오는 질문인데, 상위 노출 글 중 제대로 답해 주는 곳은 드물어요. 솔직하게 정리해 볼게요.
| 기준 | Python + BS4/curl_cffi | 스크래퍼 API (ScraperAPI, Oxylabs) | 노코드(Thunderbit) |
|---|---|---|---|
| 설정 시간 | 30–60분 | 10–20분 | 약 2분 |
| 코딩 필요 여부 | 예(Python) | 예(API 호출) | 없음 |
| 차단 방어 내장 | 아니요(DIY) | 예 | 예 |
| JS 렌더링 처리 | Selenium/Playwright 사용 시 가능 | 제공사별 상이 | 예(Browser 또는 Cloud 모드) |
| 예약 실행 | 직접 구현(cron/클라우드) | 일부 제공 | 내장 |
| 비용 | 무료(+ 프록시 비용) | 월 $30–100+ | 무료 플랜 제공 |
| 유지보수 | 높음(셀렉터가 자주 깨짐) | 낮음 | 없음(AI가 적응) |
| 적합한 대상 | 완전한 제어를 원하는 개발자 | 대규모 안정성이 필요한 팀 | 빠른 작업이 필요한 비개발자, 비즈니스 사용자 |
배우고 싶고, 세부까지 전부 커스터마이즈하고 싶고, 지속적인 유지보수도 감수할 수 있다면 Python이 좋은 선택이에요. 스크래퍼 API는 차단 방어를 대신 떠맡아 주지만 코드는 여전히 필요하고요. 반면 Thunderbit은 영업, 이커머스 운영, 또는 그냥 데이터만 필요한 사람에게 가장 빠른 길이에요. 셀렉터도, 코드도, Amazon HTML이 바뀔 때마다 손볼 유지보수도 없어요.
Thunderbit이 Amazon 상품을 2번 클릭으로 스크래핑하는 방법
제가 만든 제품이라 편향이 있을 수 있다는 점은 인정해요. 하지만 실제 워크플로우는 정말 이래요.
- Thunderbit Chrome Extension 설치
- Amazon 검색 결과나 상품 페이지로 이동
- "AI Suggest Fields" 클릭(또는 바로 쓸 수 있는 Amazon 스크래퍼 템플릿 사용)
- "Scrape" 클릭
Thunderbit의 AI가 페이지를 읽고, 데이터 구조를 파악한 뒤, 모든 정보를 깔끔한 표로 뽑아줘요. Excel, Google Sheets, Airtable, Notion으로 무료 내보내기도 되고요. 진짜 강점은 다음 주에 Amazon이 HTML을 바꿔도(분명 바꿀 거고요), Thunderbit AI가 알아서 적응한다는 점이에요. 깨진 스크립트도, 셀렉터 업데이트도 없어요.
상품 목록에 상세 페이지 데이터를 더 붙이고 싶을 때는 Thunderbit의 Subpage Scraping이 링크를 따라 상품 페이지로 들어가 이미지, 설명, 옵션 같은 필드를 자동으로 가져와요. Python으로 짜려면 코드가 꽤 늘어나는 작업이죠.
Python Amazon 스크래퍼를 장기적으로 안정적으로 유지하는 팁
Python으로 갈 거라면, 유지보수 부담을 줄이는 방법은 이래요.
- 셀렉터를 정기적으로 확인하세요. Amazon은 자주 바꿔요. 이 글을 북마크해 두세요. 셀렉터 표는 변화에 맞춰 갱신할게요.
- 성공률을 모니터링하세요. 200 응답과 503/CAPTCHA 비율을 추적하고, 성공률이 80% 아래로 떨어지면 알림(간단한 이메일이면 충분)을 걸어두세요.
- 원본 HTML을 저장하세요. 파싱한 데이터와 함께 전체 HTML 응답을 보관해 두면, 셀렉터가 바뀌어도 다시 긁지 않고 재파싱할 수 있어요.
- 프록시와 User-Agent를 자주 순환하세요. 고정 지문은 대량 실행 시 몇 시간이면 들켜요.
- 지수 백오프를 쓰세요. 차단 직후 즉시 재시도는 절대 금물이에요.
- Docker로 컨테이너화하세요. 배포와 이식성을 위해 스크래퍼를 Docker 컨테이너로 감싸세요.
- 데이터 검증을 더하세요. 가격이 숫자인지, 평점이 1~5 범위인지, 제목이 비지 않았는지 확인하세요. 한 팀은 검증 계층을 넣은 뒤 후속 오류를 21% 줄였다고 해요.
이 모든 게 너무 번거롭게 느껴진다면, Thunderbit 같은 노코드 도구가 더 맞는지 따져보세요. 더 빠른 길을 고르는 게 부끄러운 일은 아니에요. 스크래퍼를 셀 수 없이 디버깅해 본 입장에서 말하면, 가장 좋은 코드는 아예 안 짜도 되는 코드일 때가 있어요.
Amazon 스크래핑 시 법적·윤리적 고려 사항
Amazon 스크래핑 얘기엔 빠지지 않는 부분이니, 법적 환경을 짧게 짚고 갈게요.
- 공개 데이터 스크래핑은 미국에서 대체로 합법이에요. 획기적인 hiQ Labs v. LinkedIn 판결(2022)이 공개 데이터 접근은 CFAA 위반이 아니라고 정리했어요. 최근 Meta v. Bright Data(2024)와 X v. Bright Data(2024)도 같은 원칙을 더 단단히 했고요.
- Amazon 약관은 자동 접근을 금지해요. 이건 형사가 아니라 민사 문제(계약 위반)예요. 법원은 보통 이 둘을 구분하죠.
- **Amazon v. Perplexity(2025)**는 Amazon 페이지의 AI 스크래핑과 얽힌 진행 중인 사건이에요. 2026년 3월 예비 금지명령이 나왔어요. 눈여겨볼 만해요.
- 공개 페이지로만 한정하세요. 로그인 뒤 콘텐츠, 개인 정보, 인증 너머 정보는 긁지 마세요.
- 속도 제한을 지키세요. Amazon 서버를 너무 두드리지 마세요. 요청 사이 2~5초 지연이면 합리적이에요.
- 데이터를 책임 있게 쓰세요. 분석용 스크래핑과 저작권 콘텐츠 재배포는 전혀 다른 얘기예요.
- 대규모 상업적 사용이라면 법률 자문을 받으세요. 특히 EU에서는 개인정보에 개인정보보호법(GDPR)이 적용돼요.
더 자세한 내용은 웹 스크래핑의 법적 쟁점 가이드를 참고하세요.
마무리
이제 여러분 손엔 2025년 검증 셀렉터, "User-Agent만 바꾸면 된다" 수준을 한참 넘어선 다층 차단 회피, 지속 모니터링을 위한 실용적 예약법, 그리고 Google Sheets·데이터베이스·팀 도구로 데이터를 보내는 내보내기까지 갖춘 Python Amazon 스크래퍼가 있어요.
핵심만 추리면:
- Python + curl_cffi + BeautifulSoup 조합은 TLS 위장과 함께 쓰면 완전한 제어권과 약 94% 성공률을 줘요
- 차단 회피는 여러 층이 필요해요: 헤더 순환, TLS 위장, 프록시 순환, 속도 제한, 지수 백오프
- 스케줄링으로 일회성 스크립트를 지속 모니터링 파이프라인으로 바꿀 수 있어요(cron, GitHub Actions, 또는 Thunderbit 내장 스케줄러)
- CSV를 넘어서는 내보내기 — Google Sheets, SQLite, Airtable, Notion — 에서 진짜 비즈니스 가치가 나와요
- Thunderbit은 셀렉터 디버깅보다 데이터 분석에 시간을 쓰고 싶은 비개발자에게 2번 클릭 대안을 줘요
이 코드를 직접 돌려보고 싶다면, 이 글의 예시는 전부 그대로 복사해 실행할 수 있어요. 코딩을 통째로 건너뛰고 싶다면, Thunderbit 무료 플랜으로 Amazon에서 노코드 방식을 바로 테스트해 보세요.
더 알고 싶다면 Python으로 Amazon 상품과 리뷰 스크래핑하기, 최고의 Python 웹 스크래핑 도구, Amazon 가격 스크래핑 가이드를 참고하세요. Thunderbit YouTube 채널에서 단계별 영상도 볼 수 있어요.
행운을 빌어요. 그리고 다음 Amazon 업데이트가 올 때까지 셀렉터가 무사하길 바라요.
자주 묻는 질문
1. 왜 내 Python Amazon 스크래퍼는 몇 번 요청 후 차단되나요?
Amazon은 IP 평판 분석, TLS 지문(JA3/JA4), 브라우저 환경 감지, 행동 생체 인식, CAPTCHA, ML 기반 이상 탐지를 아우르는 6단계 방어를 써요. User-Agent만 넣은 requests 스크립트의 성공률은 약 2%에 불과하고요. 안정적으로 접근하려면 TLS 위장(curl_cffi), 전체 헤더 순환, 프록시 순환, 무작위 지터가 들어간 속도 제한이 필요해요.
2. 2025년에 Amazon 상품 스크래핑에 가장 좋은 Python 라이브러리는 무엇인가요?
가장 큰 효과를 주는 건 TLS 위장 HTTP 요청용 curl_cffi예요. 여기에 HTML 파싱용 BeautifulSoup4와 lxml, 데이터 정리·내보내기용 pandas, JavaScript 렌더링 콘텐츠 대체 수단으로 Selenium이나 Playwright를 곁들이면 돼요. Python은 스크래핑 개발자의 69.6%가 쓰는 언어예요.
3. Amazon 상품 데이터를 스크래핑하는 것은 합법인가요?
미국에서는 공개 데이터 스크래핑이 대체로 합법이고, hiQ v. LinkedIn과 Meta v. Bright Data 같은 판례가 받쳐줘요. 다만 Amazon 약관은 자동 접근을 금지하고, 법원은 보통 약관 위반(민사)과 형사 위반을 구분해요. 로그인 뒤 콘텐츠는 피하고, 속도 제한을 지키고, 대규모 상업적 사용 전엔 꼭 법률 자문을 받으세요.
4. 코드를 전혀 쓰지 않고 Amazon을 스크래핑할 수 있나요?
가능해요. Thunderbit 같은 도구를 쓰면 Chrome 확장으로 Amazon 상품을 2번 클릭에 긁을 수 있어요. AI 기반 필드 감지가 데이터를 자동으로 구조화하고, Excel, Google Sheets, Airtable, Notion으로 무료 내보내기도 되고요. Amazon HTML이 바뀌어도 Thunderbit AI는 수동 업데이트 없이 적응해요.
5. Amazon은 HTML 셀렉터를 얼마나 자주 바꾸며, 스크래퍼는 어떻게 최신 상태로 유지하나요?
자주, 그리고 예고 없이 바뀌어요. 업계에선 DOM 변경 탓에 매주 크롤러의 10~15%가 손봐야 한다고 봐요. 앞서가려면 스크래퍼 성공률을 모니터링하고, 원본 HTML을 저장해 재파싱할 수 있게 두고, 실제 페이지에서 셀렉터를 정기적으로 확인해야 해요. 아니면 Thunderbit 같은 AI 도구로 자동 적응을 맡겨 유지보수 부담을 없앨 수도 있고요.
더 알아보기
