바이낸스 SOR 체결 배분 확인 2026｜Allocation·주문 ID·수량 대조 가이드

바이낸스 SOR 체결 배분 확인 2026｜Allocation·주문 ID·수량 대조 가이드

바이낸스 SOR 체결 배분 확인은 주문이 어떤 방식으로 실행됐는지 주문 기록과 Allocation 기록을 연결해 읽는 작업입니다. SOR의 일반적인 뜻을 아는 것과, 내 주문의 수량·대금·수수료가 어떤 기록으로 남았는지 확인하는 것은 다릅니다. 이 글은 SOR 주문을 새로 넣는 방법보다 이미 발생한 결과를 대조하는 데 초점을 맞춥니다.

2026년 11월 2일 확인한 Binance 현물 공식 문서에는 SOR 주문으로 발생한 배분 기록을 조회하는 GET /api/v3/myAllocations가 안내돼 있습니다. 응답에는 allocationId, orderId, price, qty, quoteQty, commission 등이 포함됩니다. 공개 시장의 체결 데이터를 보는 요청과 달리 자신의 계정 자료를 읽는 USER_DATA 요청이라는 점부터 구분해야 합니다.

앞선 Pegged Orders 글이 호가를 기준으로 주문 가격을 선택하는 문제였다면, 이번 글은 실행 이후의 기록을 확인하는 문제입니다. 두 기능을 연결해 설명한다고 동시에 사용할 수 있다는 뜻은 아닙니다. 확인한 Pegged 공식 FAQ는 SOR와의 결합을 미지원으로 안내합니다.

먼저 보는 핵심 정리

가장 중요한 질문은 “SOR를 사용했는가”만이 아닙니다. 어느 주문의 어느 배분을 조회했으며, 같은 기록을 두 번 더하지 않았는가를 확인해야 합니다. 이 두 가지가 정리되지 않으면 평균 가격과 수수료 분석도 틀어질 수 있습니다.

1. SOR 개념을 결과 확인 관점에서 읽기

SOR는 같은 기초 자산과 상호 교환 가능한 기준 자산을 사용하는 적격 호가창의 유동성을 활용할 수 있는 구조입니다. 공식 설명은 정해진 구성 안의 호가를 살펴 실행할 수 있다고 안내합니다. 따라서 거래소 전체의 모든 코인 시장을 검색해 환전과 차익 거래를 자동 수행한다는 의미로 읽으면 안 됩니다.

사용자가 주문한 심볼과 내부에서 활용되는 적격 유동성은 구별될 수 있습니다. 공식 FAQ는 매도할 때 주문 심볼의 기준 자산을 받는다고 설명합니다. 다른 호가창의 가격을 활용했다는 이유만으로 사용자의 수령 자산이 임의로 바뀐다고 가정하지 않아야 합니다.

결과 확인에서는 이 구분이 중요합니다. 주문의 symbol은 사용자가 낸 주문을 식별하는 데 필요합니다. 배분 기록을 봤다고 모든 실제 유동성 출처와 내부 라우팅 세부 정보가 공개된다고 기대해서는 안 됩니다. 응답에 없는 경로를 추측으로 채우지 않는 것이 정확한 분석의 출발점입니다.

또한 SOR가 유동성을 활용할 수 있다는 설명과 더 좋은 결과를 보장한다는 주장은 다릅니다. 시점별 호가, 수량, 주문 가격, 유효기간, 수수료가 결과에 영향을 줍니다. 실행 경로 이름만 보고 절감액이나 수익을 계산하지 말고 실제 체결 자료를 이용해야 합니다.

2. 주문·체결·배분은 서로 다른 단위다

하나의 주문이 여러 번 나눠 체결될 수 있다는 사실은 익숙합니다. SOR 결과에서는 여기에 배분 기록이라는 관점이 추가됩니다. 주문 ID가 같다고 각 배분 기록이 중복이라는 뜻은 아니며, 배분 ID가 다르다고 반드시 별개의 주문이라는 뜻도 아닙니다.

다음처럼 계층을 나누면 이해하기 쉽습니다.

1. 주문은 사용자의 거래 의도와 조건을 담습니다.
2. 체결은 실제로 거래된 가격과 수량을 나타냅니다.
3. 배분 기록은 SOR 실행 결과를 조회하고 대조하는 자료입니다.
4. 수수료는 각 기록의 자산 단위와 함께 확인합니다.
5. 계정 잔고는 거래 외 다른 변동도 반영할 수 있습니다.

