바이낸스 Request Weight 뜻 2026｜API 호출 비용·IP 제한·429 관리

바이낸스 Request Weight 뜻 2026｜API 호출 비용·IP 제한·429 관리

바이낸스 Request Weight는 API 요청이 사용하는 호출 예산의 가중치입니다. 주문 금액이나 거래 수수료가 아니며, 요청 한 번을 항상 같은 비용으로 세는 방식도 아닙니다. 같은 횟수로 요청해도 어떤 정보를 얼마나 넓게 조회했는지에 따라 사용량이 달라질 수 있습니다.

자동 주문 프로그램을 운영할 때는 가격을 읽는 작업, 주문 결과를 확인하는 작업, 거래 규칙을 새로 받는 작업이 함께 움직입니다. 이때 각각의 프로그램이 자신이 보낸 요청만 세면 전체 사용량을 놓치기 쉽습니다. 특히 같은 외부 IP를 공유하는 여러 프로그램은 서로의 요청 때문에 영향을 받을 수 있습니다.

이 글은 Binance Spot REST API를 기준으로 Request Weight, RAW_REQUESTS, ORDERS의 차이와 응답 헤더 읽는 순서를 설명합니다. 선물·마진·지갑 API의 제한을 이 글의 숫자로 대체하지 않습니다. 2026년 10월 27일 공식 개발 문서를 확인했으며, 예시의 가상 한도와 실제 서비스 한도는 구별합니다.

먼저 알아둘 핵심

가장 중요한 질문은 “나는 몇 번 호출했나?”보다 “같은 IP에서 어떤 요청들이 어느 구간에 얼마나 누적됐나?”입니다. API 키를 바꾸는 것으로 IP 기반 예산이 새로 생긴다고 생각하면 원인을 잘못 진단하게 됩니다.

1. Request Weight가 필요한 이유

요청 하나가 처리하는 일이 같지 않다

한 거래쌍의 간단한 값을 가져오는 요청과 여러 거래쌍의 정보를 한꺼번에 가져오는 요청은 반환 범위가 다릅니다. 호가를 조회하더라도 요청한 깊이에 따라 처리량이 달라질 수 있습니다. 공식 문서는 각 경로에 가중치를 지정하고, 무거운 작업이나 여러 심볼을 다루는 작업은 더 높은 가중치를 가질 수 있다고 설명합니다.

가중치는 투자 금액의 크기를 측정하는 단위가 아닙니다. 큰 금액의 주문을 넣었다고 요청 가중치가 반드시 비례해서 커지는 것도 아니고, 조회만 하는 프로그램이라고 가중치가 발생하지 않는 것도 아닙니다. 따라서 매매 전략의 예산과 API 통신 예산을 서로 다른 표로 관리해야 합니다.

이 구별은 작은 봇에서도 중요합니다. 한 계정으로 실제 주문을 하루 몇 번만 내더라도, 화면을 갱신하려고 매초 다수의 종목을 조회하면 통신 부하는 커질 수 있습니다. “거래를 많이 하지 않았는데 왜 제한이 걸렸지?”라는 상황에서 먼저 확인할 것은 조회 작업의 반복입니다.

가중치는 돈으로 빠져나가는 수수료가 아니다

Request Weight라는 표현의 Weight를 수수료 또는 거래량 등급으로 오해하면 안 됩니다. 주문 체결에 따른 수수료는 거래 수수료 규칙과 관련되고, Request Weight는 API 사용 제한의 계산에 사용됩니다. 가중치를 절약했다고 체결 수수료가 그만큼 줄어드는 구조는 아닙니다.

반대로 수수료 등급이나 보유 자산이 바뀌었다는 이유만으로 모든 API 호출 예산이 자동으로 바뀐다고 가정하지 않습니다. 실제 적용 한도는 해당 서비스의 공식 문서와 현재 반환되는 정보로 확인해야 합니다. 이 글은 특정 계정에 추가 한도가 있다고 전제하지 않습니다.

2. 공식 문서에서 확인할 위치

확인 출발점은 Binance Spot REST API 공식 문서의 Limits, IP Limits, 해당 엔드포인트의 Weight 항목입니다. 제한 종류의 이름은 ENUM 문서에서도 확인할 수 있습니다.

