바이낸스 API 속도 제한(Rate Limit) 해결 가이드: Weight의 의미와 대처법
API 속도 제한으로 인해 요청이 거부되는 문제를 해결하세요. Weight와 Order라는 두 가지 제한 시스템과 효율적인 대처 방법을 설명합니다.
API 속도 제한(Rate Limit)은 퀀트 트레이딩 전략 구현 시 가장 자주 마주치는 난관입니다. 먼저 바이낸스 공식 사이트에서 API 키를 생성하고, 실시간 모니터링을 위해 바이낸스 공식 앱을 활용하세요(iOS 설치는 iOS 가이드 참고).
두 가지 속도 제한 시스템
바이낸스 API는 서로 독립된 두 가지 차원의 제한을 두고 있습니다.
1. Weight (가중치)
각 API 인터페이스에는 고유의 가중치(Weight)가 할당되어 있습니다. 1분당 총 가중치 합계가 제한을 넘지 않아야 합니다.
| 등급 | 분당 가중치(Weight) 한도 |
|---|---|
| 일반 사용자 | 1,200 |
| VIP 1 | 2,400 |
| VIP 2 | 3,600 |
| ... | 등급에 따라 상승 |
2. Order (주문 수)
주문 관련 API에만 적용되는 추가 제한입니다.
| 시간 범위 | 최대 주문 수 |
|---|---|
| 10초 | 100회 |
| 1일 | 200,000회 |
둘 중 하나라도 초과하면 일시적으로 API 사용이 금지됩니다.
주요 인터페이스별 가중치(Weight)
자주 사용되는 인터페이스의 가중치는 다음과 같습니다.
| 인터페이스 | 가중치(Weight) |
|---|---|
| 현재 시세 스냅샷 | 1 |
| 오더북(호가창) 5단계 | 1 |
| 오더북 100단계 | 5 |
| 오더북 1,000단계 | 50 |
| K-라인(캔들) | 1 |
| 주문 생성 | 1 |
| 주문 취소 | 1 |
| 계정 정보 조회 | 10 |
깊은 단계의 오더북(1,000단계)을 한 번 조회하면 50의 가중치가 소모되므로, 분당 최대 24회까지만 조회가 가능합니다.
응답 헤더(Response Header) 확인
모든 API 응답의 헤더에는 현재 사용량을 알 수 있는 정보가 포함되어 있습니다.
X-MBX-USED-WEIGHT-1M: 현재 분(Minute)의 누적 사용 가중치X-MBX-ORDER-COUNT-10S: 최근 10초간의 누적 주문 수
이 값을 모니터링하여 임계치에 도달하기 전 속도를 조절해야 합니다.
제한 초과 시 발생하는 문제
- 429 에러: 일시적인 차단입니다. 몇 초에서 몇 분간 대기해야 합니다.
- 418 에러: 차단 후에도 계속 요청을 보낼 경우 발생하며, IP 자체가 영구 차단될 위험이 있습니다.
418 에러가 발생하면 해제까지 24시간 또는 그 이상이 걸릴 수 있습니다. 강제로 계속 요청을 보내지 마세요.
우아한 퇴避(Backoff) 로직 구현
import time
while True:
try:
result = api_call()
weight_used = int(headers.get('X-MBX-USED-WEIGHT-1M', 0))
if weight_used > 1000:
time.sleep(10) # 임계치 근접 시 자발적 감속
return result
except RateLimitError:
time.sleep(60) # 차단 발생 시 1분 대기
가중치(Weight)를 절약하는 기술
1. 오더북 단계 축소
5단계 호가 정보로 충분하다면 1,000단계를 조회하지 마세요. 가중치 차이가 50배입니다.
2. 웹소켓(WebSocket) 활용
시세, 오더북, K-라인 정보는 웹소켓 실시간 푸시를 통해 받으세요. 웹소켓은 가중치를 소모하지 않습니다.
3. 배치(Batch) 주문 활용
/api/v3/batchOrders를 사용하면 한 번에 5개의 주문을 넣을 수 있어 개별 주문보다 가중치 면에서 유리합니다.
4. 캐싱(Caching)
매 초마다 확인할 필요가 없는 정적 데이터는 로컬에 수 초간 캐싱하세요.
웹소켓의 이점 비교
| 데이터 종류 | REST API 가중치 | 웹소켓(WS) |
|---|---|---|
| 시세 정보 | 요청당 1 | 실시간 푸시, 가중치 0 |
| 오더북 정보 | 1 ~ 50 | 실시간 푸시 |
| K-라인 정보 | 1 | 실시간 푸시 |
효율적인 전략 프레임워크는 실시간 데이터는 웹소켓으로(가중치 0), 주문 및 취소만 REST API로 처리하는 구조입니다.
다중 계정 분산 전략
여러 개의 하위 계정(API Key)을 사용하면 가중치 제한을 계정별로 분산할 수 있습니다.
- 메인 계정 키: 주문 실행 전용
- 하위 계정 키: 시세 조회 및 분석 전용
- 가중치 풀이 배수로 늘어나는 효과
VIP 등급과 가중치 상향
VIP 등급이 올라갈수록 다음과 같은 혜택이 주어집니다.
- 분당 가중치 한도 대폭 상향
- 특정 인터페이스에 대한 특별 한도 적용
- 수수료 절감보다 가중치 상향이 더 큰 메리트가 될 수 있음
VIP 1만 달성해도 가중치 한도가 2배로 늘어나므로 적극 고려해 볼 만합니다.
모니터링 코드 예시
class RateMonitor:
def __init__(self):
self.last_weight = 0
self.alert_threshold = 1000
def update(self, headers):
used = int(headers.get('X-MBX-USED-WEIGHT-1M', 0))
if used > self.alert_threshold:
print(f"경고: 현재 가중치 사용량 {used} / 1200")
self.last_weight = used
자주 하는 실수
1. 루프 내 모든 요청을 REST API로 처리
주문과 동시에 매초 잔액 조회, K-라인 조회를 REST로 반복하면 순식간에 가중치가 소모됩니다. 웹소켓으로 전환하세요.
2. 예외 처리 미흡
429 에러 발생 시 즉시 대기(sleep)하지 않고 계속 요청을 보내 418 IP 차단을 자초하는 경우입니다.
3. 동일 IP에서 여러 키 사용
API 키가 다르더라도 동일 IP에서 오는 요청은 합산하여 제한될 수 있습니다.
4. 응답 헤더 무시
가중치 사용량을 확인하지 않고 무작정 요청을 보내는 방식입니다.
실전 운영 전 테스트
- 테스트넷(Testnet)에서 고빈도 테스트를 수행하여 429 에러 발생 여부를 확인합니다.
- 실전 운영 시에는 알림 시스템을 구축하여 가중치가 80%를 넘어서면 자동으로 속도를 늦추거나 경고를 보내도록 설정하세요.
자주 묻는 질문(FAQ)
Q: 429 차단은 얼마나 지속되나요? A: 보통 수 초에서 수 분입니다. 이 기간에는 절대 추가 요청을 보내지 마세요.
Q: 418 IP 차단은 어떻게 해제하나요? A: 최소 1시간에서 24시간, 심할 경우 7일까지 지속됩니다. 기다리는 것 외에 뾰족한 방법이 없습니다.
Q: 가중치는 모든 종목이 공유하나요? A: 네, 계정당 모든 거래쌍(Symbol) 요청의 가중치 합계로 계산됩니다.
Q: 주문 수 제한은 IP를 바꾸면 해결되나요? A: 아니요, 주문 수 제한은 계정 단위입니다. IP를 바꿔도 소용없습니다.
관련 가이드
속도 제한은 제약이 아니라 내 계정을 보호하는 안전장치입니다. 가중치를 현명하게 관리하면 차단 걱정 없는 안정적인 자동 매매 시스템을 구축할 수 있습니다.