바이낸스 Trade Stream 뜻 2026｜개별 체결·거래 ID·매수 매도 방향 읽기

바이낸스 Trade Stream 뜻 2026｜개별 체결·거래 ID·매수 매도 방향 읽기

바이낸스 Trade Stream은 현물 시장에서 발생한 개별 공개 체결 정보를 실시간으로 받는 데이터 스트림입니다. 호가창에 대기 중인 수량이나 내 계정의 주문 상태를 조회하는 기능과 다릅니다. 가격과 수량이 실제로 거래된 기록을 어떤 단위로 읽어야 하는지가 이 글의 핵심입니다.

전날 살펴본 Aggregate Trades가 정해진 조건으로 묶인 체결을 다룬다면, Trade Stream은 원래 체결 단위를 읽는 출발점입니다. 두 자료를 함께 이용할 때는 줄 수와 ID를 혼용하지 않아야 합니다. 같은 시장을 관찰하더라도 무엇을 한 건으로 세는지에 따라 통계가 달라집니다.

이 글은 2026년 10월 29일 확인한 Binance Spot WebSocket 공식 문서의 Trade Streams를 기준으로 합니다. 선물·블록 거래·계정 체결 메시지를 같은 규격으로 간주하지 않습니다. 아래 숫자는 개념 설명을 위한 가상 자료이며 현재 시세나 투자 신호가 아닙니다.

1. Trade Stream이 알려주는 것

공식 문서는 Trade Stream이 원시 체결 정보를 전달하며 각 거래에 고유한 매수자와 매도자가 있다고 설명합니다. 공개 메시지에 개인의 신원이 제공된다는 뜻은 아닙니다. 거래의 가격, 수량, 식별자, 체결 시각, maker 방향 같은 시장 데이터를 읽는 구조입니다.

하나의 주문은 여러 상대 주문과 나뉘어 체결될 수 있습니다. 따라서 하나의 체결 메시지를 한 사용자의 주문 전체와 동일하게 생각하면 안 됩니다. 반대로 여러 체결 메시지가 연속으로 나타났다는 사실만으로 서로 다른 사람이 각각 주문했다고 단정할 수도 없습니다.

공개 거래와 개인 주문을 구분

공개 스트림에서 가격 100, 수량 2인 거래를 봤다고 가정해 보겠습니다. 내 주문도 같은 값이었다는 이유만으로 그 메시지를 내 주문의 체결 확인서로 사용할 수는 없습니다. 같은 조건의 거래가 다른 계정에서 발생할 수 있고 공개 메시지는 내 수수료나 주문의 남은 수량을 모두 알려주지 않습니다.

내 주문의 접수·부분 체결·취소·수수료 확인은 계정 주문 기록과 해당 사용자 데이터 규격을 통해 처리해야 합니다. 공개 Trade Stream은 시장 관측에 유용하지만 계정 상태의 권위 있는 기록을 대신하지 않습니다. 자동화에서도 두 데이터의 저장 목적을 분리하는 것이 중요합니다.

체결과 호가의 차이

체결은 이미 거래된 결과이고 호가는 아직 시장에 제시된 가격과 수량입니다. 체결 가격이 100이었다고 현재 100에 같은 수량을 다시 거래할 수 있다는 뜻은 아닙니다. 마지막 체결 이후 최우선 매수·매도 호가가 바뀌었을 수 있습니다.

Trade Stream으로 거래 흐름을 보고 Book Ticker나 Depth로 현재 호가를 보는 이유가 여기에 있습니다. 두 자료를 함께 보더라도 관측 시점과 갱신 방식이 다르므로 숫자를 무조건 일대일로 연결하지 않아야 합니다. 체결량과 호가 감소량이 항상 같다고 가정하는 것도 피해야 합니다.

2. 스트림 이름과 연결 구조

현물 Trade Stream의 이름은 {symbol}@trade입니다. 공식 일반 규칙에서 스트림에 사용하는 심볼은 소문자입니다. 예를 들어 BTCUSDT를 관찰하는 스트림 이름은 btcusdt@trade 형태로 읽습니다. 이는 설명용 예이며 모든 지역에서 특정 서비스 이용이 가능하다는 보장은 아닙니다.

