바이낸스 Notional Filter 뜻 2026｜최소 주문 금액·상한·시장가 적용 조건

바이낸스 Notional Filter 뜻 2026｜최소 주문 금액·상한·시장가 적용 조건

바이낸스 Notional Filter는 주문의 가격과 수량으로 계산한 금액이 허용 범위에 있는지 확인하는 규칙입니다. 코인을 최소 몇 개 주문할 수 있는지 정하는 수량 조건과 다릅니다. 수량 단위는 맞아도 주문 금액이 너무 작거나 적용되는 상한을 넘으면 별도 조건에서 거절될 수 있습니다.

최소 주문 금액을 모든 거래쌍에 같은 숫자로 기억하면 오류가 생기기 쉽습니다. 거래쌍의 표시 자산이 다를 수 있고 실제 필터값도 달라질 수 있기 때문입니다. 또한 지정가의 가격과 시장가 평가에 쓰이는 가격을 같은 것으로 생각하면 화면 계산과 서버 판단의 차이를 설명하기 어렵습니다.

이 글은 2026년 10월 28일 확인한 Binance Spot 공식 Filters 문서의 MIN_NOTIONAL과 NOTIONAL을 다룹니다. 선물 포지션 명목가치나 레버리지별 한도와 혼합하지 않습니다. 아래 계산 숫자는 가상의 학습 예시이며 특정 거래쌍의 현재 최소 주문 금액을 안내하는 것이 아닙니다.

1. Notional의 의미부터 정리

현물 주문에서 이 필터가 다루는 명목 금액은 기본적으로 가격에 수량을 곱한 값입니다. 가격이 표시 자산으로 표현되고 수량이 기준 자산 수량이라면 결과는 표시 자산 단위가 됩니다. 따라서 숫자를 읽을 때는 baseAsset과 quoteAsset을 함께 확인해야 합니다.

예를 들어 가격이 20 QUOTE이고 주문 수량이 0.4 BASE라면 명목 금액은 8 QUOTE입니다. 여기서 BASE와 QUOTE는 단위를 설명하는 가상 이름입니다. 8이라는 숫자를 무조건 8달러나 8원이라고 부르면 단위를 잘못 해석한 것입니다.

수량과 금액은 서로 다른 검사

minQty는 최소 수량, stepSize는 수량 간격과 관련된 항목입니다. minNotional은 최소 주문 금액을 의미합니다. 같은 수량이라도 가격이 달라지면 금액이 달라지므로 수량 조건만으로 금액 조건을 대체할 수 없습니다.

반대로 최소 금액을 넘었다고 수량 간격 조건까지 맞는 것도 아닙니다. 큰 주문이어도 잘못된 수량 단위를 사용하면 다른 필터에서 실패할 수 있습니다. 실제 주문은 적용되는 여러 조건을 동시에 만족해야 하며 금액 필터는 그중 하나입니다.

계정 잔고와도 다른 개념

잔고는 사용자가 사용할 수 있는 자산의 상태이고 필터는 주문이 충족해야 하는 거래 규칙입니다. 가용 잔고가 충분해도 주문 금액이 하한보다 작으면 필터 문제가 남을 수 있습니다. 반대로 필터를 통과할 크기의 주문이라도 잔고가 부족하면 주문이 수락되지 않을 수 있습니다.

수수료와 잠긴 잔고도 별도 확인 항목입니다. 명목 금액이 최소 기준 이상이라는 사실을 최종 사용 가능 금액이나 실제 수령량과 동일하게 취급하면 안 됩니다. 거래 금액, 수수료, 가용 잔고, 체결 후 수령량은 각각 의미가 다릅니다.

2. MIN_NOTIONAL과 NOTIONAL 차이

Binance 공식 Filters 문서는 MIN_NOTIONAL을 심볼에서 허용되는 최소 주문 금액으로 설명합니다. 지정가처럼 가격이 있는 주문의 기본 검사는 가격×수량이 minNotional 이상인지 확인하는 것입니다.

NOTIONAL은 허용되는 금액 범위를 정의합니다. minNotional 이상이면서 maxNotional 이하라는 하한·상한 조건을 다룹니다. 두 이름이 비슷하지만 제공하는 범위와 시장가 적용 옵션을 구분해야 합니다. 실제 심볼 응답에서 반환되는 filterType을 기준으로 해석하세요.

