Hyperliquid 아키텍처 설명: 보안 및 탈중앙화

2025-2026년 Hyperliquid가 중요한 이유

온체인 파생상품은 틈새 DeFi 상품에서 핵심 암호화폐 시장 원시 상품으로 발전했습니다. 2025년 한 해 동안 영구 선물 DEX의 총 거래량이 급격히 증가했으며, 이는 트레이더들이 온체인 투명성과 자체 보관을 포기하지 않으면서 CEX와 같은 실행을 점점 더 원한다는 광범위한 변화를 반영합니다. DefiLlama 기반 영구 선물 DEX 거래량 추세를 요약한 보고서는 이 부문이 얼마나 빠르게 성장했는지를 강조합니다. (cointelegraph.com)

Hyperliquid는 "단순한 선물 앱"이 아니기 때문에 이러한 변화의 중심에 있습니다. Hyperliquid는 온체인 주문장을 매우 높은 처리량으로 실행하도록 설계된 목적 기반 레이어 1이며, HyperEVM을 통해 이 기반을 일반적인 스마트 계약 환경으로 확장했습니다. DefiLlama의 Hyperliquid 대시보드에 따르면, Hyperliquid는 누적 선물 거래량 수조 달러를 달성했으며, 이는 온체인 레버리지 거래의 주요 장소로서의 역할을 강조합니다. (defillama.com)

이 글은 두 가지 질문을 염두에 두고 Hyperliquid의 아키텍처를 분석합니다.

• 온체인 상태를 유지하면서 어떻게 빠른 속도를 낼 수 있을까요?
• 보안과 탈중앙화의 트레이드오프가 여전히 나타나는 부분은 어디일까요?

Hyperliquid를 한눈에 파악하는 다이어그램 (개념 모델)

Hyperliquid는 HyperBFT라는 BFT 스타일 PoS 합의를 실행하는 검증인 세트로 보호되는 단일 블록체인입니다. 실행은 두 도메인으로 나뉩니다.

• HyperCore: 목적 기반 금융 원시 상품 (현물 + 영구 선물 주문장, 증거금, 청산)
• HyperEVM: 동일한 L1 "내부"에 구축된 EVM 실행 환경으로, 동일한 합의 보안을 상속받습니다.

Hyperliquid 자체 문서는 기술 개요에서 이러한 분할을 명확하게 설명합니다. (hyperliquid.gitbook.io)

합의: HyperBFT 및 "BFT 스타일 최종성"의 의미

HyperBFT는 HotStuff 기반 PoS 합의입니다.

Hyperliquid는 블록 생성이 스테이킹 비율에 비례하는 HyperBFT, "HotStuff 합의의 변형"에 의해 보호된다고 명시합니다. HyperCore 개요를 참조하세요. (hyperliquid.gitbook.io)

"HotStuff 계열" 합의가 (부분 동기화 하에서의) 응답성과 효율성을 최적화하는 것이 무엇인지에 대한 학술적 기준을 원한다면, 원본 논문인 HotStuff: BFT Consensus in the Lens of Blockchain을 참조하세요. (arxiv.org)

실질적인 결론: BFT 스타일 PoS (확률적 최종성과 비교)는 주문장 DEX에 매력적입니다. 왜냐하면 트레이더들은 변동성이 큰 시기에 결정론적 순서 및 빠른 최종성을 중요하게 생각하기 때문입니다.

쿼럼, 구금, 검증인 주기

Hyperliquid의 스테이킹 문서는 고전적인 BFT 쿼럼 가정을 강조합니다. 쿼럼은 스테이킹의 2/3 이상이며, 안전성과 라이브 타임은 쿼럼의 스테이킹이 정직하다고 가정합니다. 또한 다음과 같이 설명합니다.

• "라운드"로 진행되는 합의
• 주기적으로 (지속적으로가 아님) 발생하는 검증인 세트 변경
• 성능 저하에 대한 구금 (슬래싱과 구별됨)

스테이킹 (기술 세부 정보)을 참조하세요. (hyperliquid.gitbook.io)

탈중앙화에 중요한 이유: "누가 스테이킹을 보유하고, 누가 검증인을 운영하며, 시간이 지남에 따라 세트가 어떻게 변경되는가?"는 단순히 거버넌스가 아니라 체인의 핵심 보안 모델의 일부입니다.

