Blockchain

Hyperliquid의 성공이 가지는 의미

Hyperliquid의 성공은 "탈중앙 거래소도 빠를 수 있다"를 보여준 사건만은 아닙니다. 더 중요한 의미는 거래소의 핵심 상태 전이를 어디에서 실행할 것인가에 대한 새로운 답을 제시했다는 데 있습니다.

발행 2026년 5월 6일12분2,373자

#Blockchain #Hyperliquid #DeFi

같은 주제에서 이어 읽기

"단순 해시 검증"의 한계와 데이터 가용성 문제

Blockchain 안에서 이어지는 글

이어서 읽기 토론 보기

처음 Hyperliquid를 봤을 때는 그냥 빠른 perp DEX라고 생각했다. 오더북이 있고, 체결이 빠르고, UI가 중앙화 거래소처럼 매끄럽고, 수수료와 유동성도 괜찮은 온체인 선물거래소 정도로 보였다.

그런데 계속 들여다볼수록 핵심은 속도만이 아니었다.

Hyperliquid가 흥미로운 이유는 "탈중앙화 거래소도 빠를 수 있다"를 보여줬기 때문만은 아니다. 더 중요한 점은 거래소의 핵심 상태 전이, 즉 주문, 취소, 체결, 포지션, 청산, 펀딩, 수수료 같은 로직을 일반적인 스마트컨트랙트 애플리케이션이 아니라 Hyperliquid L1의 HyperCore execution state에 가깝게 올렸다는 데 있다.

지갑 UX를 조사할 때 중요하게 봤던 것은 권한 경계였다. 누가 사용자의 approval을 만들 수 있고, 누가 recovery나 delegation 경로를 우회할 수 있는가가 핵심이었다. Hyperliquid를 보면서 비슷하게 든 생각은 실행 경계였다. 금융 시스템에서 중요한 질문은 "결과가 체인에 기록되는가"가 아니라, "상태 전이를 누가, 어디서, 어떤 규칙으로 결정하는가"에 더 가깝다.

성공을 먼저 인정해야 한다

Hyperliquid를 평가하려면 먼저 이미 큰 성공이라는 점을 인정해야 한다.

2026년 5월 6일 KST에 DeFiLlama의 Hyperliquid 프로토콜 데이터를 조회했을 때, combined TVL은 약 48.9억 달러였다. 같은 조회에서 누적 fees는 약 12.5억 달러, 누적 revenue는 약 11.3억 달러 수준으로 잡혔다.

거래 규모도 이미 작지 않다. 같은 날 Hyperliquid public API의 metaAndAssetCtxs를 별도로 조회해 230개 perps 시장의 dayNtlVlm을 단순 합산하면 24시간 notional volume은 약 44.8억 달러였다. openInterest * markPx를 단순 합산한 open interest는 약 65.6억 달러였다. 이 둘은 DeFiLlama의 reported 또는 normalized derivatives volume과 같은 집계가 아니라, 글 작성 시점에 public API 응답을 기반으로 계산한 참고값이다.

이 숫자는 시점과 집계 방식에 따라 빠르게 달라진다. 그래서 특정 숫자 하나보다 더 중요한 것은 규모의 질감이다. Hyperliquid는 이제 "재미있는 실험"이라고 부르기 어렵다. 이미 트레이더가 반복적으로 사용하는 대형 거래 인프라다.

이 성공은 몇 가지 질문을 다시 던지게 만든다.

온체인 금융은 꼭 범용 스마트컨트랙트 위에서만 만들어져야 하는가?

거래소 core logic은 애플리케이션 레이어에 있어야 하는가,
아니면 체인의 실행 규칙에 더 가까워져야 하는가?

EVM은 모든 것을 실행하는 중심이어야 하는가,
아니면 core financial state에 접근하는 composability layer여도 되는가?

Hyperliquid의 의미는 이 질문들 안에 있다.

기존 DeFi 거래소 모델과 다른 점

기존 DeFi 거래소를 단순화하면 대략 몇 가지 모델이 있었다.

