자체 방문 통계는 항상 수집됩니다. 사용자가 공개 페이지를 어떻게 이용하는지 파악하는 데 쓰이는 Google Analytics(로그인한 워크스페이스는 제외)는 동의한 경우에만 사용됩니다. 자세한 내용은 개인정보 처리방침을 참고하세요.

Amazon 페이지 하나에 프록시 트래픽은 얼마나 들까?

Amazon 상품 페이지 요청 40건과 전체 브라우저 로드 6건의 바이트를 측정하고, IPFoxy의 GB당 정가로 비용을 계산해 페이지 1,000개당 비용을 데이터 API와 비교했습니다. 결과는 수집 방식, 구매하는 요금제, 요청 성공률에 따라 달라집니다.

일러스트: 상품 페이지를 띄운 브라우저 창이 저울 위에 놓여 있습니다. 데이터 패킷이 계량기가 달린 파이프를 통해 흘러나가며, 이는 사용량 기준으로 과금되는 프록시 트래픽을 뜻합니다. 저울 옆에는 동전 더미가 있습니다.

로테이팅 주거용 프록시는 GB 단위로 판매됩니다. 따라서 한 페이지가 내려받는 바이트 수가 그 페이지의 프록시 비용을 결정합니다. 2026년 10월 24일 싱가포르 시간 18:30부터 18:41까지 Amazon 미국 상품 페이지 요청 40건과 전체 브라우저 로드 6건을 측정했습니다. HTML만 받을 때 페이지 크기 중앙값은 0.44 MB였습니다. 헤드리스 브라우저로 전체를 로드하면 중앙값은 7.96 MB로 18배 많았습니다. IPFoxy 로테이팅 주거용 프록시 정가 기준으로 1,000페이지 분량의 트래픽 비용은 $0.88에서 $47.71입니다. 같은 페이지를 데이터 API로 받으면 호출 1,000건당 $1.39입니다.

이 글은 프록시 트래픽 비용과 데이터 API 비용을 같은 기준으로 비교합니다. 어느 쪽이 더 저렴한지는 수집 방식, 구매하는 요금제, 요청 성공률에 따라 달라집니다. 아래의 모든 수치에는 출처가 있으며, 원시 데이터도 내려받을 수 있습니다.

Amazon 상품 페이지 1개를 가져오는 데 전송된 바이트 중앙값을 방식별로 나타낸 가로 막대 차트: EveryInfra 상품 JSON 0.004 MB(프록시 없음), curl과 gzip으로 HTML만 받기 0.442 MB(16페이지, 범위 0.213~0.496 MB), 이미지와 폰트를 차단한 헤드리스 Chrome 3.44 MB(3페이지, 범위 3.43~4.03 MB), 전체 페이지를 로드한 헤드리스 Chrome 7.96 MB(3페이지, 범위 4.15~13.60 MB). 2026년 10월 24일 싱가포르 광대역 회선에서 프록시 없이 측정했습니다.

바이트부터 측정하는 이유

IPFoxy는 로테이팅 주거용 프록시를 트래픽 단위로 판매합니다. 10월 24일 기준 요금 페이지에는 1GB, 10GB, 50GB, 100GB, 500GB, 1000GB의 6개 요금제가 있었습니다. GB당 가격은 $5.99에서 $1.99까지 내려가고, 유효 기간은 30~180일입니다. 1000GB를 넘으면 "GB당 $0.60부터"인 맞춤 요금제가 있습니다(IPFoxy 로테이팅 주거용 프록시 요금). IP 풀은 200개 이상의 국가와 지역을 포괄합니다(IPFoxy 지원 지역). 트래픽으로 과금되는 상품의 비용은 내려받은 바이트 × 가격입니다. 가격은 웹사이트에 나와 있지만, 바이트는 직접 측정해야 합니다.

"페이지가 얼마나 무거운가"에 대한 답은 하나가 아닙니다. HTTP Archive의 Web Almanac 2025는 페이지 무게를 브라우저가 페이지를 표시하기 위해 내려받는 모든 바이트로 정의합니다. 또한 가장 많은 바이트를 차지하는 것은 이미지라고 보고합니다(Web Almanac 2025: Page Weight). 하지만 데이터 수집 스크립트가 항상 이미지를 내려받지는 않습니다. HTML만 받는 경우와 전체 브라우저 실행은 약 10배 차이가 납니다. 그래서 흔히 쓰는 세 가지 방식을 측정했습니다.