공식 문서는 단일 raw stream과 여러 스트림을 묶는 combined stream을 구분합니다. raw에서는 원래 메시지 본문을 직접 읽고, combined에서는 stream과 data라는 포장 구조 안에 데이터가 들어갑니다. 어떤 형식으로 연결했는지에 맞춰 필드를 읽어야 합니다.

raw와 combined를 혼동했을 때

combined 메시지를 받으면서 최상위에서 p나 q를 찾으면 값이 없다고 판단할 수 있습니다. 실제로는 data 안에 원래 체결 자료가 있는 상황입니다. 정상 응답을 빈 거래로 바꾸거나 가격 0으로 저장하지 말고 메시지 구조를 먼저 확인해야 합니다.

반대로 raw 메시지에 항상 data가 있다고 가정해도 문제가 생깁니다. 수신 단계에서 포장을 해석하고 내부 표준 구조로 변환하는 경계를 정하면 이후 집계 코드를 단순하게 만들 수 있습니다. 변환 전 원본을 제한적으로 남기면 오류 재현에도 도움이 됩니다.

구독 성공과 데이터 수신 성공

구독 제어 요청의 응답이 성공이라고 해서 이후 모든 체결이 누락 없이 저장됐다는 뜻은 아닙니다. 연결·구독·수신·해석·저장·집계는 각각 다른 단계입니다. 운영 화면에서 연결 상태 하나만 초록색으로 표시하면 중간 저장 오류를 놓칠 수 있습니다.

첫 메시지가 실제 대상 심볼이고 이벤트 종류가 trade인지 확인하는 과정이 필요합니다. 이후에도 마지막 수신 시각, 처리 오류, 저장 진행 위치를 구분해서 관찰해야 합니다. 거래가 드문 시장에서는 일정 시간 메시지가 없다는 사실만으로 장애라고 단정할 수 없습니다.

3. t·p·q·T·E·m 필드 읽기

Trade Stream의 t는 거래 ID, p는 가격, q는 수량입니다. T는 체결 시각이고 E는 이벤트 시각입니다. s는 심볼, e는 이벤트 종류를 뜻합니다. 짧은 이름을 보고 모든 t 계열 필드를 시간으로 해석하거나 모든 ID를 같은 종류로 저장하지 않도록 주의해야 합니다.

가격과 수량은 공식 예시에서 문자열로 전달됩니다. 문자열이라는 이유로 문자 순서로 가격을 비교하면 안 되고, 숫자로 바꿀 때도 소수 정밀도를 고려해야 합니다. 원본 값과 화면 표시용 반올림 값을 분리해 보관하는 편이 검증에 유리합니다.

거래 ID는 시각이 아님

t를 날짜로 변환하거나 초·밀리초 단위처럼 다루지 않습니다. 식별자의 역할은 거래를 구분하는 것이며 시간 집계는 T 같은 해당 시간 필드의 의미를 따라야 합니다. ID 차이를 경과 시간으로 바꾸는 것도 근거 없는 해석입니다.

다른 심볼이나 다른 제품에서 같은 숫자의 ID가 보일 수 있다는 가능성을 고려해 키를 설계합니다. 제품·환경·심볼·거래 ID를 구분하면 자료 충돌을 줄일 수 있습니다. 현물과 선물 또는 실거래와 테스트 자료를 한 저장소에서 섞을 때 특히 중요합니다.

q와 p×q의 단위

q는 체결 수량이며 p×q는 해당 거래쌍의 quote 자산 기준 금액으로 이해할 수 있습니다. 예를 들어 가격 100, 수량 0.5라면 가상 거래 금액은 50입니다. 수량 0.5와 금액 50은 같은 지표가 아닙니다.

여러 거래쌍의 q를 그대로 더하면 서로 다른 기초 자산 단위를 합치는 오류가 생길 수 있습니다. quote 자산이 같더라도 가격·시점·환산 목적을 확인해야 합니다. 보고서에는 수량인지 거래 금액인지 단위를 명확하게 적어야 합니다.

