HyperEVM이 진정으로 필요로 하는 앱은?

Key Takeaways

• HyperEVM은 하이퍼코어(HyperCore)의 거래, 담보, 포지션, 리스크를 스마트컨트랙트가 읽고 활용하게 만드는 실행 환경으로 봐야 한다.
• HyperEVM 앱을 볼 때는 두 가지를 먼저 봐야 한다: 1) 왜 EVM이 필요한지, 그리고 2) 왜 하이퍼리퀴드여야 하는지다.
• 스왑, 렌딩, 자산 래퍼 같은 기본적인 앱은 생태계 성장에 필수적이지만, 장기적인 차별화는 하이퍼코어와 컴포저블(composable)한 상품에서 나온다.
• 가장 차별화된 앱은 하나의 잔고로 거래, 차입, 수익 창출, 헤지, 결제까지 이어지는 통합 계좌에 가까운 형태가 될 수 있다.

1. 거래소부터 출범한 체인

대부분의 블록체인은 출범 시 먼저 실행 환경을 만든다. 개발자가 컨트랙트를 배포할 수 있는 인프라를 구축하고, 유동성 인센티브를 제공하고, 생태계 펀드로 팀을 유치한다. 이후 충분한 애플리케이션과 자본이 모이면 체인의 가치와 존재 이유가 증명된다는 접근 방식이다.

하이퍼리퀴드는 범용 체인이 아닌 거래소 인프라부터 만들었다. HyperEVM이 존재하기 전부터 하이퍼코어에는 현물과 무기한 선물 오더북, 사용자 잔고, 담보, 포지션, 청산 로직, 리스크 관리가 존재했으며, 덕분에 HyperEVM을 출시했을 때에는 이미 수많은 트레이더들이 이미 하이퍼리퀴드에서 거래하고 있었다.

따라서 HyperEVM을 일반적인 블록체인으로 보면 핵심을 놓치게 된다. 비록 범용 EVM 실행 환경을 제공하나, 모든 앱을 무차별적으로 수용하는 공간이라는 뜻은 아니다. HyperEVM의 역할은 하이퍼코어의 거래, 담보, 포지션, 리스크를 스마트 컨트랙트가 읽고 활용할 수 있는 대상으로 만드는 데 있다.

필자가 판단하기에 가치 있는 HyperEVM 네이티브 애플리케이션은 다음과 같이 세 가지 조건을 만족한다:

• 하이퍼코어만으로 처리하기 어려운 범용 애플리케이션 로직이 필요하다
• 하이퍼코어와 컴포저블(composable)해야 한다
• 하이퍼리퀴드를 더 유용한 금융 플랫폼으로 만들어야 한다

다르게 말하면, 단순히 EVM 컨트랙트라는 이유만으로는 충분하지 않으며 하이퍼코어의 상태를 읽거나 쓸 때 HyperEVM 네이티브 애플리케이션의 차별성이 생긴다. 구조를 단순화하면 하이퍼코어는 거래소 엔진이고, HyperEVM은 그 주변의 스마트컨트랙트 레이어다. 하이퍼코어에서는 주문이 체결되고, 담보가 관리되며, 포지션과 리스크가 계산된다. HyperEVM에서는 개발자가 일반적인 EVM 컨트랙트처럼 애플리케이션 로직을 작성할 수 있다.

중요한 점은 두 환경이 완전히 분리되어 있지 않다는 것이다. HyperEVM 컨트랙트는 읽기 프리컴파일(read precompiles)을 통해 하이퍼코어내 유저의 잔고, 포지션, 가격, 스테이킹 위임, 볼트 지분 등을 읽을 수 있다. CoreWriter를 사용하면 HyperEVM에서 작성된 로직이 하이퍼코어로 특정 액션을 보낼 수도 있다. 즉, HyperEVM 애플리케이션들은 하이퍼코어 거래소 원장을 직접 참조해 렌딩, 자산운용, 결제, 구조화 상품을 설계할 수 있다는 의미다.