이 계층을 하나의 표에 섞으면 문제가 생깁니다. 예를 들어 주문 수량과 배분 수량을 모두 거래량으로 합산하면 같은 거래를 반복 집계할 수 있습니다. 잔고 변화를 배분 수량으로 해석해도 입출금이나 다른 주문의 영향이 섞일 수 있습니다.

정확한 대조는 먼저 “이번 표에서 한 행은 무엇인가”를 정하는 데서 시작합니다. 한 행이 주문이면 배분 세부 행을 따로 묶고, 한 행이 배분이면 해당 행의 수량만 집계합니다. 단위를 명확히 하지 않은 총합은 숫자가 그럴듯해도 의미가 불분명합니다.

3. 식별자는 이름별로 보존한다

allocationId는 배분 기록을 구별하는 값이고 orderId는 주문을 연결하는 값입니다. 클라이언트가 지정한 clientOrderId와도 역할이 다릅니다. 하나의 ID라는 이름으로 통합해 저장하면 나중에 다른 조회 결과와 연결하기 어렵습니다.

심볼도 함께 보존하는 편이 좋습니다. 숫자 ID 하나만으로 모든 거래쌍과 모든 데이터 종류에서 전역적으로 같은 대상을 뜻한다고 가정하지 않기 위해서입니다. 운영 기록의 키를 설계할 때는 데이터 종류·심볼·문서상 식별자를 묶어 구분해야 합니다.

식별자는 계산에 사용할 숫자가 아닙니다. ID 차이를 거래 건수나 시간 차이로 해석하지 않아야 합니다. 정수 범위를 다루는 환경에서는 큰 식별자가 정밀도를 잃지 않도록 저장 방식도 확인해야 합니다. 이는 데이터 처리상의 권고이며 거래소가 특정 프로그래밍 언어를 요구한다는 뜻은 아닙니다.

4. Query Allocations의 범위부터 정하기

현재 문서에서 symbol과 timestamp는 필수 항목으로 안내됩니다. orderId, fromAllocationId, 시간 범위와 limit 등은 조회 범위를 정하는 데 사용됩니다. 서명된 계정 요청이므로 공개 시세 조회와 같은 방식으로 취급하면 안 됩니다.

이 글에서는 개인 계정의 API 키를 입력하거나 실제 계정 자료를 가져오지 않습니다. 독자가 사용하는 도구에서 공식 문서와 조회 권한을 확인하는 방법을 설명합니다. 자격 증명을 블로그 예제나 공개 오류 화면에 넣지 않아야 합니다.

단일 주문을 점검한다면 먼저 주문의 symbol과 orderId를 확인하고 그 주문에 연결되는 배분을 조회하는 편이 범위를 이해하기 쉽습니다. 하루 전체 실행을 분석한다면 시간 범위와 페이지 수집 규칙을 먼저 정해야 합니다. 두 목적을 한 요청으로 대충 해결하려 하면 누락과 중복을 구분하기 어렵습니다.

현재 공식 문서는 startTime과 endTime을 함께 쓰는 범위가 24시간을 넘을 수 없다고 설명합니다. 이는 한 요청의 조회 범위 조건이지, 모든 데이터가 24시간 뒤 사라진다는 뜻이 아닙니다. 보존 기간을 별도 근거 없이 추정하지 않아야 합니다.

limit은 기본 500, 최대 1000으로 안내됩니다. 이 숫자는 결과 페이지의 행 수 제한이며 주문 수량이나 일일 거래 한도가 아닙니다. 1000개 행을 받았다고 해당 기간의 모든 결과를 확보했다고 단정하지 말고 후속 페이지 필요 여부를 확인해야 합니다.

5. 지원되는 조회 조합을 사용하기

공식 문서는 symbol만 사용하는 조회, 시간 범위를 더하는 조회, fromAllocationId를 사용하는 조회, orderId로 좁히는 조회 등을 구분합니다. 임의로 모든 선택 항목을 한 번에 붙이는 것이 더 정확한 조회를 보장하지는 않습니다.

표는 이해를 돕기 위해 조회 조건만 요약한 것입니다. 실제 요청에는 인증·시간 관련 필수 항목이 추가로 필요합니다. 예시 조합을 완성된 요청 문자열로 오해하지 않아야 합니다.

