바이낸스 Prevented Matches 확인 2026｜STP 기록·주문 ID·방지 수량 대조

바이낸스 Prevented Matches 확인 2026｜STP 기록·주문 ID·방지 수량 대조

바이낸스 Prevented Matches 확인은 자기거래 방지로 실행되지 않은 매칭 기록을 주문과 연결해 읽는 과정입니다. 실제 체결 내역과 다른 자료이므로 가격과 수량이 보인다고 곧바로 거래가 발생했다고 해석하면 안 됩니다.

주문이 EXPIRED_IN_MATCH로 끝났거나 preventedMatchId가 나타났다면, 어느 주문과 어떤 조건에서 방지 사건이 생겼는지 확인할 필요가 있습니다. 이 글은 STP의 개념을 반복하기보다 기록 조회, 식별자 연결, 중복 제거, 실제 체결과의 대조에 집중합니다.

확인 기준은 2026년 11월 3일 Binance Spot REST API와 STP 공식 FAQ입니다. 아래 식별자·가격·수량은 설명을 위한 가상 값이며, 계정별 지원 모드와 실제 결과는 현재 공식 자료와 본인 기록에서 확인해야 합니다.

Prevented Match는 거래가 아닌 사건 기록

STP는 같은 계정 또는 같은 tradeGroupId로 연결된 계정의 주문이 자기거래를 일으키는 상황을 방지하는 기능입니다. 방지가 발생하면 어떤 주문들이 서로 거래할 수 있었는지를 설명하는 기록이 만들어질 수 있습니다.

이 기록에 price가 있다고 해서 그 가격에 실제 거래가 체결됐다는 뜻은 아닙니다. 주문이 서로 만날 수 있었던 맥락을 나타내는 자료와 실제 거래 장부를 구분해야 합니다.

또한 한 주문이 이전에는 외부 상대와 일부 체결되고, 이후 자기 주문과 만날 상황에서 방지될 수 있습니다. 이런 경우 실제 거래 내역과 Prevented Match가 같은 주문 ID에 연결될 수 있지만 서로 다른 종류의 사건입니다.

이 구분을 하지 않으면 거래량, 평균 가격, 수수료, 보유량이 모두 틀어질 수 있습니다. 방지 사건을 실제 매매로 기록하면 존재하지 않는 자산 이동을 장부에 만들어 버립니다.

어떤 주문이 자기거래 대상으로 판단되는가

공식 FAQ는 같은 계정의 주문과 같은 tradeGroupId를 가진 계정 사이의 주문을 자기거래 판단 범위로 설명합니다. tradeGroupId는 단순히 사람이 붙인 전략 이름과 다릅니다.

계정의 tradeGroupId를 확인하는 공식 계정 자료가 있으며, 값이 -1이면 해당 계정에 그룹이 설정되지 않았다는 설명이 있습니다. 이 경우에도 같은 계정의 주문 사이에서 STP가 발생할 수 있습니다.

여러 계정이 있다고 모두 같은 그룹이라고 가정하거나, 계정이 다르므로 STP가 발생할 수 없다고 단정하면 안 됩니다. 실제 계정 자료와 사건 기록을 확인해야 합니다.

거래쌍과 계정 범위를 함께 저장

기록 식별자를 숫자 하나만 저장하지 않습니다. symbol과 계정 범위, 관련 주문 식별자를 함께 보관해야 다른 자료와 혼동하지 않습니다.

여러 시장이나 여러 계정을 분석하는 시스템에서는 동일해 보이는 숫자가 같은 사건이라는 보장이 없습니다. 공식 식별 범위에 맞춰 키를 구성해야 합니다.

공유 보고서에는 필요한 범위만 표시하고 계정 식별 정보와 인증 자료를 불필요하게 공개하지 않습니다. 기록 대조와 민감정보 노출은 별개의 문제입니다.

조회 엔드포인트와 문서 확인

작성일 현재 현물 REST API의 Query Prevented Matches 항목은 GET /api/v3/myPreventedMatches를 안내합니다. USER_DATA 보안 유형이며 데이터 소스는 Database로 표시되어 있습니다.

