Reading the Hyperliquid Order Book Through the API: Depth, Spread, and What They Actually Tell You

By @CoinMarketMan - 27-May-2026

API를 통해 Hyperliquid 오더북 읽기: 깊이, 스프레드 그리고 그것들이 실제로 말해주는 것

대부분의 개인 트레이더들은 Hyperliquid UI에서 오더북을 대충 훑어보고, 한쪽에는 녹색 바, 다른 쪽에는 빨간색 바를 보며 대략적인 인상을 형성합니다: 빨간색보다 녹색이 더 많으면 "매수세가 우위"라고요. 그 인상은 맞을 때보다 틀릴 때가 약간 더 많습니다. 오더북은 트레이딩에서 가장 정보 밀도가 높은 데이터 구조 중 하나이며, 일반적으로 표시되는 방식은 중요한 거의 모든 것을 압축해버립니다.

동일한 데이터에 대한 Hyperliquid API를 통한 프로그래밍 방식 접근은 오더북을 구조화된 신호로 바꿉니다. 바를 읽는 것을 멈추고 유동성의 형태를 읽기 시작합니다 — 그것이 어디에 집중되는지, 가격이 접근할 때 어떻게 변화하는지, 그리고 스프레드가 자체 최근 히스토리에 비해 무엇을 하고 있는지. 코호트 포지셔닝 데이터와 결합하면, 이러한 리딩은 UI가 답할 수 없는 질문에 답합니다: 누가 유동성을 제공하고 있는지, 누가 그것을 가져가고 있는지, 그리고 보이는 매수 호가가 진짜 의도인지 아니면 터치 시 철회되는 노이즈인지.

이 글은 API를 통해 Hyperliquid의 오더북을 읽는 실용적인 메커니즘을 다룹니다: 깊이와 스프레드가 실제로 무엇을 측정하는지, 모든 무기한 선물 자산에서 반복되는 세 가지 북 형태, 그리고 노이즈에서 신호를 필터링하기 위해 오더북 리딩을 코호트 데이터와 결합하는 방법.

오더북이 실제로 나타내는 것

무기한 선물 오더북은 시장 양쪽의 대기 중인 지정가 주문의 스냅샷입니다. 각 레벨은 특정 가격에서 이용 가능한 누적 수량을 보여줍니다. "스프레드"는 최고 매수 호가와 최저 매도 호가 간의 차이입니다. "깊이"는 중간 가격 주변의 특정 가격 대역 내에 얼마나 많은 볼륨이 있는지입니다.

오더북을 보기보다 읽기 어렵게 만드는 두 가지:

유동성은 약속이 아닙니다. 대기 중인 매수 호가는 누군가가 팔려고 할 경우 해당 가격에 매수하겠다는 제안입니다. 메이커는 밀리초 단위로 해당 주문을 취소할 수 있습니다. 바쁜 무기한 선물 오더북에 표시되는 대부분은 가격이 접근할 때 사라지는 기회주의적 유동성입니다.
디스플레이가 정보를 압축합니다. UI 오더북은 일반적으로 각 측면당 10-20개 레벨을 보여줍니다. API는 각 측면당 50개 이상을 노출하며, 해당 레벨이 어떻게 변경되었는지의 전체 시계열도 제공합니다. 신호는 UI에 맞지 않는 레벨과 다이나믹스에 있습니다.

API는 두 가지를 모두 제공합니다 — 어느 순간의 스냅샷과 북이 초 단위로 어떻게 진화하는지 추적할 수 있는 능력. 그것이 분석적 우위가 시작되는 곳입니다.

프로그래밍 방식으로 오더북 가져오기

Hyperliquid의 오더북은 공개 WebSocket 및 REST 엔드포인트를 통해 접근할 수 있습니다. HyperTracker API는 이 접근을 래핑하고 정규화하며, 히스토리 지속성을 추가하고, 코호트 포지셔닝 데이터를 오버레이합니다.