실행 계층: HyperCore가 일반적인 DEX 설계와 다른 이유

완전한 온체인 주문장 (오프체인 매칭 엔진이 아님)

일반적인 DEX 패턴은 오프체인 주문장 + 온체인 정산 (또는 온체인 AMM)입니다. Hyperliquid는 다르게 포지셔닝합니다. HyperCore는 주문, 취소, 거래 및 청산이 합의에 의해 생성된 단일 일관된 순서로 온체인에서 발생하도록 설계되었습니다.

해당 문서는 HyperCore가 "오프체인 주문장의 지지대에 의존하지 않으며", 증거금 및 매칭 엔진 상태를 온체인에 포함한다고 강조합니다. HyperCore 개요를 참조하세요. (hyperliquid.gitbook.io)

지연 시간 및 처리량 목표

Hyperliquid는 코로케이션된 클라이언트의 매우 짧은 엔드투엔드 지연 시간과 초당 약 20만 건의 주문 수준의 메인넷 처리량을 보고하며, 마찬가지로 HyperCore 개요에서 확인할 수 있습니다. (hyperliquid.gitbook.io)

이것이 핵심 아키텍처적 베팅입니다. 일반적인 체인을 먼저 구축하는 대신, Hyperliquid는 금융 메시지 처리량 (주문, 취소, 청산)에 맞춰 기본 체인을 최적화했습니다.

HyperEVM: "별도의 체인"이 되지 않고 프로그래밍 가능

HyperEVM은 HyperBFT 보안을 상속받습니다.

Hyperliquid는 HyperEVM이 독립적인 네트워크가 아님을 매우 명확하게 밝힙니다. "EVM 블록은 Hyperliquid의 실행의 일부로 구축되며, HyperBFT 합의로부터 모든 보안을 상속받습니다." HyperEVM (개발자 문서)을 참조하세요. (hyperliquid.gitbook.io)

동일한 문서의 주요 운영 세부 정보:

• 메인넷 체인 ID: 999
• EIP-1559 활성화 (블롭 없는 Cancun 하드포크)
• HYPE는 네이티브 가스 토큰입니다.
• 우선 수수료도 소각됩니다 (주목할 만한 설계 선택).

HyperEVM (개발자 문서)을 참조하세요. (hyperliquid.gitbook.io)

이중 블록 아키텍처: 사용자를 위한 작은 블록, 빌더를 위한 큰 블록

HyperEVM은 빠른 확인과 큰 블록 크기 사이에 단일 강제 트레이드오프를 피하기 위해 이중 블록 아키텍처를 사용합니다. Hyperliquid 문서:

• 약 1초마다 200만 가스 한도의 작은 블록
• 약 1분마다 3000만 가스 한도의 큰 블록

이중 블록 아키텍처를 참조하세요. (hyperliquid.gitbook.io)

중요한 이유: 이것은 Hyperliquid가 L1 설계를 실제 거래 + 애플리케이션 요구 사항에 맞게 조정하는 가장 명확한 예 중 하나입니다. 트레이더는 빠른 확인을 원하고, DeFi 빌더는 더 무거운 계약 배포를 위한 공간을 원합니다.

HyperCore와 HyperEVM 간의 자산 이동 방법

Hyperliquid는 도메인 간 전송에 대한 특정 타이밍 규칙을 설명합니다 (Core → EVM은 다음 EVM 블록까지 대기열에 포함, EVM → Core는 EVM 블록 직후 처리). 상호 작용 타이밍을 참조하세요. (hyperliquid.gitbook.io)

또한 Hyperliquid는 HYPE를 HyperEVM으로 이동하기 위한 표준 메커니즘을 제공합니다 (특정 주소로 전송). HyperEVM (개발자 문서)을 참조하세요. (hyperliquid.gitbook.io)

예시 (문서에 명시된 대로):

HyperCore에서 HyperEVM으로 HYPE를 이동하려면:
HYPE를 0x2222222222222222222222222222222222222222로 전송하세요.

보안 모델: 합의에 의해 보호되는 것 vs "애플리케이션 위험"

Hyperliquid 보안을 추론하는 유용한 방법은 다음과 같이 구분하는 것입니다.

