바이낸스 Tick Size·Step Size 뜻 2026｜가격·수량 단위·필터 오류

바이낸스 Tick Size·Step Size 뜻과 가격·수량 주문 단위

바이낸스 Tick Size는 주문 가격의 허용 간격을, Step Size는 주문 수량의 허용 간격을 이해할 때 사용하는 핵심 용어입니다. 잔고가 충분하고 숫자가 자연스러워 보여도 거래쌍의 단위와 맞지 않으면 주문이 거절될 수 있습니다.

예를 들어 가격 간격이 가상으로 0.05라면 1.20과 1.25는 그 격자에 맞지만 1.23은 맞지 않습니다. 소수점 두 자리라는 공통점만으로 같은 조건을 만족하는 것은 아닙니다. 마찬가지로 수량 간격이 0.002라면 소수점 세 자리의 모든 값이 허용되는 것은 아닙니다.

2026년 10월 26일 Binance Spot 공식 Filters와 REST API 문서를 확인했습니다. 이 글은 현물 주문에서 가격·수량·주문금액 조건을 구분하고 입력 오류를 조사하는 방법에 집중합니다. 모든 예시 단위와 한도는 가상값이며 특정 거래쌍의 현재 규칙으로 사용하면 안 됩니다.

가격과 수량을 같은 숫자로 생각하면 생기는 문제

거래쌍이 가상의 AAA/USDT라면 가격은 보통 AAA 한 단위당 USDT를 나타내고, 수량은 거래하려는 AAA의 양을 나타냅니다. 숫자 자체가 같더라도 단위가 다릅니다. 가격 10과 수량 10을 같은 방식으로 반올림하면 의도한 주문과 다른 결과가 나올 수 있습니다.

주문금액은 가격과 수량을 곱한 기준 자산 금액과 관련됩니다. 따라서 가격 조건을 통과했다고 수량 조건이나 주문금액 조건까지 통과한 것은 아닙니다. 서로 다른 필터가 각각 다른 질문을 검사한다고 이해하면 좋습니다.

이 구분을 익히면 오류가 났을 때 무조건 소수점을 지우거나 주문금액을 키우는 식으로 대응하지 않을 수 있습니다. 어느 조건이 맞지 않았는지 먼저 찾아야 수정 방향도 정확해집니다.

Tick Size는 소수 자릿수와 다릅니다

PRICE_FILTER의 tickSize는 허용되는 가격 간격을 설명합니다. 현재 공식 문서는 활성화된 가격 규칙에서 최소·최대 가격과 함께 가격이 tickSize의 배수인지 확인하는 조건을 제시합니다. Binance Spot Filters

가상 tickSize가 0.01이라면 소수점 두 자리로 된 많은 값이 자연스럽게 맞습니다. 이 때문에 ‘두 자리면 된다’고 기억하기 쉽습니다. 하지만 간격이 0.05라면 같은 두 자리라도 2.03은 격자에 맞지 않습니다. 자릿수는 표시 형식이고, 간격은 가능한 값들의 집합을 정하는 조건입니다.

가격을 저장할 때 원본 문자열을 유지하는 이유도 여기에 있습니다. 0.05000000을 보았다고 여덟 자리의 모든 소수값을 허용하는 것으로 해석하면 안 됩니다. 실제 간격은 0.05입니다. 뒤의 0과 허용 간격의 의미를 구분합니다.

또한 최소 가격과 tickSize를 혼동하지 않습니다. 최소 가격은 범위의 하한이고 tickSize는 값 사이의 간격입니다. 하한 이상이라고 모두 유효하지 않으며, 배수라고 해도 하한·상한 밖이면 해당 범위 조건을 통과하지 못합니다.

PRICE_FILTER를 읽는 세 단계

minPrice와 maxPrice: 범위 확인

최소와 최대 가격은 해당 가격 규칙에서 허용되는 범위를 설명합니다. 값이 존재한다는 사실만 보고 임의의 공통 범위를 적용하지 말고 실제 심볼에서 조회한 조건을 사용합니다. 특정 예제에 나오는 큰 최대값을 모든 종목의 현재 상한으로 인용하면 안 됩니다.

현재 공식 문서는 PRICE_FILTER의 각 변수가 0인 경우 해당 가격 규칙이 비활성화될 수 있음을 설명합니다. 0을 일반적인 가격 하한이나 간격처럼 무조건 계산에 넣으면 오류가 생깁니다. 특히 0으로 나머지 연산을 하는 구현은 피해야 합니다.

