로컬 호가창은 snapshot을 받은 뒤 그때부터 delta를 듣는 순서로 만들면 snapshot 요청 중 발생한 변경을 놓칠 수 있습니다. 먼저 WebSocket delta를 버퍼에 쌓고, 그다음 snapshot을 받아 snapshot의 lastUpdateId 이전 이벤트를 버립니다. 첫 적용 이벤트의 ID 범위가 snapshot 다음 순번을 포함하는지 확인한 뒤 가격 레벨을 갱신합니다. 이후 이전 순번과 새 이벤트가 이어지지 않으면 현재 북을 신뢰하지 말고 폐기하고, 새 snapshot으로 처음부터 재동기화해야 합니다.
snapshot과 delta는 서로 다른 역할을 합니다
snapshot은 특정 update ID 시점에 존재한 가격별 잔량의 상태입니다. delta는 이후 변경된 가격 레벨만 보냅니다. snapshot만 반복 조회하면 요청 사이 변화를 놓치고, delta만 받으면 연결 이전부터 남아 있던 잔량을 알 수 없습니다. 두 자료는 snapshot 기준점과 그 이후 순서가 정확히 연결될 때 하나의 로컬 주문서가 되며, 그 뒤에야 호가 불균형 같은 지표를 계산할 수 있습니다.
Binance의 공식 절차는 depth 스트림을 열어 이벤트를 버퍼링한 다음 REST depth snapshot을 받도록 안내합니다. snapshot의 lastUpdateId가 첫 버퍼 이벤트보다 너무 오래됐으면 snapshot을 다시 받고, snapshot에 이미 반영된 이벤트는 버립니다. 이 순서가 네트워크 왕복 중 생긴 변경을 잃지 않게 합니다.
호가창 재구축은 잔량을 모으는 작업이 아니라 하나의 연속된 순번 상태를 증명하는 작업입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- snapshot과 delta는 서로 다른 역할을 합니다
snapshot은 특정 update ID 시점에 존재한 가격별 잔량의 상태입니다.
- 첫 delta가 snapshot 경계를 덮는지 확인합니다
가상 snapshot의 `lastUpdateId=100`이고 버퍼 이벤트가 `[U=98,u=100]`, `[101,102]`, `[103,103]`이라면 첫 이벤트는 snapshot에 이미 반영돼 버립니다.
- 가격 레벨은 문서의 교체·삭제 규칙대로 갱신합니다
가상 snapshot에 bid 50,000원 수량 2가 있고 다음 delta가 같은 가격 수량 3을 보냈다고 합시다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
첫 delta가 snapshot 경계를 덮는지 확인합니다
가상 snapshot의 `lastUpdateId=100`이고 버퍼 이벤트가 `[U=98,u=100]`, `[101,102]`, `[103,103]`이라면 첫 이벤트는 snapshot에 이미 반영돼 버립니다. 다음 `[101,102]`는 snapshot 다음 순번 101을 포함하므로 첫 적용 이벤트입니다. `[103,103]`도 직전 끝 102 다음으로 이어집니다. 이 숫자는 알고리즘 검산용 가정입니다.
반대로 버퍼의 첫 적용 후보가 `[105,106]`이면 101~104 변경을 잃었습니다. snapshot에 없는 레벨을 현재 수량 0으로 가정하거나 105부터 적용하면 유령 주문과 누락 주문이 함께 생깁니다. 버퍼를 비우고 연결부터 다시 시작하는 것이 안전합니다.
| 상태 | ID 예시 | 처리 | 이유 |
|---|---|---|---|
| 이미 반영 | u≤100 | 버림 | snapshot에 포함 |
| 경계 연결 | U≤101≤u | 첫 적용 | 다음 순번 포함 |
| 정상 후속 | next U=prev u+1 | 적용 | 연속 상태 |
| 공백 | U>prev u+1 | 폐기·재동기화 | 중간 변경 누락 |
가격 레벨은 문서의 교체·삭제 규칙대로 갱신합니다
가상 snapshot에 bid 50,000원 수량 2가 있고 다음 delta가 같은 가격 수량 3을 보냈다고 합시다. Binance depth 규칙에서 수량은 새 절대 수량이므로 결과는 5가 아니라 3입니다. 이후 수량 0 이벤트가 오면 그 레벨을 삭제합니다. 덧셈으로 구현하면 업데이트마다 잔량이 부풀고, 0 레벨을 보존하면 실제로 없는 주문이 분석에 남습니다.
삭제하려는 가격이 로컬 북에 없어도 정상일 수 있습니다. snapshot 깊이 밖에 있던 레벨이 snapshot 이후 이미 사라졌거나 수신 경계 때문에 로컬에 없을 수 있기 때문입니다. 경고 로그는 남기되 이것만으로 공백이라 단정하지 않고 sequence 연속성으로 무결성을 판단합니다.
- WebSocket 연결과 delta 버퍼링을 먼저 시작합니다.
- snapshot ID보다 오래된 버퍼 이벤트를 버립니다.
- 첫 적용 이벤트가 snapshot 다음 ID를 포함하는지 검사합니다.
- 수량 0은 삭제하고 sequence gap이면 전체 재동기화합니다.
재연결과 중복 이벤트도 같은 상태 기계로 처리합니다
네트워크가 끊긴 동안 몇 개의 delta가 있었는지 알 수 없다면 이전 로컬 북을 이어 쓰지 않습니다. connection_id를 새로 만들고 새 버퍼와 새 snapshot으로 재구축합니다. 늦게 도착한 이전 연결 메시지는 connection_id가 다르므로 버려야 합니다. 두 연결의 이벤트를 timestamp 순서로 섞으면 순번이 우연히 맞아 보이는 오염이 생깁니다.
같은 이벤트가 재전송되거나 소비자가 재시작해 버퍼를 다시 읽을 수 있습니다. 이벤트 끝 ID가 현재 로컬 ID 이하라면 이미 적용된 것으로 보고 무시합니다. 적용·체크포인트 저장을 하나의 트랜잭션으로 묶거나 마지막 적용 ID를 함께 기록하면 재시작해도 같은 상태로 수렴합니다.
로컬 북의 불변식을 계속 검사합니다
정상 주문서는 최고 bid가 최저 ask보다 낮아야 하고, 모든 수량은 0보다 커야 하며, 가격 레벨은 각 side에서 정렬돼야 합니다. crossed book이 나타나면 실제 시장의 잠깐 상태일 수도 있지만 재구축 오류, 상품 혼합, 업데이트 순서 오류도 점검해야 합니다. snapshot과 직후 REST 표본의 상위 레벨을 비교하면 장기 누적 오염을 조기에 찾을 수 있습니다.
가상 검산에서 snapshot에 40개 레벨, delta로 3개 교체·2개 삭제·1개 신규가 있었다면 단순 레벨 수 기대치는 `40-2+1=39개`입니다. 교체 3개는 레벨 수를 바꾸지 않습니다. 실제로 42개가 남았다면 0 삭제 실패나 잘못된 덧셈을 조사합니다. 이 계산은 동시 가격 이동이 없는 작은 테스트 픽스처에 한정됩니다.
운영 지표는 정확성과 복구 비용을 함께 보여 줍니다
대시보드에는 현재 connection_id, 마지막 update ID, buffer 크기, gap 횟수, 재동기화 시간, snapshot 재시도 횟수를 둡니다. 단순히 ‘connected’만 표시하면 연결은 살아 있지만 로컬 북이 무효인 상태를 놓칩니다. 상태를 buffering, syncing, live, stale로 나누고 live일 때만 지표 계산에 사용하세요.
재동기화가 반복되면 호출 제한과 메모리 사용이 커질 수 있습니다. 버퍼 최대 크기와 snapshot 제한 시간을 정하고 넘으면 안전하게 중단해 원인을 남깁니다. 로컬 북이 완성됐다는 사실은 데이터 재구축 증거이며, 그 호가가 실제 체결 가능하거나 미래 가격을 예측한다는 뜻은 아닙니다.
자주 묻는 질문
snapshot을 먼저 받고 바로 WebSocket에 연결하면 왜 안 되나요?
snapshot 응답 이후 연결 완료 사이의 delta를 잃을 수 있습니다. 스트림을 먼저 버퍼링해야 그 틈을 메울 수 있습니다.
sequence가 한 번 끊기면 REST에서 빠진 한 건만 찾으면 되나요?
API가 정확한 범위 복구를 보장하지 않으면 안전하지 않습니다. 공식 절차에 따라 전체 snapshot부터 재동기화하세요.
delta 수량은 기존 잔량에 더하나요?
거래소 계약에 따라 다릅니다. Binance depth 예시처럼 절대 수량이면 교체하고 0이면 삭제합니다. 문서 확인 없이 덧셈하면 안 됩니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
