바이낸스 FIX MarketDataRequest 뜻 2026｜체결·최우선 호가·깊이 구독과 거절 대조

바이낸스 FIX MarketDataRequest 뜻 2026｜체결·최우선 호가·깊이 구독과 거절 대조

바이낸스 FIX MarketDataRequest는 현물 FIX 시장 데이터 세션에서 어떤 시장 자료를 구독하거나 해제할지 요청하는 메시지입니다. 주문을 제출하는 NewOrderSingle과 구분해야 합니다. 이름에 request가 들어간다고 모두 매수·매도 요청인 것은 아닙니다.

이 글은 2026년 11월 5일 확인한 일반 텍스트 FIX 기준의 시장 자료 요청과 응답을 설명합니다. FIX SBE는 메시지 분기와 일부 필드 표현이 다르므로 마지막 비교에서 따로 다룹니다. 공개 시장 체결을 내 계정의 주문 체결로 기록하지 않습니다.

핵심은 구독 접수, 초기 스냅샷, 이후 갱신과 실제 분석 준비를 나누는 것입니다. 서버와 연결됐다고 필요한 호가가 완성되는 것은 아니며, 구독 요청을 보냈다고 모든 자료가 정상 수신된 것도 아닙니다. 단계마다 확인할 근거가 필요합니다.

필요한 자료부터 선택

Trade: 이미 발생한 시장 거래

체결 자료는 시장에서 일어난 거래 사건입니다. 호가창에 대기 중인 주문 상태와 다릅니다. 현재 공식 문서는 원시 거래 정보를 전달하는 Trade Stream을 안내합니다. 거래 식별자와 시각, 가격·수량의 의미를 해당 메시지 정의에서 확인해야 합니다.

같은 가격과 수량이 반복돼도 서로 다른 거래일 수 있습니다. 단순히 숫자가 같다는 이유로 중복 제거하면 실제 사건을 잃을 수 있습니다. 반대로 연결 전환 중 같은 사건을 다시 받으면 수신 경로가 두 개라도 경제적 사건은 하나일 수 있습니다.

Book Ticker: 최우선 가격과 수량

최우선 매수·매도 자료는 현재 가장 가까운 양쪽 호가를 살펴보는 데 쓰입니다. 전체 주문장 깊이와 같지 않습니다. 스프레드 화면에는 도움이 될 수 있지만 큰 수량의 체결 비용을 평가하려면 더 넓은 범위가 필요할 수 있습니다.

일반 FIX 문서는 해당 구독의 CHANGE 동작이 이전 최우선 호가를 대체한다는 점을 설명합니다. 이를 단순히 새 가격대 하나를 계속 추가하는 방식으로 처리하면 최우선 상태가 여러 줄로 쌓일 수 있습니다. 자료 목적과 변경 의미를 함께 읽어야 합니다.

Diff Depth: 로컬 주문장 갱신

깊이 자료는 가격대별 호가 상태와 갱신을 로컬에서 관리할 때 검토합니다. 초기 상태와 이후 변화를 올바르게 연결해야 합니다. 증분 갱신을 실제 거래량처럼 누적 합산하지 않습니다. 호가의 대기 수량과 체결 수량은 다른 값입니다.

현재 일반 FIX 문서의 MarketDepth는 초기 스냅샷 크기를 정하는 데 사용되며, 이후 증분 갱신의 범위를 같은 숫자로 고정하는 개념이 아니라고 설명합니다. 초기 20단계라는 설정을 이후 모든 메시지가 20단계만 포함한다는 뜻으로 일반화하지 않습니다.

요청 필드 읽기

MDReqID

MDReqID는 시장 자료 요청의 식별자입니다. 일반 FIX의 스냅샷과 갱신, 거절 자료를 원래 구독과 연결할 때 사용됩니다. 주문 번호나 시장의 거래 ID가 아닙니다. 제어 요청과 시장 사건을 서로 다른 범위로 관리해야 합니다.