기본 스냅샷 가져오기:

import requests

# BTC 무기한 선물의 현재 오더북 가져오기
ob = requests.get(
    "https://api.hypertracker.cmm.app/orderbook/BTC",
    headers={"Authorization": "Bearer YOUR_API_KEY"}
).json()

# 구조:
# {
#   "timestamp": "2026-05-25T14:30:00Z",
#   "mid": 81234.50,
#   "spread_bps": 1.2,
#   "bids": [{"price": 81234.0, "size": 4.5}, ...],
#   "asks": [{"price": 81235.0, "size": 3.8}, ...],
#   "depth_1pct": {"bid": 142.3, "ask": 138.7},   # 중간가의 1% 이내 BTC
#   "depth_5pct": {"bid": 1284.5, "ask": 1247.2}, # 중간가의 5% 이내 BTC
# }

각 가져오기에서 가장 유용한 파생 메트릭:

mid — 최고 매수 호가와 최저 매도 호가의 평균, 분석 목적의 "진짜" 가격
spread_bps — 베이시스 포인트 단위의 스프레드 (1 bps = 0.01%), 자산 간 비교를 위해 정규화됨
depth_1pct / depth_5pct — 대역 내 총 대기 수량. 주어진 대역에서 매수 깊이 대 매도 깊이의 비율이 불균형 신호입니다.
depth_imbalance — (bid_depth - ask_depth) / (bid_depth + ask_depth), -1에서 +1 범위

반복되는 세 가지 오더북 형태

수백 개의 오더북 스냅샷을 보면, 이름 붙일 만큼 충분히 나타나는 세 가지 구조적 패턴이 있습니다:

1. 벽(Wall)

인접 레벨보다 상당히 많은 수량을 가진 단일 레벨(또는 밀집된 클러스터). 종종 인접 레벨의 평균 크기보다 5-10배 큽니다. 매수 측면에서는 "바닥"처럼 보이고, 매도 측면에서는 "천장"처럼 보입니다.

의미: 해당 레벨에서 확신을 가진 진짜 매수자/매도자(가격을 방어할 것) 또는 소규모 트레이더들을 물러나게 하려는 스푸핑 의도.

차이를 판단하는 방법: 가격이 벽에 닿을 때까지 기다리세요. 벽이 터치를 견디면 진짜입니다. 가격이 접근하는 순간 철회되고 가격이 이동한 후 다른 레벨에 다시 나타나면 스푸핑일 가능성이 높습니다 — 하지만 Hyperliquid의 오더북 투명성은 대량 스푸핑을 중앙화 거래소보다 더 가시적이고 따라서 덜 일반적으로 만듭니다.

2. 페이드(Fade)

처음 몇 레벨을 넘어서면 깊이가 급격히 얇아지는 북. 최고 매수 호가와 최저 매도 호가는 각각 괜찮은 크기를 가지지만, 중간가에서 1% 떨어진 곳에서는 북 상단에 있던 깊이가 80% 이상 감소했습니다.

의미: 마켓 메이커들이 타이트하고 낮은 확신의 유동성을 제공하고 있습니다. 그들은 소규모 거래를 촉진할 의향은 있지만 큰 움직임을 흡수하지는 않습니다. 이것은 낮은 변동성 횡보 기간의 일반적인 형태입니다.

읽는 방법: 페이드 형태의 북은 심지가 발생하기 쉽습니다. 유동성이 빠르게 얇아질 때, 적당한 시장가 매수는 여러 레벨을 휩쓸고 단일 캔들에서 가격을 2-3% 밀어낼 수 있습니다. 페이드 형태의 북에서 스탑을 가진 포지션을 보유하고 있다면, 보이는 스프레드가 제안하는 것보다 높은 심지 위험을 예상하세요.

3. 스택(Stack)

여러 레벨에 걸쳐 깊이가 대략 균일한 북, 종종 서로 30% 이내인 크기의 5-10개 레벨이 있습니다. 북이 "어깨"를 가지고 있습니다 — 상단뿐만 아니라 몇 퍼센트 아래에도 상당한 깊이.

