폴리마켓 봇 튜토리얼 · 32장 중 5장

2026년 폴리마켓 봇을 위한 Polygon RPC 제공업체 비교: Alchemy, QuickNode, Ankr, 퍼블릭 endpoint, 자체 호스팅. 지연 시간, 요청 한도, 그리고 모의 거래에 사용할 수 있는 무료 요금제까지 다룹니다.

Polymarkets.co.il의 수석 작가 할리 영 작성. 최종 검토: 2026년 5월.

이 장에서 다루는 내용

Polygon RPC endpoint는 봇이 온체인 상태를 직접 확인할 수 있는 유일한 창구입니다. 잔액, 사용 허가(allowance), 정산 확인, UMA 이벤트까지 모두 여기서 읽습니다. 폴리마켓의 자체 API는 이 중 대부분을 감추지만, 실전 봇은 자체 장부를 검증하기 위해 온체인의 실제 값을 읽어야 합니다. 이 장에서는 주요 RPC 제공업체를 실제 부하 환경에서 비교하고, 각 업체가 무료 요금제에서 언제 한계에 도달하는지 보여주며, 마지막에는 대부분의 봇이 결국 채택하는 이중 제공업체 페일오버 방식을 소개합니다.

  • RPC가 봇에서 하는 역할
  • Alchemy: 무료 요금제와 가격
  • QuickNode: 전용 노드
  • Ankr: 가장 저렴한 유료 요금제
  • 퍼블릭 Polygon RPC(무료, 요청 제한 있음)
  • 자체 호스팅 Polygon 노드(언제 의미가 있는가)
  • 지연 시간 벤치마크(US-East vs EU)
  • 페일오버 방식

RPC가 봇에서 하는 역할

RPC endpoint는 봇이 Polygon 체인 상태를 읽고 쓰는 HTTPS 또는 WebSocket URL입니다. 폴리마켓 봇에서 RPC는 네 가지 일을 처리합니다.

  • 잔액 읽기: 프록시에 pUSD 또는 USDC가 얼마나 있는지, 실제로 어떤 outcome token을 보유하고 있는지 확인합니다. CLOB API가 보여주는 값이 체인의 실제 값과 일치하는지 검증하는 데 필요합니다.
  • 사용 허가 읽기: 폴리마켓 컨트랙트가 사용자의 token을 사용할 수 있는지 확인합니다. 사용 허가(allowance) 설정이 잘못되면 주문이 조용히 거절될 수 있습니다.
  • 이벤트 구독: UMA Optimistic Oracle의 제안과 이의 제기, 입금 확인, 다른 지갑에서 발생한 대규모 온체인 전송을 감지합니다.
  • 정산 검증: CLOB가 "matched"라고 표시해도 체인에서는 아직 ERC-1155 전송이 확정되지 않았을 수 있습니다. 체인을 읽으면 실제로 완료되었는지 확인할 수 있습니다.

봇이 주문을 RPC를 통해 서명하는 것은 아닙니다. 주문 서명은 로컬에서 수행되고, 서명된 payload는 CLOB HTTP API로 전송됩니다. RPC는 대부분의 전략에서 순수하게 읽기와 이벤트를 위한 채널입니다.

Alchemy: 무료 요금제와 가격

Alchemy는 우리가 아는 폴리마켓 개발자들 사이에서 가장 많이 사용되는 Polygon RPC 제공업체입니다. 무료 요금제는 대부분의 모의 거래와 소규모 봇 사용 사례를 감당합니다. 초당 300 compute units, 월 3억 compute units를 제공하며, Polygon mainnet과 Polygon testnet endpoint를 준비하는 데 쓰는 대시보드가 동일합니다.

일반적인 20개 시장 봇이 30초마다 잔액과 UMA 이벤트를 읽는 경우 월 약 5천만~8천만 CU를 사용하므로, 무료 한도 안에서 충분히 운영할 수 있습니다. 유료 요금제는 대체로 월 50달러부터 시작하며, 총 호출 수보다 더 높은 초당 처리량을 구매하는 형태입니다. 대부분의 모의 거래 봇이 부딪히는 제약은 월 사용량이 아니라 무료 요금제의 요청 한도입니다.

Alchemy는 실패한 요청을 확인할 수 있는 유용한 대시보드와 메서드별 지연 시간 분석을 제공합니다. 느린 읽기를 디버깅할 때 특히 도움이 됩니다. 첫 봇을 만들 때는 이 대시보드만으로도 대시보드가 없는 제공업체보다 선택할 이유가 충분합니다.

QuickNode: 전용 노드

QuickNode는 더 높은 처리량 요구를 겨냥합니다. 가격은 요금 단계보다 월 요청량에 따라 확장되며, 많은 WebSocket 이벤트 필터를 구독하거나 무거운 과거 로그 조회를 수행하는 봇에 특히 적합합니다. 최하위 요금제는 대략 월 10~20달러이며, 일부 Alchemy 무료 요금제에서는 제한되는 WebSocket 지원이 포함됩니다.