이미 활성인 요청과 혼동되는 ID를 재사용하면 거절이나 잘못된 귀속이 생길 수 있습니다. 연결 세대와 요청 기록을 함께 보존하면 복구 때 상태를 확인하기 쉽습니다. 다만 내부 연결 ID와 서버에 전달하는 요청 ID의 목적도 구분해야 합니다.

SubscriptionRequestType

현재 공식 문서는 구독과 해제를 구분하는 값을 안내합니다. 어떤 요청이 추가인지 제거인지 명시해야 하며, 로컬 화면 선택만으로 서버 상태가 바뀌었다고 생각하지 않습니다. 전송과 실제 처리 결과를 나눠 기록하는 것이 좋습니다.

해제 뒤에도 로컬 큐에 이전 자료가 남을 수 있습니다. 원본 보관과 현재 화면 반영의 정책을 나눌 수 있지만, 요청을 보낸 순간 이전의 모든 수신 자료가 사라진다고 가정하지 않습니다. 실제 접수와 처리 경계를 확인해야 합니다.

MDEntryType와 MarketDepth

MDEntryType은 체결, 매수 호가와 매도 호가 같은 항목을 구분합니다. 최우선 양쪽 호가와 깊이 자료에서는 필요한 조합과 MarketDepth를 공식 조건에 맞춰 사용해야 합니다. 데이터 종류를 잘못 조합한 요청을 정상 구독으로 추정하지 않습니다.

현재 문서는 최우선 호가에 깊이 1, 증분 깊이에 2~5000 범위를 안내합니다. 이 숫자는 일반 FIX의 해당 기능 조건이며, 모든 바이낸스 시장 자료와 다른 프로토콜의 공통 규칙으로 쓰지 않습니다. 배포 전 현재 공식 문서를 다시 확인해야 합니다.

반복 그룹

FIX의 반복 그룹은 항목 개수와 그룹 안 필드를 올바르게 읽어야 합니다. 메시지 하나가 여러 항목을 담을 수 있으므로 첫 항목만 읽고 종료하면 자료가 누락됩니다. 반대로 같은 필드가 반복된다고 무조건 중복 오류로 처리해도 안 됩니다.

현재 스키마와 라이브러리의 그룹 처리 방식이 맞는지 표본으로 확인합니다. 편의를 위해 모든 태그를 하나의 딕셔너리에 덮어쓰면 앞선 항목을 잃을 수 있습니다. 메시지 구조의 반복과 경제적 사건의 중복은 서로 다른 문제입니다.

구독 이후 확인 흐름

요청 전송과 거절 확인

잘못된 MarketDataRequest에는 MarketDataRequestReject가 올 수 있습니다. 현재 문서는 중복 요청 ID와 과도한 구독 같은 거절 이유를 설명합니다. 오류 코드와 텍스트, 원래 MDReqID를 함께 확인해야 원인을 좁힐 수 있습니다.

자료가 안 온다는 이유로 새 요청을 계속 보내기 전에 거절 기록과 현재 상태를 확인합니다. 이미 유사 구독이 활성인지, 필요한 필드가 맞는지, 연결과 역할이 맞는지 대조해야 합니다. 제한을 우회하는 반복 연결은 정상 복구로 취급하지 않습니다.

초기 MarketDataSnapshot

호가 구독에서는 초기 스냅샷이 현재 상태의 출발점이 됩니다. 스냅샷을 받았다고 모든 시장 가격대가 알려지는 것은 아닙니다. 공식적으로 제한된 초기 범위 밖은 변화가 오기 전까지 모르는 상태일 수 있습니다. 없는 값과 관측되지 않은 값은 다릅니다.

스냅샷에는 요청 식별자와 심볼, 항목과 갱신 관련 정보가 포함될 수 있습니다. 실제 필드의 필수·선택 조건을 확인해야 합니다. 임의 기본값으로 빠진 의미를 채우지 않습니다. 받은 범위와 아직 모르는 범위를 구분해 저장해야 합니다.

이후 MarketDataIncrementalRefresh