공식 FAQ의 일부 예시 설명에는 다른 경로 표기가 남아 있을 수 있습니다. 실제 구현에서는 작성일의 엔드포인트별 REST 명세를 기준으로 메서드·경로·필드 조합을 확인해야 합니다. 서로 다른 문서의 경로를 섞어 새로운 주소를 만들지 않습니다.

이 글에서 제시하는 조회 경로는 현재 REST 엔드포인트 명세 기준입니다. WebSocket API의 메서드 이름과 REST URL을 같은 문자열로 취급하지 않습니다.

공개 시세 조회가 아니다

USER_DATA 자료이므로 공개 시장 데이터처럼 인증 없이 모든 계정의 기록을 조회하는 기능으로 생각하면 안 됩니다. 공식 서명·timestamp·recvWindow 조건을 따라야 합니다.

비밀키나 서명을 문제 해결용 문서에 그대로 넣지 않습니다. 기록을 검토할 때 필요한 것은 주로 주문 식별자와 사건 내용이며, 인증 원문을 공개할 이유는 없습니다.

지원되는 조회 조합

작성일 명세는 limit 기본값 500, 최대값 1000을 안내합니다. 이 숫자는 전체 기록이 그 개수뿐이라는 뜻이 아니라 한 요청에서 다루는 반환 범위와 관련됩니다.

표에 없는 startTime·endTime 같은 값을 다른 엔드포인트에서 가져와 지원된다고 가정하지 않습니다. 비슷한 조회 API라도 지원 조합과 페이지 방식은 다를 수 있습니다.

요청 가중치

명세는 잘못된 symbol일 때 2, preventedMatchId로 조회할 때 2, orderId로 조회할 때 20의 요청 가중치를 안내합니다.

이 가중치는 거래 수수료가 아닙니다. API 호출 제한을 관리하는 값입니다. 전체 주문 기록을 반복 조회하는 방식과 이미 알고 있는 특정 사건을 확인하는 방식의 비용이 다를 수 있습니다.

가중치가 낮다고 무제한 호출해도 된다는 뜻은 아닙니다. 현재 제한 규칙과 응답을 확인하고 필요한 범위만 조회하는 것이 좋습니다.

응답 필드를 읽는 순서

먼저 symbol과 preventedMatchId로 사건을 식별합니다. 다음으로 takerOrderId와 makerOrderId를 연결하고, makerSymbol이 제공되면 그 값을 별도로 보존합니다.

그다음 selfTradePreventionMode와 방지 수량 관련 필드를 읽습니다. price와 transactTime은 사건의 맥락을 설명하지만 실제 체결 거래의 가격·시각으로 장부에 넣지 않습니다.

필드가 항상 모두 나타난다고 가정하지 않습니다. 모드와 응답 종류에 따라 조건부 정보가 달라질 수 있으므로 실제 자료와 공식 표시 조건을 함께 확인해야 합니다.

maker와 taker는 매수·매도가 아니다

makerOrderId와 takerOrderId를 각각 매도·매수 주문으로 번역하면 안 됩니다. maker와 taker는 주문장에 유동성을 제공하거나 가져가는 역할과 관련된 구분입니다.

매수 주문도 상황에 따라 maker 또는 taker가 될 수 있고 매도 주문도 마찬가지입니다. 실제 방향은 해당 주문의 side에서 확인해야 합니다.

사건 기록에 역할 식별자가 있다는 이유만으로 거래 방향까지 추측하지 않는 것이 중요합니다. 주문 ID로 원래 주문 자료를 연결하면 방향과 유형을 확인할 수 있습니다.

STP 모드와 기록의 관계

EXPIRE_TAKER, EXPIRE_MAKER, EXPIRE_BOTH는 어느 쪽 잔여 수량을 종료시키는지 이해하는 데 중요합니다. DECREMENT는 양쪽 방지 수량에 영향을 주며 작은 쪽 또는 같은 크기의 양쪽 주문이 종료될 수 있는 구조입니다.

NONE은 자기거래 방지를 적용하지 않는 모드로 설명됩니다. 다만 모든 거래쌍과 모든 계정에서 모든 모드를 사용할 수 있다고 가정하면 안 됩니다. exchangeInfo의 허용 모드와 기본 모드를 확인해야 합니다.

