바이낸스 Order Rate Limit 뜻 2026｜ORDERS·미체결 카운트·429 대응

바이낸스 Order Rate Limit 뜻과 미체결 주문 카운트

바이낸스 Order Rate Limit를 이해하려면 ‘현재 열린 주문이 몇 개인가’, ‘정해진 시간 동안 미체결 주문 카운트를 얼마나 사용했는가’, ‘API 요청 가중치를 얼마나 사용했는가’를 나눠야 합니다. 모두 한도처럼 보이지만 같은 숫자를 세는 규칙이 아닙니다.

특히 주문을 취소하면 모든 한도가 즉시 줄어든다고 생각하기 쉽습니다. 그러나 현재 Binance Spot 공식 문서의 미체결 주문 카운트 규칙에서는 취소·만료와 첫 체결의 처리를 다르게 설명합니다. 열린 주문 목록이 줄었다는 사실만으로 시간 구간의 ORDERS 카운트도 같은 만큼 감소했다고 판단해서는 안 됩니다.

이 글은 2026년 10월 26일 확인한 Spot Unfilled Order Count Rules, REST API Limits와 Filters 문서를 기준으로 작성했습니다. 선물이나 다른 거래소의 한도에 그대로 적용하지 않습니다. 아래 카운트·시간 구간·상한의 숫자는 작동 방식을 보여 주는 가상 사례이며 실제 현재 한도는 공식 조회 결과로 확인해야 합니다.

세 가지 제한부터 구분합니다

열린 주문 수 제한

열린 주문 수 관련 필터는 현재 존재하는 주문의 개수와 관련됩니다. 심볼별 또는 거래소 차원의 필터 등 범위를 확인해야 합니다. 특정 거래쌍에 열린 주문이 많아서 생기는 문제와 시간 구간의 신규 주문 카운트 문제는 같지 않을 수 있습니다.

주문 목록이 여러 하위 주문을 포함하면 단순히 목록 한 개를 주문 한 개로 세어도 되는지 별도 확인이 필요합니다. 정확한 계산은 해당 주문 경로의 문서와 필터를 따릅니다. 화면에 한 카드로 보인다는 이유만으로 내부 제한도 한 개라고 추측하지 않습니다.

ORDERS 시간 구간 카운트

Spot의 미체결 주문 카운트는 정해진 시간 구간에서 신규 주문의 배치와 체결에 관련된 규칙입니다. 현재 열린 주문 목록의 길이를 복사한 값이 아닙니다. 새 주문이 추가되고 첫 체결이 발생하는 방식, 구간 갱신이 함께 작용합니다.

공식 문서는 계정 또는 서브계정 단위로 추적되며 그 범위 안의 IP·API 키·API 경로 사이에서 공유된다고 설명합니다. 따라서 같은 계정에서 프로그램을 여러 개 실행하면 서로의 사용량에 영향을 줄 수 있습니다. Spot 미체결 주문 카운트 공식 FAQ

REQUEST_WEIGHT 등 API 요청 제한

API 호출에는 요청 가중치와 별도의 제한이 관련됩니다. 많은 데이터를 조회하는 요청과 가벼운 요청의 비용이 같다고 가정하면 안 됩니다. 주문이 잘 체결돼 ORDERS 카운트가 여유롭더라도 조회 요청이 과도하면 다른 제한에 걸릴 수 있습니다.

현재 REST 문서는 IP 기준 요청 가중치 사용량과 계정 기준 주문 카운트를 구분합니다. 어느 제한이 발생했는지 확인하지 않고 API 키만 바꾸거나 요청 경로를 바꾸는 방식으로 해결하려 해서는 안 됩니다. 제한의 공유 범위와 안내를 그대로 따라야 합니다.

현재 한도는 어디서 확인하나요?

Exchange Information의 rateLimits에서 rateLimitType, interval, intervalNum, limit를 읽습니다. 어떤 종류의 제한인지, 구간 단위가 무엇인지, 몇 단위의 구간인지와 상한이 얼마인지를 함께 확인해야 합니다.

숫자만 보관하면 의미가 사라집니다. 예를 들어 가상 한도 20이 있어도 20회/초인지 20회/분인지, 주문 카운트인지 가중치인지에 따라 완전히 다릅니다. 네 필드를 하나의 규칙으로 묶어 저장합니다.

