바이낸스 STP Prevented Quantity 뜻 2026｜방지 수량·DECREMENT·주문 기록

바이낸스 STP Prevented Quantity 뜻 2026

바이낸스 STP Prevented Quantity는 실제 체결 수량과 구분해서 읽어야 하는 자기거래 방지 관련 수량입니다. 주문 기록에 숫자가 있다고 해서 모두 시장에서 거래된 것은 아닙니다. STP 때문에 방지된 수량을 체결량에 더하면 거래량과 잔여 수량, 실행 성과를 잘못 계산할 수 있습니다.

이 글은 STP의 기본 뜻을 반복하기보다 방지 수량, 누적값, 마지막 이벤트와 실제 거래 기록을 대조하는 방법에 집중합니다. 특히 DECREMENT처럼 수량을 차감하는 모드를 이해할 때, ‘줄어든 주문 수량’과 ‘실제로 교환된 자산’이 같지 않다는 점이 중요합니다.

2026년 10월 15일 Binance Spot Developers의 STP FAQ, 주문 상태 정의, 사용자 데이터 스트림과 계정 조회 문서를 확인했습니다. 이 글의 범위는 Spot 기록입니다. Futures나 Options의 필드와 모드에 그대로 적용하지 않습니다. 모든 사례의 수량은 기록 해석용 가상값이며 실제 거래 권유가 아닙니다.

Prevented Quantity를 체결량과 나눠 읽어야 하는 이유

STP는 자기거래가 발생할 상황에서 적용되는 처리와 관련됩니다. 현재 공식 FAQ는 같은 계정 또는 같은 tradeGroupId에 속한 계정의 주문이 맞닥뜨리는 경우를 설명합니다. 어떤 처리가 일어나는지는 적용 모드와 조건을 확인해야 합니다. Spot STP FAQ

중요한 것은 방지된 매칭이 실제 거래와 같지 않다는 점입니다. 주문에서 더 이상 실행할 수 없는 양이 생겼다고 해서 그 양을 매수하거나 매도한 것으로 기록하면 안 됩니다. 실제 체결은 거래 내역에서 확인합니다.

가상의 원래 주문 10단위 중 실제 체결 2단위, 방지 수량 3단위라는 정보를 봤다면, 5단위를 거래했다고 기록하지 않습니다. 실제 거래는 확인된 2단위입니다. 나머지 수량의 상태는 주문 모드와 현재 상태를 함께 읽어 판단해야 합니다.

이 구분은 자동 보고서에도 필요합니다. 체결량과 방지 수량을 같은 ‘처리량’ 열로 합쳐 놓으면 주문 진행을 설명하는 데는 편해 보여도 실제 자산 교환을 잘못 표현할 수 있습니다. 처리 목적이 다른 값은 별도 열로 남깁니다.

세 가지 수량을 먼저 분리합니다

원래 주문 수량

원래 수량은 주문이 의도한 총량을 설명합니다. 이 값이 크다는 사실만으로 실제 거래가 그만큼 일어났다고 볼 수 없습니다. 체결, 방지, 아직 남아 있는 양을 읽기 위한 출발점입니다.

주문을 수정하거나 새 주문으로 교체했다면 식별자와 변경 기록도 확인해야 합니다. 서로 다른 주문의 원래 수량을 한 개의 연속된 주문처럼 합치지 않습니다. 수량 계산 전에 대상 주문을 정확히 고정해야 합니다.

실제 체결 수량

실제 체결 수량은 시장에서 거래가 발생한 결과입니다. 평균 체결 가격이나 실제 거래 금액을 계산할 때 사용하는 범위와 연결됩니다. STP로 방지된 양을 여기에 넣으면 체결 결과가 왜곡됩니다.

한 주문에서 일부 거래가 먼저 발생한 뒤 STP가 적용될 수도 있으므로, 최종 상태만 보고 전체 거래를 0으로 처리하지 않습니다. 상태와 누적 체결을 함께 확인하고, 실제 거래 내역으로 대조하는 것이 좋습니다.

방지된 수량

방지 수량은 STP 처리와 관련된 기록입니다. 어떤 쪽 주문에서 얼마가 더 이상 거래되지 않게 됐는지는 모드와 이벤트를 함께 읽어야 합니다. 모든 모드에서 단순히 상대 주문의 작은 수량과 같다고 가정하면 안 됩니다.

특히 누적 방지량과 마지막 방지량은 서로 다릅니다. 한 주문에서 여러 사건이 있으면 최신 누적값에는 이전 사건이 포함될 수 있습니다. 두 값을 모두 더하면 같은 사건을 중복 계산하는 문제가 생깁니다.