갱신 메시지는 구독 자료의 변화를 전달합니다. 일반 FIX에서는 NEW, CHANGE와 DELETE 같은 동작을 확인해야 합니다. 수량을 매번 더하는 방식이 아니라 해당 자료의 동작 의미에 맞춰 상태를 갱신합니다. 거래 사건과 호가 상태의 수량 계산을 섞지 않습니다.

일부 그룹 항목의 심볼이나 갱신 ID는 같은 메시지의 이전 항목 값을 따르는 조건이 안내됩니다. 이를 선택 필드가 없으니 빈 심볼이라고 처리하면 정상 자료를 버릴 수 있습니다. 상속 범위를 같은 메시지 안의 규칙으로 정확히 제한해야 하며 이전 메시지 전체에 임의로 확대하지 않습니다.

분석 준비 완료

자료를 해석하는 것과 분석에 사용할 준비가 된 것은 별개입니다. 필요한 초기 상태, 갱신의 연속성과 신선도, 내부 처리 지연을 확인해야 합니다. 연결이 열렸다는 표시만으로 계산기를 정상 상태로 바꾸지 않습니다.

오래된 자료를 유지할 수는 있지만 마지막 확인 시각과 상태를 표시해야 합니다. 일부 가격대만 아는 주문장으로 전체 유동성을 주장하지 않습니다. 결과의 표현 범위를 원본의 관측 범위와 맞추는 것이 중요합니다.

네 가지 사례

사례 1. 같은 ID로 새 구독을 추가

기존 호가 구독의 요청 ID를 새 체결 구독에 다시 사용했다고 가정합니다. 거절이 왔다면 서버가 자료를 제공하지 않는다고 단정하기 전에 ID와 활성 구독 상태를 확인합니다. 원래 요청의 역할과 새 의도를 비교해야 합니다.

거절 텍스트만 보고 입력을 임의 변경하는 대신 MDReqID와 이유, 현재 설정을 기록합니다. 수정한 요청이 실제로 접수되고 필요한 자료가 오는지 확인합니다. 실패한 시도와 성공한 결과를 구분하면 다음 복구에서 같은 오류를 반복하기 어렵습니다.

사례 2. 초기 깊이를 전체 유동성으로 계산

설명용으로 초기 20단계 스냅샷을 받았다고 가정합니다. 그 밖의 가격대를 모두 수량 0으로 간주하면 전체 주문장 해석이 틀어질 수 있습니다. 자료가 없다는 사실과 시장에 주문이 없다는 사실은 다릅니다.

분석 결과에는 관측한 초기 범위와 이후 갱신 조건을 명시합니다. 대량 주문 비용을 평가하려면 해당 수량과 가격 범위를 뒷받침하는 자료가 있는지 확인해야 합니다. 상위 범위의 스프레드가 좁아도 큰 수량의 체결 비용은 다를 수 있습니다.

사례 3. 여러 항목 메시지에서 첫 줄만 저장

갱신 메시지의 반복 그룹에 여러 체결이 있는데 파서가 첫 항목만 처리한 상황입니다. 연결과 서버는 정상이어도 로컬 거래량은 작게 나올 수 있습니다. 수신 메시지 개수와 실제 항목 개수를 나눠 확인해야 합니다.

표본에서 그룹 개수와 처리한 항목 수를 대조합니다. 반복 필드를 단일 값으로 덮어쓰는 구현인지 확인하고 스키마에 맞게 수정합니다. 수정 후에는 한 항목 표본뿐 아니라 여러 심볼과 여러 항목, 선택값이 생략된 경우를 검토해야 합니다.

사례 4. 해제 뒤 늦은 자료가 도착

구독 해제를 요청했는데 이전 자료가 잠시 처리 큐에 남아 있는 상황입니다. 늦은 자료를 무조건 서버의 잘못된 재구독으로 판단하지 않습니다. 원본 수신 시각과 해제 처리, 로컬 큐의 경계를 확인해야 합니다.

원본 보관과 현재 화면 반영을 나누면 이 구간을 설명하기 쉽습니다. 새 구독의 자료와 섞이지 않도록 연결 세대와 요청 범위를 유지합니다. 실제 활성 상태가 불명확하다면 확인 가능한 공식 절차로 대조하고 무제한 추가·해제를 반복하지 않습니다.

