Hyperliquid가 다시 정의한 금융 실행 앱체인

---

Hyperliquid는 빠르다. 그러나 여기서 볼 것은 속도보다 실행 위치다. 핵심은 주문, 취소, 체결, 포지션, 청산, 펀딩, 수수료 같은 흐름이 어디에서 실행되느냐는 점이다. Hyperliquid는 이 흐름을 범용 스마트컨트랙트 앱 바깥, HyperCore라는 L1의 네이티브 실행 영역에 둔다.

여기서 말하는 성공은 토큰 가격이나 하루짜리 거래량이 아니다. 반복적으로 쓰이는 거래 인프라가 되었고, 사용자가 자산을 직접 보관한 채 CEX에 가까운 경험을 할 수 있게 만들었다는 뜻이다.

처음엔 나도 Hyperliquid를 빠른 perp DEX쯤으로 봤다. 오더북이 있고, 체결이 빠르고, UI가 중앙화 거래소처럼 매끄러운 온체인 선물거래소. 그 인상도 틀리지는 않았다.

하지만 "DEX도 CEX처럼 빠를 수 있다"에서 멈추면 핵심을 놓친다. 이 글이 묻는 질문은 결과가 체인에 기록되느냐가 아니다. 문제는 상태 전이를 누가, 어떤 순서와 규칙으로 결정하느냐다. Hyperliquid는 이 질문을 선명하게 드러낸다.

한눈에 보는 논지

규모가 먼저 설득한다

이 주장이 의미 있으려면 Hyperliquid가 흥미로운 실험을 넘어섰다는 점부터 확인해야 한다.

2026년 5월 6일 KST에 DeFiLlama와 Hyperliquid public API를 조회한 기준으로 보면 다음과 같다.

다만 이 값은 public API 응답을 그대로 더한 참고값이다. DeFiLlama의 reported 또는 normalized derivatives volume, 그리고 HIP-3 deployer DEX까지 포함할 수 있는 별도 OI 집계와는 범위가 다르다. 따라서 이 표의 24시간 notional volume과 open interest는 "현재 기본 perp 시장을 API 응답 기준으로 단순 합산한 참고값"으로 봐야 한다. DeFiLlama의 normalized derivatives volume이나 전체 생태계 OI와 직접 비교할 숫자는 아니다.

숫자는 시점과 집계 방식에 따라 빠르게 바뀐다. 여기서 보려는 것은 49억이냐 50억이냐가 아니다. Hyperliquid가 이제 "재미있는 실험"이라고 부르기 어려운 규모에 도달했다는 점이다. 이미 반복적으로 쓰이는 대형 거래 인프라가 됐다.

기존 거래소 모델과 갈라지는 지점

CEX는 빠르다. Binance, OKX, Coinbase 같은 중앙화 거래소에서는 주문장, matching engine, margin engine, liquidation engine이 모두 거래소 내부 시스템에서 돌아간다. 사용자는 빠른 체결과 깊은 유동성을 얻는다. 대신 주문 처리의 세부 순서, 내부 risk engine, 장애 대응, 자산 보관, 출금 정책은 거래소 운영 경계 안에 남는다.

DeFi 거래소는 다른 방식으로 타협해왔다. AMM은 pool 상태와 가격 함수만으로 거래를 만들기 때문에 온체인 실행에 잘 맞았다. GMX나 Synthetix 계열의 oracle-priced pooled liquidity perp는 주문장 matching을 피하는 대신 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 자체가 항상 consensus state로 commit되는 것은 아니다.

범용 스마트컨트랙트 위에 거래소 로직을 그대로 올릴 수도 있다. 조합 가능성은 좋아지지만, 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로 보호되는 범용 스마트컨트랙트 환경이다.

기록이 아니라 실행을 온체인화한다

Hyperliquid를 빠르다는 말로만 정리하면 핵심을 놓친다. 물론 속도는 중요하다. 공식 문서에 따르면 지리적으로 가까운 클라이언트 기준 요청부터 응답까지의 종단 간 지연시간은 중앙값 0.2초, p99는 0.9초다. 측정 조건은 제한적이지만, CEX에 익숙한 트레이더 경험을 온체인으로 가져오려는 방향은 분명하다.

다만 더 중요한 질문은 그 성능이 어디에서 나오느냐다. 일반적인 스마트컨트랙트 체인에서 모든 주문과 취소를 EVM transaction으로 처리하면 order book 거래소가 원하는 사용자 경험을 만들기 어렵다. 사용자는 주문을 넣고, 취소하고, 다시 넣고, 일부만 체결되기도 한다. 그 사이 포지션과 마진 상태가 바뀌고, 조건이 무너지면 청산이 일어난다. 이 흐름 전체가 거래소의 핵심 루프다.

Hyperliquid는 이 흐름을 EVM 바깥, HyperCore의 금융 실행 엔진에 둔다. 여기서 "onchain"은 Ethereum smart contract 위에서 실행된다는 뜻이 아니다. Hyperliquid L1의 HyperCore state와 HyperBFT consensus 아래에서 거래소 상태 전이가 처리된다는 뜻이다.