4. m으로 매수·매도 방향을 읽는 법

공식 설명에서 m은 매수자가 maker인지 묻는 값입니다. true라면 매수자가 maker이고 상대편 매도자가 taker인 관계입니다. false라면 매수자가 maker가 아닌 관계이므로 taker 매수 방향으로 읽을 수 있습니다. true를 곧바로 매수 신호라고 해석하면 방향이 반대로 계산됩니다.

모든 체결에는 매수자와 매도자가 함께 존재합니다. 분석 화면에서 매수 체결량이라고 부르는 값은 보통 어느 쪽이 유동성을 가져간 taker인지에 따른 분류입니다. 거래에 매수자만 있었다는 뜻으로 표현해서는 안 됩니다.

방향별 합계는 전체와 대조

동일한 고유 거래 집합을 taker buy와 taker sell로 나눴다면 두 수량의 합이 전체 수량과 일치하는지 확인할 수 있습니다. 이 검사는 자료 처리의 일관성을 확인하는 것이며 미래 가격 예측이 맞는지 검증하는 절차가 아닙니다.

합계가 맞지 않으면 m의 자료형, 누락 필드, 중복 제거 위치, 시간 구간 기준을 점검합니다. 문자열 "false"를 단순히 값이 있는 문자열로 처리하면 참처럼 취급하는 언어도 있으므로 파싱 규칙을 명확히 해야 합니다. 원본 boolean의 의미를 유지하는 것이 중요합니다.

방향과 주문 종류를 동일시하지 않기

taker라는 이유만으로 원래 주문이 반드시 시장가 주문이었다고 단정하지 않습니다. 즉시 상대 호가와 체결되는 지정가 주문도 있을 수 있습니다. maker·taker는 거래에서 유동성을 제공하거나 가져가는 역할과 관련된 분류이며 공개 필드만으로 모든 주문 조건을 복원할 수는 없습니다.

또한 체결 방향이 한쪽으로 쏠렸다고 다음 가격이 반드시 그 방향으로 움직이는 것은 아닙니다. 남은 유동성, 다른 시장, 관측 구간, 이후 신규 주문 등 여러 조건이 있습니다. 관측한 수량과 해석한 전망을 구분해 표시해야 합니다.

5. 서로 다른 다섯 가지 체결 사례

예시 1. 같은 가격에 두 번 체결

가격 100에서 수량 0.2와 0.3의 서로 다른 거래 ID가 수신됐다고 가정합니다. 개별 체결 관점에서는 두 건이고 수량 합계는 0.5, 금액 합계는 50입니다. 가격과 시각이 비슷하다는 이유로 두 메시지를 하나의 중복으로 제거하면 실제 거래량이 줄어듭니다.

중복 판정에는 가격·수량의 우연한 일치보다 해당 자료의 고유 식별자를 사용해야 합니다. 같은 가격과 수량의 거래가 반복될 수 있기 때문입니다. 반대로 같은 ID를 두 번 받았다고 실제 거래가 두 번 발생한 것은 아닙니다.

예시 2. 한 주문이 여러 가격을 통과

가상의 매수 주문이 가격 100에서 수량 1, 가격 101에서 수량 2로 체결됐다고 생각해 보겠습니다. 수량 합계는 3이고 금액은 302입니다. 이 자료 집합의 수량 가중 평균은 302를 3으로 나눈 값입니다. 두 가격의 단순 평균 100.5와는 다릅니다.

다만 공개 거래 두 줄만 보고 실제로 같은 주문이었다고 식별할 수 있다는 뜻은 아닙니다. 이 예시는 평균 계산의 차이를 설명하기 위해 주문 관계를 가정한 것입니다. 관측된 공개 자료와 예시에서 추가한 가정을 혼동하지 않아야 합니다.

예시 3. m=true인 거래

q=2, m=true인 거래는 매수자가 maker인 거래로 읽습니다. taker 방향 통계에서는 매도 taker 수량 2로 분류합니다. 전체 거래량을 계산할 때 maker 매수 2와 taker 매도 2를 각각 더해 4로 만들면 같은 거래를 양쪽에서 중복 계산한 것입니다.