A와 B: 누적값과 마지막 값을 구분합니다

Spot 사용자 데이터 스트림은 executionReport에서 STP 관련 조건부 필드를 설명합니다. A는 Prevented Quantity, B는 Last Prevented Quantity로 구분되며, 방지 매칭 식별자나 상대 주문 정보 같은 항목도 조건에 따라 나타납니다. 사용자 데이터 스트림 공식 문서

필드가 조건부라는 것은 모든 이벤트에 항상 같은 정보가 있다는 뜻이 아니라는 점도 중요합니다. 값이 없다고 무조건 0을 채워 넣기 전에 해당 이벤트에서 제공되는 항목인지 확인해야 합니다. 부재와 실제 0은 다른 상태일 수 있습니다.

가상으로 첫 사건의 마지막 방지량이 1, 이후 다른 사건이 2라면 누적 방지량은 해당 기록 구조에 맞춰 3으로 이해할 수 있습니다. 이때 마지막 이벤트의 누적 3과 마지막 2를 더해 5로 만들면 안 됩니다. 두 숫자가 서로 다른 범위를 설명하기 때문입니다.

이벤트 저장표에는 누적과 증분을 명시합니다. 열 이름을 그냥 ‘수량’이라고 두면 후속 계산에서 어느 값을 더해야 하는지 모호해집니다. ‘누적 방지’와 ‘이번 사건 방지’처럼 범위를 드러내는 이름이 좋습니다.

주문 상태와 실행 이벤트도 다릅니다

주문 상태는 현재 주문의 상태를, 실행 이벤트는 어떤 종류의 일이 일어났는지를 설명합니다. 이름이 비슷해도 같은 열로 덮어쓰면 해석이 어려워집니다. 원본 필드의 역할을 유지해야 합니다.

Spot의 공식 상태 정의는 EXPIRED_IN_MATCH를 STP에 의해 만료된 상태로 설명합니다. 실행 유형에서는 TRADE와 TRADE_PREVENTION을 구분합니다. Spot 상태·이벤트 정의

따라서 이벤트 유형을 읽고 실제 거래가 발생한 사건인지 먼저 구분해야 합니다. 방지 이벤트를 거래 이벤트처럼 처리해 거래량 차트에 넣으면 기록의 의미가 바뀝니다. 상태가 만료라고 해도 이전 실제 체결이 있었는지는 별도로 확인합니다.

이벤트 한 건으로 주문 전체의 모든 이력을 설명하려 하지 않습니다. 최종 주문 조회와 실제 거래 목록, 방지 기록이 서로 다른 관점을 제공합니다. 세 자료를 같은 식별자로 연결하면 마지막 이벤트만 읽었을 때 생기는 오해를 줄일 수 있습니다.

모드별로 수량이 달라지는 이유

만료시키는 쪽을 구분하는 모드

EXPIRE_MAKER, EXPIRE_TAKER, EXPIRE_BOTH 같은 이름은 어느 쪽에 만료 처리가 적용되는지 이해하는 출발점입니다. 기록을 읽을 때는 maker와 taker가 누구인지 실제 주문번호로 연결해야 합니다.

기존 주문이 항상 내 관심 주문이고 새 주문은 항상 다른 사람 주문이라고 가정하면 안 됩니다. 같은 계정에서 여러 전략을 사용하면 양쪽 모두 내 기록에 나타날 수 있습니다. 주문 생성 순서와 매칭 역할을 정확히 확인합니다.

이 글에서는 모든 모드의 세부 알고리즘을 하나의 간단한 공식으로 통일하지 않습니다. 모드에 따라 만료되는 남은 양과 매칭에서 방지된 양의 관계를 공식 정의대로 읽어야 합니다. 단순히 작은 주문 크기만 뽑아 모든 방지량으로 쓰지 않습니다.

DECREMENT는 실제 거래와 다른 수량 처리를 합니다

DECREMENT를 이해할 때 핵심은 수량이 차감됐다는 사실과 실제 체결됐다는 사실을 분리하는 것입니다. 공식 FAQ의 모드 설명과 해당 주문의 방지 기록을 함께 읽어야 합니다. 양쪽 주문의 남은 양이 같지 않으면 상태 변화도 따로 확인해야 합니다.

가상의 사건에서 관련 수량 3이 양쪽에 반영됐다고 해도, 이를 매수 3과 매도 3의 실제 거래로 보고하지 않습니다. 기록상 방지 처리와 실제 거래 목록을 분리합니다. 두 계정 또는 두 주문의 로그를 합칠 때도 같은 사건을 두 번 집계하지 않도록 주의합니다.