로컬 수집기의 책임

수집기는 요청 기록과 자료 기록을 연결할 수 있어야 합니다. 어떤 구독이 어떤 심볼과 종류를 의미하는지, 언제 추가·해제됐는지 남기면 누락 구간을 확인하기 쉽습니다. 현재 화면에 보이는 종목 목록만 보존하면 과거의 수집 범위를 설명하기 어렵습니다.

원본 수신 시각과 사건 시각, 저장 시각도 나눠 볼 수 있습니다. 지연을 비교할 때는 단위와 장비의 시계 조건을 맞춰야 합니다. 로컬 수신 차이를 매칭 엔진의 정확한 처리 지연이라고 광고하지 않습니다. 갱신 주기와 종단 지연도 다릅니다.

부하가 커지면 큐가 쌓일 수 있습니다. 큐를 크게 만들었다고 최신 자료가 유지되는 것은 아닙니다. 처리 대기량과 가장 오래된 미처리 자료를 확인하고, 연속성이 필요한 깊이 자료를 임의로 버리지 않도록 정책을 검토해야 합니다.

오류가 발생한 구간은 자료 품질 기록에 반영합니다. 빈 구간을 무거래 기간으로 채우거나 마지막 값을 실제 현재 상태로 간주하지 않습니다. 복구 후에는 필요한 초기 상태와 갱신 경계를 다시 검증해야 합니다. 원본 기록과 계산 결과의 책임을 나누면 재검토가 쉬워집니다.

SBE와 함께 쓸 때

FIX SBE에서는 일반 FIX의 공통 갱신이 자료별 메시지로 나뉘고 일부 자료를 Symbol과 template로 연결하도록 안내됩니다. 따라서 일반 FIX의 MDReqID 기반 분기를 그대로 적용하지 않습니다. 구독 요청과 거절에서는 요청 ID가 여전히 중요할 수 있습니다.

변경 동작도 현재 스키마를 따라야 합니다. 일반 FIX의 MDUpdateAction과 SBE의 null·값 존재 조건을 혼동하지 않습니다. 같은 이름의 시장 자료라도 인코딩별 차이를 따로 확인해야 합니다. 빠른 형식이라는 인상보다 의미 보존이 먼저입니다.

두 형식을 비교할 때 자료 종류와 구독 범위, 저장 방식과 측정 기준을 맞춥니다. 다른 조건에서 받은 자료량의 차이를 인코딩 성능의 유일한 근거로 쓰지 않습니다. 공식적으로 안내된 전달 특성의 차이도 함께 고려해야 합니다.

구독 장부와 자료 장부를 분리하기

구독 장부는 어떤 요청을 보냈고 무엇이 활성인지 설명합니다. 자료 장부는 어떤 시장 사건과 호가 갱신을 실제로 받았는지 설명합니다. 두 장부를 연결할 수 있어야 하지만 같은 것은 아닙니다. 요청이 성공해도 자료가 잠시 없을 수 있고, 해제 이후에도 이전에 받은 자료가 저장 큐에 남아 있을 수 있습니다. 이 차이를 모델에 반영하는 것이 좋습니다.

구독 장부에는 요청 ID와 심볼, 자료 종류와 깊이 조건, 연결 세대와 확인 시각을 남길 수 있습니다. 추가와 제거의 시도·결과도 나눠 기록합니다. 실제 수신 목록과 비교하면 등록은 됐는데 파서가 처리하지 못하는 상태를 발견할 수 있습니다. 화면 선택 상태를 서버의 확인된 상태로 바로 덮어쓰지 않습니다.

반복 그룹 해석의 경계

메시지 안의 기본값 상속

공식 문서가 같은 메시지의 이전 항목을 따르도록 설명하는 필드는 그 범위 안에서 처리해야 합니다. 이전 메시지 전체에서 마지막으로 본 심볼을 무조건 사용하면 자료가 다른 대상에 붙을 수 있습니다. 어떤 그룹의 어떤 항목에서 값을 이어받았는지 검증할 수 있어야 합니다. 선택 필드 생략을 전역 캐시 규칙으로 확대하지 않습니다.