표시 이름을 "매수 여부"처럼 모호하게 붙이기보다 "매수자 maker 여부" 또는 분류 후 "taker 방향"이라고 구분하면 혼동을 줄일 수 있습니다. 원본 필드와 파생 필드를 따로 보관하는 것도 오류를 추적하는 데 도움이 됩니다.

예시 4. 재연결 과정에서 같은 거래 재수신

같은 시장·심볼의 t=900을 이미 저장했는데 복구 과정에서 다시 받았다고 가정합니다. 분석용 고유 체결 집합에는 한 번만 반영해야 합니다. 수신 로그에는 두 번 받은 흔적을 남길 수 있지만 그 행 수를 실제 체결 수로 보고해서는 안 됩니다.

이미 반영한 ID를 다시 처리해도 최종 합계가 변하지 않는지 확인하는 테스트가 유용합니다. 저장 성공과 합계 반영 성공의 경계도 살펴야 합니다. 저장은 됐는데 진행 위치를 기록하지 못한 경우 재시작 후 같은 자료를 다시 읽을 수 있습니다.

예시 5. 체결 시각과 도착 시각이 다른 경우

체결 시각 T가 10시 00분 59초이고 내 컴퓨터 도착 시각이 10시 01분 01초라고 가정합니다. 체결 시각으로 분 단위 통계를 만들면 앞선 분에 들어가지만 도착 시각을 쓰면 다음 분에 들어갑니다. 두 그래프는 목적이 다르므로 같은 지표라고 비교하면 안 됩니다.

늦게 도착한 자료를 이전 구간에 반영할지, 수정분을 따로 표시할지 정책을 정해야 합니다. 이미 확정한 보고서를 갱신한다면 수정 시각과 이유를 기록하는 것이 좋습니다. 지연된 자료를 조용히 현재 구간에 넣는 방식은 실제 체결 흐름을 왜곡할 수 있습니다.

6. 시간 단위와 시간대를 분리

현재 공식 일반 규칙에서 시간 필드는 기본 밀리초이며 연결 URL의 timeUnit 설정으로 마이크로초 정보를 요청할 수 있습니다. 선택한 설정과 원본 필드 단위를 확인해야 합니다. 숫자가 길다는 이유만으로 무조건 특정 단위라고 추측하지 않습니다.

한국시간 표시와 원본 타임스탬프 저장은 별개의 문제입니다. 화면에 한국시간을 보여주기 위해 원본 절대 시각에 임의로 9시간을 더해 다시 저장하면 다른 시스템과 어긋날 수 있습니다. 내부 시각을 유지하고 표시 단계에서 시간대를 적용하는 구조를 검토하세요.

T·E·로컬 수신 시각의 역할

T는 체결이 발생한 시각, E는 이벤트 시각, 로컬 수신 시각은 내 프로그램이 메시지를 받은 시각입니다. 이 세 값을 구분하면 구간 분석과 처리 지연을 따로 볼 수 있습니다. 모든 값을 timestamp 하나로 덮어쓰면 나중에 차이의 원인을 찾기 어렵습니다.

로컬 시계가 정확하지 않으면 수신 시각과 거래소 시각의 차이에 시계 오차가 포함됩니다. 그 차이를 순수 네트워크 지연이라고 단정해서는 안 됩니다. 시간 동기화 상태, 수신 처리 대기, 저장 지연을 구분하는 것이 진단에 도움이 됩니다.

구간의 포함 규칙

연속된 시간 구간을 만들 때 시작과 끝을 둘 다 포함하면 경계 거래를 두 번 셀 수 있습니다. 내부 분석에서는 시작 포함·끝 제외 같은 명확한 규칙을 선택할 수 있습니다. 이는 클라이언트의 분석 정의이며 API 조회 파라미터의 포함 규칙과 같다고 가정해서는 안 됩니다.

