바이낸스 Percent Price Filter 뜻 2026｜동적 가격 범위·매수 매도 배수·오류 확인

바이낸스 Percent Price Filter 뜻 2026｜동적 가격 범위·매수 매도 배수·오류 확인

바이낸스 Percent Price Filter는 기준이 되는 가격에 배수를 적용해 주문 가격의 허용 범위를 정하는 현물 거래 규칙입니다. 소수점 자릿수나 가격 간격을 맞추는 PRICE_FILTER와 다릅니다. 가격이 tickSize에 맞더라도 동적인 가격 범위를 벗어나면 다른 조건에서 거절될 수 있습니다.

이름에 Percent가 들어 있지만 사용자가 정한 수익률 목표나 수수료율을 뜻하지 않습니다. 또한 시장가 주문의 실제 체결 가격을 원하는 범위 안에 보장하는 설정도 아닙니다. 무엇을 기준으로 어떤 주문 가격을 검사하는지 구분하는 것이 중요합니다.

이 글은 2026년 10월 28일 확인한 Binance Spot 공식 Filters 문서의 PERCENT_PRICE와 PERCENT_PRICE_BY_SIDE를 기준으로 합니다. 선물의 가격 제한이나 별도 실행 규칙을 같은 기능으로 합치지 않습니다. 아래 배수와 가격은 설명용 가정이며 특정 심볼의 실제 현재 설정을 의미하지 않습니다.

1. 정적인 가격 단위와 동적인 범위

가격 100.01이 허용되는 소수 단위에 맞는지 묻는 것과 현재 기준 가격에 비해 너무 높거나 낮은지 묻는 것은 다릅니다. 전자는 가격 간격의 문제이고 후자는 기준 가격과 배수의 문제입니다. 서로 다른 질문이므로 두 검사를 모두 확인해야 할 수 있습니다.

PRICE_FILTER는 minPrice, maxPrice, tickSize를 설명합니다. PERCENT_PRICE 계열은 기준 가격에 multiplier를 곱한 범위를 설명합니다. 고정된 최소·최대 숫자처럼 보이는 자료와 현재 가격을 따라 달라지는 경계를 한 필드에 합쳐 저장하면 원인을 추적하기 어렵습니다.

범위는 가격 변화에 따라 달라질 수 있음

배수가 그대로여도 기준 가격이 바뀌면 계산한 하한과 상한이 바뀝니다. 어제 허용됐던 숫자가 오늘도 같은 조건을 충족한다고 보장할 수 없는 이유입니다. 필터값의 최신 여부와 기준 가격의 최신 여부를 각각 확인해야 합니다.

가격 밴드를 계산했다는 사실이 미래의 수락을 보장하지도 않습니다. 조회와 요청 전송 사이에 조건이 달라질 수 있습니다. 로컬 계산은 사전 점검이며 실제 응답과 주문 상태를 확인하는 단계가 반드시 뒤따라야 합니다.

변동률·수익률과의 차이

multiplierUp이 가상으로 1.2라면 기준 가격에 1.2를 곱해 상단 경계를 계산한다는 의미입니다. 이를 1.2% 수수료나 20% 수익 보장으로 해석하면 안 됩니다. 배수는 가격 검사식에 들어가는 값이지 투자 성과를 표현하는 값이 아닙니다.

하단 배수 역시 기준 대비 가격 범위를 계산하는 요소입니다. 같은 단어가 여러 화면에서 사용되더라도 필드의 정확한 이름과 문맥을 읽어야 합니다. Slippage Tolerance나 손절 비율을 이 필터의 배수와 바꾸어 사용하지 않습니다.

2. PERCENT_PRICE의 공식 구조

공식 Filters 문서는 PERCENT_PRICE가 이전 거래 가격을 바탕으로 주문 가격의 유효 범위를 정의한다고 설명합니다. 상단에는 multiplierUp, 하단에는 multiplierDown을 사용합니다. 가격이 상단 이하이고 하단 이상인지 확인하는 구조입니다.

