바이낸스 Aggregate Trades 뜻 2026｜압축 체결·매수 매도 방향·ID·중복 집계

바이낸스 Aggregate Trades 뜻 2026｜압축 체결·매수 매도 방향·ID·중복 집계

바이낸스 Aggregate Trades는 일정한 조건으로 묶인 공개 체결 데이터입니다. 호가창에 남아 있는 주문 수량을 보여주는 자료가 아니라 실제로 발생한 거래를 읽는 자료입니다. 다만 한 줄이 반드시 하나의 원래 체결이나 한 사람의 전체 주문을 뜻하는 것은 아니므로 집계 기준과 필드를 구분해야 합니다.

가격과 수량만 보면 거래량을 쉽게 더할 수 있을 것 같지만, 같은 데이터를 두 번 받거나 maker 방향을 반대로 해석하면 통계가 달라집니다. REST 조회와 실시간 스트림을 연결할 때도 경계 중복과 시간 단위를 확인해야 합니다. 데이터가 많다는 것보다 무엇을 한 건으로 세는지가 먼저입니다.

이 글은 2026년 10월 28일 확인한 Binance Spot의 GET /api/v3/aggTrades와 Aggregate Trade Stream 설명을 기준으로 합니다. 선물의 집계 조건이나 다른 거래소의 체결 구조를 섞지 않습니다. 숫자 예시는 학습용이며 가격 방향이나 수익을 예측하는 신호가 아닙니다.

1. Aggregate Trades가 묶는 것

Spot REST 공식 문서는 같은 시점, 같은 taker 주문, 같은 가격으로 체결된 거래의 수량을 집계하는 압축 체결 자료로 설명합니다. WebSocket 공식 문서는 단일 taker 주문에 대해 집계된 거래 정보를 전송한다고 안내합니다.

여기서 핵심은 임의의 시간대 안에 발생한 모든 거래를 하나로 묶는 분봉 같은 자료가 아니라는 점입니다. 같은 가격이라고 무조건 한 줄로 합쳐지는 것도 아닙니다. 공식 집계 조건을 유지해야 데이터의 한 줄이 무엇을 의미하는지 이해할 수 있습니다.

하나의 taker 주문이 여러 줄로 보일 수 있음

한 주문이 여러 가격대에서 체결되면 가격이 서로 다르므로 같은 가격이라는 집계 조건을 고려해야 합니다. 따라서 aggregate 한 줄을 한 사용자의 전체 주문 크기라고 단정하지 않습니다. 공개 데이터에는 개인 주문의 전체 의도를 복원할 정보가 충분하지 않을 수 있습니다.

반대로 한 줄의 q에는 여러 원래 체결의 수량이 포함될 수 있습니다. 줄 수를 원래 체결 건수와 동일하게 세면 잘못된 통계가 됩니다. 집계 건수, 수량 합계, 가격×수량 금액은 서로 다른 지표입니다.

공개 거래와 내 체결의 차이

Aggregate Trades는 시장의 공개 거래 자료입니다. 내 계정의 수수료, 실제 주문 ID, 개별 주문의 누적 체결 상태를 모두 보여주는 자료가 아닙니다. 내 주문을 확인하려면 계정 주문·체결 내역과 사용자 데이터 스트림을 사용해야 합니다.

공개 체결의 가격과 수량이 내 주문과 비슷하다고 같은 거래라고 확정하는 것도 피해야 합니다. 같은 가격에 여러 거래가 있을 수 있습니다. 계정의 식별자와 실제 기록을 기준으로 확인해야 합니다.

2. 필드 a·p·q·f·l·T·m 읽기

REST 응답의 a는 aggregate trade ID입니다. p는 가격, q는 수량이며 f와 l은 해당 묶음의 첫 거래 ID와 마지막 거래 ID를 뜻합니다. T는 체결 시각을 나타냅니다. 비슷하게 보이는 숫자라도 목적이 다르므로 하나의 id나 time으로 합치지 않습니다.

