GitHub에서 "amazon scraper"를 검색하면 약 가 나옵니다. 여기서 최근 6개월 안에 푸시된 저장소만 추리면 약 정도로 줄어들어요. 전체의 20%도 안 됩니다. 나머지는요? 방치된 튜토리얼, 낡은 래퍼, 그리고 Amazon이 방어를 강화한 순간 바로 작동을 멈춘 스크립트들입니다.
저는 Amazon 스크레이퍼 저장소들을 오래 살펴보고, GitHub 이슈를 읽고, Reddit과 Stack Overflow 커뮤니티 스레드를 따라다니며 많은 시간을 보냈습니다. 패턴은 아주 일관적이에요. 누군가 인기 있는 저장소를 찾고, 한 시간 정도 설정한 뒤, 한 번 실행해 보고는 CAPTCHAs나 503 오류의 벽에 부딪힙니다. 2026년의 Amazon 안티봇 방어는 2년 전과도 다릅니다. TLS 핑거프린팅, 행동 분석, 공격적인 CAPTCHA 배포 때문에 예전의 "User-Agent만 돌려가며 운에 맡기기" 방식은 거의 쓸모가 없어졌어요. 이 가이드는 GitHub 저장소에서 신뢰할 수 있는 Amazon 데이터를 얻고 싶을 때 정말 중요한 실전 방법과, 스크레이퍼가 깨졌을 때(깨질 때가 아니라면 말이죠) 무엇을 해야 하는지 다룹니다.
GitHub의 Amazon Scraper란 무엇이며, 왜 이렇게 많이 실패할까?
Amazon scraper GitHub 저장소는 보통 오픈소스 스크립트입니다. 대개 Python, Node.js, 또는 Scrapy 기반으로 만들어지며, Amazon 페이지에서 구조화된 데이터를 추출합니다. 다루는 데이터는 익숙해요. 상품명, 가격, ASIN, 평점, 리뷰 수, 재고 상태, 판매자 정보, 검색 결과 카드, 리뷰 텍스트 등이죠.
구조는 보통 단순합니다.
- HTTP 클라이언트나 헤드리스 브라우저가 페이지를 가져옵니다.
- HTML 또는 JSON 파서가 필드를 추출합니다.
- 데이터는 CSV, JSON, 또는 데이터베이스에 저장됩니다.
저장소는 대체로 네 가지 범주로 나뉩니다.
- 가벼운 Python 라이브러리 (예: )
- Scrapy 스파이더 (예: )
- Selenium 또는 Playwright 브라우저 자동화 도구
- 실제로는 상용 스크래핑 서비스의 프런트엔드인 API 래퍼 프로젝트 (예: )
실패 패턴도 예측 가능합니다. 대부분의 저장소가 깨지는 이유는 다음과 같아요.
- Amazon이 페이지 레이아웃이나 HTML 조각을 변경함
- 실제 콘텐츠 대신 503 또는 CAPTCHA를 반환함
- 스크레이퍼의 TLS와 HTTP 핑거프린트가 더 이상 브라우저처럼 보이지 않음
- 로케일, 언어, 헤더 불일치가 수상함을 유발함
- 유지보수자가 원래의 좁은 사용 사례를 해결한 뒤 프로젝트를 떠남
별점이 높다고 해서 "지금도 쓸 수 있다"는 뜻은 아닙니다. 이 글을 위해 진행한 점검에서는 널리 노출된 8개 저장소 중 약 3개 정도만 2026년에도 분명히 활발해 보였어요.
아무 Amazon Scraper GitHub 저장소나 클론하기 전에 2026년 최신성 점검부터 하세요
이 단계는 다른 타깃보다 Amazon에서 훨씬 중요합니다. Amazon의 방어 정책은 일반적인 이커머스 사이트보다 더 빨리 바뀌기 때문에, 브로슈어 웹사이트에서는 멀쩡하던 저장소도 Amazon에서는 몇 주 만에 무용지물이 될 수 있어요. 그런데도 대부분의 "best amazon scraper github" 목록은 아직도 실제로 작동하는지 확인하지 않은 채 저장소를 추천합니다. 사용자들은 깨진 도구를 설정하느라 몇 시간을 날리죠.
GitHub 저장소가 아직 살아 있는지 확인하는 방법
git clone을 하기 전에 다음 항목을 확인하세요.
- 마지막 커밋 날짜: Amazon에서는 6개월 이상 된 항목이면 강한 경고 신호입니다.
- 열린 이슈 vs. 응답률: Issues 탭에서 "captcha," "503," "blocked," "not working"을 검색하세요. 이런 보고가 쌓이는데 유지보수자 답변이 없으면 그냥 넘기는 게 좋습니다.
- 의존성 상태:
requirements.txt또는package.json을 열어보세요. 오래된 라이브러리(예: 최신 TLS 처리가 없는 예전requests)는 위험 신호입니다. - Amazon 페이지 유형 범위: 상품 페이지, 검색 결과, 그리고 리뷰까지 처리하나요? 아니면 하나만 되나요?
- 안티봇 대응 방식: 프록시 지원 없이 헤더만 하드코딩돼 있다면, 2023년식 접근이라 2026년에는 버티기 어렵습니다.
Amazon Scraper GitHub 최신성 체크리스트
| 최신성 신호 | 확인할 내용 | 위험 신호 🚩 |
|---|---|---|
| 마지막 커밋 날짜 | 커밋 피드 또는 저장소 푸시 날짜 | 6개월 이상 오래됨 |
| 열린 이슈 | Issues 탭 — "captcha," "503," "blocked"로 필터링 | 유지보수자 응답 없이 반복적으로 깨짐 |
| 의존성 상태 | requirements.txt / package.json | 오래된 라이브러리, 최신 TLS 전략 없음 |
| Amazon 페이지 범위 | README + 코드 예시 | 한 가지 페이지 유형만 처리(예: 상품 페이지만, 검색이나 리뷰는 불가) |
| 안티봇 방식 | 소스 코드, 프록시 설정 | 헤더와 UA 문자열만 하드코딩 |
| 유지보수 모델 | 실제 스크레이퍼인가, 튜토리얼인가, 상용 API 래퍼인가? | 저장소가 사실상 유료 서비스의 프런트엔드임 |
실제 점검 결과는 어땠나
저는 널리 노출된 Amazon scraper 저장소 8개를 이 기준으로 확인했습니다. 결과는 꽤 씁쓸했어요.
This paragraph contains content that cannot be parsed and has been skipped.
공개 이슈도 같은 이야기를 합니다. 에는 "All requests receive captcha response."라는 이슈가 있고, 에는 "Doesn't seem to be working."가 있습니다. 에는 "Bypass Amazon protection."가 올라와 있죠. 이런 문제는 특이한 예외가 아니라, 사용자들이 가장 먼저 맞닥뜨리는 현실입니다.
차단 방지 전략: GitHub의 Amazon Scraper로 막히지 않는 법
차단당하는 건 Amazon scraper github 프로젝트를 쓰는 사람들에게 가장 큰 고통입니다. "프록시를 쓰고 User-Agent를 돌리세요" 같은 일반론만으로는 더 이상 충분하지 않아요. 2025~2026년의 Amazon 안티봇 스택에는 TLS 핑거프린팅, 행동 분석, 공격적인 CAPTCHA 배포가 포함됩니다. 층위별 대응이 필요합니다.
TLS 핑거프린트 맞추기: 왜 기본 requests로는 차단되기 쉬운가
이건 가장 간과되는 차단 방지 기술 중 하나입니다. TLS 핑거프린팅은 이렇게 작동해요. 스크립트가 Amazon에 보안 연결을 열면, 서버는 핸드셰이크 방식만 봐도 클라이언트에 대해 많은 정보를 알 수 있습니다. 어떤 암호군을 제안하는지, 확장 순서는 어떤지, HTTP/2 설정은 어떤지 같은 것들이죠. 브라우저는 비교적 고정된 TLS와 HTTP/2 설정을 사용하고, 이런 조합은 같은 방식으로 식별 가능합니다.
일반 requests와 보통의 httpx 설정은 헤더는 복사할 수 있어도, Chrome 같은 TLS와 HTTP/2 동작은 복제하지 못합니다. Amazon은 그 차이를 알아냅니다.
는 이 문제를 직접 해결합니다. 브라우저 위장 기능을 제공하며, chrome136, safari184, firefox133 같은 대상이 지원돼서 HTTP 클라이언트의 TLS 핑거프린트가 실제 브라우저와 일치하게 됩니다. 문서에서도 무작위 JA3 문자열 생성은 피하라고 명확히 경고합니다. 브라우저 핑거프린트는 버전마다 대부분 고정돼 있고, 무작위로 만든 값은 실제 핑거프린트를 복사하는 것보다 훨씬 쉽게 탐지되기 때문입니다.
커뮤니티 데이터도 이를 뒷받침합니다. 에서는 impersonate 인자가 브라우저 프로필을 바꾸고 헤더를 일치시키는 데 유용하다고 확인합니다. 또 다른 는 Amazon이 TLS 핑거프린트를 기준으로 클라이언트를 "한두 달쯤 후" 막는다고 언급합니다. 에서는 Amazon이 python-requests를 핑거프린팅하는지 묻고 있고요(답은 그렇다고 보는 쪽에 가깝습니다).
아직도 기본 requests를 Amazon용 첫 번째 클라이언트로 쓰고 있다면, 다른 걸 업그레이드하기 전에 그 가정부터 바꾸세요.
프록시 로테이션, 제대로 하는 법(그냥 "프록시 쓰기"가 아님)
프록시의 목적은 가능한 한 많이 바꾸는 데 있지 않습니다. 세션이 그럴듯해 보이게 만드는 데 있습니다.
Residential vs. datacenter: 데이터센터 프록시는 더 싸지만 탐지하기 쉽습니다. Residential 프록시는 더 비싸지만 Amazon이 훨씬 덜 쉽게 걸러냅니다. 은 종량제로 GB당 $4.00에서 시작하고, 더 큰 요금제에서는 GB당 $3.50까지 내려갑니다. 은 GB당 $6에서 시작합니다. Amazon은 정교한 타깃에 해당하므로, residential 프록시에 프리미엄을 지불할 가치가 있습니다.
요청 단위 vs. 세션 단위 로테이션: 대부분의 튜토리얼이 여기서 틀립니다. 쿠키와 헤더는 그대로 두고 요청마다 프록시만 바꾸면, 사람 같아지기는커녕 오히려 더 수상해 보일 수 있어요. 더 안전한 패턴은 다음과 같습니다.
- 가능하면 검색 → 상품 → 리뷰 탐색을 같은 스티키 세션에서 유지
- 매 요청마다가 아니라, 새 검색 여정을 시작할 때 세션을 변경
- 한 브라우징 세션 내부에서 무작위로 바꾸지 말고, 세션 사이에서만 로테이션
한 에서는 일반 ISP IP가 인기 이커머스 사이트에서 모바일 IP만큼 잘 작동하지 않는다고 지적했습니다. 또 다른 는 User-Agent를 돌리고 residential 프록시를 써도 차단됐다고 보고했는데, 프록시만으로는 충분하지 않다는 점을 잘 보여줍니다.
요청 속도 조절, 백오프, 레이트 리밋
Amazon의 503 페이지는 단순한 우연한 오류가 아닙니다. 피드백입니다.
500개가 넘는 ASIN을 스크래핑하다가 발생한 503에 대한 에서는, 심지어 sleep을 넣었는데도 ASIN 101쯤에서 매번 같은 지점에서 503이 난다고 보고했습니다. 패턴은 오래됐지만 교훈은 지금도 유효합니다. 하나의 IP나 핑거프린트에서 나오는 원시적인 트래픽 양은 결국 방어를 자극합니다.
직접 만드는 GitHub 스크레이퍼를 위한 모범 속도 조절 방식:
- 요청 사이에 무작위 지연 적용(고정 간격은 탐지되기 쉬움)
- 단순 HTTP 클라이언트의 경우 공개 상품 요청 사이에 2~5초 간격
- 503 또는 CAPTCHA 후에는 지수 백오프 적용 — 바로 재시도하지 말고 점진적으로 간격을 늘리기
- 생각보다 낮은 동시성 사용
- 빡빡한 재시도 루프 대신 실패 허용 로그 남기기
대부분의 amazon scraper github 저장소에는 기본 레이트 리밋이 없습니다. 직접 추가해야 해요.
헤더 구성: User-Agent 문자열만의 문제가 아닙니다
Amazon은 User-Agent만 보지 않고, 전체 헤더 집합을 확인합니다.
실제 브라우저에 가까운 헤더 세트에는 다음이 포함돼야 합니다.
User-AgentAcceptAccept-LanguageAccept-Encoding- 적절한 경우
Sec-CH-*힌트 - 선택한 브라우저 프로필과 일치하는 연결 동작
헤더는 마켓플레이스 로케일과 맞아야 합니다. 10개 Amazon 로케일을 크롤링한 한 는 같은 봇 설정이 일부 로케일에서만 탐지된다고 했고, 다른 댓글은 Accept-Language 같은 지역 관련 헤더를 지적했습니다.
규칙은 간단합니다. 헤더, TLS/브라우저 프로필, 프록시 지리 정보는 서로 모순되면 안 됩니다. Chrome 헤더를 보내면서 Firefox UA를 쓰지 마세요. 미국 프록시를 쓰면서 Accept-Language: de-DE를 보내지도 마세요.
CAPTCHA 처리: 언제 풀고, 언제 물러나야 하나
CAPTCHA에 걸렸다는 건 이미 Amazon이 수상하게 보고 있다는 뜻입니다. 푼다고 신뢰 점수가 초기화되지는 않아요.
드물고, 단발성인 CAPTCHA 이벤트라면:
- PyPI 패키지는 순수 Python 기반 Amazon 텍스트 CAPTCHA 솔버입니다. 다만 최신 릴리스가 2023년 5월이므로 지속 가능한 전략이라기보다 전술 도구로 보세요
- 는 Amazon Captcha를 1,000회 해결당 $0.45로 책정합니다
반복되는 CAPTCHA 루프라면:
- 계속 풀지 말고 물러나세요
- 반복 CAPTCHA는 세션이 이미 소진됐다는 신호입니다. 해결한다고 해서 핑거프린트, 세션 기록, IP 평판이 다시 회복되지는 않아요
- 프록시 서브넷별로 CAPTCHA가 몰린다면, 문제는 파서가 아니라 네트워크 계층입니다
실제로 헤드리스 브라우저가 필요한 경우와 과한 경우
잘못된 직감은 모든 작업에 Playwright를 쓰는 것입니다.
브라우저가 좋은 경우:
- JavaScript 렌더링이나 로케일 의존 상태에 따라 달라지는 검색 결과
- 로그인 또는 사인인 페이지로 리디렉션되는 리뷰 흐름
- 쿠키와 브라우저 컨텍스트가 원시 속도보다 더 중요한 워크플로
브라우저가 과한 경우:
- 일반적인 공개 상품 페이지
- 브라우저처럼 보이는 HTTP 클라이언트만으로 충분한 정적 상품 상세 추출
- 연산 효율이 중요한 대규모 일괄 수집
가장 가벼운 클라이언트부터 시작하세요. 규모 있게 스크래핑하는 방법을 다룬 한 는 흐름을 이렇게 설명합니다. requests로 시작하고, 그다음 curl_cffi를 쓰고, 가벼운 방식이 실패할 때만 전체 브라우저로 넘어가라는 거죠. Amazon 상품 페이지 스크래핑에서는 헤드리스 브라우저가 HTTP 클라이언트보다 훨씬 느리고 자원도 더 많이 씁니다.
Amazon Scraper GitHub 프로젝트를 위한 차단 방지 의사결정 매트릭스
| 상황 | 권장 접근법 | 이유 |
|---|---|---|
| 공개 상품 페이지(소규모) | curl_cffi + 스티키 residential 세션 | 브라우저처럼 보이면서도 가장 저렴한 경로 |
| 검색 결과 페이지 | 먼저 curl_cffi, 렌더링이나 상태 때문에 HTTP가 깨질 때만 Playwright | 검색은 상태와 로케일 의존성이 더 큼 |
| 리뷰(로그인 필요) | 실제 쿠키/세션을 쓰는 브라우저 모드 | 로그인과 동적 리뷰 흐름은 순수 HTTP로 흉내내기 어려움 |
| 대규모(하루 5천 개 이상) | 관리형 스크레이퍼 API, 언락커, 또는 노코드 플랫폼 | GitHub 코드만으로는 인프라 문제가 됨 |
Amazon Scraper GitHub 프로젝트가 깨졌을 때: 노코드 대체 플랜을 준비하세요
경험 많은 스크레이퍼는 항상 B 플랜을 둡니다.
Amazon 업데이트는 결국 어떤 GitHub 저장소든 가장 엉뚱한 타이밍에 깨뜨릴 수 있어요. 이커머스 팀에게는 스크레이퍼가 깨진다는 건 가격 변동 누락, 경쟁사 데이터 노후화, 대시보드 공백을 뜻합니다.
"amazon scraper github"를 찾는 많은 사람은 사실 비즈니스 사용자입니다. 이커머스 운영, 마케팅, FBA 리서처 등으로, 더 나은 도구를 못 찾아서 코딩 솔루션을 시도한 분들이죠. 포럼 데이터를 보면 Amazon의 공식 에 대한 불만도 큽니다. 접근 제한이 엄격하고, 데이터도 제한적이며, 도 많은 판매자가 충족하기 어렵습니다.
GitHub Amazon Scraper가 계속 유지보수를 필요로 하는 이유
위의 점검은 이걸 분명히 보여줍니다.
- 낡은 저장소는 수정 없이 깨짐 보고만 쌓입니다
- "작동 중"인 저장소들도 이제 README에서 안티봇 대응을 노골적으로 언급합니다
- 커뮤니티 스레드는 점점 CSS 셀렉터보다 TLS 핑거프린트, CAPTCHA 루프, 프록시 품질에 집중합니다
비즈니스 사용자에게는 그 유지보수 부담이 진짜 숨은 비용입니다. 저장소는 무료예요. 새벽 2시에 디버깅하는 여러분의 시간은 무료가 아니죠.
실용적인 Amazon Scraper 대안으로서의 Thunderbit
는 코드 없이 제목, 가격, ASIN, 평점, 브랜드, 재고 상태, 배송 출발지, 원본 URL을 추출하는 을 제공합니다.
실제로는 이런 차이가 있습니다.
- Python 환경, 의존성, 프록시 설정을 준비하는 대신 2클릭 스크래핑
- 즉시 사용 가능한 Amazon 템플릿 — AI 오버헤드 없이 1번 클릭으로 추출
- 리뷰 페이지처럼 로그인이 필요한 페이지를 위한 브라우저 스크래핑 모드
- 공개 상품 페이지를 빠르게 처리하는 클라우드 스크래핑(한 번에 50페이지)
- CSV/JSON만이 아니라 Google Sheets, Airtable, Notion, Excel로 무료 내보내기
- 계속되는 가격 모니터링을 위한 예약 스크레이퍼
- 레이아웃 변경을 AI가 적응하므로 유지보수 부담 없음
GitHub Amazon Scraper vs. Thunderbit: 솔직한 비교
| 요소 | GitHub 스크레이퍼(예: AmzPy) | Thunderbit |
|---|---|---|
| 설정 시간 | 15~60분(Python, 의존성, 프록시) | 약 2분(Chrome 확장 프로그램 설치) |
| 유지보수 | 직접 깨진 부분을 수정 | AI가 레이아웃 변경에 적응 |
| 안티봇 처리 | 직접 구성(프록시, 헤더, TLS) | 내장(클라우드 + 브라우저 모드) |
| 리뷰 스크래핑(로그인 상태) | 복잡한 세션 관리 | 브라우저 스크래핑 모드 |
| 데이터 내보내기 | CSV/JSON만 | Sheets, Airtable, Notion, Excel, CSV, JSON |
| 스케줄링 | 직접 구성(cron, Airflow 등) | 내장 예약 스크레이퍼 |
| 커스터마이징 | 높음 | 낮음 |
| 비용 | 무료(프록시 비용 별도) | 무료 플랜 제공; 크레딧 기반 |
솔직한 트레이드오프는 이렇습니다. GitHub 저장소는 더 높은 커스터마이징을 제공하고, Thunderbit는 더 높은 신뢰성을 제공합니다. 팀이 유연성보다 안정성을 중시한다면, 노코드 방식이 대체로 더 합리적인 선택입니다.
예약 및 반복 Amazon 스크래핑을 위한 모범 사례
대부분의 amazon scraper github 프로젝트는 일회성 실행용으로 만들어졌지만, 가격 모니터링, 재고 추적, 경쟁사 분석 같은 실제 비즈니스 사용 사례는 반복 스크래핑이 필요합니다. GitHub 저장소에는 스케줄링이 기본 내장된 경우가 거의 없어서, 사용자가 cron 작업, Airflow, 또는 n8n 워크플로를 직접 엮어야 해요.
GitHub Amazon Scraper용 DIY 스케줄링
최소한으로 갖춰야 할 반복 실행 구성은 다음과 같습니다.
- 스크립트를 정해진 시간에 실행하는 Linux 또는 macOS cron 작업
- 나중에 실패를 디버깅할 수 있도록 append-only 로그
- 중복 데이터를 저장하지 않도록 ASIN + 타임스탬프 기반 중복 제거
- 새벽 3시에 실패했을 때 알 수 있도록 실패 알림(종료 코드가 0이 아닐 때 간단한 이메일만 보내도 충분)
더 복잡한 팀이라면:
- 가벼운 워크플로 자동화를 위한 n8n(커뮤니티 스레드에서 자주 언급됨)
- 더 무거운 예약 파이프라인을 위한 Airflow
- 차이와 히스토리가 필요하면 데이터베이스 기반 상태 관리
중요한 모범 사례는 스케줄러 자체가 아니라 상태 관리입니다. 마지막 성공 실행, 마지막 ASIN 세트, 변경된 가격, 실패한 URL을 추적하세요.
Thunderbit로 더 간단해지는 스케줄링
Thunderbit의 는 간격을 자연어로 설명하고, URL을 입력한 뒤 "Schedule"을 클릭하면 됩니다. AI가 자연어를 cron 스케줄로 바꿔 주기 때문에 별도 기술 설정이 필요하지 않아요. 가격이나 경쟁사 신제품 출시를 모니터링하는 비개발 이커머스 팀에게는 운영 부담이 크게 줄어드는 셈입니다.
반복 Amazon 스크래핑을 위한 모범 사례
어떤 도구를 쓰든 아래 원칙은 같습니다.
- ASIN + 타임스탬프 창으로 중복 제거 — 한 번 실행에서 같은 상품을 두 번 저장하지 않기
- 가격은 원시 문자열이 아니라 숫자로 저장 — 나중 정리 작업이 훨씬 쉬움
- 각 행에 스크래핑 타임스탬프 추가 — 추세 분석에 꼭 필요함
- 현재 상태만이 아니라 변화량도 추적 — "지난주보다 12% 하락"이 "가격이 $24.99"보다 훨씬 유용함
- 의미 있는 변화만 알림 — 경쟁사 가격이 15% 떨어지면 알림 가치가 있지만, 0.5% 변동은 노이즈에 가깝습니다
- 데이터 저장 방식을 미리 생각 — 소규모 실행에는 플랫 파일로 충분하지만, 하루 5천 개 이상의 ASIN을 다루면 데이터베이스나 클라우드 스프레드시트를 고려하세요
결과를 나란히 비교해 보면: 각 Amazon Scraper GitHub 방식의 실제 산출물 품질
아무도 amazon scraper github 저장소들 사이의 실제 출력 품질을 비교하지 않습니다. 사용자들은 "어떤 도구가 가장 깔끔하고 완전한 데이터를 주는가"를 매우 중요하게 여기지만, 결국 각 저장소를 직접 클론하고 테스트해야 하죠. 이 섹션이 그 공백을 메웁니다.
인기 있는 GitHub 저장소가 실제로 추출하는 것과 놓치는 것
README 샘플, 공개 예시, 문서화된 출력 형식을 바탕으로 보면:
| 접근 방식 | 명확히 추출하는 항목 | 흔한 공백 / 트레이드오프 |
|---|---|---|
| amzpy | 제목, 가격, 통화, 이미지 URL, 평점, 리뷰, 변형, ASIN | 상품 페이지 중심이며, 전체 리뷰/사양 섹션은 상대적으로 약함 |
| tducret/amazon-scraper-python | 제목, 평점, 리뷰 수, 상품 URL, 이미지 URL, ASIN이 포함된 CSV | 오래됨, 목록 중심, 안티봇 대응 약함 |
| python-scrapy-playbook scraper | 검색 결과, 상품 페이지, 리뷰, CSV/JSON 파이프라인 | 튜토리얼 수준이며 외부 프록시 미들웨어에 의존, 정리 작업이 더 필요함 |
| omkarcloud/amazon-scraper | 검색, 카테고리, 상세, 상위 리뷰, 많은 이미지/비디오/사양 | 원시 스크레이퍼가 아니라 관리형 API 서비스 |
| Thunderbit Amazon 템플릿 | 제목, 가격, ASIN, 브랜드, 평점, 리뷰, 재고 상태, 배송 출발지, 하위 페이지 보강 | 사용자 코드 수준의 제어는 커스텀 스크립트보다 적음 |
출력 품질 비교 표
| 데이터 필드 | AmzPy | Scrapy 기반 저장소 | Selenium 저장소 | Thunderbit |
|---|---|---|---|---|
| 상품 제목 | ✅ | ✅ | ✅ | ✅ |
| 가격(숫자형) | ⚠️ 문자열 | ✅ | ⚠️ 문자열 | ✅(숫자 타입) |
| 평점 | ✅ | ✅ | ✅ | ✅ |
| 리뷰 수 | ❌ | ✅ | ✅ | ✅ |
| ASIN | ✅ | ✅ | ✅ | ✅ |
| 상품 이미지 | ❌ | ⚠️ 썸네일만 | ✅ | ✅(고해상도, 내보내기 가능) |
| 원재료/사양 | ❌ | ❌ | ❌ | ✅(하위 페이지 스크래핑 + AI) |
| Sheets/Airtable로 내보내기 | ❌ | ❌ | ❌ | ✅ 무료 |
비즈니스 사용자에게 데이터 형식이 중요한 이유
지저분한 데이터는 보이지 않는 노동을 만듭니다. 스크레이퍼가 성공적으로 동작해도 다음과 같다면 운영 실패가 될 수 있어요.
- 가격이 깔끔한 숫자가 아니라 통화 기호가 붙은 문자열로 저장됨
- 빈 값 표현이 제각각임(빈 문자열, null, "N/A" 혼용)
- 이미지가 저해상도 썸네일만 있음
- 리뷰 항목이나 사양을 분석 전에 다시 가공해야 함
이커머스 운영팀에게 깔끔한 데이터는 분석 속도와 의사결정에 직접 영향을 줍니다. Thunderbit의 AI는 숫자는 숫자, 날짜는 날짜, URL은 URL처럼 타입별로 데이터를 정리해 바로 사용할 수 있게 해 줍니다. GitHub 저장소들은 이 부분의 편차가 크고, 정리 시간은 금방 누적됩니다.
빠른 참고용: Amazon Scraper GitHub 모범 사례 체크리스트
- 클론하기 전에 마지막 커밋 날짜를 확인하세요. Amazon에서는 6개월 이상이면 강한 경고 신호입니다.
- 설정 전에 이슈에서 "captcha," "503," "blocked," "not working"을 검색하세요.
- 일반
requests보다curl_cffi같은 브라우저 위장 HTTP 클라이언트를 우선 사용하세요. - 헤더, TLS 프로필, 언어, 프록시 지리 정보를 일치시키세요. 모순이 있으면 안 됩니다.
- 브라우징 흐름에는 스티키 세션을 쓰고, 매 요청마다 무작정 로테이션하지 마세요.
- 무작위 속도 조절과 지수 백오프를 추가하세요.
- 반복되는 CAPTCHA는 퍼즐이 아니라 소진된 세션으로 취급하세요.
- HTTP 클라이언트가 페이지를 안정적으로 재현하지 못할 때만 헤드리스 브라우저를 사용하세요.
- 실패한 실행이 안전하게 재개될 수 있도록 체크포인트와 상태를 저장하세요.
- 같은 관리형 API든 노코드 도구든 대체 플랜을 준비하세요.
2026년 Amazon 스크래핑의 법적·윤리적 고려사항
짧게 알아둘 만한 내용만 말씀드릴게요.
Amazon의 정책은 제한적이며, 점점 더 강화되고 있습니다. 가장 강한 신호는 다음과 같습니다.
- Amazon의 도움말 페이지는 이제 를 반환하며 다음 문구를 보여줍니다. "To discuss automated access to Amazon data please contact api-services-support@amazon.com."
- Amazon의 는 다양한 동적 경로, 리뷰 경로, 프로필, 위시리스트, 오퍼 목록 경로를 차단합니다.
- Amazon의 는 은밀하거나 위장된 에이전트 접근, 보안 조치 우회, 에이전트를 Google Chrome으로 잘못 식별하는 행위를 명시적으로 문제 삼았습니다. Amazon은 이 사건에 대해 도 발표했습니다.
- Amazon은 2025년 말 해 OpenAI 크롤러에 대한 접근을 더 막았습니다.
실질적 위험은 공개 상품 페이지에서 인증된 흐름, 위장된 자동화, 고용량 상업적 추출로 넘어갈수록 분명히 커집니다. 이것은 법률 자문이 아니니, 구체적인 상황은 여러분의 법무팀에 문의하세요.
핵심 정리: 차단당하지 않고 신뢰할 수 있는 Amazon 데이터 얻기
중요도 순으로 정리하면:
- 클론 전에 점검하세요. GitHub 결과의 대부분은 낡았거나, 튜토리얼이거나, 상용 API 위의 래퍼라고 가정하세요.
- 네트워크 계층부터 업그레이드하세요. TLS 핑거프린팅과 세션 일관성이 HTML 셀렉터보다 더 중요합니다.
- 무작위 프록시 난장판 대신 스티키 residential 세션을 쓰세요. 세션 내부가 아니라 세션 사이에서만 로테이션하세요.
- 사람처럼, 스트레스 테스트처럼 말고 요청하세요. 무작위 지연과 지수 백오프는 필수입니다.
- 단발성 CAPTCHA는 풀되, 반복되는 CAPTCHA 세션은 버리세요. 소진된 핑거프린트를 억지로 뚫으려 하지 마세요.
- 대체 수단을 준비하세요. Amazon은 주중 한가운데 뭔가를 바꿀 것이고, 여러분의 GitHub 스크레이퍼는 깨질 겁니다. 같은 유지보수형 노코드 도구나 관리형 API가 있으면, 디버깅하는 동안에도 데이터 파이프라인을 살릴 수 있습니다.
- 출력 품질을 우선하세요. 깔끔하고 타입이 정리된 데이터가, 빠르지만 지저분한 스크레이퍼보다 downstream 시간을 더 많이 절약해 줍니다.
커스터마이징보다 신뢰성이 더 중요하다면, Thunderbit가 유지보수되는 대안이 됩니다. 을 확인하거나 에서 튜토리얼을 보세요. 완전한 제어를 원하는 개발자는 GitHub 저장소를 얼마든지 사용할 수 있지만, 이 가이드에서 다룬 차단 방지와 유지보수 관행을 함께 적용해야 합니다.
자주 묻는 질문
GitHub 스크레이퍼로 Amazon 상품 데이터를 스크래핑하는 것은 합법인가요?
Amazon의 서비스 약관은 자동화된 데이터 수집을 제한하며, Amazon은 중지 요구서와 기술적 대응책을 통해 이를 적극적으로 집행해 왔습니다(특히 2025~2026년). 공개적으로 접근 가능한 상품 데이터 스크래핑은 회색지대이고, 로그인 뒤의 데이터를 긁거나 봇을 실제 브라우저처럼 위장하는 것은 더 큰 위험을 동반합니다. 이 내용은 법률 자문이 아니며, 구체적인 사용 사례는 법무팀에 문의하세요.
Amazon scraper GitHub 저장소는 얼마나 자주 깨지나요?
매우 자주요. Amazon은 정기적으로 페이지 레이아웃을 바꾸고, 새로운 안티봇 계층을 추가하며, 엔드포인트를 폐기합니다. 이 글을 위한 점검에서는 널리 노출된 8개 저장소 중 약 3개만 2026년에 명확히 작동하는 것으로 보였습니다. "작동 중"인 저장소도 CAPTCHAs와 503 오류에 대한 열린 이슈가 있는 경우가 많아요. 몇 주에서 몇 달마다 디버깅이나 업데이트가 필요하다고 예상하는 편이 좋습니다.
2026년에 GitHub에서 가장 좋은 Amazon scraper는 무엇인가요?
단 하나의 승자는 없습니다. 사용 사례와 기술 숙련도에 따라 달라져요. 가볍고 직접적인 Python 스크레이퍼를 찾는다면 가 비교적 최신 옵션 중 하나입니다. 관리형 API를 통한 넓은 범위를 원한다면 가 동작하긴 하지만, 진정한 DIY는 아닙니다. 어떤 저장소든 직접 쓰기 전에 이 글의 최신성 체크리스트로 먼저 평가해 보세요.
Thunderbit으로 코딩 없이 Amazon을 스크래핑할 수 있나요?
네. Thunderbit의 은 상품명, 가격, ASIN, 평점, 브랜드, 재고 상태 등을 한 번 클릭으로 추출합니다. 로그인 필요 페이지를 위한 브라우저 스크래핑 모드, 공개 페이지를 빠르게 처리하는 클라우드 스크래핑, 반복 작업을 위한 예약 스크래핑, Google Sheets, Airtable, Notion, Excel로의 무료 내보내기를 지원합니다. 을 설치하면 시작할 수 있어요.
Amazon을 스크래핑할 때 IP가 차단되는 것을 어떻게 피하나요?
층위별 접근이 필요합니다. (1) 일반 requests에서 curl_cffi 같은 TLS 위장 클라이언트로 바꾸고, (2) 무작위 데이터센터 로테이션 대신 스티키 세션이 있는 residential 프록시를 사용하고, (3) 무작위 속도 조절과 지수 백오프를 추가하고, (4) 전체 헤더 세트를 브라우저 프로필과 마켓플레이스 로케일에 맞추고, (5) 반복 CAPTCHA는 끝없이 푸는 퍼즐이 아니라 세션을 종료해야 한다는 신호로 보세요. 더 자세한 내용은 이 글 앞부분의 차단 방지 의사결정 매트릭스를 참고하세요.