테스트 전에 정한 합격·불합격 기준

테스트 전에 세 가지 규칙을 정했습니다.

  1. 비교 단위는 "상품 페이지 1개의 데이터"입니다. 합격 기준: 방식마다 실제 상품 페이지(차단 페이지가 아니라 제목이 상품명인 페이지)를 3개 이상 가져와야 합니다.
  2. 프록시는 전송된 트래픽으로 과금하므로, 압축 해제 후 크기가 아니라 실제 전송된 바이트를 셉니다. HTML은 curl의 size_download와 size_header를 더합니다(curl 매뉴얼, --write-out; Everything curl: write-out 변수). 브라우저는 Chrome DevTools Protocol에서 요청마다 Network.loadingFinished.encodedDataLength를 더합니다(CDP Network 도메인).
  3. 1 GB = 10⁹바이트로 계산합니다(NIST 이진 배수 접두어). 1 GB를 2³⁰바이트로 계산하는 업체라면 아래 비용은 각각 약 7% 낮아집니다.

결과: 세 방식 모두 규칙 1을 통과했습니다(HTML 16페이지, 브라우저 방식별 3페이지). 규칙 2와 3은 아래에서 적용합니다.

테스트 1: 방식별 바이트

싱가포르의 가정용 광대역 회선에서 프록시 없이 테스트했습니다. 상품은 한 번의 검색 결과에서 가져왔습니다. Amazon 키워드 검색 API로 air fryer를 검색해 처음 20개 ASIN을 사용했습니다(18:30, 31.6초, $0.001389 과금).

HTML만 받기. curl로 일반 브라우저 헤더와 Accept-Encoding: gzip, deflate, br(MDN: Accept-Encoding)을 붙여 /dp/<ASIN>을 요청했으며, 4초 간격으로 20건씩 두 차례 진행했습니다. Amazon은 Brotli(RFC 7932)가 아닌 gzip(RFC 1952)으로 응답했습니다. 실제 상품 페이지 16개의 전송량 중앙값은 441,688바이트, 최솟값은 213,178바이트, 최댓값은 496,482바이트였습니다. 압축을 풀면 페이지 크기는 1.08~2.68 MB였습니다.

헤드리스 브라우저, 전체 로드. 새 Chrome 헤드리스 모드(Chrome 헤드리스 문서)에서 캐시를 끄고 상품 페이지 3개를 열어 페이지마다 15초씩 기다렸습니다. 세 페이지는 각각 13.60, 4.15, 7.96 MB를 사용했고, 페이지당 요청은 224~270건이었습니다. 첫 페이지에서 이미지는 7.03 MB(52%), 스크립트는 3.02 MB였습니다. DevTools의 "transferred size"(전송 크기)와 "resource size"(리소스 크기)는 서로 다른 값이며, 이 글에서는 앞의 값을 사용합니다(Chrome DevTools 네트워크 참조).

헤드리스 브라우저, 이미지와 폰트 차단. 많은 스크립트가 이미지를 차단합니다. Playwright와 Puppeteer 모두 그 방법을 문서로 안내합니다(Playwright: Network; Puppeteer: request interception). CDP Network.setBlockedURLs로 이미지와 폰트를 차단하자 세 페이지는 4.03, 3.44, 3.43 MB를 사용했습니다. 나머지 전송량의 대부분은 스크립트가 차지했으며, 약 3.0 MB(87%)였습니다.

방법샘플페이지당 전송량 중앙값범위
HTML만 받기(curl, gzip)16페이지0.442 MB0.213–0.496 MB
헤드리스 Chrome, 이미지·폰트 차단3페이지3.44 MB3.43–4.03 MB
헤드리스 Chrome, 전체 페이지 로드3페이지7.96 MB4.15–13.60 MB
EveryInfra 상품 JSON(프록시 없음)1회0.004 MB—

두 브라우저 행은 각각 3페이지뿐입니다. 그중 두 페이지에서는 CDP가 메인 문서를 0바이트로 기록했습니다. 따라서 이 두 행은 정확한 값이 아니라 하한값입니다.

테스트 2: 프록시 없이 접속하면 어느 스토어가 보일까?

