"개인 키가 유출되지 않았다"는 가장 위험한 위안제: 진정으로 신뢰할 수 있는 암호화 제품을 어떻게 선택할까?
암호화폐 제품에서 사용자 개인키 유출 사고가 단 한 번도 발생하지 않았다면, 그것이 충분히 안전하다는 뜻일까?
답은 분명 그렇게 간단하지 않다.
잘 알려진 바와 같이, 9월 하순부터 10월 말까지 암호화폐 업계는 상당히 집중적인 보안 시험대를 거쳤다. 글로벌 주요 중앙화 거래소부터 오랜 역사를 지닌 유명 하드웨어 지갑 제조사에 이르기까지, 영향력이 큰 보안 사고가 연달아 발생했다.
이러한 사건 이후의 공식 발표를 자세히 살펴보면, 반복적으로 등장하는 표현이 있다. 바로 "개인키가 유출되었다는 증거는 없다"거나 "사용자 개인키와 니모닉은 영향을 받지 않았다"는 것이다.
그러나 공격자가 찾는 진입점은 개인키에 있지 않을 수 있다. 거래소의 내부 권한이 도용될 수 있고, 제3자 보안 제품이 관리 시스템으로 들어가는 발판이 될 수 있으며, 하드웨어 기기에 악성 모듈이 심어질 수 있고, 심지어 사용자의 실명, 연락처, 자택 주소가 데이터 유출로 노출될 수도 있다. 단순히 "개인키가 유출되지 않았다"고 강조하는 것만으로는 사용자가 직면한 모든 위험을 포괄하기에 분명 부족하다.
결국 개인키 보안은 암호화폐 자산 안전의 출발점일 뿐, 종착점은 아니다.
이는 또한 우리가 한 가지 질문을 다시 검토해야 함을 의미한다. 오늘날의 암호화폐 세계에서 어떤 제품이 진정으로 안전하고 신뢰할 수 있는지 어떻게 판단해야 하는가?
1. 공격자는 어떻게 개인키를 우회하며, 자산과 데이터는 어떻게 무너지는가?
지난 글에서 언급했듯이, 최근의 보안 사건들을 함께 놓고 보면 뚜렷한 추세가 보인다. 공격자가 반드시 암호학과 개인키 자체를 직접 돌파해야 하는 것은 아니며, 오히려 전체 '신뢰 체인'에서 돌파구를 찾을 수 있다.
직원 단말기, 제3자 보안 제품부터 소프트웨어 공급망, 서비스 컨테이너, 나아가 거래 승인 프로세스에 이르기까지, 어느 한 고리에서든 균열이 생기면 본래 견고해 보이던 보안 체계가 무력화될 수 있다.
- Bybit 사건에서 공격자는 사회공학적 수법으로 Safe 개발자 한 명의 기기를 침해해 관련 접근 자격 증명을 확보했고, 이를 통해 Safe 지갑 인프라의 프런트엔드 리소스를 통제했다.
- Bitget 사건에서 공격자는 제3자 보안 제품의 취약점을 악용해 내부 고권한 자격 증명을 획득한 뒤, 위조된 출금 지시로 기존 리스크 통제 메커니즘을 우회했다.
- 최신 Binance 사건에서는 공격 경로가 DevOps 엔지니어 한 명의 노트북 침해에서 시작되었을 가능성이 높다. 다만 Binance는 이후 추가 조사에서 다른 침입 지점도 발견했으며, 전체 공격 경로는 여전히 확인 중이라고 밝혔다.
세 사건은 각각 제3자 지갑 인프라, 제3자 보안 제품, 내부 개발 및 운영 환경과 관련되어 있다.
이는 전통적인 콜드월렛과 멀티시그 메커니즘이 모든 문제를 해결할 수 없는 이유도 설명해 준다. 공격자가 실제로 악용하는 것은 바로 최종 거래 실행에 영향을 줄 수 있으면서도 충분히 독립적으로 검증되지 않은 신뢰 고리이기 때문이다.
결국 중앙화 자산 관리 체계에서 공격자가 반드시 사용자 개인키를 직접 획득해야 하는 것은 아니며, 거래 지시, 승인 프로세스 또는 지갑 실행 시스템을 통제할 수만 있다면 승인되지 않은 자산 이전을 촉발할 수 있다.
그리고 자산 실행 체인 외에도 일반 사용자가 더 쉽게 과소평가하는 또 다른 위험이 있다. 바로 데이터 유출이다.
2025년 5월, Coinbase는 내부 인원의 데이터 절취 사건을 공개했다. 공격자는 일부 해외 고객센터 직원에게 뇌물을 제공해 이들의 정상 업무 권한으로 내부 고객 지원 시스템에 접근하게 했고, 일부 사용자의 개인정보, 계정 정보, 거래 관련 정보를 절취했다.
Coinbase는 이 사건으로 사용자 비밀번호, 개인키 또는 자금이 직접 유출되지는 않았다고 밝혔지만, 공격자가 이러한 자료를 확보한 목적은 이후 정교한 사회공학 공격을 실행해 공식 고객센터 직원을 사칭하며 사용자의 자산 이전을 유도하기 위한 것이었다.
Keystone 사건은 사용자 데이터 유출이 하드웨어 지갑의 기기 진위 검증에도 영향을 미칠 수 있음을 더욱 분명히 보여준다.
10월 20일 Keystone 공식 웹사이트가 승인되지 않은 접근을 당했다. 이후 공개된 내용에 따르면, 공격자는 웹사이트 제3자 데이터 모니터링 도구의 취약점을 악용해 일부 사용자의 구매 기록과 기기 진위 확인에 사용되는 WebAuth 키를 획득했다.
이는 사용자의 니모닉과 개인키가 직접 유출되지 않았더라도, 공격자가 탈취한 검증 키를 이용해 공식 인증을 통과하는 위조 기기를 제작할 수 있으며, 사용자가 이를 인지하지 못한 채 위험이 있는 하드웨어 지갑을 사용하게 만들 수 있음을 의미한다.
Ledger가 폭로한 기기 및 공급망 보안 문제는 말할 것도 없다. 이는 제조사가 하드웨어 생산, 인증, 물류, 판매 과정에서 기기가 교체되거나 변조되거나 악성 모듈이 심어질 가능성을 차단해야 함을 요구한다.
이 문제들은 제품의 서로 다른 위치에서 발생하는 것처럼 보이지만, 최종적으로는 동일한 결과로 수렴할 수 있다. 바로 사용자가 자신의 자산에 대한 통제권을 상실하는 것이다.
따라서 개인키가 직접 유출되지 않았다고 해서 제품 전체의 보안 체계가 무너지지 않았다는 뜻은 아니며, 특히 AI의 빠른 발전이 이러한 위험을 더욱 확대하고 있다.
2. 암호화폐 제품이 안전하고 신뢰할 수 있는지 어떻게 판단할까?
이러한 사건들을 이해했다면, 다시 일반 사용자가 실제로 직면하는 문제로 돌아가 보자. 비교적 안전하고 신뢰할 수 있는 암호화폐 제품을 선택하려면 도대체 무엇을 봐야 할까?
브랜드 인지도, 제품 기능, 마케팅 홍보보다 imToken은 최소 세 가지 차원을 우선적으로 고려할 가치가 있다고 본다.
1. 개인키 통제권: 자산은 결국 누가 통제하는가?
이는 암호화폐 제품의 보안 아키텍처를 판단할 때 가장 기본적이면서도 가장 중요한 문제다.
먼저 완전히 다른 두 가지 모델, 즉 수탁형과 비수탁형을 구분해야 한다.
중앙화 거래소를 예로 들면, 사용자는 일반적으로 계정 체계를 통해 자신의 자산을 관리한다. 입금 후 자산은 거래소가 통제하는 지갑 체계로 들어가며, 플랫폼은 내부 계정 시스템으로 사용자 잔액을 기록하고 출금, 리스크 통제, 자금 관리를 담당한다.
이 모델의 장점은 사용이 편리하다는 것이다. 사용자가 직접 개인키를 관리할 필요가 없지만, 동시에 플랫폼의 자산 수탁, 내부 권한, 운영 관리 메커니즘을 신뢰해야 함을 의미한다. 플랫폼에 시스템 장애, 내부 권한 통제 불능 또는 자금 관리 문제가 발생하면 사용자는 자산에 정상적으로 접근하거나 인출하지 못할 수 있다.
비수탁형 지갑은 다르다.
사용자가 지갑을 생성할 때 개인키는 로컬 환경에서 생성되고 사용자가 직접 보관하며, 지갑은 주로 키 관리, 거래 구성, 서명 등의 기능을 담당하고 실제 자산은 블록체인에 기록된다.
구조적으로 보면两者에는 뚜렷한 차이가 있다.
- 중앙화 수탁: 사용자 → 플랫폼 계정 및 권한 체계 → 플랫폼이 통제하는 지갑 → 온체인 자산
- 비수탁형 지갑: 사용자가 개인키 보유 → 지갑이 관리 및 서명 도구 제공 → 사용자가 직접 통제하는 온체인 주소
이는 비수탁형 모델이 자산 수탁자로서 플랫폼의 역할을 줄이고, 사용자가 자산을 통제하기 위해 중앙화 플랫폼에 의존해야 하는 단계도 줄인다는 것을 의미한다.
물론 이것이 비수탁형 지갑이 절대적으로 안전하다는 뜻은 아니다.
사용자는 직접 니모닉을 백업하고 기기 보안을 유지하며, 모든 거래와 서명에 책임을 져야 한다. 니모닉이 유출되거나 사용자가 자발적으로 악성 거래에 서명하면 자산은 여전히 손실될 수 있다.
따라서 지갑을 선택할 때는 최소한 세 가지 질문을 명확히 해야 한다. 개인키가 사용자 기기에서 생성되는가, 아니면 서버에서 생성되는가? 개인키와 니모닉이 서비스 제공업체 서버에 업로드되는가? 사용자가 실제로 서명권을 보유하고 있으며, 다른 호환 지갑에서 자신의 자산을 복구할 수 있는가?
2. 데이터 프라이버시: 제품은 도대체 당신에 대해 얼마나 많은 정보를 수집하는가?
두 번째 차원은 많은 사용자가 쉽게 간과하는 프라이버시 보호다.
암호화폐 제품을 사용하는 과정에서 사용자는 이메일, 휴대전화 번호, 신원 인증 자료, 기기 정보, 구매 기록, 물류 주소, 심지어 계정 잔액과 거래 내역까지 많은 정보를 남길 수 있다.
이러한 데이터가 모든 제품에서 반드시 수집되어야 하는 것은 아니다.
예를 들어 중앙화 거래소는 계정 체계와 규제 요건과 관련되어 일반적으로 신원 인증이 필요하다. 반면 기본적인 비수탁형 지갑의 핵심 기능은 로컬에서 키를 관리하고 온체인 거래를 시작하는 것이며, 같은 방식으로 사용자의 실제 신원 정보를 파악할 필요는 없다.
여기서 가장 주목할 점은 제품이 필요한 데이터 최소화 원칙을 준수하는지 여부다.
예를 들어 사용자의 실제 신원, 연락처, 기기 정보, 온체인 주소가 불필요하게 연결되어 있는가?
이러한 데이터가 중앙 집중적으로 저장되면 공격자는 완전한 사용자 프로필을 더 쉽게 구축할 수 있고, 이는 '5달러 렌치 공격'으로 이어질 수 있다. 아무리 강력한 암호 알고리즘도 공격자가 자산 보유자를 직접 찾아내는 문제를 해결할 수는 없기 때문이다. (관련 읽기: 《Web3 지갑의 '다사다난한 시기': AI 시대, Crypto 보안의 '창과 방패' 진화를 어떻게 이해할 것인가?》)
3. 보안 아키텍처: 지속적으로 검증된 보안 메커니즘이 있는가?
세 번째 차원은 제품 이면의 기술적 보안 역량이다.
소프트웨어 지갑의 경우 개인키 생성, 암호화 저장, 거래 서명, 코드 보안에 중점을 두어야 한다. 하드웨어 지갑의 경우 보안 칩, 펌웨어 무결성, 기기 인증, 공급망 관리까지 추가로 주목해야 한다.
그러나 어떤 제품이든 공통적으로 적용할 수 있는 판단 기준이 있다.
첫째, 핵심 코드가 검토 가능한지 여부다. 오픈소스가 절대적 안전을 의미하지는 않지만, 최소한 외부 개발자와 보안 연구원이 핵심 코드를 검토할 기회를 가질 수 있다.
둘째, 독립적인 보안 감사를 거쳤는지 여부다. 제품이 전문 보안 기관과 협력하는지, 감사가 어떤 모듈과 어떤 버전을 대상으로 하는지, 발견된 문제가 수정되었는지에 주목할 수 있다.
유의할 점은 감사 보고서는 특정 시점과 특정 범위의 보안 평가일 뿐이며, 제품 전체에 이후 취약점이 존재하지 않는다는 의미는 아니라는 점이다.
셋째, 취약점 보상 및 지속적 테스트 메커니즘을 구축했는지 여부다. 보안은 일회성 작업이 아니며, 제품이 계속 업그레이드되고 새로운 체인과 제3자 구성 요소가 연결되면서 공격 표면도 계속 변화한다. 따라서 공개된 취약점 피드백 채널, 취약점 보상 프로그램, 그리고 잘 갖춰진 버전 검토 및 권한 관리 메커니즘이 있는지는 주목할 만한 지표다.
마지막으로 제품이 충분한 보안 투명성을 갖추고 있는지도 봐야 한다. 보안 사고 발생 후 영향 범위, 공격 원인, 사용자 대응 조치, 수정 진행 상황을 적시에 공개할 수 있는지 역시 한 제품이 장기적으로 신뢰할 가치가 있는지를 가늠하는 중요한 기준이다.
결국 보안 감사, 오픈소스, 하드웨어 격리, 취약점 포상금은 각각 독립적인 부적이 아니다.
진정으로 신뢰할 수 있는 보안 체계는 위험을 가능한 한 국소적으로 격리하여, 어느 한 고리에서 문제가 발생하더라도 쉽게 사용자 자산 통제권의 전면 상실로 이어지지 않도록 해야 한다.
