빌더 코드가 본전을 뽑을 때, 그리고 그렇지 않을 때

2026년 7월 기준 수치, HyperTracker 빌더 리더보드 데이터.

Hyperliquid의 빌더 코드 프로그램은 출시 이후 1,411명의 빌더에게 총 9,000만 달러 이상을 지급했다. Phantom 혼자 2,360만 달러를 가져갔다. 이런 헤드라인을 보면 소수의 유저라도 보유한 지갑 앱이나 트레이딩 앱이라면 통합이 당연한 선택처럼 느껴진다.

하지만 상위 5위권을 넘어서면 그림이 달라진다. 빌더 한 명당 평생 수익 평균은 약 64,000달러다. 중앙값은 거의 확실히 더 낮다. 소수의 대형 통합 업체들이 평균을 크게 끌어올리기 때문이다. 엔지니어링 시간을 통합에 투자할지 저울질하는 지갑 팀 입장에서 진짜 질문은 "Phantom은 얼마를 버나?"가 아니다. "우리 유저 수, 우리 볼륨, 우리 유저의 수수료 허용 범위를 고려하면 우리는 얼마를 벌 수 있나?"다.

이 글은 빌더 코드 수익성을 결정하는 세 가지 변수, 손익분기점 계산, 그리고 통합이 타당한 시나리오와 그렇지 않은 시나리오를 다루는 의사결정 프레임워크를 정리한다.

모든 것을 결정하는 세 가지 변수

빌더 코드 수익은 간단한 공식으로 요약된다.

월 수익 = 앱 경유 일일 볼륨 x 수수료율 x 30

입력값은 셋이다. 각각이 중요하고, 서로 예상치 못한 방식으로 상호작용한다. 설정하는 수수료율은 파워 유저의 이탈 여부에 영향을 주고, 그것이 볼륨에 영향을 주며, 결국 전체 구축이 가치 있었는지를 결정한다.

1. 볼륨: 조작할 수 없는 변수

앱 경유 볼륨은 인터페이스를 통해 거래하는 유저 수와 그들의 거래 빈도에 달려 있다. Phantom이 누적 퍼프 볼륨 448억 달러 이상을 기록하는 이유는 153,128명의 유저가 Phantom을 통해 거래하고, 그 중 상당수가 편의를 위해 Phantom을 선택한 고빈도 퍼프 트레이더이기 때문이다. 반면 Insilico는 유저가 3,339명에 불과하지만 363억 달러의 볼륨을 기록했다. 유저들이 계정당 대규모 체결을 만들어내는 기관급 알고 운영자이기 때문이다.

시사점은 이렇다. 단순 유저 수는 약한 예측 지표다. 중요한 것은 유저당 거래 볼륨이고, 이는 유저가 누구이며 제품이 어떤 행동을 유도하느냐의 함수다. 일상적인 스팟 스왑 유저 100,000명을 보유한 지갑은 활발한 선물 트레이더 2,000명을 보유한 터미널보다 퍼프 볼륨이 적다.

2. 수수료율: 직접 조절할 수 있는 변수

Hyperliquid는 빌더에게 퍼프는 최대 10 베이시스 포인트(0.10%), 스팟은 최대 100 베이시스 포인트(1.00%)까지 수수료를 부과할 수 있게 한다. 부과한 수수료의 100%는 빌더가 가져간다. 프로토콜 수수료는 별도로 부과된다.

수수료율 설정에는 트레이드오프가 따른다. MetaMask는 최대에 가까운 약 8.9 베이시스 포인트를 부과한다(90억 달러 볼륨 대비 810만 달러 수익으로 계산). 이 공격적인 수수료가 통하는 이유는 MetaMask의 52,534 유저가 주로 편의 중심이기 때문이다. MetaMask를 떠나지 않고 퍼프를 거래하고 싶어하고, 그를 위해 몇 베이시스 포인트 더 지불할 의향이 있다. Insilico는 반대로 약 1 베이시스 포인트를 부과한다. 유저들이 10 bps 추가 수수료를 즉시 알아채고 우회 경로를 찾는 퀀트 팀이기 때문이다.