설명을 단순화해 평가에 쓰이는 가격을 R이라고 쓰면 하한은 R×multiplierDown, 상한은 R×multiplierUp입니다. 이는 공식 공개 조건을 기호로 정리한 것입니다. R을 어떻게 선택하는지는 별도의 공식 규칙을 따라야 하며 임의로 현재가나 내 매수가를 넣으면 안 됩니다.

기준 가격 선택 순서

현재 문서는 심볼에 비어 있지 않은 reference price가 있으면 이를 필터 평가에 사용한다고 설명합니다. 그 값이 없으면 이전 avgPriceMins분의 거래량 가중 평균 가격을 사용합니다. avgPriceMins가 0이면 마지막 가격을 사용한다고 안내합니다.

따라서 “항상 최근 몇 분 평균 가격으로 계산한다”는 설명만으로는 현재 규칙을 충분히 반영할 수 없습니다. reference price 우선 조건과 fallback 관계를 함께 읽어야 합니다. 기준 가격의 내부 구성 방식까지 공식적으로 확인하지 못했다면 별도 공식을 만들어 넣지 않습니다.

평균 가격의 의미를 과도하게 넓히지 않기

평균이라는 단어가 있다고 단순 산술평균이나 캔들의 종가 평균을 대신 넣을 수 있는 것은 아닙니다. 공식 설명은 거래량 가중 평균을 언급합니다. 어떤 자료를 어떤 구간으로 계산했는지 모르면 서버의 평가 기준을 정확히 재현했다고 말할 수 없습니다.

내 계정의 평균 매수가나 포지션 진입 가격도 이 기준과 다릅니다. 개인 계정의 손익 기준과 시장 필터의 평가 기준은 목적이 다릅니다. 이름이 비슷한 가격 자료를 연결하기 전에 자료의 출처와 사용 목적을 확인하세요.

3. PERCENT_PRICE_BY_SIDE의 차이

PERCENT_PRICE_BY_SIDE는 매수와 매도에 서로 다른 범위를 적용할 수 있도록 필드를 나눕니다. BUY에는 bidMultiplierUp과 bidMultiplierDown을, SELL에는 askMultiplierUp과 askMultiplierDown을 사용합니다. side를 읽지 않고 공통 배수 하나만 사용하는 구현은 의미를 잃을 수 있습니다.

평가 기준 가격을 선택하는 흐름은 현재 공식 설명에 따라 확인합니다. reference price가 있으면 우선 사용하고 없을 때 평균 구간 규칙을 적용합니다. 매수·매도 배수 구분과 기준 가격 선택은 각각 별도 단계로 생각하면 이해하기 쉽습니다.

bid와 ask를 주문 방향에 연결

이 필터에서 bid 계열 배수는 BUY 주문 검사와 연결됩니다. ask 계열 배수는 SELL 주문 검사와 연결됩니다. 호가창에서 어떤 줄을 클릭했는지나 화면의 색상만으로 판단하지 말고 실제 주문의 side 값을 기준으로 해석해야 합니다.

예를 들어 매수 주문을 만들면서 매도 측 배수를 사용하면 정상 범위를 잘못 계산할 수 있습니다. 내부 함수의 인자에 side를 명시하고, 대소문자·열거값을 정확히 처리하는 것이 도움이 됩니다. 알 수 없는 side를 임의로 BUY로 바꾸는 기본 동작은 피해야 합니다.

두 방향의 범위가 대칭이라는 가정 금지

매수 상단과 매도 하단이 서로 대칭이라고 보장하지 않습니다. 실제 응답에 네 개의 배수가 있는 이유를 유지해야 합니다. 공식 예시의 숫자 관계를 모든 거래쌍의 고정 규칙으로 복사해서는 안 됩니다.

사용자 화면에 범위를 표시한다면 현재 주문 방향과 기준 시각도 함께 보여주는 편이 좋습니다. 매수 화면에서 계산한 밴드를 매도 화면으로 전환한 뒤 그대로 재사용하면 잘못된 안내가 됩니다. 방향 전환은 단순 색상 변경이 아니라 검증 조건이 바뀌는 사건입니다.

표의 R은 공식 규칙에 따라 선택한 평가 가격입니다. 수식이 간단하다고 실제 R을 추정값으로 바꾸어도 동일한 결과가 나온다는 뜻은 아닙니다. 값이 확인되지 않으면 추정 범위와 확정 규칙을 구분해야 합니다.