필드 이름을 구분해서 읽기

MIN_NOTIONAL에는 applyToMarket이 있습니다. 이는 해당 최소 금액 필터를 MARKET 주문에도 적용할지 나타냅니다. NOTIONAL에는 applyMinToMarket과 applyMaxToMarket이 따로 있어 시장가에 하한과 상한을 각각 적용할지 구분합니다.

따라서 시장가 적용 여부를 하나의 공통 boolean으로 합치면 원래 규칙을 잃을 수 있습니다. 하한 적용과 상한 적용이 같은 값이라고 가정하지 않아야 합니다. 각 필드의 실제 값을 읽고 주문 종류에 맞는 검사를 선택하는 구조가 필요합니다.

응답 예시와 실제 조건

공식 문서에는 이해를 돕는 JSON 예시가 포함됩니다. 그 예시의 minNotional이나 maxNotional은 모든 심볼에 고정적으로 적용되는 값이 아닙니다. 문서 예시를 복사해 현재 거래 규칙으로 저장하는 대신 대상 심볼의 Exchange Info를 확인해야 합니다.

응답에 어떤 필터가 있는지 확인하지 않고 이름이 더 최신처럼 보이는 하나만 선택하는 것도 피해야 합니다. 적용되는 규칙을 filterType별로 읽고 필요한 항목을 검사합니다. 필터가 없다는 것과 조회·파싱에 실패해 보이지 않는 것은 구분해야 합니다.

3. 지정가 주문의 계산

지정가 주문을 이해할 때는 최종 제출 가격과 최종 제출 수량을 사용합니다. 화면에서 임시로 계산한 가격이나 수량을 조정하기 전 값을 쓰면 실제 요청과 검사값이 달라질 수 있습니다. 검증이 끝난 뒤 직렬화 과정에서 값이 달라지는지도 확인해야 합니다.

가상의 하한이 10 QUOTE이고 지정가가 25 QUOTE/BASE라면 수량 0.4 BASE의 명목 금액은 10 QUOTE입니다. 단순한 금액 계산에서는 하한과 같으므로 이상 조건에 해당합니다. 그러나 이것이 모든 다른 필터와 잔고 조건을 만족한다는 뜻은 아닙니다.

경계값은 정확한 수치로 비교

공식 조건의 이상·이하를 초과·미만으로 바꾸면 경계값 처리 결과가 달라집니다. 가격×수량이 정확히 하한과 같은 경우를 잘못 거절하거나 상한과 같은 경우를 잘못 통과시키지 않도록 비교 연산의 의미를 확인해야 합니다.

십진수 계산도 중요합니다. 사람에게 10으로 보이는 결과가 내부 부동소수점에서는 조금 작거나 크게 표현될 수 있습니다. 수치 표현과 계산 방식을 검토하고 최종 전송 문자열까지 일관되게 다루세요. 화면에 소수 둘째 자리로 보인다는 이유만으로 정확한 경계 통과를 확정하지 않습니다.

수량을 내린 뒤 재검사

stepSize에 맞추려고 수량을 내리면 금액이 줄어듭니다. 조정 전 금액이 하한을 넘었다고 조정 후에도 넘는다고 가정하지 마세요. 반대로 금액을 맞추려고 수량을 올리면 잔고 사용량과 사용자의 의도가 달라질 수 있습니다.

자동 조정은 단순한 표시 수정과 다릅니다. 주문 규모가 바뀌는 만큼 사용자가 정한 금액 한도와 거래 조건 안에서만 처리해야 합니다. 가능한 수량이 없다면 이유를 설명하고 요청을 중단하는 선택지도 필요합니다. 필터 오류를 피하는 것이 사용자 의사보다 우선할 수는 없습니다.

4. 시장가에는 어떤 가격을 사용하는가

시장가 주문은 지정가와 같은 명시적인 주문 price가 없기 때문에 필터 평가용 가격이 필요합니다. 현재 공식 문서는 유효한 비어 있지 않은 reference price가 있으면 이를 우선 사용한다고 설명합니다. 이것을 놓치고 항상 최근 몇 분 평균 가격만 사용한다고 쓰면 최신 설명을 충분히 반영하지 못합니다.