• 합의 보안 (HyperBFT 정확성, 쿼럼 가정, 검증인 동작)
• 실행 정확성 (HyperCore 매칭/증거금 로직, HyperEVM EVM 의미론)
• 브리징 및 자산 보관 경로 (자금이 어떻게 들어오고 나가는지, 어떤 계약에 의존하는지)
• 오라클 및 위험 제어 (마크 가격, OI 상한선, 청산 동작)

위험 공개: L1 위험, 오라클 조작, 브리지 위험

Hyperliquid 자체의 위험 페이지에서는 다음을 지적합니다.

• L1 다운타임 위험 (최신 체인, 덜 검증됨)
• 오라클 조작 위험 (검증인이 유지 관리하는 오라클)
• 스마트 계약 / 브리지 위험 (문서에서 브리지 계약에 대한 의존성을 구체적으로 언급)

해당 페이지에서는 또한 미결제 약정 상한선 및 유동성이 낮은 자산에 대해 오라클 가격에서 멀리 떨어진 주문에 대한 제한과 같은 완화 조치를 언급합니다. (hyperliquid.gitbook.io)

보안 피드백 루프로서의 버그 바운티

Hyperliquid는 메인넷 노드/API 문제 및 (테스트넷에서) HyperEVM 상호 작용 표면을 포함하는 공식 버그 바운티 프로그램을 운영합니다. 버그 바운티 프로그램을 참조하세요. (hyperliquid.gitbook.io)

보안 결론: 빠르게 발전하는 DeFi 인프라에서 책임감 있는 정보 공개에 대한 지속적인 인센티브는 선택 사항이 아니라 프로토콜 운영의 일부입니다.

프로토콜 계층의 내장형 다중 서명 (HyperCore)

주목할 만한 설계 선택: HyperCore는 스마트 계약 지갑 패턴을 필요로 하기보다는 기본 다중 서명 작업을 내장된 원시 기능으로 지원합니다. 다중 서명 (HyperCore)을 참조하세요. (hyperliquid.gitbook.io)

사용자 결론: 운영자, LP 또는 고액 트레이더라면 다중 서명을 통해 단일 키 위험을 줄일 수 있습니다. 이는 암호화폐에서 가장 흔한 실패 모드 중 하나입니다.

탈중앙화: Hyperliquid가 강점을 보이는 부분과 여전히 논쟁이 있는 부분

탈중앙화는 단일 지표가 아닙니다. Hyperliquid의 경우 일반적으로 다음과 같이 귀결됩니다.

• 검증인 독립성 및 스테이킹 분포
• 코드 투명성 (오픈 소스 vs. 비공개 구성 요소)
• 거버넌스 및 비상 권한 (실제로 검증인이 무엇을 할 수 있는가?)

"비공개 노드" 및 스테이킹 집중 논쟁 (2025년)

2025년 초, Hyperliquid는 검증인의 공정성, 스테이킹 집중, 당시 노드 코드가 완전히 오픈 소스되지 않았다는 사실 등을 포함한 탈중앙화 관련 공개 조사를 받았습니다. CoinDesk는 Hyperliquid의 응답을 보도했으며, 여기에는 탈중앙화 강화 계획과 위임 프로그램에 대한 언급이 포함되었습니다. CoinDesk 보도를 참조하세요. (coindesk.com)

아키텍처적으로 중요한 이유: HotStuff 스타일 PoS 체인은 기술적으로 견고할 수 있지만, 탈중앙화 인식은 검증인이 독립적으로 (최소한의 "게이트키핑"으로 노드 소프트웨어를 검토 및 실행하는 것을 포함하여) 운영될 수 있는지 여부에 크게 영향을 받습니다.

실제 스트레스 테스트로서의 검증인 개입

높은 인지도를 가진 시장 사고 이후, 검증인이 선물 시장을 상장 폐지하고 포지션을 강제로 청산했을 때 별도의 탈중앙화 논의가 발생했으며, 이는 극단적인 상황에서 "중단 없는" 시장의 한계에 대한 의문을 제기했습니다. Blockworks는 이 사건을 설명하고 탈중앙화 제약을 드러낸 것으로 프레임했습니다. Blockworks 분석을 참조하세요. (blockworks.co)

이는 온체인 파생상품의 핵심 긴장 관계를 강조합니다.

• 트레이더는 조작 시도 중에 강력한 위험 관리를 요구합니다.
• DeFi 사용자는 신뢰할 수 있는 중립성과 예측 가능한 규칙을 기대합니다.