4. 다섯 가지 범위 계산 사례

예시 1. 공통 가격 범위 계산

가상의 평가 가격 R이 100 QUOTE이고 multiplierDown이 0.8, multiplierUp이 1.2라고 가정합니다. 하한은 80, 상한은 120 QUOTE입니다. 이 금액 범위는 주문 수량과 곱한 총액이 아니라 주문 가격 자체의 범위입니다.

가격 110은 이 예시의 범위 안이고 125는 상단을 벗어납니다. 하지만 110이 범위 안이라는 사실만으로 tickSize, 수량, 잔고, 권한까지 모두 통과한 것은 아닙니다. 하나의 검사 결과를 전체 주문 성공으로 표시하지 않아야 합니다.

예시 2. 매수와 매도 배수 차이

R이 100이고 BUY 범위가 90~110, SELL 범위가 80~130이 되도록 가상의 배수를 정했다고 생각해 보겠습니다. 같은 가격 120이라도 BUY 기준과 SELL 기준의 판단은 달라집니다. 방향을 무시한 공통 범위로 검사하면 결과가 틀릴 수 있습니다.

이 숫자는 실제 심볼 설정이 아닙니다. side와 네 배수 필드를 독립적으로 다뤄야 한다는 원리를 설명하기 위한 예시입니다. 운영에서는 현재 응답의 값을 사용하고 화면의 매수·매도 선택과 실제 요청 side가 일치하는지도 확인합니다.

예시 3. 배수는 같지만 기준 가격 변화

상단 배수가 1.2로 유지되어도 R이 100에서 95로 바뀌면 상한은 120에서 114로 내려갑니다. 이전에 계산한 상한 120만 저장해 두면 현재 범위를 잘못 안내할 수 있습니다. 규칙값이 바뀌지 않았다는 사실과 계산 결과가 그대로라는 사실은 다릅니다.

이때 캐시에는 배수의 조회 시각과 평가 가격의 관측 시각을 나누어 기록할 수 있습니다. 둘 중 무엇이 오래됐는지 알아야 적절한 자료를 갱신할 수 있습니다. 모든 오류를 필터 변경으로 해석하거나 모든 오류를 시장 가격 변화로 해석하지 마세요.

예시 4. 가격 간격은 맞지만 범위 밖

가상의 tickSize가 0.01이고 동적 상한이 110이라고 가정합니다. 가격 110.50은 0.01 간격에는 맞지만 상한을 넘습니다. 소수점 자릿수와 배수 조건을 통과했다는 이유로 동적 범위를 생략할 수 없는 사례입니다.

해결을 위해 가격을 임의로 110으로 바꾸는 행동은 사용자의 지정가 의사를 변경합니다. 자동으로 조정할 수 있는 범위가 사전에 정해져 있는지 확인해야 합니다. 단순한 오류 제거보다 사용자가 어떤 가격으로 주문하려 했는지를 보존하는 것이 중요합니다.

예시 5. 마지막 가격과 reference price 차이

화면의 마지막 체결 가격은 102인데 공식 필터가 사용하는 reference price는 100인 가상 상황을 생각해 볼 수 있습니다. 상단 배수가 1.1이면 화면 가격을 기준으로 한 계산은 112.2, 실제 기준에 따른 계산은 110입니다. 기준 자료를 잘못 선택하면 경계가 달라집니다.

현재 규칙에서 어떤 가격이 우선되는지 확인해야 하며, 값이 없을 때의 fallback도 구분합니다. 이 예시는 특정 시장에서 두 가격이 그렇게 차이 난다는 주장도 아니고 reference price 내부 공식을 설명하는 것도 아닙니다. 자료 선택의 중요성을 보여주는 계산입니다.

5. Exchange Info에서 무엇을 확인하나

정확한 현물 symbol을 확인한 뒤 filters 배열에서 해당 filterType을 찾습니다. 배열 순서에 의존하지 않고 이름으로 구분해야 합니다. PERCENT_PRICE인지 PERCENT_PRICE_BY_SIDE인지에 따라 필요한 필드가 달라집니다.