첫째는 AMM이다. Uniswap, Curve처럼 liquidity pool이 있고, 가격은 pool의 상태와 수식에 의해 결정된다. 이 모델은 온체인에 잘 맞았다. 모든 주문을 직접 matching하지 않아도 되고, LP 자본과 가격 함수만 있으면 거래가 가능하기 때문이다.

둘째는 oracle-priced pooled liquidity 기반 perp다. GMX나 Synthetix 계열처럼 LP 또는 debt pool이 거래 상대가 되고, 가격은 외부 oracle과 내부 risk parameter에 의해 결정된다. 이 모델은 주문장 matching을 피하면서 파생상품 UX를 만들 수 있지만, oracle, pool risk, skew, funding, open interest cap 같은 설계가 핵심이 된다.

셋째는 off-chain order book과 on-chain settlement의 조합이다. 주문 제출과 매칭은 오프체인에서 처리하고, 최종 결과만 온체인에서 정산한다. 성능은 좋아지지만, matching engine의 투명성, 주문 순서, 검열 가능성, 운영자 권한 같은 문제가 남는다. dYdX v4처럼 validator가 in-memory order book을 유지하는 구조도 이 축 위에서 비교할 수 있다. 차이는 order book 자체가 합의 상태로 commit되는지, 아니면 validator 로컬 메모리에서 matching을 돕는 실행 경로인지에 있다.

넷째는 범용 스마트컨트랙트 위에 거래소 로직을 올리는 방식이다. 이 방식은 composability가 좋지만, 고빈도 주문, 취소, 체결, 청산이 필요한 order book 기반 파생상품 거래소에는 비용과 지연 문제가 커진다.

Hyperliquid는 이 모델들과 조금 다르다.

Hyperliquid 문서는 state execution이 HyperCore와 HyperEVM으로 나뉘며, HyperCore가 fully onchain perpetual futures와 spot order book을 포함한다고 설명한다. 또한 order, cancel, trade, liquidation이 HyperBFT에서 상속되는 one-block finality로 투명하게 처리되고, HyperCore는 현재 약 200k orders/sec를 지원한다고 설명한다.

즉 Hyperliquid는 "EVM 위에 perp DEX 컨트랙트를 올린 것"이라기보다, 거래소의 핵심 실행 상태를 HyperCore라는 전용 실행 영역에 둔 구조에 가깝다. HyperEVM은 별도 체인이나 단순 부가 기능이 아니라, 같은 HyperBFT consensus로 보호되는 범용 스마트컨트랙트 실행 환경이다.

이 차이가 중요하다.

핵심은 속도가 아니라 core logic의 위치다

Hyperliquid의 성공을 "빠르다"로만 이해하면 반만 본 것이다.

물론 속도는 중요하다. Hyperliquid 문서는 geographically co-located client에서 request를 보낸 뒤 committed response를 받기까지의 end-to-end latency가 median 0.2초, p99 0.9초라고 설명한다. mainnet은 약 200k orders/sec를 지원한다고도 말한다. 이 수치는 공식 문서의 측정 조건 안에서 읽어야 하지만, 자동화 전략이나 CEX에 익숙한 트레이더 경험을 온체인 환경으로 끌어오는 데 중요한 방향을 보여준다.

하지만 더 중요한 것은 이 성능이 어디에서 나오느냐다.

일반적인 스마트컨트랙트 체인에서 모든 주문과 취소를 EVM transaction으로 처리하면 order book 거래소가 원하는 사용자 경험을 만들기 어렵다. 사용자는 주문을 넣고, 취소하고, 다시 넣고, 부분 체결되고, 포지션이 변하고, 마진 상태가 바뀌고, 필요하면 청산된다. 이 모든 것이 거래소의 core loop다.

Hyperliquid는 이 loop를 EVM 바깥, HyperCore 안의 금융 실행 엔진에 가깝게 둔다. 여기서 "onchain"은 Ethereum smart contract 위에서 실행된다는 뜻이 아니라, Hyperliquid L1의 HyperCore execution state와 HyperBFT consensus 아래에서 처리된다는 뜻에 가깝다.

이렇게 보면 Hyperliquid의 본질은 "빠른 DEX"보다 "거래소 상태 전이를 HyperCore의 native execution component로 만든 L1"에 가깝다.