반복 그룹에 여러 사건이 있다면 메시지 수와 항목 수를 따로 기록할 수 있습니다. 수신 메시지가 하나라고 거래가 하나라는 뜻은 아닙니다. 반대로 하나의 시장 사건이 여러 연결에서 보일 수 있으므로 원본 항목 수와 고유 사건 수 역시 다를 수 있습니다. 이 세 단위를 구분하면 누락과 중복 진단이 쉬워집니다.

변경 동작과 내부 자료 구조

NEW·CHANGE·DELETE를 처리할 때 가격과 방향, 해당 자료의 상태 범위를 확인합니다. 매수와 매도에 같은 가격이 보인다고 같은 키로 덮어쓰면 안 됩니다. 거래와 호가도 같은 가격·수량 자료로 단순화하지 않습니다. 내부 키 설계는 원본 자료의 의미를 반영해야 합니다.

최우선 호가 교체와 깊이 가격대 갱신은 같은 동작 이름을 보더라도 사용 목적이 다를 수 있습니다. 최우선 자료에서 이전 상태를 대체해야 하는 상황과 여러 가격대를 유지하는 상황을 구분합니다. 구조를 잘못 선택하면 파서는 정상인데 화면과 계산이 틀어질 수 있습니다. 표본과 공식 설명을 함께 대조해야 합니다.

초기 스냅샷과 이후 관측 범위

스냅샷에서 알게 된 가격대와 이후 갱신으로 새로 알게 된 가격대를 나눠 생각할 수 있습니다. 초기 범위 밖은 주문이 없다는 뜻이 아니라 아직 모르는 상태일 수 있습니다. 이 불확실성을 내부 모델과 보고서에서 보존해야 합니다. 보이지 않는 수준을 모두 0으로 채우면 전체 유동성을 왜곡할 수 있습니다.

구독을 새로 시작하거나 연결을 복구할 때는 초기 상태를 언제부터 신뢰할 수 있는지 검토합니다. 이전 연결의 마지막 상태를 새 갱신에 무조건 붙이지 않습니다. 필요한 갱신 ID와 경계를 공식 조건에 맞춰 대조해야 합니다. 현재 자료 수신과 연속된 상태 복원은 별도 결과입니다.

오래된 자료를 사용하는 위험

연결은 정상인데 로컬 저장이나 계산이 밀리면 과거 자료를 계속 처리할 수 있습니다. 화면에 값이 자주 바뀐다는 사실만으로 최신 자료를 보여준다고 판단할 수 없습니다. 마지막 사건 시각과 원본 수신, 처리 대기량을 함께 봐야 합니다. 단순한 연결 표시만으로 자료 품질을 설명하지 않습니다.

자동 분석에서는 어떤 상태에서 계산을 중단하거나 결과를 미확인으로 표시할지 정해야 합니다. 기준은 업무 목적과 자료 특성에서 정하고 문서에 없는 시간을 거래소의 보장으로 붙이지 않습니다. 불완전한 입력을 정상적인 매매 신호로 바꾸지 않는 정책이 중요합니다. 복구 기준도 사용 중단 기준과 함께 정의해야 합니다.

거절과 불명확한 요청의 후속 처리

거절은 원래 요청의 어떤 조건이 문제였는지 확인할 근거가 될 수 있습니다. 단순히 자료 없음이라는 표시로 줄이면 수정할 부분을 알기 어렵습니다. 요청 ID와 이유, 현재 활성 범위를 연결해 기록합니다. 중복 요청과 구독 제한, 필드 조합 문제를 각각 확인해야 합니다.

응답 자체가 확인되지 않은 경우에는 성공과 실패를 임의로 확정하지 않습니다. 현재 공식적으로 확인 가능한 상태와 실제 수신을 대조해 범위를 좁힙니다. 같은 요청을 계속 보내는 행동은 제어량과 혼동을 늘릴 수 있습니다. 재시도는 원인이 해소됐거나 확인 가능한 다음 단계가 있을 때 수행해야 합니다.