물론 모든 HyperEVM 애플리케이션이 처음부터 복잡한 구조를 가질 필요는 없다. 생태계가 작동하려면 기본적인 금융 인프라부터 필요하다. 가령 사용자는 자산을 교환하고, 담보를 맡기고, 자금을 빌리고, 수익을 얻고, 위험을 헤지할 수 있어야 한다. 다만 HyperEVM의 장기적인 차별화는 기존 디파이 앱을 그대로 가져오는 데서 나오지 않는다. 하이퍼코어의 거래소 상태를 읽고, 필요할 때 하이퍼코어와 직접 상호작용하는 금융 상품을 만드는 데 있다. 신용, 자산운용, 결제, 구조화 상품이 단순한 ERC20 잔고가 아니라 실시간 거래소 상태를 기반으로 설계될 때, HyperEVM은 다른 범용 EVM 체인과 다른 위치에 서게 된다.

이러한 구조는 물론 간단하지 않다. HyperEVM과 하이퍼코어는 하나의 동기식(synchronous) 실행 환경이 아니다. HyperEVM에서 작성된 로직이 CoreWriter를 통해 하이퍼코어로 액션을 보내더라도, 그 과정에는 처리 순서, 지연, 실패 가능성, 두 환경 사이의 상태 조정 문제가 따른다. 따라서 빌더는 실행 실패, 담보 회계, 지연된 반영, 두 환경에 걸친 리스크를 직접 설계해야 한다.

HyperEVM의 설계 공간은 이러한 제약 때문에 좁아진다. 그러나 바로 그 제약을 다룰 수 있는 애플리케이션이 HyperEVM의 차별화를 만든다.

2. 2x2 매트릭스

HyperEVM 위의 애플리케이션을 볼 때 먼저 물어봐야 할 질문은 두 가지다.

• 첫째, 이 애플리케이션은 하이퍼코어만으로는 만들기 어려운 스마트컨트랙트 로직이 필요한가. 예를 들어 사용자 권한 관리, 금리 모델, 볼트 회계, 토큰화, 자동화된 전략, 담보 관리처럼 EVM에서 처리해야 하는 로직이 있는가.
• 둘째, 이 애플리케이션은 하이퍼코어 안에 있는 정보를 실제로 써야 하는가. 사용자 잔고, 포지션, 담보, 가격, 볼트 지분을 읽어야 하는가. 혹은 CoreWriter를 통해 하이퍼코어로 액션을 보내야 하는가.

이 두 질문을 기준으로 보면 HyperEVM 애플리케이션은 아래와 같이 크게 네 가지 영역으로 나눌 수 있다.

해당 매트릭스는 좋고 나쁨을 가르는 표가 아니다. HyperEVM 위에 필요한 앱과, HyperEVM이 아니면 만들기 어려운 앱을 구분하기 위한 간단한 분류 방식에 가깝다.

2.1 로컬 EVM 금융

로컬 EVM 금융(Local EVM finance)은 HyperEVM 생태계가 작동하기 위해 필요한 기본 금융 앱이다. AMM, 머니마켓, CDP, 라우터, 옵션 시장, 레버리지 상품, 수익률 시장이 여기에 속한다. Felix가 대표적인 예시 중 하나다. HyperLend 역시 HyperEVM의 주요 신용 시장으로서 이 영역에서 출발하지만, 일부 기능과 로드맵은 더 깊은 하이퍼코어 연동을 지향한다.

이 영역은 익숙하다는 이유로 과소평가되기 쉽다. 그러나 사용자가 자산을 교환하고, 담보를 맡기고, 빌리고, 빌려주고, 헤지할 수 없다면 생태계는 오래 머물 자본을 만들기 어렵다. 다만 이 앱들의 기본 구조는 다른 EVM 체인에도 비교적 쉽게 옮겨갈 수 있다. 따라서 HyperEVM에 필요하지만, 그 자체만으로 HyperEVM의 장기 차별화를 설명하기는 어렵다.

2.2 하이퍼코어 자산 래퍼

하이퍼코어 자산 래퍼(core native extensions)는 하이퍼코어 안에 있는 자산을 HyperEVM 애플리케이션에서 쓸 수 있는 형태로 바꾸는 영역이다. Kinetiq, StakedHYPE, Kintsu, HLP 래퍼, Unit 연동 자산 및 유사한 상품들이 여기에 속한다. 예를 들어 HYPE가 스테이킹되어 있거나 HLP 안에 묶여 있으면, 그 자체로는 다른 앱에서 담보나 전략 자산으로 쓰기 어렵다. 이를 토큰화하거나 래핑하면 HyperEVM의 머니마켓, 볼트, 전략 상품에서 활용할 수 있다.