리더보드에서 얻을 수 있는 교훈은 보편적으로 옳은 수수료율이란 없다는 것이다. 수수료율은 유저의 수수료 민감도에 달려 있으며, 그것은 유저의 전문성과 이용 가능한 대안과 밀접하게 연관된다.

3. 유저 경제학: 검증 지표로서의 유저당 수익

유저당 수익은 노이즈를 걷어내는 지표다. 각 유저가 제품과 함께하는 기간 동안 실제로 얼마나 가치 있는지 보여주고, 서로 다른 빌더 전략이 실제로 어떻게 전개되는지 드러낸다.

Mass는 1,054개 계정만으로 유저당 1,395달러 이상을 번다. Phantom은 153,128개 계정 전반에 걸쳐 유저당 154달러를 번다. 둘 다 성공적이지만, 완전히 다른 비즈니스 모델을 대표한다. Mass는 소수의 헤비 트레이더를 상대하고, Phantom은 다수의 중간 수준 트레이더를 상대한다. 제품이 Phantom보다 Mass에 가깝다면 빌더 코드를 수익성 있게 만들기 위해 필요한 유저 수가 적다. 하지만 그 유저들이 공격적으로 거래해야 한다.

손익분기점 계산

통합은 공짜가 아니다. 이미 지갑이나 트레이딩 인터페이스를 보유한 팀 기준으로 Hyperliquid 빌더 코드 통합에는 통상 몇 주의 엔지니어링 시간이 필요하다. 빌더 주소 자체는 퍼프 계정에 100 USDC만 있으면 되므로 자본 요건은 무시할 수준이다. 진짜 비용은 엔지니어링 시간과 지속적인 유지보수다.

아래는 볼륨과 수수료 조합별 월 수익을 보여주는 시나리오 매트릭스다.

표 읽는 법: 앱이 하루 퍼프 볼륨 200만 달러를 5 베이시스 포인트로 경유한다면 월 약 30,000달러다. 하루 1,000만 달러에 동일한 수수료라면 150,000달러로 뛴다. 이는 빌더 코드 공식(수익 = 일일 볼륨 x 수수료율(소수점 표기) x 30일)에 기반한 예시 계산이다.

위 수치는 공식에만 근거한다. 볼륨 변동, 유저 이탈, 그리고 크립토 거래 볼륨이 순환적이며 강세장과 약세장 사이에서 몇 배씩 오갈 수 있다는 현실은 반영하지 않는다.

통합이 타당한 경우

리더보드 데이터를 보면 빌더 코드가 효과를 발휘하는 상황이 몇 가지 분명하게 보인다.

퍼프를 거래하는 유저가 이미 있다

이것이 가장 강력한 근거다. 지갑이나 앱이 이미 Hyperliquid 거래를 처리하고 있는데 빌더 코드 없이 볼륨을 흘려보내고 있다면 기회를 날리는 것이다. Phantom의 통합이 효과를 발휘하는 이유는 수백만 명이 이미 Phantom을 사용하고 있었기 때문이다. 빌더 코드로 퍼프를 추가한 것은 기존 배포 우위 위에 쌓은 점진적 엔지니어링이었다.

유저의 수수료 민감도가 낮다

편의 중심 유저, 즉 전용 거래소로 이동하는 대신 지갑의 내장 스왑 인터페이스로 거래하는 유형은 소액 수수료를 감수하는 경향이 있다. 이런 유형의 유저를 끌어들이는 제품이라면 볼륨 손실 걱정 없이 더 높은 수수료율(10 bps 상한에 가깝게)을 설정할 수 있다. MetaMask의 실효 수수료율이 9 bps에 가까워도 통하는 이유는 정확히 유저들이 수수료 최적화보다 편의를 우선시하기 때문이다.

유저당 볼륨이 높은 니치를 공략한다