문자열로 표현된 가격과 수량은 정확한 소수 처리에 유의해야 합니다. 단순히 화면에 반올림한 값으로 다시 계산하면 원래 자료와 합계가 달라질 수 있습니다. 원본 문자열과 계산용 표현을 구분하고 정밀도를 유지하는 방식을 선택해야 합니다.

aggregate ID와 원래 trade ID

a와 f· l은 서로 다른 식별자를 설명합니다. a를 원래 개별 trade ID라고 생각해 다른 경로와 직접 연결하면 잘못된 매칭이 될 수 있습니다. 데이터베이스에서도 필드 이름을 의미가 드러나게 유지하는 편이 좋습니다.

여러 심볼을 함께 저장할 때는 ID만 단독 키로 삼지 않는 것이 중요합니다. 심볼과 제품·환경을 함께 구분해야 합니다. 서로 다른 시장의 같은 숫자가 같은 거래를 의미한다고 가정하지 않습니다.

T와 E의 차이

스트림에는 이벤트 시각 E와 체결 시각 T가 구분되어 있습니다. 실제 거래가 발생한 시각으로 구간을 집계할지, 메시지를 받은 시각으로 운영 지연을 관찰할지 목적을 나누어야 합니다. 로컬 수신 시각은 또 다른 값입니다.

세 시각을 혼합하면 네트워크가 느린 순간에 거래량이 뒤쪽 시간 구간으로 몰려 보일 수 있습니다. 구간 분석에는 어떤 시각을 사용했는지 명시하고, 운영 모니터링에는 수신 지연을 별도로 기록하는 편이 좋습니다.

3. m 필드로 방향을 읽는 방법

공식 설명에서 m은 “매수자가 maker인가”를 뜻합니다. true라면 매수자가 maker인 거래이고, 이때 상대편인 매도자가 taker인 관계로 읽을 수 있습니다. false라면 매수자가 maker가 아니므로 매수 측이 taker인 관계로 해석할 수 있습니다.

이것을 m=true이면 적극적 매수라는 뜻으로 뒤집으면 방향 집계가 반대로 됩니다. 필드 이름이 짧으므로 표시용 이름을 붙일 때 원래 질문을 기억해야 합니다. buyerIsMaker 같은 의미를 유지하면 혼동을 줄이는 데 도움이 됩니다.

모든 체결에는 매수자와 매도자가 있음

매수 체결량이라는 표현은 거래에 매수자만 존재한다는 뜻이 아닙니다. 보통 어느 쪽이 유동성을 가져간 taker인지 구분하는 분석상의 표현입니다. 같은 거래에 매수·매도 양쪽이 존재한다는 사실과 공격적 방향 분류를 구분해야 합니다.

따라서 방향별 수량을 더할 때 어떤 정의를 사용했는지 명시합니다. taker buy와 taker sell로 나누었다면 전체 수량과 어떻게 연결되는지 검증할 수 있습니다. 거래 양쪽을 각각 더해 총량을 두 배로 세지 않도록 주의하세요.

방향은 미래 가격 예측이 아님

taker 매수 수량이 많다고 다음 가격이 반드시 오르는 것은 아닙니다. 관측 기간, 상대 유동성, 다른 시장의 움직임, 이후 주문 변화 등 다양한 조건이 있습니다. 이 글은 필드를 정확히 읽는 방법을 설명하며 매매 신호를 보장하지 않습니다.

큰 집계 체결 하나를 특정 투자자의 강한 의지로 단정하는 것도 피해야 합니다. 공개 자료는 실제 발생한 체결의 일부 구조를 보여줄 뿐 주문자의 전체 전략과 이유를 알려주지 않습니다. 관측과 해석을 나누어 표현해야 합니다.

4. REST 조회의 기본

GET /api/v3/aggTrades는 symbol을 지정해 압축 체결 목록을 조회하는 경로입니다. 현재 공식 문서는 요청 가중치 4, limit 기본값 500과 최대 1,000을 안내합니다. 실제 운영 전 최신 문서를 확인해야 하며 이 숫자를 모든 제품에 적용하지 않습니다.