시간 기준으로 수집한 자료와 ID 기준으로 수집한 자료를 합칠 때는 이미 받은 행이 다시 들어올 수 있습니다. 이를 정상적인 중복 수신으로 관리할지, 정말 다른 배분인지 식별자로 판단해야 합니다. 파일 이름이나 다운로드 시각만으로 다른 자료라고 생각하면 총합이 부풀어집니다.

페이지 경계의 포함 여부와 정렬 방향은 현재 문서 및 실제 응답으로 확인합니다. 추측으로 ID에 임의 숫자를 더해 건너뛰는 구현은 누락을 만들 수 있습니다. 수집 도구에는 마지막으로 검증된 경계와 실제 수집 행 수를 함께 남기는 것이 좋습니다.

6. 가격·수량·대금을 연결하는 방법

응답의 price와 qty는 해당 배분 기록의 가격과 수량을 읽는 데 사용됩니다. quoteQty는 기준 자산 금액입니다. 설명용 사례에서는 가격 곱하기 수량으로 금액을 계산할 수 있지만, 실제 결과를 검증할 때는 반환된 값과 정밀도 규칙을 우선 확인합니다.

여러 기록의 평균 가격을 계산하려면 단순 가격 평균보다 수량 가중을 고려해야 합니다. 수량 1의 가격과 수량 9의 가격을 같은 비중으로 평균내면 전체 실행 단가를 잘못 표현할 수 있습니다. 같은 자산 단위와 같은 집계 범위라는 조건이 먼저 충족돼야 합니다.

가상 배분 A가 가격 100에 수량 1, 배분 B가 가격 102에 수량 3이라면 총수량은 4, 총대금은 406입니다. 수량 가중 평균은 101.5입니다. 가격 두 개만 더해 2로 나눈 101은 이 실행의 전체 단가를 나타내지 못합니다.

이 계산에는 수수료가 포함되지 않았습니다. 수수료가 기초 자산에서 차감됐다면 순수령 수량이 달라질 수 있고, BNB 등 다른 자산으로 지급됐다면 별도 비용으로 관리해야 합니다. 평균 실행 가격과 비용을 포함한 순경제적 결과를 같은 항목으로 표시하지 않는 것이 좋습니다.

7. 수수료는 자산별로 먼저 묶는다

commission 숫자만 합산하면 서로 다른 자산 단위를 더할 수 있습니다. 예를 들어 0.001 BTC와 0.01 BNB를 더해 0.011이라는 수수료 총액을 표시하는 것은 의미가 없습니다. 자산별로 집계한 뒤, 필요한 경우 명시한 환산 기준으로 비교해야 합니다.

수수료 환산에는 기준 시각과 가격 출처가 필요합니다. 현재 가격으로 바꾼 비용과 체결 당시 가격으로 바꾼 비용은 다를 수 있습니다. 어떤 방식이 분석 목적에 맞는지 먼저 정하고 보고서에 표시해야 합니다.

또한 문서 예시에서 commission이 0이라는 이유로 실제 SOR가 항상 무료라고 설명하면 안 됩니다. 공식 설명용 데이터와 실제 계정 요율은 다릅니다. 실제 결과는 응답의 commission 및 commissionAsset, 계정의 현재 수수료 조건을 기준으로 확인해야 합니다.

손익 분석과 수수료 확인을 분리하는 이유도 여기에 있습니다. 체결 배분 기록은 거래 결과의 중요한 자료이지만 세금, 전체 포트폴리오 성과, 입출금 비용까지 한 번에 설명하는 장부는 아닙니다. 무엇을 포함하고 제외했는지 적어야 숫자를 올바르게 해석할 수 있습니다.

8. isBuyer·isMaker·isAllocator를 섞지 않기

isBuyer는 해당 기록의 매수 방향을 이해하는 데 쓰고, isMaker는 체결 역할을 구분하는 데 사용합니다. 두 값은 같은 질문에 답하지 않습니다. 매수 주문이라고 항상 테이커가 되는 것도 아니고, 매도 주문이라고 항상 메이커가 되는 것도 아닙니다.

isAllocator라는 필드도 별도로 반환됩니다. 익숙하지 않은 필드 이름을 보고 고객 등급, 수익 배분 자격, 전략 성공 여부 같은 의미를 덧붙이지 않아야 합니다. 현재 공식 스키마에서 설명하는 범위 안에서 보존하고, 확인하지 않은 해석은 분석 결과에서 제외하는 편이 정확합니다.