해당 reference price가 없으면 이전 avgPriceMins분 동안의 거래량 가중 평균 가격을 사용한다고 안내합니다. avgPriceMins가 0이면 마지막 가격을 사용합니다. 이 순서는 공식 필터 설명의 가격 선택 규칙이며 사용자의 계정 평균 매수가와는 관계가 없습니다.

화면의 현재가와 같다고 보장하지 않기

차트에 보이는 가격, 최우선 호가, 최근 체결 가격, 필터의 평가 기준은 서로 다른 자료일 수 있습니다. 화면 숫자 하나로 시장가 금액 검사를 정확하게 복제했다고 주장하면 안 됩니다. 특히 기준 가격의 적용 여부와 관측 시각을 구분해야 합니다.

평가 가격은 실제 주문이 최종적으로 체결되는 평균 가격을 보장하는 값도 아닙니다. 시장가 주문은 여러 가격대에서 체결될 수 있고 유동성과 변동의 영향을 받습니다. 필터 통과와 체결 비용·슬리피지는 별도의 질문입니다.

avgPriceMins를 시간 제한으로 오해하지 않기

avgPriceMins는 가격 평가에 쓰이는 과거 구간의 의미를 설명하는 항목입니다. 주문이 그 시간 동안 유지된다거나 해당 시간이 지나면 자동 취소된다는 뜻이 아닙니다. 주문의 생명주기와 필터 가격 산출 구간을 구분해야 합니다.

또한 reference price가 있는 경우의 우선 규칙을 고려해야 합니다. avgPriceMins가 응답에 있다고 해서 모든 상황에서 그 구간 평균이 실제 평가 기준이라고 단정하지 않습니다. 필드 하나를 떼어 읽기보다 현재 공식 규칙 전체를 적용합니다.

5. 시장가 적용 플래그를 읽는 절차

첫째, 실제 주문 종류가 MARKET인지 확인합니다. 둘째, 해당 심볼의 필터 종류를 확인합니다. 셋째, MIN_NOTIONAL이면 applyToMarket을, NOTIONAL이면 하한·상한 플래그를 각각 읽습니다. 넷째, 적용되는 조건에 필요한 가격 평가 규칙을 확인합니다.

이 과정에서 false를 해당 시장가 주문에 아무 제한도 없다는 의미로 넓히지 않아야 합니다. 특정 금액 필터의 특정 경계가 적용되지 않는다는 의미와 수량·잔고·기타 제한이 모두 사라진다는 의미는 다릅니다. 다른 조건은 그대로 확인해야 합니다.

하한과 상한이 독립적일 수 있음

가상의 NOTIONAL 응답에서 applyMinToMarket은 true, applyMaxToMarket은 false라고 가정해 보겠습니다. 이 경우 하한과 상한에 같은 적용 여부를 강제로 넣으면 문서가 표현한 구분을 잃습니다. 실제 값은 현재 심볼 응답에서 확인해야 합니다.

이 예시는 특정 거래쌍이 그런 조합을 사용한다고 주장하는 것이 아닙니다. 파서와 검증 로직이 두 플래그를 독립적으로 다루는지 확인하기 위한 설명입니다. 필드 이름의 차이를 유지하는 것이 구현과 진단 모두에 도움이 됩니다.

시장가를 수량 기준과 금액 기준으로 나누기

수량을 지정하는 시장가와 quoteOrderQty를 사용하는 금액 기준 시장가는 요청 의미가 다릅니다. 사용자가 입력한 값이 base 수량인지 quote 금액인지 먼저 확인해야 합니다. 같은 숫자 20이 들어 있어도 단위가 다르면 주문 의사는 전혀 달라집니다.

quoteOrderQty를 사용한다고 모든 필터 검사를 생략할 수 있는 것은 아닙니다. 지원 여부와 해당 요청 규격, 실제 실행 결과를 확인해야 합니다. 금액 입력 기능을 최소 금액 제한을 우회하는 방법으로 설명하지 않습니다.

6. 다섯 가지 계산 사례

예시 1. 수량은 맞지만 금액이 작음

가상 거래쌍의 최소 금액이 10 QUOTE이고 주문 가격이 20 QUOTE/BASE라고 가정합니다. 수량 0.4 BASE는 명목 금액 8 QUOTE이므로 금액 하한보다 작습니다. 수량 간격에 맞는 값이라는 사실만으로 이 문제를 해결할 수 없습니다.