기존 관점:
거래소 앱이 체인 위에 올라간다.

Hyperliquid식 관점:
거래소의 핵심 상태 전이가 체인의 실행 규칙이 된다.

이 관점 전환이 Hyperliquid의 가장 큰 의미라고 생각한다.

기록하는 것과 실행하는 것은 다르다

블록체인 금융을 이야기할 때 종종 "온체인 기록"이라는 말을 쓴다. 하지만 금융 시스템에서 정말 중요한 것은 기록 그 자체가 아니다.

중요한 것은 상태 전이다.

주문이 들어왔는가.
어떤 순서로 처리됐는가.
누구의 주문과 체결됐는가.
포지션은 어떻게 바뀌었는가.
마진은 충분한가.
청산은 어떤 가격과 규칙으로 발생했는가.
수수료와 funding은 어떻게 정산됐는가.

이것들이 거래소의 핵심이다.

만약 이 결정은 중앙 서버가 하고, 최종 결과만 체인에 적는다면 그것은 온체인 기록 시스템에 가깝다. 반대로 이 결정 과정 자체가 합의된 실행 규칙 안에 들어간다면 그때는 금융 상태 전이가 온체인화된 것이다.

Hyperliquid가 보여준 것은 후자에 가깝다.

다만 합의된 순서가 있다는 것이 곧 모든 주문 처리의 공정성을 보장한다는 뜻은 아니다. Hyperliquid order book 문서는 주문이 price-time priority로 matching된다고 설명하면서도, 한 block 안에서는 action category별 정렬이 있고 category 안에서는 block proposer가 제안한 순서를 따른다고 설명한다. 즉 consensus는 하나의 일관된 순서를 만들지만, proposer ordering, API path, node access가 만드는 실행 표면은 별도의 검토 대상이다.

물론 Hyperliquid가 모든 면에서 완전한 탈중앙 금융 시스템이라는 뜻도 아니다. 프로토콜 실행의 탈중앙성, 검증 가능성, 접근 경로의 탈중앙성은 서로 다른 축이다. 하지만 적어도 "거래 결과를 기록하는 것"과 "거래소의 상태 전이를 합의 대상에 올리는 것"이 다르다는 점을 매우 선명하게 보여줬다.

HyperEVM은 중심이라기보다 확장면에 가깝다

Hyperliquid에서 또 흥미로운 부분은 HyperEVM의 위치다.

많은 체인은 EVM을 중심 실행 환경으로 둔다. 애플리케이션은 EVM 컨트랙트로 작성되고, 프로토콜은 그 컨트랙트들의 조합으로 만들어진다.

Hyperliquid는 조금 다르다.

HyperCore가 거래소의 핵심 상태를 담당하고, HyperEVM은 그 상태와 연결되는 범용 스마트컨트랙트 환경에 가깝다. Hyperliquid 문서는 HyperEVM이 별도 체인이 아니라 HyperCore와 같은 HyperBFT consensus로 보호된다고 설명한다. 또한 Ethereum이 개척한 general-purpose smart contract platform을 Hyperliquid blockchain으로 가져오며, HyperCore의 liquidity와 financial primitives를 permissionless building block으로 사용할 수 있게 한다고 설명한다.

또 HyperEVM은 HyperCore 정보를 읽기 위한 precompile을 제공한다. 문서에 따르면 EVM에서 perps positions, spot balances, vault equity, staking delegations, oracle prices, L1 block number 같은 HyperCore 정보를 query할 수 있고, 이 값들은 EVM block이 구성되는 시점의 최신 HyperCore state와 일치하도록 보장된다. 개발자 문서에는 HyperEVM에서 HyperCore로 action을 보내기 위한 CoreWriter system contract도 설명되어 있다.

다만 이 지점은 구현 상태를 계속 확인해야 한다. HyperEVM은 점진적으로 출시되는 alpha stage이고, 공식 문서는 higher throughput과 write system contracts가 mainnet에 아직 완전히 live된 것은 아니라고 설명한다. 그래서 HyperEVM을 "이미 모든 금융 실행을 자유롭게 제어하는 완성된 확장면"으로 읽기보다는, HyperCore의 금융 상태를 범용 애플리케이션이 활용하도록 열어가는 방향으로 보는 편이 정확하다.