문서를 읽을 때는 엔드포인트 이름만 보지 말고 메서드·경로·파라미터 조건·가중치 표를 함께 봅니다. 같은 조회 계열이라도 단일 symbol, 여러 symbols, 파라미터 생략 시의 비용이 다를 수 있기 때문입니다. 문서 예시의 응답 한 개만 복사해 고정 설정으로 사용하면 변경을 놓치기 쉽습니다.

GET /api/v3/exchangeInfo의 rateLimits 배열은 현재 거래소 제한 종류와 구간을 파악하는 기준 자료입니다. 이 배열의 rateLimitType, interval, intervalNum, limit을 하나의 묶음으로 읽어야 합니다. limit 숫자만 따로 저장하면 그 수치가 몇 초 또는 몇 분에 적용되는지 알 수 없습니다.

예를 들어 interval이 MINUTE이고 intervalNum이 1이면 1분 구간의 제한을 설명하는 항목입니다. SECOND와 MINUTE를 같은 시간 단위로 계산하면 프로그램의 여유 예산 추정이 크게 틀어질 수 있습니다. 여러 항목이 있다면 가장 느슨한 하나만 선택하지 말고 관련 제한을 함께 고려합니다.

예시 응답과 실시간 적용값 구분

공식 문서에 제시된 JSON은 필드 구조를 이해하기 위한 예시 역할도 합니다. 그 안의 숫자를 모든 날짜·모든 서비스에 영구 적용되는 계약처럼 읽어서는 안 됩니다. 문서에 있는 값과 현재 API 응답이 다르면 서비스를 구분한 뒤 현재 규칙을 재확인해야 합니다.

운영 기록에는 “한도 6,000”처럼 숫자만 적기보다 확인한 날짜, 서비스 이름, 제한 종류, 구간을 함께 남기는 편이 낫습니다. 이 글에서는 특정 한도를 모든 독자에게 고정 적용한다고 안내하지 않습니다. 실제 배포 전에는 사용하는 API의 최신 정보로 설정을 갱신하세요.

3. 응답 헤더를 읽는 방법

Spot REST 문서는 X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) 형식의 응답 헤더를 안내합니다. intervalLetter는 S, M, H, D처럼 시간 단위를 나타냅니다. 이름 끝에 있는 숫자와 글자는 단순 장식이 아니라 사용량이 어떤 구간에 속하는지 설명하는 정보입니다.

헤더의 값은 해당 IP에서 사용한 가중치를 파악하는 데 쓰입니다. 프로그램 한 개의 자체 카운터와 값이 다를 수 있다는 점이 중요합니다. 같은 네트워크에서 다른 봇이나 대시보드가 요청하고 있다면, 자신의 로컬 기록보다 서버가 알려준 사용량이 더 높게 보일 수 있습니다.

HTTP 응답 본문만 저장하는 구현은 이 정보를 놓치기 쉽습니다. JSON 파싱에 성공했더라도 헤더를 버리면 제한에 가까워지는 추세를 볼 수 없습니다. 상태 코드, 관련 헤더, 호출한 경로, 호출 시각을 함께 기록하면 문제가 발생했을 때 원인을 더 빨리 구분할 수 있습니다.

헤더 이름의 대소문자를 처리하는 방식은 사용하는 HTTP 라이브러리의 동작을 확인합니다. 화면에 보이는 표기와 내부 저장 키가 다르다는 이유만으로 값이 없다고 단정하지 마세요. 다만 헤더가 없을 때 가상의 사용량을 서버가 확정한 값처럼 만들어 기록해서도 안 됩니다.

로컬 예상치와 서버 관측치는 용도가 다르다

로컬 예상치는 요청을 보내기 전에 예산을 계획하는 데 유용합니다. 서버 헤더는 실제 응답 시점의 관측값입니다. 요청들이 동시에 진행 중이면 아직 응답이 오지 않은 요청이 존재하므로, 마지막으로 본 헤더 값만으로 앞으로 모든 요청을 승인해서는 안 됩니다.

