코인 거래소 API 호출 제한 실측 — 머리글을 준 일곱 창구와 주지 않은 일곱 창구

altnara 자금흐름 데스크는 시장 데이터가 어느 창구에서 어떤 모양으로 나오는지를 점검합니다. 이번 노트의 주제는 거래소 API 호출 제한입니다. 운영자 보유 가능성: 본 매체는 비트코인·주요 알트 및 스테이블코인 보유 가능성을 명시합니다.

먼저 이 노트가 재는 자리를 못박아 둡니다. 여기서 잰 것은 전부 인증 헤더를 한 번도 붙이지 않고 부른 공개 시세 창구의 응답 머리글입니다. 계정을 붙이면 값이 달라집니다. 문서에서 옮긴 숫자와 머리글에서 읽은 숫자를 맞댈 때도 그래서 축을 먼저 봐야 합니다. 쿠코인 문서의 4,000은 VIP0 등급 계정이 쓰는 현물 자원 풀의 값이고, 제가 받은 머리글의 2,000은 키 없이 부르는 공개 자원 풀의 값입니다. 두 값을 한 줄에 놓고 "문서가 틀렸다"고 읽으면 틀린 글이 됩니다. 어느 문서를 여느냐에 따라 숫자가 달라지는 자리도 있었습니다. 실제로 어긋난 것과 어긋난 것처럼 보였을 뿐인 것을 아래에서 갈라 적었습니다.

스크립트로 시세를 부르다가 갑자기 막혀 본 적이 있으시다면, 그때 궁금한 것은 하나입니다. 지금 내가 얼마나 남겨 두었는가. 어떤 거래소는 그 값을 응답 머리글에 그대로 실어 보내고, 어떤 거래소는 한 글자도 알려 주지 않습니다. 이번에 열두 개 해외 거래소의 공개 시세 창구 열네 곳을 인증 없이 불러 응답 머리글을 통째로 받아 봤습니다. 호출 시각은 절마다 한국 시각으로 적었습니다.

결론부터 — 인증 없이 부른 일곱 창구가 알려 준 남은 몫

첫째, 열네 창구 가운데 남은 몫을 알려 준 곳은 일곱, 아무 말도 하지 않은 곳도 일곱이었습니다. 2026년 8월 19일 11시 25분 56초부터 11시 26분 10초(KST)까지 열네 창구를 다섯 회전, 모두 일흔 번 불렀고 전부 HTTP 200이 왔습니다. 알려 준 쪽은 바이낸스 현물·USDT 선물·코인 선물, 쿠코인, 게이트, 비트겟, 비트마트입니다. 알려 주지 않은 쪽은 바이비트, OKX, HTX, MEXC, 코인베이스, 크라켄, 데리비트입니다.

둘째, 문서의 숫자와 머리글의 숫자가 실제로 갈린 자리는 없었습니다. 갈린 것은 어느 문서를 여느냐였습니다. 게이트 공식 API v4 문서의 Frequency limit rule 표는 모든 공개 엔드포인트를 200r/10s per endpoint, 기준을 IP 로 적어 두었고, 제가 받은 X-Gate-RateLimit-Limit: 200 과 10초짜리 창, 엔드포인트마다 따로 도는 버킷이 이 표기와 그대로 맞았습니다. 다만 게이트 공식 저장소 gateio/rest-v4 README 의 성능 표는 같은 자리를 900r/s, 기준을 API Key 로 적어 두어서 저장소만 보면 45배가 벌어진 것처럼 읽힙니다. 쿠코인도 사정이 같았습니다. 문서의 4,000은 현물 열이고, 같은 표의 맨 끝 Public 열이 2000/30s 라서 제 머리글과 정확히 맞았습니다.

셋째, 머리글 이름이 뜻을 알려 주지 않았습니다. 비트마트의 X-BM-RateLimit-Remaining은 남은 몫이 아니라 쓴 몫이었고, 값이 1에서 15로 올라간 뒤 열여섯 번째 호출부터 429가 왔습니다. 비트겟이 쓰는 이름은 x-mbx-used-remain-limit인데 x-mbx- 는 바이낸스가 쓰는 머리글 앞자리입니다. 게이트의 X-Gate-RateLimit-Reset-Timestamp는 잔량이 되돌아오는 자리에서 튀지 않고 호출 시각을 그대로 따라 움직였는데, 이것은 문서가 적어 둔 그대로였습니다. 한도를 넘기지 않았으면 그냥 현재 시각이 온다고 문서가 못박아 두었습니다.

이 노트가 재는 자리와 재지 않는 자리

같은 주제어로 묶이기 쉬운 자리를 먼저 갈라 둡니다.

첫째, 입출금 이야기가 아닙니다. 출금이 안 되는 이유, 출금이 늦어지는 이유, 입출금이 중단되는 사정은 이 노트에서 다루지 않습니다. 여기서 보는 것은 오직 인증 없이 열리는 공개 시세 엔드포인트가 돌려주는 HTTP 응답 머리글입니다.

둘째, 열쇠를 다루는 글도 아닙니다. API 키를 어떻게 만들고, 어떤 권한을 켜고 끄고, 접속 IP 허용 목록을 어떻게 거는지는 범위 밖입니다. 이 노트는 키를 한 번도 쓰지 않았습니다.

셋째, 어느 거래소가 낫다는 판단을 하지 않습니다. 한도가 넓다고 좋은 것도 좁다고 나쁜 것도 아닙니다. 좁으면 한쪽 이용자가 창구를 독차지하는 일을 막고, 넓으면 자료를 모으는 쪽이 편합니다. 이 노트가 하는 일은 각 창구가 어디에 선을 그어 두었는지, 그리고 그 선을 응답으로 알려 주는지를 같은 방식으로 재서 나란히 놓는 것까지입니다.

넷째, 인증했을 때의 값은 재지 않았습니다. 등급별 한도와 계정 기준 한도는 각 문서의 문구를 옮기는 데까지만 썼고, 그 값이 실제로 그렇게 걸리는지는 확인하지 않았습니다.

열네 창구의 응답 머리글 이름과 값을 그대로 옮깁니다