문서의 예시 숫자는 설명용입니다. 예제에 10초 구간이 있다고 현재 모든 계정이 동일한 10초 상한만 적용받는다고 쓰면 안 됩니다. 여러 구간이 동시에 적용될 수 있으므로 하나가 여유롭다고 전체가 허용되는 것은 아닙니다.

사용량은 주문 응답의 X-MBX-ORDER-COUNT-... 헤더와 GET /api/v3/rateLimit/order 같은 공식 조회 경로를 확인합니다. 실패 응답에는 관련 헤더가 항상 제공된다고 보장되지 않으므로, 헤더가 없다는 이유로 사용량을 0으로 초기화하지 않습니다. REST Limits 공식 문서

새 주문과 첫 체결의 관계

현재 공식 FAQ는 성공적으로 새 주문을 배치할 때 해당 구간의 카운트가 증가하고, 주문이 처음으로 일부 또는 전부 체결되면 카운트 감소가 적용되는 구조를 설명합니다. 중요한 단어는 처음으로입니다.

한 주문이 여러 번 나누어 체결된다고 모든 체결 이벤트마다 같은 감소를 반복 계산하면 안 됩니다. 최초 체결과 이후 체결을 구분해야 합니다. 거래 이벤트 수를 카운트 감소 횟수로 그대로 복사하는 것은 잘못된 추정이 될 수 있습니다.

또한 특정 조건에서는 감소량이 한 개보다 클 수 있다는 공식 설명이 있습니다. 이를 모든 maker 주문의 고정 보상으로 일반화하거나 공개되지 않은 산식을 만들어서는 안 됩니다. 실제 한도와 관측값을 확인하는 것이 우선입니다.

첫 체결과 사용량 갱신 사이에는 짧은 지연이 있을 수 있다는 점도 문서에 안내됩니다. 한도에 가까운 상태에서 ‘방금 체결됐으니 즉시 여유가 생겼을 것’이라고 단정해 요청을 몰아 보내지 않습니다. 서버에서 확인되는 사용량과 응답을 기준으로 관리해야 합니다.

취소와 만료는 왜 다른가요?

공식 FAQ는 주문 취소와 만료가 미체결 주문 카운트를 감소시키지 않는다고 설명합니다. 이것은 현재 열린 주문 수의 변화와 다른 규칙입니다. 목록에서 사라진 주문과 해당 구간에서 사용한 카운트를 분리해서 보아야 합니다.

가상으로 카운트가 4인 상태에서 미체결 주문 하나를 취소했다고 합시다. 열린 주문 수는 줄 수 있지만, 그 취소만으로 ORDERS 카운트가 3이 됐다고 계산하면 안 됩니다. 실제 카운트는 해당 규칙과 현재 조회 결과로 확인합니다.

만료 역시 거래가 없었다면 카운트 감소의 근거로 사용하지 않습니다. 단, 이전에 첫 체결이 있었는지와 만료 사건 자체의 영향은 구분해야 합니다. 주문의 최종 상태 하나만 보고 전체 카운트 변화를 추정하면 과거 체결의 효과를 놓칠 수 있습니다.

이 규칙은 취소를 하지 말라는 권유가 아닙니다. 거래 목적상 취소가 필요할 수 있지만, 취소가 모든 요청 한도를 회복시키는 버튼은 아니라는 뜻입니다. 주문 위험 관리와 호출 한도 관리를 같은 기능으로 보지 않는 것이 중요합니다.

고정 시간 구간을 읽는 방법

공식 설명의 시간 구간은 임의의 ‘최근 몇 초’라는 표현만으로 해석하면 혼동할 수 있습니다. 예제에서는 정해진 경계 사이의 구간을 사용해 카운트를 설명합니다. 실제 적용 구간과 경계는 현재 문서·조회 정보를 기준으로 읽어야 합니다.

가상 구간이 1분이라면 12시 00분대와 12시 01분대처럼 경계를 갖는 모델로 설명할 수 있습니다. 이것은 마지막 요청을 보낸 순간부터 무조건 60초를 기다리는 개인 타이머와 같지 않습니다. 다만 오류 시에는 제공되는 재시도 안내와 해당 제한을 따라야 합니다.

짧은 구간이 초기화됐더라도 더 긴 구간의 제한은 남아 있을 수 있습니다. 모든 구간을 함께 확인해야 하는 이유입니다. 프로그램이 가장 짧은 구간만 관리하면 낮 동안 누적되는 다른 제한을 놓칠 수 있습니다.