운영 설계에서는 대기 중인 요청까지 고려한 예약 예산을 둘 수 있습니다. 이는 Binance가 제공하는 별도 기능이라는 뜻이 아니라 클라이언트가 과도한 동시 호출을 막기 위한 자체 관리 방법입니다. 내부 예상치를 공식 한도와 혼동하지 않도록 로그 이름을 분리하세요.

4. IP 기반 제한과 API 키의 관계

공식 IP Limits 설명은 API 제한이 API 키가 아니라 IP를 기준으로 적용된다고 안내합니다. 따라서 동일한 외부 IP를 사용하는 프로세스들이 각각 새 키를 발급받아도, IP 호출 예산이 프로그램마다 독립적으로 생긴다고 볼 수 없습니다.

회사 서버, 집의 공유기, 하나의 클라우드 출구를 함께 쓰는 서비스는 외부에서 같은 IP로 보일 수 있습니다. 중요한 것은 컴퓨터 수나 코드 파일 수가 아니라 요청이 어떤 외부 네트워크 경로로 나가는지입니다. 네트워크 관리자가 알고 있는 구성과 애플리케이션의 관측을 함께 확인해야 합니다.

이 문제의 해결책은 제한을 피하도록 주소를 돌리는 것이 아닙니다. 중복 조회를 합치고 호출 주기를 조절하며, 같은 IP의 사용량을 공유하는 방식으로 설계를 개선하는 것이 먼저입니다. 제한에 걸렸을 때 새 키를 만들거나 IP를 바꾸며 계속 호출하는 방법을 정상적인 복구 절차로 삼지 마세요.

공개 데이터 요청도 함께 관리

인증이 필요하지 않은 공개 시세 조회라고 해서 통신 예산에서 제외된다고 추측하지 않습니다. API 키가 없다는 사실과 요청에 비용이 없다는 사실은 서로 다릅니다. 사용 중인 공개 엔드포인트의 Weight 항목을 직접 확인해야 합니다.

읽기 전용 프로그램이 주문 프로그램보다 더 많은 예산을 사용할 수도 있습니다. 주문 엔진과 별개로 운영하는 모니터링 화면이 모든 종목을 자주 갱신한다면, 실제 매매와 무관한 조회가 한도를 채울 수 있습니다. 장애 분석에서는 주문 로그만 보지 말고 같은 IP의 데이터 수집 작업도 포함하세요.

5. Request Weight와 ORDERS의 차이

전날 다룬 Order Rate Limit은 주문 관련 카운트가 중심입니다. 오늘의 Request Weight는 요청별 통신 비용을 중심으로 봅니다. 둘은 같은 프로그램에서 동시에 관찰할 수 있지만, 감소 조건과 추적 범위를 같은 것으로 취급할 수 없습니다.

주문이 체결되어 주문 관련 카운트에 변화가 생겼다고 해서 이미 사용한 요청 가중치가 같은 방식으로 되돌아온다고 생각하면 안 됩니다. 반대로 요청 가중치가 충분하다고 신규 주문을 무제한 제출할 수 있는 것도 아닙니다. 잔고·필터·주문 제한·거래 상태 등 다른 검사도 통과해야 합니다.

429가 보였다는 사실만으로 Request Weight 초과라고 단정하지 않습니다. 공식 문서는 주문 카운트 초과에도 429가 발생할 수 있다고 설명합니다. 응답 메시지와 관련 헤더를 읽어 어느 제한을 만났는지 확인하고, 원인이 불명확한 동안 재시도량을 늘리지 않는 것이 중요합니다.

6. 호출 예산을 설계하는 실제 순서

1단계: 호출 목록을 기능별로 나누기

먼저 프로그램이 호출하는 경로를 모두 적습니다. 가격·호가·캔들 조회, 거래 규칙 확인, 주문 제출, 주문 조회, 체결 내역 확인처럼 기능별로 나누면 중복을 찾기 쉽습니다. “봇이 한 번 실행된다”는 단위보다 실제 HTTP 요청 단위로 세어야 합니다.

각 경로에 현재 문서상 가중치와 파라미터 조건을 연결합니다. 범위에 따라 가중치가 달라지는 요청은 최대값 하나로 숨기지 말고 현재 사용하는 조건을 기록하세요. 목록의 목적은 정밀한 내부 서버 계산을 복원하는 것이 아니라, 자신의 프로그램이 만드는 부하를 설명할 수 있게 하는 것입니다.