의미: 여러 마켓 메이커가 경쟁하거나 진정한 양방향 관심. 이것은 정돈된 가격 발견을 지원하는 형태입니다. 큰 거래는 하나를 휩쓰는 대신 많은 레벨에 걸쳐 흡수됩니다.

읽는 방법: 스택 형태의 북은 심지 저항성이 있습니다. 스택 북에서의 5% 시장가 주문은 페이드 북에서의 동일한 주문보다 중간가를 훨씬 덜 이동시킵니다. 시장가 진입의 크기를 정하고 북이 스택 형태라면, 과도한 슬리피지를 예상하지 않고 더 공격적일 수 있습니다.

세 가지 북 형태

맥락 속의 스프레드

스프레드 자체는 올바른 참조가 자산별로 다르기 때문에 해석하기 어렵습니다. BTC 무기한 선물은 보통 Hyperliquid에서 1-2 bps 스프레드로 거래됩니다; 롱테일 HIP-3 시장은 30-50 bps를 가질 수 있습니다. 신호는 절대 수치가 아닙니다 — 자산 자체의 최근 베이스라인에 비해 변화입니다.

추적할 가치가 있는 세 가지 스프레드 패턴:

압축: 스프레드가 최근 베이스라인 아래로 좁아집니다. 더 타이트한 스프레드가 더 공격적인 플로우를 끌어들이기 때문에 종종 가격 움직임에 선행합니다. 지속적인 압축은 무언가가 깨지려 한다는 선행 지표입니다.

확대: 스프레드가 급격히 확장되며, 종종 뉴스 이벤트, 청산 캐스케이드 또는 펀딩 극단 동안 발생합니다. 순간적인 더 넓은 스프레드는 슬리피지 경고이기도 합니다 — 확대 동안의 시장가 주문은 예상보다 나쁘게 체결될 것입니다.

펄싱: 스프레드가 두 개의 가시적 상태(예: 1 bps와 3 bps) 사이를 왕복하며, 종종 규칙적인 주기로. 보통 단일 마켓 메이커가 호가 제공을 지배하고, 리드미컬하게 레벨을 철회하고 교체함을 나타냅니다.

절대 bps가 아닌 24시간 중앙값에 대한 비율로 스프레드를 추적하세요. 그것은 자산 간에 정규화되고 깨끗한 "이것이 정상인가" 측정을 제공합니다.

오더북 리딩과 코호트 데이터 결합

오더북 메커니즘을 실제 트레이더 우위로 바꾸는 것은 누가 거래를 하고 있는지를 레이어링하는 것입니다. 오더북 리딩은 유동성의 형태를 알려줍니다. 코호트 데이터는 테이커와 메이커의 구성을 알려줍니다.

실용적인 조합:

설정: 매수 측면의 벽 + 최근 몇 시간 동안 롱 포지션을 늘리는 Money Printer 코호트. 진짜 매수 벽은 일반적으로 자본이 필요합니다. 코호트 데이터가 같은 기간에 Money Printer 지갑이 롱 익스포저를 축적하고 있음을 보여주면, 벽은 스푸핑보다 방어적(진짜 매수자)일 가능성이 더 높습니다.

설정: 페이드 형태의 북 + 테이커 볼륨을 지배하는 Exit Liquidity 코호트. 얇은 북과 수익성 없는 코호트가 테이커 측을 주도하는 것이 결합된 것은 전형적인 혼잡한 패자 패턴입니다. 반전의 첫 징후는 얇은 유동성을 불균형적으로 빠르게 휩쓸 것입니다.

설정: 스택 북 + 코호트 컨센서스 형성. 북이 건강하고 높은 PnL 코호트가 한 방향으로 수렴할 때, 포지션 크기를 더 공격적으로 할 수 있습니다. 시장은 구조적으로 상당한 영향 없이 당신의 진입을 흡수할 수 있습니다.