현재 FAQ는 DAY 구간의 기준 시간대를 UTC로 설명합니다. 한국시간의 날짜 변경과 같은 시점으로 가정하지 않습니다. 기록에는 원본 시간대와 사용자 표시 시간대를 구분해 두면 경계 부근의 혼동을 줄일 수 있습니다.

계정 공유 범위와 여러 프로그램

같은 계정에서 두 봇과 수동 주문을 함께 사용하는 상황을 생각해 볼 수 있습니다. 각 프로그램이 자기 요청만 세면 전체 카운트를 과소평가할 수 있습니다. 로컬 카운트는 자기 관찰값일 뿐 계정 전체의 권위 있는 값이 아닐 수 있습니다.

공식 FAQ는 같은 계정 범위에서 API 키·IP·API가 공유하는 카운트를 설명합니다. 따라서 키를 추가했다고 새로운 독립 주문 한도가 생긴다고 가정하지 않습니다. 제한을 우회하기 위한 계정·IP 변경을 해결책으로 삼지 않고, 전체 사용량을 모아 관리해야 합니다.

서브계정이라는 표현도 실제 계정 구조와 연결해서 읽습니다. 어떤 범위가 독립적으로 추적되는지 공식 조건을 확인하고, 임의로 모든 계정의 합이나 분리를 가정하지 않습니다. 시스템의 계정 식별과 문서의 제한 단위를 맞추는 것이 중요합니다.

여러 실행자가 있는 경우에는 새로운 주문 요청을 한곳에서 조정하거나 공유 사용량을 확인하는 방식이 도움이 될 수 있습니다. 이는 더 많은 요청을 밀어 넣기 위한 장치가 아니라, 동시에 각자 여유가 있다고 판단하는 충돌을 줄이기 위한 운영 방법입니다.

Order Amend와 Cancel Replace의 카운트 차이

현재 문서는 Order Amend Keep Priority의 미체결 주문 카운트 증가가 0이라고 안내합니다. 반면 Cancel Replace는 별도의 카운트 동작을 갖고, 신규 배치가 NOT_ATTEMPTED인 경우에도 증가가 설명됩니다. 이름이 모두 수정처럼 느껴져도 같은 비용 구조라고 가정할 수 없습니다.

다만 카운트 증가가 0이라는 이유로 수량 감소 수정을 무제한 호출해도 된다는 뜻은 아닙니다. 요청 가중치와 수정 횟수 필터, 계정 조건은 별도입니다. 하나의 제한에서 유리한 특성을 모든 제한이 없다는 의미로 확장하지 않습니다.

기능은 거래 목적에 맞춰 선택해야 합니다. 한도를 줄이기 위해 원래 의도와 다른 주문 형태를 쓰거나 불필요한 실제 거래를 만들어서는 안 됩니다. 필요한 변경만 수행하고 결과를 정확히 확인하는 것이 우선입니다.

체결을 한도 확보 수단으로 생각하지 않습니다

공식 규칙에서 체결과 카운트 감소가 연결된다고 해서, 한도를 확보하려고 원치 않는 거래를 만드는 것이 적절한 운영 방식은 아닙니다. 거래에는 가격 변동과 수수료, 자산 노출이 따릅니다. 주문 한도 관리가 거래 목적을 대신해서는 안 됩니다.

시장가 주문도 단순한 ‘카운트 초기화 버튼’이 아닙니다. 지원 조건과 잔고, 유동성에 따라 결과가 달라지고 실제 자산 교환이 발생합니다. 첫 체결 여부와 실제 대금·수량을 정확히 이해해야 합니다.

사례 1: 주문을 취소했는데 한도 오류가 계속되는 경우

가상 사용자 A는 짧은 구간에 여러 미체결 주문을 만들었습니다. 한도 오류가 나자 열린 주문 일부를 취소했습니다. 목록의 행 수는 줄었지만 다음 신규 요청도 제한됩니다.

이 상황에서 취소가 실패했다고 바로 결론 내리면 안 됩니다. 취소 결과와 ORDERS 카운트는 별도 규칙입니다. 실제 취소 성공을 확인한 뒤, 카운트가 취소만으로 감소하지 않는다는 문서의 설명과 현재 사용량을 대조해야 합니다.

A는 현재 열린 주문 수, 각 시간 구간의 카운트와 오류의 Retry-After를 분리해서 봅니다. 필요 없는 주문이 종료됐다는 결과는 기록하되, 그것을 신규 요청 가능 상태의 증거로 사용하지 않습니다.

