체결 건수는 일정 시간에 공개된 체결 레코드의 수일 뿐, 그 자체로 주문 수·참여자 수·거래 관심을 뜻하지는 않습니다. 한 주문이 여러 상대 주문과 만나면 개별 체결은 늘고, 반대로 거래소가 같은 taker 주문·시각·가격의 개별 체결을 묶어 제공하면 줄어듭니다. 비교하려면 먼저 원시 체결인지 집계 체결인지, 시장·기간·페이지 경계가 같은지 정한 뒤 거래량과 체결 크기 분포를 함께 봐야 합니다.
체결 건수는 무엇을 세는 숫자인가
체결 건수는 보통 API나 데이터 파일에서 받은 거래 레코드의 개수를 말합니다. 그러나 레코드는 거래소가 정한 공개 단위입니다. 체결 한 행은 주문 한 건이나 투자자 한 명과 같은 단위가 아닙니다. 하나의 지정가 주문이 호가창의 세 주문과 차례로 맞으면 세 개의 개별 거래가 남을 수 있고, 한 시장가 주문이 한 상대 주문과 전량 맞으면 한 개만 남을 수 있습니다. 두 경우 주문을 낸 사람 수나 거래한 명목가치가 같아도 행 수는 달라집니다.
그래서 ‘오늘 체결이 10만 건’이라는 문장에는 적어도 거래쌍, 현물 또는 파생상품 여부, 시작·끝 시각, 원시 또는 집계 레코드 여부가 따라야 합니다. 이 정보가 없으면 10만은 활동량의 크기라기보다 데이터 공급 방식의 흔적일 수 있습니다. 같은 BTC-USDT라는 표기라도 여러 법인·상품·거래소의 시장을 하나로 합쳤는지에 따라 관측 대상이 달라집니다.
체결 건수는 시장의 소리를 기록하지만, 마이크가 한 번에 몇 소리를 묶는지까지 알려 주지는 않는다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 체결 건수는 무엇을 세는 숫자인가
체결 건수는 보통 API나 데이터 파일에서 받은 거래 레코드의 개수를 말합니다.
- 주문 하나가 여러 체결로 나뉘는 정상적인 상황
호가창에는 가격과 수량이 다른 여러 대기 주문이 놓입니다.
- 집계 체결의 관측 단위를 먼저 확인한다
Binance Spot API 용어집은 aggTrade를 같은 taker 주문이 같은 시각과 가격에서 채워진 하나 이상의 개별 체결을 모은 값으로 정의합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
주문 하나가 여러 체결로 나뉘는 정상적인 상황
호가창에는 가격과 수량이 다른 여러 대기 주문이 놓입니다. 매수자가 10개를 즉시 사려 할 때 최우선 매도 호가가 2개, 다음 호가가 3개, 그다음 호가가 5개라면 매수 주문은 세 상대 주문과 맞을 수 있습니다. 개별 체결 자료에서는 가격·수량이 다른 세 레코드가 생깁니다. 이 분할은 오류나 조작을 뜻하지 않고, 유동성이 여러 호가에 배치된 결과일 수 있습니다.
반대로 같은 총수량 10개가 한 가격의 한 대기 주문과 맞았다면 개별 체결은 하나입니다. 따라서 건수가 많은 시장이 언제나 더 많은 자금이나 더 많은 독립 참여자를 가졌다고 말할 수 없습니다. 평균 체결 수량은 총 거래량을 체결 건수로 나눠 구합니다. 위의 세 체결 예에서는 10÷3≈3.33개이고, 한 체결 예에서는 10÷1=10개입니다. 이 값 역시 주문 라우팅·최소 주문 단위·호가 단위·데이터 집계에 영향을 받습니다.
| 상황 | 개별 체결 수량 | 총수량과 기록 행 수 |
|---|---|---|
| 한 상대 주문과 전량 매칭 | 10 | 총 10, 1행 |
| 세 호가를 순서대로 소진 | 2 + 3 + 5 | 총 10, 3행 |
| 동일 taker 주문의 같은 가격·시각 체결을 집계 | 원시 행 여러 개를 합산 | 총수량은 유지될 수 있으나 집계 행 수는 감소 |
집계 체결의 관측 단위를 먼저 확인한다
Binance Spot API 용어집은 aggTrade를 같은 taker 주문이 같은 시각과 가격에서 채워진 하나 이상의 개별 체결을 모은 값으로 정의합니다. 즉 aggTrade 이벤트 하나는 개별 체결 하나일 수도, 여러 개일 수도 있습니다. 집계 체결은 원시 체결과 다른 관측 단위입니다. 원시 거래 수를 세려는 분석에서 aggTrade 개수를 그대로 사용하면 거래소가 공개한 집계 규칙까지 함께 세게 됩니다.
이 정의는 해당 Spot API의 문서 범위입니다. 다른 거래소의 ‘trade’, ‘fill’, ‘match’, ‘aggregate’가 같은 규칙이라고 가정하면 안 됩니다. API 명칭이 비슷해도 같은 주문 ID를 기준으로 묶는지, 가격과 시간까지 같아야 하는지, 정정 데이터를 어떻게 반영하는지 확인해야 합니다. 페이지네이션의 경계 규칙도 행 수를 바꾸므로, 집계 정의와 수집 방식은 함께 기록하는 편이 안전합니다.
거래소를 넘겨 건수를 합칠 때 생기는 두 번째 편향
A 거래소의 원시 체결 1만 행과 B 거래소의 집계 체결 1만 행은 같은 단위가 아닙니다. A는 한 taker 주문이 다섯 상대 주문과 맞을 때 다섯 행을 내보내고, B는 이를 한 행으로 줄일 수 있습니다. 이때 두 시장의 행 수가 같다는 사실만으로 주문 흐름이 같다고 결론낼 근거는 없습니다. 각 venue에서 총 base 수량과 quote 거래대금이 얼마나 되는지도 별도로 대조해야 합니다.
비교 대상의 범위도 맞춰야 합니다. 현물 BTC-USDT와 무기한 선물 BTC-USDT는 이름이 비슷하지만 계약 단위, 거래 규칙, 데이터 피드가 다를 수 있습니다. 한 거래소의 여러 quote 시장을 모두 더하면 동일한 기초자산의 경제적 관심을 여러 통화 시장에서 중복 관측하게 될 수도 있습니다. 거래소 거래량을 합산하는 기준처럼 시장 목록과 환산 방법을 먼저 고정해야 합니다.
- 각 데이터 필드가 raw trade, aggregate trade, 사용자 주문 체결 중 무엇인지 공식 문서에서 확인합니다.
- 거래쌍·상품 유형·거래소 법인·관측 시간대를 표에 함께 적습니다.
- 행 수와 함께 base 수량, quote 거래대금, 중앙값 체결 크기를 별도 열로 둡니다.
- 서로 다른 집계 수준을 한 순위표에 넣어야 하면 원시 단위로 되돌릴 수 있는지와 불가능한 이유를 표시합니다.
- 이상 급증은 결론으로 쓰기 전에 API 사양 변경·시장 재개·수집 누락 여부를 확인합니다.
페이지가 끝난 지점을 기간의 끝으로 착각하지 않기
Coinbase Exchange API의 product trades 응답은 trade_id, price, size, time, side를 개별 레코드로 내보내며, 최신 거래 목록은 pagination됩니다. 기본 limit은 1,000이고 before·after cursor로 범위를 움직입니다. 그러므로 첫 응답의 행 수 1,000을 한 시간 또는 하루의 체결 건수로 적으면, 단지 응답 상한에 닿았다는 사실을 활동량으로 오독할 수 있습니다.
수집기는 마지막 레코드의 ID와 시각, 다음 요청의 cursor, 각 페이지의 최소·최대 ID를 남겨야 합니다. 같은 ID가 두 페이지에 반복되는지, 경계의 거래를 버렸는지, 요청 중 새 거래가 들어와 정렬 창이 움직였는지를 점검해야 합니다. 특히 동일 시각 거래가 많은 시장에서는 timestamp 하나만으로 다음 페이지를 자르면 동률 레코드를 누락하거나 중복할 수 있습니다.
숫자를 비교 가능한 지표로 바꾸는 작은 보고서
체결 건수 자체를 버릴 필요는 없습니다. 같은 venue, 같은 상품, 같은 API 버전, 같은 수집 규칙 안에서 시간별 변화로 보면 주문 분할과 유동성 변화의 단서가 될 수 있습니다. 다만 이때도 건수 급증이 시장 참여 증가인지, 낮아진 최소 단위인지, 피드가 raw에서 aggregate로 바뀐 결과인지는 분리해서 확인해야 합니다. 관측한 데이터만으로 거래 주체의 의도나 실제 참여자 수를 단정할 수는 없습니다.
예를 들어 5분 창마다 raw trade 수, aggregate trade 수, base volume, quote notional, 중간 체결 크기를 나란히 두면 어떤 변화가 행 수에만 있었는지 볼 수 있습니다. ‘거래가 활발했다’는 서술은 최소한 거래대금과 가격 변동, 스프레드 또는 호가 상태 같은 별도 증거가 있을 때 제한적으로 사용합니다. 기준자산 거래량과 거래대금의 단위를 맞추지 않으면 건수와 거래량의 관계도 왜곡됩니다.
| 기록 항목 | 확인할 내용 | 빠졌을 때의 오해 |
|---|---|---|
| 관측 단위 | raw trade인지 aggregate trade인지와 묶는 조건 | 행 수를 동일한 체결 단위로 오인 |
| 시간 창 | UTC 시작·끝과 포함 경계 | 서로 다른 기간의 건수를 비교 |
| 수집 완결성 | cursor, 페이지 수, ID 연속성, 재시도 기록 | 응답 한도 또는 누락을 활동 감소로 해석 |
| 보조 수치 | base 수량, quote 거래대금, 체결 크기 분포 | 작은 주문 분할을 거래대금 증가로 해석 |
건수 급변을 만났을 때 질문할 순서
먼저 같은 데이터 소스에서 직전 기간과 다음 기간을 다시 조회해 수집 공백인지 확인합니다. 둘째, 원시·집계 종류와 endpoint 버전, limit·cursor 처리에 변경이 없는지 봅니다. 셋째, 행 수가 늘어도 base 수량·quote 거래대금·가격 범위가 함께 변했는지 비교합니다. 이 세 단계가 끝나야 주문이 더 잘게 나뉜 것인지, 실제 거래 규모가 달라진 것인지에 대한 가설을 제한적으로 세울 수 있습니다.
거래소별 공개 데이터는 시장 전체의 모든 주문과 계정 정보를 제공하지 않습니다. 체결 건수만으로 특정 주체가 거래했다거나 가장매매가 있었다고 판정할 수 없으며, 그러한 판단에는 거래소의 조사·집행 자료나 추가 증거가 필요합니다. 이 글의 목적은 숫자를 정답처럼 읽는 것이 아니라, 숫자가 어떤 관측 단위에서 나왔는지 드러내는 데 있습니다.
자주 묻는 질문
체결 건수가 많으면 유동성이 좋은가요?
그렇게 단정할 수 없습니다. 체결 건수는 주문 분할과 데이터 집계 방식의 영향을 받습니다. 호가 깊이, 스프레드, 실제 체결 가능 수량, 거래대금을 같은 시간 창에서 함께 확인해야 합니다.
aggTrade 수를 원시 체결 수로 환산할 수 있나요?
집계 레코드가 원시 거래 ID의 시작·끝 또는 구성 수를 제공하고 그 의미가 공식 문서에 명시된 경우에만 범위를 계산할 여지가 있습니다. 그렇지 않으면 aggregate 이벤트 수는 그 자체의 단위로 보관하는 편이 맞습니다.
거래소 API에서 최근 1,000건을 받았으면 그 기간 전체인가요?
아닙니다. Coinbase 문서처럼 limit과 cursor가 있는 endpoint라면 한 응답은 제한된 페이지입니다. 시작·끝 시각과 다음 cursor를 따라 전체 구간을 수집했는지 별도로 검증해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