2단계: 정상 상태와 장애 상태를 따로 계산하기

정상 운영에서는 요청량이 낮아도 장애 때 재시도가 겹치면 급격히 증가할 수 있습니다. 통신 실패 시 즉시 다시 보내는 루프가 여러 곳에 있으면, 하나의 지연이 추가 요청 폭증으로 이어질 수 있습니다. 정상 주기만 계산한 예산표는 이런 순간을 설명하지 못합니다.

재연결, 서버 재시작, 데이터 복구, 미확인 주문 조회가 동시에 발생하는 상황을 별도로 그려보세요. 모든 작업을 한꺼번에 시작하지 않고 중요도가 낮은 조회를 늦출 수 있는지 검토합니다. 여기서 중요도란 전략 수익성이 아니라 상태 확인과 불필요한 조회 사이의 운영상 우선순위입니다.

3단계: 데이터의 유효 기간을 정하기

자주 바뀌는 가격 데이터와 상대적으로 덜 바뀌는 거래 규칙을 같은 간격으로 요청할 필요는 없습니다. 그렇다고 거래 규칙을 영구 캐시해도 된다는 뜻은 아닙니다. 데이터마다 언제 갱신하고 어떤 오류가 발생하면 다시 확인할지 정해야 합니다.

캐시에 마지막 갱신 시각과 출처를 기록하면 오래된 값이 현재 값처럼 쓰이는 문제를 줄일 수 있습니다. 갱신 실패 시 이전 값을 사용하는 정책도 명확히 해야 합니다. 특히 오래된 가격으로 새 주문을 결정하는 문제는 호출량 절약만으로 정당화할 수 없습니다.

4단계: 동시 실행 프로그램의 예산을 공유하기

같은 IP에서 여러 프로그램이 동작한다면 각 프로그램의 자체 제한만으로 전체 한도를 지키기 어려울 수 있습니다. 중앙에서 사용량을 집계하거나 요청을 조정하는 계층을 두는 방법을 검토합니다. 이는 구현 선택이며 Binance가 특정 구조를 요구한다는 뜻은 아닙니다.

한 프로그램이 재시작하면서 저장된 사용량을 0으로 초기화해도 서버의 구간 사용량까지 초기화되는 것은 아닙니다. 재시작 직후에는 현재 서버 관측값과 진행 중인 작업을 고려해야 합니다. 로그 파일이 새로 생겼다는 이유로 실제 호출 예산도 새로 시작됐다고 해석하지 마세요.

5단계: 한도 도달 전 동작을 정하기

예산이 빠르게 소모될 때 무엇을 줄일지 미리 정해두는 편이 낫습니다. 중요도가 낮은 전체 종목 조회를 줄이고, 필요한 범위만 요청하며, 동일 데이터를 여러 곳에서 중복 요청하지 않도록 조정할 수 있습니다. 다만 특정 조치가 언제나 더 저렴한지는 실제 가중치 표로 비교합니다.

모든 조회를 멈추면 주문 상태를 확인하지 못하는 또 다른 문제가 생길 수 있습니다. 따라서 미확인 주문을 정리하는 데 필요한 합법적인 요청 여유를 계획하는 것이 중요합니다. 이미 제한 응답을 받았다면 정해진 대기 조건을 따라야 하며, 중요한 작업이라는 이유로 제한을 무시할 수는 없습니다.

7. 서로 다른 다섯 가지 예시

아래 숫자는 계산 방법을 설명하기 위한 가정입니다. 실제 Binance 한도나 특정 엔드포인트의 현재 가중치를 뜻하지 않습니다. 운영 설정에는 공식 문서에서 확인한 값을 넣어야 합니다.

예시 1: 호출 횟수는 같지만 가중치가 다른 경우

가상의 요청 A는 가중치 2, 요청 B는 가중치 20이라고 가정해 보겠습니다. 각각 10번 호출하면 A의 예상 사용량은 20, B는 200입니다. 단순히 “둘 다 10번 호출했으니 같은 부담”이라고 보면 차이를 놓치게 됩니다.