새로운 모드와 지원 범위는 현재 문서로 확인합니다

현재 문서에는 TRANSFER 같은 추가 모드 설명도 존재합니다. 따라서 ‘STP는 세 종류뿐’처럼 고정해서 쓰면 최신 범위를 놓칠 수 있습니다. 다만 이 글의 가상 산술 사례는 별도 언급이 없는 한 단순한 방지 수량 대조에 집중합니다.

모드 이름이 목록에 있다는 사실과 모든 심볼·계정에서 사용할 수 있다는 사실은 다릅니다. 기본 모드와 허용 모드는 현재 심볼 정보와 이용 경로를 확인해야 합니다. API 예제의 모드를 그대로 실제 주문에 복사하지 않습니다.

조회는 실제 거래와 방지 기록을 따로 봅니다

현재 Spot 계정 API의 Query Prevented Matches는 STP 관련 기록을 조회하는 경로입니다. 공식 경로는 GET /api/v3/myPreventedMatches이며, symbol과 주문 또는 방지 매칭 식별자 같은 지원 조합을 문서에서 확인해야 합니다. 계정 조회 공식 문서

조회 결과에서는 maker와 taker의 주문번호, 방지 매칭 식별자, 모드와 시각 등을 연결해 읽습니다. 결과 예제에 보이는 모든 필드가 모든 모드에서 같은 의미와 구성으로 나타난다고 가정하지 않습니다.

실제 거래 목록은 별도로 확인합니다. 방지 기록이 있다고 거래 목록에 같은 수량이 있어야 한다고 기대하면 안 됩니다. 반대로 주문이 일부 체결된 후 방지됐다면 실제 거래 기록과 방지 기록이 모두 있을 수 있습니다.

조회 과정에서는 계정과 상품, 심볼과 시간대를 고정합니다. 이름이 같은 종목이라도 다른 상품의 로그를 가져오면 필드와 상태 정의가 달라질 수 있습니다. Spot 문서의 설명을 선물 로그에 바로 대입하지 않습니다.

남은 수량 계산에 상태를 함께 넣어야 합니다

공식 STP FAQ는 열린 주문의 원래 수량, 실제 체결과 방지 수량의 관계를 설명합니다. 이 관계를 이해하면 왜 단순히 ‘원래 수량 빼기 체결량’만으로 현재 실행 가능량을 계산하면 안 되는지 알 수 있습니다.

가상으로 아직 열린 주문의 원래 수량이 10, 누적 체결이 2, 누적 방지가 3이라고 합시다. 동일한 주문과 시점, 단위라는 조건에서 산술적으로 남는 양은 5입니다. 여기서 3은 실제 매매량이 아니므로 체결 성과의 분자에 넣지 않습니다.

그러나 주문이 이미 취소 또는 만료 상태라면 산술적으로 남는 양을 곧바로 실행 중 잔여량이라고 부르면 안 됩니다. 상태가 더 이상의 실행을 허용하는지 확인해야 합니다. 수량 관계와 주문 상태를 함께 읽어야 합니다.

자동 보고서에서는 ‘계산상 미체결’, ‘현재 실행 가능한 잔여’, ‘종료로 남은 목표’를 구분하는 편이 좋습니다. 세 항목을 모두 ‘남은 주문’으로 표시하면 종료된 양이 아직 시장에 걸려 있는 것처럼 보일 수 있습니다.

사례 1: 방지 수량을 실제 거래량에 더한 경우

가상 사용자 A의 주문은 원래 10단위이고 실제 체결 내역은 2단위입니다. 별도 STP 기록에서 방지 수량 3을 확인했습니다. A는 둘을 더해 5단위를 거래했다고 보고서를 작성하려 합니다.

이 경우 실제 매매량은 거래 내역에서 확인된 2단위입니다. 3은 방지 처리에 관한 값이므로 거래량에 합치지 않습니다. 주문의 전체 처리 상태를 설명하고 싶다면 ‘체결 2, 방지 3’처럼 나란히 표시합니다.

평균 체결 가격을 계산할 때도 같은 원칙을 적용합니다. 실제 거래 금액을 5로 나누면 존재하지 않는 체결량을 분모에 넣는 셈입니다. 실제 거래 수량과 금액을 짝지어 계산해야 합니다.

A가 확인할 다음 항목은 현재 주문 상태입니다. 아직 열린 주문인지, 이미 종료됐는지에 따라 남은 양의 의미가 달라집니다. 단순 계산만으로 남은 5가 계속 실행된다고 단정하지 않습니다.