구간 길이를 바꿀 때도 원본 체결 시각 기준을 유지해야 합니다. 이미 반올림한 분 단위 자료에서 초 단위 흐름을 복원할 수는 없습니다. 필요한 시간 해상도와 보관 비용을 먼저 결정하는 편이 좋습니다.

7. 중복·누락·재연결을 관리하는 절차

스트림 연결은 영구 유지되는 저장 서비스가 아닙니다. 공식 문서는 단일 연결의 유효 기간과 ping·pong 규칙, 연결 제한을 안내합니다. 프로그램은 정상적인 재연결과 예상하지 못한 연결 중단을 모두 고려해야 합니다. 연결이 다시 열렸다는 사실만으로 중단 구간이 복구됐다고 볼 수 없습니다.

재연결 전 마지막으로 확실히 저장한 거래 위치와 시각을 기록합니다. 수신했지만 아직 저장하지 않은 자료와 저장이 끝난 자료를 구분해야 합니다. 단순히 마지막으로 화면에 보인 번호를 복구 기준으로 사용하면 저장되지 않은 구간을 건너뛸 수 있습니다.

복구할 자료의 종류를 먼저 선택

개별 Trade Stream과 Aggregate Trades의 ID는 같은 종류가 아닙니다. 개별 거래 t를 aggregate 조회의 fromId에 그대로 넣어 복구한다고 가정해서는 안 됩니다. REST에서 어떤 종류의 거래를 조회하는지와 그 식별자의 의미를 현재 공식 문서에서 확인해야 합니다.

복구 자료를 받았다면 요청 범위와 실제 반환 범위, 제한에 따른 잘림 가능성을 확인합니다. 최근 목록 한 번을 받았다는 이유만으로 긴 중단 구간 전체가 복구됐다고 기록하지 않습니다. 확인할 수 없는 구간은 자료 완성도에 표시해야 합니다.

처리 상태를 단계별로 남기기

연결 상태, 마지막 수신, 마지막 저장, 마지막 집계, 복구 진행 위치를 분리하면 문제가 발생한 단계를 찾기 쉽습니다. 메시지는 계속 들어오는데 저장 장치가 느리면 수신 상태만으로는 정상을 판단할 수 없습니다. 반대로 시장이 조용한데 메시지가 없다는 이유만으로 연결을 반복 재시작하면 불필요한 부하가 생깁니다.

오류 응답이나 파싱 실패를 빈 거래 목록으로 바꾸지 않습니다. 정상적으로 거래가 없는 상태와 읽지 못한 상태는 다릅니다. 이 구분이 사라지면 이후 분석에서 실제 무거래 구간처럼 처리할 위험이 있습니다.

8. 수량·금액·평균 계산 검증

선택한 고유 체결 집합의 수량은 q의 합, quote 기준 금액은 p×q의 합으로 계산할 수 있습니다. 수량 가중 평균을 구한다면 총 금액을 총 수량으로 나누는 정의를 사용할 수 있습니다. 이것은 해당 자료 집합에 대한 산술 계산이지 거래소의 다른 기준 가격이 모두 같은 식이라는 주장은 아닙니다.

총 수량이 0이면 평균을 계산하는 나눗셈을 실행하지 않아야 합니다. 빈 자료, 누락 자료, 실제 거래가 없는 구간을 모두 가격 0으로 치환하면 이후 변화율 계산이 잘못됩니다. 값이 없는 이유를 상태로 함께 보관하는 편이 낫습니다.

원본 정밀도와 표시 정밀도

각 거래 수량을 화면 자릿수로 먼저 반올림하고 합산하면 작은 오차가 누적될 수 있습니다. 계산에는 원본 정밀도를 유지하고 마지막 표시 단계에서 반올림하는 방식을 검토합니다. 다른 도구와 합계를 비교할 때도 반올림 시점이 같은지 확인해야 합니다.

가격·수량 문자열을 다루는 방식은 사용하는 언어와 저장소에 따라 달라집니다. 특정 숫자 형식 하나가 모든 상황에서 충분하다고 단정하지 않습니다. 아주 작은 소수, 큰 거래 ID, 합산 후 자릿수 확장을 포함한 가상 입력으로 검증하는 것이 좋습니다.