건전한 탈중앙화 질문: 비상 조치는 규칙 기반, 투명하며 명확한 정당성으로 통제되는가, 아니면 즉흥적인가? 답은 사용자가 시스템을 불변의 인프라로 취급하는지, 아니면 관리되는 장소로 취급하는지에 영향을 미칩니다.

"보안 + UX"는 온체인 선물 거래의 새로운 격전지

2025년, 온체인 선물 거래량은 사상 최고치를 기록했으며 거래소 간 경쟁이 치열해졌습니다. 시장 구조는 다음과 같은 방향으로 변화하고 있습니다.

• 더 나은 실행 지연 시간
• 더 깊은 유동성
• 더 명확한 위험 제어
• 보관 및 접근에 대한 더 강력한 보증

이것이 Hyperliquid의 아키텍처가 중요한 이유입니다. "추가한" 것이 아니라 고성능 거래를 일등석 L1 기능으로 만들기 위한 시도입니다.

사용자 (트레이더, LP, 빌더)를 위한 실용적인 체크리스트

1) 핵심 보안을 거래 우위의 일부로 취급하십시오.

키를 보호할 수 없다면 성능 향상의 이점은 의미가 없습니다. Hyperliquid 자체 지원 문서는 피싱 인식 및 공식 URL 확인을 강조합니다. 지원 가이드를 참조하세요. (hyperliquid.gitbook.io)

2) 다중 서명 (또는 최소한 역할 분할)을 사용하십시오.

팀의 경우 다음을 분리하는 것을 고려하십시오.

• 거래 운영자 키
• 재무 보관 키
• 계약 배포/관리자 키 (HyperEVM에서 구축하는 경우)

HyperCore의 내장 다중 서명은 이를 위한 유용한 기본 기능입니다. 다중 서명 (HyperCore)을 참조하세요. (hyperliquid.gitbook.io)

3) 레버리지를 사용하기 전에 오라클 및 유동성 위험을 이해하십시오.

프로토콜 자체의 위험 페이지를 읽고 이를 필수 사전 거래 실사로 취급하고 법률 문구로 간주하지 마십시오. (hyperliquid.gitbook.io)

OneKey의 역할 (온체인 속도에 맞는 자체 보관)

Hyperliquid의 발전 (특히 HyperEVM)은 간단한 추세를 강화합니다. 더 심각한 거래 및 DeFi 활동이 온체인으로 이동하고 있으며, 이는 안전한 거래 서명 및 운영 안전성을 더 중요하게 만듭니다.

OneKey와 같은 하드웨어 지갑은 해당 보안 스택에서 실용적인 계층이 될 수 있습니다.

• 개인 키를 일상적인 장치에서 격리하십시오.
• 빈번한 DeFi 활동 중 피싱 및 멀웨어의 영향을 받는 범위를 줄이십시오.
• 다중 계정 운영 설정 (거래 vs. 재무 분리)과 잘 어울립니다.

목표는 사용자를 늦추는 것이 아니라 실제 위협 모델 하에서 "빠른 온체인 금융"이 생존 가능하도록 만드는 것입니다.

최종 생각: Hyperliquid의 아키텍처는 통합된 온체인 금융에 대한 베팅입니다.

Hyperliquid의 설계는 일관됩니다. 지연 시간에 최적화된 HotStuff 기반 BFT PoS 합의, 전문화된 금융 실행 엔진 (HyperCore), 그리고 기본 체인의 성능 프로필을 포기하지 않으면서 구성 가능성을 제공하려는 긴밀하게 통합된 EVM 환경 (HyperEVM)입니다. HyperCore + HyperEVM을 단일 통합 시스템으로 설명하는 문서는 전체 스택을 이해하는 열쇠입니다. Hyperliquid 정보를 참조하세요. (hyperliquid.gitbook.io)

동시에, 2026년 Hyperliquid에 대한 가장 중요한 대화는 광범위한 DeFi 인프라를 정의하는 대화와 동일할 가능성이 높습니다.

• 사용량이 증가함에 따라 탈중앙화가 어떻게 발전하는가
• 검증인 권한이 얼마나 투명하고 규칙에 구속되는가
• 보안 프로세스 (바운티, 감사, 사고 대응)가 성장에 얼마나 잘 따라가는가