fromId는 해당 aggregate ID부터 포함하여 조회하는 조건입니다. startTime과 endTime도 문서에서 포함 경계로 설명됩니다. 페이지를 이어 붙이거나 시간 구간을 나누는 경우 경계값이 다시 들어올 수 있다는 점을 고려해야 합니다.

조건을 주지 않았을 때

fromId, startTime, endTime을 보내지 않으면 최근 aggregate trades가 반환된다고 안내됩니다. 최근 자료를 받았다는 사실만으로 이전에 놓친 전체 기간을 복구했다고 볼 수는 없습니다. 복구 대상의 시작과 끝을 명확히 해야 합니다.

프로그램이 재시작될 때마다 최근 목록만 가져오면 중단 시간이 길었던 경우 누락이 남을 수 있습니다. 저장된 마지막 확인 위치와 현재 요청 범위를 연결하는 설계가 필요합니다. 단순히 응답이 비어 있지 않다는 이유로 복구 완료를 기록하지 않습니다.

fromId의 포함 경계

마지막으로 저장한 a를 그대로 fromId에 넣으면 그 경계 자료가 다시 반환될 수 있습니다. 포함 경계라는 의미를 이해하고 중복을 처리해야 합니다. 무조건 마지막 항목을 버리는 방식보다 식별자를 기준으로 이미 저장한 자료인지 확인하는 편이 명확합니다.

다음 요청의 시작값을 계산할 때도 현재 문서의 경계 의미를 따라야 합니다. ID가 시간이라고 생각해 시간 단위처럼 더하거나 변환하지 않습니다. 사용한 커서와 응답 범위를 기록하면 재시작 이후의 복구를 추적하기 쉽습니다.

5. 실시간 스트림의 기본

Aggregate Trade Stream의 이름은 현물 문서에서 {symbol}@aggTrade로 안내됩니다. 스트림 심볼 표기와 연결 규칙은 공식 문서를 따라야 합니다. raw stream과 combined stream은 메시지 포장 구조가 다를 수 있으므로 파서가 어느 형태를 처리하는지 확인해야 합니다.

스트림은 새 거래를 빠르게 받는 데 유용하지만 연결이 영구 유지된다고 가정하지 않습니다. 재연결과 누락 구간 확인이 필요할 수 있습니다. 연결이 열렸다는 사실만으로 끊긴 동안의 자료가 자동 복구되었다고 볼 수는 없습니다.

raw와 combined 포장

combined 방식은 stream 이름과 data 객체로 원래 payload를 감싸는 구조가 설명되어 있습니다. raw payload의 필드를 최상위에서 찾는 파서와 combined의 data 안에서 찾는 파서를 혼동하면 정상 메시지를 빈 자료로 처리할 수 있습니다.

가능하다면 수신 형식을 명확히 정하고 내부 표준 구조로 변환하는 단계를 둡니다. 변환 후에도 원래 심볼·ID·시각 의미를 유지해야 합니다. 포장을 벗기는 작업에서 필드를 재명명하더라도 의미가 바뀌지 않게 기록합니다.

기본 시간 단위 확인

현재 스트림 문서는 시간 필드가 기본 밀리초이고 선택적으로 마이크로초를 요청할 수 있다고 안내합니다. REST 요청의 시간 파라미터와 스트림 설정을 함께 사용할 때 단위가 일치하는지 확인해야 합니다. 자릿수가 길다는 이유만으로 임의 변환하지 않습니다.

내부 저장에는 원본 단위 또는 명확한 표준 단위를 정할 수 있습니다. 이때 변환은 한 곳에서 수행하고 중복 적용하지 않도록 합니다. 시간 단위 오류는 방향 계산보다 눈에 덜 띄지만 구간 집계 전체를 잘못 만들 수 있습니다.

6. 다섯 가지 집계 사례

예시 1. 같은 가격의 여러 체결 묶음

같은 taker 주문이 공식 집계 조건에 맞는 상황에서 가격 100에 수량 0.2와 0.3으로 체결됐다고 가정합니다. 묶인 자료의 q는 0.5가 될 수 있습니다. 이때 한 줄이라는 이유로 원래 체결이 하나였다고 단정하면 안 됩니다.