해당 영역의 역할은 하이퍼코어 안의 자산을 HyperEVM에서 쓸 수 있게 만드는 것이다. 복잡한 금융 로직을 새로 만드는 영역이라기보다, 하이퍼코어에 이미 존재하는 자산을 다른 앱이 사용할 수 있는 형태로 바꾸는 인프라에 가깝다.

2.3 프로그래머블한 하이퍼코어

프로그래머블한 하이퍼코어는 가장 중요한 영역이다. 여기서는 애플리케이션이 EVM 로직을 필요로 하면서 동시에 하이퍼코어 안의 거래소 정보를 사용한다. ERC20 잔고를 담보로 받는 렌딩 프로토콜을 넘어 사용자의 하이퍼코어 포지션이나 담보 상태를 읽어 신용을 제공하는 렌딩 프로토콜에 가깝다. 기본적인 볼트를 넘어 하이퍼코어 유동성을 이용해 헤지하거나 실행하는 전략 상품에 가깝다. 일반적인 스마트 지갑을 넘어 CoreWriter를 통해 하이퍼코어 액션까지 제어하는 계정에 가깝다.

이 영역에 들어가는 앱은 다른 체인으로 마이그레이션하기가 어렵다. 상품의 핵심이 하이퍼코어 안에 있는 잔고, 포지션, 가격, 담보, 실행 환경에 의존하기 때문이다. 같은 코드를 다른 EVM 체인에 배포하더라도, 하이퍼코어라는 거래소 엔진이 없으면 같은 상품이 되기 어렵다. Rysk는 사용자가 보유한 자산을 기반으로 옵션 수익을 제공한다는 점에서 이 방향에 가깝다. Liminal은 하이퍼리퀴드 기반 전략을 토큰화된 상품으로 패키징한다. Hyperbeat는 하이퍼코어 포지션과 ERC20 컴포저빌리티를 결합한 델타 중립 익스포저를 지향한다.

Derive는 이 매트릭스에서 별도로 봐야 한다. Derive의 HyperEVM 브리지 볼트는 HYPE와 kHYPE를 옵션 및 무기한 선물 거래의 담보로 사용할 수 있게 해준다. 이 점에서 하이퍼리퀴드 자산의 활용도를 높인다. 다만 핵심 거래, 마진, 정산 로직은 Derive 자체 스택 위에 있다. 따라서 하이퍼코어를 직접 프로그래밍하는 네이티브 HyperEVM 앱과는 구분해야 한다.

프로그래머블 하이퍼코어는 아직 성숙한 카테고리라기보다 초기 실험에 가깝다. 따라서 제품의 방향성과 실제 아키텍처는 구분해야 한다. 핵심은 컨트랙트가 자산을 보관하고, 하이퍼코어의 잔고, 포지션, 담보 상태를 읽으며, CoreWriter를 실행 경로의 일부로 사용하는지 여부다. 이 조건을 충족할 때 비로소 HyperEVM 애플리케이션은 하이퍼코어를 단순히 참조하는 수준을 넘어, 하이퍼코어를 프로그래밍하는 구조에 가까워진다.

Valantis Prime은 이러한 방향성을 보여주는 초기 사례 중 하나다. 핵심은 스마트 계정(smart account)인데, 사용자는 HyperEVM 위의 계정을 통해 하이퍼코어에서 실행될 액션을 관리하고, CoreWriter를 통해 권한, 에이전트, 세션 키, 가디언, 액션별 제한을 설정할 수 있다. 즉 계정 자체가 단순한 지갑을 넘어, 하이퍼코어 활동을 제어하는 프로그래밍 가능한 인터페이스가 된다. HyperLend와 Rysk도 각각 신용과 변동성 상품의 관점에서 비슷한 방향을 시도하고 있다. HyperLend는 L1 현물 기반 차입, Liquid HLP, 통합 계정 설계를 통해 하이퍼코어 자산과 신용 시장을 연동하려 한다. Rysk는 온체인 수익 상품과 하이퍼리퀴드 무기한 선물 유동성을 결합하여 사용자가 보유한 자산에서 변동성 수익을 만들려 한다.