배수 문자열을 읽을 때 1.2를 1.2%로 변환하지 않습니다. 공식 식에 들어가는 배수 그대로 해석합니다. 화면 설명을 위해 퍼센트 차이로 환산할 수는 있지만 원본 배수와 구분해야 하며 계산 의미를 바꾸면 안 됩니다.

적용 대상과 값의 출처 보존

심볼마다 반환 규칙이 다를 수 있으므로 다른 심볼의 배수를 재사용하지 않습니다. 같은 코인의 다른 quote 거래쌍도 별도 대상입니다. 저장 구조에는 symbol과 필터 종류, 조회 시각을 함께 넣어 잘못된 연결을 줄일 수 있습니다.

예시 JSON은 구조를 이해하는 자료입니다. 실제 현재 값을 확인하지 않은 상태에서 문서 예시를 모든 계정의 한도로 안내하지 마세요. 값이 바뀔 수 있는 정보와 개념적으로 안정적인 설명을 구분해서 관리하는 것이 좋습니다.

없는 필터와 읽지 못한 필터

필터가 반환되지 않은 경우와 응답을 파싱하지 못한 경우는 다릅니다. 파싱 실패를 규칙 없음으로 처리하면 필요한 검사를 생략할 수 있습니다. 정상 응답인지, 정확한 심볼을 선택했는지, 예상 구조가 유지되는지 확인해야 합니다.

알 수 없는 필터 종류가 추가됐을 때의 정책도 필요합니다. 임의로 무시한 채 주문이 유효하다고 확정하지 않고 공식 문서를 확인할 수 있게 기록합니다. 모든 필터가 반드시 존재한다고 가정하는 파서도 수정에 취약하므로 선택적 항목을 올바르게 다룹니다.

6. 주문 전 확인 절차

1단계: 제품과 주문 방향 확인

현물 문서를 선물 주문에 그대로 적용하지 않습니다. 실제 요청의 symbol과 side, 주문 종류를 확인합니다. 화면에서 선택한 방향과 전송 데이터의 방향이 다르면 계산이 맞더라도 잘못된 검사일 수 있습니다.

사용자가 입력한 가격이 어떤 자산 단위인지도 확인합니다. 다른 quote 자산의 가격을 같은 숫자로 복사하면 의미가 달라집니다. 환산값을 표시할 때는 원래 주문 가격과 환산 가격을 분리하고 어느 값을 API에 보내는지 명확히 합니다.

2단계: 현재 필터값 확보

PERCENT_PRICE에는 상·하단 배수, BY_SIDE에는 방향별 네 배수가 필요합니다. avgPriceMins와 현재 공식 기준 가격 선택 규칙도 함께 확인합니다. 배수 하나만 저장해 두면 나머지 조건을 추측하게 될 수 있습니다.

캐시를 사용하는 경우 마지막 성공 갱신 시각을 확인합니다. 최근 조회 실패가 있었다면 이전 값을 현재 확인값처럼 표시하지 않습니다. 규칙 자료가 최신인지 알 수 없는 상황에서는 검증의 한계를 드러내야 합니다.

3단계: 평가 가격의 성격 확인

reference price의 존재 여부와 현재 공식 조회·자료 제공 방식을 확인합니다. 없을 때 사용하는 평균 구간 규칙도 확인합니다. 공식적으로 확인하지 않은 계산 방식을 임의로 도입해 서버와 동일하다고 표현하지 않습니다.

클라이언트에서 추정 가격을 사용한다면 진단용 추정이라는 점을 구분합니다. 최종 주문 판단은 서버 응답으로 확인해야 합니다. 확인되지 않은 기준 가격에 작은 임의 여유율을 더하는 방식은 정확성 문제를 숨길 수 있습니다.

4단계: 방향별 경계 계산

해당 side에 맞는 하한과 상한을 계산합니다. 공식 조건의 이상·이하 관계를 그대로 사용하고 숫자 계산의 정밀도를 확인합니다. 표시용 반올림값을 다시 검사값으로 가져오지 않는 편이 좋습니다.

