
다중 서명이 단일 장애 지점이 될 때, Safe 지갑 사용자는 어디로 가야 하나?
2025년 2월 21일, 암호화폐 거래소 바이비트(Bybit)가 해킹을 당해 약 15억 달러 상당의 자산이 유출되는 사건이 발생했다. 이 사고는 단순히 암호화폐 도난 기록을 갱신한 것에 그치지 않고, 업계 표준으로 여겨지는 멀티시그(다중 서명) 보안 메커니즘조차 우회할 수 있다는 점에서 전 산업계에 충격을 안겼다.
사후 분석 결과, 공격자는 Safe 개발자의 장비를 탈취하여 Safe{Wallet} 서버상의 프론트엔드 JavaScript 코드를 조작한 것으로 밝혀졌다. 바이비트의 멀티시그 소유자가 로그인하면 정상적인 거래처럼 화면에 표시되지만, 실제로 서명하는 내용은 완전히 다른 것이었고, 이로 인해 자금이 유출된 것이다.
이번 사건은 다음과 같은 근본적인 질문을 제기한다. 과연 멀티시그 지갑 자체에 문제가 있는가? 아니면 우리가 그것을 사용하는 방식에 문제가 있었던 것인가?
보안의 맹점: 보이지 않는 단일 실패 지점
바이비트 사고 이후 하나의 핵심 질문이 대두되었다. 정말로 Safe는 안전한가?
우선 인정해야 할 것은, Safe 스마트 계약 자체는 안전하다는 점이다. 전체 코드는 오픈소스이며 다수의 보안 업체의 검증을 거쳤으며, 운영 역사 동안 중대한 계약 취약점은 발견되지 않았다. 그러나 보안은 오직 계약 코드만의 문제가 아니다.
실제로 보안 리스크는 매우 긴 신뢰 체인(trust chain) 전반에 걸쳐 있다. Safe 지갑을 사용할 때, 서명자는 여러 요소에 의존하게 된다: 서명 장비, 운영체제, 웹 브라우저, 지갑 플러그인, Safe UI, RPC 노드, 블록체인 탐색기, 하드웨어 지갑 및 그 소프트웨어 등. 이 체인이 너무 길기 때문에, 해커는 그 중 한 고리를 뚫기만 하면 막대한 보상을 얻을 수 있다.
바이비트 사고에서 공격자는 눈에 띄지 않아 보이는 한 고리인 '웹 프론트엔드'를 선택했다. Safe{Wallet} 서버를 공격하여 JavaScript 코드를 교체한 것이다. 사용자는 마치 정상적인 거래를 서명하는 것처럼 느꼈지만, 실제로는 악성 업그레이드(CALL을 DELEGATE_CALL로 변경)를 승인하고 있었던 것이다.
좀 더 깊이 분석해 보면, 이러한 보안 취약점의 근본 원인은 바로 '신뢰 체인 내 교차점(crossing point)'에 있다. 멀티시그 지갑은 본래 여러 사람이 독립적으로 검증하는 보안 체인을 구성해야 한다. 이상적인 상황에서는 각 서명자가 독립된 도구와 방법을 사용해 거래를 검증해야 한다. 하지만 현실에서는 서명자들이 종종 동일한 웹 인터페이스, 동일한 RPC 노드 세트, 유사한 하드웨어 지갑 및 검증 절차를 공유한다.
이것이 중요한 보안 허점을 드러낸다. 모든 서명자가 동일한 웹 인터페이스에 의존한다면, 공격자는 그 공유된 단일 지점을 통제하기만 하면 모든 서명자를 동시에 속일 수 있다. 이는 Safe만의 특수한 문제라기보다, 멀티시그 운용에서 널리 존재하지만 자주 간과되는 보안 맹점이다.
이러한 공유 지점들이 바로 보안 체인의 약점이다. 해커는 단 하나의 교차점을 공격함으로써 모든 사람에게 영향을 미칠 수 있다.
이 사례는 우리에게 깊은 교훈을 준다. 보안은 단 하나의 도구가 아니라, 체계적인 실천 방식(systematic practice)이라는 점이다. 최고 수준의 멀티시그 도구를 갖추었다고 해서 안전이 보장되는 것은 아니다. 핵심은 그러한 도구들을 어떻게 활용하여 완전한 보안 프로세스를 구축하느냐 하는 것이다.
기관 및 거래소의 경우 이 인식은 특히 시급하다. 2024년 데이터에 따르면, 암호화폐 도난 피해액은 전년 대비 67% 증가해 4.94억 달러에 달했으며, 피해 주소 수는 3.7%만 증가했다. 공격자들은 이제 명확히 '정밀 타격(Precision Sniper)' 전략을 채택해 고가치 대상만을 노리고 있으며, 가장 큰 단건 도난액은 무려 5548만 달러에 달했다. 당신의 자산 규모가 기관 수준에 도달하면, 해커들의 주요 목표가 되며, 어떤 보안 타협도 재앙을 초래할 수 있다.
바이비트의 손실은 바로 이 깊은 교훈을 제공하며, 업계 전체에 경종을 울렸다. 진정한 멀티시그 보안은 단순히 많은 서명자가 필요한 것이 아니라, 다중의 독립된 검증 경로가 필요하다는 점이다. 모든 사람이 동일한 정보원에 의존한다면, 아무리 많은 서명자가 있어도 진정한 보안은 불가능하다.
즉, Safe 자체는 매우 안전할 수 있지만, 전제 조건은 올바른 방식으로 사용하고, 보안 체인의 모든 고리를 이해하고 있어야 한다는 것이다. 이는 고자산 보유자에게 특히 중요하다.
MPC + Safe: 더욱 강력한 보안 조합?
15억 달러라는 막대한 손실을 입은 바이비트 해킹 사건에서 우리가 배운 것이 있다면, 그것은 바로 보안의 본질에 대한 재고찰이다. 멀티시그 지갑의 안전성은 서명자의 수에 있지 않고, 검증 경로의 독립성에 있다.
모든 사람이 동일한 웹 인터페이스를 본다면, 완벽한 단일 실패 지점(Single Point of Failure)이 만들어진다. 해커는 그 지점 하나만 공격하면 모두를 속일 수 있다. 이것이 바로 바이비트 사건의 진실이다.
그렇다면 우리는 멀티시그의 권한 분산 장점을 유지하면서도, 검증 경로의 독립성을 강화할 수 있을까?
MPC와 Safe의 결합이 해답이 될 수 있다. 이 조합은 두 기술의 장점을 계승할 뿐 아니라, 새로운 보안 패러다임을 창출할 수 있으며, 현재 멀티시그 운용에서 존재하는 '공유 신뢰 지점(shared trust points)' 문제를 근본적으로 해결할 가능성이 있다.
Cobo Portal의 MPC+Safe 결합 보안 설계는 두 가지 핵심 원칙을 기반으로 한다:
검증 경로 분리(Decoupling Verification Chain)
기존 멀티시그 솔루션에서는 모든 서명자가 동일한 인터페이스, RPC 노드, 파싱 로직을 공유하여 위험한 '집중된 신뢰 지점'을 형성한다. 더 안전한 솔루션은 이러한 패턴을 깨뜨리고, 분리된 검증 시스템을 구축해야 한다:
-
분리된 서명 인프라(MPC 또는 HSM)
-
자체 운영하는 RPC 노드 네트워크(Safe에서 제공하는 노드에 의존하지 않음)
-
독립적인 거래 내용 파싱 서비스 계층(각 서명자가 실제 거래 내용을 확인할 수 있도록 보장)
-
기존 웹 UI와 완전히 분리된 전용 승인 인터페이스
Cobo가 출시한 'Safe{Wallet} 협의 서명(Co-signing)' 솔루션은 바로 이러한 철학에 기반하여 개발되었으며, Safe 멀티시그 지갑 내 하나의 서명자 역할을 수행하되, 다른 서명자들과는 완전히 독립된다.
그동작 원리는 다음과 같다. Cobo Portal은 Safe 서비스로부터 서명 대기 중인 거래를 가져와 독립된 리스크 컨트롤 시스템으로 심사한 후, MPC 지갑 또는 전托管 HSM 지갑을 사용해 서명을 완료하고, 서명 결과를 다시 시스템에 반영한다.
바이비트 사고 사례로 보면, 공격자가 Safe 인터페이스를 장악하더라도 Cobo의 독립 검증 시스템은 여전히 실제 거래 내용과 위험 경고를 표시할 수 있다.
최소 권한 원칙(Principle of Least Privilege)
Cobo의 보안 제품인 Cobo Safe 권한 분리 모듈은 간단하지만 강력한 개념을 구현한다: 콜드월렛은 결코 모든 권한을 가질 필요가 없다는 것이다.
거래소 사례를 들어보자. 콜드월렛의 주요 업무는 핫월렛에 자금을 입금하는 것이다. 그러나 매번 핫월렛에 자금이 필요할 때마다 관리자는 콜드월렛의 완전한 제어권을 행사하여 송금해야 하므로, 불필요한 리스크 노출이 증가한다.
Cobo Safe 솔루션은 직관적이다. 특정 작업만 수행 가능한 '제한된 운영자(Restricted Operator)' 역할을 생성할 수 있다. 이 역할은 오직 미리 설정된 핫월렛 주소로 허용된 화이트리스트 자산을 전송하는 권한만을 가진다. 일상 운영은 이 낮은 권한의 주소를 통해 수행되며, 주요 Safe 지갑은 자주 사용할 필요가 없다. 사용자는 또한 Safe의 블랙/화이트리스트를 직접 설정할 수 있으며, 호출 가능한 대상 컨트랙트를 제한함으로써 권한 통제를 더욱 강화할 수 있다.
즉, 해커가 이 운영자 계정을 완전히 장악하더라도 할 수 있는 유일한 일은 거래소 자신의 핫월렛으로 송금하는 것뿐이다. 지갑 설정 수정 권한 없음, 다른 주소로 전송 불가, 화이트리스트 외 자산 사용 불가.
Cobo Portal을 사용했다면, 15억 달러 유출 사고는 일어났을까?
공격자의 행동 방식을 이해하면 효과적인 방어선을 설계할 수 있다. 바이비트 공격 시나리오에서 Cobo Portal의 방어 메커니즘이 어떻게 작동할지 시뮬레이션해보자.
시나리오 재현
공격 단계 1: Safe 프론트엔드에 악성 JavaScript 코드 주입
-
Safe 멀티시그 방식: 모든 서명자가 공격받은 동일한 인터페이스를 사용하며, 위장된 거래 내용을 확인함;
-
Cobo Safe{Wallet} 협의 서명 방식: Safe 인터페이스가 공격을 당했더라도, Cobo의 독립 승인 앱에는 영향 없음. 실제 거래 내용이 표시됨.
공격 단계 2: 위장된 거래 요청에 서명 요청
-
Safe 멀티시그 방식: 서명자는 '핫월렛으로 송금'이라고 보지만, 실제로는 업그레이드를 승인하고 있음;
-
Cobo Safe{Wallet} 협의 서명 방식: 독립 검증 경로가 실제 거래가 Delegate Call임을 파악하고, 앱에 위험 경고 표시.
공격 단계 3: 서명 수집 후 공격 실행
-
Safe 멀티시그 방식: 충분한 서명을 확보하면, 공격자가 계약 제어권을 획득함;
-
Cobo Safe{Wallet} 협의 서명 방식: 실제 거래 내용과 위험 경고를 표시하여 서명자가 공격 행위를 식별할 수 있게 함.
공격 단계 4: 멀티시그 방어선 우회
-
Safe 멀티시그 방식: 공격자가 계약 제어권을 얻으면 모든 자산을 이전할 수 있음;
-
Cobo Safe 솔루션 병행 사용 시: 앞선 모든 방어선이 무너지더라도, Cobo Safe의 권한 분리 덕분에 공격자는 사전 승인된 작업(예: 화이트리스트 핫월렛으로 송금)만 수행 가능.
Cobo Portal의 독립 검증 방어 체계 아래에서, 바이비트 공격자는 여러 단계에서 차단될 것이다. 주목할 점은, Cobo Safe{Wallet} 협의 서명과 Cobo Safe는 각각 독립된 제품이지만, 두 시스템을 함께 사용하면 보안 수준이 더욱 높아진다는 점이다. 독립 검증 방어선이 무너지더라도, 권한 분리 시스템은 잠재적 손실 범위를 효과적으로 제한할 수 있다. 이러한 다층 방어 전략을 통해, 이 15억 달러의 자산 손실은 완전히 피할 수 있었을 것이다.
보안은 보험이다. 사람들은 언제나 재난이 발생한 후에야 그 중요성을 깨닫는다.
불행히도, 이 업계는 이미 천문학적인 수업료를 치렀지만, 그만큼 암호화 보안에 대해 다시 생각할 기회를 얻었다. 보안은 비대칭 게임이다. 공격자는 단 하나의 취약점만 찾으면 되지만, 방어자는 모든 고리를 반드시 지켜야 한다. 수십억 달러의 자산이 놓여 있다면, 최정상급 해커뿐 아니라 무한한 자원을 가진 국가급 공격자까지도 몇 달에서 몇 년에 걸쳐 당신의 시스템을 연구하며 유일한 약점을 찾아낼 것이다.
그래서 바로 Cobo가 Safe{Wallet} 협의 서명 솔루션을 개발한 이유다. 우리는 핵심 문제를 해결하고자 했다. 단일 실패 지점을 어떻게 제거할 것인가? 답은 바로 검증 프로세스 전체를 재구성하여 다중 보안 장치를 실현하는 것이다. 대규모 자산을 관리하는 기관에게 보안은 효율성과 대립되는 것이 아니라, 전제조건이다. 보안이 없다면 효율성 자체가 성립할 수 없다.
Cobo 내부에서는 오랫동안 이 시스템을 사용해왔다. 보안 사고가 빈번히 발생하자, 우리는 이러한 보안 실천이 우리만의 것이 아니라 더 많은 사용자에게 혜택을 주어야 한다는 것을 깨달았다. 그래서 이를 제품화하고 30일 무료 체험을 시작했다. 이 솔루션이 여러분의 자산을 보호할 뿐 아니라, 여러분의 피드백을 통해 계속 최적화되고 업그레이드되어 보안 체계가 더욱 견고해지기를 바란다.
보안은 일회성 투자가 아니라, 지속적으로 진화하는 과정이다. 위협이 끊임없이 진화하듯, 보안 방어도 지속적으로 반복 개선되어야 한다. 오직 집중과 끈기만이 변화하는 리스크 환경에 진정으로 대응할 수 있다.
대규모 암호자산을 관리하고 있거나, 고자산 보유자라면, Cobo Safe{Wallet} 협의 서명 솔루션을 무료로 체험해보고 사용 경험을 공유해주기 바란다. 암호화 산업에서 보안은 언제나 가장 중요한 일이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News