이 구조는 꽤 중요하다.

Hyperliquid는 EVM을 버린 것이 아니다. 다만 EVM만으로 모든 금융 실행을 처리해야 한다는 가정을 버린 것에 가깝다.

HyperCore = margin / matching engine state와 거래소 실행
HyperEVM = 같은 consensus 아래의 composability, application, extension surface

이 구분은 다른 금융 체인을 설계할 때도 참고할 만하다.

모든 것을 스마트컨트랙트로 만들 필요는 없다. 반대로 모든 것을 core protocol에 넣는 것도 위험하다. 중요한 것은 어떤 로직이 체인의 핵심 실행 규칙이어야 하고, 어떤 로직이 애플리케이션 레이어에 남아야 하는지를 나누는 일이다.

앱체인의 의미가 다시 선명해졌다

한동안 appchain이라는 말은 조금 막연했다.

앱을 위한 체인. 특정 서비스에 최적화된 체인. 성능 좋은 자체 L1. 브랜딩과 토큰을 가진 독립 네트워크.

이 정도로 쓰이는 경우가 많았다.

Hyperliquid는 appchain의 의미를 더 선명하게 만든다. 앱체인은 단순히 "앱이 자기 체인을 갖는 것"이 아니다. 적어도 이 글에서 말하는 강한 의미의 appchain은 특정 애플리케이션의 핵심 상태 전이를 체인의 실행 모델로 끌어올리는 것이다.

거래소라면 주문, 취소, 체결, 포지션, 청산, funding이 core state가 된다. 게임이라면 캐릭터 상태, 아이템 이동, 전투 판정, 경제 시스템이 core state가 될 수 있다. 증권형 토큰 체인이라면 주문, 배정, 결제, 권리, 제한, 잔고, corporate action이 core state가 될 수 있다.

이렇게 보면 appchain은 단순한 성능 최적화가 아니다.

어떤 상태 전이를 애플리케이션 서버가 아니라
합의된 실행 규칙의 일부로 만들 것인가

이 질문에 대한 답이다.

Hyperliquid는 이 답을 perp 거래소라는 성능 요구가 높은 영역에서 보여줬다.

HIP-3가 보여주는 다음 단계

Hyperliquid가 더 흥미로운 이유는 core 거래소 하나에서 멈추지 않고, 그 core를 다른 builder들이 사용할 수 있는 방향으로 확장하고 있다는 점이다.

HIP-3는 builder-deployed perpetuals를 지원하는 제안이다. Hyperliquid 문서는 HIP-3를 permissionless builder-deployed perps로 설명하며, 이는 perp listing process를 더 탈중앙화하기 위한 milestone이라고 말한다. HIP-3 deployer는 market definition, oracle definition, contract specifications, oracle price 설정, leverage limit, 필요 시 settlement 같은 market operation을 책임진다. 또한 HIP-3는 HyperCore의 high performance margining과 order book stack을 상속한다.

다만 여기서 permissionless는 아무 제약이 없다는 뜻이 아니다. HIP-3 mainnet deployer에는 500k HYPE staking requirement가 있고, 각 perp DEX는 독립적인 margining, order book, deployer setting을 가진다. 잘못된 oracle 운영이나 irregular operation에 대해서는 validator vote를 통한 deployer stake slashing도 가능하다. 즉 HIP-3는 개방형이지만 stake-gated이고, 시장 운영 책임이 deployer에게 붙는 구조다.

이건 Hyperliquid가 단일 거래소 앱에서 금융 인프라 플랫폼으로 넘어가려는 지점이다.

처음에는 Hyperliquid 팀이 만든 perp venue가 중요했다. 그 다음에는 HyperCore의 liquidity와 matching/margining infrastructure를 다른 builder가 사용할 수 있는지가 중요해진다.

이 방향이 성공하면 Hyperliquid는 단순히 하나의 거래소가 아니라, 여러 perp 시장과 venue가 올라가는 execution substrate가 된다.

여기서 다시 중요한 질문이 생긴다.

누가 시장을 만들 수 있는가?
누가 oracle을 정하는가?
누가 leverage limit을 정하는가?
문제가 생겼을 때 누가 settlement를 실행하는가?