수집 결과를 내보낼 때

자료를 다른 분석자에게 전달한다면 심볼과 종류, 단위와 수집 구간을 함께 제공하는 편이 좋습니다. 자료가 실제 체결인지 호가 상태인지 명확해야 합니다. 누락과 중복 처리, 복구 보완 여부도 결과의 해석에 영향을 줍니다. 숫자 열만 내보내면 원래 범위를 오해하기 쉽습니다.

특히 상위 호가로 만든 자료를 전체 주문장 이력으로 이름 붙이지 않습니다. 원본이 제공한 범위와 분석 결론이 맞아야 합니다. 현재 상태 조회로 빈 구간을 보완했다면 모든 중간 사건을 실시간으로 받았던 것으로 표시하지 않습니다. 자료 품질의 구분은 기술 로그가 아니라 결과의 신뢰 범위를 설명하는 정보입니다.

수집 인수 시험에서 볼 항목

단일 심볼의 체결 수신뿐 아니라 여러 반복 항목, 최우선 교체, 깊이의 새 가격대와 삭제, 구독 해제와 재연결을 각각 검토할 수 있습니다. 시험 항목마다 서버의 원본과 로컬 해석, 화면과 저장 결과를 연결해야 합니다. 원본은 정상인데 집계만 틀리는 경우도 있으므로 접속 성공이나 수신 건수만으로 검증을 끝내지 않습니다.

각 결과에는 어떤 종류와 범위가 확인됐는지 적습니다. 체결 수신을 확인했다고 깊이 복원도 확인된 것은 아닙니다. 같은 연결에서 받더라도 자료마다 초기 상태와 계산 요구가 다르기 때문입니다. 필요한 업무에 맞는 인수 기준을 정하고 아직 검증하지 않은 자료를 정상 지원 목록에 섞지 않아야 합니다.

FAQ

Q1. MarketDataRequest는 주문인가요?

시장 자료의 구독과 해제를 위한 요청입니다. 계정의 매수·매도 주문 전송과 구분해야 합니다. 공개 자료 수신 성공을 주문 실행 성공으로 기록하지 않습니다.

Q2. MDReqID가 거래 ID인가요?

구독 요청을 식별하는 값입니다. 시장의 개별 거래나 계정 주문의 식별자와 다릅니다. 각 범위를 구분해 보존해야 오류와 중복을 대조할 수 있습니다.

Q3. Trade 자료로 내 체결을 알 수 있나요?

공개 시장 체결은 계정 귀속의 충분한 근거가 아닙니다. 내 주문 결과는 계정 보고와 조회에서 확인해야 합니다. 비슷한 가격과 수량만으로 연결하지 않습니다.

Q4. Book Ticker는 전체 주문장인가요?

최우선 양쪽 호가를 보는 자료입니다. 큰 수량의 체결 비용이나 전체 깊이를 보장하지 않습니다. 분석 질문에 맞는 범위의 자료를 선택해야 합니다.

Q5. MarketDepth는 이후 갱신도 제한하나요?

현재 일반 FIX 안내는 초기 스냅샷 크기와 이후 갱신의 범위를 구분합니다. 초기 깊이 숫자를 모든 후속 자료의 범위로 일반화하지 않습니다. 선택한 프로토콜 문서를 확인해야 합니다.

Q6. 자료가 없으면 재요청하면 되나요?

먼저 거절과 활성 구독, 파서와 갱신 조건을 확인합니다. 원인이 해결되지 않은 반복 요청은 제한과 혼동을 늘릴 수 있습니다. 요청과 실제 결과를 나눠 기록해야 합니다.

Q7. 스냅샷 밖은 수량 0인가요?

관측되지 않은 범위일 수 있습니다. 없는 자료를 시장에 주문이 없는 것으로 확정하지 않습니다. 보고서에는 관측 범위와 불완전성을 명시해야 합니다.

Q8. 갱신 수량은 계속 더하나요?