실무 보고서에는 원문 필드를 보존하는 영역과 사람이 이해하기 쉽게 표시하는 영역을 나누면 좋습니다. 원문을 삭제하고 해석값만 남기면 잘못 해석한 뒤 복구하기 어렵습니다. 반대로 모든 원문을 그대로 보여주면 일반 독자가 목적을 이해하기 어려우므로 핵심 필드를 설명과 함께 제시합니다.

새로운 필드가 추가되더라도 전체 수집이 조용히 실패하지 않도록 해야 합니다. 필요한 필드가 없거나 예상 유형과 다를 때는 확인 필요 상태로 남기고, 무조건 0이나 false로 채우지 않는 것이 바람직합니다. 없는 값과 실제 0은 구별해야 합니다.

9. 주문 상태와 배분 결과를 대조하기

배분 자료를 확보했으면 주문의 executedQty와 상태를 확인합니다. 다만 어떤 자료가 전체 체결을 나타내는지 먼저 판단해야 합니다. SOR 경로를 사용한 주문이라고 모든 후속 체결이 동일한 실행 경로에 머문다고 가정하면 안 됩니다.

공식 SOR FAQ는 유동성으로 전량을 채우지 못한 LIMIT GTC의 잔량이 원래 주문한 호가창에 놓일 수 있다고 설명합니다. LIMIT IOC나 MARKET의 남은 부분은 다른 방식으로 종료될 수 있습니다. 따라서 배분 합계가 전체 주문 체결량과 다르다는 이유만으로 곧바로 데이터 오류라고 결론 내리지 않습니다.

먼저 집계 시점을 맞춥니다. 주문 조회는 나중 시점의 누적값인데 배분 조회는 앞선 시점의 일부 페이지라면 차이가 발생할 수 있습니다. 다음으로 일반 체결 기록과 주문 이벤트를 함께 확인해 SOR 이후 다른 방식의 체결이 있었는지 검토합니다.

마지막으로 중복과 누락을 확인합니다. 동일 배분을 두 번 더한 경우에는 합계가 커질 수 있고, 페이지가 빠진 경우에는 작아질 수 있습니다. 차이를 설명하지 못했는데 단순히 한쪽 숫자를 수정해 맞추면 검증이 아니라 장부를 꾸미는 일이 됩니다.

10. 다섯 가지 가상 점검 사례

아래 사례는 기록을 읽는 연습입니다. 실제 계정·시세·요율을 나타내지 않으며, 예시 숫자가 현재 지원되는 주문 수량이나 시장 조건이라는 뜻도 아닙니다.

사례 1. 하나의 주문에 배분 두 개가 있음

가상 주문 410에 배분 A와 B가 연결돼 있습니다. A는 가격 100, 수량 2이고 B는 가격 101, 수량 3입니다. 두 행의 orderId가 같다는 이유로 B를 중복 삭제하면 전체 체결을 놓치게 됩니다.

배분 식별자가 각각 다르다면 두 행을 별도로 보존하고 총수량 5, 총대금 503으로 계산합니다. 수량 가중 평균은 100.6입니다. 이는 수수료 전 실행 가격 설명이며 순수령 자산의 평가액과는 구분됩니다.

이 사례에서 중복 판단 기준은 주문 ID 하나가 아닙니다. 주문은 여러 배분을 가질 수 있으므로 배분 자체의 식별자를 확인해야 합니다. 주문별 묶음과 배분별 행을 동시에 유지하면 이 구조를 쉽게 표현할 수 있습니다.

사례 2. 다음 페이지에 마지막 행이 다시 보임

첫 조회에서 배분 식별자 A, B, C를 받았고 다음 조회에서 C, D, E를 받았다고 가정합니다. 페이지 경계에 C가 반복됐는데 두 파일을 그대로 합산하면 C의 수량과 비용이 두 번 들어갑니다.

이때 “두 번째 파일이 최신이니 첫 번째 파일 전체를 버린다”는 대응도 적절하지 않습니다. A와 B가 사라질 수 있기 때문입니다. 원문 파일은 보존하고 배분 식별자를 기준으로 중복 행을 정리한 집계표를 별도로 만들면 됩니다.