가격 범위를 통과한 뒤에는 PRICE_FILTER와 수량·금액 조건을 추가 확인합니다. 어느 단계에서 값을 조정했다면 최종 값으로 다시 검사해야 합니다. 필터마다 각각 다른 임시값을 검사하고 마지막에 서로 다른 값을 전송하는 구조를 피하세요.

5단계: 실제 응답과 상태 확인

요청 직전 계산이 통과됐어도 서버에서 거절될 수 있으므로 실제 코드와 메시지를 읽습니다. 가격이 변했는지, 다른 규칙이 실패했는지, 전송값이 달라졌는지 확인합니다. 사전 계산 결과가 정상이라는 이유로 오류 응답을 무시하지 않습니다.

응답이 유실된 경우에는 새 가격으로 바로 재전송하기 전에 원래 주문이 존재하는지 확인합니다. 가격 필터 오류와 결과 불명확은 서로 다른 상태입니다. 원래 주문 식별자를 보존해 중복 주문을 방지하는 복구 절차가 필요합니다.

7. PRER·가격 보호·슬리피지와 구분

공식 문서가 reference price 설명을 위해 다른 실행 규칙 문서를 연결하더라도 모든 기능이 하나의 필터라는 뜻은 아닙니다. PERCENT_PRICE 계열의 주문 가격 검사를 설명하는 것과 PRER의 실행 규칙 전체를 설명하는 것은 범위가 다릅니다.

따라서 reference price를 사용한다는 공통점만으로 특정 주문의 잔량 처리, 만료 상태, 체결 순서까지 추측하지 않습니다. 그런 동작은 해당 기능의 최신 공식 문서에서 확인해야 합니다. 이미 알고 있는 기능의 설명을 비슷한 이름의 다른 기능에 복사하지 마세요.

Slippage Tolerance와의 차이

슬리피지 관련 설정은 해당 제품의 주문 실행 조건을 다룹니다. Percent Price Filter는 공식 필터에서 정의한 주문 가격 범위를 검사합니다. 둘을 동일한 보호 장치로 설명하면 사용자가 필터 통과를 체결 가격 보장으로 오해할 수 있습니다.

가격 범위 안의 지정가 주문도 미체결 상태로 남을 수 있습니다. 시장 상황과 상대 주문, 우선순위가 실제 체결에 영향을 줍니다. 이 필터가 있다고 시장 충격이나 슬리피지가 완전히 제거되는 것은 아닙니다.

선물 Price Protection과의 차이

같은 Binance 안에서도 현물 필터와 선물 조건부 주문의 가격 보호는 제품과 작동 단계가 다릅니다. Mark Price·Last Price를 사용하는 다른 기능의 설명을 현물 PERCENT_PRICE의 기준 가격으로 대체하지 않습니다.

용어가 비슷할수록 제품, 경로, 필드 이름을 먼저 적어두면 혼동을 줄일 수 있습니다. 외부 도구에서 한글로 모두 “가격 제한”이라고 표시하더라도 내부에서 어떤 규칙을 의미하는지 확인해야 합니다. 번역 문구 하나만으로 동작을 확정하지 마세요.

8. 흔한 오류와 해결 방향

가격 간격을 맞췄는데 거절되면 동적 범위와 다른 필터를 확인합니다. 수량을 크게 바꾸는 것은 가격 범위 문제를 직접 해결하지 못할 수 있습니다. 오류가 요구하는 항목을 정확히 구분하는 것이 첫 단계입니다.

BUY만 실패하거나 SELL만 실패한다면 BY_SIDE의 방향 선택과 배수 연결을 확인할 수 있습니다. 두 방향을 같은 상·하단으로 처리했는지 점검하세요. 실제 원인은 다른 조건일 수도 있으므로 오류 메시지와 전송값을 함께 봅니다.

오래된 경계값을 고정 저장

배수와 기준 가격을 곱한 결과만 저장하면 그 경계가 언제 계산됐는지 알기 어렵습니다. 가격 자료가 바뀌어도 과거 상한을 계속 사용할 수 있습니다. 원본 배수, 기준 자료, 계산 시각을 함께 남겨야 진단이 가능합니다.

화면에 범위를 보여줄 때는 현재 추정인지 마지막 확인값인지 구분합니다. 연결이 끊긴 동안 마지막 숫자를 계속 현재값처럼 보이게 하지 않는 것이 좋습니다. 단순히 화면이 움직인다는 사실만으로 모든 기준 자료가 갱신된다고 가정하지 않습니다.