이 설명을 모든 필터의 모든 0에 확대하지 않는 것도 중요합니다. 비활성화 조건은 필터별 정의를 읽어야 합니다. 한 필터에서 본 특례를 다른 수량·금액 조건에 그대로 적용하면 검증이 잘못될 수 있습니다.

tickSize: 허용 간격 확인

간격 검사는 가격이 정해진 격자 위에 있는지 확인하는 것입니다. 가상 가격 2.15와 tickSize 0.05는 43개의 간격으로 설명할 수 있습니다. 반면 2.17은 같은 간격으로 정확히 나눠지지 않습니다.

이 원리는 가격을 임의의 가장 가까운 값으로 바꾸라는 권유가 아닙니다. 사용자가 정한 최대 매수가격이나 최소 매도가격이 있다면, 조정 방향에 따라 의도가 달라질 수 있습니다. 숫자를 유효하게 만드는 것과 거래 조건을 지키는 것은 별도 검증입니다.

stopPrice 등 적용 항목 확인

가격 필터의 적용 항목에는 문서상 price와 stopPrice가 포함됩니다. 조건 주문을 사용하면서 주문가격만 맞추고 트리거 관련 입력의 단위를 놓치지 않도록 해야 합니다. 다만 특정 주문 유형에서 어떤 필드가 필요한지는 해당 주문 문서를 함께 읽습니다.

가격 입력란이 두 개라면 두 값의 역할도 구분합니다. 발동 기준과 발동 후 주문가격은 같은 숫자일 필요가 없고, 각 조건이 어떤 규칙을 받는지 확인해야 합니다. 단위 검증을 통과했다고 조건 주문의 경제적 의도가 올바르다는 뜻은 아닙니다.

Step Size와 LOT_SIZE는 수량을 다룹니다

LOT_SIZE의 minQty, maxQty, stepSize는 수량 범위와 간격을 설명합니다. 현재 문서는 수량이 최소 이상·최대 이하이며 stepSize의 배수여야 한다는 조건을 제시합니다. LOT_SIZE 공식 정의

가상의 stepSize가 0.002라면 0.010은 5단위의 간격으로 맞지만 0.011은 맞지 않습니다. 소수점 셋째 자리까지만 썼다는 이유로 유효하지 않습니다. 수량 역시 소수 자릿수보다 실제 간격을 기준으로 판단해야 합니다.

minQty와 stepSize도 서로 다릅니다. 가상 최소 수량이 0.010이고 간격이 0.002라면 0.008은 격자에 맞아도 최소 조건에 못 미칩니다. 반대로 0.011은 최소 이상이어도 격자에 맞지 않습니다. 두 조건을 모두 확인해야 합니다.

수량 단위는 거래쌍의 기초 자산 기준이라는 맥락을 유지합니다. 0.01 BTC와 0.01 USDT는 같은 규모의 입력이 아닙니다. 금액 기준으로 주문하려는 경우에는 어떤 필드가 금액을 뜻하는지 따로 확인해야 합니다.

수량을 내리면 항상 해결되나요?

원하는 양보다 더 주문하지 않기 위해 수량을 아래쪽 격자로 조정하는 생각은 자연스럽습니다. 하지만 내린 값이 최소 수량이나 최소 주문금액보다 작아질 수 있습니다. 단위 문제 하나를 해결한 뒤 다른 조건에서 거절될 수 있다는 뜻입니다.

예를 들어 가상 목표 수량이 0.013이고 stepSize가 0.005라면 아래 격자 후보는 0.010입니다. 이 후보가 거래 의도에 맞는지와 함께 minQty, 금액 조건과 잔고를 다시 확인해야 합니다. ‘내림했으니 유효’라는 한 단계 검증으로 끝내지 않습니다.

반대로 최소 조건을 맞추려고 수량을 올리는 것은 거래 규모를 늘리는 결정입니다. 입력 오류를 해결한다는 이유로 자동으로 노출을 늘리면 원래 예산이나 위험 한도를 넘을 수 있습니다. 유효한 주문을 만들 수 없을 때는 주문하지 않는 선택도 남겨 두어야 합니다.

NOTIONAL: 수량과 금액은 별도 조건입니다