이 사례의 교훈은 한도 문제를 해결하려는 행동과 거래 위험을 줄이려는 행동을 나누는 것입니다. 취소는 거래 목적상 필요할 수 있지만 카운트 회복을 보장하지 않습니다. 오류 안내에 맞춰 추가 신규 요청을 멈추고 해당 구간을 확인해야 합니다.

사례 2: 한 주문이 여러 번 부분 체결된 경우

가상 주문 B가 처음 1단위, 이후 2단위, 마지막 3단위로 나누어 체결됐다고 합시다. 거래 이벤트는 세 번이지만 첫 체결은 한 번입니다. 각 이벤트마다 동일한 카운트 감소를 반복 적용하면 로컬 사용량이 실제보다 낮아질 수 있습니다.

공식 규칙은 최초 체결의 의미를 구분합니다. 따라서 내부 추적에서도 주문번호를 중심으로 첫 체결 여부를 관리해야 합니다. 같은 이벤트를 다시 수신한 경우에도 추가 첫 체결로 처리하지 않습니다.

B의 실제 거래량은 6단위라는 가상 합계로 설명할 수 있지만, 거래량 합계와 주문 카운트 변화는 같은 계산이 아닙니다. 체결 크기가 늘었다고 카운트가 선형으로 계속 줄어든다고 추정해서는 안 됩니다.

최종 확인은 공식 응답 헤더나 사용량 조회와 대조합니다. 로컬 추정값은 관찰 누락·중복 수신·갱신 지연의 영향을 받을 수 있습니다. 추정과 서버 관측값을 구분하면 차이가 생겼을 때 원인을 조사하기 쉽습니다.

사례 3: 두 프로그램이 같은 계정을 사용하는 경우

사용자 C는 같은 계정에서 전략 프로그램 두 개를 실행합니다. 각 프로그램은 가상 한도 10 중 자신이 6만 사용했다고 생각합니다. 그러나 실제 공유 범위에서는 두 프로그램의 활동을 함께 고려해야 합니다.

각각의 로컬 로그만 보면 여유가 있는 것처럼 보일 수 있습니다. 하지만 실제 계정 카운트는 다른 프로그램과 수동 주문의 영향을 받을 수 있습니다. 자기 로그를 계정 전체 사용량으로 취급한 것이 문제입니다.

C는 계정별 공유 사용량을 확인하는 통합 지점을 마련하고, 제한이 가까우면 각 프로그램이 독립적으로 신규 요청을 몰아 보내지 않도록 조정합니다. 실제 한도 규칙과 결과를 공유하는 것이 중요합니다.

해결책으로 API 키를 더 만들어 독립 한도를 기대하지 않습니다. 공식 공유 범위를 따르면서 필요 없는 요청을 줄이고 신규 거래 의도를 조정해야 합니다. 여러 프로그램의 동시 실행 자체가 잘못은 아니지만 공동 자원이라는 점을 반영해야 합니다.

사례 4: 주문 카운트는 낮지만 요청 가중치가 초과된 경우

사용자 D의 주문은 잘 체결돼 ORDERS 카운트가 높지 않습니다. 그러나 대량의 시장 데이터 조회를 자주 반복해 요청 가중치 제한에 도달했다고 가정합니다. 이때 주문 체결만 확인하고 ‘한도에 걸릴 이유가 없다’고 판단하면 다른 제한을 놓칩니다.

오류 응답과 사용량 헤더에서 제한 종류를 확인해야 합니다. 같은 429라도 발생 맥락과 안내를 함께 읽습니다. 주문 카운트가 여유롭다는 사실이 모든 API 요청의 여유를 보장하지 않습니다.

D는 반복 조회를 줄이고 필요한 데이터 범위와 갱신 주기를 재검토합니다. 이미 받은 정보를 여러 프로그램이 중복 요청하는지, 더 무거운 조회를 불필요하게 사용하는지 확인할 수 있습니다. 공식 제한을 존중하면서 요구되는 관찰을 효율적으로 수행하는 것이 목적입니다.

이 사례에서 주문을 취소하거나 새로 체결시키는 것은 요청 가중치 문제의 직접 해결책이 아닙니다. 제한이 무엇인지 먼저 파악해야 불필요한 거래 행동을 피할 수 있습니다.

사례 5: 날짜가 바뀌었는데 예상 카운트와 다른 경우