수정된 보고서는 실제 거래와 방지 처리의 차이를 보존합니다. ‘처리됐다’는 모호한 표현을 쓰기보다 무엇이 거래됐고 무엇이 방지됐는지 구체적으로 적으면 자산 변화와 기록을 대조하기 쉬워집니다.

사례 2: 누적값과 마지막 값을 둘 다 합산한 경우

사용자 B는 첫 방지 사건 뒤 누적값 1을 저장했습니다. 이후 새 사건의 마지막 방지량이 2이고 최신 누적값이 3이라고 가정합니다. B는 저장한 1, 마지막 2, 최신 누적 3을 모두 더해 6을 만들었습니다.

세 숫자는 독립적인 거래 세 건이 아닙니다. 최신 누적 3에는 앞선 사건이 이미 포함돼 있습니다. 사건별 증분을 합산하는 방식과 최신 누적값을 사용하는 방식을 구분해야 합니다.

기록표에는 누적 스냅샷과 개별 사건을 별도로 둡니다. 누적 스냅샷은 시간에 따른 상태 관찰용이고, 사건 표는 실제 발생한 방지 이벤트를 보관하는 용도입니다. 한 표로 유지하더라도 필드 의미를 명확히 표시해야 합니다.

B가 과거 합계를 복구할 때는 잘못된 최종 숫자만 수정하지 않습니다. 어떤 필드를 어떤 방식으로 더했는지 계산 규칙을 고쳐야 이후 기록도 맞게 유지됩니다. 원본 이벤트는 보존하고 집계 결과를 다시 만듭니다.

이 사례에서 중요한 교훈은 누적값을 많이 수집할수록 정확해지는 것이 아니라는 점입니다. 값의 의미를 구분하지 않으면 관찰 횟수가 늘어날수록 잘못된 합계가 더 커질 수 있습니다.

사례 3: 같은 방지 이벤트가 다시 들어온 경우

사용자 C의 프로그램이 연결을 복구하면서 이미 저장한 사건을 다시 읽었다고 가정합니다. 동일한 방지 매칭 식별자를 가진 기록을 새 사건으로 추가하면 방지량이 중복됩니다. 네트워크 재연결과 새로운 매칭 사건을 구분해야 합니다.

C는 계정, 상품, 심볼과 방지 식별자, 관련 주문번호를 함께 확인합니다. 식별자 하나를 모든 상품에서 전역적으로 유일하다고 추측하지 않고, 현재 문서의 범위에 맞춰 연결 정보를 보존합니다.

같은 사건이 확인되면 원본 수신 기록은 남길 수 있지만 집계에서는 중복을 구분합니다. 수신 횟수와 사건 횟수는 다른 통계입니다. 한 이벤트를 두 번 받았다는 사실이 두 번 방지됐다는 뜻은 아닙니다.

반대로 시각과 수량이 같다는 이유만으로 서로 다른 사건을 하나로 합쳐도 안 됩니다. 실제 식별자를 확인해야 합니다. 중복 제거는 추측으로 기록을 지우는 작업이 아니라 동일 사건임을 검증하는 작업입니다.

C의 최종 보고서는 원본 수신 건수와 검증된 사건 수를 분리합니다. 이 차이가 보이면 연결 복구 과정에서 왜 데이터 행 수가 늘어났는지 설명할 수 있고, 실제 방지 처리량을 과장하지 않을 수 있습니다.

사례 4: 일부 체결 뒤 EXPIRED_IN_MATCH가 된 경우

사용자 D는 최종 상태가 EXPIRED_IN_MATCH인 주문을 보고 실제 거래가 전혀 없었다고 생각합니다. 그러나 주문이 그 상태에 도달하기 전에 다른 상대와 일부 체결됐는지는 별도 확인해야 합니다.

가상으로 실제 체결 4단위가 먼저 있었고 이후 STP 관련 종료가 발생했다면, 최종 상태만으로 그 4단위를 지울 수 없습니다. 실제 거래 목록과 누적 체결을 확인하고 방지 기록은 별도 연결합니다.

D는 주문 상태 정의와 실행 유형을 나눠 읽습니다. 최종 상태는 현재 주문의 종료 이유를 설명하는 단서이고, 전체 생애의 모든 사건이 하나였다는 뜻은 아닙니다. 거래 이벤트와 방지 이벤트가 순서대로 있을 수 있다는 관점이 필요합니다.

복구 과정에서는 원래 수량, 최종 누적 체결, 방지 처리와 종료 상태를 한 줄에 모읍니다. 단, 각 값의 범위를 지우지 않습니다. 실제 거래와 더 이상 실행되지 않는 양을 나누면 잔고 대조가 쉬워집니다.