이 예시의 핵심은 무조건 가벼운 요청만 사용하라는 것이 아닙니다. B가 한 번에 필요한 정보를 충분히 가져와 A를 수십 번 반복할 필요를 없앨 수도 있습니다. 같은 목적을 달성하는 전체 요청 묶음을 비교해야 하며, 단일 호출 비용만으로 효율을 판단하지 않습니다.

예시 2: 같은 IP의 세 프로그램

봇 A가 100, 대시보드 B가 150, 백그라운드 수집기 C가 200의 가중치를 같은 구간에 사용했다고 가정하면, 운영자는 전체 450의 영향을 고려해야 합니다. A만 바라보면 사용량이 작아 보이지만 서버 관측치는 다른 작업의 영향을 포함할 수 있습니다.

이때 A의 API 키를 재발급하는 것은 B와 C의 중복 조회를 줄이지 않습니다. 먼저 같은 출구 IP를 공유하는 작업을 목록화하고, 데이터를 공유할 수 있는지 점검합니다. 실제 운영에서는 응답 헤더와 네트워크 구성을 비교해 이 가설을 확인해야 합니다.

예시 3: 정상 호출보다 재시도가 많은 경우

프로그램이 한 번 실패할 때 세 번 재시도하고, 그 상위 모듈도 다시 전체 작업을 세 번 수행한다면 요청은 예상보다 늘어날 수 있습니다. 여러 계층의 재시도 정책이 겹치는 문제입니다. 각 함수가 선의로 복구를 시도해도 전체적으로는 부하를 키울 수 있습니다.

재시도 책임을 어느 계층이 가질지 정하고, 429나 418은 일반 네트워크 오류와 다르게 처리합니다. 요청 결과가 불명확한 주문은 새 주문을 반복하기 전에 원래 주문의 상태를 확인해야 합니다. 통신 복구와 거래 의사 재실행은 같은 행동이 아닙니다.

예시 4: 모든 종목 조회의 숨은 비용

화면에서 관심 종목은 세 개뿐인데 전체 거래쌍 데이터를 매번 가져오는 구현을 생각해 볼 수 있습니다. 반환 범위가 불필요하게 넓다면 사용 중인 엔드포인트의 단일·복수 심볼 조건을 비교할 이유가 있습니다. 필요 데이터가 무엇인지 먼저 정해야 최적화 방향이 보입니다.

단일 조회 세 번이 전체 조회 한 번보다 반드시 저렴하다고 단정해서도 안 됩니다. 실제 가중치 표, 응답 크기, 데이터 신선도, 재사용 가능성을 함께 봅니다. 목적은 요청 개수를 기계적으로 줄이는 것이 아니라 필요한 정보를 합리적인 비용으로 얻는 것입니다.

예시 5: 사용량은 낮아졌는데 주문은 여전히 거절됨

Request Weight 사용량이 낮아졌지만 주문 관련 한도나 거래 규칙 때문에 신규 주문이 거절될 수 있습니다. 이때 조회 주기만 더 늦추는 것은 근본 해결이 아닐 수 있습니다. 상태 코드뿐 아니라 에러 코드, 메시지, 계정·심볼 조건을 함께 확인해야 합니다.

반대로 주문 제한이 해소돼도 IP 호출 예산이 남아 있지 않을 수 있습니다. 서로 다른 제한을 하나의 초록색 표시로 합치지 않고, 각각의 상태를 보여주면 운영자가 잘못된 결론을 내릴 가능성을 줄일 수 있습니다. “API 정상”이라는 한 문장보다 구체적인 관측값이 유용합니다.

8. 429와 418을 만났을 때

429는 요청 제한을 초과했을 때 나타날 수 있습니다. 공식 문서는 429 이후 요청을 줄이고 기다릴 책임을 명시합니다. 응답을 받자마자 같은 호출을 빠르게 반복하면 복구를 앞당기는 대신 추가 제한으로 이어질 수 있습니다.

418은 반복적인 제한 위반이나 429 이후 충분히 물러나지 않는 경우의 IP 차단과 관련됩니다. 이 상태에서는 정상적인 대기 조건을 따르는 것이 우선입니다. 다른 주소나 키로 우회하는 절차를 자동 복구 코드에 넣지 마세요.