사용자 E는 한국시간 자정이 지나면 DAY 카운트가 초기화될 것이라고 생각합니다. 하지만 현재 공식 FAQ의 DAY 기준은 UTC입니다. 지역 표시 시각과 제한 경계의 기준을 혼동하면 잘못된 초기화 시점으로 판단하게 됩니다.

또한 어제 배치한 주문이 오늘 처음 체결될 때의 감소는 현재 카운트와 관련된다는 문서 설명이 있습니다. 주문 생성 날짜만으로 모든 변화가 과거 구간에 속한다고 생각하지 않습니다. 생성 시각과 첫 체결 시각을 분리해 읽어야 합니다.

공식 FAQ는 카운트가 0 아래로 내려가 미래 요청을 위한 크레딧처럼 쌓이지 않는다는 점도 설명합니다. 가상으로 체결이 많이 발생해도 마이너스 사용량을 적립했다고 계산해서는 안 됩니다. 신규 주문은 현재 규칙에 따라 다시 카운트됩니다.

E는 구간 종류, 원본 UTC 시각과 한국시간 표시를 함께 기록합니다. 날짜별 보고서를 만들 때도 거래 기록의 표시 날짜와 제한 구간의 경계를 같은 것으로 처리하지 않습니다. 시간대 차이를 숫자 오류로 오해하지 않게 됩니다.

429와 -1015를 받으면 확인할 것

현재 공식 FAQ는 미체결 주문 카운트 한도를 넘었을 때 HTTP 429와 -1015 오류를 설명합니다. 이 경우 영향을 받은 구간이 만료될 때까지 신규 주문 전송을 멈추라는 안내를 따릅니다. 재시도 시간을 무시하고 같은 요청을 반복하는 방식은 해결책이 아닙니다.

REST 문서는 429 또는 418 응답의 Retry-After 안내를 확인하도록 설명합니다. 반복적인 한도 위반과 대기 안내 무시는 추가 제한으로 이어질 수 있습니다. 고정된 짧은 간격으로 계속 두드리는 대신 실제 응답의 의미와 시간을 읽어야 합니다.

단, 오류 코드 하나만으로 현재 시장의 모든 주문이 취소됐다고 판단하지 않습니다. 신규 요청이 거절됐다는 사실과 기존 열린 주문의 상태는 다릅니다. 제한이 발생한 동안에도 기존 주문이 어떻게 진행됐는지 필요한 범위에서 확인해야 합니다.

조회 자체에도 제한이 적용될 수 있으므로 상태 확인을 명목으로 과도한 폴링을 만들지 않습니다. 필요한 자료를 모으되 공식 제한과 안내를 지켜야 합니다. 제한을 피하려고 IP나 키를 바꿔 반복 제출하는 방식으로 우회하지 않습니다.

Retry-After를 기록할 때의 주의점

응답 시각과 대기 안내값을 함께 보관하면 언제부터 어느 요청을 다시 검토할지 명확해집니다. 단위가 무엇인지 공식 문서와 실제 응답을 확인해야 합니다. 초 단위 값을 밀리초처럼 읽거나 반대로 해석하면 너무 이른 재요청 또는 불필요한 장기 대기가 생길 수 있습니다.

대기 시간이 끝났다는 사실은 이전 거래 의도가 여전히 유효하다는 뜻은 아닙니다. 가격과 잔고, 기존 주문의 체결 상태가 달라졌을 수 있습니다. 다시 전송하기 전에 실제 거래 목적과 현재 상태를 확인해야 합니다.

재시도에는 이전 요청의 처리 결과도 포함해 검토합니다. 한도 오류가 명확한 경우와 통신 단절로 결과를 모르는 경우는 다릅니다. 후자는 기존 요청의 존재를 확인하지 않고 새 요청을 보내면 중복 거래가 생길 수 있습니다.

로컬 카운터를 설계할 때 피할 오류

첫째, 모든 주문 제출 시도를 동일한 카운트 증가로 처리하지 않습니다. 성공·거절·특정 엔드포인트의 별도 규칙을 현재 문서에 맞춰 읽어야 합니다. 특히 Cancel Replace의 NOT_ATTEMPTED처럼 직관과 다른 설명이 있을 수 있습니다.

둘째, 모든 체결 이벤트를 감소로 처리하지 않습니다. 첫 체결과 이후 체결, 중복 수신을 구분해야 합니다. 체결 이벤트의 개수와 주문의 최초 체결 횟수는 다른 값입니다.