새 주문을 검토한다면 먼저 현재 자산 상태와 다른 주문을 확인합니다. 이전 주문을 모두 실패로 보고 원래 총량을 다시 넣으면 이미 체결된 부분이 중복될 수 있습니다. 상태 해석 오류가 실제 추가 거래로 이어지지 않도록 주의합니다.

사례 5: 양쪽 주문의 방지량을 두 배 거래량으로 계산한 경우

사용자 E는 같은 방지 사건의 maker와 taker 쪽 로그를 모두 수집합니다. DECREMENT 관련 기록을 분석하면서 양쪽에 각각 수량 3이 보인다고 가정합니다. E는 이를 합쳐 6단위가 시장에서 거래됐다고 표시하려 합니다.

하지만 양쪽 기록은 하나의 사건을 각 주문 관점에서 보여줄 수 있습니다. 우선 같은 방지 매칭인지 연결하고, 실제 거래가 아니라 방지 처리라는 점을 유지해야 합니다. 주문별 영향과 시장 거래량은 서로 다른 통계입니다.

주문별로 얼마가 차감됐는지 분석하려면 양쪽 영향을 각각 표시할 수 있습니다. 다만 그 합계를 실제 체결량이라는 이름으로 바꾸면 안 됩니다. 보고서의 목적과 열 이름을 정확히 정해야 합니다.

이 사례는 여러 서브계정이나 전략의 기록을 모을 때 더 중요합니다. 같은 tradeGroupId 관련 사건을 여러 곳에서 관찰할 수 있으므로 계정별 관점과 사건별 관점을 분리해야 합니다. 모든 서브계정이 같은 그룹이라고 추측하지도 않습니다.

E는 사건 식별 정보, 양쪽 주문과 모드, 각 주문에 나타난 값을 보존합니다. 그런 다음 실제 거래 목록과 비교해 방지 사건을 매매 실적으로 포함하지 않았는지 점검합니다. 데이터가 많아도 의미를 구분해야 정확한 보고가 됩니다.

주문이 사라졌을 때 조사하는 순서

현재 주문과 과거 기록을 연결합니다

현재 열린 주문 목록에 없다고 기록이 없는 것은 아닙니다. 대상 주문번호와 심볼로 주문 조회 및 과거 기록을 확인합니다. 마지막으로 본 상태와 최종 상태를 구분하고, 현재 목록의 부재를 원인으로 단정하지 않습니다.

찾는 과정에서 계정과 상품을 바꾸지 않았는지도 확인합니다. Spot 주문번호를 다른 상품 조회에 넣고 결과가 없다고 판단하면 잘못된 조사 방향으로 갈 수 있습니다. 먼저 조회 범위를 고정합니다.

실제 체결 내역을 확인합니다

실제 거래가 있었는지와 방지 사건이 있었는지는 별도 질문입니다. 체결 목록에서 수량과 금액을 확인하고, 방지 기록에서 모드와 관련 주문을 확인합니다. 한 목록에 없다는 이유로 다른 목록의 내용까지 부정하지 않습니다.

조회 범위나 페이지를 누락하지 않도록 합니다. 특정 기간이나 제한된 결과만 확인한 상태에서 전체 기록이 없다고 결론 내리지 않습니다. 시간대가 다른 자료를 함께 읽는 경우 기준을 맞추고 원본 시각도 보관합니다.

상태·모드·수량을 대조합니다

최종 상태, 적용 모드와 수량의 의미가 서로 맞는지 확인합니다. 특정 모드에서 어떤 쪽 주문에 영향이 있었는지 이해하려면 maker와 taker 주문번호를 연결해야 합니다. 방향만 보고 역할을 추측하지 않습니다.

원인을 확인하지 못했다면 미확인으로 기록하고 필요한 자료를 모읍니다. STP 모드를 바꾸거나 방지 기능을 제거하는 것을 조사 대신 사용하지 않습니다. 자기거래 방지의 목적을 이해하고 현재 규칙 안에서 원인을 확인해야 합니다.

조회 시점이 다른 기록을 맞추는 방법

실시간 이벤트와 나중에 조회한 주문 요약은 서로 다른 순간을 보여 줄 수 있습니다. 이벤트 한 건을 받은 직후의 값과 몇 초 뒤의 누적값이 다르다고 즉시 데이터 오류라고 판단하지 않습니다. 같은 주문인지와 각 정보의 시점을 먼저 확인해야 합니다.

관찰 시각과 사건 시각을 모두 남기면 도움이 됩니다. 사건 시각은 실제 처리와 관련된 시간이고, 관찰 시각은 프로그램이나 사람이 그 정보를 확인한 시간입니다. 연결이 늦어지면 두 시각 사이에 차이가 있을 수 있습니다.