이 차이는 기록과 실행을 갈라놓는다. 중앙 서버가 주문 순서와 체결, 포지션, 마진, 청산을 결정하고 최종 결과만 체인에 적는다면, 그것은 온체인 기록 시스템에 가깝다고 보는 편이 맞다. 반대로 이 결정 과정 자체가 합의된 실행 규칙 안에 들어간다면, 그때는 금융 상태 전이가 온체인화된 것이다.

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

프로토콜 실행의 탈중앙성, 검증 가능성, 접근 경로의 탈중앙성도 같은 축이 아니다. Hyperliquid가 보여준 것은 완성된 이상향이라기보다, "거래 결과를 기록하는 것"과 "거래소의 상태 전이를 합의 대상에 올리는 것"이 다르다는 점이다.

HyperEVM은 중심이 아니라 확장면이다

다음 쟁점은 HyperEVM의 위치다.

많은 체인은 EVM을 중심 실행 환경으로 둔다. 애플리케이션은 EVM 컨트랙트로 작성되고, 프로토콜은 그 컨트랙트들의 조합으로 만들어진다. Hyperliquid는 역할을 나눈다. 거래소의 핵심 상태는 HyperCore가 맡고, HyperEVM은 그 상태와 연결되는 범용 스마트컨트랙트 환경이다.

공식 문서는 HyperEVM이 별도 체인이 아니라 HyperCore와 같은 HyperBFT consensus로 보호된다고 설명한다. HyperCore의 유동성과 금융 프리미티브를 허가 없이 쓸 수 있는 구성요소로 열어 두기도 한다. 이 말은 EVM을 버렸다는 뜻이 아니다. EVM이 모든 금융 실행의 중심이어야 한다는 가정에서 벗어났다는 뜻이다.

연결 구조도 따로 봐야 한다. 개발자 문서의 testnet EVM read 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은 아직 단계적으로 열리고 있고, 공식 HyperEVM 문서도 더 높은 처리량 기능과 write system contracts가 메인넷에서 아직 모두 열려 있지 않다고 밝힌다. 반면 개발자 문서는 CoreWriter 주소와 action timing을 별도로 설명한다. CoreWriter로 보내는 order action과 vault transfer는 L1 mempool 우회를 막기 위해 onchain에서 몇 초 지연된다. 그래서 "HyperEVM이 HyperCore를 읽고 쓸 수 있다"는 말은 맞지만, 어떤 기능이 어떤 제약 아래 열려 있는지는 최신 개발자 문서를 봐야 한다.

이 구조를 간단히 쓰면 이렇다.

HyperCore = margin, matching, liquidation 같은 거래소 실행
HyperEVM = 같은 consensus 아래에서 HyperCore 상태를 활용하는 애플리케이션 표면

모든 것을 스마트컨트랙트로 만들 필요는 없다. 반대로 모든 것을 core protocol에 넣는 것도 위험하다. 결국 설계자가 정해야 할 것은 이 구분이다. 어떤 로직은 체인의 핵심 실행 규칙이어야 하고, 어떤 로직은 애플리케이션 레이어에 남아야 하는가.

앱체인의 기준은 실행 경계다

한동안 appchain이라는 말은 조금 막연하게 쓰였다. 앱을 위한 체인, 특정 서비스에 최적화된 체인, 성능 좋은 자체 L1, 브랜딩과 토큰을 가진 독립 네트워크. 대체로 이런 뜻들이 섞여 있었다.

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

거래소라면 주문, 취소, 체결, 포지션, 청산, funding이 핵심 상태가 된다. Hyperliquid는 이 선택을 perp 거래소라는 성능 요구가 높은 영역에서 보여줬다. 앱체인으로서의 Hyperliquid의 의미는 서비스 전용 체인이라는 이름표보다, 어떤 상태 전이를 합의된 실행 규칙 안으로 넣었는지에 있다.

HIP-3는 핵심 루프를 플랫폼화하려는 시도다

HIP-3가 흥미로운 이유는 Hyperliquid가 단일 거래소에 머무르지 않고, 그 실행 스택을 다른 빌더에게 열려는 시도이기 때문이다.

Hyperliquid 문서는 HIP-3를 permissionless builder-deployed perps로 설명하며, perp 상장 과정을 더 탈중앙화하려는 단계라고 말한다. HIP-3 deployer는 market definition, oracle definition, contract specifications, oracle price 설정, leverage limit, 필요할 때 settlement까지 맡는다. 대신 HyperCore의 고성능 margining과 order book stack을 그대로 쓴다.

여기서 permissionless는 무제한 개방을 뜻하지 않는다. HIP-3 mainnet deployer에는 현재 500k HYPE staking requirement가 있다. 이 기준은 인프라가 성숙하면 낮아질 수 있고, 모든 perp를 halt한 뒤에도 30일 동안 유지된다. 현재 각 deployer는 하나의 perp DEX를 배포할 수 있으며, cross margin 활성화에도 별도 eligibility 기준이 붙는다. 각 perp DEX는 독립적인 margining, order book, deployer setting을 가진다. 잘못된 oracle 운영이나 irregular operation에 대해서는 validator vote를 통한 deployer stake slashing도 가능하다. slashed stake는 피해자에게 배분되는 것이 아니라 burn된다.