US-East 기준 QuickNode의 요청당 지연 시간은 보통 5~15ms로, 부하가 걸린 Alchemy 무료 요금제보다 약간 더 좋습니다. 단일 전략 봇에서는 체감하기 어렵지만, 100개 시장에 호가를 내는 마켓 메이커라면 의미가 있을 수 있습니다. 아카이브 노드 접근(전체 과거 상태)은 필요할 경우 세 주요 제공업체 중 가장 저렴합니다.

단점은 JSON-RPC 오류 응답이 Alchemy보다 덜 구체적이라는 점입니다. 메서드가 실패했을 때 디버깅에 더 오래 걸립니다.

Ankr: 가장 저렴한 유료 요금제

Ankr는 주요 제공업체 중 가장 저렴한 Polygon RPC를 제공합니다. 최하위 프리미엄 요금제는 대략 월 10달러이며 초당 1,500 CU를 제공합니다. 무료 요금제는 요청 한도가 빡빡하지만 모의 거래에는 충분히 사용할 수 있습니다.

주의할 점이 두 가지 있습니다. 첫째, Ankr의 부하 분산 endpoint는 가끔 약간 오래된 블록 데이터를 반환합니다(최신 블록보다 1~2개 뒤). 잔액 읽기에는 문제없지만, 최신 블록에 의존하는 차익거래 전략에는 중대한 문제가 될 수 있습니다. 둘째, 특정 지역의 노드에 문제가 생겼을 때 지원 응답 시간이 Alchemy나 QuickNode보다 느립니다.

Ankr는 비용에 민감한 봇의 기본 제공업체로 합리적이며, 기본 제공업체가 무엇이든 백업 제공업체로는 매우 훌륭합니다. 아래의 페일오버 방식 섹션에서 함께 사용하는 방법을 다룹니다.

퍼블릭 Polygon RPC(무료, 요청 제한 있음)

Polygon은 몇 가지 무료 퍼블릭 RPC endpoint를 제공합니다. polygon-rpc.com, rpc.ankr.com/polygon(퍼블릭용이며 유료 Ankr와 별개), 그리고 몇몇 커뮤니티가 호스팅하는 endpoint입니다. 동작은 하지만 유의할 점이 있습니다.

  • 요청 한도가 공격적이고 문서화되어 있지 않습니다. 초당 약 10건을 지속적으로 넘기면 제한될 가능성이 큽니다.
  • 지원도 없고 대시보드도 없습니다. endpoint가 실패하면 봇의 오류율이 올라가는 것으로만 알 수 있습니다.
  • 대개 1~3개 블록 뒤처집니다. 시간에 덜 민감한 읽기에는 괜찮습니다.

퍼블릭 endpoint는 노트북에서의 개발, 유료 제공업체 두 곳 뒤에 두는 페일오버 구성의 세 번째 단계, 일회성 스크립트에 사용하세요. 실전 봇 거래의 기본 endpoint로 퍼블릭 endpoint를 사용하지 마세요.

자체 호스팅 Polygon 노드(언제 의미가 있는가)

자체 Polygon 풀 노드를 운영하는 것은 가능합니다. 4-vCPU/16GB VPS에 Bor + Heimdall을 올리고 약 2TB SSD를 사용해 며칠 안에 동기화할 수 있습니다. 직접 운영할지 여부를 가르는 계산은 단순합니다.

비용: 주요 호스팅 업체 기준으로 VPS와 스토리지에 대략 월 40~80달러 정도가 듭니다. 여유 있는 유료 RPC 요금제의 약 4배입니다.

이점: 요청당 요금이 없고, 요청 한도도 없으며, 체인 상태에 도달하는 지연 시간이 가장 낮습니다(호스팅 업체까지 인터넷으로 20~50ms가 걸리는 대신 1~3ms).

부담: 스냅샷 관리가 필요하고, Heimdall과 Bor는 각각 나름의 충돌 상황이 있으며, 거래 중간에 동기화가 멈추면 조용히 오래된 값을 읽게 됩니다.

대부분의 개발자에게는 자체 호스팅을 권하지 않습니다. 노드 유지보수에 들어가는 시간이 RPC 요금 절감보다 훨씬 큽니다. 읽기 지연 30ms가 PnL에 실제로 영향을 주는 전략이 있고, 이미 호스팅 제공업체에서 그 전략이 검증된 경우에만 자체 호스팅하세요.

지연 시간 벤치마크(US-East vs EU)

2026년 5월, 세 지역의 VPS에서 각 제공업체의 가장 가까운 Polygon RPC로 측정한 왕복 시간 중앙값입니다.

VPS 지역AlchemyQuickNodeAnkr(유료)polygon-rpc.com
NY (US-East)14ms11ms22ms34ms
AMS (EU)21ms17ms28ms41ms
SG (Asia)97ms89ms110ms140ms