지정가 주문의 단순한 명목금액은 가격×수량으로 이해할 수 있습니다. 수량이 충분해 보여도 가격이 작으면 금액이 최소 조건보다 낮을 수 있습니다. 반대로 수량은 작아도 가격이 크면 상당한 금액이 될 수 있습니다.

현재 공식 문서는 MIN_NOTIONAL과 NOTIONAL을 구분하고, 시장가 적용 여부를 설명하는 필드도 별도로 둡니다. 따라서 모든 거래쌍에 ‘최소 몇 USDT’라는 하나의 숫자를 적용하면 안 됩니다. 적용 필터와 현재 값을 실제 심볼에서 확인해야 합니다.

시장가 주문에는 사용자가 지정한 단일 체결가격이 없으므로, 해당 필터가 어떤 기준 가격을 사용하는지 확인해야 합니다. 현재 공식 문서는 참조가격의 존재 여부와 이전 거래 가격의 평균 관련 조건을 설명합니다. 화면의 마지막 가격을 곱한 값이 언제나 거래소의 검증값과 같다고 가정하지 않습니다.

MARKET_LOT_SIZE와 다른 필터를 함께 확인합니다

시장가 주문에 별도의 수량 규칙이 있다면 LOT_SIZE만 보고 끝내지 않습니다. 적용되는 필터의 종류와 엔드포인트의 설명을 함께 확인해야 합니다. 시장가라는 이유로 단위와 최소 조건이 모두 사라지는 것은 아닙니다.

가격 범위 제한도 마찬가지입니다. tickSize가 맞는다고 현재 기준 가격에서 지나치게 떨어진 주문가격까지 모두 허용되는 것은 아닙니다. PERCENT_PRICE 계열은 가격 간격과 다른 범위 조건을 설명합니다.

또한 접수 조건과 체결 과정의 규칙은 구분해야 합니다. 여기서는 가격·수량 입력의 유효성에 집중합니다. 주문이 접수된 뒤 어떤 가격에서 얼마나 체결되는지는 주문 유형, 유동성과 다른 실행 규칙을 함께 봐야 합니다.

현재 규칙을 확인하는 방법

Binance Spot의 Exchange Information 조회는 심볼의 거래 규칙과 필터를 확인하는 공식 경로입니다. 조회 결과의 심볼, 거래 상태와 필터 목록을 확인한 다음 내 주문 유형에 필요한 조건을 선택합니다. 문서의 예시 JSON을 실제 심볼의 현재 응답으로 오해하지 않는 것이 중요합니다.

조회 시각을 남기고 규칙을 갱신하는 기준을 정해 두는 편이 좋습니다. 오래된 캐시를 사용하는 프로그램이라면 과거에는 맞던 주문이 지금은 거절될 수 있습니다. 오류가 발생했을 때는 먼저 최신 규칙으로 재확인하고 무엇이 달라졌는지 비교합니다.

다만 매 주문마다 여러 조회를 불필요하게 반복하면 요청 부담이 커질 수 있습니다. 갱신 주기는 시스템 목적과 공식 제한을 고려해 정하되, 오류가 난 뒤에도 오래된 값을 고집하지 않는 구조가 필요합니다. 최신성 관리와 과도한 요청 방지는 함께 고려해야 합니다.

화면에서 단위 정보를 찾지 못했다고 임의의 숫자를 만들지 않습니다. UI에서 제공하는 안내와 공식 문서·공식 조회 결과를 구분해 사용합니다. 어떤 버튼 경로를 직접 확인하지 못했다면 모든 앱 버전에 같은 메뉴가 있다고 설명해서는 안 됩니다.

사례 1: 소수점 두 자리인데 가격이 거절된 경우

가상의 거래쌍에서 tickSize는 0.05이고 사용자가 원하는 가격은 3.17입니다. 사용자는 소수점 두 자리만 입력했으므로 문제없다고 생각합니다. 그러나 3.17은 0.05의 정수배가 아닙니다.

가능한 인접 격자 값으로 3.15와 3.20을 생각할 수 있지만, 둘 중 아무 값이나 자동 선택하면 안 됩니다. 매수에서 최대 지불가격을 3.17로 정했다면 3.20은 원래 상한을 넘는 값입니다. 매도에서 최소 수령가격을 3.17로 정했다면 3.15는 원래 하한보다 낮습니다.