이것들은 거래가 아닙니다 — 필터입니다. 오더북 형태만으로는 너무 노이즈가 많습니다. 코호트 포지셔닝만으로는 실행 다이나믹스를 놓칩니다. 조합은 둘 중 어느 것보다 더 선택적이며, 그 뒤의 수학은 스크리닝 함수로 인코딩하기에 간단합니다.

북과 코호트

실용적 고려사항 및 한계

몇 가지 솔직한 주의사항:

오더북 데이터는 높은 빈도입니다. 유용한 오더북 모니터는 몇 초마다 스냅샷을 가져옵니다. 그것은 자산당 분당 많은 요청입니다. 무료 티어 API 접근(일 100 요청)은 실제 모니터링을 유지할 수 없습니다. 진지한 오더북 작업에는 Pulse ($179/월) 이상이 필요합니다.

지연이 중요합니다. REST 스냅샷은 파싱할 때까지 1-3초 오래된 것입니다. 실행 시점 결정의 경우 WebSocket 스트림이 필요합니다. HyperTracker API는 둘 다 포함합니다 — 분석용 REST, 실시간용 WebSocket.

오더북 메트릭은 빠르게 감쇠합니다. 30초 전 스냅샷은 현재 북 형태에 대해 거의 아무것도 말해주지 않습니다. 오래된 데이터로 결정을 내리지 마세요. 전략이 초 이하의 신선도를 요구한다면, 인프라가 이를 지원해야 합니다.

의미 있어 보이는 대부분은 노이즈입니다. 오더북은 끊임없이 펄스하고 변화합니다. 명백한 "패턴"의 대부분은 아무것도 예측하지 못합니다. 행동할 가치가 있는 신호는 여러 스냅샷에 걸쳐 지속되고 다른 독립적인 신호(코호트 포지셔닝, 펀딩 비율, 온체인 플로우)와 일치하는 것들입니다. 단일 스냅샷 리딩은 대부분 오락입니다.

이것이 가능하게 하는 것

Hyperliquid에서 자동화된 시스템을 구축하는 트레이더들에게, 프로그래밍 방식 오더북 접근은 UI에서는 실용적이지 않은 전략 클래스를 열어줍니다:

스프레드 차익거래: 브레이크아웃에 앞서 진입하기 위한 스프레드 압축 모니터링
유동성 인식 실행: 북 형태가 깨끗한 체결을 지원할 때만 시장가 주문 라우팅
안티 스푸핑 필터: 신호 가중치에서 터치 시 철회되는 벽 할인
코호트 조건부 북 리딩: 높은 PnL 트레이더들이 동의하는 설정으로 편향되도록 위의 모든 것을 코호트 포지셔닝을 통해 필터링

이들 중 어느 것도 UI를 통해 도달할 수 없습니다. 모두 API에 대한 몇 백 줄의 Python입니다.

Hyperliquid 오더북 + 코호트 데이터에 대한 프로그래밍 방식 접근 받기 →

더 큰 프레이밍

UI는 캐주얼 관찰을 위해 만들어졌습니다. API는 분석 작업을 위해 만들어졌습니다. 대부분의 개인 트레이더들은 UI를 통해 시장과 상호작용하기 때문에, 대부분의 개인 트레이더들은 같은 패턴을 보고 같은 불완전한 정보로 행동합니다. 오더북 데이터로 의미 있는 작업을 하는 트레이더들은 프로그래밍 방식으로 가져오고, 히스토리로 지속하며, UI가 노출하지 않는 코호트 포지셔닝 같은 구조적 신호와 결합하는 사람들입니다.

정보 우위는 복리로 증가합니다. API를 통해 북을 읽는 매일, 다음 날 패턴을 인식하는 데 도움이 되는 개인 데이터셋을 구축하고 있습니다. 그 데이터셋이 실제 우위입니다. 오더북은 단지 데이터가 사는 곳입니다.