수치는 주 단위로 약 3ms 정도 변동합니다. 패턴은 안정적입니다. QuickNode와 Alchemy는 사실상 비슷하고, Ankr는 일관되게 5~10ms 뒤처지며, 퍼블릭 endpoint는 15~25ms 더 느립니다. 아시아에 호스팅된 봇은 Polygon의 북미 중심 백본 때문에 약 80ms의 피할 수 없는 비용을 치르게 됩니다.

페일오버 방식

RPC 하나만 쓰면 단일 장애 지점이 됩니다. 실전 봇은 간단한 전환 규칙으로 두 제공업체를 사용합니다.

방식은 이렇습니다. 제공업체 A로 먼저 호출하고, 타임아웃(3초) 또는 5xx 응답이 오면 제공업체 B로 재시도합니다. 둘 다 실패하면 5초 대기 후 기본 제공업체를 다시 시도합니다. 기본 제공업체의 연속 실패 횟수를 추적하고, 3번 실패하면 60초 동안 B에 자동으로 고정한 뒤 다시 기본 제공업체를 확인합니다.

권장 조합은 Alchemy 유료를 기본으로 사용하고, Ankr 무료 또는 퍼블릭 Polygon endpoint를 백업으로 사용하는 것입니다. 서로 다른 상위 노드 운영자를 사용하므로 한쪽의 일시적 문제가 다른 쪽과 연관될 가능성이 낮습니다. 같은 제공업체의 두 endpoint를 쓰는 것(예: Alchemy key 두 개)은 피하세요. 진짜 이중화가 되지 않습니다.

구현은 web3.py 또는 ethers.js 위에 얇은 wrapper를 두고, 호출마다 제공업체를 선택하는 방식입니다. 약 30줄 정도의 코드로, 제공업체에 지역 장애가 한 번만 발생해도 충분히 값어치를 합니다.

자주 묻는 질문

폴리마켓 봇에 유료 Polygon RPC가 필요한가요?
모의 거래나 트래픽이 적은 봇에는 필요하지 않습니다. 퍼블릭 Polygon RPC(polygon-rpc.com)는 평균적으로 초당 요청이 약 1건 이하라면 잘 작동합니다. 여러 시장으로 확장하거나 WebSocket 구독이 필요해지면 Alchemy, QuickNode, Ankr로 옮기세요. 무료 요금제만으로도 대부분의 개인 봇을 충분히 감당할 수 있습니다.
SDK를 사용하면 폴리마켓에 Polygon RPC가 필요 없나요?
CLOB SDK는 폴리마켓 REST/WebSocket API를 호출하며, 이들은 Polygon RPC가 필요 없습니다. Polygon RPC가 필요한 경우는 온체인 읽기입니다(USDC/pUSD 잔액, 컨트랙트 이벤트, UMA 오라클 읽기, 사용자 지정 EIP-712 서명 흐름). 많은 봇은 Polygon과 직접 통신할 일이 없습니다.
가장 저렴하면서도 안정적인 Polygon RPC는 무엇인가요?
2026년 기준 Ankr Premium은 넉넉한 할당량까지 요청당 요금 없이 월 약 10달러부터 시작합니다. Alchemy의 무료 요금제도 대부분의 개인 봇에는 충분합니다(월 3억 compute units). QuickNode는 더 비싸지만, 예측 가능한 성능이 필요하다면 전용 노드 옵션이 있습니다.
Polygon 노드를 직접 호스팅할 수 있나요?
가능하지만, 고빈도 봇을 돌리거나 대규모 온체인 분석을 하지 않는다면 과합니다. Polygon 풀 노드에는 약 1TB SSD와 몇 주에 걸친 동기화 시간이 필요합니다. 디스크와 유지보수 비용은 보통 개인 규모의 봇에서는 유료 RPC 요금제보다 더 큽니다.
어떤 WebSocket에 구독해야 하나요?
폴리마켓 호가창 데이터는 폴리마켓 자체 WebSocket인 wss://ws-subscriptions-clob.polymarket.com/ws/market에 구독하세요. Polygon 블록 이벤트는 대부분의 봇에는 드문 경우이지만, 필요하다면 RPC 제공업체의 WS endpoint(예: wss://polygon-mainnet.g.alchemy.com/v2/YOUR_KEY)에 구독하세요.
요청 한도에 걸리지 않으려면 어떻게 해야 하나요?
적극적으로 캐시하고(호가창 스냅샷, gamma 메타데이터), 실시간 데이터는 폴링 대신 WebSocket을 사용하고, 가능하면 읽기 호출을 batch로 묶고, 429 응답에는 backoff를 추가하세요. 우리가 관찰한 요청 한도 초과의 대부분은 실제 수요 때문이 아니라 엉성하게 작성된 루프 때문이었습니다.