수량 집계와 건수 집계는 구분합니다. q를 더하면 집계된 수량을 구할 수 있지만 행 수를 세면 aggregate 레코드 수를 구하는 것입니다. 어떤 지표를 만들고 있는지 먼저 정의해야 결과 이름도 정확하게 붙일 수 있습니다.

예시 2. 여러 가격대에서 체결

하나의 taker 주문이 가격 100과 101에서 실행되는 가상 상황을 생각해 볼 수 있습니다. 가격이 다르면 같은 가격이라는 집계 조건을 고려해야 하므로 한 aggregate 줄에 주문 전체가 모두 들어 있다고 가정할 수 없습니다.

공개 자료에서 q가 작은 줄 몇 개 보인다고 주문 의사도 작았다고 결론 내리지 않습니다. 반대로 큰 줄 하나가 보인다고 개인 한 명의 전체 전략 규모를 안다고 할 수도 없습니다. 관측 자료의 단위와 주문자의 전체 의도를 분리하세요.

예시 3. m=true의 방향

어떤 레코드에서 q가 2이고 m=true라고 가정합니다. 공식 필드 의미에 따르면 매수자가 maker입니다. taker 방향으로 분류하는 통계라면 매도 taker 쪽 수량으로 읽는 관계가 됩니다. m을 매수 여부로 바로 사용하는 코드는 반대 결과를 만들 수 있습니다.

표시할 때는 “매수자 maker”와 “매도 taker”가 같은 거래의 서로 다른 표현임을 이해해야 합니다. 전체 거래량을 계산하면서 양쪽 표현을 각각 더하면 같은 수량을 두 번 세게 됩니다. 분류 기준과 합계 기준을 일관되게 유지합니다.

예시 4. REST와 스트림에서 같은 ID 수신

스트림으로 a=500을 저장한 뒤 복구용 REST 조회에서도 같은 a=500이 반환됐다고 가정합니다. 두 경로에서 받았다는 이유로 서로 다른 거래가 되는 것은 아닙니다. 같은 제품·환경·심볼의 같은 집계 ID인지 확인해 중복 반영을 막아야 합니다.

중복을 제거하는 단계는 수량 합계에 더하기 전에 적용하는 편이 명확합니다. 원본 수신 기록은 두 경로로 남길 수 있지만 분석용 고유 거래 집합에서는 한 번만 반영해야 합니다. 수신 횟수와 거래 횟수는 다른 지표입니다.

예시 5. 수신 지연과 시간 구간

체결 시각 T는 10시 00분 59초인데 로컬 수신은 10시 01분 01초였다고 가정합니다. 체결 시각 기준의 분 단위 집계라면 앞선 분에 속하지만 수신 시각 기준으로 넣으면 다음 분으로 이동합니다. 어떤 시각을 사용하는지에 따라 그래프 모양이 달라질 수 있습니다.

지연된 이벤트를 이미 닫은 구간에 반영할지, 수정 기록을 남길지 정책을 정해야 합니다. 이 정책은 분석 시스템의 선택이며 거래소가 모든 사용자에게 특정 집계 방식을 강제한다는 뜻은 아닙니다. 결과를 비교할 때도 시간 기준이 같은지 확인해야 합니다.

7. 수량과 거래 금액 계산

q는 집계된 수량이고 p×q는 해당 가격과 수량에 대한 quote 자산 기준 금액으로 이해할 수 있습니다. 수량 합계와 금액 합계는 단위가 다르므로 같은 차트 축에 무심코 섞지 않습니다. 다른 심볼을 비교할 때는 단위 차이가 더 중요해집니다.

여러 가격의 평균을 구하고 싶다면 목적에 맞는 가중 방식을 정의해야 합니다. 각 줄의 가격을 단순히 더해 행 수로 나눈 값과 거래량 가중 평균은 다릅니다. 수량 가중 평균을 계산하는 경우에는 해당 집계 구간의 Σ(p×q)를 Σq로 나누는 산술적 정의를 사용할 수 있습니다.