Spot REST의 Retry-After는 해당 응답에서 기다려야 할 초 단위 시간을 알려주는 헤더로 설명됩니다. 다른 API의 이름이 비슷한 필드가 같은 단위라고 추측하지 말고, 사용 중인 서비스의 문서를 확인하세요. 단위를 잘못 읽으면 충분히 기다렸다고 생각했는데 실제로는 거의 기다리지 않은 상황이 됩니다.

권장 진단 순서

1. 신규 반복 요청을 멈추고 응답 상태와 메시지를 저장합니다.
2. Retry-After와 사용량 관련 헤더를 확인합니다.
3. 같은 IP의 다른 작업이 계속 호출하는지 점검합니다.
4. 주문 요청의 결과가 불명확하다면 별도로 표시합니다.
5. 허용된 대기 후 필요한 확인부터 제한적으로 재개합니다.
6. 원인 분석 후 정상 호출 주기와 재시도 구조를 수정합니다.

여기서 “중단”은 과거 주문이 취소됐다는 뜻이 아닙니다. API 호출을 멈춰도 이미 접수된 주문은 별도 상태를 가질 수 있습니다. 프로그램의 네트워크 상태와 거래소의 주문 상태를 혼동하지 않도록 운영 화면에 구분해서 표시해야 합니다.

9. WebSocket으로 바꾸면 해결되는가

시세를 주기적으로 반복 조회하는 작업은 스트림 방식이 더 적합할 수 있습니다. 그러나 WebSocket이라는 이름만으로 모든 제한이 사라지는 것은 아닙니다. WebSocket API와 시장 데이터 Streams는 역할과 제한 문서가 다르므로, 어느 것을 사용하는지 먼저 구분해야 합니다.

스트림을 사용해도 연결 유지, 재연결, 메시지 처리, 데이터 누락 검증을 설계해야 합니다. 연결이 끊어졌는데 마지막 가격을 계속 현재 값으로 표시하면 요청량은 적어도 데이터 품질은 나빠집니다. 갱신 시각과 연결 상태를 보여주는 설계가 필요합니다.

또한 스트림 데이터만으로 모든 계정 상태를 영구적으로 복원할 수 있다고 가정하지 않습니다. 필요한 시점에 공식 조회 수단으로 상태를 대조하는 절차를 마련해야 합니다. 조회와 스트림은 경쟁 관계라기보다 서로 다른 역할을 맡는 도구로 보는 편이 정확합니다.

10. 로그를 남길 때 포함할 정보

문제 해결에 필요한 기록은 호출 시각, 서비스·경로, 파라미터 범위, 응답 상태, 가중치 헤더, 재시도 횟수, 대기 이유입니다. 주문 관련 요청이라면 내부 작업 식별자와 실제 주문 식별자의 연결도 별도로 관리할 수 있습니다.

API Secret, 전체 서명 문자열, 인증 헤더를 일반 로그에 남기는 것은 피합니다. 진단에 필요한 정보와 인증 비밀은 다릅니다. 팀에 로그를 공유하거나 외부 문의에 첨부할 때는 비밀값을 제거하고 오류 재현에 필요한 최소 정보만 사용하세요.

사용량 그래프가 있다면 단순 합계뿐 아니라 어떤 기능이 늘었는지 분해하면 유용합니다. 최근 배포 이후 전체 종목 조회가 추가됐는지, 네트워크 장애 이후 재시도가 증가했는지, 같은 IP의 새 서비스가 생겼는지 확인할 수 있습니다. 그래프의 급증을 곧바로 거래소 오류로 판단하지 않습니다.

11. 자주 하는 실수와 수정 방향

한 가지 변경으로 모든 오류가 해결된다고 기대하지 않는 편이 좋습니다. 조회 주기를 바꾼 뒤에는 실제 사용량 추세와 데이터 신선도를 함께 관찰해야 합니다. 비용 절감 때문에 주문 상태 확인이 지나치게 늦어지면 다른 운영 문제가 생길 수 있습니다.

운영 점검표를 실제로 사용하는 방법

하루의 호출량을 평균으로만 보면 짧은 시간에 몰리는 요청을 놓칠 수 있습니다. 정기 작업이 정각에 동시에 시작되는지, 서버 시작 직후 모든 캐시를 한꺼번에 갱신하는지 확인해 보세요. 평균 호출량이 낮아도 특정 제한 구간에 요청이 집중되면 문제가 생길 수 있습니다.