시장 생성이 permissionless해질수록, 실행 경계뿐 아니라 운영 경계도 중요해진다.

그대로 따라 하면 안 되는 이유

Hyperliquid의 성공이 의미 있다고 해서, 모든 금융 시스템이 Hyperliquid를 그대로 따라 해야 한다는 뜻은 아니다.

오히려 반대다. Hyperliquid는 목적이 매우 선명했기 때문에 강한 설계 선택을 할 수 있었다. perp 거래소라는 단일하고 명확한 core loop가 있었고, 그 core loop를 위해 L1, consensus, matching state, margin state, HyperEVM 연결 구조를 최적화했다.

하지만 다른 금융 시스템은 조건이 다를 수 있다.

예를 들어 증권형 토큰이나 기관 컨소시엄 체인을 생각하면 문제가 달라진다. 거기서는 빠른 체결만 중요한 것이 아니다. 참여 기관의 권한 분리, 내부통제, 주문 책임, 규제 보고, 투자자 자격, transfer restriction, corporate action, 장애 대응, 감사 가능성이 함께 중요하다.

Hyperliquid의 구조에서 배울 점은 "거래소를 이렇게 만들자"가 아니다. 더 정확한 교훈은 이것이다.

금융 시스템을 온체인화하려면
어떤 상태 전이를 protocol execution으로 올릴지 먼저 정해야 한다.

증권 시스템이라면 단순히 증권사 내부 DB의 결과를 체인에 적는 것만으로는 충분하지 않을 수 있다. 주문 접수, 주문 순서, 체결, 배정, 결제, 잔고 변경, 권리 발생이 어떤 규칙으로 결정되는지까지 체인의 실행 모델 안에서 다룰 수 있어야 한다.

하지만 그 과정에서 모든 것을 무조건 탈중앙화한다는 말도 조심해야 한다. 기관 금융에서는 권한 있는 주체가 필요할 때가 있고, 법적 책임을 지는 운영자가 필요할 때도 있다. 따라서 중요한 것은 "운영자가 없는 시스템"이 아니라, "운영자의 권한이 어디까지인지 명확히 검증 가능한 시스템"일 수 있다.

이 점에서 Hyperliquid는 좋은 참고 사례지만, 그대로 복제할 청사진은 아니다.

리스크도 성공의 일부로 봐야 한다

Hyperliquid의 성공을 말할 때 리스크를 빼면 안 된다.

Hyperliquid 공식 문서도 Arbitrum에 배포된 Hyperliquid bridge contract에 대한 의존, 자체 L1이 Ethereum 같은 성숙한 L1만큼 오래 검증되지 않았다는 점, liquidity risk, validator가 유지하는 oracle의 조작 가능성 등을 위험 요소로 명시한다. 특히 oracle이 장시간 compromised되거나 manipulated되면 mark price와 liquidation에 영향을 줄 수 있다고 설명한다.

Bridge risk는 조금 더 구체적으로 볼 필요가 있다. Hyperliquid bridge의 deposit과 withdrawal은 staking power의 2/3 초과 서명에 의존하고, withdrawal에는 dispute period가 있다. 악의적 withdrawal로 bridge가 lock되면 stake-weighted validator set의 2/3 cold wallet signature가 unlock에 필요하다고 문서는 설명한다. 이는 "사용자가 서명한다"는 self-custody UX와 별개로, 출금 가능성과 bridge safety가 validator quorum 및 bridge contract correctness에 의존한다는 뜻이다.

또 Hyperliquid는 delegated proof of stake 구조를 사용한다. 문서에 따르면 HYPE는 validator에 stake 또는 delegate될 수 있고, HyperBFT에서 quorum은 전체 stake의 2/3 초과를 의미한다. consensus의 운영 조건은 quorum stake가 honest하다는 가정에 의존한다. Staking 문서는 현재 automatic slashing이 구현되어 있지 않다고도 설명한다. HIP-3 deployer slashing과 일반 validator staking의 risk model은 구분해서 봐야 한다.