변경 동작과 자료 종류의 의미를 확인해야 합니다. 호가 잔량과 체결량은 다릅니다. 모든 숫자 수량에 같은 누적 규칙을 적용하면 장부가 왜곡될 수 있습니다.

Q9. 반복 필드는 중복인가요?

반복 그룹 안의 서로 다른 항목일 수 있습니다. 단일 딕셔너리로 덮어쓰면 앞선 항목을 잃을 수 있습니다. 공식 스키마의 그룹 구조를 따라야 합니다.

Q10. 일부 항목에 심볼이 없으면 버리나요?

같은 메시지 내 이전 항목을 따르는 공식 조건을 확인합니다. 빈값으로 단순 처리하지 않습니다. 상속 범위를 이전 메시지나 다른 연결까지 임의 확대하지도 않습니다.

Q11. 구독 해제 뒤 원본을 지우나요?

현재 구독 상태와 과거 자료의 보관은 다른 문제입니다. 수집 범위를 설명할 필요가 있다면 원본과 변경 이력을 정책에 맞춰 보존합니다. 현재 선택에서 빠졌다고 과거 사건이 없어지는 것은 아닙니다.

Q12. SBE도 같은 파서를 사용하나요?

프레이밍과 메시지 분기, 요청 ID와 변경 동작 표현을 별도 확인해야 합니다. 텍스트 FIX의 구조를 그대로 바이너리에 적용하지 않습니다. 의미를 대응시키는 별도 검증이 필요합니다.

Q13. 갱신 주기가 실제 수신 지연인가요?

문서의 갱신 조건과 사용자 환경의 종단 지연은 다릅니다. 네트워크와 로컬 처리 시간이 영향을 줍니다. 측정 위치와 단위 없이 성능 숫자를 일반화하지 않습니다.

Q14. 연결만 복구하면 주문장도 맞나요?

필요한 초기 상태와 연속성 검증이 남습니다. 자료 공백이 있었다면 기존 상태를 현재로 확정하지 않습니다. 공식 복구 조건에 맞춰 대조해야 합니다.

Q15. 정상 수집의 완료 기준은 무엇인가요?

역할과 요청, 거절 여부, 초기 상태와 갱신, 신선도와 처리 결과를 함께 확인합니다. 요청 전송과 접속만으로 모든 자료가 준비됐다고 표시하지 않습니다.

체크리스트

• 일반 FIX와 SBE를 구분했는가
• 시장 자료와 계정 결과를 분리했는가
• 분석 목적에 맞는 종류를 선택했는가
• MDReqID와 사건 식별자를 나눴는가
• 구독·해제 요청의 결과를 기록하는가
• 필요한 필드 조합과 현재 제한을 확인했는가
• 거절 이유와 원래 요청을 대조하는가
• 스냅샷 범위를 보존하는가
• 관측되지 않은 범위를 0으로 확정하지 않는가
• 변경 동작을 자료 의미에 맞게 처리하는가
• 반복 그룹의 모든 항목을 읽는가
• 선택 필드의 상속 범위를 지키는가
• 시간 단위와 신선도를 검증하는가
• 복구 뒤 연속성을 확인하는가
• 잘못된 자료를 정상값으로 숨기지 않는가

핵심 정리

바이낸스 FIX MarketDataRequest는 자료를 받기 위한 시작점입니다. 구독 이후의 스냅샷과 갱신을 정확히 해석해야 분석 준비가 됩니다. 다음 글에서는 구독 대상인 거래상품을 InstrumentList에서 어떻게 조회하고 필터 정보와 구분하는지 살펴봅니다.

공식 확인 자료: Binance FIX API의 Market Data Messages, 공식 FIX 원본. 확인일은 2026년 11월 5일입니다.

이 글은 기술 정보이며 투자 권유가 아닙니다. 자료 누락·지연·파서 오류가 생길 수 있고 공개 시장 자료는 내 주문 체결이나 미래 가격을 보장하지 않습니다. 실제 적용 전 최신 공식 조건과 데이터 범위를 확인하세요.