두 자료를 합산하지 않기

Trade Stream과 Aggregate Trade가 같은 체결 흐름을 서로 다른 단위로 표현한다면 둘의 거래량을 단순히 더할 수 없습니다. 자료 종류가 다르다는 이유로 서로 독립적인 거래량이 되는 것은 아닙니다. 비교하거나 검증할 수는 있어도 중복 범위를 이해하지 못한 채 합산하면 과대 계산이 됩니다.

거래 건수 비교도 주의해야 합니다. 개별 체결 행 수와 aggregate 행 수는 의미가 다릅니다. 보고서에 단순히 거래 수라고만 적기보다 개별 체결 수 또는 집계 레코드 수라고 정의를 명시하는 것이 정확합니다.

9. 자주 발생하는 문제와 확인 순서

문제가 생기면 먼저 원본 메시지 한 건과 변환 결과를 비교합니다. 그다음 고유 키, 시간 구간 배정, 방향 분류, 합계 반영 순서를 차례대로 확인합니다. 최종 그래프만 보고 원인을 추측하기보다 작은 입력으로 같은 오류를 재현하는 편이 효과적입니다.

정상 자료뿐 아니라 같은 ID 재수신, 필드 누락, 예상하지 못한 이벤트 종류, 늦은 도착, 연결 중단 후 재개를 시험해야 합니다. 오류를 발견했을 때 이미 잘못 집계한 구간을 어떻게 재계산할지도 정합니다. 처리 코드만 고치고 과거 통계를 그대로 두면 보고서의 비교 기준이 달라질 수 있습니다.

10. 작은 체결 장부를 직접 검산하는 순서

처음부터 복잡한 차트를 만들기보다 몇 건의 가상 체결로 장부를 만들어 보면 자료의 의미를 확인하기 쉽습니다. 아래 표는 실제 거래소 기록이 아니라 처리 순서를 점검하기 위한 학습 자료입니다. 같은 제품·환경·심볼이고 서로 다른 고유 거래라는 조건을 가정합니다.

전체 수량은 4이고 quote 금액은 401입니다. taker 매수 수량은 3, 매도 수량은 1이므로 두 방향 합계는 전체 수량 4와 같습니다. 이 자료 집합의 수량 가중 평균은 401÷4=100.25입니다. 가격 세 개의 단순 평균인 100과 다르다는 점을 확인할 수 있습니다.

첫 단계: 수신 기록과 고유 거래 집합

이제 ID 102 메시지를 한 번 더 받았다고 가정합니다. 원본 수신 장부는 네 줄이 될 수 있지만 고유 거래 집합은 여전히 세 건이어야 합니다. 전체 수량도 4, quote 금액도 401로 유지돼야 합니다. 여기서 수량이 6으로 바뀐다면 중복 제거가 합계 반영 전에 작동하지 않은 것입니다.

중복 메시지를 버렸다는 로그만으로는 충분하지 않을 수 있습니다. 저장은 중복을 막았지만 메모리 합계는 이미 증가했을 가능성이 있기 때문입니다. 저장소와 집계 결과를 함께 검산하고, 재시작 뒤 다시 계산한 값도 같은지 확인해야 합니다.

두 번째 단계: 시간 경계 추가

세 거래의 체결 시각이 각각 분 경계 직전, 경계 정각, 경계 직후라고 가정합니다. 시작 포함·끝 제외라는 내부 구간 규칙을 정했다면 정각 거래가 어느 구간에 들어가는지 명확해야 합니다. 같은 거래가 두 구간에 동시에 들어가거나 어느 구간에도 들어가지 않는지 확인합니다.

로컬 수신 순서를 뒤집어도 체결 시각 기준 최종 집계가 유지되는지 시험할 수 있습니다. 늦은 자료 반영을 허용하는 정책이라면 이전 구간이 수정될 수 있다는 사실을 기록해야 합니다. 반영을 허용하지 않는 정책이라면 누락 또는 제외 이유가 보고서에 남아야 합니다.

세 번째 단계: 잘못된 입력 구분