같은 요청에서 한 가지가 더 드러났습니다. 페이지에 무엇이 표시될지는 출구 IP가 결정합니다.

  • 1차, 쿠키 없음: 상품 페이지 20개 중 19개가 HTTP 200을 반환했지만, 본문은 3,781바이트짜리 "Click the button below to continue shopping" 페이지였습니다. 실제 상품 페이지는 1개뿐이었습니다. 검색 페이지(/s?k=) 3개는 모두 503을 반환했습니다.
  • 2차는 쿠키를 받기 위해 홈페이지를 먼저 방문한 뒤 시작했습니다. 처음 5건은 여전히 중간 안내 페이지였고, 이후 15건은 실제 상품 페이지였습니다. 요청 40건 중 실제 페이지를 받은 것은 16건으로 40%였습니다.
  • 실제 페이지 16개 모두 배송지가 싱가포르로 표시되었습니다. 그중 2개에는 해당 지역으로 배송할 수 없는 상품이라는 안내가 있었습니다.
  • 브라우저에서 amazon.com/s?k=air+fryer는 싱가포르 스토어인 "Amazon.sg : air fryer" 제목의 페이지로 이동했습니다.

따라서 미국 쇼핑객이 보는 가격, 배송 정보, 검색 결과를 보려면 미국 IP에서 요청해야 합니다. 주거용 프록시는 바로 이런 용도로 씁니다. IPFoxy 솔루션 페이지는 이커머스, 데이터 수집, 광고 검증을 주요 용도로 소개합니다(IPFoxy 솔루션). IPFoxy 블로그에도 이커머스 데이터 수집 가이드가 있습니다(IPFoxy: 이커머스 데이터 수집 가이드). 차단 페이지 자체는 작습니다(헤더 포함 4,206바이트). 차단 페이지는 트래픽은 거의 쓰지 않지만 요청 횟수와 시간을 소모합니다.

상품 페이지 1,000개의 비용

테스트 1의 중앙값에 1,000과 요금제별 IPFoxy GB당 가격을 곱했습니다. 모든 페이지가 첫 시도에 성공한다고 가정합니다. 재시도, 프록시 터널 핸드셰이크, 업로드 바이트는 계산에 넣지 않았습니다.

방법1GB 요금제 $5.99/GB10GB 요금제 $4.99/GB100GB 요금제 $2.99/GB1000GB 요금제 $1.99/GB
HTML만 받기$2.65$2.20$1.32$0.88
브라우저, 이미지·폰트 차단$20.59$17.15$10.28$6.84
브라우저, 전체 로드$47.71$39.74$23.81$15.85

Amazon 상품 상세 API는 같은 페이지를 호출당 $0.001389, 즉 호출 1,000건당 $1.39에 반환합니다(기능 카탈로그, 18:29 확인). 실패하거나 결과가 비어 있는 호출은 과금되지 않습니다. 18:37에 B0CYJDVT31로 한 번 호출했습니다. 9.1초 만에 필드 20개를 반환했고, JSON 본문은 3,569바이트였습니다. 목록 필드(가격, 평점, 평점 수, 브랜드)만 필요하다면 검색 호출 한 번에 상품 20개가 반환되므로, 상품 1,000개에 약 $0.07가 듭니다.

Amazon 상품 페이지 1,000개의 프록시 트래픽 비용을 IPFoxy 요금제 두 가지(GB당 5.99 미국 달러인 1GB 요금제, GB당 1.99 미국 달러인 1000GB 요금제)로 비교한 묶은 막대 차트: HTML만 받기 2.65달러와 0.88달러, 이미지와 폰트를 차단한 브라우저 20.59달러와 6.84달러, 전체 로드 브라우저 47.71달러와 15.85달러. 점선은 호출 1,000건당 1.39달러인 EveryInfra를 나타냅니다.

필요한 성공률

위 표는 성공률 100%를 가정합니다. 실제 요청은 실패하기도 하고, 실패하면 재시도해야 합니다. 성공률을 s라고 하면 성공한 페이지당 트래픽 비용은 약 "트래픽 비용 ÷ s"입니다(실패한 페이지는 약 4 KB에 불과하므로 무시합니다). HTML만 받을 때 데이터 API보다 저렴하려면 최소한 다음 성공률이 필요합니다.

  • 1GB, 10GB, 50GB 요금제: 각각 190%, 159%, 127%. 이 요금제들은 어떤 경우에도 더 저렴해지지 않습니다.
  • 100GB 요금제: 95%.
  • 500GB 요금제: 76%.
  • 1000GB 요금제: 63%.