계산식의 적용 범위

이 계산은 사용자가 선택한 자료 집합의 수량 가중 평균을 뜻합니다. 거래소의 모든 필터 기준 가격이나 별도 reference price가 같은 방식으로 구성된다고 주장하는 것이 아닙니다. 계산 대상의 범위와 누락 여부가 결과에 직접 영향을 줍니다.

Σq가 0인 경우에는 나눗셈을 수행하지 않아야 합니다. 빈 구간, 데이터 누락, 실제 거래가 없는 구간을 구분해야 합니다. 0 가격을 임의로 넣으면 이후 평균과 변화율에 잘못된 값이 전파될 수 있습니다.

합계 검증

같은 자료를 전체 수량과 방향별 수량으로 나눴다면 두 방향 합계가 전체와 맞는지 확인할 수 있습니다. 차이가 있다면 중복 제거 위치, m 해석, 누락 필드 처리, 시간 구간 경계를 점검합니다. 이런 대조는 특정 매매 전략의 수익성을 검증하는 것이 아니라 데이터 처리의 일관성을 확인하는 과정입니다.

수량을 표시용으로 먼저 반올림한 뒤 합산하면 오차가 누적될 수 있습니다. 원래 정밀도로 합산하고 마지막 표시 단계에서 반올림하는 방식을 검토할 수 있습니다. 계산 규칙을 바꾸었다면 과거 통계와 비교할 때 변경점을 명시해야 합니다.

8. REST와 스트림 연결 설계

실시간 수신과 과거 복구가 겹치는 구간은 자연스럽게 생길 수 있습니다. 겹침 자체를 오류로 보기보다 중복을 식별할 수 있게 설계하는 것이 중요합니다. 반대로 겹침을 피하려고 경계를 너무 멀리 건너뛰면 누락을 만들 수 있습니다.

저장된 마지막 ID와 체결 시각, 복구 요청 범위, 반환된 첫·마지막 ID를 함께 기록하면 흐름을 추적하기 쉽습니다. 단순히 마지막 요청 성공 시각만 남기면 실제 어느 거래까지 저장했는지 알 수 없습니다. 진행 상태와 데이터 상태를 구분해야 합니다.

포함 경계와 중복 제거

fromId와 시간 조건의 포함 의미를 고려해 경계 레코드를 처리합니다. 같은 데이터를 다시 받아도 결과 합계가 변하지 않도록 고유 키와 저장 규칙을 정할 수 있습니다. 이를 위해 자료의 제품·환경·심볼·aggregate ID를 함께 구분하는 것이 도움이 됩니다.

중복 레코드에서 값이 다르게 보이면 조용히 덮어쓰기보다 원인을 확인하는 정책을 마련할 수 있습니다. 단위 변환이나 파싱 오류, 다른 환경 자료의 혼합 가능성을 점검합니다. “같은 ID니까 아무 값이나 써도 된다”는 식으로 처리하지 않습니다.

복구 완료 기준

응답을 한 번 받았다는 사실만으로 모든 누락 구간이 채워졌다고 기록하지 않습니다. 요청한 범위와 실제 반환 범위, limit에 따른 잘림 가능성, 다음 조회 위치를 확인해야 합니다. 데이터가 많은 구간에서는 여러 페이지를 이어야 할 수 있습니다.

빈 응답도 신중하게 해석합니다. 실제 거래가 없는 구간인지, 요청 조건이 맞지 않는지, 복구 위치가 잘못됐는지 구분해야 합니다. 오류 응답을 빈 목록으로 바꾸면 누락을 정상 상태처럼 감출 수 있으므로 상태를 따로 보존합니다.

9. 시간 기반 분석의 주의점

분·초 단위의 구간을 만들 때 시작과 끝의 포함 규칙을 명확히 해야 합니다. 인접 구간이 같은 경계 시각을 모두 포함하면 중복 집계가 생길 수 있습니다. 내부 집계 규칙과 API 조회 경계 규칙이 서로 다를 수 있으므로 변환 과정을 정의해야 합니다.