Oracle risk도 구체적인 신뢰 가정으로 봐야 한다. Hyperliquid의 validator는 perp asset의 spot oracle price를 3초마다 publish하고, clearinghouse가 사용하는 최종 oracle price는 validator 제출값의 stake-weighted median으로 계산된다. 이 oracle은 funding, mark price, margining, liquidation, TP/SL trigger에 영향을 준다. 그러므로 oracle risk는 외부 가격 피드 하나의 문제가 아니라, validator-maintained oracle과 stake-weighted aggregation을 신뢰하는 문제에 가깝다.

접근 경로도 별도 리스크다. 공식 API server는 node 업데이트를 듣고 state를 로컬에 유지하며, 사용자 transaction을 연결된 node로 forward한 뒤 L1 committed block에 포함되면 실행 결과를 돌려준다. Node 운영 자체는 열려 있더라도 많은 사용자는 공식 frontend와 API path에 의존한다. 이는 consensus trust와 별개인 가용성, 검열 가능성, 지연, 사용자 경험의 신뢰 경계다.

이런 리스크는 Hyperliquid의 성과를 무효화하지 않는다. 다만 성공을 더 정확히 해석하게 만든다.

Hyperliquid는 완성된 이상향이라기보다, 성능과 투명성, self-custodial signing, 금융 core execution을 한 방향으로 강하게 밀어붙인 사례다. 그 결과로 실제 사용량과 유동성을 얻었다. 동시에 그 선택은 validator decentralization, bridge risk, oracle trust, API path, market operation responsibility 같은 새로운 검증 과제를 남긴다.

좋은 시스템 설계는 장점만 보는 것이 아니라, 어떤 위험을 어떤 위치로 이동시켰는지 보는 일이다.

Hyperliquid가 증명한 것

내가 보기에 Hyperliquid의 성공이 증명한 것은 네 가지다.

첫째, 온체인 금융 UX가 반드시 느릴 필요는 없다. 사용자가 체감하는 거래 경험이 CEX에 가까워질 수 있다면, self-custodial signing과 onchain execution transparency가 꼭 사용성을 크게 희생해야 하는 것은 아니다.

둘째, 모든 금융 로직을 범용 스마트컨트랙트에 넣을 필요는 없다. 주문, 체결, 마진, 청산처럼 시스템 전체의 coherence가 중요한 로직은 HyperCore 같은 native execution component에 두는 편이 더 자연스러울 수 있다.

셋째, EVM은 중심 실행 환경이 아니라 확장면일 수도 있다. EVM은 여전히 중요하지만, 모든 것을 EVM 안에서 직접 실행해야 하는 것은 아니다. HyperCore 같은 전용 금융 상태와 HyperEVM 같은 composability layer가 공존할 수 있다.

넷째, 온체인화의 의미는 기록이 아니라 실행이다. 거래 결과를 체인에 적는 것과, 거래소의 상태 전이를 체인의 합의된 실행 규칙으로 만드는 것은 다르다.

이 네 가지가 Hyperliquid의 성공이 가지는 가장 큰 의미라고 생각한다.

결론

Hyperliquid는 그냥 빠른 perp DEX가 아니다.

Hyperliquid의 성공은 금융 애플리케이션의 핵심 실행 로직을 어디에 둘 것인가에 대한 강한 사례다. 기존 DeFi가 주로 범용 스마트컨트랙트 위에서 금융 앱을 만들었다면, Hyperliquid는 거래소의 core loop를 HyperCore 실행 영역에 가깝게 올리고, 같은 consensus 아래의 HyperEVM을 확장면으로 둔다.

이 구조가 모든 문제의 답은 아니다. 하지만 적어도 하나는 분명히 보여줬다.

온체인 금융의 본질은
금융 결과를 체인에 기록하는 것이 아니라,
금융 상태 전이를 어떤 규칙과 합의 아래 실행할 것인가에 있다.

Hyperliquid의 성공은 이 질문을 다시 앞으로 끌어냈다.

그래서 Hyperliquid는 단순히 하나의 성공한 거래소가 아니라, 앞으로 금융 체인을 설계할 때 반드시 참고해야 할 사례라고 생각한다.

참고한 문서

다음 읽기

이 생각이 이어지는 방향

Blockchain 더 보기