프록시 없이 싱가포르 광대역에서 요청했을 때는 40%의 요청에서 실제 페이지를 받았습니다. 미국 주거용 IP를 거치면 성공률이 달라집니다. IPFoxy 계정이 없어 이 값은 측정하지 않았으며, 수치도 제시하지 않습니다. 위 공식에 직접 측정한 성공률을 넣어 계산하시기 바랍니다.

HTML만 받을 때 프록시 트래픽 비용이 호출 1,000건당 1.39 미국 달러인 데이터 API보다 저렴해지는 데 필요한 성공률을 나타낸 막대 차트: 1GB 요금제 190%, 10GB 요금제 159%, 50GB 요금제 127%로 이 세 개는 100%를 넘어 '불가'로 표시되어 있고, 100GB 요금제 95%, 500GB 요금제 76%, 1000GB 요금제 63%입니다. 점선은 100%를 나타냅니다.

이 계산에는 인건비가 포함되지 않았습니다. 페이지를 직접 수집하면 파서를 작성하고, 페이지 레이아웃이 바뀔 때마다 코드를 수정하고, 차단 페이지와 재시도를 처리해야 합니다. 데이터 API는 고정된 필드 이름으로 결과를 반환하므로 이런 작업이 필요 없습니다. 다만 데이터 API는 카탈로그에 있는 플랫폼과 필드만 지원합니다. 그 밖의 페이지는 여전히 직접 수집해야 합니다.

IPFoxy와 데이터 API, 각각 무엇을 맡길까

이 수치를 바탕으로 다음과 같이 권장합니다.

  • IPFoxy는 특정 국가의 사용자로 접속해야 하는 페이지에 사용합니다. 미국 쇼핑객 기준의 배송 정보와 최종 가격, 자사 판매자 계정, 현지 광고 게재 위치 등이 그 예입니다. 데이터 API 카탈로그에 없는 사이트나 실제 브라우저 렌더링이 필요한 페이지에도 사용합니다. 고정 주거용 IP는 하나의 스토어나 계정을 장기간 운영할 때 적합하며, 정가는 월 $7.99부터입니다(IPFoxy 고정 주거용 프록시 요금).
  • 데이터 API는 이미 카탈로그에 있는 플랫폼과 필드에 사용합니다. 고정된 필드를 시트나 데이터베이스에 넣는 대규모 작업에 가장 적합합니다. 데이터 API 호출에는 프록시가 필요 없습니다. 프록시를 거치면 프록시 트래픽만 늘어납니다.

두 가지를 한 스크립트에서 함께 쓰려면 문서의 "IPFoxy 프록시와 함께 사용하기" 섹션을 참고하세요. Python 예제는 requests 2.34.2를 사용합니다(PyPI: requests). 직접 보내는 요청은 프록시를 거치고, EveryInfra 요청은 trust_env = False로 직접 전송됩니다(Requests 고급 사용법: 프록시; Requests API: Session.trust_env). 프록시 주소는 username:password@host:port 형식이며, IPFoxy 고객센터에서 Python 설정 방법을 안내합니다(IPFoxy: Python으로 로테이팅 프록시 사용하기). 이 예제는 표준 라이브러리 urllib.request를 사용하는데, 이 라이브러리도 기본적으로 프록시 환경 변수를 읽습니다(Python urllib.request 문서). Scrapy에서는 요청 meta에 proxy를 설정합니다(Scrapy: HttpProxyMiddleware).

IPFoxy 계정이 없어서 예제의 프록시 부분은 로컬 모의 프록시로 테스트했습니다. 모의 프록시는 HTTP CONNECT 메서드로 터널을 열고(RFC 9110, 9.3.6절; MDN: CONNECT) Proxy-Authorization 헤더의 Basic 인증 정보를 확인합니다(RFC 7617; MDN: Proxy-Authorization). 올바른 비밀번호를 쓰면 예제는 모의 프록시를 거쳐 ipinfo.io에 접속한 뒤 EveryInfra 상품 데이터를 받았습니다. 잘못된 비밀번호를 쓰면 모의 프록시가 407(MDN: 407)을 반환했고, 예제는 EveryInfra를 호출하기 전에 멈췄으므로 과금도 없었습니다. HTTPS_PROXY를 모의 프록시로 설정해 보기도 했습니다. 그래도 모의 프록시 로그에는 ipinfo.io 요청만 남았으며, EveryInfra 요청은 프록시를 거치지 않았습니다.

