Road to Web3 (20) 지갑 키 관리 실전: 핫 웜 콜드, 시드 HD, MPC 개요

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

 

이번 편의 목표는 한 문장입니다.

• 키를 어떻게 보관하고 서명할지의 선택이 곧 서비스 아키텍처와 운영 리스크를 결정한다

이 글은 세 축을 다룹니다.

• 핫 웜 콜드 지갑을 언제 어떻게 나누는가
• 시드와 HD 지갑이 왜 기본값이 되었는가
• MPC가 무엇을 해결하고 무엇을 해결하지 못하는가

 

제가 처음 키 관리 얘기를 들을 때 했던 오해는 이렇습니다.

• 지갑은 앱이고, 키는 그냥 파일 같은 것이다
• 키를 잘 숨기면 끝이고, 보안은 암호학 문제다
• 서비스는 어차피 서버가 처리하니 지갑은 하나면 된다

현실은 이렇습니다.

• 키는 비밀이면서 동시에 권한이다. 권한 설계가 곧 보안 설계다
• 키를 온라인에 두면 운영 편의는 올라가지만 공격 표면도 같이 커진다
• 지갑을 나누는 이유는 성능이 아니라 피해 반경을 줄이기 위해서다

web2 결제 시스템 비유로 말하면

• 핫 지갑은 즉시 승인과 출금이 가능한 운영 계정
• 콜드 지갑은 금고에 있는 원장 보관 계정
• 웜 지갑은 금고와 운영 계정 사이의 중간 금고 역할

---

 

0) 한 번만 고정하는 위협 모델

이 글에서 최소 전제는 아래입니다.

• 서버가 뚫릴 수 있다
• 내부자 실수나 악의가 있을 수 있다
• 키가 유출되면 되돌리기 어렵다
• 체인 트랜잭션은 승인 취소나 차지백이 기본으로 없다

따라서 목표는 완벽이 아니라 피해 반경과 사고 대응 시간을 늘리는 것입니다.

---

 

1) 핫 웜 콜드 지갑: 돈의 흐름이 아니라 권한의 경계

핫 웜 콜드는 온도라기보다 연결성의 단계입니다.

구분	온라인 연결	서명 속도	권장 용도	사고 시 피해
핫	상시	매우 빠름	소액 출금, 즉시 처리	크게
웜	제한적	빠름	리밸런싱, 배치 출금	중간
콜드	오프라인	느림	트레저리, 장기 보관	작게

 

핵심은 이겁니다.

• 핫에서 모든 것을 처리하면 편하지만, 해킹 시 전액 손실이 가능하다
• 콜드만 쓰면 안전하지만, 운영이 불가능할 정도로 느리다
• 웜은 리스크와 속도의 타협점이다

1.1 실무 패턴: 잔고 상한과 스윕

핫 지갑에는 상한을 둡니다.

• 예: 운영 상한 10 ETH
• 초과분은 주기적으로 웜이나 콜드로 스윕

1.2 실무 패턴: 출금은 상태다

출금은 단일 API가 아니라 상태로 다뤄야 합니다.

• 요청 접수
• 위험 평가와 정책 적용
• 서명 생성
• 브로드캐스트
• 확정 정책 충족
• 사용자 통지
• 회계 반영

핫 지갑은 이 상태 머신의 서명 단계를 빠르게 하지만, 동시에 사고를 빠르게 만듭니다.

---

 

2) 키를 어디에 두는가: 키 저장소 옵션 5개

옵션	요약	장점	단점
앱 내 키	지갑 앱이 키를 저장	간단	디바이스 보안에 의존
서버 키	백엔드가 키 보유	자동화 쉬움	서버 침해 시 치명적
HSM	하드웨어 보안 모듈	추출 난이도 상승	비용과 운영 복잡
멀티시그	여러 키의 합의	단일 키 리스크 감소	서명 절차가 느림
MPC	키를 조각내 분산 서명	키 단일 보관을 피함	구성과 복구가 어렵다

서비스 관점에서 제일 흔한 조합은

• 핫: 서버 키 또는 MPC
• 웜: 멀티시그 또는 MPC
• 콜드: 오프라인 멀티시그 또는 콜드 보관