확인 순서는 가격과 수량의 단위, 실제 minNotional, 최종 요청값입니다. 주문을 더 크게 만드는 것은 사용자의 투자 규모를 바꾸는 일이므로 자동으로 실행할 해결책이라고 볼 수 없습니다. 사용자가 정한 한도 내에서 가능한 요청인지 검토하거나 제한 이유를 알리는 방식이 필요합니다.

예시 2. 수량 정리 뒤 하한 아래로 내려감

가격 24 QUOTE/BASE, 조정 전 수량 0.42 BASE라면 곱은 10.08 QUOTE입니다. 그런데 허용 수량 간격에 맞추는 과정에서 0.4 BASE로 내려갔다면 금액은 9.6 QUOTE가 됩니다. 하한을 10 QUOTE로 가정하면 조정 후에는 조건을 충족하지 않습니다.

이 사례는 필터를 한 번씩만 확인하고 끝내는 구조의 한계를 보여줍니다. 최종 가격·수량으로 전체 검사를 다시 수행해야 합니다. 계산기를 통해 처음 확인한 10.08이라는 값이 최종 전송 금액이 아니라는 점을 로그에서도 구분해 두는 것이 좋습니다.

예시 3. 상한을 넘는 지정가 주문

가상의 maxNotional이 1,000 QUOTE이고 가격이 25 QUOTE/BASE라면 수량 50 BASE의 명목 금액은 1,250 QUOTE입니다. 최소 금액은 충분히 넘지만 상한 검사가 적용된다면 허용 범위를 벗어납니다. 최소 금액만 검사하는 구현은 이런 경우를 놓칩니다.

상한 초과를 보고 주문을 여러 개로 자동 분할하는 것도 별도 거래 정책입니다. 주문 개수 제한과 실제 실행 위험이 달라질 수 있기 때문입니다. 이 글의 계산 예시는 필터의 의미를 설명하며 제한 회피나 무조건적인 분할 주문을 권장하지 않습니다.

예시 4. 화면 가격과 평가 가격의 차이

화면에서 본 가격으로는 주문 금액이 10.1 QUOTE인데 필터 평가에 사용하는 기준 가격으로 계산하면 9.9 QUOTE가 되는 상황을 가정합니다. 하한 근처에서는 작은 가격 차이도 결과를 바꿀 수 있습니다. 시장가 평가 기준을 단순히 화면의 마지막 숫자로 대체할 수 없는 이유입니다.

reference price 존재 여부, 공식 가격 선택 규칙, 관측 시각, 최종 수량을 확인합니다. 기준값을 확인하지 못했다면 로컬 계산이 서버 판단과 같다고 보장하지 않아야 합니다. 오차를 숨기려고 임의의 고정 여유율을 공식 규칙처럼 제시하는 것도 피해야 합니다.

예시 5. quote 자산을 잘못 해석

가상의 거래쌍에서 quoteAsset이 BTC인데 minNotional을 USDT 금액처럼 읽었다고 가정합니다. 숫자만 같아도 단위가 다르므로 주문 규모에 대한 이해가 크게 달라질 수 있습니다. 최소 금액 필터를 읽을 때 거래쌍의 자산 구성을 함께 확인해야 하는 이유입니다.

화면에는 금액 옆에 표시 자산을 명확히 붙이고, 환산값을 보여준다면 원래 필터 단위와 구분합니다. 원화 환산은 별도 가격 자료와 시각을 필요로 하며 원래 필터의 단위를 바꾸지 않습니다. 환산 표시값을 다시 API 입력값으로 사용하는 실수를 피하세요.

7. 주문 전 실제 확인 절차

대상 시장과 입력 단위 확정

먼저 Spot인지 확인하고 정확한 symbol을 선택합니다. 다음으로 입력한 값이 수량인지 금액인지 구분합니다. base와 quote를 명시하지 않은 채 숫자만 전달하는 내부 함수는 혼동을 만들 수 있으므로 단위가 드러나는 구조를 사용하는 편이 좋습니다.

같은 코인이라도 거래쌍이 다르면 표시 자산과 규칙이 다를 수 있습니다. 다른 거래쌍에서 성공했던 최소 금액을 복사하지 않습니다. 기존 주문 성공 기록은 과거 결과이며 현재 대상의 필터를 대신하지 않습니다.