시간대 표시도 절대 시각과 구분합니다. 한국시간으로 그래프를 보여준다고 원래 타임스탬프에 임의로 9시간을 더해 저장하면 다른 시스템과 맞지 않을 수 있습니다. 저장 기준과 표시 시간대를 나누어 관리하는 것이 좋습니다.

늦게 도착한 자료

이벤트가 늦게 도착했을 때 이전 구간을 수정할 수 있도록 허용할지 정해야 합니다. 수정 가능한 분석이라면 갱신 시각이나 자료 완성도를 함께 표시할 수 있습니다. 실시간 화면의 숫자와 나중에 복구한 확정 집계가 다를 수 있는 이유를 설명할 수 있어야 합니다.

반대로 이미 확정된 보고서를 바꾸지 않는 시스템이라면 누락과 수정분을 별도로 기록하는 정책이 필요합니다. 어떤 방식을 선택하든 조용히 숫자를 바꾸거나 누락을 숨기지 않는 것이 중요합니다. 이 선택은 분석 목적과 사용자 요구에 따라 달라집니다.

시각 차이를 지연으로 단정하지 않기

거래소 시각과 로컬 수신 시각의 차이에는 시계 오차가 포함될 수 있습니다. 시간 동기화 상태를 확인하지 않고 그 차이를 정확한 네트워크 지연이라고 주장하지 않습니다. 이벤트 시각 E와 체결 시각 T의 차이도 목적을 구분해 읽어야 합니다.

운영 로그에는 시간 단위와 출처를 명시합니다. 숫자 하나만 저장하면 밀리초인지 마이크로초인지, 체결 시각인지 수신 시각인지 나중에 알기 어렵습니다. 필드 이름을 명확히 하는 것이 복잡한 추측보다 효과적입니다.

10. 거래 방향 지표의 해석 한계

taker 방향별 수량은 공개 체결을 한 관점으로 분류한 통계입니다. 시장 참여자의 전체 매수·매도 의사나 미체결 주문까지 모두 포함하지 않습니다. 특정 기간의 방향 불균형을 미래 가격 방향으로 바로 연결하는 것은 추가 가정입니다.

거래량이 큰 레코드가 나왔다고 특정 개인이나 기관을 식별할 수 있는 것도 아닙니다. 공개 자료의 식별자는 거래 데이터의 구분을 위한 것이며 개인의 신원을 알려주는 자료가 아닙니다. 확인되지 않은 주체나 동기를 덧붙이지 않습니다.

작은 구간의 변동

아주 짧은 구간에서는 이벤트 몇 개만으로 비율이 크게 바뀔 수 있습니다. 숫자가 크게 움직인다는 이유로 강한 신호라고 단정하지 않습니다. 구간 길이, 표본 수량, 누락 여부, 시장 상황을 함께 살펴야 합니다.

서로 다른 도구의 방향 지표가 다르면 먼저 정의를 비교합니다. m 해석, 체결 시각과 수신 시각, 중복 제거, 집계 단위가 다를 수 있습니다. 차이가 있다는 사실만으로 어느 서비스가 조작됐다고 결론 내리는 것은 근거가 부족합니다.

호가 자료와의 결합

체결과 호가를 함께 보면 실행 환경을 더 풍부하게 관찰할 수 있지만 두 자료의 순서·시각·집계 방식이 같다고 가정하지 않습니다. 호가 수량 감소와 aggregate 체결을 숫자만으로 일대일 대응시키는 것은 부정확할 수 있습니다.

분석에서는 확인 가능한 연결과 추정 연결을 구분합니다. 공개 호가가 줄었다는 관측과 실제 체결이 있었다는 관측을 각각 보존하고, 그 사이의 원인을 확정할 수 있는지 따로 판단하세요. 자료가 여러 개라는 이유만으로 모든 시장 행동을 복원할 수 있는 것은 아닙니다.

11. 오류 진단과 검증

거래량이 예상보다 두 배라면 REST·스트림 중복 반영이나 양쪽 방향의 이중 합산을 확인할 수 있습니다. 방향이 반대로 보인다면 m을 매수 여부로 잘못 읽었는지 점검합니다. 시간 그래프가 어긋나면 단위와 시간대, T·E·수신 시각 선택을 확인합니다.

