블록체인 기반 디지털 자산을 금융기관이 직접 보관하려면 “키(Key) 관리”가 핵심입니다. 개인키를 잃으면 자산을 영구히 잃고, 탈취당하면 전액이 즉시 사라집니다. 이 글에서는 금융기관 커스터디 시스템의 내부망 보안 구조 — MPC, HSM, Hot/Cold Wallet 분리, 다단계 승인 워크플로우를 처음부터 완전히 해설합니다.
왜 키 관리가 이렇게 복잡한가
은행에서 고객 예금은 중앙 DB에 숫자로 저장됩니다. 잘못된 거래는 취소하거나 되돌릴 수 있습니다. 하지만 블록체인 자산은 다릅니다.
- 개인키를 가진 사람이 자산의 실질적 소유자입니다
- 트랜잭션은 한 번 온체인에 올라가면 되돌릴 수 없습니다
- 키를 잃으면 복구 방법이 없습니다
- 키가 탈취되면 전액이 수 초 안에 이체됩니다
2022년 Ronin Network 해킹: 개인키 5개 중 4개가 단일 공격자에게 탈취되어 6,250억 원 상당의 자산이 15분 만에 빠져나갔습니다. 멀티시그 구조였지만 키 관리가 집중화되어 있었던 것이 문제였습니다.
내부망 보안 전체 구조
소액 · 자동처리
대액 · 수동승인
MPC: 키를 나눠 가지는 기술
MPC vs 멀티시그 — 무엇이 다른가
둘 다 “여러 곳에서 승인”하는 방식이지만 근본적으로 다릅니다.
| 항목 | 멀티시그 (Multisig) | MPC |
|---|---|---|
| 서명 방식 | 온체인에서 N개 서명 검증 | 오프체인 분산 연산 후 서명 1개 생성 |
| 온체인 흔적 | 멀티시그 구조 노출 | 일반 서명처럼 보임 |
| 가스 비용 | 서명 수만큼 증가 | 단일 서명과 동일 |
| 키 탈취 시 | N-1개 탈취 시 안전 | 임계값 미만 탈취 시 안전 |
| 완전한 키 존재 여부 | 각 서명자 서버에 키 존재 | 어느 곳에도 완전한 키 없음 |
MPC 작동 원리
서버 A: 키 조각 s1 보유
서버 B: 키 조각 s2 보유
서버 C: 키 조각 s3 보유
서명 요청 →
A와 B가 각자의 조각으로 분산 연산 참여
↓
완전한 키를 조합하지 않고
연산 결과를 합쳐 서명 1개 생성
↓
유효한 서명 — 어디에도 완전한 키는 존재하지 않았음
멀티시그는 각 서명자 서버에 완전한 개인키가 있습니다. MPC는 키 조각만 있고, 연산 과정에서도 완전한 키가 한 곳에 모이는 순간이 없습니다. 서버 A가 해킹되어도 s1 조각만 탈취되고, 단독으로는 서명이 불가능합니다.
온체인에서 멀티시그 구조가 드러나지 않아 공격 타깃이 되기 어렵습니다. 가스비도 낮고, 블록체인 종류에 관계없이 동일한 키 관리 방식을 적용할 수 있습니다.
HSM: 서명 연산을 물리 장치 안에 가두는 기술
MPC로 키를 분산했더라도, 각 서버에서 서명 연산을 소프트웨어로 처리하면 메모리에 키 조각이 올라옵니다. 서버가 해킹되면 메모리 덤프로 키 조각을 탈취할 수 있습니다.
HSM은 이 연산을 물리적 장치 내부에서만 실행합니다.
- 서버 메모리에 키 올라옴
- 서버 해킹 → 메모리 덤프 → 키 탈취
- 키가 파일로 복사될 수 있음
- 감사 추적 어려움
- 키는 HSM 칩 내부에만 존재
- 서명 결과만 외부로 반환
- 키 자체는 HSM 밖으로 나오지 않음
- 변조 감지 시 키 자동 삭제
HSM 작동 흐름
|
| “이 데이터에 서명해줘” 요청
↓
[HSM 장치]
|
| 내부에서 키 조각 + 데이터로 서명 연산
| (키는 HSM 밖으로 절대 나오지 않음)
↓
| 서명 결과만 반환
↓
[서명 완료 — 키는 어디에도 노출되지 않음]
금융권 규제(전자금융감독규정, ISMS-P)에서는 암호키를 HSM 또는 이와 동등한 수준의 보안 장치에서 관리하도록 요구합니다.
Hot Wallet vs Cold Wallet: 피해 범위를 한정하는 설계
아무리 MPC와 HSM을 잘 구축해도 시스템이 항상 온라인이면 공격 노출 시간이 길어집니다. Hot/Cold 분리는 “언제나 온라인인 자산의 규모를 최소화”하는 전략입니다.
| 항목 | 🔥 Hot Wallet | 🧊 Cold Wallet |
|---|---|---|
| 연결 상태 | 항상 온라인 | 오프라인 / 에어갭 |
| 용도 | 소액 자동 처리 | 대액 수동 승인 |
| 잔액 한도 | 정책 한도 이하 | 전체 자산의 대부분 |
| 서명 방식 | 자동 (Dispatcher) | 다단계 수동 승인 |
| 탈취 시 최대 피해 | 한도 금액만 | 오프라인으로 보호됨 |
Hot ↔ Cold 자동 리밸런싱
Hot 잔액 > 한도 상한
→ 초과분을 Cold로 자동 이관
Hot 잔액 < 한도 하한
→ 운영팀 알림 발송
→ 수동 승인 후 Cold에서 Hot으로 보충
승인 워크플로우: 금액 기준 다단계 서명
임계값은 기관 내부 정책에 따라 다르지만, 금액 구간별로 승인 depth를 다르게 설계하는 것이 핵심입니다. 대형 트랜잭션일수록 더 많은 사람이 명시적으로 승인해야 합니다.
대액 출금에 24~48시간 타임락을 걸어두면 승인 후에도 이상 감지 시 취소할 수 있는 시간을 확보합니다. 내부 직원에 의한 단독 출금을 방지하는 효과도 있습니다.
감사 로그 DB: 불변 기록
모든 접근, 서명 요청, 트랜잭션 제출, 승인/거부 이력을 변경 불가능한 형태로 저장합니다.
| 기록 항목 | 목적 |
|---|---|
| 누가 언제 서명 요청했는가 | 내부자 행위 추적 |
| 어떤 주소로 얼마를 보냈는가 | 이상 거래 탐지 |
| 승인자는 누구인가 | 책임 소재 명확화 |
| HSM 접근 이력 | 물리 장치 감사 |
규제 기관 감사 시 이 로그가 핵심 증거가 됩니다. 로그 자체가 변조되지 않도록 Write-Once 스토리지나 별도 감사 체인에 저장하는 방식을 씁니다.
장애 시나리오별 대응
| 시나리오 | 대응 |
|---|---|
| MPC 참여 서버 1대 다운 | 임계값 충족하는 나머지 서버로 서명 계속 |
| HSM 장치 물리 손상 | 백업 HSM으로 키 복원 (키 생성 시 백업 절차 필수) |
| 내부 직원 키 조각 유출 의심 | 해당 서버 격리 → 키 재생성 → 나머지 조각으로 기존 자산 이전 |
| Hot Wallet 해킹 | 한도 금액만 피해, Cold는 오프라인으로 보호됨 |
| 승인자 전원 연락 불가 (재난 상황) | 긴급 복구 키(별도 보관) + 이사회 레벨 승인 프로세스 |
정리: 내부망 보안 3대 원칙
키의 단일 존재 금지
MPC로 키를 분산. 어느 한 곳에 완전한 키가 존재하는 순간이 없어야 한다.
연산의 물리 격리
HSM으로 서명 연산 격리. 키가 메모리에 노출되는 순간을 원천 차단한다.
피해 범위 제한
Hot/Cold 분리로 항상 온라인인 자산을 최소화. 최악의 해킹도 전손이 아닌 부분 손실로 막는다.
DMZ가 외부 공격으로부터 시스템을 지키는 구조라면, 내부망 보안은 내부자 위협과 시스템 침해 시에도 자산을 지키는 최후 방어선입니다. 두 레이어가 함께 작동할 때 금융기관 수준의 커스터디 보안이 완성됩니다.
About the Author