배수와 퍼센트 변환 실수

1.2를 0.012로 바꾸거나 120으로 바꾸면 가격 경계가 크게 달라집니다. API 필드가 어떤 단위의 값인지 먼저 읽고 필요한 변환을 한 곳에서만 수행합니다. 표시용 문구를 만들기 위한 변환과 검증용 배수를 분리하세요.

입력 문자열에 붙은 표시 기호를 제거하는 과정에서도 값이 달라질 수 있습니다. 원본 응답은 그대로 보존하고 내부 계산용 값의 형식을 명시하면 추적하기 쉽습니다. 검증과 전송 과정에서 서로 다른 변환 규칙을 사용하지 않습니다.

9. 경계값과 십진수 처리

공식 조건은 상단 이하와 하단 이상입니다. 경계와 정확히 같은 가격을 어떻게 처리하는지 테스트하면 비교 연산 오류를 찾기 쉽습니다. 다만 실제 기준 가격의 시각이 달라지면 같은 주문 가격이라도 검사 결과가 달라질 수 있다는 점을 함께 고려해야 합니다.

계산한 상한이 tickSize에 맞지 않을 수 있습니다. 동적 경계와 주문 가격 간격을 동시에 충족하는 실제 가격이 무엇인지 따로 확인해야 합니다. 경계를 표시할 때 편의를 위해 반올림한 숫자를 그대로 주문 가능 가격으로 안내하면 잘못된 결과가 나올 수 있습니다.

조정 방향은 거래 의사와 연결

매수 지정가를 높이거나 매도 지정가를 낮추는 것은 체결 의사와 비용에 영향을 줍니다. 필터를 통과시키기 위한 자동 수정이라고 해서 영향이 없는 것은 아닙니다. 사용자가 허용한 조정 범위와 절차를 정하고 변경 전후 값을 명확히 보여주는 편이 좋습니다.

일부 도구는 입력값을 조용히 정리할 수 있으므로 실제 전송값을 확인할 수 있는 기록이 유용합니다. 사용자 화면의 원래 값, 내부 보정값, 최종 요청값을 구분하면 예상과 다른 주문이 왜 만들어졌는지 추적할 수 있습니다. 이 글은 임의 가격 변경을 권장하지 않습니다.

10. 변경·재연결·캐시 운영

가격 데이터 연결이 끊기면 마지막 평가 자료가 오래될 수 있습니다. 메타데이터 조회는 정상이어도 가격 자료가 오래된 상황이 가능하므로 두 상태를 따로 관리해야 합니다. “API 연결 정상” 하나의 표시로 모든 자료의 신선도를 표현하지 않는 편이 좋습니다.

재연결 뒤에는 새 가격을 하나 받았다는 사실뿐 아니라 필요한 자료가 완전한지 확인합니다. 특정 기준 자료의 제공 방식은 공식 문서를 따라야 합니다. 연결 복구를 가격 판단 복구와 동일하게 처리하면 오래된 계산 결과가 계속 사용될 수 있습니다.

변경 이력을 남기는 이유

배수 변경과 기준 가격 변화를 구분하면 오류 원인을 설명하기 쉽습니다. 규칙이 바뀌지 않았는데 주문이 실패했다고 반드시 서비스 장애인 것은 아닙니다. 반대로 시장이 조용해 보여도 규칙이나 권한 조건이 달라졌을 수 있습니다.

로그에는 공개 필터값과 관측 시각, 최종 요청 가격, 오류 분류처럼 필요한 자료를 남길 수 있습니다. 비밀 키나 전체 인증 헤더를 기록할 필요는 없습니다. 개인 계정 자료를 외부에 공유할 때는 필요한 범위만 남겨야 합니다.

동일 요청의 반복을 줄이기

정상적인 규칙 거절에 대해 즉시 동일 요청을 반복하면 호출 예산만 소모할 수 있습니다. 어떤 자료가 바뀌었을 때 재평가할지 정하는 편이 낫습니다. 기준 가격이 바뀌었는지, 사용자 가격 의사가 바뀌었는지, 규칙 자료가 갱신됐는지를 확인해야 합니다.