반복 행의 내용이 다르다면 조용히 덮어쓰지 않고 차이를 확인해야 합니다. 데이터 정정인지, 서로 다른 범위를 잘못 연결했는지, 파싱 과정에서 값이 바뀌었는지 검토해야 합니다. 같은 ID라는 이유로 모든 차이를 무시하는 것도 위험합니다.

사례 3. 24시간보다 긴 기간을 한 번에 조회하려 함

사용자가 일주일 동안의 SOR 결과를 한 번에 분석하고 싶다고 가정합니다. 현재 문서의 시간 범위 제한을 무시하고 일주일을 한 요청으로 보내면 요청 조건과 맞지 않을 수 있습니다.

기간을 허용되는 구간으로 나누고 각 구간의 실제 결과와 경계를 관리합니다. 구간을 나눴다는 것만으로 완전 수집이 보장되는 것은 아닙니다. 각 구간에 페이지 제한보다 많은 행이 있다면 이어 읽기가 필요합니다.

최종 보고서에는 분석 기간, 사용한 시간대, 수집 구간, 중복 제거 기준을 남기는 것이 좋습니다. 일주일이라는 말만 있고 시작·종료 시각이 없으면 다른 사람이 같은 결과를 재현하기 어렵습니다.

사례 4. 배분 합계보다 주문 누적 체결이 큼

가상 LIMIT GTC 주문 수량이 10이고 처음 SOR 관련 배분으로 확인한 수량이 6이라고 가정합니다. 이후 주문 조회에서는 누적 체결 수량 8이 보입니다. 이 차이 2를 즉시 누락이라고 단정하지 않습니다.

먼저 두 자료의 조회 시각과 조회 범위를 맞춥니다. 그다음 원래 호가창에 남은 수량이 나중에 체결됐는지 일반 체결 내역을 확인합니다. 공식 SOR의 잔량 처리 설명을 고려하면 분석 범위를 나눠야 하는 상황일 수 있습니다.

설명이 확인되지 않으면 “배분 6, 전체 체결 8, 차이 2 확인 중”으로 남깁니다. 근거 없이 임의의 배분 행을 만들어 합계를 맞추면 이후 수수료와 잔고까지 잘못 해석하게 됩니다.

사례 5. 수수료 자산이 서로 다름

한 기록의 수수료가 기초 자산으로, 다른 기록의 수수료가 BNB로 표시됐다고 가정합니다. 숫자만 더하면 서로 다른 단위를 합산하게 됩니다. 먼저 자산별 수수료를 각각 표시합니다.

전체 비용 비교가 필요하면 사용할 환산 시점과 가격 출처를 정합니다. 환산 전 원래 수량은 계속 남겨 두어야 합니다. 나중에 환산 기준을 바꿀 때 원자료 없이 이미 합산된 숫자만 있으면 재검증이 어렵습니다.

이 사례는 같은 전략을 사용했더라도 체결 후 비용 기록을 따로 확인해야 한다는 점을 보여줍니다. SOR라는 실행 방식 이름이 수수료 자산과 실제 부과액까지 대신 설명해 주지 않습니다.

11. 빈 응답을 확인하는 순서

빈 배열을 받았다고 “내 계정에서 거래가 전혀 없었다”고 결론 내리면 안 됩니다. 선택한 symbol과 orderId, 기간, 페이지 경계가 맞는지부터 확인해야 합니다. 주문 자체가 SOR 관련 배분을 발생시키는 대상이었는지도 확인합니다.

일반 체결 내역과 배분 내역은 같은 목록이 아닙니다. 일반 지정가 거래는 존재하지만 해당 조회 조건의 SOR 배분은 없을 수 있습니다. 반대로 주문 결과를 아직 전체 수집하지 못했을 수도 있습니다. 빈 응답은 좁은 질문에 대한 결과입니다.

오류 응답을 빈 배열로 바꾸는 구현도 피해야 합니다. 인증 실패, 시간 오류, 권한 문제, 요청 한도와 정상적인 결과 없음은 전혀 다릅니다. 사용자 화면에 둘 다 “내역 없음”으로 보이면 운영자가 잘못 판단하게 됩니다.

확인 순서는 요청 성공 여부, 조회 조건, 대상 주문, 데이터 범위, 추가 조회 필요 여부입니다. 문제가 해결되지 않았을 때 무조건 반복 호출하면 요청 한도 문제만 추가될 수 있습니다. 실제 오류 원인에 맞게 처리해야 합니다.