이 사례에서 해결해야 할 질문은 두 개입니다. ‘어떤 값이 격자에 맞는가’와 ‘어떤 값이 내 가격 조건을 지키는가’입니다. 첫 질문의 답만으로 주문을 만들어서는 안 됩니다. 유효한 후보가 생긴 뒤에도 범위·잔고·금액 조건을 점검합니다.

기록에는 최초 의도 가격, 적용한 격자, 최종 후보와 조정 이유를 남길 수 있습니다. 나중에 왜 3.17이 아닌 다른 가격으로 제출됐는지 설명하려면 원래 값도 보존해야 합니다. 표시상 반올림과 거래 의도 변경을 구분하는 것이 핵심입니다.

사례 2: 수량 자릿수는 맞지만 Step Size가 다른 경우

가상 stepSize가 0.002이고 원하는 수량은 0.013입니다. 소수점 세 자리라는 사실은 간격에 맞는지 알려 주지 않습니다. 0.012와 0.014는 인접한 격자 후보지만 0.013은 그 사이에 있습니다.

추가 수량을 원치 않는다는 가정이라면 0.012를 검토할 수 있습니다. 그러나 최소 수량이 가상으로 0.014라면 아래 후보는 최소 조건을 만족하지 않습니다. 이때 자동으로 0.014로 올리는 것은 주문 규모를 늘리는 결정입니다.

사용자의 허용 범위 안에서 유효한 수량이 없다면 주문을 만들지 않고 조건을 다시 검토해야 합니다. ‘시스템이 받아 주는 값’과 ‘사용자가 원하는 값’의 교집합을 찾는 것이 목적입니다. 어느 한쪽만 만족해도 된다고 생각하지 않습니다.

오류를 수정한 뒤에는 요청 문자열도 다시 확인합니다. 내부 계산은 0.012였지만 전송 과정에서 부동소수점 표현이 길게 붙으면 다른 검증 문제가 생길 수 있습니다. 계산값, 직렬화된 값과 실제 응답을 연결해 보는 것이 좋습니다.

사례 3: 단위는 맞는데 최소 주문금액이 부족한 경우

가상 가격은 2.50, 수량은 1.20이고 각 단위 조건은 맞는다고 합시다. 명목금액은 3.00입니다. 해당 가상 거래쌍의 최소 명목금액이 5.00이라면 단위에 맞는다는 사실만으로 주문이 유효하지 않습니다.

사용자는 ‘수량 오류가 아닌데 왜 안 되지’라고 생각할 수 있습니다. 이때 확인할 것은 LOT_SIZE가 아니라 실제 오류가 가리키는 금액 조건입니다. 거래소가 여러 필터를 적용한다는 구조를 이해하면 원인 조사가 쉬워집니다.

수량을 늘리면 금액 조건을 만족할 수 있다는 산술적 사실과, 그렇게 거래하는 것이 적절하다는 판단은 별개입니다. 예산이나 목적 때문에 3.00만 거래하려던 상황이면 최소 조건을 충족시키기 위해 거래액을 늘리지 않을 수 있습니다.

최종 보고에는 ‘가격·수량 단위는 적합하지만 금액 조건 미달’처럼 실패한 범위를 적습니다. 모든 거절을 ‘소수점 오류’로 묶어 두면 다음에도 같은 잘못된 수정이 반복됩니다. 필터별로 원인을 분리하는 편이 좋습니다.

사례 4: 계산 결과가 아주 조금 어긋난 경우

프로그램이 십진수 계산을 이진 부동소수점으로 수행하면 사람 눈에는 0.3이어야 할 값이 내부에서 아주 작은 차이를 포함할 수 있습니다. 그 상태로 나머지 연산을 하면 격자에 맞는 값을 틀렸다고 판단하거나 반대로 잘못된 허용 오차를 줄 수 있습니다.

이 문제는 거래소가 소수점 규칙을 임의로 바꿨다는 뜻이 아닙니다. 입력 데이터의 표현과 계산 방식부터 확인해야 합니다. 십진수 연산 도구나 정수 배율 변환을 사용해 단위를 정확히 표현하는 방법이 있습니다.

가상 간격 0.05를 정수 5로, 가격 3.15를 정수 315로 바꿔 같은 배율에서 계산하면 315가 5의 배수인지 명확히 확인할 수 있습니다. 단, 모든 입력을 같은 배율로 변환하고 범위를 넘는 큰 정수 처리도 주의해야 합니다.