재시도 전에는 원래 주문 상태를 확인해야 하는 상황인지도 분류합니다. 명확한 거절 응답과 네트워크 오류는 다릅니다. 모든 실패를 한 종류로 처리하면 필터 진단과 중복 주문 방지 모두 어려워집니다.

11. 검증 사례 구성

가상의 R과 배수로 정상 범위, 하한 바로 아래, 하한과 동일, 상한과 동일, 상한 바로 위를 나눠 확인할 수 있습니다. BY_SIDE에서는 같은 가격을 BUY와 SELL 양쪽에 적용해 방향 선택을 검증합니다. 실제 자금을 사용하는 주문 없이도 계산 논리의 상당 부분을 점검할 수 있습니다.

reference price가 있는 경우와 없는 경우, avgPriceMins가 0인 경우를 각각 구분합니다. 단순히 함수가 숫자를 반환하는지보다 어떤 자료를 선택했는지 확인해야 합니다. 잘못된 자료로 정확한 곱셈을 해도 전체 판단은 틀릴 수 있습니다.

테스트와 운영의 차이

가상 계산 검증이 통과했다고 실제 서버와 항상 같은 결과를 낸다고 보장할 수는 없습니다. 운영에서는 지연과 자료 변경, 다른 필터가 함께 작용합니다. 테스트의 목적은 내부 논리 오류를 줄이는 것이며 실제 응답 확인을 생략하는 근거가 아닙니다.

운영에 반영한 뒤에는 거절 유형이 어떻게 바뀌었는지 관찰합니다. 가격 오류가 줄었지만 금액 오류가 늘었다면 자동 조정이 다른 조건에 영향을 줬을 수 있습니다. 최종 요청 전체를 기준으로 검토해야 한 문제를 해결하면서 다른 문제를 만들지 않습니다.

12. FAQ

Q1. 바이낸스 Percent Price Filter는 수수료율인가요?

아닙니다. 기준 가격에 배수를 적용해 주문 가격의 허용 범위를 검사하는 규칙입니다. 수수료나 수익률, 개인 계정의 손익과 구분해야 합니다. 필드 이름과 공식 계산 조건을 함께 읽으세요.

Q2. PRICE_FILTER와 무엇이 다른가요?

PRICE_FILTER는 가격의 최소·최대·간격을 다룹니다. PERCENT_PRICE 계열은 현재 평가 기준 가격과 배수에 따른 범위를 다룹니다. 가격 간격을 맞춰도 동적 범위 조건에서 실패할 수 있습니다.

Q3. 항상 최근 평균 가격을 사용하나요?

현재 공식 설명은 비어 있지 않은 reference price가 있으면 이를 우선 사용합니다. 없을 때 과거 avgPriceMins 구간의 거래량 가중 평균을 사용하며 0이면 마지막 가격을 사용합니다. 우선순서를 생략하지 않아야 합니다.

Q4. multiplierUp 1.2는 1.2%인가요?

공식 식에 사용하는 배수 1.2입니다. 기준 가격의 1.2배로 상단을 계산하는 의미이지 1.2% 수수료가 아닙니다. 표시용 퍼센트 환산과 원본 배수는 구분해야 합니다.

Q5. BY_SIDE는 왜 필요한가요?

BUY와 SELL에 다른 배수 범위를 표현하기 위해 필드가 나뉩니다. 실제 주문 방향에 맞는 bid 또는 ask 계열 배수를 사용해야 합니다. 양쪽이 항상 대칭이라고 가정하지 않습니다.

Q6. 매수 주문에는 askMultiplier를 쓰나요?

이 필터의 공식 BUY 조건에는 bidMultiplierUp·bidMultiplierDown이 사용됩니다. SELL에는 ask 계열을 사용합니다. 호가창에서 선택한 줄보다 실제 요청 side와 공식 필드 연결을 기준으로 판단하세요.

Q7. 내 평균 매수가를 기준으로 계산하나요?

아닙니다. 개인 계정의 평균 매수 가격과 시장 필터의 평가 기준은 다른 자료입니다. 공식 기준 가격 선택 규칙을 따라야 하며 계정 손익 기준으로 바꾸어 적용하면 안 됩니다.