12. 시간과 순서를 다룰 때 주의할 점

자료에는 거래 또는 기록 시각과 프로그램이 수신한 시각이 함께 존재할 수 있습니다. 네트워크 지연 때문에 수신 순서가 항상 사건 발생 순서와 같다고 기대해서는 안 됩니다. 정렬 기준을 명시하고 원래 시각 필드를 보존해야 합니다.

시간대도 중요합니다. 한국시간 하루를 분석하는데 UTC 날짜 경계를 그대로 사용하면 다른 구간을 집계할 수 있습니다. 사용자가 보는 날짜와 실제 요청에 넣는 시간 범위의 대응을 확인해야 합니다. 문자열 날짜만 비교하기보다 정확한 시작·종료 시점을 관리하는 편이 좋습니다.

시간 단위가 밀리초인지 마이크로초인지도 확인해야 합니다. 단위를 잘못 읽으면 오래된 데이터처럼 보이거나 미래 데이터처럼 보일 수 있습니다. 공식 API의 기본 단위 및 요청 설정을 확인하고, 보고서에는 사람이 읽을 수 있는 시각과 원래 값을 함께 보존하는 방법을 고려할 수 있습니다.

동일한 시각에 여러 기록이 존재할 수 있으므로 시간만으로 중복 제거하면 안 됩니다. 서로 다른 배분이 같은 시각 값으로 기록됐을 가능성을 고려해야 합니다. 식별자와 시각은 서로 보완하는 정보이지 서로 대체하는 정보가 아닙니다.

13. 운영용 대조표를 만드는 방법

복잡한 자동화 없이도 먼저 작은 표를 만들 수 있습니다. 심볼, 주문 ID, 배분 ID, 수량, 대금, 수수료, 수수료 자산, 시각을 한 행에 정리합니다. 원문 조회 결과는 별도로 보존하고 표의 계산식과 원문 값을 구분합니다.

그다음 주문별로 묶어 배분 수량과 금액을 합산합니다. 가격은 단순 합산하지 않고 집계 목적에 맞게 가중 평균을 계산합니다. 수수료는 자산별로 묶고, 불명확한 값은 0으로 대체하지 않고 확인 필요로 표시합니다.

주문 조회의 누적 체결 수량과 비교할 때는 조회 시점을 적습니다. 실행 중인 주문의 누적값은 달라질 수 있으므로, 앞선 배분 자료와 나중 주문 결과를 비교한 차이를 곧바로 오류라고 보고하지 않아야 합니다.

마지막으로 검증 상태를 별도 칸에 둡니다. “원문 확보”, “페이지 수집 확인”, “중복 제거”, “주문 대조”, “비용 확인”처럼 어떤 단계까지 끝났는지 표시하면 단순히 완료라는 한 단어보다 정확합니다. 이는 자체 관리표의 예시이며 Binance가 제공하는 상태 이름은 아닙니다.

14. 자주 묻는 질문

Q1. Allocation은 새로운 주문 종류인가요?

이 글에서 다루는 Allocation은 SOR 주문 실행 결과를 확인하는 배분 기록입니다. 별도의 주문을 생성하는 행위와 구분해야 합니다. 조회 결과에 행이 많다고 그만큼 새 주문을 냈다는 뜻은 아닙니다.

Q2. myAllocations는 공개 시장 데이터인가요?

자신의 계정 자료를 조회하는 USER_DATA 요청입니다. 공개 호가나 공개 체결 목록과 다릅니다. 인증 정보가 필요한 요청을 블로그 예시나 공유 화면에 그대로 노출하지 않아야 합니다.

Q3. orderId가 같으면 중복인가요?

아닙니다. 하나의 주문에 여러 배분이 연결될 수 있습니다. 배분 식별자를 구분하고 같은 배분을 재수신했는지 확인해야 합니다. 주문 단위 묶음과 행 단위 중복 제거는 별개입니다.

Q4. allocationId 차이로 거래 건수를 계산해도 되나요?

식별자의 숫자 차이를 거래 건수로 해석하지 않는 것이 좋습니다. 실제로 수집하고 검증한 행을 기준으로 집계해야 합니다. ID는 계산용 거래량 값이 아닙니다.

Q5. 배분 가격을 단순 평균하면 되나요?

수량이 서로 다르면 단순 평균이 전체 실행 가격을 잘못 나타낼 수 있습니다. 같은 범위의 수량과 대금을 사용한 가중 평균을 검토해야 하며 수수료 포함 여부도 별도로 표시해야 합니다.