셋째, 하나의 구간만 관리하지 않습니다. 여러 시간 구간이 적용될 수 있으므로 현재 제한 목록을 읽고 각각의 사용량과 경계를 따로 관리해야 합니다. 짧은 구간의 여유만 보고 요청을 허용하면 긴 구간 제한을 놓칠 수 있습니다.

넷째, 로컬값을 절대적인 진실로 취급하지 않습니다. 다른 프로그램의 활동, 수동 주문과 갱신 지연 때문에 차이가 생길 수 있습니다. 서버에서 확인되는 값과 대조하고 불일치를 기록해야 합니다.

다섯째, 카운트를 0 아래의 적립금처럼 다루지 않습니다. 실제 규칙의 하한과 초기화 방식을 반영해야 합니다. 많은 체결이 있었다고 미래에 무제한 주문 여유가 쌓였다고 계산하면 안 됩니다.

운영 보고서에 남기면 좋은 항목

한도 기록에는 계정 범위, 제한 종류, 구간과 상한, 관측 사용량, 관측 시각을 둡니다. 오류가 났다면 HTTP 상태와 오류 코드, Retry-After, 마지막으로 확인한 실제 주문 상태를 연결합니다. 로그 양을 늘리기보다 의미가 다른 값을 분리하는 것이 중요합니다.

주문 기록과 한도 기록은 연결하되 같은 표의 같은 수량으로 만들지 않습니다. 주문 표의 체결량은 실제 자산 거래를 설명하고, 한도 표의 카운트는 요청 가능 조건을 설명합니다. 단위와 목적이 다릅니다.

예를 들어 ‘주문 3개 취소, 열린 주문 2개, ORDERS 카운트 8’은 서로 모순일 필요가 없습니다. 각각의 범위와 시점이 다르기 때문입니다. 이름을 정확히 붙이면 사용자도 왜 숫자가 같지 않은지 이해하기 쉽습니다.

비밀 키나 인증 토큰을 일반 보고서에 남기지 않습니다. 계정 전체 비밀정보 없이도 제한 종류와 오류를 분석할 수 있어야 합니다. 필요한 식별자와 시각만 보존하고 공식 지원 경로에 전달할 자료도 최소화합니다.

제한 종류별로 다른 대응 계획을 둡니다

한도에 가까워졌을 때 모든 요청을 같은 방식으로 처리하면 필요한 상태 확인까지 막거나 불필요한 신규 요청을 계속 보내는 문제가 생길 수 있습니다. 어떤 제한을 사용하고 있는지, 각 요청의 목적이 무엇인지 분리해 계획해야 합니다. 단, 필요한 요청이라고 해서 공식 제한을 초과할 수 있는 것은 아닙니다.

신규 거래 의도를 만드는 요청과 이미 보낸 요청의 결과를 확인하는 작업은 역할이 다릅니다. 제한이 발생했을 때는 새로운 의도를 계속 쌓기보다 미확인 상태를 정리하고 현재 주문을 파악하는 데 집중할 수 있습니다. 이때도 허용되는 조회 빈도와 대기 안내를 따라야 합니다.

예약해 둔 요청을 대기 후 한꺼번에 재전송하는 방식도 조심해야 합니다. 기다리는 동안 거래 목적이 바뀌거나 기존 주문이 체결됐을 수 있습니다. 오래된 의도를 모두 실행하는 대신 각 요청이 여전히 필요한지 확인하고 현재 한도 안에서 처리해야 합니다.

결과적으로 한도 관리에는 요청 속도뿐 아니라 요청의 수명 관리가 포함됩니다. 언제 만들어진 의도인지, 아직 유효한지, 이미 처리된 요청은 아닌지를 확인해야 합니다. 속도를 낮추는 것만으로 중복 거래 문제까지 해결되지는 않습니다.

구간별 사용량을 읽는 연습

가상 계정에 짧은 구간 상한 10과 긴 구간 상한 100이 동시에 있다고 합시다. 현재 사용량이 각각 2와 100이라면 짧은 구간에 8의 여유가 보이더라도 긴 구간 조건을 무시할 수 없습니다. 실제 적용 규칙 중 하나라도 제한에 도달했는지 확인해야 합니다.

반대 경우도 생각할 수 있습니다. 긴 구간 사용량이 20이라 여유롭지만 짧은 구간이 상한에 가까우면 순간적인 요청 집중이 문제가 됩니다. 일일 총량만 보고 짧은 시간에 모든 요청을 보내는 설계는 적절하지 않을 수 있습니다. 숫자는 어디까지나 설명용이고 실제 구간·상한은 조회값으로 대체해야 합니다.