과거 기록을 다시 읽을 때는 시간대도 맞춥니다. 날짜가 다르게 보인다는 이유만으로 다른 주문이라고 판단하기 전에 UTC와 현지 시간의 차이를 확인합니다. 다만 시간을 변환하더라도 원본 시각을 보존하면 추적이 쉽습니다.

최신 상태를 저장하는 표에서는 오래된 응답이 뒤늦게 들어왔을 때 최신값을 덮어쓰지 않도록 주의합니다. 시간 순서만으로 모든 사건 관계를 확정할 수는 없으므로 주문과 사건 식별 정보도 함께 사용해야 합니다. 기록의 정렬과 실제 사건의 중복 확인은 별개의 점검입니다.

최종 대조에서는 같은 주문의 최신 상태, 실제 거래 목록과 방지 사건을 한 번 더 연결합니다. 진행 중 관찰값을 최종 결과로 고정하지 않습니다. 종료가 확인됐다면 그 확인 시각과 함께 실제 체결과 방지 수량을 각각 남깁니다.

이 방식은 로그를 많이 수집하기 위한 규칙이 아니라, 서로 다른 출처의 값이 왜 달라 보이는지 설명하기 위한 방법입니다. 원인을 확인할 수 없는 차이는 그대로 기록하고, 숫자를 맞추기 위해 원본 필드를 임의로 수정하지 않습니다.

기본 모드와 허용 모드를 기억에 의존하지 않기

과거 글이나 예제에서 본 모드가 현재 심볼의 기본값이라고 단정하면 안 됩니다. 공식 문서가 제공하는 기본 모드와 허용 모드 정보를 현재 기준으로 확인해야 합니다. 같은 이름의 기능이라도 상품별 규칙은 다를 수 있습니다.

일반 화면에 모든 모드 선택지가 보이지 않는다고 STP가 없다고 판단하지 않습니다. 반대로 API 문서에 모드가 나열됐다고 일반 화면에 그 선택 버튼이 있다고 만들어 설명하지도 않습니다. 이용 경로와 실제 제공 정보를 구분해야 합니다.

여러 전략을 운용할 때는 각 전략이 어떤 설정으로 주문을 제출했는지 기록합니다. 문제가 생긴 뒤 기억으로 모드를 추측하면 maker와 taker의 설정 차이를 놓칠 수 있습니다. 원래 요청과 실제 결과를 연결하는 자료가 필요합니다.

이 글의 목적은 방지 수량을 정확히 해석하는 것입니다. 더 많은 자기거래를 허용하도록 설정을 바꾸라는 안내가 아닙니다. 기록 오류와 전략 충돌을 조사하고 올바른 체결·방지 통계를 만드는 데 초점을 둡니다.

데이터 표를 설계할 때의 실용 원칙

주문 표와 사건 표를 분리합니다

주문 표에는 계정, 상품, 심볼, 주문번호, 원래 수량, 최신 체결과 방지 누적, 상태와 조회 시각을 둡니다. 사건 표에는 방지 매칭 식별자, 양쪽 주문, 모드, 사건 시각과 해당 수량을 둡니다.

두 표를 연결하면 현재 상태와 사건의 흐름을 모두 볼 수 있습니다. 주문 표를 갱신하는 동안 과거 사건을 지우지 않고, 사건 표를 합산할 때는 중복 식별과 누적·증분 구분을 적용합니다.

실제 거래 표는 독립적으로 유지합니다

매매량과 평균 가격, 거래 금액을 계산하는 표에는 실제 거래 기록을 사용합니다. 방지 기록을 같은 형식으로 변환해 넣지 않습니다. 분석 편의를 위해 데이터를 합치더라도 사건 유형을 보존하고 계산에서 구분해야 합니다.

수수료나 잔고 변화도 실제 계정 기록으로 대조합니다. 방지 수량에 가격을 곱한 가상 금액을 실제 지출이나 수익으로 표시하지 않습니다. 추정 시나리오를 만들었다면 실제 내역과 명확히 구분합니다.

정밀도와 원문을 보존합니다

긴 주문번호와 방지 식별자는 문자열로 보관하는 편이 오류를 줄이는 데 도움이 됩니다. 소수 수량도 표시용 반올림과 원본값을 구분합니다. 원본을 지운 뒤 둥근 숫자만 남기면 작은 차이의 원인을 찾기 어렵습니다.