Q6. quoteQty는 수수료까지 포함한 최종 비용인가요?

수수료 필드가 별도로 있으므로 같은 값으로 가정하지 않습니다. 대금과 수수료 자산을 나눠 읽고, 순수령량이나 총비용을 계산할 때 어떤 항목을 포함했는지 명시해야 합니다.

Q7. 모든 수수료를 숫자로 더해도 되나요?

수수료 자산이 같을 때와 다를 때를 구분해야 합니다. 다른 자산은 먼저 따로 집계하고, 필요한 경우 명시한 환산 기준으로 비교합니다. 단위 없는 합계는 의미가 없습니다.

Q8. 24시간 제한은 보존 기간인가요?

확인한 문서는 startTime과 endTime 사이의 요청 구간 제한을 설명합니다. 이를 데이터 보존 기간으로 바꿔 설명하면 안 됩니다. 조회 범위와 보존 정책은 서로 다른 사항입니다.

Q9. limit 1000이면 주문을 1000개 낼 수 있다는 뜻인가요?

아닙니다. 조회 결과 행 수에 관한 제한입니다. 주문 수량, 미체결 주문 카운트, API 요청 한도와 구별해야 합니다. 같은 숫자라도 단위가 다릅니다.

Q10. 빈 응답이면 거래가 없는 건가요?

지정한 조건의 배분을 찾지 못한 결과일 수 있습니다. 대상 심볼·주문·기간과 요청 성공 여부를 확인해야 합니다. 일반 거래 내역 전체가 없다는 결론으로 넓히지 않습니다.

Q11. SOR 주문의 배분 합계는 항상 전체 체결량과 같나요?

조회 범위와 시점, 잔량의 후속 체결을 확인해야 합니다. 공식 문서는 GTC 잔량이 원래 호가창에 놓일 수 있다고 설명합니다. 차이가 있으면 다른 체결 자료와 대조해야 합니다.

Q12. isBuyer와 isMaker는 같은 방향 정보인가요?

아닙니다. 매수 방향과 체결 역할은 다른 구분입니다. 매수라고 항상 테이커가 되거나 매도라고 항상 메이커가 되는 것은 아닙니다. 각 필드의 의미대로 읽어야 합니다.

Q13. 실제로 어떤 호가창을 썼는지 모두 알 수 있나요?

응답에 나타난 정보만으로 판단해야 합니다. 제공되지 않은 세부 라우팅 경로를 임의로 추정하지 않습니다. 필드가 설명하는 범위와 사용자가 알고 싶은 범위가 같지 않을 수 있습니다.

Q14. Pegged와 SOR를 같이 설정하면 더 정확한가요?

확인한 공식 Pegged 문서는 SOR 미지원을 안내합니다. 서로 다른 기능의 예시를 결합해 지원되는 조합처럼 사용하지 않아야 합니다. 기능 간 비교와 결합 가능성은 다른 문제입니다.

Q15. 배분 확인으로 수익이 좋아졌는지 알 수 있나요?

실행 결과를 분석하는 자료가 되지만 비교 기준과 비용을 함께 정해야 합니다. 같은 시점의 대안 실행을 실제로 관측하지 않았다면 절감액을 확정적으로 말하기 어렵습니다. SOR 사용 자체가 성과 보장은 아닙니다.

15. 실무 점검 체크리스트

• 현물 SOR 결과를 확인하는 작업인지 범위를 정했는가?
• 공개 체결과 계정 배분 자료를 구분했는가?
• 실제 주문의 symbol과 orderId를 확인했는가?
• allocationId를 별도 필드로 보존했는가?
• 문서에 안내된 조회 조합을 사용했는가?
• 시간 구간과 시간대를 명시했는가?
• 페이지 제한으로 남은 결과가 없는지 확인했는가?
• 같은 배분을 재수신했을 때 중복 합산하지 않는가?
• 수량과 대금의 범위를 맞춰 계산했는가?
• 수수료를 자산별로 구분했는가?
• 주문 누적 체결과 비교할 때 조회 시점을 맞췄는가?
• GTC 잔량의 후속 체결 가능성을 확인했는가?
• 오류 응답을 빈 결과나 0으로 바꾸지 않았는가?
• 확인되지 않은 라우팅 경로와 절감액을 추측하지 않았는가?