현재 필터를 조회하고 보관

Exchange Info의 symbols에서 정확한 심볼을 찾고 filters를 filterType으로 구분합니다. 최소·최대 금액과 시장가 플래그, avgPriceMins를 함께 읽습니다. 파라미터 하나만 저장하면 나중에 어떤 조건으로 평가했는지 복원하기 어렵습니다.

조회 시각과 출처도 저장해야 합니다. 최신 조회에 실패했는데 이전 값을 현재 확인한 값처럼 표시하지 않습니다. 자료가 없거나 파싱에 실패한 경우 임의 최소 금액을 넣어 정상으로 처리하는 대신 검증 불가 상태를 구분합니다.

최종 요청값으로 계산

가격 단위와 수량 단위를 맞춘 최종 값을 사용합니다. 계산을 위해 사용한 소수 표현과 실제 전송 표현이 같은지 확인합니다. 화면에서는 반올림한 값을 보여주더라도 검증과 요청에는 원래 정확한 값을 일관되게 사용해야 합니다.

지정가의 금액과 시장가의 평가 금액은 구분합니다. 시장가에서 평가용 기준 가격을 확인할 수 없는 상황이라면 단순한 추정값임을 기록해야 합니다. 추정이 가능한 것과 서버의 동일한 판정을 재현했다고 주장할 수 있는 것은 다릅니다.

다른 필터와 잔고도 확인

금액 조건을 만족한 뒤에도 가격 범위, 수량 범위, 지원 주문 종류, 계정 권한, 잔고 등 다른 조건이 남습니다. 금액 필터 통과를 주문 전체의 성공으로 표시하지 않습니다. 단계별로 어떤 검사가 통과했고 어떤 검사가 아직 확인되지 않았는지 구분하면 진단이 쉬워집니다.

일부 조건을 맞추려고 값을 바꿨다면 영향을 받는 다른 조건을 다시 검사합니다. 예를 들어 가격을 낮추면 매수 비용은 줄지만 최소 금액 아래로 내려갈 수 있습니다. 수량을 늘리면 금액 조건을 맞춰도 잔고 한도를 넘을 수 있습니다.

요청 이후 실제 결과 확인

서버의 접수 응답과 주문 상태, 실제 체결량·체결 금액을 확인합니다. 필터 평가에 사용한 금액과 실제 체결 결과를 같은 필드에 덮어쓰지 않는 편이 좋습니다. 두 값은 사전 조건과 사후 결과라는 서로 다른 역할을 합니다.

응답을 받지 못한 경우에는 주문이 없었다고 단정하지 않습니다. 원래 clientOrderId 등 식별자로 상태를 확인하는 절차가 필요합니다. 금액을 조금 바꾸어 바로 다시 보내는 행동은 원래 주문의 존재 여부를 해결하지 못하며 중복 주문으로 이어질 수 있습니다.

8. 오류가 발생했을 때의 진단 순서

먼저 실제 오류가 금액 필터와 관련되는지 확인합니다. “주문 실패”라는 문구만으로 최소 금액 문제라고 단정하지 마세요. 수량 단위, 가격 범위, 잔고, 권한, 시간 검증이 다른 이유일 수 있습니다. 코드와 메시지의 원문을 비밀 정보 없이 기록하는 것이 출발점입니다.

다음으로 최종 price와 quantity, quoteAsset, 적용 필터값을 한 줄로 정리합니다. 어떤 값으로 계산했는지 보이면 단위 혼동과 오래된 캐시를 찾기 쉬워집니다. 시장가라면 평가 가격을 어떻게 선택했는지도 별도 항목으로 확인합니다.

숫자 표시 오류와 실제 조건 오류

화면에서 10.00으로 보이는 값이 정확히 10이라는 뜻은 아닐 수 있습니다. 표시 반올림 때문에 하한보다 작은 값이 같아 보이는 경우를 생각해야 합니다. 반대로 문자열 뒤의 0이 많다는 이유만으로 값 자체가 다른 것도 아닙니다.

문제를 해결할 때는 원래 소수 문자열, 내부 계산값, 전송 문자열을 비교합니다. 필요한 진단 범위만 보관하고 API 키·서명·개인 계정 자료는 노출하지 않습니다. 공개 필터와 주문 형식만으로도 많은 계산 문제를 분석할 수 있습니다.

