암호화폐 시장은 결코 닫히지 않는다. 가격, 주문서, 거래, 펀딩 레이트, 24시간 통계가 수백 개의 거래소에서 매초 움직이며, 분석, 리서치, 집계, 또는 데이터셋 구축을 위해 이 데이터를 수집하는 팀은 누구든 하루 종일, 국경을 넘나들며 그 작업을 하고 있다. 이 조합은 일반적인 인프라가 제대로 처리하지 못하는 특정한 문제들을 드러낸다. IP당 적용되는 거래소 속도 제한, 국가별로 제한되는 엔드포인트와 상품, 그리고 피드에 생기는 모든 공백을 벌하는 시장이 그것이다. 레지덴셜 프록시는 이 세 가지 모두를 해결한다.
이 글은 레지덴셜 프록시가 실제로 어떻게 맞아떨어지는지, 그리고 공식 API가 프런트엔드를 스크래핑하는 것보다 더 나은 도구인 경우가 언제인지를 다루는 실전 버전이다.
암호화폐 데이터 팀이 실제로 수집하는 것
유용한 데이터 대부분은 시장 데이터다. 심볼별 최종 가격과 24시간 티커 통계, 주문서 심도, 최근 거래, OHLCV 캔들, 그리고 파생상품 쪽의 펀딩이나 금리 데이터. 대다수 거래소에서는 이를 위해 만들어진 공개 REST 또는 WebSocket API로 이 데이터를 얻을 수 있으며, 여기서부터 시작해야 한다. 프런트엔드 스크래핑은 가장자리 영역에서 등장한다. 필요한 것에 대한 공개 엔드포인트가 없는 거래소나 지역, 상장/공지 페이지, 상태나 수수료 페이지, 또는 API는 제한하지만 공개 사이트는 열어두는 데이터 소스 같은 경우다. 이 글의 요점은 두 접근 방식 모두의 근간이 되는 수집 계층이며, 두 경우 모두 동일한 계층이다.
IP 하나로는 충분하지 않은 이유: 속도 제한
거래소의 속도 제한은 엄격하며, 거의 항상 IP당 카운트된다. 많은 거래소가 가중치 시스템을 사용하는데, 서로 다른 엔드포인트가 고정된 시간 창마다 리필되는 IP당 예산에서 각기 다른 비용을 소모하며, 깊은 주문서 스냅샷 같은 더 무거운 쿼리는 이 예산을 빠르게 소진시킬 수 있다. 단일 주소에서 여러 거래소에 걸쳐 수백 개의 심볼을 폴링하면 몇 초 안에 한계에 부딪히고, 그 시점에서 속도가 제한되고, 이후 일시적으로 차단되어 피드가 멈춘다.
해결책은 모든 것을 한 주소에서 보내는 것을 멈추는 것이다. 요청을 여러 레지덴셜 IP에 분산시키면 각 IP는 자체 IP당 예산 안에 편안하게 머물면서도 전체 처리량은 배가되는데, 이는 대량 처리를 하는 모든 수집기가 의존하는 것과 동일한 로드 밸런싱 로직이며, 무제한 동시 연결이 존재하는 이유이기도 하다. 이는 공개 시장 데이터를 위한 확장 기법이지, 특정 계정의 제한을 우회하는 방법이 아니며, 각 거래소가 문서화한 제한과 약관을 장애물로 취급하기보다 존중하는 것과 함께 이루어져야 한다.
지역 제한과 지역 잠금 데이터
암호화폐는 웹에서 지리적으로 가장 파편화된 분야 중 하나다. 일부 거래소는 특정 관할권에서 완전히 이용할 수 없고, 일부는 규제상의 이유로 특정 상품이나 엔드포인트를 지역별로 제한하며, 일부는 요청이 어디서 오는지에 따라 다른 수수료, 상장 목록, 인터페이스를 제공한다. 단일 위치에서 수집하고 있다면, 다른 허용된 지역의 사용자가 보는 데이터를 단순히 볼 수 없으며, 잘못된 국가에서의 요청은 아예 차단될 수 있다.
국가별, 필요시 도시 단위 타겟팅이 가능한 레지덴셜 프록시를 사용하면 해당 데이터가 공개적으로 이용 가능한 지역의 IP에서 요청을 보낼 수 있어, 그곳의 일반 방문자가 수집할 데이터를 수집할 수 있다. 중요한 유의점은 이것이 접근이 허용된 데이터에 도달하기 위한 도구이지, 자신에게 적용되도록 의도된 제한을 회피하기 위한 것이 아니라는 점이다. 공개 시장 데이터를 수집하고, 각 거래소의 서비스 약관과 운영하는 지역의 법률을 준수하며, 지역 타겟팅은 실제 금지를 우회하기보다 지리적으로 다양한 데이터에 합법적으로 접근하는 데 사용해야 한다.
잠들지 않는 시장을 위한 신뢰성
24시간 시장이라는 것은 수집의 공백이 데이터셋에 영구적인 구멍이 된다는 뜻이며, 이 구멍들은 비용이 크다. 백테스트, 리서치 수치, 또는 한 시간 동안 조용히 누락된 피드로 구축된 분석 제품은 알아채지 못한 채 잘못되어 있다. 모든 것이 하나의 IP를 통해 실행되면, 단 한 번의 속도 제한 이벤트나 차단이 해소될 때까지 전체 피드를 멈추게 한다.
풀 전체에 분산시키면 이 단일 장애점이 제거되며, 실제 페일오버와 결합하면 어떤 경로가 저하되더라도 피드가 계속 흐르게 한다. 특정 IP에서 속도 제한 응답, 타임아웃, 또는 챌린지를 감지하고, 그 경로를 폐기한 후 새 경로로 계속 진행하는 것이 다중 지역 파이프라인에서의 페일오버 뒤에 있는 패턴이다. 이 중 아무것도 눈감고 작동하지 않으므로, 거래소별 경로별로 파이프라인을 모니터링해야 한다. 성공률, 지연 시간, 공백 감지는 소스가 데이터의 구멍이 되기 전에 저하되고 있음을 알려준다. 암호화폐 데이터의 상당수가 시간에 민감하기 때문에, 깨끗하고 지연 시간이 낮은 풀 또한 중요하며, 지리적으로 가깝고 평판이 좋은 출구 노드로 지연 시간을 낮게 유지하는 것은 각 스냅샷이 도착할 때까지 얼마나 오래된 것인지를 줄여준다.
스트림과 일관된 스냅샷을 위한 스티키 세션
모든 요청이 회전해야 하는 것은 아니다. 두 가지 경우는 유지되는 IP가 필요하다.
첫 번째는 WebSocket 스트림으로, 대부분의 실시간 주문서 및 거래 데이터가 실제로 도착하는 방식이다. 스트림은 하나의 장기 연결이므로, 열린 소켓 아래에서 회전하는 주소가 아니라 그 수명 동안 유지되는 하나의 IP가 필요하며, 이는 스트림당 스티키 세션을 의미한다. 두 번째는 일관된 스냅샷이다. 특정 시점에 여러 거래소 간 가격이나 주문서를 비교하고 있다면, 폴링할 때마다 다른 IP, 어쩌면 다른 지역이 아니라 각 거래소의 시계열이 안정적이고 일관된 관측 지점에서 나오기를 원할 것이며, 따라서 거래소별 스티키 세션이 그 뷰를 깨끗하게 유지한다. 대용량 REST 폴링은 회전시켜 속도 제한을 분산시키고, 스트림과 비교 피드는 스티키하게 유지한다. 이러한 IP의 품질이 애초에 신뢰받는지 여부를 결정하며, 좋은 평판을 가진 깨끗한 주소는 플래그된 주소가 챌린지를 받는 곳을 통과한다.
공식 API를 우선하고, 프록시로 이를 확장하라
정직한 관점은 이렇다. 거래소가 공개 시장 데이터 API를 제공하는 곳에서는 그것을 사용하라. 더 빠르고, 구조화된 데이터를 반환하며, 거래소가 의도한 접근 경로이므로 약관 내에 머무를 수 있다. 레지덴셜 프록시는 그 API를 대체하는 것이 아니라, 그것을 규모 있게, 그리고 여러 지역에 걸쳐 실행할 수 있게 해주는 것이다. 폴링을 여러 IP에 분산시켜 각각이 IP당 제한 안에 머물게 하고, 국가를 타겟팅하여 지역별 공개 데이터에 접근하고, 스트림을 위해 스티키 세션을 유지하고, 페일오버로 피드를 계속 살려둔다. 진짜 공백, 즉 뒤에 API가 없는 페이지를 위해 프런트엔드 스크래핑을 남겨두고, 같은 절제력으로 다뤄야 한다. 오직 공개 데이터만, 사이트의 약관과 적용 법률 내에서. 이것은 데이터 수집이지, 거래나 재정적 조언이 아니며, 여기에 있는 어떤 것도 특정 자산에 대한 추천이 아니다.
최소한의 설정
REST 폴링을 위한 로테이팅 레지덴셜 프록시는 클라이언트 입장에서 일반적인 프록시처럼 보인다. 타겟팅은 게이트웨이의 사용자 이름에 담기므로, 세션 식별자가 없는 US 출구는 요청마다 회전한다.
import requests
PROXY = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"proxies = {"http": PROXY, "https": PROXY}
# Public ticker endpoint, one symbol, through a rotating US residential IPr = requests.get( "https://api.exchange.example/v1/ticker?symbol=BTC-USD", proxies=proxies, timeout=10,)r.raise_for_status()print(r.json())큰 심볼 목록을 이런 호출 여러 개에 분산시켜 단일 IP가 전체 부하를 지지 않도록 하고, 속도 제한이나 타임아웃 응답이 오면 그 경로를 폐기하고 새 경로로 재시도한다. WebSocket 스트림의 경우, 연결의 수명 동안 하나의 IP를 유지하기 위해 세션 식별자를 추가한다. 예를 들어 customer-USERNAME-country-us-sid-book42처럼 하고, 각 스트림에 고유한 식별자를 부여한다. 동일한 클라이언트 패턴은 Python으로 레지덴셜 프록시 사용하기에 관한 일반 가이드에서도 그대로 이어진다.
결론
암호화폐 거래소 및 시장 데이터 수집은 세 가지에 의해 제약된다. 단일 주소가 거의 즉시 부딪히는 IP당 속도 제한, 단일 위치에서 도달할 수 없는 지역 잠금 엔드포인트와 상품, 그리고 모든 공백을 영구적인 구멍으로 만드는 24시간 시장. 레지덴셜 프록시는 이 세 가지 모두에 답한다. 폴링을 풀 전체에 분산시켜 각 IP가 자체 예산 안에 머물면서도 실질적인 처리량을 배가시키고, 국가를 타겟팅하여 허용된 지역이 보는 공개 데이터를 수집하고, 스트림과 거래소 간 스냅샷을 위해 스티키 세션을 유지하며, 모니터링과 함께 페일오버하여 피드가 조용히 멈추지 않도록 한다. 존재하는 곳이라면 공식 API를 사용하고, 공개 데이터와 각 거래소의 약관을 지키며, 프록시 계층이 잘하는 일, 즉 규모와 지리를 하게 하라.
그 계층이 바로 레지덴셜 프록시가 존재하는 이유다. 국가 및 도시 타겟팅과 필요할 때의 스티키 세션을 갖춘 실제 가정용 IP의 대규모 풀 말이다. GB당 요금제는 실제로 사용한 데이터에 대해서만 비용을 지불한다는 것을 의미하며, 이는 대부분 작고 빈번한 시장 데이터 요청이 지속적으로 실행되는 워크로드에 적합하다.