검증 중 값이 맞지 않으면 원본을 억지로 수정하지 않습니다. 계정, 심볼, 시점, 중복과 필드 의미부터 확인합니다. 차이를 기록해 두면 같은 문제가 반복될 때 원인을 추적할 수 있습니다.

실제 금액과 방지된 가상 금액을 구분하는 예

방지 수량에 특정 가격을 곱하면 숫자로 된 금액을 만들 수 있습니다. 그러나 계산할 수 있다는 사실이 실제 자산 교환이 일어났다는 뜻은 아닙니다. 가상의 방지 수량 3에 가격 100을 곱한 300은 그 가정 아래의 산술값이며 실제 거래 대금으로 보고해서는 안 됩니다.

보고서에서 이런 값을 참고하려면 ‘방지 수량의 가상 환산’처럼 이름과 기준 가격을 명시해야 합니다. 실제 체결 금액과 같은 합계 열에 넣지 않습니다. 원래 목적이 자기거래 방지 사건의 크기를 이해하는 것이라면 그 범위 안에서 해석해야 합니다.

실제 평균 가격을 계산할 때도 방지 수량을 제외해야 합니다. 실제 2단위가 거래됐고 그 거래 금액이 210이라면 그 가상 기록의 평균은 105입니다. 방지된 3을 더해 5로 나누면 42가 되지만, 이는 실제 체결 평균이 아닙니다. 분모와 분자가 서로 다른 사건 범위를 사용했기 때문입니다.

이 예시는 복잡한 모드 구현보다 먼저 확인해야 할 회계적 구분을 보여 줍니다. 거래가 발생한 기록과 거래를 막은 기록은 서로 보완하지만 같은 종류의 현금 흐름은 아닙니다. 두 자료를 합쳐 분석하더라도 사건 유형을 끝까지 보존해야 합니다.

또한 방지된 금액을 곧바로 절약한 수수료나 얻은 수익으로 표시하지 않습니다. 실제로 어떤 거래가 일어났을지와 적용 비용을 별도 가정해야 하는데, 이를 검증 없이 확정할 수는 없습니다. 관찰한 사건 규모와 추정한 효과를 분리하는 것이 정확합니다.

최종 보고서의 표현 예

‘총 5단위 처리’처럼 모호한 문장 대신 ‘실제 체결 2단위와 STP 관련 방지 3단위를 별도 확인했다’고 적습니다. 이어 현재 주문 상태와 조회 시각을 붙입니다. 이렇게 하면 읽는 사람이 5단위의 실제 거래가 있었다고 오해할 가능성이 줄어듭니다.

여러 주문을 묶은 보고서에서는 사건 수와 주문 영향 수를 구분합니다. 하나의 사건이 두 주문에 영향을 줬다면 사건은 하나이지만 영향을 받은 주문은 둘일 수 있습니다. 어떤 수치를 세는지 정의한 뒤 집계해야 중복 계산과 과소 계산을 모두 피할 수 있습니다.

자주 묻는 질문 FAQ

1. Prevented Quantity는 체결 수량인가요?

실제 체결과 구분하는 STP 관련 수량입니다. 거래량이나 평균 체결 가격을 계산할 때 그대로 더하지 않습니다. 실제 거래 목록과 방지 기록을 각각 확인해야 합니다.

2. A와 B는 무엇이 다른가요?

공식 사용자 데이터 스트림에서 누적 방지 수량과 마지막 방지 수량을 구분하는 필드입니다. 두 값을 서로 독립적인 거래량처럼 합산하면 중복이 생길 수 있습니다. 원본 이벤트의 의미를 유지하십시오.

3. 필드가 없으면 0으로 기록하면 되나요?

조건부 필드인지 먼저 확인합니다. 값의 부재와 실제 0을 구분해야 합니다. 이벤트에 제공되지 않은 정보를 임의로 0 처리하면 이후 잔여 수량 계산이 잘못될 수 있습니다.

4. EXPIRED_IN_MATCH면 거래가 전혀 없었나요?

최종 상태만으로 이전 체결을 지울 수 없습니다. 누적 체결과 실제 거래 목록을 확인해야 합니다. 일부 거래 뒤 STP 관련 종료가 발생했는지 대조합니다.

5. TRADE_PREVENTION을 거래 이벤트로 세나요?

실제 TRADE와 구분해야 합니다. 방지 이벤트를 실제 매매량 차트에 넣으면 의미가 달라집니다. 사건 유형과 주문 상태를 각각 보존하는 것이 좋습니다.

6. DECREMENT로 줄어든 수량은 매매된 것인가요?

수량 처리와 실제 체결은 별개입니다. 모드에 따른 방지 기록을 읽고 실제 거래 내역을 별도로 확인합니다. 주문에서 줄었다는 이유만으로 자산이 교환됐다고 기록하지 않습니다.