작성일 공식 자료에는 TRANSFER도 설명되어 있습니다. 같은 계정이면 DECREMENT와 같은 동작으로 설명되며, 같은 tradeGroupId의 다른 계정 사이에서는 추가 전송 동작을 포함할 수 있습니다. 양쪽 주문의 모드 조건도 중요하므로 일반적인 실제 체결로 단순화하지 않습니다.

적용 모드와 지정 모드가 다를 수 있다

현재 STP FAQ는 실제 적용 모드가 해당 주문에 지정된 모드와 다를 때 효과적인 모드 정보가 보고될 수 있다고 설명합니다. FULL 응답의 preventedMatches 항목과 사용자 데이터 이벤트 등 자료별 표시 방식이 다릅니다.

이 때문에 “내 주문에 설정한 값”만 보고 사건 결과를 단정하지 않습니다. 실제 사건에서 적용된 모드 정보가 제공되는지 확인합니다.

조회 응답의 모든 형식이 동일한 필드를 준다고 확대 해석하지 않고, 읽고 있는 전송 방식의 문서를 따릅니다. 모드가 다르게 보이면 어느 주문 기준의 보고인지도 확인해야 합니다.

거래쌍의 허용 모드

공식 FAQ는 defaultSelfTradePreventionMode와 allowedSelfTradePreventionModes를 설명합니다. 기본값을 생략한 주문과 명시한 주문이 어떤 조건으로 처리되는지 이해하는 데 필요합니다.

허용되지 않는 모드를 넣으면 오류가 날 수 있습니다. 다른 거래쌍에서 사용한 설정을 복사했다고 현재 거래쌍에서도 유효하다는 보장은 없습니다.

기록 분석에서는 요청 당시 지정한 모드, 당시 허용 조건, 실제 사건 자료를 구분합니다. 현재 기본 모드를 과거 모든 주문에 소급 적용하지 않습니다.

누적 방지 수량과 사건별 수량

사용자 데이터의 STP 관련 설명에는 A가 누적 방지 수량, B가 마지막 사건의 방지 수량으로 소개됩니다. 이 구분은 같은 주문에서 여러 사건이 발생했을 때 중요합니다.

누적값을 이벤트마다 새 수량처럼 합산하면 중복 계산이 됩니다. 예를 들어 누적 방지량이 2, 다음에 5로 보였다면 두 값을 7로 더하는 방식은 잘못될 수 있습니다.

반대로 마지막 사건 수량만 보관하면 주문 전체의 방지 영향이 얼마나 누적됐는지 놓칠 수 있습니다. 어떤 필드가 누적이고 어떤 필드가 사건별인지 명시한 자료 구조가 필요합니다.

열린 주문의 잔량 관계

공식 FAQ는 열린 주문에서 원수량에서 실제 체결량과 방지 수량을 뺀 값이 추가 실행 가능한 수량이라는 관계를 설명합니다.

이 관계를 사용할 때는 주문이 열린 상태인지, 수량 수정 등 다른 사건이 반영됐는지, 같은 시점 자료를 비교하고 있는지 확인해야 합니다. 서로 다른 시점의 원수량과 누적값을 섞으면 잘못된 결과가 나올 수 있습니다.

종료된 주문에 계산상 숫자가 남는다고 자동으로 다시 실행될 수 있는 잔량이라고 표시하지 않습니다. 상태와 수량을 함께 해석해야 합니다.

조회 결과가 여러 건인 이유

한 주문이 여러 상대 주문과 자기거래 방지 상황을 만날 수 있습니다. 따라서 orderId로 조회한 결과가 한 건만 나온다고 가정하면 안 됩니다.

여러 기록이 있다고 같은 주문이 여러 번 실제로 거래됐다는 뜻도 아닙니다. 각각은 방지된 사건이며 실제 체결 내역과 별도로 읽어야 합니다.

데이터를 표로 펼칠 때는 사건별 한 행, 주문별 요약은 별도 표로 만드는 방식이 명확합니다. 사건 수와 주문 수, 방지 수량과 체결 수량을 서로 다른 지표로 유지합니다.