캐시 변경과 가격 변경

필터값이 바뀐 것인지 평가 가격이 달라진 것인지 구분해야 합니다. 둘 다 결과에 영향을 주지만 해결 방법은 다릅니다. 고정된 규칙 캐시를 갱신해야 하는 경우와 현재 시장 자료를 다시 확인해야 하는 경우를 같은 오류로 뭉뚱그리지 않습니다.

한 번 실패했다고 무한 조회를 시작하는 것도 바람직하지 않습니다. 호출 예산과 오류 유형을 고려해 재확인 조건을 정합니다. 정당한 필터 거절은 같은 요청을 빠르게 반복한다고 정상 요청으로 바뀌지 않습니다.

9. 부분 체결과 남은 금액을 읽는 방법

주문 제출 시의 명목 금액과 부분 체결 후 남은 주문 금액은 다른 시점의 값입니다. 최초 요청이 필터를 통과했다고 남은 수량의 모든 후속 작업도 같은 조건으로 처리된다고 일반화하지 않습니다. 취소·수정·새 주문 제출은 각 경로의 규칙을 확인해야 합니다.

예를 들어 일부 체결 후 잔량이 작아졌다고 가정해 보겠습니다. 기존 주문의 상태를 읽는 것과 그 잔량으로 새 주문을 만드는 것은 다릅니다. 새 주문에는 현재 규칙이 적용될 수 있으므로 원래 주문이 성공했다는 사실만으로 재주문 가능성을 확정할 수 없습니다.

취소가 체결을 되돌리지는 않음

남은 주문을 취소해도 이미 체결된 부분은 별도 기록으로 남습니다. 최소 금액 오류를 해결하려다가 과거 체결을 잊고 전체 목표 수량을 다시 주문하면 의도보다 큰 거래가 발생할 수 있습니다. 실제 체결량과 아직 실행하지 않은 목표량을 분리해야 합니다.

복구 계획에는 원래 주문 ID, 누적 체결량, 남은 주문 상태, 새 요청 여부가 연결되어야 합니다. 필터 계산은 이 전체 과정 중 한 부분입니다. 숫자 하나를 통과시키는 데 집중하다가 거래 의사의 중복 실행을 놓치지 마세요.

수수료와 소액 잔고

체결 후 남은 소액 자산이 현재 최소 주문 금액을 충족하지 못하는 상황은 원래 주문의 필터 통과와 별개의 문제입니다. 수수료 차감 자산과 실제 수령량, 현재 가격을 확인해야 합니다. 원래 주문 금액만으로 남은 잔고의 처분 가능성을 계산하지 않습니다.

이때 별도 전환 기능이 있더라도 지원 자산과 조건은 해당 서비스 안내를 확인해야 합니다. 금액 필터를 우회할 수 있다고 일반화하지 않습니다. 거래 필터 설명과 잔고 정리 서비스의 이용 조건을 구분해 안내하는 것이 정확합니다.

10. 복합 주문과 알고리즘에 적용할 때

부모 주문과 하위 주문이 있는 기능에서는 어느 단위에 어떤 조건이 적용되는지 해당 제품 문서를 확인해야 합니다. 전체 목표 금액이 크다는 이유만으로 모든 하위 주문이 일반 현물 주문과 같은 방식으로 통과한다고 추측해서는 안 됩니다. 제품별 실행 규칙이 추가될 수 있습니다.

TWAP처럼 주문을 나누는 기능에서도 목표 금액과 각 실행 단위의 의미를 구분해야 합니다. 이 글의 MIN_NOTIONAL 설명만으로 알고리즘의 최소 주문 크기나 자동 조정 방식을 만들어내지 않습니다. 확인 가능한 공식 기능 안내와 실제 주문 상세를 따로 읽어야 합니다.

취소 후 재주문과 수량 수정

기존 주문을 취소하고 새 주문을 만드는 것과 같은 주문의 수량을 줄이는 기능은 처리 구조가 다릅니다. 필터 적용이나 실패 결과도 경로별 문서를 확인해야 합니다. “수정”이라는 한 단어로 묶어서 같은 검사 규칙을 가정하지 마세요.