무작정 아주 작은 허용 오차를 주어 통과시키는 방식은 실제로 격자에서 벗어난 값을 허용할 수 있습니다. 목표는 오차를 숨기는 것이 아니라 전송할 십진수 값을 정확히 만드는 것입니다. 검증한 문자열과 제출한 문자열이 같은지도 확인합니다.

사례 5: 예전 규칙을 계속 사용한 경우

사용자 E의 프로그램은 예전에 저장한 tickSize와 stepSize를 계속 사용합니다. 어느 날 같은 계산으로 만든 주문이 거절됩니다. 과거에 성공했다는 이유로 서버 오류라고 단정하기 전에 현재 심볼 정보를 다시 확인해야 합니다.

규칙이 변경됐는지, 다른 심볼을 조회했는지, 상품이 달라졌는지 비교합니다. 종목 이름이 비슷해도 기준 자산이 다른 거래쌍은 별도 심볼입니다. BTC/USDT의 규칙을 BTC/다른 자산에 적용하면 안 됩니다.

새 규칙을 확인했다면 기존 값과 갱신 시각을 보존합니다. 현재 주문을 어떻게 처리할지는 별도 결정이고, 향후 주문 검증에는 올바른 규칙을 사용해야 합니다. 캐시를 지우는 것만으로 원인이 기록되지 않으면 같은 문제가 재발했을 때 조사하기 어렵습니다.

이 사례는 규칙을 한 번 읽는 것보다 규칙의 출처와 시점을 관리하는 것이 중요하다는 점을 보여 줍니다. 값이 정확해도 다른 시점이나 다른 심볼의 값이면 현재 입력을 검증하는 근거가 되지 못합니다.

반올림 방향은 거래 의도의 일부입니다

가격과 수량을 ‘가장 가까운 유효값’으로 바꾸는 알고리즘은 계산상 편리하지만 모든 목적에 맞지는 않습니다. 매수 상한, 매도 하한, 최대 예산과 최대 수량 같은 조건은 방향성을 갖습니다. 반올림으로 그 조건을 넘는지 반드시 확인해야 합니다.

예를 들어 최대 매수가격을 지키는 것이 목적이라면 위로 올린 가격은 원래 의도를 어길 수 있습니다. 최소 매도가격을 지키는 것이 목적이라면 아래로 내린 가격이 문제가 될 수 있습니다. 숫자 차이가 작아 보여도 의도와 다른 주문이라는 점은 변하지 않습니다.

수량을 아래로 맞춘 뒤 남은 소액을 어떻게 처리할지도 미리 정의하면 좋습니다. 잔여량이 있다는 이유로 추가 주문을 무조건 만들면 최소 조건이나 비용 문제가 생길 수 있습니다. 남은 양을 기록하고 별도 판단으로 남겨 둘 수 있습니다.

이 글의 예시는 후보를 계산하는 방법이지 매매 방향을 추천하는 규칙이 아닙니다. 실제 주문의 가격과 수량은 사용자가 정한 목적과 허용 범위 안에서 결정해야 합니다. 자동화는 그 범위를 임의로 넓히지 않아야 합니다.

정밀도 필드와 주문 단위를 구분합니다

Exchange Information에는 자산·기준 자산 정밀도와 필터 정보가 함께 보일 수 있습니다. 자산 정밀도는 표현과 계산 범위에 관련되지만, 그것만으로 주문의 tickSize나 stepSize를 대체해서는 안 됩니다. 주문 가능한 격자는 해당 필터에서 읽어야 합니다.

가상의 자산이 많은 소수 자릿수를 지원한다고 해서 주문 수량도 그 마지막 자리까지 자유롭게 입력할 수 있는 것은 아닙니다. 잔고에 보이는 정밀도와 주문 최소 단위는 다른 목적을 가진 정보입니다. 잔고 전부를 그대로 복사했을 때 주문 단위 오류가 생기는 이유 중 하나입니다.

또한 표시용 문자열과 계산용 원본을 나눕니다. 화면에서 길이를 줄이기 위해 반올림한 값을 다시 주문 계산에 사용하는 구조는 오차를 누적시킬 수 있습니다. 원본 값으로 검증하고 표시만 별도로 처리하는 편이 명확합니다.

필터 오류를 조사할 때의 순서

먼저 정확한 오류 메시지와 대상 심볼을 보존합니다. 오류가 PRICE_FILTER를 가리키는지, LOT_SIZE인지, 금액 조건인지 확인합니다. 메시지가 충분하지 않다면 관련 필드를 차례로 대조하되 원인을 확인한 것처럼 단정하지 않습니다.