q가 숫자로 읽히지 않거나 m이 누락된 입력을 넣어 봅니다. 이런 자료를 정상 거래량 0으로 처리하면 실패가 드러나지 않습니다. 파싱 실패, 필수 필드 누락, 지원하지 않는 이벤트 종류를 별도 상태로 기록하고 정상 합계에서 어떻게 제외했는지 설명할 수 있어야 합니다.

단순히 프로그램이 멈추지 않았다는 이유로 검증을 통과했다고 보지 않습니다. 잘못된 자료가 정상 통계에 섞이지 않았는지가 핵심입니다. 원본을 제한적으로 보존하면 파서 수정 후 해당 구간을 다시 처리할 수 있습니다.

네 번째 단계: 계산 결과의 이름

검산한 100.25는 위 세 거래만의 수량 가중 평균입니다. 이 숫자를 시장 전체 평균이나 거래소 필터 기준 가격이라고 이름 붙이면 범위를 벗어납니다. 자료 집합·시간 범위·누락 여부를 이름 또는 설명에 포함해야 합니다.

마찬가지로 taker 매수 비중 75%는 이 가상 수량 집합의 분류 결과입니다. 매수 주문자의 수가 75%라는 뜻도 아니고 다음 가격이 상승할 확률도 아닙니다. 분자와 분모가 무엇인지 설명할 수 있을 때 지표를 표시하는 것이 좋습니다.

운영 기록에서 남길 항목

문제가 생긴 시점의 심볼, 연결 세대, 원본 이벤트 종류, 마지막 저장 ID, 체결 시각, 수신 시각, 처리 결과를 함께 남기면 원인을 좁힐 수 있습니다. 개인 계정 인증 정보나 비밀키는 공개 시장 자료의 진단에 필요하지 않으므로 로그에 넣지 않습니다.

장기간 보관할 자료는 목적에 맞게 정해야 합니다. 원본 전체를 무기한 저장하는 방식과 필요한 진단 구간만 보관하는 방식은 비용이 다릅니다. 무엇을 재현해야 하는지 먼저 정하고 자료 손실 없이 유지할 범위와 보존 기간을 선택하세요.

11. FAQ

Q1. Trade Stream은 주문을 넣는 기능인가요?

아닙니다. 공개 체결을 받는 시장 데이터 스트림입니다. 데이터를 구독했다고 계정에 주문이 생성되는 것은 아닙니다. 주문 실행 기능과 조회·수신 기능을 구분해야 합니다.

Q2. 메시지 한 개는 주문 한 개인가요?

개별 체결 정보이며 주문 전체와 같다고 단정할 수 없습니다. 한 주문이 여러 상대 주문과 나뉘어 체결될 수 있습니다. 공개 자료만으로 원래 주문의 모든 조건을 복원하지 않습니다.

Q3. t는 timestamp인가요?

Trade Stream에서 t는 거래 ID입니다. 체결 시각은 T, 이벤트 시각은 E로 구분합니다. 대소문자와 자료 종류를 함께 확인해야 하며 다른 스트림의 같은 이름을 그대로 적용하지 않습니다.

Q4. m=true는 매수 taker인가요?

매수자가 maker라는 뜻입니다. taker 관점에서는 매도 방향으로 읽습니다. 단순히 true를 매수로 표시하면 방향 통계가 뒤집힐 수 있습니다.

Q5. q는 거래 금액인가요?

체결 수량입니다. 가격 p와 곱한 값은 quote 자산 기준 금액으로 계산할 수 있습니다. 수량과 금액을 같은 축이나 같은 단위로 표시하지 않도록 주의하세요.

Q6. 같은 가격과 수량이면 중복인가요?

그렇지 않습니다. 서로 다른 거래가 같은 가격과 수량으로 발생할 수 있습니다. 시장·심볼·거래 ID 등 해당 자료의 식별 기준으로 중복을 확인해야 합니다.

Q7. Aggregate Trade의 a와 같은 ID인가요?

서로 다른 종류의 식별자입니다. t는 개별 거래 ID이고 a는 aggregate trade ID입니다. 다른 조회 경로의 커서에 무조건 서로 바꾸어 넣어서는 안 됩니다.