이런 진단은 실제 원인을 확인하는 출발점이지 자동 확정 규칙은 아닙니다. 원본 자료 일부와 처리 단계별 결과를 대조해야 합니다. 원본을 보존하지 않고 최종 합계만 저장하면 어떤 단계에서 차이가 생겼는지 추적하기 어렵습니다.

가상 입력으로 확인할 사례

같은 ID를 두 번 넣어도 분석용 합계가 한 번만 증가하는지 확인합니다. m=true와 false를 각각 넣고 방향별 합계가 전체 수량과 맞는지 검토합니다. 가격이 다른 두 레코드를 넣어 단순 평균과 가중 평균을 구분하는지도 확인할 수 있습니다.

시간 경계 직전과 직후, 늦게 도착한 이벤트, 빈 응답, 오류 응답을 따로 처리해 봅니다. 정상 자료만으로 테스트하면 복구와 중복 문제를 놓치기 쉽습니다. 검증의 목적은 특정 전략 성과가 아니라 자료 처리의 일관성을 확보하는 것입니다.

저장과 보고의 구분

원본 수신 로그에는 같은 자료가 여러 경로로 들어온 흔적을 남길 수 있습니다. 하지만 최종 분석용 데이터에는 고유 거래 단위를 정의해야 합니다. 원본 로그의 행 수와 고유 체결 집계 수를 같은 이름으로 보고하지 않습니다.

보고서에는 제품·심볼·기간·시간 기준·단위·자료 완성도를 적으면 비교가 쉬워집니다. 수량인지 quote 금액인지도 명확히 표시합니다. 숫자만 크게 제시하는 것보다 무엇을 계산한 값인지 드러내는 것이 유용합니다.

12. FAQ

Q1. 바이낸스 Aggregate Trades는 호가 주문인가요?

아닙니다. 실제 발생한 거래를 공식 조건에 따라 집계한 체결 자료입니다. 호가창에 남은 수량은 depth 자료에서 확인합니다. 남아 있는 주문과 실행된 거래를 구분해야 합니다.

Q2. 한 줄은 한 사람의 주문 전체인가요?

그렇게 단정할 수 없습니다. 집계 조건에는 같은 가격 등의 조건이 포함되며 한 주문이 여러 가격대에서 체결될 수 있습니다. 공개 자료만으로 주문자의 전체 의도나 전략을 복원할 수 있다고 보지 않습니다.

Q3. 같은 가격이면 모두 합쳐지나요?

공식 REST 설명에는 같은 시점·같은 taker 주문·같은 가격이라는 집계 조건이 있습니다. 가격 하나만 같다고 모든 거래가 한 줄이 되는 구조로 해석하지 않습니다. 시간 캔들 집계와도 다릅니다.

Q4. a와 f· l은 같은 ID인가요?

a는 aggregate trade ID이고 f· l은 첫·마지막 원래 trade ID를 뜻합니다. 서로 다른 식별자를 하나로 합치지 않습니다. 다른 경로와 연결할 때도 해당 ID가 무엇을 가리키는지 확인해야 합니다.

Q5. m=true면 매수 taker인가요?

공식 의미는 매수자가 maker라는 뜻입니다. taker 방향으로 분류하면 반대편인 매도 taker 관계로 읽습니다. true를 단순 매수 신호로 처리하면 방향 통계가 뒤집힐 수 있습니다.

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

집계 수량입니다. 가격 p와 수량 q를 곱하면 해당 자료의 quote 자산 기준 금액을 계산할 수 있습니다. 수량과 금액은 단위가 다르므로 차트와 보고서에서 구분해야 합니다.

Q7. fromId는 그 ID를 제외하나요?

현재 공식 문서는 포함 경계로 설명합니다. 이어서 조회할 때 같은 경계 레코드가 다시 들어올 수 있으므로 ID 기반 중복 처리가 필요합니다. 경계 의미를 임의로 바꾸지 마세요.