2026년 8월 19일 11시 25분 56초부터 11시 26분 10초(KST), 협정세계시로는 8월 19일 2시 25분입니다. 열네 창구를 번갈아 다섯 회전 불렀고 인증 헤더는 어디에도 붙이지 않았습니다. 이 열네 곳을 연 거래소는 열둘입니다. 바이낸스만 현물과 USDT 선물과 코인 선물이 서로 다른 주소로 갈리기 때문에 창구 수와 거래소 수가 둘 어긋납니다.

첫 회전에서 받은 값을 그대로 옮깁니다.

여기서 눈에 걸리는 자리가 넷입니다.

첫째, 바이낸스 현물만 같은 값을 두 줄로 줍니다. 공식 저장소의 rest-api.md 는 머리글 이름을 X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) 하나로만 적어 두었고, 뒤에 붙는 글자는 SECOND => S / MINUTE => M / HOUR => H / DAY => D 규칙을 따른다고 설명합니다. 그러니 1m 이 붙은 줄은 문서대로입니다. 그런데 현물 응답에는 접미사가 없는 x-mbx-used-weight 가 한 줄 더 옵니다. 이 문서 안에서 해당 문자열은 정확히 한 번 나오고 전부 접미사가 붙은 형태입니다. 선물 두 창구에는 접미사 없는 줄이 오지 않았습니다.

둘째, 비트겟이 쓰는 이름이 남의 집 이름입니다. x-mbx-used-remain-limit 의 x-mbx- 는 바이낸스가 쓰는 앞자리입니다. 뜻도 조금 다릅니다. 바이낸스 쪽은 쓴 무게를 알려 주는데 비트겟 쪽은 남은 횟수로 읽힙니다.

셋째, 쿠코인의 gw-ratelimit-reset 은 시각이 아니라 카운트다운입니다. 29999로 시작해 줄어듭니다. 쿠코인 문서도 이 자리를 resource pool quota reset countdown (milliseconds) 로 적어 두었고, 예시로 "gw-ratelimit-limit": 500 "gw-ratelimit-remaining": 300 "gw-ratelimit-reset": 1489 를 들었습니다.

넷째, 비트마트만 기준을 밝힙니다. X-BM-RateLimit-Mode: IP 한 줄이 이 한도가 IP 기준임을 응답 안에서 말해 줍니다. 나머지 여섯 창구는 그 값이 IP 몫인지 계정 몫인지를 응답만으로는 알 수 없습니다.

같은 거래소의 다른 공개 엔드포인트로 한 번 더 확인했습니다. 11시 44분 23초(KST) 에 게이트 무기한 선물 시세, 게이트 현물 호가, HTX 호가와 심볼 목록, 바이비트 호가, OKX 호가, MEXC 호가, 크라켄 호가, 코인베이스 호가, 데리비트 호가를 각각 한 번씩 불렀습니다. 게이트 두 곳은 머리글이 왔고 나머지는 여전히 오지 않았습니다. 머리글의 유무는 엔드포인트가 아니라 거래소 단위로 갈리는 것으로 관측됩니다.

문서가 적어 둔 상한과 머리글이 알려 준 상한을 맞대 본 두 자리

머리글에서 읽은 값과 문서에서 옮긴 값을 맞대 본 자리가 둘입니다. 게이트의 200과 쿠코인의 2,000이 응답 머리글에서 읽은 값이고, 게이트 저장소의 900과 쿠코인 문서의 4,000이 문서에서 옮긴 값입니다. 결론부터 적으면 둘 다 실제로 갈린 자리가 아니었습니다.

게이트 — 어느 문서를 여느냐가 갈랐습니다. 처음에 근거로 삼은 것은 공식 저장소 gateio/rest-v4 의 README 였습니다. 게이트 공식 문서 사이트가 세 주소 모두 HTTP 403이라 열리지 않았기 때문입니다. 그 README 의 API Performance 표 첫 줄이 이렇습니다. Spot | Public endpoints | 900r/s | API Key | Depth,Kline,trading pairs,etc. 네 번째 칸이 기준을 적는 자리인데 현물 공개 엔드포인트의 기준이 API Key 입니다.

그런데 게이트 현행 공식 API v4 문서를 열면 값이 다릅니다. 이 문서는 라이브 주소가 지금도 403이라 인터넷 아카이브에 남은 스냅샷으로 받아 축자로 확인했습니다. 그 안의 Frequency limit rule 표가 이렇게 적습니다. All public endpoints | Public endpoints | 200r/10s per endpoint | IP | Orderbook, Candlestick, Ticker, etc. 모든 공개 엔드포인트가 엔드포인트마다 10초에 200회이고 기준은 IP 입니다.

제가 받은 값은 200이었습니다. 창의 길이를 재기 위해 11시 30분 09초부터 11시 30분 54초(KST) 까지 0.3초 간격으로 계속 불렀습니다. 잔량은 호출마다 1씩 줄었고, 200으로 되돌아간 순간이 네 번 있었습니다. 되돌아간 시각 사이의 간격은 9.844초·9.888초·10.266초 였습니다. 곧 10초짜리 고정 창에 200회이고, 이는 현행 문서의 200r/10s per endpoint 와 그대로 같습니다. 문서와 응답이 갈린 것이 아니라 저장소 README 한 장이 낡아 있었던 것입니다. 저장소 README 만 놓고 보면 900r/s 와 초당 20이 45배로 벌어진 것처럼 읽히지만, 그 45배는 실재하는 차이가 아닙니다.

세 머리글의 뜻도 그 현행 문서가 적어 두었습니다. X-Gate-RateLimit-Requests-Remain - your remaining requests for current endpoint, X-Gate-RateLimit-Limit - your current limit for current endpoint, 그리고 X-Gate-RateLimit-Reset-Timestamp - the timestamp indicating when your request limit resets if you have exceeded your rate_limit. Otherwise, this is just the current timestamp 입니다. 제 관측에서 Reset-Timestamp 가 호출 시각을 그대로 따라 움직인 것은 제가 한도를 넘기지 않았기 때문이고, 문서가 그 경우를 그냥 현재 시각이라고 못박아 두었습니다. 뒤에 나오는 바이비트의 X-Bapi-Limit-Reset-Timestamp 설명과 문장이 글자까지 같습니다. 저장소 README 에는 이 설명이 한 줄도 없습니다.

문서 표기를 실측으로 확인한 자리가 하나 더 있습니다. per endpoint 라는 표기 그대로 버킷이 엔드포인트마다 따로 돌았습니다. 11시 44분 23초에 같은 10초 창 안에서 무기한 선물 시세와 현물 호가를 잇달아 불렀는데 둘 다 잔량이 199 였습니다. 하나의 풀을 나눠 쓴다면 두 번째는 198이어야 합니다.