따라서 HIP-3는 단순히 아무나 아무 시장이나 여는 구조가 아니다. stake가 입장권처럼 붙은 permissionless 구조이고, 시장 운영 책임도 deployer에게 붙는다. 이 지점에서 Hyperliquid는 하나의 perp 거래소를 넘어, 여러 perp 시장과 venue가 올라갈 수 있는 실행 기반이 되려 한다.

시장 생성이 열릴수록 질문도 바뀐다. 누가 oracle을 정하는가. 누가 leverage limit과 margin table을 관리하는가. 문제가 생겼을 때 누가 halt, resume, settlement를 실행하는가. 실행 경계만큼이나 운영 경계도 중요해진다.

그대로 복제할 청사진은 아니다

Hyperliquid의 성공이 의미 있다고 해서 모든 금융 시스템이 같은 구조를 따라야 하는 것은 아니다. 오히려 Hyperliquid는 목적이 선명했기 때문에 강한 설계 선택을 할 수 있었다. perp 거래소라는 비교적 명확한 핵심 루프가 있었고, 그 루프를 위해 L1, consensus, matching state, margin state, HyperEVM 연결 구조를 최적화했다.

다른 거래소나 금융 시스템은 핵심 루프가 다를 수 있다. 빠른 체결보다 법적 책임, 시장 운영자 권한, 장애 대응, 감사 가능성이 더 중요한 경우도 있다. 어떤 시스템은 범용 스마트컨트랙트의 조합 가능성을 더 우선해야 하고, 어떤 시스템은 core protocol에 들어가는 로직을 최소화해야 한다.

그래서 Hyperliquid에서 배울 점은 "모든 거래소를 이렇게 만들자"가 아니다. 금융 시스템을 온체인화하려면 먼저 어떤 상태 전이를 protocol execution으로 올릴지 정해야 한다는 것이다. Hyperliquid는 좋은 참고 사례지만, 그대로 복제할 청사진은 아니다.

리스크는 설계의 일부다

Hyperliquid의 성과를 보려면, 그 성과가 어디서 왔는지뿐 아니라 어떤 위험을 함께 떠안았는지도 봐야 한다. 아래 리스크는 성과를 무효화하지 않지만, 위험이 어디로 이동했는지는 분명히 보여준다.

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

좋은 시스템 설계는 장점만 보는 일이 아니다. 어떤 위험을 줄였고, 어떤 위험을 다른 위치로 옮겼는지도 봐야 한다. Hyperliquid는 성능과 투명성, CEX에 가까운 거래 경험, 금융 core execution을 한 방향으로 강하게 밀어붙였다. 그 결과 실제 사용량과 유동성을 얻었다. 동시에 validator decentralization, bridge safety, oracle trust, API path, market operation responsibility 같은 검증 과제도 남겼다.

결론

Hyperliquid는 거래소의 핵심 상태 전이를 어디에 둘지에 대한 기준을 바꿨다. 기존 DeFi가 주로 범용 스마트컨트랙트 위에서 금융 앱을 만들었다면, Hyperliquid는 주문, 체결, 마진, 청산 같은 실행을 HyperCore로 올리고, 같은 합의 아래의 HyperEVM을 확장면으로 둔다.

온체인 금융의 핵심은 결과를 기록하는 일이 아니라, 상태 전이를 어떤 합의와 규칙 아래 실행할지 정하는 일이다. Hyperliquid의 성공은 이 질문을 다시 앞으로 끌어냈다.

Hyperliquid가 증명한 것은 세 가지다.

첫째, 온체인 금융 UX가 반드시 느릴 필요는 없다.

둘째, 금융의 핵심 루프는 범용 스마트컨트랙트 바깥의 프로토콜 실행 영역으로 올라갈 수 있다.

셋째, EVM은 모든 실행의 중심이 아니라 핵심 금융 상태를 활용하는 확장면일 수도 있다.

그래서 Hyperliquid는 단순히 하나의 성공한 거래소로만 보기 어렵다. 앞으로 금융 체인을 설계할 때 반드시 참고해야 할 사례다.

참고한 문서

• DeFiLlama: Hyperliquid
• Hyperliquid Docs: About Hyperliquid
• Hyperliquid Docs: HyperCore Overview
• Hyperliquid Docs: Order book
• Hyperliquid Docs: Bridge
• Hyperliquid Docs: API servers
• Hyperliquid Docs: Oracle
• Hyperliquid Docs: Robust price indices
• Hyperliquid Docs: HyperEVM
• Hyperliquid Docs: Interacting with HyperCore
• Hyperliquid Docs: Interaction timings
• Hyperliquid Docs: HIP-3 Builder-deployed Perpetuals
• Hyperliquid Docs: HIP-3 Deployer Actions
• Hyperliquid Docs: Delisting
• Hyperliquid Docs: Running a Validator
• Hyperliquid Docs: Risks
• Hyperliquid Docs: Staking
• Hyperliquid Docs: Perpetuals Info Endpoint
• dYdX: v4 Technical Architecture Overview