altnara 자금흐름 데스크는 파생시장의 구조 값을 점검합니다. 이번 노트의 주제는 리스크 한도 구간입니다. 운영자 보유 가능성: 본 매체는 비트코인·주요 알트 및 스테이블코인 보유 가능성을 명시합니다.
거래소 선물 화면 맨 위에는 대체로 배수 하나가 크게 걸려 있습니다. 그런데 그 숫자는 조건 없이 주어지는 값이 아닙니다. 포지션이 일정 금액을 넘어서면 같은 계정에서도 그 배수를 더는 고를 수 없습니다. 그 경계를 정해 놓은 표를 리스크 한도 구간, 또는 포지션 티어라고 부릅니다.
이 글에서 말하는 배수는 전부 레버리지 설정값을 가리킵니다. 수익률이나 수익 배수를 뜻하지 않습니다.
아래 수치는 다섯 거래소의 공개 API를 한 스크립트 안에서 연속 호출해 같은 초 안에 받은 응답입니다. 측정 창은 2026년 8월 10일 13시 41분 07초부터 13시 41분 08초(KST) 이고, 전부 BTC-USDT 무기한 계약·기본 계정 등급 기준입니다. 마진 모드는 다섯 곳 가운데 OKX만 요청 파라미터로 받아 tdMode=cross로 지정했고, 나머지 네 곳의 엔드포인트에는 마진 모드를 넣을 자리가 없어 심볼 기본 응답을 그대로 받았습니다.
결론부터 — 광고된 최고 배수는 첫 구간 안에서만 유효합니다
먼저 확인할 것은 세 가지입니다. 그 배수가 유효한 첫 구간의 상한이 얼마인지, 그 상한이 달러로 매겨져 있는지 계약 수로 매겨져 있는지, 그리고 구간이 몇 개로 쪼개져 있는지입니다.
측정 결과 첫 구간의 크기는 20만 USDT에서 200만 USDT까지 열 배 벌어져 있었습니다. 같은 배수를 내걸어도 그 배수를 유지할 수 있는 금액이 전혀 다르다는 뜻입니다.
기준가부터 적어 둡니다. 같은 창 안에서 바이낸스 markPrice는 64,897.69268116, indexPrice는 64,936.61608696이었고, OKX markPx는 64,898.8, 게이트 mark_price는 64,901.2, index_price는 64,929.54였습니다.
같은 시각, 다섯 거래소의 첫 구간
응답이 돌려준 1구간 값만 뽑아 정렬했습니다.
| 거래소 | 응답의 1구간 상한 | USDT 환산 | 그 구간 최고 배수 | 유지증거금률 | 전체 구간 수 |
|---|---|---|---|---|---|
| 비트겟 | endUnit 200,000 | 200,000 | 150 | 0.40% | 12 |
| 바이낸스 | bracketNotionalCap 300,000 | 300,000 | 150 | 0.40% | 12 |
| 게이트 | risk_limit 500,000 | 500,000 | 200 | 0.30% | 19 |
| OKX | maxSz 1,000 계약 | 648,988 | 100 | 0.40% | 99 |
| 바이비트 | riskLimitValue 2,000,000 | 2,000,000 | 100 | 0.50% | 35 |
읽히는 것이 두 가지입니다.
첫째, 최고 배수가 같아도 첫 구간의 크기가 다릅니다. 바이낸스와 비트겟은 둘 다 150배를 내걸지만 그 배수가 살아 있는 구간은 30만과 20만 USDT로 1.5배 차이입니다. 바이비트와 OKX는 둘 다 100배인데 첫 구간은 200만과 약 65만 USDT로 세 배 넘게 벌어집니다.
둘째, 첫 구간의 유지증거금률도 0.30%에서 0.50%까지 갈립니다. 게이트가 0.30%로 가장 낮고 바이비트가 0.50%로 가장 높았습니다. 초기증거금률까지 응답에 실어 주는 곳은 세 곳이었는데, 바이비트 initialMargin 0.01, OKX imr 0.01, 게이트 initial_rate 0.005였습니다.
OKX만 한도를 계약 수로 매깁니다
표에서 OKX 한 줄만 굵게 표시한 이유가 여기 있습니다. 다른 네 곳은 구간 경계를 달러 금액으로 돌려주는데 OKX는 계약 개수로 돌려줍니다.
OKX 공식 문서의 Get position tiers 절은 maxSz를 "The maximum borrowing amount or number of positions held in this position is only applicable to margin/options/perpetual/delivery"라고 적습니다. 같은 문서의 Get instruments 절은 lotSz와 minSz에 대해 "If it is a derivatives contract, the value is the number of contracts"라고 못박습니다. 파생 계약에서 수량 단위가 계약 수라는 뜻입니다.
그래서 계약 하나의 크기를 따로 받아야 합니다. 같은 창에서 받은 GET /api/v5/public/instruments 응답의 ctVal은 0.01, ctValCcy는 BTC, ctMult는 1이었습니다. 계약 하나가 0.01 BTC라는 뜻입니다.
곱하면 이렇게 됩니다.
- 1구간 상한: 1,000계약 × 0.01 BTC × 64,898.8 = 648,988 USDT
- 2구간 상한: 5,000계약 × 0.01 BTC × 64,898.8 = 3,244,940 USDT
- 99구간 상한: 1,940,000계약 × 0.01 BTC × 64,898.8 = 1,259,036,720 USDT
이 곱셈을 빠뜨리면 표가 통째로 틀립니다. 1,000이라는 숫자를 달러로 읽으면 OKX의 첫 구간이 다섯 곳 중 압도적으로 작아 보이는데, 실제로는 게이트보다 크고 바이비트보다 작습니다. 그리고 계약 값이 BTC로 매겨져 있으므로 BTC 가격이 오르면 OKX의 달러 한도는 저절로 따라 움직입니다. 나머지 네 곳의 달러 경계는 가격이 움직여도 그대로입니다.
게이트는 세 값으로 답하던 자리를 폐기 예정으로 표시해 두었습니다
게이트 계약 정보 엔드포인트는 리스크 한도를 배열이 아니라 세 값으로 돌려줍니다. 이번 응답에서 risk_limit_base는 500,000, risk_limit_step은 1,499,500,000, risk_limit_max는 1,500,000,000이었습니다.
이 세 값만 읽고 표를 만들면 어긋납니다. 게이트 공식 SDK의 Contract 모델 문서는 세 필드에 모두 deprecated 표기를 붙였고, RiskLimitMax 설명에는 "It is recommended to use ... risk_limit_tiers to query risk limits"라고 대체 경로까지 적어 두었습니다. 원문에서 생략 부호 자리에는 정산 통화를 넣는 자리표시자가 들어가고, USDT 마진 계약이면 그 자리에 usdt 가 들어갑니다.
그래서 그 경로를 실제로 호출했습니다. GET https://api.gateio.ws/api/v4/futures/usdt/risk_limit_tiers?contract=BTC_USDT 는 길이 19의 배열을 돌려줍니다. 1구간은 risk_limit 500,000 · leverage_max 200 · maintenance_rate 0.003 · deduction 0이고, 19구간은 risk_limit 1,500,000,000 · leverage_max 1.05 · maintenance_rate 0.5입니다.
두 응답을 겹쳐 보면 무엇이 사라졌는지 정확히 보입니다. 폐기 예정 필드의 risk_limit_base 500,000은 티어 배열 1구간과 같고, risk_limit_max 1,500,000,000은 19구간과 같습니다. risk_limit_base + risk_limit_step을 더하면 정확히 risk_limit_max가 나옵니다. 즉 세 값은 19구간 가운데 처음과 끝만 알려 주고 중간 17구간을 통째로 감춥니다.
구간 개수가 12개에서 99개까지 갈립니다
같은 자산, 같은 상품인데 표의 해상도가 다릅니다.
| 거래소 | 구간 수 | 마지막 구간 상한 | 마지막 구간 최고 배수 | 마지막 구간 유지증거금률 |
|---|---|---|---|---|
| 바이낸스 | 12 | 1,800,000,000 USDT | 1 | 50% |
| 비트겟 | 12 | 1,200,000,000 USDT | 1 | 60% |
| 게이트 | 19 | 1,500,000,000 USDT | 1.05 | 50% |
| 바이비트 | 35 | 1,200,000,000 USDT | 1 | 60% |
| OKX | 99 | 1,940,000계약 | 2 | 48.75% |
구간이 많다는 것은 배수와 요율이 더 잘게 바뀐다는 뜻입니다. OKX의 99구간은 3구간 상한인 2만 계약을 지나면 마지막까지 상한이 2만 계약씩 일정하게 올라갑니다. 인접한 두 상한의 간격 98개 가운데 96개가 2만 계약이고, 나머지 둘은 1·2구간 사이의 4천 계약과 2·3구간 사이의 1만 5천 계약이라 앞쪽에서 한 번 넓어진 뒤로는 폭이 변하지 않습니다. 반대로 바이낸스와 비트겟의 12구간은 구간마다 폭이 크게 달라집니다.
명목 120만 USDT 한 자리에 다섯을 세워 보면
구간표를 나란히 놓는 것보다 같은 명목금액을 정해 놓고 그 자리에서 각 거래소가 무엇을 허용하는지 보는 편이 비교가 됩니다. 명목 1,200,000 USDT로 잡았습니다. 어느 거래소의 구간 경계와도 겹치지 않는 값이라 판정이 갈리지 않습니다. OKX는 계약으로 환산하면 1,200,000 ÷ 64,898.8 ÷ 0.01 = 1,849.03계약입니다.
| 거래소 | 그 자리의 구간 | 구간 최고 배수 | 유지증거금률 | 공제항 | 요구 유지증거금 |
|---|---|---|---|---|---|
| 게이트 | 3구간 (상한 1,500,000) | 125 | 0.40% | 750 | 4,050 USDT |
| 바이비트 | 1구간 (상한 2,000,000) | 100 | 0.50% | 없음 | 6,000 USDT |
| OKX | 2구간 (1,000.01~5,000계약) | 66.66 | 0.50% | 필드 없음 | 6,000 USDT |
| 바이낸스 | 3구간 (800,000~3,000,000) | 75 | 0.65% | 1,500 | 6,300 USDT |
| 비트겟 | 3레벨 (1,000,000~5,000,000) | 75 | 0.70% | 필드 없음 | 8,400 USDT |
같은 금액인데 고를 수 있는 최고 배수가 66.66에서 125까지, 요구되는 유지증거금이 4,050에서 8,400 USDT까지 벌어집니다. 최대와 최소의 비는 약 2.07배입니다. 첫 화면에 걸린 배수만 보고 두 거래소를 같은 조건으로 취급하면 이 차이가 통째로 사라집니다.
요구 유지증거금은 각 거래소가 공표한 요율과 공제항만으로 계산한 값입니다. 실제 청산 판정에 다른 항목이 더 들어가는지는 이 글에서 확인하지 않았고, 청산가 산식 자체도 이 노트의 범위 밖입니다. 청산 판정에 쓰이는 가격이 어느 값인지는 청산은 어느 값으로 계산되는가 노트에서 따로 확인했습니다. 같은 시각 같은 종목인데 거래소마다 값이 갈리는 구조는 무기한 선물 펀딩비 보는 법 노트에서도 같은 방식으로 재 봤습니다.
구간은 계단이 아니라 연속으로 이어져 있습니다
표만 보면 구간을 넘는 순간 요율이 툭 튀는 것처럼 보입니다. 그런데 응답에는 그 계단을 메우는 필드가 하나 더 있습니다.
- 바이비트
mmDeduction— 공식 문서 설명은 "The maintenance margin deduction value when risk limit tier changed" - 게이트
deduction— 공식 SDK 문서 설명은 "Maintenance margin quick calculation deduction amount" - 바이낸스
cumFastMaintenanceAmount
이 값이 실제로 계단을 메우는지 직접 계산해 봤습니다. 이웃한 두 구간의 경계 금액에 대해 경계금액 × 그 구간 요율 − 그 구간 공제항을 앞뒤 구간으로 각각 계산해 비교하는 방식입니다.
- 바이비트 1·2구간 경계 2,000,000: 2,000,000 × 0.005 − 0 = 10,000, 2,000,000 × 0.0056 − 1,200 = 10,000
- 게이트 2·3구간 경계 1,000,000: 1,000,000 × 0.0035 − 250 = 3,250, 1,000,000 × 0.004 − 750 = 3,250
- 바이낸스 1·2구간 경계 300,000: 300,000 × 0.004 − 0 = 1,200, 300,000 × 0.005 − 300 = 1,200
세 거래소의 모든 경계로 확장해 돌린 결과 바이낸스 11개, 바이비트 34개, 게이트 18개, 합계 63개 경계 전부에서 두 값이 일치했습니다(허용 오차 1e-6, 불일치 0건). 요율이 계단으로 올라가도 실제 요구 금액은 경계에서 끊기지 않는다는 뜻입니다.
OKX와 비트겟 응답에는 이 공제항에 해당하는 필드가 없었습니다. 다만 이것은 "그 거래소가 공제를 하지 않는다"는 뜻이 아니라 "이 엔드포인트 응답에 그 필드가 없다"는 뜻입니다. 두 문장은 다르고, 이 글이 확인한 것은 뒤쪽입니다.
바이낸스는 문서화된 창구가 인증을 요구합니다
바이낸스 공개 문서에 실린 브래킷 조회 경로는 인증 없이는 열리지 않습니다. GET https://fapi.binance.com/fapi/v1/leverageBracket?symbol=BTCUSDT 를 그대로 부르면 HTTP 401과 함께 본문에 "code": -2014 와 "msg": "API-key format invalid." 가 담겨 돌아옵니다. 브라우저 UA를 붙여 다시 시도해도 같았습니다.
여기서 멈추고 "바이낸스는 확인할 수 없다"로 적을 수도 있었습니다. 그런데 경로를 몇 개 더 두드려 보니 웹 프런트엔드가 쓰는 경로 하나가 인증 없이 열렸습니다. GET https://www.binance.com/bapi/futures/v1/friendly/future/common/brackets 는 HTTP 200과 함께 989개 심볼의 브래킷 배열을 돌려줍니다. 같은 계열의 .../v1/public/future/common/brackets 는 HTTP 400이었습니다.
그 응답 안 BTCUSDT 항목은 12구간이고, 1구간이 bracketNotionalCap 300,000 · bracketMaintenanceMarginRate 0.004 · maxOpenPosLeverage 150입니다. updateTime은 1755585384254, 사람이 읽는 시각으로 2025년 8월 19일 15시 36분(KST)입니다. 브래킷 표 자체는 거의 1년 동안 갱신되지 않았다는 뜻이지만, 언제든 바뀔 수 있는 값이므로 인용할 때는 받은 시각을 함께 적는 편이 안전합니다.
한 가지는 분명히 해 둡니다. 이 경로의 필드 정의를 담은 바이낸스 공식 문서는 이번 조사에서 찾지 못했습니다. 값은 응답 그대로 옮겼지만, 문서화된 창구가 인증을 요구한다는 사실과 인증 뒤의 값이 계정마다 다른지 여부는 확인되지 않는다는 점을 함께 적어 둡니다.
직접 재 보실 때 부를 창구
이 글이 부른 경로를 그대로 남겨 둡니다. 다섯 곳 모두 인증 없이 응답이 옵니다.
- 바이비트:
GET https://api.bybit.com/v5/market/risk-limit?category=linear&symbol=BTCUSDT - OKX:
GET https://www.okx.com/api/v5/public/position-tiers?instType=SWAP&tdMode=cross&instFamily=BTC-USDT그리고 계약 단위는GET https://www.okx.com/api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP - 비트겟:
GET https://api.bitget.com/api/v2/mix/market/query-position-lever?symbol=BTCUSDT&productType=USDT-FUTURES - 게이트:
GET https://api.gateio.ws/api/v4/futures/usdt/risk_limit_tiers?contract=BTC_USDT - 바이낸스: 문서화된 경로는 인증이 필요하고, 위에 적은 웹 프런트엔드 경로가 인증 없이 열립니다
기준가는 GET https://fapi.binance.com/fapi/v1/premiumIndex?symbol=BTCUSDT 와 GET https://www.okx.com/api/v5/public/mark-price?instType=SWAP&instId=BTC-USDT-SWAP 로 받았습니다.
다섯 곳 모두 해외 거래소입니다. 국내 원화 거래소가 무기한 선물을 취급하는지, 취급한다면 그 리스크 한도가 어떤지는 이 글에서 확인하지 않았습니다.
리스크 한도 구간 자가 점검 7단계
- 지금 보는 최고 배수가 몇 번째 구간의 값인지 확인하셨습니까.
- 그 구간의 상한 금액을 적어 두셨습니까.
- 그 상한이 달러 금액인지 계약 수인지 확인하셨습니까. 계약 수라면 계약 단위를 곱하셨습니까.
- 값을 받은 엔드포인트가 폐기 예정 필드가 아닌지 확인하셨습니까.
- 그 값을 받은 엔드포인트가 마진 모드를 구분하는지, 어느 심볼인지, 어느 계정 등급인지 적어 두셨습니까.
- 응답에 공제항 필드가 있는지 확인하셨습니까. 없다면 없는 것으로 단정하지 말고 없다고만 적으셨습니까.
- 값을 인용할 때 받은 시각과 기준가를 함께 남기셨습니까.
FAQ
Q. 리스크 한도 구간이 무엇인가요? A. 포지션 크기에 따라 고를 수 있는 최고 레버리지와 적용되는 유지증거금률을 구간별로 정해 둔 표입니다. 거래소마다 부르는 이름이 달라 바이비트는 risk limit, OKX는 position tier, 비트겟은 position tier, 게이트는 risk limit tier, 바이낸스는 bracket이라고 씁니다. 이 글은 BTC-USDT 무기한 계약·기본 계정 등급 기준으로 다섯 곳을 2026년 8월 10일 13시 41분(KST)에 같은 창에서 재 봤습니다. 마진 모드를 요청 파라미터로 받는 곳은 OKX뿐이라 그곳만 교차로 지정했고, 나머지 네 곳은 심볼 기본 응답입니다.
Q. 거래소가 내건 최고 배수는 언제까지 유효한가요? A. 첫 구간 안에서만 유효합니다. 측정 시각 기준으로 첫 구간의 상한은 비트겟 200,000 USDT, 바이낸스 300,000 USDT, 게이트 500,000 USDT, OKX 약 648,988 USDT 환산, 바이비트 2,000,000 USDT였습니다. 최소와 최대가 열 배 벌어집니다.
Q. OKX 값이 다른 거래소보다 훨씬 작아 보입니다.
A. 단위가 다르기 때문입니다. OKX는 구간 경계를 계약 수로 돌려주고, 같은 시각 BTC-USDT-SWAP의 ctVal은 0.01 BTC였습니다. 1,000계약에 0.01과 마크가격 64,898.8을 곱해야 648,988 USDT라는 달러 값이 나옵니다. 이 곱셈을 빠뜨리면 표가 통째로 틀립니다.
Q. 게이트의 risk_limit_base·step·max 세 값으로 표를 만들면 되나요? A. 그 세 필드는 게이트 공식 SDK 문서에 deprecated로 표기돼 있고, 문서가 티어 조회 엔드포인트를 대신 쓰라고 적어 두었습니다. 실제로 티어 엔드포인트는 19구간을 돌려주는데, 세 값은 그중 처음(500,000)과 끝(1,500,000,000)만 재구성할 수 있어 중간 17구간이 사라집니다.
Q. 구간을 넘으면 유지증거금이 갑자기 뛰나요?
A. 요율은 계단으로 올라가지만 요구 금액은 경계에서 이어집니다. 바이비트 mmDeduction, 게이트 deduction, 바이낸스 cumFastMaintenanceAmount가 그 차이를 메웁니다. 세 거래소의 경계 63개 전부에서 앞 구간과 뒤 구간의 계산 결과가 일치했습니다. 다만 이 계산은 각 거래소가 공표한 요율과 공제항만 쓴 것이고, 실제 청산 판정에 다른 항목이 들어가는지는 확인하지 않았습니다.
Q. OKX와 비트겟에는 공제항이 없나요? A. 이 글이 호출한 두 엔드포인트의 응답에 그 필드가 없었습니다. 그 거래소가 공제를 적용하지 않는다는 뜻은 아닙니다. 응답에 없는 것과 제도상 없는 것은 다른 문장이고, 이 글이 확인한 것은 앞쪽뿐입니다.
Q. 바이낸스 브래킷은 왜 표에서 별도로 다뤘나요?
A. 문서화된 경로 /fapi/v1/leverageBracket 가 인증을 요구해 HTTP 401과 함께 "code": -2014 · "msg": "API-key format invalid." 를 돌려주기 때문입니다. 이 글은 웹 프런트엔드가 쓰는 다른 경로에서 인증 없이 같은 성격의 배열을 받아 값을 옮겼고, 그 경로의 필드 정의를 담은 공식 문서는 찾지 못했습니다. 인증 뒤의 값이 계정 등급마다 다른지 여부도 확인되지 않습니다.
Q. 이 표는 다른 종목이나 격리 마진에도 그대로 적용되나요?
A. 다른 종목과 다른 계정 등급은 이 글이 재지 않았습니다. 이번 실측은 BTC-USDT 한 종목, 기본 계정 등급 기준이라 심볼이나 계정 등급이 달라지면 구간 값도 달라질 수 있습니다. 격리 마진은 사정이 조금 다릅니다. 다섯 엔드포인트 가운데 마진 모드를 요청 파라미터로 받는 곳은 OKX 한 곳뿐이고, 같은 날 14시 50분(KST)에 tdMode=isolated로 다시 불러 보니 99구간이 교차 응답과 같은 값이었습니다. 나머지 네 곳은 요청에 마진 모드를 넣을 자리가 없어 심볼 기본 응답만 돌아옵니다. 다만 이것은 이 엔드포인트들이 마진 모드를 구분하지 않는다는 뜻까지이고, 거래소가 내부적으로 모드별 다른 표를 쓰는지는 확인되지 않습니다.
함께 보면 좋은 글
- 청산은 어느 값으로 계산되는가 노트: 청산 판정에 쓰이는 가격이 어느 값인지를 두 거래소 공개 API와 공식 문서로 갈랐습니다.
- 비트코인 옵션 스큐 보는 법 노트: 같은 이름의 지표가 제공처마다 다른 정의로 계산된다는 점을 문서 원문으로 대조했습니다.
데이터·개념 출처
본 노트의 수치는 2026년 8월 10일 13시 41분 07초부터 13시 41분 08초(KST) 사이에 다음 공개 엔드포인트를 직접 호출해 받은 응답입니다. 바이비트 GET /v5/market/risk-limit?category=linear&symbol=BTCUSDT(35구간·1구간 riskLimitValue 2,000,000·maintenanceMargin 0.005·initialMargin 0.01·maxLeverage 100.00·mmDeduction 빈 문자열), OKX GET /api/v5/public/position-tiers?instType=SWAP&tdMode=cross&instFamily=BTC-USDT(99구간·1구간 maxSz 1,000·maxLever 100·mmr 0.004·imr 0.01)와 GET /api/v5/public/instruments?instType=SWAP&instId=BTC-USDT-SWAP(ctVal 0.01·ctValCcy BTC·ctMult 1·lotSz 0.01·tickSz 0.1)와 GET /api/v5/public/mark-price?instType=SWAP&instId=BTC-USDT-SWAP(markPx 64,898.8), 비트겟 GET /api/v2/mix/market/query-position-lever?symbol=BTCUSDT&productType=USDT-FUTURES(12레벨·1레벨 endUnit 200,000·leverage 150·keepMarginRate 0.0040), 게이트 GET /api/v4/futures/usdt/risk_limit_tiers?contract=BTC_USDT(19구간·1구간 risk_limit 500,000·leverage_max 200·maintenance_rate 0.003·initial_rate 0.005·deduction 0)와 GET /api/v4/futures/usdt/contracts/BTC_USDT(leverage_max 200·maintenance_rate 0.003·risk_limit_base 500,000·risk_limit_step 1,499,500,000·risk_limit_max 1,500,000,000·quanto_multiplier 0.0001·mark_price 64,901.2·index_price 64,929.54), 바이낸스 GET /fapi/v1/premiumIndex?symbol=BTCUSDT(markPrice 64,897.69268116·indexPrice 64,936.61608696)와 웹 프런트엔드 경로 bapi/futures/v1/friendly/future/common/brackets(BTCUSDT 12구간·1구간 bracketNotionalCap 300,000·bracketMaintenanceMarginRate 0.004·maxOpenPosLeverage 150·updateTime 1755585384254)입니다.
필드 정의는 각 거래소 공식 문서에서 확인했습니다. 바이비트 API 문서의 Get Risk Limit 절 응답 표(riskLimitValue를 Position limit으로, maintenanceMargin을 Maintain margin rate로, initialMargin을 Initial margin rate로, maxLeverage를 Allowed max leverage로, mmDeduction을 The maintenance margin deduction value when risk limit tier changed로 적은 서술), OKX API 문서의 Get position tiers 절 응답 표(maxSz를 The maximum borrowing amount or number of positions held in this position is only applicable to margin/options/perpetual/delivery로, mmr을 Position maintenance margin requirement rate로, imr을 Initial margin requirement rate로, maxLever를 Maximum available leverage로 적은 서술)와 Get instruments 절(ctVal을 Contract value로, ctValCcy를 Contract value currency로, ctMult를 Contract multiplier로 적고 파생 계약의 수량 단위가 계약 수라고 적은 서술), 비트겟 API 문서의 Get Position Tier 절 응답 설명표(level을 Tier로, startUnit을 Start value로, endUnit을 End value로, leverage를 Leverage multiple로 적고, keepMarginRate는 Margin Rate로 적으면서 포지션의 증거금률이 유지증거금률보다 낮아지면 강제 감축이나 청산이 발동한다고 설명한 서술), 게이트 공식 SDK의 Contract 모델 문서(RiskLimitBase·RiskLimitStep·RiskLimitMax에 deprecated 표기를 붙이고 티어 조회 엔드포인트 사용을 권한 서술, QuantoMultiplier를 Multiplier used in converting from invoicing to settlement currency로 적은 서술)와 같은 SDK의 FuturesLimitRiskTiers 모델 문서(RiskLimit을 Position risk limit으로, InitialRate를 Initial margin rate로, MaintenanceRate를 Maintenance margin rate로, LeverageMax를 Maximum leverage로, Deduction을 Maintenance margin quick calculation deduction amount로 적은 서술)에서 인용했습니다.
두 가지는 인용 자리를 정확히 갈라 둡니다. OKX 문서에서 수량 단위가 계약 수라고 적힌 자리는 Get instruments 절이고, Get position tiers 절의 maxSz 설명은 계약이라는 말을 쓰지 않습니다. 비트겟 설명표는 v1 경로 /api/mix/v1/market/queryPositionLever 문서이고, 본문 실측은 v2 경로 /api/v2/mix/market/query-position-lever로 호출했습니다. 응답 필드 이름은 두 버전이 같습니다.
이 글은 공개 데이터와 공식 문서를 정리한 정보 제공 목적의 자료이며 특정 종목의 매매 권유가 아닙니다. 본 노트는 진입가·손절가·목표가·적정 배수를 제시하지 않으며, 어떤 배수나 포지션 크기도 권하지 않습니다. 구간 값은 특정 시각의 스냅샷이라 거래소가 표를 갱신하면 달라지고, 심볼이나 계정 등급에 따라서도 달라질 수 있습니다. 파생상품은 원금을 초과하는 손실이 발생할 수 있고 투자 판단과 그 결과는 전적으로 본인 책임입니다.