헤비 트레이더라면 소규모 유저 베이스도 의미 있는 수익을 창출할 수 있다. Insilico의 3,339명 유저가 빌더 수익 370만 달러를 기록한 이유는 유저 한 명이 평생 평균 1,080만 달러 이상의 볼륨을 거래했기 때문이다. 퀀트 팀, 펀드 매니저, 전문 마켓 메이커를 위한 툴을 만들고 있다면 수만 명의 유저가 필요하지 않다. 공격적으로 거래하는 수백 명이면 된다.

그렇지 않은 경우

리더보드는 빌더 코드가 기대에 못 미치는 패턴도 드러낸다.

유저가 주로 스팟 트레이더다

Hyperliquid의 퍼프 볼륨은 스팟 볼륨을 압도한다. 빌더 코드는 둘 다에 적용되지만 수익 계산이 크게 다르다. 스팟 유저는 더 적은 규모로 더 낮은 빈도로 거래하는 경향이 있다. 진지한 스팟 플로우를 경유하면서 스팟 상한(100 bps)에 가깝게 수수료를 부과하지 않는 한, 캐주얼 스팟 스와퍼로부터 나오는 수익은 미미할 가능성이 높다.

유저 베이스의 수수료 민감도가 높고 대안이 있다

다른 터미널과 경쟁하는 트레이딩 터미널을 만들고 있다면 유저들은 수수료를 비교하는 유형이다. 경쟁사가 1 bps를 부과하는데 5 bps를 부과하면 실질적인 이탈 위험이 생긴다. 특히 볼륨의 대부분을 만들어내는 파워 유저 사이에서. 이 시나리오에서는 수수료 범위의 하단에 머물 수밖에 없고, 수익 계산을 성립시키려면 엄청난 볼륨이 필요하다.

Hyperliquid 유저가 아직 없다

빌더 코드는 수요를 만들지 않는다. 기존 수요를 수익화할 뿐이다. 지갑 유저들이 이미 Hyperliquid에서 거래하지 않거나 퍼프에 관심이 없다면, 빌더 코드를 통합해도 행동이 바뀌지 않는다. 통합 비용이 크지 않을 수 있지만, 인터페이스를 통해 유저를 Hyperliquid로 유도할 명확한 계획이 없다면 수익 전망은 유기적 도입을 기대하지 않는 것을 전제로 해야 한다.

상위 빌더들의 수수료 전략

수익 기준 상위 10개를 보면 수수료 전략은 두 가지 부류로 나뉜다.

| 전략 | 수수료 범위 | 유저 유형 | 사례 | | --- | --- | --- | --- | | 고수수료, 편의 우선 | 5-10 bps | 리테일, 지갑 네이티브 | Phantom, MetaMask, Rabby | | 저수수료, 볼륨 우선 | 1-3 bps | 알고리즘, 기관 | Insilico, Axiom, Based |

어느 쪽이 본질적으로 우월하지 않다. Phantom과 Based 모두 총수익 기준 상위 3위에 오르지만 정반대의 전략으로 그 자리에 올랐다. Phantom은 방대한 유저 베이스에 높은 수수료를 부과했고, Based는 비슷하게 방대한 볼륨에 낮은 수수료를 부과했다. 올바른 전략은 전적으로 유저가 누구이며 너무 높은 수수료를 부과할 경우 어떤 대안으로 이동할지에 달려 있다.

주목할 만한 패턴이 하나 있다. 유저당 수익 기준 상위 2개 빌더(Mass와 Insilico)는 모두 헤비 트레이더로 구성된 소규모의 집중된 유저 베이스를 보유한다. 제품이 자연스럽게 이런 유형을 끌어들인다면 빌더 코드를 수익성 있게 만들기 위해 Phantom의 규모가 필요하지 않을 수 있다.

빌더 코드 성과 모니터링