부분 실패가 가능한 흐름에서는 취소가 성공했는지 새 주문이 성공했는지 각각 확인합니다. 새 주문의 금액 오류가 보인다고 기존 주문이 반드시 남아 있다고 생각하면 안 됩니다. 반대로 요청 전체를 실패로 표시하고 다시 보내기 전에 실제 상태를 대조해야 합니다.

11. 검증용 사례를 만드는 방법

운영 주문을 반복하기 전에 계산 로직을 가상 데이터로 검토할 수 있습니다. 하한 바로 아래, 하한과 동일, 하한 바로 위, 상한과 동일, 상한 초과를 나누면 비교 연산의 실수를 찾기 쉽습니다. 여기에 수량 조정 전후와 quote 자산 변경 사례를 더할 수 있습니다.

시장가 적용 플래그는 하한·상한 조합을 독립적으로 점검합니다. reference price가 있는 경우와 없는 경우, avgPriceMins가 0인 경우도 의미를 구분해 검토합니다. 이 검증은 공식 서버 내부를 그대로 재현한다는 보장이 아니라 클라이언트 해석 오류를 줄이는 과정입니다.

결과를 통과·실패·확인 불가로 나누기

필요한 기준 가격을 알 수 없거나 규칙 자료가 오래된 상황을 무조건 통과 또는 실패 중 하나로만 표현하면 정보가 손실될 수 있습니다. 확인 불가 상태를 별도로 두면 무엇을 추가로 확인해야 하는지 드러납니다. 사용자 화면에도 추정값을 확정값처럼 표시하지 않는 것이 중요합니다.

최종 판단에는 관측 시각과 사용한 자료 버전을 남깁니다. 같은 주문 숫자라도 다른 시점의 기준 가격이나 필터로 판단하면 결과가 달라질 수 있기 때문입니다. 재현 가능한 진단 기록은 같은 문제를 반복해서 추측하는 시간을 줄여줍니다.

12. FAQ

Q1. 바이낸스 Notional Filter는 최소 코인 수량인가요?

아닙니다. 가격과 수량으로 계산한 주문 금액을 다룹니다. 최소 수량과 수량 간격은 다른 필터의 항목입니다. 두 조건을 모두 확인해야 하며 한쪽을 충족했다고 다른 쪽도 충족하는 것은 아닙니다.

Q2. 모든 거래쌍의 최소 금액은 같나요?

현재 대상 심볼의 실제 필터를 확인해야 합니다. 문서 예시 숫자나 다른 거래쌍의 값을 공통값으로 사용하지 않습니다. quoteAsset이 무엇인지도 함께 확인해야 같은 숫자의 단위를 정확히 해석할 수 있습니다.

Q3. MIN_NOTIONAL과 NOTIONAL은 같은가요?

전자는 최소 금액을, 후자는 허용 금액 범위의 하한과 상한을 설명합니다. 시장가 적용 플래그도 다릅니다. 실제 응답의 filterType과 각 필드를 기준으로 처리해야 합니다.

Q4. 지정가 금액은 어떻게 계산하나요?

기본적으로 최종 제출 가격에 최종 제출 수량을 곱합니다. 수량이나 가격을 조정했다면 다시 계산해야 합니다. 계산에 쓰는 단위와 실제 전송값이 일치하는지도 확인하세요.

Q5. 시장가에는 가격이 없는데 어떻게 검사하나요?

현재 문서는 reference price가 있으면 이를 우선하고, 없으면 지정된 과거 구간의 거래량 가중 평균 가격을 사용하는 흐름을 설명합니다. avgPriceMins가 0이면 마지막 가격을 사용합니다. 실제 체결 평균 가격의 보장은 아닙니다.

Q6. applyToMarket이 false면 시장가 제한이 없나요?

해당 최소 금액 필터의 시장가 적용 여부를 뜻합니다. 수량·잔고·권한 등 모든 다른 제한이 사라지는 것은 아닙니다. 하나의 플래그를 주문 전체의 무제한 허용으로 해석하지 않습니다.

Q7. applyMinToMarket과 applyMaxToMarket은 왜 나뉘나요?

NOTIONAL의 시장가 하한 적용과 상한 적용을 각각 표현하기 때문입니다. 두 값을 같은 것으로 합치지 말고 실제 응답대로 읽어야 합니다. 한쪽 조건만 보고 전체 시장가 검사를 결정하면 잘못된 판단이 될 수 있습니다.