배포 전후 비교에서는 같은 시간 범위와 같은 기능 구성을 사용해야 합니다. 거래 대상 종목 수가 늘어난 날과 줄어든 날의 총 사용량만 비교하면 코드 개선의 효과를 잘못 평가할 수 있습니다. 기능별 호출 수, 가중치 예상치, 서버 관측값, 오류 수를 함께 비교하면 어떤 변경이 실제로 영향을 줬는지 판단하기 쉽습니다.

또한 예산 절약을 위해 데이터 범위를 줄인 뒤에도 프로그램이 필요한 질문에 답할 수 있는지 확인해야 합니다. 호가 일부만 받고 전체 유동성을 안다고 판단하거나, 주문 조회를 줄인 뒤 상태 확인이 끝났다고 표시하면 통신 비용은 줄어도 판단 근거가 약해집니다. 최적화의 완료 기준은 요청량 감소뿐 아니라 필요한 정보의 정확성과 신선도를 유지하는 것입니다.

12. FAQ

Q1. 바이낸스 Request Weight는 수수료인가요?

아닙니다. API 요청의 제한 계산에 쓰는 가중치입니다. 체결 수수료나 VIP 거래량 계산과 구분해야 하며, 가중치를 절약했다고 거래 수수료가 자동으로 할인되는 것은 아닙니다.

Q2. 요청 한 번은 항상 가중치 1인가요?

아닙니다. 경로와 파라미터 조건에 따라 달라질 수 있습니다. 현재 사용하는 엔드포인트의 Weight 항목을 확인하고, 여러 심볼이나 큰 조회 범위를 지정했을 때 별도 표가 있는지 봐야 합니다.

Q3. 공개 시세만 가져와도 제한을 받나요?

인증이 없는 요청이라고 무제한이라고 볼 수 없습니다. 공개 엔드포인트에도 문서상 가중치와 제한이 있습니다. 주문을 하지 않는 대시보드도 반복 조회가 많으면 사용량에 영향을 줄 수 있습니다.

Q4. API 키를 바꾸면 사용량이 초기화되나요?

IP Limits의 예산을 키별로 독립된 것으로 생각하면 안 됩니다. 같은 외부 IP를 공유한다면 다른 키를 사용하는 요청의 영향도 고려해야 합니다. 키 변경을 제한 회피 방법으로 사용하지 마세요.

Q5. 거래가 체결되면 Request Weight도 줄어드나요?

주문 카운트의 공식 감소 규칙을 Request Weight에 그대로 적용하지 않습니다. 두 제한은 추적 대상이 다릅니다. 사용 구간과 헤더를 확인해야 하며 체결을 호출 예산 환급으로 해석해서는 안 됩니다.

Q6. 429는 항상 조회를 너무 많이 해서 생기나요?

아닙니다. 주문 관련 제한에서도 나타날 수 있습니다. 응답 메시지와 관련 헤더를 확인해 어떤 제한인지 구분해야 합니다. 코드 숫자 하나만 보고 요청 주기만 바꾸면 원인을 놓칠 수 있습니다.

Q7. Retry-After의 단위는 무엇인가요?

이 글에서 다루는 Spot REST 429·418 응답 헤더는 기다려야 할 초 단위 시간을 안내합니다. 다른 제품이나 다른 응답 필드에도 같은 해석을 자동 적용하지 말고 각각의 공식 설명을 확인하세요.

Q8. 프로그램을 껐다 켜면 다시 호출해도 되나요?

프로그램 재시작은 서버가 관리하는 제한 구간을 초기화하지 않습니다. 내부 카운터만 0이 된 상태에서 많은 요청을 보내면 실제 사용량을 과소평가할 수 있습니다. 진행 중이던 작업과 서버 관측값을 확인해야 합니다.

Q9. 여러 종목을 한 번에 조회하는 것이 늘 효율적인가요?

항상 그렇지는 않습니다. 단일 조회와 복수 조회의 가중치, 필요한 종목 수, 응답 크기, 재사용 가능성을 비교해야 합니다. 한 번 호출했다는 이유만으로 가장 저렴한 선택이라고 판단하지 않습니다.