페이지 경계와 중복

fromPreventedMatchId와 limit을 활용하는 경우 시작 경계의 포함 여부와 반환 순서는 현재 명세와 실제 결과를 확인해 처리해야 합니다. 근거 없이 다음 ID가 항상 이전 ID+1이라고 가정하지 않습니다.

페이지가 겹쳐도 중복 사건을 다시 더하지 않도록 식별자를 기준으로 대조합니다. 반대로 누락을 피하려고 전체 자료를 매번 합산하면 중복이 늘어날 수 있습니다.

반환 개수가 limit과 같다는 사실은 조회 범위를 추가 확인할 필요가 있다는 단서일 수 있지만 전체 기록 수를 확정해 주지 않습니다. 완전성은 조회 조건과 경계 검증을 통해 판단해야 합니다.

실무 대조 절차

1단계: STP 관련 단서를 확인

주문 상태와 preventedMatchId 같은 관련 필드를 확인합니다. 모든 취소·만료를 STP로 분류하지 않습니다.

일반 IOC 종료나 가격 실행 규칙에 따른 만료는 다른 원인일 수 있습니다. 사유가 불명확하면 원본 상태와 공식 정의를 먼저 대조합니다.

2단계: 정확한 조회 조합을 선택

사건 ID가 있으면 특정 사건 조회를, 주문 기준으로 전체 관계를 보려면 orderId 조회를 검토합니다. symbol은 현재 명세에 맞게 포함합니다.

필요 이상의 범위를 반복 조회하지 않습니다. 인증 오류, 잘못된 symbol, 지원하지 않는 필드 조합을 서로 다른 문제로 구분합니다.

3단계: 원본 기록을 보존

응답의 식별자와 모드, 수량, 시각을 원본 의미대로 저장합니다. 사람이 보기 쉬운 번역은 별도 열에 둘 수 있습니다.

단순화 과정에서 maker·taker를 매수·매도로 바꾸거나 방지 수량을 체결 수량으로 바꾸지 않습니다. 원본과 해석을 분리해야 추후 검증이 가능합니다.

4단계: 양쪽 주문을 연결

takerOrderId와 makerOrderId로 관련 주문의 방향·유형·원수량·상태를 확인합니다. 접근 가능한 계정 범위 안에서 확인한 사실만 사용합니다.

상대 역할의 주문 자료를 모두 볼 수 없다면 그 한계를 기록합니다. 확인할 수 없는 주문의 잔고나 의도를 추측해서는 안 됩니다.

5단계: 실제 체결과 별도 집계

실제 거래 내역은 거래 장부에, 방지 사건은 STP 장부에 둡니다. 하나의 주문에서 두 자료가 모두 존재할 수 있습니다.

최종 보유량은 실제 거래와 자산 이동 자료로 확인합니다. 방지 가격과 수량을 가상의 매매로 장부에 반영하지 않습니다.

6단계: 누적량과 개별 사건을 대조

누적 방지량과 사건별 수량의 단위를 확인하고 중복을 제거합니다. 서로 다른 응답 출처가 같은 사건을 보고했는지도 확인합니다.

누적값이 맞지 않으면 자료 시각과 조회 범위, 주문 수정, 모드 차이를 점검합니다. 원인을 모른 채 수량을 임의로 맞추지 않습니다.

7단계: 운영 원인과 후속 행동을 분리

왜 같은 계정 또는 그룹의 주문이 마주쳤는지 전략·주문 관리 흐름을 검토할 수 있습니다. 이것은 곧 STP를 해제하라는 뜻이 아닙니다.

방지된 수량을 다시 주문할지는 기존 체결과 현재 목표를 반영한 별도 결정입니다. 기록 확인 과정에서 실제 거래 설정을 자동으로 바꾸지 않습니다.

가상 사례 1: 메이커 쪽 주문 종료

가상의 주문장에 같은 계정의 매수 주문 M이 있고, 새 매도 주문 T가 들어와 서로 만날 상황이라고 가정합니다. 사건 기록의 모드가 EXPIRE_MAKER로 확인됐습니다.