다음으로 실제 제출값을 봅니다. 화면에 표시된 값이나 코드의 중간 계산값이 아니라, 전송한 가격·수량 문자열을 확인해야 합니다. 자동 변환이나 포맷팅에서 값이 바뀌었을 수 있기 때문입니다.

그다음 현재 공식 심볼 규칙과 비교합니다. 범위, 배수 조건과 주문 유형별 적용 여부를 분리해 점검합니다. 하나를 수정한 뒤에는 전체 조건을 다시 확인합니다. 수량을 줄여 단위를 맞췄지만 금액이 최소보다 작아지는 식의 연쇄 변화가 생길 수 있습니다.

마지막으로 기존 주문 상태를 확인합니다. 신규 주문 오류인지 취소·재주문의 신규 단계 오류인지에 따라 기존 주문이 남았는지가 달라질 수 있습니다. 입력 검증 문제를 해결하는 동안 실제 열린 주문을 잊지 않아야 합니다.

테스트에서 확인하면 좋은 경계값

단위 계산을 구현했다면 임의의 정상값 하나만 시험하지 말고 경계값을 확인하는 것이 좋습니다. 최소 바로 아래, 최소값, 최대값과 최대 바로 위의 값을 비교하면 범위 처리 오류를 발견하기 쉽습니다. 격자에 맞는 값과 한 간격의 일부만 벗어난 값도 구분해 봅니다.

단위가 0.01인 경우만 시험하면 소수 자릿수 검사로도 우연히 통과할 수 있습니다. 0.05나 0.002 같은 가상 간격을 넣어 보면 실제 배수 조건을 구현했는지 확인할 수 있습니다. 이는 실제 거래소 수치가 아니라 검증 로직을 위한 시험 데이터입니다.

가격 조정 후 금액 조건이 달라지는 사례, 수량 조정 후 최소 조건을 벗어나는 사례와 잔고보다 커지는 사례도 각각 확인합니다. 모든 실패를 하나의 메시지로 반환하지 않으면 사용자가 무엇을 검토해야 하는지 알기 쉽습니다.

테스트 주문 기능이 있다고 해도 실제 체결과 동일한 결과를 보장하는 것은 아닙니다. 입력 검증, 시장 상태와 실제 체결은 다른 단계입니다. 테스트 결과의 범위를 명확히 이해하고 실제 거래를 검증 수단으로 무리하게 사용하지 않습니다.

주문 의도와 검증 결과를 한 장에 정리하기

검증표에는 사용자가 원한 가격·수량, 실제 적용 규칙, 조정한 후보와 최종 제출값을 구분해 넣습니다. 원래 값이 지워지면 나중에 단위에 맞추는 과정에서 어떤 변경이 있었는지 알기 어렵습니다. 작은 반올림도 거래 조건의 일부이므로 변경 근거를 남기는 편이 좋습니다.

예를 들어 ‘가격 3.17, 가격 간격 0.05, 후보 3.15, 최대 매수가격을 넘지 않도록 조정’이라고 적을 수 있습니다. 이어 수량과 금액, 잔고 조건이 모두 맞는지 확인합니다. 이 문장은 가상 검토 예이며 실제 매매가격을 추천하는 것이 아닙니다.

수량에도 같은 구조를 적용합니다. ‘원하는 수량, 수량 간격, 조정 후 수량, 잔여 목표’를 나눠 적으면 단위 때문에 실행하지 못한 부분이 드러납니다. 잔여 목표는 자동으로 새 주문을 만들어야 한다는 지시가 아니라 아직 수행되지 않은 계획의 일부입니다.

최종 제출값에는 단위가 붙어야 합니다. 수량 열에는 기초 자산, 가격에는 기준 자산/기초 자산, 금액에는 기준 자산을 표시합니다. 단위가 붙으면 값이 잘못된 열에 들어간 실수도 발견하기 쉽습니다. 숫자만 보면 자연스러워 보이는 오류를 잡는 데 도움이 됩니다.

예산 상한과 주문 단위가 충돌할 때

예산으로 수량을 계산하면 나눗셈 결과가 허용 수량 간격과 맞지 않는 경우가 흔합니다. 가상의 예산 10, 가격 3, 수량 간격 0.1이라면 산술 수량은 반복 소수지만 실제 후보는 격자에 맞춰 검토해야 합니다. 후보가 원래 예산을 넘는지 다시 곱해서 확인합니다.