이 데이터를 인용하는 방법

  • 원시 데이터: amazon-page-weight-2026-10-24.csv(GitHub: EveryInfra 예제 저장소, amazon-page-weight-2026-10-24.csv, 이 사이트의 사본: https://everyinfra.com/articles/proxy-traffic-cost-amazon-product-pages/amazon-page-weight-2026-10-24.csv), 51행. 각 행은 요청 1건 또는 전체 페이지 로드 1회입니다. 열은 페이지 유형, ASIN, 방식, 시각, HTTP 상태, 실제 페이지 여부(예/아니요), 전송 바이트, 요청 수, 비고입니다.
  • 확인 시각: 2026-10-24, 싱가포르 시간(UTC+8) 18:30–18:41. IPFoxy 가격도 같은 날 확인했습니다.
  • 검증 방법: HTML은 curl 8.7.1과 --write-out '%{size_download} %{size_header}'로, 브라우저는 헤드리스 모드의 Chrome 155와 CDP로 측정했으며, 내장 WebSocket을 사용하는 Node.js 26 스크립트에서 실행했습니다(Node.js 전역 객체). 측정 스크립트와 차트 스크립트는 GitHub 예제 폴더에 있으며, /docs#with-proxy에서 링크를 확인할 수 있습니다.
  • 인용 예시: EveryInfra, “Amazon 페이지 하나에 프록시 트래픽은 얼마나 들까?”, 2026-10-24, https://everyinfra.com/ko/blog/proxy-traffic-cost-amazon-product-pages (데이터 확인 2026-10-24, 18:30–18:41 SGT).

이 결과가 맞지 않는 경우

  • 작은 샘플: 실제 HTML 페이지 16개와 브라우저 방식별 3페이지이며, 모두 한 카테고리(에어프라이어)에서 가져왔습니다. 더 긴 페이지(리뷰나 옵션이 많은 페이지)는 바이트를 더 많이 씁니다. HTTP Archive 월간 보고서를 보면 페이지 무게는 시간에 따라 달라집니다(HTTP Archive: Page Weight 보고서). 1년 뒤에 다시 측정하시기 바랍니다.
  • 경로에 프록시 없음: 프록시를 거치면 헤더, 터널 핸드셰이크, 리디렉션으로 바이트가 조금 늘어나고 성공률도 달라집니다.
  • 정가 기준: IPFoxy 웹사이트에는 회원가입 할인(10GB 요금제 이상에서 17~23%)이 표시되어 있지만 적용하지 않았습니다. 현재 가격은 IPFoxy 웹사이트에서 확인하시기 바랍니다.
  • 규정 준수는 범위 밖: 이번에는 바이트만 측정했습니다. Amazon의 robots.txt는 일반 크롤러에 대해 /dp/ 상품 페이지를 차단하지 않습니다. 하지만 Scrapy, GPTBot 등 이름이 명시된 여러 크롤러에는 사이트 전체를 차단합니다(Amazon robots.txt). 이용 약관(Conditions of Use, 2026-08-14 업데이트)의 "License and Access" 섹션은 데이터 마이닝과 로봇 사용을 제한합니다(Amazon Conditions of Use). 수집하기 전에 해당 사이트의 약관을 읽어 보시기 바랍니다.

이번 테스트 비용: EveryInfra 호출 3건, 총 $0.004167(검색 1건, 상품 상세 2건). 같은 키의 요청 속도 제한으로 요청 3건이 추가로 429를 반환했으며, 이 요청들은 과금되지 않았습니다. IPFoxy는 EveryInfra의 파트너입니다. 이 글의 IPFoxy 링크에는 추천 파라미터가 없습니다. 그래서 추천 링크로 표시하지 않았습니다(유료 링크와 추천 링크에 관한 Google 규칙: Qualify your outbound links). 파트너 페이지는 IPFoxy Global Proxy입니다. 이 글의 수치는 두 웹사이트를 확인한 당일 기준입니다.

더 읽어보기

참고 자료

  1. “Rotating Residential Proxy pricing”, IPFoxy, 2026-10-24 확인. https://www.ipfoxy.com/pricing/rotating/
  2. “Static Residential Proxy pricing”, IPFoxy, 2026-10-24 확인. https://www.ipfoxy.net/pricing/residential/
  3. “How to use Rotating proxy through Python?”, IPFoxy Help Center, 2025-11-18. https://www.ipfoxy.com/help/docs/bn3BDn
  4. “Solutions”, IPFoxy, 2026-10-24 확인. https://www.ipfoxy.net/solution/
  5. “Proxy locations”, IPFoxy, 2026-10-24 확인. https://www.ipfoxy.net/country/
  6. “E-commerce data collection guide”(중국어), IPFoxy 블로그, 2026-10-24 확인. https://www.ipfoxy.net/blog/use-cases/6929
  7. “Network domain (loadingFinished, setBlockedURLs)”, Chrome DevTools Protocol, 2026-10-24 확인. https://chromedevtools.github.io/devtools-protocol/tot/Network/
  8. “Chrome Headless mode”, Chrome for Developers, 2026-10-24 확인. https://developer.chrome.com/docs/chromium/headless
  9. “Network features reference”, Chrome for Developers, 2026-10-24 확인. https://developer.chrome.com/docs/devtools/network/reference
  10. “curl manual (--write-out)”, curl 프로젝트, 2026-10-24 확인. https://curl.se/docs/manpage.html
  11. “Write out”, Everything curl, 2026-10-24 확인. https://everything.curl.dev/usingcurl/verbose/writeout.html
  12. “Advanced Usage (Proxies)”, Requests 문서, 2026-10-24 확인. https://requests.readthedocs.io/en/latest/user/advanced/
  13. “Developer Interface (Session.trust_env)”, Requests 문서, 2026-10-24 확인. https://requests.readthedocs.io/en/latest/api/
  14. requests 2.34.2, PyPI, 2026-05-14 배포. https://pypi.org/project/requests/
  15. “urllib.request”, Python 문서, 2026-10-24 확인. https://docs.python.org/3/library/urllib.request.html
  16. RFC 9110, “HTTP Semantics”, IETF, 2022-06. https://www.rfc-editor.org/rfc/rfc9110
  17. RFC 7617, “The 'Basic' HTTP Authentication Scheme”, IETF, 2015-09. https://www.rfc-editor.org/rfc/rfc7617
  18. RFC 1952, “GZIP file format specification version 4.3”, IETF, 1996-05. https://www.rfc-editor.org/rfc/rfc1952
  19. RFC 7932, “Brotli Compressed Data Format”, IETF, 2016-07. https://www.rfc-editor.org/rfc/rfc7932
  20. “CONNECT request method”, MDN, 2026-10-24 확인. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT
  21. “Proxy-Authorization header”, MDN, 2026-10-24 확인. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Proxy-Authorization
  22. “407 Proxy Authentication Required”, MDN, 2026-10-24 확인. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/407
  23. “Accept-Encoding header”, MDN, 2026-10-24 확인. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Encoding
  24. “Web Almanac 2025: Page Weight”, HTTP Archive, 2026-01-15. https://almanac.httparchive.org/en/2025/page-weight
  25. “Page Weight report”, HTTP Archive, 2026-10-24 확인. https://httparchive.org/reports/page-weight
  26. “Network”, Playwright 문서, 2026-10-24 확인. https://playwright.dev/docs/network
  27. “Request Interception”, Puppeteer 문서, 2026-10-24 확인. https://pptr.dev/guides/network-interception
  28. “Downloader Middleware (HttpProxyMiddleware)”, Scrapy 문서, 2026-10-24 확인. https://docs.scrapy.org/en/latest/topics/downloader-middleware.html
  29. “Prefixes for binary multiples”, NIST, 2026-10-24 확인. https://physics.nist.gov/cuu/Units/binary.html
  30. robots.txt, Amazon, 2026-10-24 확인. https://www.amazon.com/robots.txt
  31. “Conditions of Use”, Amazon, 2026-08-14 업데이트. https://www.amazon.com/gp/help/customer/display.html?nodeId=508088
  32. “Developers”, IPinfo, 2026-10-24 확인. https://ipinfo.io/developers
  33. “Global objects (WebSocket)”, Node.js 문서, 2026-10-24 확인. https://nodejs.org/api/globals.html
  34. EveryInfra 기능 카탈로그, GET /api/v1/social/catalog, 2026-10-24 18:29 확인. https://api.everyinfra.com/api/v1/social/catalog
  35. “Qualify your outbound links to Google”, Google Search Central, 2026-10-24 확인. https://developers.google.com/search/docs/crawling-indexing/qualify-outbound-links
  36. 원시 데이터 amazon-page-weight-2026-10-24.csv, EveryInfra 예제 저장소 everyinfra-agent-plugins, 2026-10-24. https://github.com/everyinfra/everyinfra-agent-plugins/blob/main/examples/proxy-plus-data-api/data/amazon-page-weight-2026-10-24.csv

참고 BL-36