입니다.

---

 

3) 시드와 HD 지갑: 주소가 많아도 백업은 하나로 끝내는 방법

3.1 시드란 무엇인가

지갑에서 흔히 말하는 시드는 보통

• 니모닉 문구로 표현되는 비밀값

입니다. 니모닉은 사람이 적어둘 수 있게 만든 표현이고, 핵심은 그 뒤의 시드 비트열입니다.

3.2 HD 지갑이란 무엇인가

HD는 Hierarchical Deterministic 입니다.

• 하나의 시드에서
• 무수히 많은 개인키와 주소를 파생한다

여기서 결정적이라는 말은

• 같은 시드면 같은 키 트리가 다시 만들어진다

는 뜻입니다.

 

참고 : 키 파생에 대한 자세한 설명
니모닉으로부터 KDF로 seed 64바이트를 만들고, seed에서 HMAC-SHA512로 마스터 키 재료 32바이트와 chain code 32바이트를 만든 뒤, 각 노드에서 chain code를 HMAC의 key로 사용하고 index 0,1,2… 를 HMAC 입력에 넣어 매번 새로운 64바이트 출력을 얻어 그중 32바이트로 EC 연산을 통해 자식 개인키를 만들며, 동시에 나머지 32바이트는 다음 노드의 chain code로 갱신되면서 트리로 확장된다.

 

3.3 왜 서비스와 사용자 모두 HD를 좋아하나

• 백업이 단순하다. 니모닉 하나
• 주소를 재사용하지 않기 쉬워져 프라이버시가 개선된다
• 계정과 주소를 논리적으로 분리할 수 있다

참고: hardened 파생은 슬래시 경로에서 h 표기로 자주 씁니다.
예: m/44h/60h/0h/0/i

---

 

4) MPC 개요: 키를 나누고 서명은 같이 한다

MPC는 참여자들이 DKG 같은 분산 키 생성으로 개인키가 단일 지점에 나타나지 않게 secret share를 만들고 이를 인증된 암호화 채널로 교환해 각자 보관한 뒤, secure computation으로 임계치 t of n에서만 ECDSA와 동일하게 검증되는 정상 서명을 합성하는 분산 서명 프로토콜이다.

4.1 MPC가 해결하려는 문제

서버가 키를 한 번이라도 완전한 형태로 갖는 순간

• 침해 시 손실이 커진다

MPC는 이를 줄이기 위해

• 개인키를 여러 조각으로 나누고
• 각 조각이 부분 연산을 수행해
• 최종 서명만 합성되게

만듭니다. 목표는

• 어떤 단일 노드도 완전한 키를 가지지 않게 하기

입니다.

4.2 멀티시그와 MPC의 차이

멀티시그는 온체인 정책입니다.

• 트랜잭션 자체가 여러 서명을 요구한다

MPC는 오프체인 서명 방식입니다.

• 체인에는 일반 EOA 서명처럼 보일 수 있다

따라서 차이는 운영에 직접 반영됩니다.

비교	멀티시그	MPC
체인 상 가시성	여러 서명이 보인다	일반 서명처럼 보일 수 있다
통합 난이도	온체인 컨트랙트 필요	오프체인 시스템 필요
장애 모델	서명자 부재가 지연	조각 노드 장애가 지연
복구	서명자 교체로 대응	키 조각 재구성이 핵심

4.3 MPC가 해결하지 못하는 것

• 정책 자체가 없으면 키 분산만으로는 사고를 막지 못한다
• 충분한 임계치 조합이 탈취되면 끝이다
• 운영 실수, 잘못된 출금 정책은 MPC로도 막기 어렵다

즉, MPC는 보안의 전부가 아니라

• 키 보관 방식의 선택지

입니다.

---

 

결론

• 핫 웜 콜드는 돈을 나누는 게 아니라 권한과 피해 반경을 나누는 설계다
• HD 지갑은 주소 수와 무관하게 백업과 운영을 단순하게 만든다
• MPC는 단일 키 보관을 피하지만, 정책과 운영 절차 없이는 완전한 해결책이 아니다