Q8. avgPriceMins가 0이면 필터가 꺼지나요?

현재 설명에서는 reference price가 없는 경우 마지막 가격을 사용하는 의미입니다. 필터 전체가 비활성화된다는 뜻으로 해석하지 않습니다. 각 필드의 0 값 의미는 해당 규칙별로 확인해야 합니다.

Q9. 범위 안이면 바로 체결되나요?

아닙니다. 가격 조건 통과와 실제 체결은 다릅니다. 다른 필터·계정 조건도 필요하며 상대 주문과 우선순위에 따라 미체결이 남을 수 있습니다. 이 필터는 체결이나 수익 보장 기능이 아닙니다.

Q10. 가격을 자동으로 범위 안으로 바꾸면 되나요?

가격 변경은 사용자의 거래 의사를 바꾸는 행위일 수 있습니다. 사전에 정한 조정 범위와 절차가 필요하며 금액·잔고 등 다른 조건도 다시 확인해야 합니다. 오류를 없애기 위해 임의로 변경하지 않습니다.

Q11. 어제 통과한 가격이 오늘 실패할 수 있나요?

배수가 같아도 기준 가격이 달라지면 범위가 달라질 수 있습니다. 규칙 자료와 가격 자료의 시각을 각각 확인해야 합니다. 과거 성공 기록이 현재 조건을 대신하지 않습니다.

Q12. 시장가 슬리피지를 막아주나요?

이 필터를 실제 체결 가격의 보호 보장으로 해석하면 안 됩니다. 슬리피지 관련 기능은 해당 제품의 실행 규칙을 별도로 확인해야 합니다. 필터 통과와 체결 비용은 다른 질문입니다.

Q13. PRER와 같은 기능인가요?

관련 기준 가격 설명이 연결될 수 있지만 규칙 전체를 동일하게 합칠 수는 없습니다. 주문 가격 검사와 별도 실행 규칙의 적용 단계·결과를 구분해야 합니다. 이름이나 참조 링크만으로 잔량 처리까지 추측하지 않습니다.

Q14. 오류가 나면 수량을 줄여야 하나요?

가격 범위 문제라면 수량 변경이 직접 해결책이 아닐 수 있습니다. 실제 오류 유형과 기준 가격, 배수, side를 먼저 확인하세요. 금액 필터와 가격 필터를 구분하는 것이 중요합니다.

Q15. 다음으로 무엇을 보면 좋나요?

주문 조건을 이해한 다음에는 현재 호가 자료가 얼마나 일관되게 구성되는지 확인하는 Order Book Snapshot으로 이어질 수 있습니다. 필터 기준과 호가 자료는 다르지만, 실행 판단에 쓰는 데이터의 출처와 시각을 구분하는 습관이 공통으로 중요합니다.

13. 실행 체크리스트

• 현물과 다른 제품의 가격 규칙을 구분했다.
• 정확한 symbol과 side를 확인했다.
• PERCENT_PRICE와 BY_SIDE를 구분했다.
• 배수를 퍼센트나 수수료로 오해하지 않는다.
• reference price 우선 규칙을 확인했다.
• avgPriceMins와 마지막 가격 fallback을 구분한다.
• BUY와 SELL에 맞는 배수 필드를 사용한다.
• 기준 가격과 필터값의 시각을 따로 기록한다.
• PRICE_FILTER와 동적 범위를 모두 확인한다.
• 최종 가격으로 금액 조건도 다시 계산한다.
• 경계값과 소수 정밀도를 점검한다.
• 사용자 의사 없이 주문 가격을 바꾸지 않는다.
• 명확한 거절과 결과 불명확을 구분한다.
• 실제 접수·체결 결과를 확인한다.

핵심 정리

바이낸스 Percent Price Filter는 단순히 가격을 몇 퍼센트 안에 넣는 설정으로 외우기보다 기준 자료, 배수, 주문 방향, 관측 시각을 연결해서 이해해야 합니다. 정확한 규칙을 읽고 다른 필터와 함께 확인한 뒤 실제 응답으로 결과를 판단하세요.

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