이 경우 3.3이라는 가상 후보의 대금은 9.9이고 3.4의 대금은 10.2입니다. 가까운 값이라는 이유로 3.4를 택하면 예산 10을 넘습니다. 단순한 소수점 정리도 실제 지출 조건을 바꿀 수 있다는 점을 보여 줍니다. 수수료와 다른 조건은 이 산술 예에서 별도이며 실제 기록으로 확인해야 합니다.

가격도 동시에 조정한다면 금액을 한 번 더 계산해야 합니다. 수량을 처음 계산할 때 사용한 가격과 제출할 가격이 다르면 예산 검증 결과가 달라질 수 있기 때문입니다. 최종 가격과 최종 수량으로 계산한 결과를 확인하는 것이 중요합니다.

최소 주문금액과 최대 예산 사이에 허용되는 격자 조합이 없다면 유효한 주문이 없을 수 있습니다. 이런 상태를 프로그램이 숨기고 자동으로 금액을 늘리면 사용자의 제한을 위반합니다. ‘현재 조건에서 주문 가능 조합 없음’이라는 결과도 올바른 검증 결과입니다.

단위 오류와 시장 변화에 따른 오류를 구분합니다

tickSize와 stepSize는 입력이 격자에 맞는지 확인하는 기준입니다. 상대 가격 범위처럼 시장 기준값에 연동되는 조건은 시간이 지나면서 판단에 쓰이는 값이 달라질 수 있습니다. 입력 문자열이 같아도 적용 맥락이 같다는 보장은 없습니다.

단위 오류가 명확하다면 먼저 계산과 직렬화 방식을 확인합니다. 반면 현재 기준 가격 관련 오류라면 해당 필터의 참조값과 시점을 확인해야 합니다. 두 문제를 모두 ‘소수점 문제’로 부르면 수정해도 원인이 남을 수 있습니다.

이 구분은 오류 메시지를 사용자에게 설명할 때도 유용합니다. ‘가격 간격 불일치’와 ‘현재 허용 가격 범위 밖’은 다른 안내가 필요합니다. 전자는 격자 후보의 검토가 중심이고 후자는 원래 가격 의도와 현재 시장 조건의 관계를 다시 검토해야 합니다.

자주 묻는 질문 FAQ

1. Tick Size는 무엇인가요?

주문 가격이 움직일 수 있는 허용 간격을 설명하는 값입니다. 현재 심볼의 PRICE_FILTER에서 확인합니다. 단순히 소수점 몇 자리까지 입력하는지와는 다르며 최소·최대 가격도 함께 확인해야 합니다.

2. Step Size는 무엇인가요?

주문 수량의 허용 간격을 설명합니다. LOT_SIZE의 수량 범위와 함께 읽어야 합니다. 수량이 최소 이상이어도 간격의 배수가 아니면 조건을 만족하지 못할 수 있습니다.

3. 둘을 같은 값으로 설정하면 되나요?

가격과 수량은 단위와 역할이 다릅니다. 실제 심볼에서 각각의 필터 값을 읽어야 합니다. 우연히 숫자가 같아 보이더라도 하나를 다른 항목의 근거로 사용하지 않습니다.

4. 소수점 두 자리면 0.05 간격에 맞나요?

모든 두 자리 값이 맞지는 않습니다. 1.20과 1.25는 가상 0.05 격자에 맞지만 1.23은 맞지 않습니다. 표시 자릿수 대신 정확한 배수 관계를 확인해야 합니다.

5. minQty와 stepSize는 같은 뜻인가요?

최소 수량과 허용 간격은 다릅니다. 격자에 맞아도 최소보다 작을 수 있고, 최소보다 커도 격자에서 벗어날 수 있습니다. 두 조건을 동시에 점검합니다.

6. 수량을 내리면 항상 주문되나요?

내린 값이 최소 수량이나 최소 금액 조건을 벗어날 수 있습니다. 잔고와 다른 적용 필터도 확인해야 합니다. 단위를 맞추는 조정 후 전체 조건을 다시 검증합니다.

7. 금액이 크면 단위 오류가 없어지나요?

가격·수량 간격은 주문금액과 별도 조건입니다. 충분히 큰 금액이어도 격자에 맞지 않는 가격이나 수량은 문제가 될 수 있습니다. 오류가 가리키는 필터부터 확인합니다.

