v0.1
엔터프라이즈 커스터디 사업 모델 분류 체계¶
1. 분류 체계 개요¶
1.1. 배경: 기존 Tier 분류의 한계¶
기존 competitive-analysis.md에서는 시장 점유율과 기업 규모를 기준으로 Tier 1/2/3을 분류했다. 이 분류는 시장 내 영향력 파악에는 유용하지만, 사업 모델 차이를 반영하지 못하는 근본적 한계가 있다.
구체적 한계: - BitGo(Qualified Custodian, 자산 수탁)와 Fireblocks(인프라 플랫폼, SaaS)가 동일한 Tier 1에 분류되어, 완전히 다른 수익 구조와 고객 관계를 구분하지 못함 - Ledger Enterprise(하드웨어 보안 벤더)가 Fireblocks/BitGo와 같은 Tier에 있으나, 키를 보관하지 않고 장비를 판매하는 근본적으로 다른 사업 모델임 - D'CENT Enterprise의 포지션이 "Tier 2 이하"로만 표시되어, 사업 모델 측면의 독자적 가치가 드러나지 않음 - 경쟁/협력 관계를 파악하려면 사업 모델 유형이 핵심인데, Tier 분류만으로는 "누구와 경쟁하고, 누구와 협력할 수 있는지"가 불명확함
1.2. 목적¶
사업 모델 기준 분류 체계를 수립하여: 1. 각 플레이어가 어떻게 돈을 버는지(수익 구조)를 기준으로 시장을 구조화한다 2. D'CENT Enterprise의 정확한 포지션을 확정하고, 인접 플레이어와의 경계를 명확히 한다 3. Phase 8-10(팩트 시트, 포지셔닝, 통합)의 분석 프레임워크를 제공한다
1.3. 분류 축 정의¶
사업 모델 분류를 위해 3개의 직교 축(orthogonal axes)을 정의한다. 각 축은 독립적으로 하나의 특성을 측정하며, 3개 축의 조합으로 범주가 결정된다.
축 1: 키 보관 주체 (Key Custody Model)¶
플레이어가 고객의 프라이빗 키(또는 키 셰어)를 보유하는지 여부로, 사업의 근본적 성격을 결정한다.
| 값 | 정의 | 판별 기준 |
|---|---|---|
| 벤더 보유 (Vendor-held) | 벤더가 키 또는 키 셰어 1개 이상을 직접 보유하고, 서명 프로세스에 벤더 인프라가 필수적으로 개입한다 | 키 셰어 1개라도 벤더 서버에 상주하면 "벤더 보유"로 분류. 벤더 서비스 중단 시 고객의 즉시 자산 접근이 불가능한 경우 포함 |
| 고객 보유 (Client-held) | 고객이 키의 100%를 보유하며, 벤더는 키에 대한 접근 권한이 전혀 없다. 벤더 서비스 중단 시에도 자산 접근이 가능하다 | 벤더가 키 셰어를 보유하지 않고, 표준 시드(BIP-39/44) 또는 자체 백업으로 벤더 없이 자산 복구 가능 |
| 혼합 (Hybrid) | 벤더 보유와 고객 보유를 별도 상품으로 모두 제공한다 | 두 가지 모델 각각이 독립 상품으로 존재하고, 각각의 매출이 식별 가능 |
축 2: 수익 구조 (Revenue Model)¶
주 매출원이 무엇인지로, 고객에게 제공하는 가치의 본질을 반영한다.
| 값 | 정의 | 판별 기준 |
|---|---|---|
| AUC 수수료 (AUC-based) | Assets Under Custody 규모에 비례하는 수수료가 주 매출원 | 매출의 50% 이상이 AUC 기반 수수료에서 발생 (공개 정보 또는 가격 체계에서 AUC 과금이 핵심) |
| SaaS 구독 (Subscription) | 플랫폼 이용료(월/연 구독)가 주 매출원 | 매출의 50% 이상이 고정 구독료에서 발생. AUC가 아닌 사용량(API 콜, 유저 수, 월렛 수) 기반 과금 포함 |
| HW + 라이선스 (Hardware + License) | 하드웨어 장비 판매 및 소프트웨어 라이선스가 주 매출원 | 하드웨어 제품이 존재하고, 이를 통한 장비 판매 + SW 라이선스가 핵심 수익 모델. 자산 규모와 무관한 과금 |
| 거래 수수료 (Transaction-based) | 트랜잭션 건수 또는 금액 기반 수수료가 주 매출원 | 매출의 50% 이상이 트랜잭션 수수료에서 발생 |
| 복합 (Blended) | 위 모델 중 2개 이상이 각각 30% 이상의 매출 비중을 차지 | 단일 수익 모델이 50% 이상을 차지하지 않음 |
축 3: 규제 라이선스 (Regulatory License)¶
커스터디 관련 규제 라이선스 보유 여부로, 서비스 범위와 고객 유형에 직접적 영향을 준다.
| 값 | 정의 | 판별 기준 |
|---|---|---|
| Qualified Custodian | 미국 SEC/주 규제 하의 적격 수탁자 자격 보유 | Trust Company 라이선스, SEC 등록 등 자산 수탁에 대한 법적 자격 보유 |
| VASP/MiCA | 가상자산사업자 등록 또는 EU MiCA 라이선스 보유 | 각국 VASP 등록, EU MiCA 인가, FCA 등록 등 |
| 없음 (None) | 커스터디 관련 규제 라이선스를 보유하지 않음 | 인프라/장비 판매 사업으로 커스터디 라이선스가 불필요하거나, 아직 취득하지 않음 |
2. 범주 정의¶
3개 분류 축의 조합과 실제 플레이어 데이터를 대조하여, 5개의 상호 배타적 범주를 확정한다.
범주 1: 규제 수탁 사업자 (Regulated Custodian)¶
정의: 규제 라이선스를 보유하고 고객 자산(프라이빗 키)을 직접 수탁하며, AUC 기반 수수료를 주 수익원으로 하는 사업자.
포함 기준: | 축 | 값 | |----|---| | 키 보관 주체 | 벤더 보유 (Vendor-held) | | 수익 구조 | AUC 수수료 (AUC-based) 또는 복합이되 AUC가 핵심 | | 규제 라이선스 | Qualified Custodian 또는 Trust License 보유 필수 |
배제 기준: - 키 셰어를 전혀 보유하지 않는 인프라 제공자 - 하드웨어 장비 판매가 주 사업인 벤더 - 규제 라이선스 미보유 사업자
대표적 사업 모델 패턴: - 고객 자산을 법적으로 수탁하고, 보관 규모에 비례하는 수수료를 부과한다 - 보험, 감사 보고서, 규제 컴플라이언스 서비스를 부가 제공한다 - 고객은 "자산 보관 + 규제 대응 서비스"를 구매한다
고객에게 제공하는 가치: "규제 준수가 보장된 안전한 자산 보관 서비스" — 고객은 자산 관리 부담을 벤더에게 위탁하고, 규제 보고와 보험 혜택을 받는다.
범주 2: 커스터디 인프라 플랫폼 (Custody Infrastructure Platform)¶
정의: 고객이 자체 커스터디를 구축할 수 있는 소프트웨어 인프라(API, SDK, 정책 엔진)를 제공하되, 벤더가 키 셰어를 보유하여 서명 프로세스에 개입하는 SaaS 플랫폼.
포함 기준: | 축 | 값 | |----|---| | 키 보관 주체 | 벤더 보유 (Vendor-held) — 키 셰어 최소 1개를 벤더 서버에 보유 | | 수익 구조 | SaaS 구독 또는 복합 (구독 + 거래 수수료 + AUC) | | 규제 라이선스 | 불문 (보유할 수도, 미보유할 수도 있음) |
배제 기준: - AUC 수수료가 매출의 명확한 주력이며, 자산 수탁이 핵심 서비스인 경우 → 범주 1 - 하드웨어 장비를 직접 제조·판매하는 경우 → 범주 3 - 벤더가 키 셰어를 전혀 보유하지 않는 경우 → 범주 4 또는 3
대표적 사업 모델 패턴: - MPC/TSS 기반 키 관리 인프라를 SaaS로 제공한다 - 정책 엔진, API, SDK를 통해 고객이 자체 워크플로우를 구축하게 한다 - 벤더가 키 셰어 1개를 보유하여 보안을 강화하되, "인프라 제공"이 핵심 가치이다 - 고객은 "자체 커스터디 구축을 위한 도구 + 보안 인프라"를 구매한다
고객에게 제공하는 가치: "검증된 인프라 위에서 자체 커스터디를 구축하는 도구" — 고객은 자산을 직접 관리하되, 벤더의 기술 인프라(MPC, 정책 엔진, 네트워크)를 활용한다.
범주 1과의 경계: - 범주 1(규제 수탁 사업자)은 자산 보관 자체가 서비스이고, 범주 2(인프라 플랫폼)는 자산 관리 도구가 서비스이다 - BitGo는 Trust Company 라이선스를 보유하고 AUC 수수료가 핵심이므로 범주 1, Fireblocks는 인프라 플랫폼 구독이 핵심이므로 범주 2
범주 3: 하드웨어 보안 벤더 (Hardware Security Vendor)¶
정의: 하드웨어 보안 장비(SE, HSM)를 직접 설계·제조하고, 장비 판매 + 소프트웨어 라이선스를 주 수익원으로 하는 벤더. 고객의 키를 보유하지 않는다.
포함 기준: | 축 | 값 | |----|---| | 키 보관 주체 | 고객 보유 (Client-held) — 벤더는 키에 대한 접근 권한 없음 | | 수익 구조 | HW + 라이선스 (Hardware + License) | | 규제 라이선스 | 없음 (커스터디 라이선스 불필요) |
배제 기준: - 벤더가 키 셰어를 보유하는 경우 → 범주 2 또는 1 - 하드웨어를 제조하지 않고 순수 소프트웨어만 제공하는 경우 → 범주 2 또는 4 - 자산 수탁 서비스를 제공하는 경우 → 범주 1
대표적 사업 모델 패턴: - Secure Element(SE) 또는 HSM 기반 하드웨어 장비를 설계·제조한다 - 장비 판매 + 동반 소프트웨어(관리 대시보드, 서명 앱) 라이선스를 판매한다 - 고객이 장비를 구매하면, 키는 고객의 하드웨어에만 존재한다 - 고객은 "보안 하드웨어 + 관리 소프트웨어"를 구매한다
고객에게 제공하는 가치: "하드웨어 수준의 보안이 보장된 자체 키 관리 장비" — 고객은 장비를 소유하고, 벤더 서비스 중단과 무관하게 자산에 접근할 수 있다.
범주 4: 키리스 인프라 제공자 (Keyless Infrastructure Provider)¶
정의: API/SDK 기반 월렛 인프라를 제공하되, 벤더가 키 셰어를 보유하지 않거나 최소한으로 보유하며, 고객의 자체 키 관리를 원칙으로 하는 순수 소프트웨어 인프라 제공자.
포함 기준: | 축 | 값 | |----|---| | 키 보관 주체 | 고객 보유 (Client-held) — 키 셰어 분산 시 벤더 서버에 보유하지 않는 것이 원칙 | | 수익 구조 | SaaS 구독 (Subscription) 또는 거래 수수료 | | 규제 라이선스 | 없음 또는 VASP |
배제 기준: - 벤더가 키 셰어를 서버에 보유하고 서명에 개입하는 경우 → 범주 2 - 하드웨어 장비를 제조하는 경우 → 범주 3 - 자산 수탁 서비스를 제공하는 경우 → 범주 1
대표적 사업 모델 패턴: - 분산 MPC를 제공하되, 키 셰어를 벤더 서버가 아닌 고객 인프라 또는 분산 노드에 배치한다 - "Wallet-as-a-Service" API를 제공하여 고객이 자체 앱에 월렛 기능을 임베드한다 - 고객은 "프로그래매틱 월렛 인프라"를 구매한다
고객에게 제공하는 가치: "벤더 종속 없이 자체 월렛을 구축하는 API 인프라" — 고객은 벤더의 API를 사용하되, 키를 자체 관리한다.
범주 2와의 경계: - 범주 2(커스터디 인프라 플랫폼)는 벤더가 키 셰어를 보유하여 서명 보안에 직접 개입한다. 범주 4(키리스 인프라)는 벤더가 키에 관여하지 않고 순수 인프라만 제공한다 - 핵심 구분점: "벤더 서비스 중단 시 고객이 즉시 자산에 접근 가능한가?" — Yes이면 범주 4, No이면 범주 2
범주 5: 하이브리드 사업자 (Hybrid Operator)¶
정의: 자산 수탁 서비스(범주 1 유형)와 인프라 플랫폼(범주 2 유형)을 모두 별도 상품으로 운영하며, 두 사업이 각각 유의미한 매출 비중을 차지하는 사업자.
포함 기준 (모두 충족해야 함): | 기준 | 조건 | |------|------| | 이중 사업 모델 | 자산 수탁(Custodial) 서비스와 인프라 플랫폼(Self-custody tools) 서비스를 별도 상품으로 제공 | | 매출 비중 | 두 사업 각각의 매출이 전체의 20% 이상으로 추정 (공개 데이터 또는 상품 라인업 기반) | | 의도적 이중 운영 | 마케팅, 가격, 고객 세그먼트가 두 사업별로 구분되어 있음 |
배제 기준: - 하나의 사업 모델이 매출의 80% 이상을 차지하는 경우 → 주력 사업의 범주로 분류 - "분류가 어려운" 플레이어를 임의로 배치하는 잔여 범주가 아님 - 부가 서비스(예: 수탁 사업자가 API도 제공)는 Hybrid로 분류하지 않음. 별도 상품으로 독립 운영되어야 함
대표적 사업 모델 패턴: - Custodial Wallet(수탁형)과 Co-managed/Self-custody Wallet(자체 관리형)을 별도 상품으로 운영한다 - 고객이 니즈에 따라 수탁 서비스 또는 자체 구축 도구를 선택할 수 있다 - 고객은 "수탁 서비스 + 자체 관리 도구의 선택지"를 구매한다
고객에게 제공하는 가치: "커스터디와 자체 관리를 상황에 따라 선택하는 유연성" — 고객은 자산 유형, 규제 요건, 보안 니즈에 따라 모델을 혼합한다.
3. 결정 트리 (Decision Tree)¶
새로운 플레이어가 등장했을 때, 아래 결정 트리를 따라 3-4개 질문으로 범주를 판별한다.
Q1: 고객 자산의 프라이빗 키(또는 키 셰어)를 벤더가 직접 보유하는가?
│
├─ YES → Q2a: 자산 수탁이 핵심 서비스이며, 규제 라이선스(Qualified Custodian/Trust)를 보유하는가?
│ │
│ ├─ YES → Q3a: 별도 상품으로 인프라/셀프 커스터디 플랫폼도 운영하며,
│ │ 해당 사업의 매출 비중이 20% 이상인가?
│ │ │
│ │ ├─ YES → ★ 범주 5: 하이브리드 사업자 (Hybrid Operator)
│ │ │
│ │ └─ NO → ★ 범주 1: 규제 수탁 사업자 (Regulated Custodian)
│ │
│ └─ NO → ★ 범주 2: 커스터디 인프라 플랫폼 (Custody Infrastructure Platform)
│
└─ NO → Q2b: 하드웨어 보안 장비(SE, HSM)를 직접 설계·제조하여 판매하는가?
│
├─ YES → ★ 범주 3: 하드웨어 보안 벤더 (Hardware Security Vendor)
│
└─ NO → ★ 범주 4: 키리스 인프라 제공자 (Keyless Infrastructure Provider)
결정 트리 사용 가이드¶
Q1 판별 세부 기준: - "키 셰어 1개라도 벤더 서버에 상주하면" → YES - MPC 키 셰어를 벤더 클라우드에 보유하면 → YES - 키 셰어를 고객 인프라에만 배치하면 → NO - 하드웨어 장비에 키가 저장되고, 벤더가 접근 불가하면 → NO
Q2a 판별 세부 기준: - "핵심 서비스"의 판단: 가격 모델이 AUC 기반이거나, 규제 보고/보험이 서비스의 일부이면 → YES - 인프라 제공이 핵심이고 라이선스는 부수적이면 → NO (범주 2로 분류)
Q2b 판별 세부 기준: - "직접 설계·제조"가 핵심: 하드웨어를 OEM으로 받아 리셀하는 경우는 제외 - SE/HSM 기반 장비의 설계와 제조가 사업의 핵심 역량이어야 함
Q3a 판별 세부 기준: - "별도 상품"의 판단: 독립된 가격 체계, 별도 마케팅, 구분된 고객 세그먼트가 존재해야 함 - 부가 기능으로 API를 제공하는 수준은 Hybrid가 아님
경계 사례 처리 원칙¶
- 판단이 모호한 경우: 주력 사업 모델이 무엇인지를 최우선 기준으로 삼는다. "무엇으로 가장 많은 매출을 올리는가?"
- 사업 모델 전환 중인 경우: 현재 시점 기준으로 분류하되, 전환 방향을 비고에 기술한다
- 데이터 부족 시: 공개된 가격 모델, 제품 라인업, 마케팅 메시지를 기반으로 추정하고, 데이터 품질을 INFERRED로 표기한다
4. 플레이어 매핑¶
v0.0 competitive-analysis.md에서 분석된 10개 플레이어를 분류 체계에 매핑한다. 각 플레이어에 대해 결정 트리를 적용하고, 매핑 근거를 제시한다.
4.1. 매핑 요약 테이블¶
| 플레이어 | 범주 | 키 보관 주체 | 주 수익 구조 | 규제 라이선스 | 데이터 품질 |
|---|---|---|---|---|---|
| Fireblocks | 범주 2: 커스터디 인프라 플랫폼 | 벤더 보유 (MPC 키 셰어) | SaaS 구독 + 거래 수수료 (복합) | 없음 (규제 수탁자 아님) | VERIFIED |
| BitGo | 범주 1: 규제 수탁 사업자 | 벤더 보유 (TSS 키 셰어) | AUC 수수료 (커스터디+스테이킹 매출 80%+) | Qualified Custodian (SD Trust) | VERIFIED |
| Ledger Enterprise | 범주 3: 하드웨어 보안 벤더 | 고객 보유 (SE/HSM에 키 저장) | HW + 라이선스 (장비 + SaaS 구독) | 없음 | INFERRED |
| Cobo | 범주 5: 하이브리드 사업자 | 혼합 (Custody + Co-managed) | SaaS 구독 (사용량 기반) | VASP (싱가포르) | VERIFIED |
| Copper | 범주 2: 커스터디 인프라 플랫폼 | 벤더 보유 (MPC 키 셰어) | SaaS 구독 + 거래 수수료 (복합) | VASP (UK FCA) | VERIFIED |
| DFNS | 범주 4: 키리스 인프라 제공자 | 고객 보유 (분산 MPC, 벤더 미보유 원칙) | SaaS 구독 (API 기반) | 없음 | INFERRED |
| Fordefi | 범주 2: 커스터디 인프라 플랫폼 | 벤더 보유 (MPC + HSM) | SaaS 구독 | 없음 | INFERRED |
| Anchorage Digital | 범주 1: 규제 수탁 사업자 | 벤더 보유 (벤더 관리 키) | AUC 수수료 + 거래 수수료 | Qualified Custodian (OCC 연방 은행 인가) | VERIFIED |
| Coinbase Custody | 범주 1: 규제 수탁 사업자 | 벤더 보유 (벤더 관리 키) | AUC 수수료 | Qualified Custodian (NY Trust) | VERIFIED |
| Hex Trust | 범주 1: 규제 수탁 사업자 | 벤더 보유 (벤더 관리 키) | AUC 수수료 + 구독 | VASP (홍콩 SFC, 싱가포르 MAS) | VERIFIED |
| Zodia Custody (이머징) | 범주 1: 규제 수탁 사업자 | 벤더 보유 (고객 자산 수탁) | AUC 수수료 | FCA 등록 + 은행 라이선스 | INFERRED |
| HashKey Group (이머징) | 범주 1: 규제 수탁 사업자 | 벤더 보유 (고객 자산 수탁) | AUC + 거래 수수료 | SFC Type 1/7 라이선스 | INFERRED |
| Taurus (이머징) | 범주 2: 커스터디 인프라 플랫폼 | 벤더 보유 (MPC/HSM 기반) | SaaS 구독 | FINMA 감독 | INFERRED |
| Sodot (이머징) | 범주 4: 키리스 인프라 제공자 | 고객 보유 (MPC SDK, 벤더 미보유 원칙) | SaaS 구독 (SDK 라이선스) | 없음 | INFERRED |
4.2. 개별 매핑 근거¶
Fireblocks → 범주 2: 커스터디 인프라 플랫폼¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (MPC-CMP 4개 키 셰어 중 Fireblocks 서버가 최소 1개 보유) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → NO (Fireblocks는 규제 수탁자가 아님. 인프라 플랫폼이 핵심 서비스) - → 범주 2 확정
근거: Fireblocks의 핵심 가치는 "기관이 자체 커스터디를 구축하는 인프라"이다. MPC-CMP 키 관리, 정책 엔진(TAP), Fireblocks Network를 SaaS로 제공하며, 구독 + 거래 수수료의 복합 수익 모델을 운영한다. 고객 자산을 법적으로 수탁하지 않으며, Qualified Custodian 라이선스를 보유하지 않는다. 다만 키 셰어를 벤더 서버에 보유하므로 범주 4(키리스)가 아닌 범주 2이다.
BitGo → 범주 1: 규제 수탁 사업자¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (TSS 키 3개 중 BitGo 서버가 1개 보유) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → YES (사우스다코타주 Trust Company 라이선스 보유. S-1 기준 커스터디+스테이킹이 매출 80%+) - Q3a: 별도 인프라 플랫폼도 운영하며 매출 비중 20% 이상인가? → NO (셀프 매니지드 월렛도 제공하나, 핵심은 수탁 서비스) - → 범주 1 확정
근거: BitGo는 2026년 1월 IPO 시 공개한 S-1에서 커스터디+스테이킹이 매출의 80% 이상임을 확인했다. AUC 기반 수수료(월 5bps)가 핵심 수익 모델이며, $250M+ 보험 풀을 제공한다. BitGo Trust Company로서 Qualified Custodian 자격을 보유하여 기관의 규제 요건을 충족한다.
Ledger Enterprise → 범주 3: 하드웨어 보안 벤더¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → NO (키는 고객의 HSM/SE 장비에 저장. Ledger가 키에 접근하지 않음) - Q2b: 하드웨어 보안 장비를 직접 설계·제조하여 판매하는가? → YES (CC EAL5+/6+ SE 칩 직접 설계, Ledger Vault HSM 장비 제공) - → 범주 3 확정
근거: Ledger의 핵심 역량은 SE 칩 설계와 하드웨어 보안 장비 제조이다. Enterprise 제품(Ledger Vault/Enterprise)은 HSM 기반 하드웨어를 고객 환경에 배치하고, 소프트웨어 플랫폼 구독을 추가 판매하는 모델이다. 고객의 키는 Ledger의 HSM/SE에 저장되지만, Ledger가 키에 접근하지 않는다. Enterprise 부문의 정확한 매출 구조는 비공개이나, 하드웨어 판매 + SaaS 구독이 핵심으로 추정된다 (데이터 품질: INFERRED).
참고: Ledger Enterprise의 HSM은 네트워크에 연결되어 운영되므로 "진정한 에어갭"은 아니다. 그러나 키 보관 주체 관점에서 Ledger가 키를 보유하지 않으므로 범주 3에 해당한다.
Cobo → 범주 5: 하이브리드 사업자¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (MPC Co-managed에서 Cobo가 키 셰어 보유) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → 부분적 (Cobo Custody는 수탁형, 그러나 Qualified Custodian이 아닌 VASP) - → 추가 분석 필요: Cobo는 수탁형(Cobo Custody)과 자체 관리형(Cobo Argus, MPC Co-managed)을 별도 상품으로 운영
Hybrid 기준 검증: 1. 이중 사업 모델: Cobo Custody(수탁형) + Cobo Argus/MPC Co-managed(자체 관리형) — 별도 상품으로 운영 ✓ 2. 매출 비중: 가격 페이지에서 Custodial과 MPC 상품을 별도 티어로 제공 — 각각 유의미한 비중으로 추정 ✓ 3. 의도적 이중 운영: 마케팅에서 "Full Custody to Self-Custody" 전 범위를 명시적으로 표방 ✓ - → 범주 5 확정
근거: Cobo는 의도적으로 수탁형(Custodial Wallet)과 자체 관리형(MPC Co-managed, Argus)을 모두 별도 상품으로 운영하는 "Full-stack custody" 전략을 추구한다. 가격 페이지에서도 두 모델이 독립 상품으로 구분되어 있다. 이는 부가 서비스가 아닌 의도적 이중 사업 모델에 해당하므로 Hybrid로 분류한다.
Copper → 범주 2: 커스터디 인프라 플랫폼¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (MPC 3-of-3 키 셰어 분산, Copper 서버 보유) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → NO (UK FCA 등록이나, 핵심 서비스는 ClearLoop 등 거래 인프라. Qualified Custodian이 아님) - → 범주 2 확정
근거: Copper의 핵심 가치는 ClearLoop(off-exchange settlement), 포트폴리오 관리 등 기관 트레이딩 인프라이다. MPC 기반 커스터디를 제공하되, 자산 수탁 자체보다는 인프라 플랫폼으로서의 가치에 초점을 맞춘다. UK FCA에 등록되어 있으나 Qualified Custodian은 아니다.
DFNS → 범주 4: 키리스 인프라 제공자¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → NO (분산 MPC로 키 셰어를 다수 노드에 분산. DFNS 서버에 키 셰어 보유하지 않는 것이 원칙) - Q2b: 하드웨어 보안 장비를 직접 설계·제조하여 판매하는가? → NO (순수 소프트웨어, 클라우드 네이티브) - → 범주 4 확정
근거: DFNS는 "MPC-as-a-Service"를 표방하며 API/SDK 기반 월렛 인프라를 제공한다. 핵심 차별화는 키 셰어를 벤더 서버가 아닌 분산 노드에 배치하여 벤더 종속을 최소화하는 것이다. 개발자 친화적 SDK를 통해 고객이 자체 앱에 월렛을 임베드하는 모델이다. 다만 DFNS의 키 관리 아키텍처 상세(키 셰어 보유 여부)는 공개 정보 기반 추정이다 (데이터 품질: INFERRED).
Fordefi → 범주 2: 커스터디 인프라 플랫폼¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (MPC + HSM 구조에서 벤더 인프라가 서명에 개입) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → NO (규제 라이선스 미보유. 인프라 플랫폼이 핵심) - → 범주 2 확정
근거: Fordefi는 MPC 기반 기관 월렛과 트랜잭션 시뮬레이션을 결합한 인프라 플랫폼이다. DeFi 특화 리스크 평가와 실시간 시뮬레이션이 차별화 요소이다. 벤더 인프라(MPC + HSM)가 서명 프로세스에 개입하므로 범주 2에 해당한다 (데이터 품질: INFERRED).
Anchorage Digital → 범주 1: 규제 수탁 사업자¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (벤더가 자산을 관리) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → YES (OCC 연방 은행 인가 보유 — 디지털 자산 업계 최초) - Q3a: 별도 인프라 플랫폼도 운영하며 매출 비중 20% 이상인가? → NO (수탁 서비스가 압도적 핵심) - → 범주 1 확정
근거: Anchorage Digital은 2021년 미국 OCC(Office of the Comptroller of the Currency)로부터 연방 은행 인가를 획득한 최초의 디지털 자산 기업이다. 기관 고객의 자산을 법적으로 수탁하며, AUC 기반 수수료와 거래/스테이킹 수수료를 주 수익원으로 한다. 규제 수탁이 핵심 서비스이다.
Coinbase Custody → 범주 1: 규제 수탁 사업자¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (Coinbase가 자산을 관리) - Q2a: 자산 수탁이 핵심 서비스이며, Qualified Custodian 라이선스를 보유하는가? → YES (뉴욕주 Trust Company 라이선스 보유) - Q3a: 별도 인프라 플랫폼도 운영하며 매출 비중 20% 이상인가? → NO (Coinbase Prime 등이 있으나, Custody 부문은 수탁 중심) - → 범주 1 확정
근거: Coinbase Custody(Coinbase Custody Trust Company, LLC)는 뉴욕주 금융감독원(NYDFS) 인가 Trust Company이다. 기관 고객의 디지털 자산을 법적으로 수탁하며, AUC 기반 수수료가 핵심이다. 세계 최대 규모의 기관 디지털 자산 수탁을 담당한다.
Hex Trust → 범주 1: 규제 수탁 사업자¶
결정 트리 적용: - Q1: 벤더가 키 셰어를 보유하는가? → YES (벤더가 자산을 관리) - Q2a: 자산 수탁이 핵심 서비스이며, 규제 라이선스를 보유하는가? → YES (홍콩 SFC 라이선스, 싱가포르 MAS 인가 보유) - Q3a: 별도 인프라 플랫폼도 운영하며 매출 비중 20% 이상인가? → NO (수탁이 핵심) - → 범주 1 확정
근거: Hex Trust는 아시아 기반 규제 디지털 자산 수탁 전문 사업자이다. 홍콩 SFC Type 1 라이선스와 싱가포르 MAS 인가를 보유하며, 기관 고객의 자산을 법적으로 수탁한다. AUC 기반 수수료와 플랫폼 구독료를 주 수익원으로 한다.
4.3. 범주별 분류 결과 요약¶
| 범주 | 플레이어 | 수 | 비율 |
|---|---|---|---|
| 범주 1: 규제 수탁 사업자 | BitGo, Anchorage Digital, Coinbase Custody, Hex Trust + (이머징) Zodia Custody, HashKey Group | 6 | 43% |
| 범주 2: 커스터디 인프라 플랫폼 | Fireblocks, Copper, Fordefi + (이머징) Taurus | 4 | 29% |
| 범주 3: 하드웨어 보안 벤더 | Ledger Enterprise | 1 | 7% |
| 범주 4: 키리스 인프라 제공자 | DFNS + (이머징) Sodot | 2 | 14% |
| 범주 5: 하이브리드 사업자 | Cobo | 1 | 7% |
| 합계 | 14 | 100% |
참고: 이머징 플레이어 4개는 v0.1 Phase 10에서 추가. 기존 10개 플레이어의 비율은 v0.0 기준.
5. Hybrid 범주 검증¶
5.1. Hybrid 분류 결과¶
Hybrid(범주 5)로 분류된 플레이어: Cobo (1개)
5.2. 30% 기준 검증¶
- Hybrid 플레이어 수: 1개
- 전체 플레이어 수: 10개
- Hybrid 비율: 10%
- 30% 기준: 충족 (10% < 30%)
5.3. Hybrid 분류 타당성¶
Cobo가 Hybrid로 분류된 이유: 1. Cobo Custody (수탁형): 기관 고객의 자산을 직접 수탁하는 서비스 2. Cobo Argus + MPC Co-managed (자체 관리형): 고객이 키 셰어를 공동 관리하는 DeFi 접근 플랫폼
두 서비스는 별도 상품으로 운영되며, 가격 페이지에서도 독립적으로 제공된다. Cobo는 마케팅에서 "Custodial부터 Self-custody까지 전 범위"를 명시적으로 표방하고 있어, 의도적 이중 사업 모델에 해당한다.
5.4. 경계 사례 재검토¶
Hybrid로 분류할 수 있었으나 분류하지 않은 플레이어:
- BitGo: BitGo는 셀프 매니지드 월렛(BitGo Portfolio)도 제공하지만, S-1 기준 커스터디+스테이킹 매출이 80%+이므로 수탁이 압도적 핵심 사업이다 → 범주 1 유지
- Fireblocks: Fireblocks는 간접적으로 커스터디 기능을 제공하나, 규제 수탁자가 아니며 인프라 플랫폼이 명확한 핵심 → 범주 2 유지
6. D'CENT Enterprise 자기 분류¶
6.1. 결정 트리 적용¶
Q1: 고객 자산의 프라이빗 키를 벤더(D'CENT)가 직접 보유하는가? → NO
D'CENT Enterprise는 프라이빗 키가 하드웨어 SE(Secure Element) 내부에만 존재하며, D'CENT 서버에 키 또는 키 셰어를 보유하지 않는다. 고객이 하드웨어 장비를 물리적으로 보유하며, 표준 시드(BIP-39/44) 기반으로 D'CENT 서비스 중단 시에도 자산 복구가 가능하다.
Q2b: 하드웨어 보안 장비(SE, HSM)를 직접 설계·제조하여 판매하는가? → YES
D'CENT은 CC EAL5+ 인증 수준의 Secure Element 기반 하드웨어 월렛을 직접 설계·제조한다. D'CENT X 콜드월렛, 오프라인 서명 앱, 온라인 대시보드를 포함하는 제품군을 판매하며, 하드웨어 장비 + 소프트웨어 라이선스가 핵심 수익 모델이다.
→ 범주 3: 하드웨어 보안 벤더 (Hardware Security Vendor) 확정
6.2. 3개 축 상세 분석¶
| 분류 축 | D'CENT Enterprise | 값 |
|---|---|---|
| 키 보관 주체 | 고객 보유 (Client-held) — 키는 SE에만 존재, 벤더 접근 불가 | 고객 보유 |
| 수익 구조 | HW + 라이선스 — 하드웨어 장비(D'CENT X) 판매 + 관리 소프트웨어(대시보드, 서명 앱) 라이선스 | HW + 라이선스 |
| 규제 라이선스 | 없음 — 자산을 수탁하지 않으므로 커스터디 라이선스 불필요 | 없음 |
6.3. 인접 범주와의 경계 분석¶
Ledger Enterprise와의 비교 (같은 범주 3)¶
D'CENT Enterprise와 Ledger Enterprise는 모두 범주 3(하드웨어 보안 벤더)에 속하지만, 핵심적 차이가 존재한다:
| 비교 항목 | D'CENT Enterprise | Ledger Enterprise |
|---|---|---|
| 에어갭 | 진정한 에어갭 (QR/USB-C만, 네트워크 연결 제로) | 부분적 (HSM이 네트워크에 연결) |
| 키 셰어 모델 | 제로 키 셰어 — 키가 SE에서 완전히 보관, 분할되지 않음. MuSig2/MPC-TSS는 서명 프로토콜이며 키를 분할 보관하지 않음 | HSM 기반 — 키가 HSM에 보관되나 네트워크 연결 상태 |
| 셀프 커스터디 | 100% — 벤더 서비스 중단 시에도 BIP-39/44 시드로 자산 복구 가능 | 높음 — 그러나 HSM 의존도로 인해 완전한 독립은 아님 |
| WYSIWYS | 완전 지원 — 디바이스 화면에서 트랜잭션 내용 직접 확인 후 서명 | 개인용 디바이스에서 지원, Enterprise HSM에서는 제한적 |
| 온프레미스 | 완전 지원 — 클라우드 의존성 제로 | 가능 — HSM 온프레미스 배치 |
| 타겟 시장 | 콜드 스토리지 전문 — 고가치 자산 장기 보관에 특화 | 범용 기관 커스터디 — 핫/웜/콜드 전 범위 |
핵심 경계: D'CENT Enterprise의 "진정한 에어갭 + 제로 키 셰어(벤더 키 미보유)"는 Ledger Enterprise와의 명확한 차별화 포인트이다. Ledger Enterprise의 HSM은 네트워크에 연결되어 운영되므로 원격 공격 표면이 존재하지만, D'CENT Enterprise는 물리적 채널(QR/USB-C)만 허용하여 원격 해킹이 불가능하다.
Fireblocks/BitGo와의 경계 (범주 2/1과의 차이)¶
| 구분 기준 | D'CENT Enterprise (범주 3) | Fireblocks (범주 2) / BitGo (범주 1) |
|---|---|---|
| 키 보유 | 벤더 키 미보유 → 고객 완전 자주 | 벤더 키 셰어 보유 → 벤더 개입 필수 |
| 사업 본질 | 보안 하드웨어 + SW 판매 | 인프라 플랫폼 SaaS / 자산 수탁 서비스 |
| 벤더 종속 | 제로 — 벤더 폐업 시에도 자산 접근 | 높음 — 벤더 서비스 중단 시 키 셰어 접근 불가 위험 |
| 수익 모델 | 장비 판매 + 라이선스 (자산 규모 무관) | AUC/구독 + 거래 수수료 (자산 규모/사용량 비례) |
| 보안 계층 | 콜드 스토리지 전문 | 핫/웜 인프라 (실시간 운영) |
핵심 경계: D'CENT Enterprise가 범주 2(인프라 플랫폼)나 범주 1(수탁 사업자)이 아닌 이유는 명확하다. 고객의 키를 보유하지 않고, 자산 수탁 서비스를 제공하지 않으며, 하드웨어 장비 판매가 핵심 사업이다. D'CENT Enterprise는 Fireblocks/BitGo의 대체재가 아니라, 콜드 스토리지 계층의 보완재로서 포지셔닝된다.
6.4. D'CENT Enterprise의 범주 내 차별화 요소¶
범주 3(하드웨어 보안 벤더) 내에서 D'CENT Enterprise의 독자적 포지션:
-
진정한 에어갭 (True Air-Gap): 네트워크 연결 제로. QR/USB-C를 통한 물리적 데이터 전송만 허용. 동일 범주의 Ledger Enterprise도 이 수준의 에어갭을 제공하지 않는다.
-
100% 셀프 커스터디 + 벤더 락인 제로: 프라이빗 키가 SE에서만 존재하며, BIP-39/44 표준 시드로 벤더 독립적 복구가 가능하다. 벤더 종속이 완전히 제거된다.
-
엔터프라이즈 거버넌스: 개인용 하드웨어 월렛(COLDCARD, Keystone 등)과 달리, RBAC, 정책 엔진, 멀티테넌시 등 기관 운영에 필요한 거버넌스 기능을 갖춘다.
-
하이브리드 서명 프로토콜: MuSig2(BTC 최적화) + MPC-TSS(멀티체인) 하이브리드 접근으로, 비트코인과 멀티체인 모두에서 최적의 서명 효율을 제공한다.
-
WYSIWYS: 디바이스 화면에서 트랜잭션 내용을 직접 확인하고 물리 버튼으로 승인하여, 블라인드 서명과 소프트웨어 조작을 원천 차단한다.
7. 기존 Tier 분류와의 대조¶
7.1. Tier × 사업 모델 범주 교차 매핑¶
| 범주 1: 규제 수탁 사업자 | 범주 2: 커스터디 인프라 플랫폼 | 범주 3: 하드웨어 보안 벤더 | 범주 4: 키리스 인프라 | 범주 5: 하이브리드 | |
|---|---|---|---|---|---|
| Tier 1 (직접 경쟁) | BitGo | Fireblocks | Ledger Enterprise | - | - |
| Tier 2 (간접 경쟁) | - | Copper, Fordefi | - | DFNS | Cobo |
| Tier 3 (참고) | Anchorage, Coinbase Custody, Hex Trust | - | - | - | - |
7.2. 기존 분류의 한계 해소¶
한계 1: "같은 Tier이지만 다른 사업 모델" 문제 해소¶
기존 Tier 1에는 Fireblocks(인프라 플랫폼), BitGo(규제 수탁), Ledger Enterprise(하드웨어 벤더)가 혼재했다. 사업 모델 분류에서는:
- Fireblocks → 범주 2 (인프라 플랫폼): 고객에게 MPC 기반 도구를 제공
- BitGo → 범주 1 (규제 수탁): 고객 자산을 법적으로 수탁
- Ledger Enterprise → 범주 3 (하드웨어 벤더): 보안 장비를 판매
세 플레이어가 완전히 다른 사업 모델임이 명확해졌다. 이는 경쟁/협력 관계 분석에 결정적 차이를 만든다: - BitGo(수탁)와 Ledger Enterprise(장비 판매)는 경쟁자가 아닌 잠재적 보완 관계일 수 있다 - Fireblocks(인프라)와 D'CENT Enterprise(하드웨어)는 직접 경쟁이 아닌 콜드 스토리지 계층의 보완재이다
한계 2: "다른 Tier이지만 같은 사업 모델" 문제 해소¶
기존 분류에서 BitGo(Tier 1)와 Anchorage/Coinbase Custody/Hex Trust(Tier 3)는 다른 Tier에 배치되었으나, 사업 모델 분류에서는 모두 범주 1(규제 수탁 사업자)로 통합된다. 사업 모델이 동일하므로: - 규제 환경 변화가 4개 플레이어에 동일하게 영향 - AUC 기반 경쟁 구도에서 직접적인 경쟁 관계 - D'CENT Enterprise 관점에서 4개 모두 "잠재적 보완 파트너" (콜드 스토리지 계층 공급)
한계 3: D'CENT Enterprise 포지션 불명확 문제 해소¶
기존 분류에서 D'CENT Enterprise는 "Tier 2 이하"로만 표시되어, 시장 규모가 작은 후발주자라는 인상만 주었다. 사업 모델 분류에서는: - 범주 3(하드웨어 보안 벤더)으로서 Fireblocks/BitGo와 다른 차원의 가치를 제공함이 명확 - 범주 1/2 플레이어의 대체재가 아닌, 콜드 스토리지 계층의 독자적 솔루션으로 포지셔닝 - 같은 범주의 Ledger Enterprise 대비 "에어갭 + 제로 키 셰어"의 차별화가 구조적으로 설명됨
7.3. Phase 10 통합 시 활용 시사점¶
기존 competitive-analysis.md 업데이트 시 다음 사항을 반영해야 한다:
- Sec 2(분류) 업데이트: Tier 분류를 유지하되, 사업 모델 범주를 병행 표기. Tier는 "시장 영향력", 범주는 "사업 모델 유형"을 나타냄
- Sec 6(포지셔닝) 업데이트: 2x2 포지셔닝 매트릭스에 사업 모델 범주별 색상/마커를 추가하여, 사업 모델 차이를 시각적으로 구분
- 경쟁/협력 관계 테이블 신설: 각 범주 간 관계(경쟁/보완/잠재 고객/공급자)를 명시하는 테이블 추가
- Tier ↔ 범주 교차 테이블 삽입: 7.1절의 교차 매핑을 competitive-analysis.md에 직접 포함
작성일: 2026-03-28 문서 분류: Phase 7 - Taxonomy Definition 요구사항 참조: TAXO-01, TAXO-02, TAXO-03 데이터 소스: competitive-analysis.md (v0.0 Phase 1), objectives/minho/m00-01-competitive-landscape-reclassification.md