구간을 저장할 때는 단위와 배수를 묶어 관리합니다. SECOND라는 문자열만으로 1초인지 여러 초인지 알 수 없습니다. intervalNum을 빠뜨리면 같은 단위의 다른 규칙을 덮어쓰거나 잘못된 초기화 주기를 적용할 수 있습니다.

관측값에는 시각도 필요합니다. 같은 카운트 5라도 언제 확인한 값인지 모르면 지금의 요청 가능 상태를 설명하지 못합니다. 오래된 수치를 최신으로 표시하지 않고 갱신 여부를 드러내면, 사람이 화면을 보고 잘못 판단할 가능성도 줄일 수 있습니다.

재시도 대기열의 중복을 점검합니다

한도 오류를 받은 요청을 대기열에 넣었다면 원래 요청과 후속 요청의 관계를 남깁니다. 같은 거래 의도를 여러 실행자가 각각 재시도 목록에 넣으면 대기 시간이 끝난 뒤 중복 실행될 수 있습니다. 요청 식별자와 거래 의도 식별자를 구분해 관리하는 이유입니다.

명시적으로 거절된 신규 요청과 처리 결과가 미확인인 요청은 같은 대기열 규칙으로 처리하지 않습니다. 전자는 원인을 해결하고 현재 의도를 재검토하는 것이 중심이지만, 후자는 이미 주문이 생겼는지 확인하는 것이 먼저입니다. 재시도 전에 어떤 증거가 필요한지 상태별로 정해 둡니다.

대기열에서 꺼낸 뒤에도 잔고·심볼 상태·필터가 바뀌었을 수 있습니다. 과거 검증을 통과한 요청이라는 이유로 현재 검증을 생략하지 않습니다. 특히 이전 부분 체결이 발생했다면 원래 수량을 그대로 다시 보내는 것이 맞는지 확인해야 합니다.

이러한 점검은 제한을 넘어서 더 많은 요청을 보내기 위한 방법이 아닙니다. 허용된 범위 안에서 실제로 필요한 요청만 수행하고, 같은 의도를 두 번 실행하지 않기 위한 방법입니다. 한도 준수와 정확한 주문 상태 관리는 함께 작동해야 합니다.

자주 묻는 질문 FAQ

1. Order Rate Limit는 열린 주문 개수인가요?

현재 열린 주문 수와 시간 구간의 ORDERS 카운트는 구분해야 합니다. 취소 후 열린 주문 수가 줄어도 카운트가 같은 방식으로 감소하는 것은 아닙니다. 실제 제한 종류를 확인합니다.

2. 실제 상한은 몇 개인가요?

이 글은 고정 숫자를 제시하지 않습니다. 현재 Exchange Information의 rateLimits와 해당 계정의 사용량을 확인해야 합니다. 공식 예제의 숫자를 현재 공통 상한으로 사용하지 않습니다.

3. 주문을 취소하면 카운트가 줄어드나요?

현재 Spot FAQ는 취소 자체가 미체결 주문 카운트를 감소시키지 않는다고 설명합니다. 취소 결과와 현재 열린 주문 수는 별도로 확인합니다. 카운트 회복을 목적으로 취소를 만능 해결책처럼 쓰지 않습니다.

4. 주문이 만료되면 줄어드나요?

만료 사건 자체도 카운트 감소와 구분합니다. 그 전에 첫 체결이 있었는지는 별도 이력입니다. 최종 상태만 보고 전체 카운트 변화를 추측하지 않습니다.

5. 부분 체결도 의미가 있나요?

공식 규칙은 최초 체결이 일부 또는 전부인지와 관련해 설명합니다. 중요한 것은 해당 주문의 첫 체결인지 여부입니다. 같은 주문의 이후 부분 체결마다 같은 감소를 반복 적용하지 않습니다.

6. maker 체결이면 항상 정해진 수만큼 줄어드나요?

공식 문서는 특정 조건에서 더 큰 감소가 가능하다고 설명하지만 예제의 수치를 모든 경우의 고정 공식으로 만들면 안 됩니다. 현재 규칙과 실제 카운트를 확인해야 합니다. 공개되지 않은 계산식을 추정하지 않습니다.

7. 카운트가 0 아래로 적립되나요?