분석자는 makerOrderId=M, takerOrderId=T를 각각 연결합니다. 메이커 쪽 종료 기록과 테이커 쪽의 이후 상태를 별도로 확인합니다.

이 사건의 price와 makerPreventedQuantity를 실제 매도 체결로 기록하면 안 됩니다. 방지된 사건이므로 실제 거래 내역과 구분해야 합니다.

테이커 주문이 그 뒤 다른 상대와 거래했는지는 별도 자료로 확인합니다. 자기거래가 방지됐다는 사실만으로 테이커 주문 전체의 미래 결과를 알 수는 없습니다.

가상 사례 2: 일부 체결 후 STP

가상의 매도 주문 10개 중 3개가 외부 상대와 실제 체결됐고, 이후 자기 주문과 마주쳐 STP가 발생했다고 가정합니다.

장부에는 실제 체결 3개가 남아야 합니다. STP로 종료됐다는 이유로 전체 거래를 0으로 바꾸면 보유량이 틀어집니다.

동시에 방지된 부분을 실제 체결 3개에 더해 거래량을 부풀려서도 안 됩니다. 체결 장부와 방지 장부가 같은 orderId로 연결되지만 합산 대상은 다릅니다.

최종 주문 상태, 누적 체결량, 방지 수량과 실제 잔고를 함께 확인하면 어떤 부분이 실행됐는지 설명할 수 있습니다.

가상 사례 3: 두 경로에서 같은 사건 수신

가상의 방지 사건 ID 42를 사용자 데이터 이벤트에서 확인한 뒤 REST 조회에서도 다시 받았다고 가정합니다. 수신 횟수는 두 번이지만 사건은 하나일 수 있습니다.

수신 시각이 다르다는 이유로 두 사건으로 추가하면 방지량이 중복됩니다. symbol과 사건 식별 범위, 주문 관계를 기준으로 대조해야 합니다.

원본 출처는 둘 다 보관할 수 있습니다. 다만 통계에서는 동일 사건 재확인과 새 사건을 구분합니다.

이 원칙은 연결 복구 후 과거 자료를 다시 조회할 때도 중요합니다. 복구를 위해 겹치는 구간을 읽었다면 중복 제거가 함께 있어야 합니다.

가상 사례 4: 누적 방지 수량 2에서 5로 증가

가상의 열린 주문에서 처음 누적 방지량이 2, 나중에 5로 나타났다고 가정합니다. 단순 합계 7은 누적값을 잘못 더한 결과일 수 있습니다.

동일 주문과 같은 필드의 연속 자료인지 확인한 뒤 차이를 해석합니다. 사건별 기록이 있다면 그 자료와 대조해 증가분을 설명할 수 있습니다.

늦게 도착한 과거 이벤트가 섞였거나 조회 시점이 다르면 단순 차이 계산만으로도 오류가 생길 수 있습니다. 시간과 식별자를 함께 확인합니다.

기록을 수정할 때는 원본 누적값을 지우지 않고 파생 계산을 별도로 남기는 편이 좋습니다. 나중에 순서 문제가 확인되면 재계산할 수 있습니다.

가상 사례 5: 다른 계정인데 같은 그룹

가상의 두 계정이 같은 tradeGroupId에 속해 있다고 가정합니다. 운영자는 계정이 다르므로 자기거래 방지가 적용되지 않을 것이라고 생각했지만 관련 사건이 기록됐습니다.

공식 정의상 같은 그룹의 계정 사이도 STP 판단 범위가 될 수 있으므로, 계정 구분만으로 원인을 배제할 수 없습니다.

그룹 값과 각 주문의 모드, 실제 적용 모드와 사건 자료를 확인합니다. TRANSFER처럼 추가 조건이 있는 모드는 일반 체결이나 단순 만료와 동일하게 처리하지 않습니다.

이 사례는 그룹 구조를 추측하지 말고 실제 계정 자료에서 확인해야 한다는 점을 보여줍니다. 기록을 통해 확인하지 못한 권한이나 자산 이동을 임의로 만들지 않습니다.

모드별 해석에서 조심할 점