Q8. 최신 목록 한 번이면 연결 중단 구간이 복구되나요?

그렇게 보장할 수 없습니다. 중단 기간과 거래량, limit에 따라 일부만 반환될 수 있습니다. 저장된 마지막 위치와 실제 반환 범위를 확인하고 필요한 복구 절차를 이어야 합니다.

Q9. REST와 스트림의 같은 ID는 두 번 더하나요?

같은 제품·환경·심볼의 같은 집계 거래라면 분석용 합계에 중복 반영하지 않아야 합니다. 수신 경로는 둘이어도 거래가 둘이 되는 것은 아닙니다. 원본 로그와 고유 거래 집합을 분리할 수 있습니다.

Q10. T와 E 중 어떤 시간을 쓰나요?

체결 구간 분석에는 체결 시각 T의 의미가 중요하고 운영 지연 관찰에는 이벤트·수신 시각도 유용합니다. 목적에 맞는 기준을 정하고 혼합하지 않아야 합니다. 보고서에도 어떤 시각을 썼는지 명시하세요.

Q11. 기본 시간 단위는 무엇인가요?

현재 스트림 문서는 기본 밀리초와 선택적 마이크로초 설정을 안내합니다. 실제 연결 설정과 REST 파라미터 규격을 확인해야 합니다. 숫자 자릿수만 보고 추측하거나 중복 변환하지 않습니다.

Q12. 매수 taker 비중이 크면 상승하나요?

그 결과를 보장할 수 없습니다. 해당 기간의 체결 분류와 미래 가격은 다른 질문입니다. 자료 범위·누락·시장 상황과 분석 가정을 함께 고려해야 하며 이 글은 매매 신호를 제공하지 않습니다.

Q13. 내 주문 수수료도 알 수 있나요?

공개 Aggregate Trades는 내 계정의 수수료 내역을 대신하지 않습니다. 실제 계정 체결 기록에서 수수료 금액과 자산을 확인해야 합니다. 비슷한 가격·수량만으로 내 거래라고 식별하지 않습니다.

Q14. 호가 감소와 체결량은 정확히 같나요?

호가에는 취소·수정 등 다른 변화가 있을 수 있고 자료의 시각·집계도 다릅니다. 숫자만으로 일대일 대응시키지 않습니다. 확인된 체결과 호가 변화를 각각 기록하고 해석의 한계를 유지해야 합니다.

Q15. 다음 분석에서는 무엇을 먼저 정해야 하나요?

어떤 심볼·기간에서 수량, 금액, taker 방향 중 무엇을 계산할지 정하는 것이 먼저입니다. 이후 시간 기준과 중복 제거, 복구 완료 기준을 정합니다. 지표 이름보다 원본 자료의 의미와 일관성이 우선입니다.

13. 운영 체크리스트

• Spot과 다른 제품의 집계 규칙을 구분했다.
• 집계 조건을 단순한 같은 가격으로 축소하지 않는다.
• a와 f· l을 별도 식별자로 보존한다.
• 고유 키에 심볼·환경·제품을 구분한다.
• q와 p×q의 단위를 구분한다.
• m의 buyer maker 의미를 정확히 읽는다.
• 방향별 합계와 전체 합계를 대조한다.
• fromId와 시간 조건의 포함 경계를 이해했다.
• REST·스트림 중복을 합산 전에 처리한다.
• 체결 시각·이벤트 시각·수신 시각을 구분한다.
• 시간 단위와 표시 시간대를 명시한다.
• 재연결 후 실제 누락 구간을 확인한다.
• 빈 응답과 오류 응답을 다르게 기록한다.
• 방향 통계를 미래 가격 보장으로 표현하지 않는다.

핵심 정리

바이낸스 Aggregate Trades를 올바르게 읽으려면 가격과 수량뿐 아니라 집계 기준, 식별자, 방향, 시간 경계를 함께 봐야 합니다. 원본 의미를 보존하고 중복과 누락을 관리한 뒤에야 체결 흐름을 일관되게 비교할 수 있습니다.

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