8. 시장가는 필터가 없나요?

시장가에 적용되는 수량·금액 조건도 확인해야 합니다. 사용자가 가격을 직접 지정하지 않는다고 모든 검증이 생략되는 것은 아닙니다. 현재 주문 경로와 필터의 시장가 적용 정보를 읽습니다.

9. 최소 주문금액은 모든 거래쌍에 같나요?

그렇게 가정하지 않습니다. 현재 심볼의 MIN_NOTIONAL 또는 NOTIONAL 등 실제 적용 정보를 확인해야 합니다. 문서 예시의 숫자를 모든 거래쌍의 고정 조건으로 쓰지 않습니다.

10. 잔고 정밀도로 주문 단위를 알 수 있나요?

잔고에 표시되는 소수 자릿수와 주문의 허용 간격은 다를 수 있습니다. 자산 정밀도만으로 stepSize를 대체하지 않습니다. 주문 필터를 별도로 확인해야 합니다.

11. 가격을 가까운 값으로 반올림하면 되나요?

그 값이 사용자의 최대 매수가격이나 최소 매도가격을 어기지 않는지 확인해야 합니다. 유효한 숫자를 만드는 것과 거래 의도를 지키는 것은 별개입니다. 조정 방향을 임의로 정하지 않습니다.

12. 아주 작은 계산 오차는 무시해도 되나요?

전송값과 검증값의 불일치 원인을 확인하는 것이 우선입니다. 십진수 연산이나 정수 배율 방식으로 정확히 계산할 수 있습니다. 무조건 허용 오차를 넓히면 실제로 틀린 값까지 통과시킬 수 있습니다.

13. 예전에 되던 값이 안 되면 무엇을 보나요?

현재 심볼과 상품, 규칙 갱신 시각부터 확인합니다. 오래된 필터 캐시나 다른 거래쌍의 조건을 사용했을 수 있습니다. 실제 오류와 최신 공식 정보를 대조합니다.

14. 필터 통과는 체결 보장인가요?

입력 조건과 실제 거래는 다른 단계입니다. 유효한 지정가 주문도 상대 주문이 없거나 가격이 맞지 않으면 대기할 수 있습니다. 체결 여부는 주문 상태와 실제 거래 내역으로 확인합니다.

15. 필터 오류에서 곧바로 다시 보내도 되나요?

먼저 잘못된 항목과 실제 제출값을 확인하고 원인을 수정해야 합니다. 같은 잘못된 값을 반복하면 해결되지 않습니다. 취소·재주문 중 오류라면 기존 주문의 상태도 함께 점검합니다.

가격·수량 검증 체크리스트

• [ ] 상품과 심볼이 맞는지 확인했다.
• [ ] 기초 자산과 기준 자산 단위를 구분했다.
• [ ] 현재 PRICE_FILTER의 범위와 간격을 읽었다.
• [ ] 비활성화 규칙을 해당 필터 정의대로 처리했다.
• [ ] 수량의 minQty·maxQty·stepSize를 확인했다.
• [ ] 시장가에 적용되는 별도 조건을 확인했다.
• [ ] 최소·최대 명목금액 조건을 점검했다.
• [ ] 가격·수량 조정이 원래 거래 의도를 바꾸지 않는다.
• [ ] 조정 후 금액과 잔고를 다시 계산했다.
• [ ] 표시 자릿수와 실제 허용 간격을 혼동하지 않았다.
• [ ] 원본 십진수와 식별자 정밀도를 보존했다.
• [ ] 실제 제출 문자열을 검증했다.
• [ ] 필터의 출처와 조회 시각을 기록했다.
• [ ] 오류 수정 전에 기존 주문 상태를 확인했다.

핵심 정리와 마무리

바이낸스 Tick Size와 Step Size를 이해하려면 가격·수량·금액의 조건을 나누고, 소수 자릿수가 아닌 실제 허용 간격을 확인해야 합니다. 단위를 맞춘 뒤에도 원래 의도와 잔고·다른 필터를 다시 검토하는 과정이 필요합니다.

이 글은 현물 주문 규칙을 이해하기 위한 정보입니다. 특정 거래를 권하거나 손실·체결 결과를 보장하지 않습니다. 실제 주문에는 이용 시점의 Binance 공식 규칙과 해당 계정·심볼의 조건을 적용하십시오.