작은 대조표로 누락과 중복을 구분하는 연습

가상 주문의 배분 자료를 아래처럼 받았다고 해 보겠습니다. 실제 거래소 데이터가 아니라 집계 방법을 설명하는 연습이며, 각 수수료는 이 표에서 제외했습니다.

파일의 모든 행을 더하면 수량 6, 대금 607이 됩니다. 그러나 B가 같은 배분을 다시 받은 행이라면 실제 고유 기록은 A·B·C 세 개이고 수량은 4, 대금은 405입니다. 중복 수신과 실제 거래를 구분하지 않으면 비용과 거래량이 동시에 부풀어집니다.

이때 먼저 할 일은 B가 정말 같은 기록인지 확인하는 것입니다. 여기서 A·B·C는 설명용 표시이므로 실제 분석에서는 심볼과 배분 식별자 등 해당 자료의 키를 사용해야 합니다. 수량과 가격이 같다는 이유만으로 중복이라고 판단하면 같은 조건에서 발생한 서로 다른 배분을 삭제할 수 있습니다.

고유 기록의 평균 가격은 설명상 405를 4로 나눈 101.25입니다. 중복을 제거하기 전에 평균부터 계산하면 그럴듯한 숫자가 나오더라도 실제 실행을 잘못 나타낼 수 있습니다. 집계 순서는 자료 범위 확정, 식별자 검증, 중복 처리, 합계와 평균 계산입니다.

차이를 분류하는 네 가지 칸

대조 중 차이가 발견되면 수집 범위, 식별 오류, 시점 차이, 실행 범위 차이로 나눠 검토할 수 있습니다. 이는 자체 분석을 위한 분류이며 공식 오류 코드가 아닙니다. 한 분류로 결론 내리기 전에 실제 근거가 있는지 확인해야 합니다.

수집 범위 차이는 기간이나 페이지가 다를 때 발생합니다. 첫 페이지 500행만 확보했는데 전체 기간 결과라고 보고했다면 추가 수집이 필요한지 확인해야 합니다. 반대로 결과가 500행보다 적다는 이유만으로 모든 가능한 자료를 확보했다고 단정하지 않고 요청 조건도 점검합니다.

식별 오류는 다른 심볼이나 주문의 행을 섞었거나 같은 배분을 두 번 더했을 때 발생할 수 있습니다. 숫자를 수정하기 전에 연결 키부터 확인합니다. 주문 ID와 배분 ID가 서로 다른 역할을 한다는 점이 여기서 실무적인 의미를 가집니다.

시점 차이는 실행 중인 주문을 서로 다른 순간에 조회할 때 생길 수 있습니다. 처음 대조표를 만든 뒤 추가 체결이 있었다면 최신 주문 누적값이 커질 수 있습니다. 원래 표를 틀렸다고 지우기보다 그 표가 어느 시점까지의 자료인지 표시해야 합니다.

실행 범위 차이는 배분 자료와 전체 주문 체결 자료가 같은 범위를 다루지 않을 때 검토합니다. SOR 이후 잔량의 후속 처리를 공식 설명과 실제 거래 내역으로 확인합니다. 차이가 남으면 확인 중으로 기록하며 임의의 거래 행을 추가하지 않습니다.

이런 분류를 사용하면 “합계가 안 맞는다”는 모호한 문제를 구체적인 확인 작업으로 바꿀 수 있습니다. 최종 보고에는 확인한 자료와 범위, 남은 차이를 함께 적어야 다른 사람이 같은 결과를 검증할 수 있습니다.

핵심 정리

바이낸스 SOR 체결 배분 확인은 복잡한 숫자를 많이 모으는 일이 아니라, 같은 주문의 실제 기록을 정확한 단위로 연결하는 일입니다. ID와 시간 범위, 페이지 경계, 수수료 자산을 먼저 정리하면 평균 가격이나 잔량 차이도 더 명확하게 설명할 수 있습니다.

공식 확인 자료: SOR FAQ, 계정 조회 API, User Data Stream. 실제 사용 전 최신 필드와 지원 조건을 확인하세요.

이 글은 거래 기록 이해를 위한 정보이며 투자 권유가 아닙니다. 가상 사례는 실제 계정 성과를 나타내지 않습니다. 디지털 자산 거래에는 가격 변동, 유동성 부족, 시스템 지연 및 원금 손실 위험이 있습니다.