결국 HyperEVM에서 중요한 기준은 렌딩인지, 볼트인지, 옵션인지, 스테이킹인지보다 그 상품의 핵심 기능이 하이퍼코어의 잔고, 포지션, 담보, 가격, 실행 환경 없이는 성립하기 어려운가에 있다.

3. 최종 형태는 통합 금융 계좌의 형태를 띨 것

가장 대체하기 어려운 HyperEVM 애플리케이션은 디파이 앱의 형태가 아니라, 하나의 잔고가 여러 금융 기능의 기반으로 쓰이는 통합 금융 계좌에 가까울 가능성이 크다.

여기서 말하는 계좌는 단순한 입출금 계좌가 아니라 사용자가 보유한 자산이 거래, 담보, 차입, 수익 창출, 헤지, 결제까지 이어지는 구조를 의미한다. 사용자는 BTC, ETH, SOL, HYPE 같은 자산을 한 번 예치하고, 같은 잔고를 여러 기능에서 활용할 수 있어야 한다.

예를 들어 한 자산은 하이퍼코어에서 거래에 쓰일 수 있다. 동시에 HyperEVM에서는 차입의 담보가 될 수 있고, 볼트를 통해 수익을 만들 수 있으며, 무기한 선물로 헤지될 수 있고, 필요하면 결제 재원으로도 사용될 수 있다. 사용자가 체감하는 것은 체인, 브리지, 앱, 거래소를 옮겨 다니는 과정이 아니다. 하나의 잔고가 여러 금융 기능 사이에서 계속 활용되는 경험이다.

중앙화 거래소는 이미 이러한 경험의 일부를 제공한다. 하나의 계정 안에서 거래, 마진, 렌딩, 수익 상품을 사용할 수 있기 때문에 사용자 경험은 통합되어 있다. 그러나 그 구조는 닫혀 있다. 원장은 공개되어 있지 않고, 리스크 엔진은 외부에서 검증하기 어렵다. 제3자 개발자가 그 계정을 기반으로 자유롭게 애플리케이션을 만들 수도 없다.

범용 체인은 반대의 문제를 갖고 있다. 사용자가 자산을 직접 통제하고, 누구나 애플리케이션을 만들 수 있다. 그러나 금융 기능은 여러 프로토콜과 거래 환경으로 파편화되어 있다. 거래는 한곳에서, 차입은 다른 곳에서, 수익 상품은 또 다른 곳에서, 헤지는 별도의 파생상품 시장에서 이루어진다. 개방성은 있지만, 금융 경험은 하나로 묶여 있지 않다.

하이퍼리퀴드의 가능성은 이 두 모델의 중간에 있다. 하이퍼코어는 거래소급 유동성, 담보, 포지션, 리스크 인프라를 제공한다. HyperEVM은 외부 개발자가 그 상태를 활용해 애플리케이션을 만들 수 있는 스마트컨트랙트 환경을 제공한다. 이 조합이 제대로 작동하면 중앙화 거래소처럼 통합된 금융 경험을 제공하면서도, 자산 통제와 애플리케이션 접근성은 더 개방된 구조로 가져갈 수 있다. 이것이 하이퍼리퀴드의 “House of All Finance” 비전을 구현한 미래라는 생각이 든다.

검증은 사용자 잔고가 어떻게 쓰이는지에서 나타나야 한다. 담보는 거래, 차입, 저축, 헤지, 결제 사이를 이동할 수 있어야 한다. 리스크는 실시간 하이퍼코어 정보를 바탕으로 계산되어야 한다. 청산 과정 시 하이퍼코어 유동성을 활용해야 하며, 구조화 상품 역시 하이퍼코어 유동성으로 헤지되어야 한다. ERC20은 그냥 래퍼가 아니라 시스템 내부의 렌딩, 볼트, 포트폴리오 마진 활동에 대한 청구권을 표현할 수 있어야 한다.

HyperEVM의 첫 번째 단계는 생태계를 사용할 수 있게 만드는 것이다. 다음 단계는 하이퍼코어를 프로그래밍 가능한 통합 금융 계좌의 기반으로 만드는 것이다.