Q8. 내 주문 수수료를 알 수 있나요?

공개 Trade Stream은 내 계정의 수수료 내역을 대신하지 않습니다. 계정 체결 기록에서 수수료 자산과 금액을 확인해야 합니다. 비슷한 가격·수량만으로 내 거래를 특정하지 않습니다.

Q9. 마지막 체결 가격으로 지금 거래할 수 있나요?

같은 가격으로 체결된다는 보장은 없습니다. 현재 호가와 남은 수량, 이후 시장 변화가 영향을 줍니다. 체결 기록과 현재 주문 가능 조건을 구분하세요.

Q10. 실시간이면 지연이 전혀 없나요?

공식 갱신 방식이 실시간이라는 뜻이지 네트워크·클라이언트 처리 지연이 없다는 보장은 아닙니다. 체결·이벤트·수신 시각을 구분하고 로컬 시계 오차도 고려해야 합니다.

Q11. 한국시간으로 저장하려면 9시간을 더하나요?

원본 절대 시각을 임의로 바꾸기보다 표시 시간대를 별도로 적용하는 방식을 검토해야 합니다. 저장 기준과 화면 시간대가 섞이면 다른 자료와 비교할 때 어긋날 수 있습니다.

Q12. 재연결하면 빠진 거래가 자동 복구되나요?

그렇게 가정하지 않습니다. 연결 복구와 과거 자료 복구는 다른 작업입니다. 마지막 저장 위치와 실제 복구 범위를 확인하고 미확인 구간을 표시해야 합니다.

Q13. 거래량을 볼 때 매수와 매도를 각각 더하나요?

같은 거래의 양쪽을 모두 더하면 중복 계산이 될 수 있습니다. taker 방향으로 분류했다면 두 방향이 전체 고유 거래량을 나누는 구조인지 검증해야 합니다.

Q14. 매수 taker가 많으면 상승을 예측할 수 있나요?

그 사실만으로 미래 가격을 보장할 수 없습니다. 관측한 기간의 체결 분류와 미래 전망은 다른 질문입니다. 자료 누락과 정의, 시장 상황을 함께 고려해야 합니다.

Q15. 첫 구현에서 무엇부터 검증하나요?

대상 심볼·이벤트 종류·필드 의미·시간 단위를 먼저 확인합니다. 이후 같은 ID 재처리, 방향 합계, 수량과 금액 단위, 재연결 복구를 작은 가상 입력으로 검증하면 좋습니다.

12. 실무 체크리스트

• 현물 Trade Stream을 대상으로 하는지 확인했다.
• 개별 체결과 주문 전체를 구분한다.
• raw와 combined 메시지 구조를 구분한다.
• 심볼과 이벤트 종류를 확인한다.
• t와 T·E를 서로 다른 의미로 저장한다.
• 고유 키에 시장·환경·심볼을 구분한다.
• p·q의 원본 정밀도를 보존한다.
• m의 buyer maker 의미를 정확히 적용한다.
• 방향별 합계와 전체 합계를 대조한다.
• 시간 단위와 표시 시간대를 분리한다.
• 늦게 도착한 거래의 처리 규칙을 정했다.
• 재연결과 누락 복구를 별도 상태로 관리한다.
• 중복 입력이 합계를 바꾸지 않는지 확인했다.
• 관측 자료를 체결·가격·수익 보장으로 표현하지 않는다.

핵심 정리

바이낸스 Trade Stream은 가격이 움직이는 순간을 관찰하는 자료이지만 정확한 활용은 메시지의 의미를 유지하는 데서 시작합니다. 개별 체결과 집계 체결을 구분하고, 식별자·방향·시간·단위를 일관되게 처리한 뒤 통계를 해석하세요.

이 글은 시장 데이터 이해를 위한 정보성 자료입니다. 특정 거래의 체결이나 투자 성과를 보장하지 않습니다. 실제 운영 전 최신 Binance 공식 문서와 사용하는 시장·서비스 조건을 확인하세요.