Q8. avgPriceMins는 주문 유지 시간인가요?

아닙니다. 필터 평가 가격의 과거 구간과 관련된 항목입니다. 주문 취소·만료 시간이나 체결 대기 시간을 정하는 값이 아닙니다. reference price 우선 규칙도 함께 확인해야 합니다.

Q9. 최소 금액과 정확히 같으면 통과하나요?

공식 금액 조건은 하한 이상입니다. 다만 실제 숫자가 정확히 같은지, 다른 필터와 잔고 조건이 충족되는지는 별도로 확인해야 합니다. 화면 반올림값만으로 경계값 일치를 확정하지 마세요.

Q10. 수량을 올리면 항상 해결되나요?

금액 하한만 보면 증가가 도움이 될 수 있지만 잔고·상한·사용자 주문 한도에 영향을 줍니다. 임의로 거래 규모를 늘리는 대응은 적절하지 않습니다. 승인된 범위에서 최종 조건을 다시 확인해야 합니다.

Q11. quoteOrderQty를 쓰면 필터를 무시할 수 있나요?

금액 기준 입력은 요청 의미가 다른 것이며 필터 우회 기능이 아닙니다. 지원 여부와 해당 API 규격을 확인해야 합니다. 실제 접수와 체결 결과도 별도로 확인하세요.

Q12. 부분 체결 뒤 남은 수량을 바로 재주문해도 되나요?

기존 주문 상태와 이미 체결된 양을 먼저 확인해야 합니다. 잔량으로 새 주문을 만들면 현재 규칙을 다시 충족해야 할 수 있습니다. 원래 전체 목표량을 그대로 다시 보내 중복 거래가 생기지 않도록 주의합니다.

Q13. 필터 통과는 슬리피지가 작다는 뜻인가요?

아닙니다. 주문 조건 검사와 실제 체결 품질은 다른 문제입니다. 시장가의 여러 가격대 체결, 호가 깊이, 스프레드와 변동은 별도로 확인해야 합니다. 금액 필터는 수익이나 유리한 가격을 보장하지 않습니다.

Q14. 금액 오류가 나면 즉시 같은 주문을 반복하나요?

먼저 오류 유형과 최종 값, 현재 규칙을 확인해야 합니다. 같은 잘못된 요청을 반복해도 원인이 해결되지 않습니다. 응답 유실로 결과가 불명확하다면 원래 주문 상태를 확인하는 절차가 우선입니다.

Q15. 다음에는 무엇을 확인하면 좋나요?

주문 금액 조건 다음에는 가격 자체가 동적으로 허용 범위 안에 있는지 보는 PERCENT_PRICE 계열로 이어집니다. 수량과 금액이 맞아도 가격 범위를 벗어날 수 있으므로 서로 다른 필터를 구분하는 데 도움이 됩니다.

13. 실행 체크리스트

• 대상이 Spot인지 확인했다.
• 정확한 symbol과 quoteAsset을 확인했다.
• 수량 입력과 금액 입력을 구분했다.
• 현재 MIN_NOTIONAL·NOTIONAL 필드를 읽었다.
• 하한과 상한을 각각 검사한다.
• 시장가 적용 플래그를 독립적으로 해석한다.
• reference price 우선 규칙을 확인했다.
• avgPriceMins를 주문 유지 시간으로 해석하지 않는다.
• 가격·수량 조정 후 금액을 다시 계산한다.
• 소수 계산과 최종 직렬화값을 대조한다.
• 잔고·다른 필터·권한도 함께 확인한다.
• 부분 체결 후 원래 목표량을 중복 전송하지 않는다.
• 필터값의 조회 시각과 출처를 기록한다.
• 실제 접수·체결 결과를 별도로 보관한다.

핵심 정리

바이낸스 Notional Filter를 이해하면 “잔고가 있는데 왜 주문이 안 되는가”를 더 구체적인 질문으로 나눌 수 있습니다. 수량, 가격, 금액, 표시 자산, 시장가 적용 여부를 구분하고 최종 요청값으로 확인하는 것이 핵심입니다.

이 글은 거래 규칙을 설명하는 정보성 자료입니다. 특정 주문의 수락·체결이나 투자 성과를 보장하지 않습니다. 실제 이용 전 최신 Binance 공식 문서와 대상 거래쌍의 현재 필터를 확인하세요.