쿠코인 — 여기는 갈린 것처럼 보였을 뿐입니다. 쿠코인 문서의 자원 풀 표는 첫 칸이 등급이고 그 뒤로 자원 풀이 여덟입니다. 머리글 줄이 Level | Unified Account | Spot (include Margin) | Futures | Management | Earn | CopyTrading | Broker | Public 이고, VIP0 행의 값은 차례로 300/s | 4000/30s | 2000/30s | 2000/30s | 2000/30s | 2000/30s | 2000/30s | 2000/30s 입니다. 여기서 4,000은 현물 열입니다. 그런데 맨 끝 Public 열이 2000/30s 이고, 이 값은 VIP0부터 VIP12까지 전 등급에서 같습니다.

제가 받은 gw-ratelimit-limit 은 2000이었습니다. 머리글과 문서가 어긋난 것이 아니라 표의 두 열을 헷갈리면 어긋나 보이는 자리입니다. 문서도 갈래를 적어 두었습니다. 5. Public Endpoint Rate Limit # It is based on IP rate limitation. 그리고 6. Private Endpoint Rate Limit # With the exception of Public resource pool endpoints, all other resource pools are based on UID 입니다. 공개 창구는 IP 기준, 나머지는 계정 기준입니다.

창의 시작점도 문서와 맞았습니다. 쿠코인 문서는 the weight of this interface will be deducted and updated every 30s (starting from the arrival time of the user's first request) 라고 적습니다. 11시 31분 32초 730밀리초(KST) 첫 호출의 카운트다운이 29999로 시작해 1025까지 내려갔고, 되돌아온 시점은 11시 32분 02초 812밀리초, 곧 약 30.08초 뒤였습니다. 벽시계의 30초 경계가 아니라 내 첫 요청이 기준입니다.

쿠코인의 차감폭도 재 봤습니다. 11시 27분 50초부터 11시 27분 54초(KST) 사이에 세 엔드포인트를 이어 불렀습니다. 24시간 통계는 한 번에 15, 심볼 목록은 10, 호가 1단은 2를 먹었습니다. 그리고 셋의 잔량이 끊기지 않고 이어졌습니다. 1850에서 1840, 1830, 1820으로, 다시 1818, 1816, 1814로 내려갔습니다. 게이트와 정반대로 하나의 풀을 여러 엔드포인트가 나눠 씁니다. 응답 형식이나 파라미터 표기가 창구마다 갈리는 사정은 코인 과거 시세 데이터 소급 한계를 잰 노트에 정리해 두었습니다.

바이낸스 가중치를 직접 재 봤습니다 — 단계 수를 키우면 5·25·50·250으로 뛰는 자리

바이낸스는 호출 횟수가 아니라 무게를 셉니다. 문서가 이렇게 적습니다. Each route has a weight which determines for the number of requests each endpoint counts for. Heavier endpoints and endpoints that do operations on multiple symbols will have a heavier weight.

그래서 문서 표를 믿지 않고 직접 재 봤습니다. 방법은 간단합니다. 무게가 1인 ping 을 부르고 곧바로 목표 요청을 부른 뒤 두 응답의 머리글 값을 빼면 목표 요청의 무게가 나옵니다. 11시 28분 57초부터 11시 29분 01초(KST) 사이에 잰 값입니다.

먼저 잡음이 없는지부터 확인했습니다. ping 을 다섯 번 연속 불렀더니 25, 26, 27, 28, 29로 정확히 1씩 올라갔습니다. 11시 28분 57초 전후의 이 짧은 구간에 한해서는 현물 장부에 남의 몫이 섞이지 않았습니다. 다만 5분 뒤에 같은 현물 장부를 다시 재 보니 사정이 달랐는데, 그 대조는 다음 절에 적었습니다.

열세 자리 전부 문서와 같았습니다. 어긋난 자리는 0건입니다. 문서를 의심해서 잰 것인데 이번에는 문서가 맞았습니다.

여기서 실무적으로 중요한 것은 값이 맞았다는 사실보다 뛰는 폭입니다. 호가를 5단만 받든 100단을 받든 무게는 똑같이 5인데, 500단은 25, 1000단은 50, 5000단은 250입니다. 같은 엔드포인트인데 파라미터 하나로 50배가 됩니다. 같은 시각에 exchangeInfo 로 받은 상한은 현물 REQUEST_WEIGHT MINUTE 1 = 6000 이었으므로, 5000단 호가만 부르면 1분에 24번이면 그 상한에 닿습니다. 전 종목 24시간 통계는 무게가 80이니 1분에 75번입니다. 호출 횟수만 세고 있으면 이 자리가 보이지 않습니다.

같은 응답의 rateLimits 배열에는 다른 상한도 함께 실려 옵니다. 현물은 ORDERS SECOND 10 = 100, ORDERS DAY 1 = 200000, RAW_REQUESTS MINUTE 5 = 300000 이고, USDT 선물과 코인 선물은 둘 다 REQUEST_WEIGHT MINUTE 1 = 2400 입니다. 무게 상한과 횟수 상한이 따로 돌고 있습니다.

바이낸스 문서는 넘겼을 때 벌어지는 일도 적어 두었습니다. Requests fail with HTTP status code 429 when you exceed the request rate limit. 이고, 이어서 Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban (HTTP status 418). 그리고 IP bans are tracked and scale in duration for repeat offenders, from 2 minutes to 3 days. 입니다. 되돌아오는 데 최대 사흘이 걸린다고 적혀 있으므로 이 노트는 바이낸스에서 경계를 넘겨 보지 않았습니다. 또 하나 중요한 문장이 있습니다. The limits on the API are based on the IPs, not the API keys. 곧 키를 여러 개 만들어도 같은 회선에서 부르면 한 장부입니다.

현물 장부와 선물 장부는 따로 돌고, 선물 장부는 혼자 쓰는 것이 아니었습니다

바이낸스는 주소가 셋으로 갈립니다. 현물, USDT 선물, 코인 선물입니다. 장부가 몇 개인지 세어 봤습니다. 11시 32분 26초부터 11시 32분 27초(KST) 사이에 선물 두 호스트의 ping 을 번갈아 불렀고 값은 이렇게 이어졌습니다.

두 호스트를 번갈아 불러도 값이 하나의 수열로 이어집니다. USDT 선물과 코인 선물은 같은 장부를 씁니다.

현물이 그 장부에 섞이지 않는다는 것은 조금 앞선 회전에서 확인했습니다. 11시 29분 01초 692밀리초(KST) 에 현물이 114였는데, 58밀리초 뒤인 11시 29분 01초 750밀리초 에 USDT 선물은 11이었습니다. 두 값이 이어질 수 없는 자리입니다. 그러니 장부는 셋이 아니라 둘입니다.

그런데 위 표에 설명되지 않는 자리가 있습니다. 5번에서 6번으로, 9번에서 10번으로 넘어갈 때 값이 11씩 뛰었습니다. 제가 부른 ping 의 문서상 무게는 1입니다. 나머지 10은 어디서 왔는가.

말로 추측하는 대신 유휴 대조를 붙였습니다. 11시 33분 13초부터 11시 33분 35초(KST) 사이에 세 번 반복했고, 매번 앞뒤로 한 번씩만 읽은 뒤 그사이 6.12초 동안은 아무 요청도 보내지 않았습니다.

증가분에는 뒤쪽을 읽은 제 호출 1이 들어 있습니다. 그것을 빼면 현물은 6.12초에 0·4·4, 선물은 80·70·70 입니다. 초로 고르면 선물 장부는 제가 아무것도 하지 않는 동안 초당 11.4에서 13.1 사이로 흘러갔습니다.

현물도 2회차와 3회차에는 6.12초에 4씩 늘었습니다. 곧 내 몫이 아닌 성분은 선물 쪽이 훨씬 크지만 현물에도 있었습니다. 앞 절에서 11시 28분대 ping 다섯 번이 정확히 1씩 올라간 것은 그 짧은 구간에 한한 관측이고, 5분 뒤에는 같은 현물 장부가 유휴 중에도 움직였습니다.

여기서 말할 수 있는 것은 여기까지입니다. 원인은 확인하지 못했습니다. 후보는 셋입니다. 같은 출구 IP를 쓰는 다른 트래픽일 수도 있고, 통신사 공유 주소일 수도 있고, 이 PC의 다른 프로그램일 수도 있습니다. 세 번째를 좁혀 보려고 두 선물 호스트가 가리키는 IP 열두 개에 대해 이 PC에서 열려 있는 연결을 조회했더니 0건이었습니다. 다만 이것은 11시 36분 한 시점의 스냅샷이라 간헐적으로 붙었다 끊기는 연결까지 배제하지는 못합니다. 그러니 "남이 같이 쓰고 있다"가 아니라 "내가 쉬는 동안에도 선물 장부가 흘러가는 것이 관측된다"까지가 이번에 확인된 전부입니다.

이 관측이 실무에서 뜻하는 바는 분명합니다. 선물 쪽 상한이 분당 2,400인데 6.12초에 70에서 80이 늘었다면, 그 속도가 이어진다고 두고 분 단위로 늘려 볼 때 분당 686에서 784 가 됩니다. 이 두 숫자는 관측이 아니라 6초짜리 관측을 분 단위로 늘린 산술입니다. 그래도 머리글 값을 자기 호출 횟수로 환산해 쓰면 어긋난다는 것은 분명합니다. 남은 몫은 세어서 아는 것이 아니라 응답이 알려 주는 값을 읽어서 아는 것입니다.

창을 넘기면 어떤 응답이 오는지도 짧게 재 봤습니다

창이 1초에서 2초로 짧아 즉시 회복되는 두 창구에서만 경계를 넘겨 봤습니다. 11시 34분 36초부터 11시 34분 50초(KST) 입니다.

비트마트. 시세 한 종목 창구를 22번 연속 불렀습니다. 1번부터 15번까지는 HTTP 200이 왔고 X-BM-RateLimit-Remaining 이 1에서 15로 올라갔습니다. 16번째부터 22번째까지는 HTTP 429가 왔고 본문은 이랬습니다.

{"code":30013,"message":"(U)Request too many requests","trace":"08a9d887-6a50-43bd-ae8f-eb75a91c033a"}

그런데 거절된 일곱 번에도 Remaining 은 16, 17, 18, 19, 20, 21, 22로 계속 올라갔습니다. Limit 은 내내 15였고 Reset 은 2, Mode 는 IP 였습니다. Retry-After 머리글은 오지 않았습니다. 4초를 쉬고 세 번 부르니 전부 200이었고 Remaining 은 1, 2, 3으로 다시 시작했습니다.

이 이름의 정체는 비트마트 문서가 직접 적어 두었습니다. 표의 설명이 X-BM-RateLimit-Remaining 에 대해 The number of requests that have been used in the current time window 입니다. 이름은 남은 몫인데 뜻은 쓴 몫입니다. 문서의 예시도 그렇게 읽힙니다. X-BM-RateLimit-Remaining: 10 X-BM-RateLimit-Limit: 600 X-BM-RateLimit-Reset: 60 을 놓고 The above setting means that it can be called 600 times within 60 seconds, and currently has been called 10 times 라고 풀어 줍니다. 문서에는 경고도 붙어 있습니다. Note that when X-BM-RateLimit-Remaining> X-BM-RateLimit-Limit, please do not continue to call, otherwise it will be banned 입니다. 제 경우 넘긴 뒤 4초 만에 200이 돌아왔으므로 차단은 관측되지 않았습니다.

문서의 엔드포인트별 표도 응답과 맞았습니다. 시세 한 종목은 IP | 15 times/2 sec, 전 종목은 IP | 10 times/2 sec 이고, 실제로 전 종목 창구를 불렀을 때 Limit 이 10으로 왔으며 한 종목 창구와 따로 세었습니다.

비트겟. 같은 방식으로 30번을 약 2.3초 안에 몰아넣었는데 전부 200이었고 429는 오지 않았습니다. 대신 값이 이상하게 움직였습니다. 19, 19, 19, 19, 18, 18, 17, 17, 16, 19, 16, 19, 15, 15, 19로 이어졌습니다. 11시 34분 45초 004밀리초에 16이던 값이 71밀리초 뒤 19가 되고, 다시 71밀리초 뒤 16이 되고, 또 76밀리초 뒤 19가 됩니다. 카운터 하나로는 설명되지 않는 움직임입니다. 응답한 서버가 갈렸을 가능성이 떠오르지만 확인하지 못했습니다.

비트겟 문서 쪽도 갈래를 갈라 적습니다. 처음 값을 찾은 곳은 별도 도메인의 정적 문서이고 거기에는 Rate Limit: 20 times/1s (IP) 가 여러 번 나오며, 빈도 제한 표에는 /api/spot/v1/market/tickers 가 20c/1s 로 적혀 있습니다. 그런데 그 표는 v1 경로 기준이고 제가 부른 것은 v2 경로입니다. www.bitget.com/api-doc/common/rate-limit 을 비롯한 옛 주소 세 곳은 모두 HTTP 200에 응답이 23,627바이트로 똑같았고 태그를 걷어 낸 본문이 3,777자짜리 좌측 메뉴뿐이라, 여기서는 값을 읽을 수 없었습니다.

경로를 바꾸면 현행 문서가 서버 렌더로 열립니다. www.bitget.com/api-doc/classic/spot/market/Get-Tickers 가 GET /api/v2/spot/market/tickers 항목에 대해 Frequency limit: 20 times/1s (IP) 라고 적어 두었습니다. 곧 v1과 v2의 숫자가 같습니다. 제 머리글이 19에서 14 사이를 오간 것도 이 20이라는 선과 어긋나지 않습니다. 다만 그 값이 71밀리초 간격으로 16과 19를 오간 움직임은 여전히 설명되지 않습니다.

머리글을 주지 않은 일곱 창구 — 어디를 보고 무엇을 못 봤는지

머리글이 없다고 해서 한도가 없는 것은 아닙니다. 각 거래소 공식 문서를 11시 39분부터 11시 47분(KST) 사이에 직접 받아 확인했습니다. 대부분은 한도를 아주 구체적으로 적어 두었고, 다만 그 값을 응답으로 알려 주지 않을 뿐이었습니다.

바이비트. 문서가 두 층을 나눠 적습니다. IP 층은 You are allowed to send 600 requests within a 5-second window per IP by default. 이고, 넘기면 403, access too frequent 가 오며 you should terminate all HTTP sessions and wait for at least 10 minutes 라고 합니다. 그 위층은 다릅니다. The API rate limit is based on the rolling time window per second and UID. 이고 머리글 셋을 적어 두었습니다. X-Bapi-Limit-Status 는 남은 횟수, X-Bapi-Limit 은 현재 한도, X-Bapi-Limit-Reset-Timestamp 는 초기화 시각인데 설명에 단서가 붙습니다. Otherwise, this is just the current timestamp 입니다. 그런데 문서는 이 세 머리글을 소개하면서 Every request to the API returns response header shown in the code panel 이라고 적습니다. 모든 요청에 온다고 적어 두었는데 인증 없이 부른 제 응답에는 한 줄도 오지 않았습니다. 규칙 자체가 per second per UID 이니 계정이 붙어야 오는 값으로 읽히지만, 문서가 그런 단서를 달아 두지는 않았습니다. 그리고 저에게 실제로 걸리는 IP 층에는 머리글이 아예 없습니다.

OKX. 문서가 Public unauthenticated REST rate limits are based on IP address. 라고 갈래를 밝히고, 엔드포인트마다 값을 적어 둡니다. 제가 부른 시세 창구 항목에는 Rate Limit: 20 requests per 2 seconds 와 Rate limit rule: IP 가 나란히 적혀 있습니다. 넘기면 error code 50011 이 옵니다. 값도 기준도 문서에 있는데 응답에는 한 줄도 없습니다.

HTX. 문서가 머리글을 읽으라고 권합니다. It is suggested to read HTTP Header X-HB-RateLimit-Requests-Remain and X-HB-RateLimit-Requests-Expire to get the remaining count of request and the expire time for current rate limit time window 입니다. 그런데 제 응답에는 그 두 이름이 없었습니다. 같은 문서가 이유를 함께 적어 두었습니다. Only those endpoints marked with rate limit value separately are applied with new rate limit rule. 이고, 그 규칙은 applied on UID basis 입니다. 따로 표시된 엔드포인트에만, 그것도 계정 기준으로 적용됩니다.

MEXC. 문서가 기준을 나눕니다. The account is used as the basic unit of speed limit for the endpoints that need to carry access keys. For endpoints that do not need to carry access keys, IP addresses are used as the basic unit of rate limiting. 그리고 값을 못박습니다. Each endpoint with IP limits has an independent 500 every 10 second limit. 눈에 띄는 것은 그다음입니다. IP 차단을 설명하는 문단이 바이낸스 문서와 거의 같은 문장입니다. IP bans are tracked and scale in duration for repeat offenders, from 2 minutes to 3 days. 와 A Retry-After header is sent with a 418 or 429 responses 가 두 문서에 나란히 있습니다. 문장은 가져왔는데 머리글은 오지 않습니다.

크라켄. 여기는 구조가 다릅니다. Every REST API user has a "call counter" which starts at 0. 로 시작해 All other API calls increase this counter by 1 이고, 등급별로 최댓값과 줄어드는 속도가 정해집니다. 초보 등급은 15에 초당 0.33씩, 중간 등급은 20에 초당 0.5씩, 상위 등급은 20에 초당 1씩입니다. 핵심은 이 문장입니다. Each API key's counter is separate 입니다. 카운터가 API 키마다 도는 구조라서 키가 없는 호출에는 이 카운터가 걸리지 않고, 이 페이지에는 공개 호출의 한도가 적혀 있지 않았습니다. 대신 공개 호출은 크라켄의 다른 문서에 따로 적혀 있습니다. Calling the public endpoints at a frequency of 1 per second (or less) would remain within the rate limits 이고, 기준은 The Spot public endpoints are rate limited by IP address and currency pair for calls to Trades and OHLC, and by IP address only for calls to all other public endpoints. 입니다. 곧 제가 부른 시세 창구의 기준은 API 키가 아니라 IP 이고, 초당 1회가 문서가 그어 둔 선입니다.

데리비트. 신용 방식입니다. Each API request consumes a certain number of credits. 이고 채워지는 방식을 This refill acts like a leaky bucket 으로 설명합니다. 공개 호출에 대해서는 이렇게 적습니다. Public, non-authorized API requests are rate-limited on a per-IP basis—they do not draw from the sub-account-level credit pool. If an IP exceeds its public request allowance, subsequent calls may be temporarily rejected or the connection disconnected to protect platform stability. IP 기준이라는 것까지는 적혀 있는데 그 몫이 얼마인지는 적혀 있지 않고, 이 문서 안에서 머리글을 뜻하는 단어는 한 번도 나오지 않습니다.

코인베이스. 값은 문서에 있습니다. docs.cdp.coinbase.com/exchange/rest-api/rate-limits 가 Public endpoints are throttled by IP and private endpoints by profile ID. 로 갈래를 밝히고, 공개 엔드포인트에 대해 Requests per second per IP: 10 과 Requests per second per IP in bursts: Up to 15 를 적어 둡니다. 채우는 방식도 lazy-fill token bucket 이라고 설명하고, 넘기면 429 Too Many Requests 가 온다고 적습니다. 다만 이 값은 응답 머리글로 오지 않습니다.

이 값을 찾는 데 한 번 헛디딘 자리를 그대로 남깁니다. 개발자 문서의 다른 한도 페이지 주소는 HTTP 200에 858,448바이트가 왔지만 태그를 걷어 낸 본문이 2,565자뿐이라 좌측 내비게이션이었고, 짧은 쪽 주소는 404였으며, REST 요청 안내 문서는 1,618바이트로 잘 열렸는데 그 안에 한도를 뜻하는 문자열이 0건이었습니다. 문서 전체 목차 파일 99,978바이트 안에서 한도 문서로 보이는 줄은 여섯이었고 각각 코인베이스 앱, 어드밴스드 트레이드 웹소켓, 코인베이스 비즈니스, 인터내셔널 익스체인지, API v2 용이라 제가 부른 창구가 속한 제품의 한도 문서는 그 목차에 없었습니다. 목차에 없다는 것이 문서가 없다는 뜻은 아니었습니다. 주소를 하나 더 열자 값이 그대로 있었습니다.

정리하면 이렇습니다. 머리글을 주지 않은 일곱 창구 전부가 공식 문서에 한도 규정을 두고 있었습니다. 그 가운데 인증 없이 부르는 쪽에 걸리는 숫자까지 적어 둔 곳은 바이비트·OKX·MEXC·크라켄·코인베이스 다섯이었고, 데리비트는 IP 기준이라는 것까지만 밝힌 채 숫자를 적지 않았으며, HTX는 따로 표시된 엔드포인트에만 적용된다고 했습니다. 그리고 응답으로 오는 머리글 이름을 적어 둔 곳은 바이비트와 HTX 둘인데 그 둘 다 계정 쪽에 붙는 머리글이었습니다. 인증 없이 부르는 사람에게 실제로 걸리는 IP 몫은 대체로 응답에 실려 오지 않습니다.

창구별 머리글 이름·기준·창 길이·실측값 정리 표

같은 값을 다시 재실 수 있게 이번에 쓴 이름과 기준, 창 길이, 실측값을 한 표에 모았습니다. 기준과 문서 값은 각 공식 문서에서 옮긴 것이고, 창 길이와 실측값은 제가 잰 것입니다. 한도의 셈 단위가 창구마다 다르므로 숫자만 세로로 비교하지 마십시오. 바이낸스는 무게, 쿠코인은 풀 안의 무게, 나머지는 횟수입니다.

이 조회의 한계와 확인하지 못한 것

• 인증했을 때의 값 전부. 이 노트는 인증 헤더를 한 번도 붙이지 않았습니다. 등급별 한도와 계정 기준 한도는 문서 인용까지이고 실측하지 않았습니다. 쿠코인 문서의 4,000도 여기에 해당합니다.
• 선물 장부가 유휴 중에 흘러간 원인. 후보 셋 가운데 하나만 스냅샷으로 좁혔고, 그 스냅샷도 한 시점의 것입니다.
• 바이낸스의 경계. 문서가 최대 사흘짜리 IP 차단을 명시해 넘겨 보지 않았습니다. 넘겼을 때의 응답 모양은 이번에 재지 않았습니다.
• 비트겟 머리글 값이 오르내린 원인. 같은 초 안에서 16과 19를 71밀리초 간격으로 오간 이유는 좁히지 못했습니다.
• 게이트 문서 사이트의 오늘자 라이브 원문. 라이브 주소는 오늘도 403이라 인터넷 아카이브 스냅샷으로 축자 확인했습니다. 스냅샷 두 개의 Frequency limit rule 표가 서로 같았지만, 오늘 시각의 라이브 원문 자체를 본 것은 아닙니다.
• 게이트 저장소 README 의 900이 언제부터 낡았는지. 현행 문서 표기가 200r/10s per endpoint 라는 것까지는 확인했지만, 저장소 표가 갱신되지 않은 시점은 이 노트에서 확인하지 않았습니다.
• 머리글이 없다는 범위. 이 열두 거래소의 공개 시세 응답 머리글에 없다는 뜻입니다. 인증 엔드포인트에는 있을 수 있고, 바이비트와 HTX 문서는 그 이름을 실제로 적어 두었습니다.
• 값의 유효 기간. 위 숫자는 2026년 8월 19일 오전 한국 시각에 한 회선에서 잰 한 번의 기록입니다. 각 거래소가 언제든 바꿀 수 있는 값입니다.

지금 확인해 볼 수 있는 여섯 단계 자가 점검

1. 응답 머리글을 한 번이라도 찍어 보셨습니까. 본문만 파싱하고 머리글을 버리면 남은 몫을 알려 주는 창구에서도 못 읽습니다. 이번 열네 창구 중 일곱은 요청할 때마다 그 값을 보내고 있었습니다.
2. 그 이름이 쓴 몫인지 남은 몫인지 확인하셨습니까. 비트마트의 Remaining 은 문서가 직접 have been used 라고 적은 값이고, 실제로 1에서 22까지 올라갔습니다. 이름만 보고 부호를 반대로 읽으면 정확히 거꾸로 관리하게 됩니다.
3. 한도의 셈 단위가 횟수인지 무게인지 아십니까. 바이낸스는 무게이고 파라미터 하나로 5에서 250까지 갑니다. 횟수만 세면 5000단 호가를 부르는 순간 계산이 어긋납니다.
4. 창이 몇 초짜리인지 재 보셨습니까. 게이트는 약 10초, 쿠코인은 30초, 비트마트는 2초, 바이낸스는 1분이었습니다. 그리고 쿠코인의 창은 벽시계가 아니라 내 첫 요청에서 시작합니다.
5. 한 풀을 나눠 쓰는지 엔드포인트마다 따로인지 아십니까. 쿠코인은 세 엔드포인트가 한 잔량에서 이어 깎였고, 게이트는 같은 창 안에서 두 엔드포인트가 각각 199였습니다. 반대로 알고 있으면 한쪽에서 예상보다 훨씬 빨리 막힙니다.
6. 머리글이 없는 창구의 한도를 문서에서 확인해 두셨습니까. 없다고 무제한이 아닙니다. 이번 일곱 곳은 전부 문서에 한도 규정이 있었고 그중 다섯은 인증 없이 부르는 쪽의 숫자까지 적어 두었습니다. 그 숫자를 모르면 429가 오고 나서야 알게 됩니다. 한 주소에서 못 찾았다고 없다고 적으면 안 된다는 것도 이번에 겪었습니다. 응답이 정상으로 오는데도 조용히 잘려서 오는 자리가 있다는 점은 코인 마진 차입 이자율을 잰 노트에서도 다뤘습니다.

FAQ

Q. 머리글이 없는 거래소는 한도가 없다는 뜻인가요? A. 아닙니다. 이번에 머리글을 주지 않은 일곱 창구는 전부 공식 문서에 한도 규정을 두고 있었고, 그 가운데 다섯은 인증 없이 부르는 쪽에 걸리는 숫자까지 적어 두었습니다. 바이비트는 IP 기준 5초에 600회, OKX는 제가 부른 시세 창구에 2초에 20회, MEXC는 IP 기준 엔드포인트마다 10초에 500회, 크라켄은 공개 호출에 초당 1회, 코인베이스는 IP 기준 초당 10회에 버스트 15회입니다. 다만 그 값을 응답으로 알려 주지 않기 때문에 부르는 쪽에서 직접 세어 두셔야 합니다. 데리비트만은 공개 호출이 IP 기준이라는 것까지만 적고 숫자를 적지 않았습니다.

Q. API 키를 하나 더 만들면 한도가 두 배가 되나요? A. 기준이 무엇인지에 달렸습니다. 바이낸스 문서는 The limits on the API are based on the IPs, not the API keys. 라고 못박아 두었으므로, 같은 회선에서 부르는 한 키를 늘려도 같은 장부입니다. 반대로 크라켄은 Each API key's counter is separate 라고 적어 두었으니 그쪽은 키마다 따로입니다. 쿠코인은 공개 창구는 IP, 나머지는 계정 기준으로 문서가 갈래를 적어 두었습니다. 거래소마다 답이 다르므로 하나의 답을 옮겨 쓰면 안 됩니다.

Q. 게이트 저장소 문서에는 900이라고 적혀 있는데 왜 200만 오나요? A. 문서를 하나 더 열어 보셔야 합니다. 게이트 현행 공식 API v4 문서는 모든 공개 엔드포인트를 200r/10s per endpoint, 기준을 IP 로 적어 두었고 제가 받은 값과 창 길이가 여기에 그대로 맞았습니다. 900은 공식 저장소 gateio/rest-v4 README 의 성능 표에 남아 있는 숫자이고, 같은 칸의 기준도 API Key 로 적혀 있습니다. 곧 900과 200은 어긋난 두 값이 아니라 서로 다른 문서의 표기이고, 지금 응답에 걸리는 값은 200 쪽입니다. 저장소 README 만 읽고 45배가 벌어졌다고 적으면 틀립니다.

Q. 쿠코인 문서의 4,000과 머리글의 2,000 중 어느 쪽이 맞나요? A. 둘 다 맞습니다. 서로 다른 자원 풀의 값이기 때문입니다. 4,000은 표의 현물 열, 2,000은 같은 표의 맨 끝 공개 열입니다. 인증 없이 시세를 부르는 경우에는 공개 열이 내 몫이고, 그 값은 VIP0부터 VIP12까지 전 등급에서 2000/30s 로 같습니다. 등급을 올려도 공개 창구 쪽은 그대로라는 뜻입니다.

Q. 429가 왔을 때 몇 초를 쉬어야 하나요? A. 창구가 알려 주면 그 값을 쓰고, 안 알려 주면 창 길이를 쉬는 편이 안전합니다. 바이낸스와 MEXC 문서는 A Retry-After header is sent with a 418 or 429 responses 라고 적어 두었습니다. 반면 이번에 실제로 429를 받아 본 비트마트 응답에는 Retry-After 가 없었고, 대신 X-BM-RateLimit-Reset 이 2였습니다. 저는 4초를 쉬었고 그 뒤 정상 응답이 돌아왔습니다. 거절 응답에서 쉴 시간을 못 찾으셨다면 그 창구의 창 길이만큼 쉬는 것이 최소선입니다.

Q. 내 호출 횟수만 세어서 관리해도 되나요? A. 그렇게 관리하시면 어긋나는 경우가 있습니다. 이번 조회에서 바이낸스 선물 장부는 제가 6.12초 동안 아무 요청도 보내지 않았는데 70에서 80이 늘어났습니다. 같은 구간에 현물 장부도 4씩 늘었습니다. 원인은 확인하지 못했지만, 원인을 몰라도 대응은 같습니다. 머리글을 주는 창구라면 응답이 알려 주는 값을 매번 읽어서 판단하시는 편이 자기 계산기보다 정확합니다.

Q. 호가를 깊게 받는 것이 그렇게 비싼가요? A. 바이낸스 기준으로는 그렇습니다. 이번에 직접 재 보니 5단과 100단은 둘 다 5인데 500단은 25, 1000단은 50, 5000단은 250이었고 문서 표와 정확히 같았습니다. 현물 상한이 1분에 6000이므로 5000단만 부르면 1분에 24번이 한계입니다. 100단으로 충분한 자리에서 5000단을 부르고 계시다면 그 한 줄만 고쳐도 무게가 50분의 1이 됩니다. 응답에 담기는 시각 필드를 함께 저장해 두는 습관은 코인 거래소 서버 시간을 잰 노트에 정리해 두었습니다.

Q. 같은 거래소인데 현물과 선물을 따로 세도 되나요? A. 바이낸스는 현물과 선물이 따로였습니다. 다만 USDT 선물과 코인 선물은 하나의 장부였습니다. 두 호스트를 번갈아 불렀는데 값이 301, 302, 303, 304, 305로 끊기지 않고 이어졌습니다. 그러니 장부는 셋이 아니라 둘로 두고 관리하셔야 합니다. 반대로 게이트는 같은 현물 안에서도 엔드포인트마다 잔량이 따로 돌았습니다.

함께 보면 좋은 글

• 코인 과거 시세 데이터 소급 한계를 잰 노트: 한 번에 받아지는 개수가 창구마다 갈리고, 한도를 넘겨 넣어도 오류가 아니라 조용히 잘려 오는 자리를 다룹니다.
• 코인 거래소 서버 시간을 잰 노트: 응답 안의 시각 필드가 초·밀리초·마이크로초·나노초로 갈리는 사정과 요청 타임스탬프 허용 창을 정리했습니다.
• 거래소 보험기금 풀 구조를 잰 노트: 같은 이름의 값이 창구마다 다른 것을 가리키는 자리를 다룹니다.

데이터·개념 출처

본 노트의 수치는 2026년 8월 19일에 직접 호출해 받은 응답을 읽은 것입니다. 호출 시각은 여덟 덩어리입니다. 창구 열네 곳 다섯 회전 전수 조사가 11시 25분 56초부터 11시 26분 10초(KST, 협정세계시 2시 25분), 창구별 버스트가 11시 27분 38초부터 11시 27분 59초, 바이낸스 가중치 측정이 11시 28분 57초부터 11시 29분 03초, 게이트 창 길이 폴링이 11시 30분 09초부터 11시 30분 54초, 쿠코인 창 폴링이 11시 31분 32초부터 11시 32분 12초, 선물 장부 대조가 11시 32분 26초부터 11시 32분 32초, 유휴 대조가 11시 33분 13초부터 11시 33분 35초, 경계 초과 재현이 11시 34분 36초부터 11시 34분 50초입니다. 두 번째 엔드포인트 확인은 11시 44분 23초 입니다. 전부 인증 헤더 없이 부른 공개 호출입니다.

부른 주소는 본문 표에 적은 열네 개 공개 시세 엔드포인트와, 가중치를 재는 데 쓴 바이낸스 현물의 ping·depth·ticker/price·ticker/24hr·exchangeInfo·trades·klines, 그리고 창 길이를 재는 데 쓴 게이트 현물 시세와 호가, 게이트 무기한 선물 시세, 쿠코인 24시간 통계와 심볼 목록과 호가 1단, 비트마트 시세 두 종, 비트겟 시세입니다. 증가분·간격·차감폭은 모두 응답을 받은 스크립트 안에서 계산했습니다.

문서 문구는 각 거래소 공식 문서를 2026년 8월 19일 11시 39분부터 11시 47분(KST) 사이에 직접 받아 축자로 확인했고, 게이트 공식 API v4 문서와 코인베이스·크라켄·비트겟의 아래 주소는 같은 날 16시 40분대(KST) 에 다시 받아 축자로 대조했습니다. 바이낸스는 공식 저장소의 rest-api.md(181,189바이트)의 ## LIMITS 절에서 옮겼습니다. 같은 내용을 싣는 문서 사이트 주소는 HTTP 202에 2,040바이트만 와서 본문을 받지 못했고, 그래서 저장소 원본으로 대체했습니다. 쿠코인은 www.kucoin.com/docs-new/rate-limit(496,747바이트)의 자원 풀 표와 여섯 항목에서 옮겼습니다. 게이트는 두 문서를 함께 씁니다. 900r/s | API Key 는 공식 저장소 rest-v4 의 README(4,464바이트)의 API Performance 표에서, 200r/10s per endpoint | IP 와 세 머리글 설명은 게이트 공식 API v4 문서 www.gate.com/docs/developers/apiv4/en/ 에서 옮겼습니다. 이 문서 사이트는 브라우저 문자열을 붙여도 라이브 주소가 HTTP 403이라 인터넷 아카이브에 남은 2026년 6월 6일과 2025년 10월 16일 스냅샷 둘을 받아 축자로 대조했고, 두 스냅샷의 Frequency limit rule 표와 머리글 설명이 서로 같았습니다.

비트겟은 v1 표기를 bitgetlimited.github.io/apidoc/en/spot/(611,442바이트)에서, v2 경로 값을 www.bitget.com/api-doc/classic/spot/market/Get-Tickers(38,423바이트)에서 옮겼습니다. 크라켄은 카운터 구조를 docs.kraken.com/exchange/guides/rest/ratelimits(371,160바이트)에서, 공개 호출 한도를 support.kraken.com/articles/206548367-what-are-the-api-rate-limits- 에서 옮겼습니다. 코인베이스는 docs.cdp.coinbase.com/exchange/rest-api/rate-limits(마크다운 판 3,924바이트)에서 옮겼고, 그 전에 헛디딘 네 주소와 각 응답 크기는 본문 해당 절에 그대로 남겼습니다. 비트마트는 developer-pro.bitmart.com/en/spot/(614,112바이트), 바이비트는 bybit-exchange.github.io/docs/v5/rate-limit(61,808바이트), OKX는 www.okx.com/docs-v5/en/(5,242,376바이트), MEXC는 mexcdevelop.github.io/apidocs/spot_v3_en/(445,494바이트), HTX는 huobiapi.github.io/docs/spot/v1/en/(830,811바이트), 데리비트는 docs.deribit.com/articles/rate-limits.md(20,202바이트)에서 옮겼습니다.

이 글은 공개 API 응답과 개발자 문서를 정리한 정보 제공 목적의 자료이며 특정 종목이나 거래소의 이용을 권하는 글이 아닙니다. 본 노트는 진입가나 정리 가격을 제시하지 않고, 어떤 자산도 매수 또는 매도 대상으로 지목하지 않으며, 어느 창구가 더 낫다는 판단도 하지 않습니다. 가상자산은 원금 손실이 발생할 수 있습니다. 위 머리글 값과 창 길이는 특정 시각에 특정 회선에서 잰 한 번의 스냅샷이라 다시 부르시면 달라질 수 있고, 각 거래소가 언제든 바꿀 수 있는 값이라 이후에도 같은 자리에 있는지는 이 글에서 확인하지 않았습니다. 투자 판단과 그 결과는 전적으로 본인 책임입니다.