7. 원래 수량에서 체결만 빼면 잔여량인가요?

방지 처리와 현재 상태를 함께 고려해야 합니다. 열린 주문의 수량 관계와 종료된 주문의 남은 목표는 다릅니다. 산술값만 보고 계속 실행 가능한 주문이라고 판단하면 안 됩니다.

8. 같은 이벤트를 다시 받으면 다시 더하나요?

동일 사건인지 식별 정보를 확인해야 합니다. 수신 횟수와 실제 사건 수를 구분합니다. 반대로 시각과 수량만 같다는 이유로 서로 다른 사건을 합쳐 버려서도 안 됩니다.

9. maker와 taker 기록을 더하면 총거래량인가요?

같은 방지 사건의 양쪽 관점일 수 있으므로 실제 거래량으로 합치면 안 됩니다. 주문별 영향과 사건별 통계를 구분하고, 실제 매매량은 거래 목록에서 확인합니다.

10. 방지 기록은 어디서 조회하나요?

현재 Spot 계정 API는 Query Prevented Matches 경로를 제공합니다. GET /api/v3/myPreventedMatches의 지원 파라미터 조합을 공식 문서에서 확인합니다. 일반 화면에 동일한 메뉴가 있다고 가정하지 않습니다.

11. 모든 서브계정이 같은 STP 그룹인가요?

그렇게 추측하지 않습니다. 현재 계정과 tradeGroupId 관련 정보를 확인해야 합니다. 계정 관계를 모르는 상태에서 같은 이름이나 소유자라는 이유로 로그를 합치지 않습니다.

12. 기본 모드는 항상 같나요?

상품과 심볼, 현재 공식 조건을 확인해야 합니다. 과거 예제의 값을 공통 기본값으로 고정하지 않습니다. 허용 모드와 기본 모드도 서로 다른 정보입니다.

13. Spot 설명을 Futures에도 적용할 수 있나요?

이 글의 범위는 Spot입니다. 다른 상품의 필드와 상태, 지원 모드는 해당 문서에서 별도로 확인해야 합니다. 이름이 같아도 모든 세부 규칙이 같다는 뜻은 아닙니다.

14. STP 때문에 종료되면 원래 총량으로 다시 주문하나요?

먼저 실제 체결과 현재 자산 상태, 다른 주문을 확인합니다. 이전 주문을 전부 실패로 보고 원래 총량을 복사하면 중복 실행이 생길 수 있습니다. 새 거래는 별도 판단이 필요합니다.

15. 지원 문의에는 무엇을 준비하나요?

상품과 계정, 심볼, 주문번호, 방지 식별자, 모드, 시각과 시간대, 실제 체결과 방지 기록을 정리합니다. 비밀 키나 토큰은 공개하지 말고 공식 지원 경로를 이용합니다.

기록 확인 체크리스트

• [ ] 조회 범위가 Spot인지 확인했다.
• [ ] 계정과 심볼을 고정했다.
• [ ] 주문번호와 방지 매칭 식별자를 구분했다.
• [ ] maker와 taker 주문을 실제 번호로 연결했다.
• [ ] 원래 수량과 실제 체결을 구분했다.
• [ ] 방지 수량을 실제 매매량에 더하지 않았다.
• [ ] 누적 방지와 마지막 방지를 분리했다.
• [ ] 조건부 필드의 부재를 임의로 0 처리하지 않았다.
• [ ] 중복 수신과 새 사건을 구분했다.
• [ ] 최종 상태와 과거 체결을 함께 확인했다.
• [ ] 현재 모드와 허용 범위를 확인했다.
• [ ] 주문 표와 사건 표의 역할을 나눴다.
• [ ] 실제 거래 목록을 별도로 대조했다.
• [ ] 원본 수량 정밀도와 긴 식별자를 보존했다.
• [ ] 확인되지 않은 원인은 미확인으로 남겼다.

핵심 정리

바이낸스 STP Prevented Quantity를 정확히 읽으려면 체결, 방지와 남은 양을 분리해야 합니다. 누적과 마지막 이벤트를 구분하고, 주문 상태와 실제 거래 목록을 함께 대조하면 방지된 수량을 매매 실적으로 잘못 계산하는 일을 줄일 수 있습니다.

이 글은 주문 기록을 이해하기 위한 정보이며 투자 권유나 자기거래 방지 우회 안내가 아닙니다. 실제 주문과 데이터 처리는 최신 공식 규칙과 해당 계정·상품의 조건을 확인한 뒤 진행하십시오.