Q10. 사용량 헤더가 예상보다 큰 이유는 무엇인가요?

같은 IP의 다른 작업, 병렬 요청, 재시도, 잘못 계산한 엔드포인트 비용을 확인해 볼 수 있습니다. 이는 가능한 진단 항목이지 특정 원인의 확정은 아닙니다. 실제 호출 로그와 네트워크 구성을 대조하세요.

Q11. 가중치가 남으면 주문은 받아들여지나요?

그렇지 않습니다. 잔고, 심볼 상태, 주문 필터, 권한, 주문 카운트, 시간 검증 등 다른 조건도 적용됩니다. Request Weight는 여러 검사 중 하나이므로 전체 주문 가능 여부를 대표하지 않습니다.

Q12. WebSocket은 무제한 대체 수단인가요?

아닙니다. 사용하는 WebSocket API 또는 Streams의 연결·요청·메시지 제한을 확인해야 합니다. 스트림 방식은 반복 조회를 줄이는 데 도움이 될 수 있지만 별도의 연결 관리와 데이터 검증이 필요합니다.

Q13. 공식 문서 예시의 limit을 그대로 써도 되나요?

구조를 이해하는 출발점으로는 유용하지만 영구 고정값으로 취급하지 않는 편이 좋습니다. 현재 서비스와 응답을 확인하고 변경에 대응할 수 있게 구성해야 합니다. 선물이나 지갑 API에 현물 예시를 복사하지 마세요.

Q14. 제한을 피하려면 조회를 모두 멈추면 되나요?

이미 제한이 발생했다면 요구된 대기를 따라야 합니다. 평상시 설계에서는 무작정 조회를 없애기보다 중복과 불필요한 범위를 줄이고, 주문 상태 확인 같은 필요한 작업을 계획해야 합니다. 통신량과 정보 신선도를 함께 봅니다.

Q15. 자동 주문 초보자가 가장 먼저 바꿀 부분은 무엇인가요?

새 기능을 추가하기 전에 실제 호출 목록과 응답 헤더를 관찰할 수 있게 만드는 것이 좋습니다. 어떤 기능이 얼마나 요청하는지 모르면 조정 결과도 평가하기 어렵습니다. 관측 후 작은 범위에서 호출 주기와 재시도 정책을 수정하세요.

13. 실행 전후 체크리스트

• 사용하는 서비스가 Spot REST인지 다른 제품인지 구분했다.
• 모든 호출 경로와 메서드를 목록으로 만들었다.
• 단일·복수 심볼 등 파라미터별 가중치를 확인했다.
• rateLimits의 종류와 시간 구간을 함께 저장한다.
• X-MBX-USED-WEIGHT 계열 헤더를 기록한다.
• 같은 외부 IP의 다른 프로그램을 파악했다.
• 정상 상태와 장애 재시도 상태의 호출량을 나눠 검토했다.
• 재시도 책임이 여러 계층에서 중복되지 않는다.
• 429·418에서 대기와 중단 절차가 있다.
• 미확인 주문을 새 주문으로 덮어쓰지 않는다.
• 캐시 데이터의 갱신 시각과 만료 정책을 정했다.
• 스트림 사용 시 연결과 데이터 신선도를 확인한다.
• 로그에 인증 비밀값을 남기지 않는다.
• 변경 후 호출량과 상태 확인 지연을 함께 점검한다.

핵심 정리

바이낸스 Request Weight를 이해하면 자동 주문의 장애를 단순히 “API가 느리다”로 묶지 않고, 어떤 요청이 예산을 사용하는지 구체적으로 볼 수 있습니다. 다음 단계는 호출량이 아니라 요청의 시간 유효성을 관리하는 recvWindow입니다. 충분한 예산이 있어도 오래된 timestamp를 보내면 다른 이유로 요청이 거절될 수 있습니다.

이 글은 API 구조를 설명하는 정보성 자료이며 특정 거래 전략이나 수익을 권유하지 않습니다. 실제 한도·지원 기능·오류 처리는 변경될 수 있으므로 운영 전 Binance 공식 문서와 현재 응답을 확인하세요.