거래소 API 호출 한도 변경 공지: 봇 장애 전에 계산할 항목

API 한도 숫자만 바꾸면 충분하지 않습니다. 제한 주체가 IP·API 키·계정 중 무엇인지, 고정 또는 토큰 버킷 창, 엔드포인트별 weight, 주문 수 제한, 429와 Retry-After 규칙을 확인해야 합니다. 모든 워커의 초당 비용을 합산하고 여유분을 둔 뒤, 제한 응답에서는 재시도를 줄이며 상태가 불명확한 주문은 조회로 대사합니다.

한도의 단위부터 확정합니다

Binance Spot 문서는 exchangeInfo의 rateLimits에 RAW_REQUESTS, REQUEST_WEIGHT, ORDERS가 있고, IP 제한은 API 키가 아니라 IP 기준이라고 설명합니다. 같은 서버의 시세 수집기와 주문 봇이 서로 다른 키를 써도 IP weight를 함께 소비할 수 있습니다.

Coinbase Exchange REST 문서는 공개 엔드포인트와 비공개 엔드포인트에 서로 다른 기본 한도를 제시하고 lazy-fill token bucket으로 설명합니다. 공지에서 ‘초당 N회’만 읽지 말고 burst, 지속 비율, 제한 대상과 예외 엔드포인트를 함께 기록해야 합니다.

호출 한도는 요청 개수가 아니라 공유 주체·시간 창·가중치가 결합된 예산입니다.

JOBCOIN 해설

발표 내용, 원문 근거, 적용 범위를 차례로 확인하는 뉴스 검증 개념도 — **그림과 함께 짚어볼 본문 내용**
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.

엔드포인트 weight를 실제 호출표에 곱합니다

모든 호출이 비용 1은 아닙니다. Binance는 각 route에 weight가 있고 여러 심볼을 처리하는 무거운 엔드포인트가 더 큰 값을 가질 수 있다고 명시합니다. 초당 호출 횟수만 세면 고비용 시장 전체 조회가 예산을 빠르게 소진합니다.

각 작업에 호출 빈도×weight를 계산합니다. 예를 들어 가정상 1초마다 weight 5 조회 3개와 weight 1 조회 10개면 초당 비용은 25입니다. 이 계산은 개념 예시이며 실제 weight와 창은 현재 exchangeInfo와 엔드포인트 문서를 사용합니다.

호출 예산표의 구성
항목	계산	운영 판단
시세 폴링	빈도×weight	공유 캐시 가능성
주문	주문 수·weight	계정별 별도 제한
재연결	초기 스냅샷 비용	동시 재시작 억제
재시도	실패율×최대 횟수	폭주 상한 설정

시간 창과 burst를 구분합니다

분당 1,200이라는 숫자가 매초 20개를 보장한다는 뜻은 아닙니다. 고정 창이면 경계에 요청이 몰릴 수 있고 토큰 버킷이면 저장된 토큰만큼 순간 burst가 허용될 수 있습니다. Coinbase 문서의 burst=15, rate=10/s 사례는 토큰이 채워지는 속도와 최대 저장량을 함께 봐야 함을 보여 줍니다.

클라이언트는 서버 응답 헤더나 교환 정보의 현재 한도를 기준으로 예산을 갱신합니다. 공지 적용 시각 전에 설정을 배포하되 구·신 한도 전환 구간에는 더 낮은 값을 사용합니다. 서버 시간과 로컬 시간 차이로 창 경계를 예측해 한도까지 꽉 채우는 방식은 피합니다.

429는 속도를 낮추라는 상태입니다

Binance는 한도 초과에 HTTP 429를 사용하고, 계속 요청하면 HTTP 418 자동 IP 차단으로 이어질 수 있으며 Retry-After가 대기 시간을 준다고 설명합니다. 429를 일반 네트워크 오류처럼 즉시 재시도하면 정상 복구보다 차단 시간을 늘릴 수 있습니다.

재시도 큐는 Retry-After를 우선하고 지수 백오프와 무작위 지터를 더합니다. 여러 워커가 동시에 깨어나는 것을 막고 큐의 최대 길이와 요청 만료 시각을 둡니다. 시세 조회는 오래된 요청을 버릴 수 있지만 주문 요청은 실행 상태를 확인하지 않은 채 복제하면 안 됩니다.

주문 요청은 멱등성과 상태 대사가 필요합니다

Binance는 처리 시간 초과나 5XX에서 실행 상태가 unknown일 수 있다고 안내합니다. 응답을 못 받았다는 이유로 동일 주문을 다시 보내기 전에 사용자 지정 주문 ID와 주문 조회, 사용자 데이터 스트림에서 결과를 확인합니다.

읽기 호출 한도와 주문 접수 한도는 다를 수 있으므로 주문 경로에 별도 차단기를 둡니다. 상태 조회조차 한도에 막힐 때는 신규 주문을 멈추고 복구용 예산을 남깁니다. 위험한 재시도보다 미확정 상태를 보존하는 것이 중복 체결을 막습니다.

IP·키·계정 중 제한 주체를 표시합니다.
모든 엔드포인트의 weight와 주기를 합산합니다.
정상 트래픽에 복구용 여유 예산을 남깁니다.
429·Retry-After·418 처리 규칙을 테스트합니다.
미확정 주문은 재전송 전 거래소 상태를 조회합니다.

변경 전 부하 시험은 테스트 환경에서 합니다

운영 API를 한도까지 밀어붙여 시험하지 않습니다. 기록된 호출 로그를 재생하거나 테스트넷·모의 제한기로 새로운 예산을 검증합니다. 정상 부하, 모든 워커 동시 재시작, WebSocket 재연결, 429 연속 응답을 각각 시험합니다.

관측 지표에는 요청 수뿐 아니라 weight 사용량, 429·418 수, Retry-After, 큐 지연, 폐기된 시세 요청과 미확정 주문 수를 포함합니다. 변경 뒤 오류가 없더라도 지연이 늘어 주문이 만료될 수 있으므로 성공률과 지연 분포를 함께 봅니다.

자주 묻는 질문

API 키를 여러 개 만들면 IP 한도가 늘어나나요?

IP 기준 제한이라면 늘어나지 않습니다. 공식 문서에서 제한 주체를 확인해야 합니다.

429가 오면 같은 요청을 바로 다시 보내도 되나요?

아닙니다. Retry-After와 백오프를 적용하고 주문이면 먼저 실행 상태를 확인해야 합니다.

WebSocket을 쓰면 REST 한도는 신경 쓰지 않아도 되나요?

초기 스냅샷, 주문, 계정 조회와 재연결 복구에 REST가 필요할 수 있어 별도 예산이 필요합니다.

더 깊이 읽기

본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.

궁금한 주제를 찾아보세요