GitHub에서 "amazon scraper"를 검색하면 약 3,515개 저장소가 뜹니다. 여기서 최근 6개월 안에 푸시된 것만 추리면 약 727개로 확 줄어요. 전체의 20%도 안 됩니다. 나머지는 방치된 튜토리얼, 낡은 래퍼, 그리고 Amazon이 방어를 조인 순간 멈춰버린 스크립트들이죠.
저는 Amazon 스크레이퍼 저장소를 한참 들여다보고, GitHub 이슈와 Reddit·Stack Overflow 스레드를 따라다니며 시간을 꽤 썼어요. 패턴은 한결같아요. 누군가 인기 저장소를 찾아 한 시간쯤 설정한 뒤 돌려보고는 CAPTCHA나 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 라이브러리 (예: amzpy)
- Scrapy 스파이더 (예: amazon-python-scrapy-scraper)
- Selenium 또는 Playwright 브라우저 자동화 도구
- 실제로는 상용 스크래핑 서비스의 프런트엔드인 API 래퍼 프로젝트 (예: oxylabs/amazon-scraper)
실패 패턴도 뻔합니다. 대부분의 저장소가 깨지는 이유는 이래요.
- Amazon이 페이지 레이아웃이나 HTML 조각을 바꿈
- 실제 콘텐츠 대신 503이나 CAPTCHA를 돌려줌
- 스크레이퍼의 TLS와 HTTP 핑거프린트가 더는 브라우저처럼 안 보임
- 로케일, 언어, 헤더가 어긋나며 의심을 삼
- 유지보수자가 원래의 좁은 목적을 푼 뒤 프로젝트를 떠남
별점이 높다고 "지금도 된다"는 뜻은 아니에요. 이 글을 위한 점검에서, 널리 노출된 8개 저장소 중 2026년에도 확실히 살아 있어 보이는 건 약 3개뿐이었어요.
아무 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개를 직접 확인했어요. 결과는 꽤 씁쓸했어요.
| 저장소 / 도구 | 별점 | 마지막 커밋 신호 | 범위 | 2026 상태 | 메모 |
|---|---|---|---|---|---|
| oxylabs/amazon-scraper | ~2,872 | 2026-04-02 | 관리형 스크레이퍼 API 래퍼 | 살아 있음, 하지만 직접 구축용은 아님 | 최신이지만 사실상 관리형 서비스의 프런트엔드 |
| omkarcloud/amazon-scraper | ~214 | 2026-02-25 | 검색, 상세, 리뷰용 관리형 API | 살아 있음, 하지만 직접 구축용은 아님 | 범위는 좋지만 원시 스크레이퍼가 아니라 API 제품 |
| theonlyanil/amzpy | ~110 | 2026-02-26 | 경량 Python 라이브러리 | 살아 있음 | curl_cffi를 사용하는 가장 분명한 직접 GitHub 스크레이퍼 |
| philipperemy/amazon-reviews-scraper | ~134 | 2024-11-21 | 리뷰 전용 | 범위는 좁지만 사용 가능 | 오래됐고 리뷰에 매우 특화됨 |
| python-scrapy-playbook/amazon-python-scrapy-scraper | ~74 | 마지막 커밋 2023; 저장소 푸시 2024-08-20 | Scrapy 스파이더 + 프록시 미들웨어 | 튜토리얼 수준, 노후화 중 | 학습용으로는 유용하지만, 바로 쓰는 2026 스택은 아님 |
| drawrowfly/amazon-product-api | ~744 | 2022-11-13 | 검색, 상세, 리뷰용 Node CLI | 고위험 | 범위는 넓지만 유지보수가 너무 오래됨 |
| tducret/amazon-scraper-python | ~881 | 2020-10-13 | 검색 → CSV | 2026년엔 사실상 종료 | 과거에는 인기 있었지만, 지금은 분명히 낡음 |
| scrapehero-code/amazon-scraper | ~432 | 2020-06-21 | 검색/상품 튜토리얼 | 2026년엔 종료 | 사실상 아카이브 수준 |
공개 이슈도 같은 얘기를 합니다. drawrowfly/amazon-product-api에는 "All requests receive captcha response."라는 이슈가, theonlyanil/amzpy에는 "Doesn't seem to be working."가 올라와 있어요. python-scrapy-playbook의 scraper에는 "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 설정을 쓰는데, 이 조합은 JA3와 Akamai HTTP/2 핑거프린트로 식별됩니다.
일반 requests나 보통의 httpx는 헤더는 베껴도 Chrome 같은 TLS·HTTP/2 동작은 복제하지 못해요. Amazon은 그 틈을 알아챕니다.
curl_cffi는 이 문제를 정면으로 풉니다. 브라우저 위장 기능을 제공하고 chrome136, safari184, firefox133 같은 대상을 지원해서, HTTP 클라이언트의 TLS 핑거프린트가 실제 브라우저와 일치하게 돼요. 문서도 무작위 JA3 문자열 생성은 피하라고 분명히 경고합니다. 브라우저 핑거프린트는 버전마다 대체로 고정돼 있어서, 무작위 값은 실제 핑거프린트를 복사하는 것보다 훨씬 쉽게 탐지되거든요.
커뮤니티 데이터도 이를 뒷받침해요. curl_cffi + Amazon 관련 Reddit 스레드에서는 impersonate 인자로 브라우저 프로필을 바꾸고 헤더를 맞추는 게 유용하다고 확인합니다. 또 다른 Reddit 스레드는 Amazon이 TLS 핑거프린트를 보고 클라이언트를 "한두 달쯤 후" 막는다고 언급해요. Stack Overflow 스레드에서는 Amazon이 python-requests를 핑거프린팅하는지 묻는데, 답은 그렇다는 쪽에 가까워요.
아직도 기본 requests를 Amazon용 첫 클라이언트로 쓰고 있다면, 다른 걸 손보기 전에 그 가정부터 바꾸세요.
프록시 로테이션, 제대로 하는 법(그냥 "프록시 쓰기"가 아님)
프록시의 핵심은 최대한 많이 바꾸는 데 있지 않아요. 세션을 그럴듯하게 보이게 하는 데 있어요.
Residential vs. datacenter: 데이터센터 프록시는 싸지만 탐지가 쉬워요. Residential 프록시는 비싸지만 Amazon이 훨씬 덜 걸러냅니다. Bright Data residential 가격은 종량제로 GB당 $4.00(약 5천 4백 원)에서 시작해 큰 요금제에선 GB당 $3.50까지 내려가요. Oxylabs residential은 GB당 $6부터고요. Amazon은 까다로운 타깃이라 residential 프록시에 프리미엄을 낼 값어치가 있어요.
요청 단위 vs. 세션 단위 로테이션: 대부분의 튜토리얼이 여기서 헛다리를 짚어요. 쿠키와 헤더는 그대로 두고 요청마다 프록시만 바꾸면, 사람 같아지기는커녕 오히려 더 수상해 보일 수 있어요. 더 안전한 패턴은 이래요.
- 가능하면 검색 → 상품 → 리뷰 탐색을 같은 스티키 세션에서 유지
- 매 요청이 아니라, 새 검색 여정을 시작할 때 세션을 바꿈
- 한 브라우징 세션 안에서 무작위로 바꾸지 말고, 세션과 세션 사이에서만 로테이션
한 Reddit 댓글은 일반 ISP IP가 인기 이커머스 사이트에서 모바일 IP만큼 잘 안 통한다고 짚었어요. 또 다른 스레드는 User-Agent를 돌리고 residential 프록시를 써도 차단됐다고 전하는데, 프록시만으로는 부족하다는 점을 잘 보여줍니다.
요청 속도 조절, 백오프, 레이트 리밋
Amazon의 503 페이지는 그냥 우연한 오류가 아니에요. 피드백이에요.
500개가 넘는 ASIN을 긁다 503을 만난 Stack Overflow 글에서는, 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 로케일을 크롤링한 한 Reddit 사용자는 같은 봇 설정이 일부 로케일에서만 탐지된다고 했고, 다른 댓글은 Accept-Language 같은 지역 관련 헤더를 지목했어요.
규칙은 간단합니다. 헤더, TLS/브라우저 프로필, 프록시 지리 정보는 서로 모순되면 안 돼요. Chrome 헤더를 보내며 Firefox UA를 쓰지 말고, 미국 프록시를 쓰면서 Accept-Language: de-DE를 보내지도 마세요.
CAPTCHA 처리: 언제 풀고, 언제 물러나나
CAPTCHA에 걸렸다는 건 이미 Amazon이 수상하게 보고 있다는 뜻이에요. 푼다고 신뢰 점수가 초기화되지는 않아요.
드물고 단발성인 CAPTCHA라면:
amazoncaptchaPyPI 패키지는 순수 Python 기반 Amazon 텍스트 CAPTCHA 솔버예요. 다만 최신 릴리스가 2023년 5월이라, 지속 전략이라기보다 전술 도구로 보세요- 2Captcha는 Amazon Captcha를 1,000회 해결당 $0.45(약 6백 원)로 책정합니다
반복되는 CAPTCHA 루프라면:
- 계속 풀지 말고 물러나세요
- 반복 CAPTCHA는 세션이 이미 소진됐다는 신호예요. 풀어도 핑거프린트, 세션 기록, IP 평판은 회복되지 않아요
- 프록시 서브넷별로 CAPTCHA가 몰린다면, 문제는 파서가 아니라 네트워크 계층이에요
헤드리스 브라우저가 정말 필요한 경우와 과한 경우
잘못된 직감은 모든 작업에 Playwright를 쓰는 거예요.
브라우저가 좋은 경우:
- JavaScript 렌더링이나 로케일 상태에 좌우되는 검색 결과
- 로그인 또는 사인인 페이지로 리디렉션되는 리뷰 흐름
- 쿠키와 브라우저 컨텍스트가 원시 속도보다 중요한 워크플로
브라우저가 과한 경우:
- 평범한 공개 상품 페이지
- 브라우저처럼 보이는 HTTP 클라이언트만으로 충분한 정적 상품 상세 추출
- 연산 효율이 중요한 대규모 일괄 수집
가장 가벼운 클라이언트부터 시작하세요. 규모 있게 긁는 법을 다룬 한 Reddit 스레드는 흐름을 이렇게 권합니다. 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 공식 Product Advertising API에 대한 불만도 큽니다. 접근 제한이 빡빡하고, 데이터도 적으며, 등록 요건도 많은 판매자가 채우기 어렵거든요.
GitHub Amazon Scraper가 계속 유지보수를 요구하는 이유
위 점검이 이걸 잘 보여줍니다.
- 낡은 저장소는 수정 없이 깨짐 보고만 쌓여요
- "작동 중"인 저장소도 이제 README에서 안티봇 대응을 노골적으로 언급합니다
- 커뮤니티 스레드는 점점 CSS 셀렉터보다 TLS 핑거프린트, CAPTCHA 루프, 프록시 품질에 집중합니다
비즈니스 사용자에게는 그 유지보수 부담이 진짜 숨은 비용이에요. 저장소는 무료지만, 새벽 2시에 디버깅하는 여러분의 시간은 무료가 아니죠.
실용적인 Amazon Scraper 대안으로서의 Thunderbit
Thunderbit는 코드 없이 제목, 가격, ASIN, 평점, 브랜드, 재고 상태, 배송 출발지, 원본 URL을 뽑는 Amazon Products Scraper 템플릿을 줍니다.
실제론 이런 차이가 있어요.
- 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 방식의 실제 산출물 품질
저장소들의 실제 출력 품질을 비교하는 곳은 거의 없어요. 사용자는 "어떤 도구가 가장 깔끔하고 완전한 데이터를 주는가"를 무척 중시하지만, 결국 각 저장소를 직접 클론해 테스트해야 하죠. 이 섹션이 그 공백을 메웁니다.
인기 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 클라이언트가 페이지를 안정적으로 재현하지 못할 때만 헤드리스 브라우저를 쓰세요.
- 실패한 실행이 안전하게 재개되도록 체크포인트와 상태를 저장하세요.
- Thunderbit 같은 관리형 API든 노코드 도구든 대체 플랜을 준비하세요.
2026년 Amazon 스크래핑의 법적·윤리적 고려사항
짧게 알아둘 것만 짚을게요.
Amazon의 정책은 제한적이고 점점 더 강해지고 있어요. 가장 강한 신호는 이래요.
- Amazon 도움말 페이지는 이제 403 페이지를 반환하며 이렇게 안내합니다. "To discuss automated access to Amazon data please contact api-services-support@amazon.com."
- Amazon robots.txt는 다양한 동적 경로, 리뷰 경로, 프로필, 위시리스트, 오퍼 목록 경로를 차단합니다.
- Amazon이 2025년 10월 31일 Perplexity에 보낸 중지 요구서는 은밀하거나 위장된 에이전트 접근, 보안 조치 우회, 에이전트를 Google Chrome으로 잘못 식별하는 행위를 명시적으로 문제 삼았어요. Amazon은 이 사건에 대해 공식 입장문도 냈고요.
- Amazon은 2025년 말 봇 차단 범위를 넓혀 OpenAI 크롤러의 접근을 더 막았어요.
실질 위험은 공개 상품 페이지에서 인증된 흐름, 위장 자동화, 고용량 상업적 추출로 갈수록 분명히 커집니다. 이 글은 법률 자문이 아니니, 구체적인 상황은 법무팀에 문의하세요.
핵심 정리: 차단당하지 않고 믿을 만한 Amazon 데이터 얻기
중요도 순으로 정리하면:
- 클론 전에 점검하세요. GitHub 결과의 대부분은 낡았거나, 튜토리얼이거나, 상용 API 위의 래퍼라고 가정하세요.
- 네트워크 계층부터 손보세요. TLS 핑거프린팅과 세션 일관성이 HTML 셀렉터보다 더 중요합니다.
- 무작위 프록시 난장판 대신 스티키 residential 세션을 쓰세요. 세션 안이 아니라 세션 사이에서만 로테이션하세요.
- 사람처럼, 스트레스 테스트처럼 말고 요청하세요. 무작위 지연과 지수 백오프는 필수예요.
- 단발성 CAPTCHA는 풀되, 반복되는 CAPTCHA 세션은 버리세요. 소진된 핑거프린트를 억지로 뚫으려 하지 마세요.
- 대체 수단을 준비하세요. Amazon은 주중 한가운데 뭔가를 바꿀 거고, 여러분의 GitHub 스크레이퍼는 깨질 겁니다. Thunderbit 같은 유지보수형 노코드 도구나 관리형 API가 있으면, 디버깅하는 동안에도 데이터 파이프라인을 살릴 수 있어요.
- 출력 품질을 우선하세요. 깔끔하고 타입이 정리된 데이터가, 빠르지만 지저분한 스크레이퍼보다 downstream 시간을 더 아껴줍니다.
커스터마이징보다 신뢰성이 더 중요하다면 Thunderbit가 유지보수되는 대안이 됩니다. Amazon Products Scraper 템플릿을 확인하거나 Thunderbit YouTube 채널에서 튜토리얼을 보세요. 완전한 제어를 원하는 개발자라면 GitHub 저장소를 얼마든지 써도 됩니다. 단, 이 가이드에서 다룬 차단 방지와 유지보수 관행을 함께 적용해야 해요.
자주 묻는 질문
GitHub 스크레이퍼로 Amazon 상품 데이터를 스크래핑하는 것은 합법인가요?
Amazon의 서비스 약관은 자동화된 데이터 수집을 제한하며, Amazon은 중지 요구서와 기술적 대응책으로 이를 적극적으로 집행해 왔어요(특히 2025~2026년). 공개적으로 접근 가능한 상품 데이터 스크래핑은 회색지대이고, 로그인 뒤의 데이터를 긁거나 봇을 실제 브라우저처럼 위장하는 건 위험이 더 큽니다. 이 내용은 법률 자문이 아니니, 구체적인 사용 사례는 법무팀에 문의하세요.
Amazon scraper GitHub 저장소는 얼마나 자주 깨지나요?
아주 자주요. Amazon은 정기적으로 페이지 레이아웃을 바꾸고, 새 안티봇 계층을 더하며, 엔드포인트를 폐기합니다. 이 글을 위한 점검에서는 널리 노출된 8개 저장소 중 약 3개만 2026년에 명확히 작동하는 것으로 보였어요. "작동 중"인 저장소도 CAPTCHA와 503 오류에 대한 열린 이슈가 있는 경우가 많고요. 몇 주에서 몇 달마다 디버깅이나 업데이트가 필요하다고 보는 편이 좋아요.
2026년에 GitHub에서 가장 좋은 Amazon scraper는 무엇인가요?
단 하나의 승자는 없어요. 사용 사례와 기술 숙련도에 따라 달라집니다. 가볍고 직접적인 Python 스크레이퍼를 찾는다면 amzpy가 비교적 최신 옵션 중 하나예요. 관리형 API를 통한 넓은 범위를 원한다면 omkarcloud/amazon-scraper가 동작은 하지만, 진정한 DIY는 아닙니다. 어떤 저장소든 직접 쓰기 전에 이 글의 최신성 체크리스트로 먼저 평가해 보세요.
Thunderbit으로 코딩 없이 Amazon을 스크래핑할 수 있나요?
네. Thunderbit의 Amazon Products Scraper 템플릿은 상품명, 가격, ASIN, 평점, 브랜드, 재고 상태 등을 한 번 클릭으로 추출합니다. 로그인 필요 페이지를 위한 브라우저 스크래핑 모드, 공개 페이지를 빠르게 처리하는 클라우드 스크래핑, 반복 작업을 위한 예약 스크래핑, Google Sheets, Airtable, Notion, Excel로의 무료 내보내기를 지원해요. Thunderbit Chrome 확장 프로그램을 설치하면 시작할 수 있어요.
Amazon을 스크래핑할 때 IP가 차단되는 것을 어떻게 피하나요?
층층이 접근해야 해요. (1) 일반 requests에서 curl_cffi 같은 TLS 위장 클라이언트로 바꾸고, (2) 무작위 데이터센터 로테이션 대신 스티키 세션이 있는 residential 프록시를 쓰고, (3) 무작위 속도 조절과 지수 백오프를 더하고, (4) 헤더 전체를 브라우저 프로필과 마켓플레이스 로케일에 맞추고, (5) 반복 CAPTCHA는 끝없이 푸는 퍼즐이 아니라 세션을 종료해야 한다는 신호로 보세요. 더 자세한 내용은 이 글 앞부분의 차단 방지 의사결정 매트릭스를 참고하세요.