통합 후에는 빌더 코드 성과에 대한 가시성이 필요하다. 핵심 지표는 코드를 통해 경유된 일일 볼륨, 실효 수수료율, 유저당 수익, 유저 리텐션(동일한 지갑이 지속적으로 거래하는지, 아니면 볼륨이 일회성 유저에서 나오는지)이다.

당사의 빌더 애널리틱스 API는 이 모든 것을 프로그래밍 방식으로 추적한다. /builders/list 엔드포인트는 모든 빌더 코드에 대해 기간(일별, 주별, 월별, 전체)별로 세분화된 볼륨, 수익, 유저 수를 반환한다. 수동 계산 없이 자신의 코드 성과를 모니터링하고 더 넓은 생태계와 벤치마킹할 수 있다.

중요한 지표 추적: HyperTracker의 빌더 애널리틱스 엔드포인트는 모든 빌더 코드의 수익, 볼륨, 유저 수를 제공한다. /builders/list를 쿼리해 더 넓은 생태계 대비 성과를 벤치마킹하고, 손익에 반영되기 전에 트렌드를 파악하라.

의사결정 프레임워크

엔지니어링 리소스를 투입하기 전에 아래 체크리스트를 점검하라.

1. 유저들이 이미 Hyperliquid에서 거래하는가? 그렇다면 기존 행동을 수익화하는 것이다. 아니라면 도입을 기대하는 베팅이다.
2. 현실적으로 경유할 수 있는 일일 볼륨은 얼마인가? 현재 유저 지표를 활용해 추정하라. 퍼프 볼륨 기준 하루 최소 100만 달러를 전망할 수 없다면 엔지니어링 비용을 정당화하기 어려울 수 있다.
3. 유저들이 감수할 수 있는 수수료율은 얼마인가? 유저 베이스의 수수료 민감도를 파악하라. 지갑 유저는 높은 수수료를 감수하는 경향이 있고, 트레이딩 터미널 유저는 이탈하는 경향이 있다.
4. 통합 비용은 얼마인가? 기존 Hyperliquid 인프라를 보유한 팀이라면 몇 주의 개발 시간이 필요하다. 지갑 서명 플로우, 에이전트 키, 입금 오케스트레이션을 처음부터 구축해야 한다면 더 오래 걸린다.
5. 시장 사이클 전반에 걸쳐 볼륨을 유지할 수 있는가? 강세장 볼륨은 약세장 볼륨의 몇 배가 될 수 있다. 보수적인 기준으로 전망치를 세워라. 통합이 하락장에서도 살아남아야 하기 때문이다.

하루 200만 달러 이상을 유저들이 감수할 수 있는 수수료율로 경유할 수 있다고 답이 나온다면, 통합이 첫 분기 내에 비용을 회수할 가능성이 높다. 그 임계값 이하라면 결정이 어려워지고 선택권의 가치를 얼마나 두느냐에 달린다. 볼륨이 성장하면 빌더 코드가 이미 준비되어 있어 그 흐름을 포착할 수 있다.

빌더 코드 수익을 실시간으로 추적하라

HyperTracker의 빌더 애널리틱스 API로 Hyperliquid의 모든 빌더 코드에 대한 볼륨, 수익, 유저 수를 모니터링하라. 리더보드를 쿼리하고, 성과를 벤치마킹하고, 스프레드시트에 나타나기 전에 트렌드를 파악하라.

API 살펴보기

헤드라인을 장식하는 빌더 코드는 방대한 배포 기반을 뒤에 두고 있다. Phantom은 통합 당시 153,128명의 유저를 보유했고, MetaMask는 52,534명을 데려왔다. 하지만 배포만이 전부가 아니다. Mass는 1,054명의 유저도 적합한 1,054명이라면 147만 달러를 만들 수 있다는 것을 증명했다. 질문은 "지갑들이 빌더 코드를 통합해야 하는가?"가 아니었다. 항상 "당신의 지갑이 그것을 작동시킬 유저와 볼륨과 수수료 허용 범위를 갖추고 있는가?"였다. 이제 그 답을 내릴 수 있는 수치가 생겼다.