모드 이름은 사건 해석의 중요한 단서이지만 전체 결과를 대신하지 않습니다. 실제 상태와 수량 자료를 함께 읽어야 합니다.

특히 설정된 모드와 효과적인 모드가 다를 수 있는 구조에서는 어느 주문 기준으로 보고된 값인지도 중요합니다. 한쪽 보고서의 필드 생략을 다른 쪽 보고서의 값과 기계적으로 비교해 오류라고 판단하지 않습니다.

빈 결과 또는 예상과 다른 결과의 점검

조회 결과가 비어 있다면 먼저 symbol과 식별자를 확인합니다. 주문 ID와 방지 사건 ID를 바꿔 넣지 않았는지 살펴봅니다.

그다음 실제로 STP 관련 사건이 있었는지 원본 주문 상태를 확인합니다. 일반 만료를 STP로 오해했다면 조회 대상 자체가 잘못됐을 수 있습니다.

조회 범위와 페이지 경계도 확인합니다. 특정 시작 ID 이후만 조회하면서 이전 사건이 없다고 결론내릴 수는 없습니다.

문서에 명시되지 않은 보존 기간이나 반영 지연 시간을 만들어 설명하지 않습니다. 현재 공식 안내와 실제 관측으로 확인할 수 없는 부분은 미확인으로 남깁니다.

오류를 줄이는 데이터 검증

숫자로 보이는 ID를 소수 계산용 숫자로 처리하면 큰 값에서 정밀도 문제가 생길 수 있습니다. 사용 언어와 저장소가 해당 정수 범위를 정확히 보존하는지 점검할 필요가 있습니다.

가격과 수량은 십진값으로 보관하고 단위를 유지합니다. 표시용 반올림값으로 원본을 덮어쓰면 나중에 수량 대조가 어려워집니다.

다른 자산의 수량을 한 합계로 더하지 않습니다. 여러 symbol을 묶어 통계 낼 때는 사건 수와 자산별 수량을 구분해야 합니다.

기록표 예시

이 표는 분석용 구조의 예시입니다. 실제 API에 존재하지 않는 필드를 요청에 넣으라는 뜻이 아닙니다.

운영 보고서에는 “자기거래 방지 3건”과 “방지 수량 3개”를 구분해서 표현합니다. 사건 수, 주문 수, 자산 수량은 서로 다른 단위입니다.

동일 주문이 여러 사건에 연결될 수 있으므로 사건 수와 고유 주문 수도 다를 수 있습니다. 통계를 설명할 때 어떤 기준으로 센 숫자인지 밝혀야 합니다.

자주 묻는 질문

Q1. Prevented Match는 실제 체결인가요?

아닙니다. 자기거래가 방지된 사건 기록입니다. 가격과 수량이 있어도 실제 거래 장부에 그대로 합산하면 안 됩니다.

Q2. 현재 REST 조회 경로는 무엇인가요?

작성일 엔드포인트 명세는 GET /api/v3/myPreventedMatches를 안내합니다. 실제 적용 전 최신 REST 명세를 확인하고 다른 API 방식의 메서드 이름과 혼동하지 않습니다.

Q3. 공개 시세처럼 인증 없이 조회하나요?

USER_DATA 보안 유형입니다. 공식 인증과 서명 조건을 따라야 하며 다른 계정의 비공개 자료를 임의로 조회하는 기능이 아닙니다.

Q4. preventedMatchId와 orderId는 같은가요?

다릅니다. 하나는 방지 사건을, 다른 하나는 주문을 식별합니다. 요청 조합과 반환 자료에서 역할을 구분해야 합니다.

Q5. maker는 매도, taker는 매수인가요?

아닙니다. 역할 구분입니다. 실제 매수·매도 방향은 관련 주문의 side에서 확인합니다.

Q6. 한 주문에 여러 기록이 나올 수 있나요?

가능합니다. 여러 상대 주문과 방지 상황이 생길 수 있으므로 한 주문당 한 사건이라고 가정하면 안 됩니다.

Q7. STP로 종료되면 이전 체결도 취소되나요?

이미 실제로 체결된 부분과 이후 방지된 부분을 구분해야 합니다. 종료됐다는 이유로 과거 체결을 삭제하지 않습니다.