현재 FAQ는 추가 체결이 미래 주문용 크레딧처럼 음수로 쌓이지 않는다고 설명합니다. 신규 주문은 다시 현재 규칙에 따라 카운트됩니다. 로컬 시스템도 임의의 음수 여유를 만들지 않아야 합니다.

8. API 키를 바꾸면 별도 한도인가요?

같은 계정의 ORDERS 카운트는 키·IP·API 사이에서 공유된다는 공식 범위를 확인해야 합니다. 키 추가를 새로운 독립 한도로 가정하지 않습니다. 우회 대신 공동 사용량을 관리합니다.

9. 여러 봇을 쓰면 어떻게 확인하나요?

각 봇의 자체 요청 수뿐 아니라 계정 전체 관측값을 확인해야 합니다. 수동 주문이나 다른 실행자의 활동이 있을 수 있습니다. 공유 카운트와 신규 요청 조정을 함께 고려합니다.

10. ORDERS가 낮은데 429가 나올 수 있나요?

요청 가중치 등 다른 제한도 확인해야 합니다. 주문 카운트가 여유롭다고 모든 API 요청 제한이 여유로운 것은 아닙니다. 오류 응답과 해당 헤더를 구분해 읽습니다.

11. DAY는 한국시간 자정 기준인가요?

현재 Spot FAQ는 UTC 기준으로 설명합니다. 한국시간 표시 날짜와 제한 구간 경계를 구분해야 합니다. 시간대 변환을 하더라도 원본 시각을 보존합니다.

12. 어제 주문이 오늘 체결되면 어떻게 읽나요?

현재 공식 설명은 새 첫 체결이 현재 미체결 주문 카운트에 영향을 준다고 안내합니다. 주문 생성일만으로 과거 구간에 고정하지 않습니다. 생성 시각과 체결 시각을 나눠 봅니다.

13. 수정 요청은 카운트가 없나요?

수정 방식별로 다릅니다. Order Amend Keep Priority와 Cancel Replace를 같은 동작으로 취급하지 않습니다. ORDERS 증가와 별도로 요청 가중치·수정 횟수 제한도 확인합니다.

14. 429를 받으면 바로 다시 보내나요?

공식 재시도 안내와 해당 제한 구간을 따라야 합니다. 반복 전송은 문제를 악화시킬 수 있습니다. 대기 후에도 기존 주문과 현재 거래 의도를 확인한 뒤 다음 요청을 결정합니다.

15. 체결을 만들면 한도가 늘어나니 거래해도 되나요?

한도 확보 자체를 목적으로 원치 않는 거래를 만들지 않습니다. 거래에는 비용과 위험이 따릅니다. 필요한 주문만 수행하고 제한 관리는 불필요한 요청 감소와 공식 안내 준수로 접근해야 합니다.

한도 관리 체크리스트

• [ ] 실제 상품이 Spot인지 확인했다.
• [ ] 열린 주문 수와 ORDERS 카운트를 분리했다.
• [ ] REQUEST_WEIGHT 등 다른 제한도 구분했다.
• [ ] 현재 rateLimits의 종류·구간·상한을 확인했다.
• [ ] 계정과 IP의 공유 범위를 구분했다.
• [ ] 여러 프로그램과 수동 주문의 영향을 고려했다.
• [ ] 첫 체결과 이후 체결을 나눠 기록했다.
• [ ] 취소·만료를 카운트 감소로 임의 계산하지 않았다.
• [ ] 서버 사용량과 로컬 추정의 차이를 점검했다.
• [ ] 짧은 구간과 긴 구간을 함께 확인했다.
• [ ] DAY의 UTC 경계를 반영했다.
• [ ] Retry-After와 오류 응답을 보존했다.
• [ ] 결과 미확인 요청은 조회 후 처리했다.
• [ ] 한도 확보를 위해 불필요한 실제 거래를 만들지 않았다.

핵심 정리와 마무리

바이낸스 Order Rate Limit는 주문 수, 시간 구간 카운트와 API 가중치를 나눠 읽어야 이해할 수 있습니다. 현재 공식 한도를 확인하고, 체결·취소·만료를 서로 다른 사건으로 기록하며, 제한 안내에 맞춰 요청을 조절하는 것이 중요합니다.

이 글은 API와 주문 기록을 이해하기 위한 정보성 자료입니다. 제한 우회나 특정 거래를 권하지 않으며 체결·수익을 보장하지 않습니다. 실제 운용 전 최신 Binance 공식 문서와 계정·상품의 조건을 확인하십시오.