Q8. 누적 방지 수량을 이벤트마다 더해도 되나요?

중복 계산이 될 수 있습니다. 누적값과 마지막 사건 수량을 구분하고 동일 주문·시각·출처를 대조합니다.

Q9. 다른 계정 사이에서도 발생할 수 있나요?

공식 정의상 같은 tradeGroupId의 계정 사이도 판단 범위가 될 수 있습니다. 실제 그룹 자료를 확인해야 합니다.

Q10. tradeGroupId가 -1이면 STP가 전혀 없나요?

그룹이 설정되지 않았다는 설명과 같은 계정 내 STP 가능성은 구분해야 합니다. 같은 계정의 주문 사이에서는 관련 상황이 생길 수 있습니다.

Q11. 조회 결과가 비면 STP가 없었다는 뜻인가요?

조회 조건·식별자·범위와 원본 주문 상태를 먼저 확인해야 합니다. 잘못된 조건이나 제한된 범위의 빈 결과를 전체 이력의 부재로 확대하지 않습니다.

Q12. limit 1000이면 전체 기록이 1000건인가요?

아닙니다. 작성일 명세의 요청 반환 최대값입니다. 전체 이력 수와 조회 완전성은 별도로 확인해야 합니다.

Q13. 요청 가중치가 수수료인가요?

아닙니다. API 호출 제한을 관리하는 값입니다. 실제 거래 수수료와 혼동하지 않습니다.

Q14. STP 모드를 바꾸면 문제를 해결할 수 있나요?

모드 변경은 거래 동작을 바꾸는 결정입니다. 기록 확인만으로 변경을 권할 수 없으며 허용 모드와 주문 목적을 검토해야 합니다. 보호 동작을 무조건 해제하는 방식으로 접근하지 않습니다.

Q15. 가장 중요한 검증은 무엇인가요?

방지 사건과 실제 체결을 분리하고, 사건 ID와 양쪽 주문 ID를 정확히 연결하는 것입니다. 그다음 모드·수량·시각·중복 여부를 대조합니다.

확인 체크리스트

• 실제 체결과 방지 사건을 별도 장부로 관리하는가.
• 현재 REST 엔드포인트와 지원 파라미터 조합을 확인했는가.
• symbol과 사건 ID·주문 ID를 구분했는가.
• 계정과 상품 범위를 혼동하지 않았는가.
• maker·taker를 매수·매도로 잘못 번역하지 않았는가.
• 제공된 makerSymbol을 보존하는가.
• 설정 모드와 실제 적용 모드 정보를 구분하는가.
• 거래쌍의 기본·허용 STP 모드를 확인하는가.
• 누적 방지량과 사건별 수량을 구분하는가.
• 여러 경로에서 받은 동일 사건을 중복 집계하지 않는가.
• 페이지 경계와 반환 범위를 검증하는가.
• 일부 실제 체결 후 STP 종료를 올바르게 반영하는가.
• 방지 가격·수량을 가상의 실제 거래로 만들지 않는가.
• 인증 원문과 비밀값을 공유 자료에서 제거했는가.

핵심 정리

마무리

바이낸스 Prevented Matches 확인은 자기거래 방지 결과를 정확한 주문 관계와 수량으로 해석하는 작업입니다. 기록에 가격이 보인다는 이유만으로 실제 거래로 처리하지 않고, 사건별 자료와 누적값을 나눠 읽는 것이 핵심입니다.

주문 기록의 정확성을 확보한 다음에는 시장 데이터의 전달 방식도 이해할 필요가 있습니다. 다음 주제인 SBE 시장 데이터에서는 바이너리 형식과 JSON, 호가 갱신과 누락 가능성을 구분해 살펴봅니다.

공식 참고 자료

• Binance Spot 계정 엔드포인트의 Query Prevented Matches
• Binance Spot 자기거래 방지 FAQ
• Binance Spot 상태와 모드 정의

이 글은 기록 해석과 API 이해를 위한 정보이며 투자 권유가 아닙니다. 모드·필드·지원 조건은 변경될 수 있으므로 실제 사용 전 최신 공식 문서를 확인하세요.