지갑과 수탁: 누가 키를 통제하는가?

권한부터 확인하기

지갑은 블록체인과 상호작용하고 행위를 승인하는 키나 서명 체계를 관리하는 도구입니다. 자체 보관에서는 사용자가 관련 인증 정보를 통제합니다. 수탁 방식에서는 다른 조직이 이를 통제하고 자체 조건에 따라 고객에게 잔액을 기록합니다. 둘 다 휴대전화 화면에서는 비슷하게 보일 수 있으므로, 화면만으로는 법적 권리나 복구 선택지를 거의 알 수 없습니다.

실용적인 질문을 해 보세요. 제공업체의 웹사이트가 내일 사라지면 무엇으로 자산에 접근할 수 있나요? 복구 문구는 호환되는 자체 보관 지갑에서 서명 접근을 복원하게 할 수 있습니다. 수탁 플랫폼의 사용자 이름과 비밀번호는 보통 같은 독립적 능력을 주지 않습니다. 반대로 수탁기관은 자체 보관 체계가 제공할 수 없는 계정 복구를 제공할 수 있습니다.

핫 월렛, 콜드 월렛, 서명 과정

핫 월렛은 인터넷에 연결된 환경을 통해 키나 서명 기능에 접근할 수 있습니다. 콜드 스토리지 체계는 서명 비밀 정보를 오프라인에 두려는 방식입니다. 하드웨어 지갑은 키 정보를 보호할 수 있지만 모든 거래를 안전하게 만들 수는 없습니다. 의도하지 않은 전송이나 위험한 계약 권한을 승인하면, 그 지시를 안전하게 서명해도 잘못된 결정이 실행됩니다.

복구 문구는 일반적인 문제 해결 정보가 아닙니다. 이를 얻은 사람은 플랫폼 비밀번호를 몰라도 통제권을 가져갈 수 있습니다. 진짜처럼 보이는 지원 상담, 유료 검색 결과, 브라우저 확장 프로그램, 가짜 업데이트는 모두 절도의 진입점이 될 수 있습니다. 클라우드 계정에 저장한 스크린샷은 비밀 정보로 향하는 추가 경로를 만들 수 있습니다. 보안에는 단순히 기기를 사는 것이 아니라 전체 과정을 생각하는 일이 필요합니다.

수탁에는 계약과 실패 시나리오가 포함된다

수탁기관에 대해서는 법인, 자산 분리 조건, 출금 조건, 사업 실패 시 처리 방식을 살펴보세요. 기관급 같은 마케팅 문구는 고객의 법적 청구권을 명시하지 않습니다. 보험에는 한도와 제외 조항이 있을 수 있고, 수익자가 개별 고객이 아닐 수도 있습니다. 준비금 증명 정보 역시 그 자체만으로 부채나 모든 권리 부담의 완전한 모습을 보여 주지는 않습니다.

자체 보관에서는 백업의 내구성, 상속 체계, 기기 고장, 서명 실수 가능성을 살펴보세요. 더 정교한 시스템은 자체 운영 오류를 도입할 수 있습니다. 오늘 한 사람이 이해하는 설정도 미래의 유언집행자나 기기를 잃은 뒤의 본인이 사용하지 못할 수 있습니다. 적절한 목표는 최대한의 복잡성이 아니라 이해할 수 있고 시험된 절차입니다.

네트워크, 주소, 기록

토큰 심볼만으로는 전송 경로를 식별하기에 부족합니다. 비슷한 이름이 여러 네트워크에 존재할 수 있고, 수신 서비스가 특정 버전만 지원할 수 있습니다. 일부 목적지는 추가 메모나 태그를 요구합니다. 유효해 보이는 주소라고 의도한 수신자 소유임이 입증되지는 않습니다. 클립보드 악성코드와 주소 포이즈닝 수법은 피상적인 육안 확인을 악용합니다.

교육용 전송 체크리스트는 의도한 자산, 네트워크, 목적지, 추가 경로 지정 필드, 수수료, 확인 요건을 구분합니다. 소액 시험 전송은 일부 실수를 드러낼 수 있지만, 이후 거래의 안전성이나 주소가 바뀌지 않았음을 보장하지는 않습니다. 대조 확인을 위해 거래 식별자와 비용 기록을 보관하세요. 세금·신고 요건은 지역마다 다르며, 현지 지침 없이 계좌 간 자산 이동을 과세 대상 이익 계산과 혼동해서는 안 됩니다.

잔액을 바꾸지 않는 서명도 권한을 바꿀 수 있다

일부 ERC-20 토큰의 승인 기능은 특정 계약이 정해진 한도 안에서 토큰을 이전하도록 허용합니다. 승인을 부여하는 순간 잔액이 그대로여도 이후에 행사할 수 있는 권한은 달라집니다. 따라서 서명 직후 잔액이 줄지 않았다는 사실만으로 그 서명이 아무 영향도 없었다고 판단해서는 안 됩니다.

가상으로 토큰 2,400개를 가진 사람이 120개만 교환하려 한다고 해 봅시다. 승인 한도가 120개인지, 훨씬 큰 수량인지에 따라 노출 범위가 달라집니다. 자산 종류, 권한을 받는 계약 주소, 한도, 요청 목적을 따로 확인해야 합니다. 익숙한 로고나 서비스 이름만으로 실제 승인 대상을 확인할 수는 없습니다.

웹사이트 연결을 끊는 것과 온체인 승인을 철회하는 것도 별개입니다. 승인을 철회해도 이미 발생한 이전이 되돌아가지는 않습니다. 학습용 기록에는 보유 자산뿐 아니라 누가 어떤 조건에서 그 자산을 움직일 수 있는지도 포함하세요. 모든 토큰과 지갑이 같은 승인 방식을 쓰는 것은 아니므로 적용 범위를 먼저 확인해야 합니다.

백업 개수보다 함께 실패할 가능성을 살펴보기

복구 자료 두 벌이 같은 가방에 있다면 가방을 잃어버리는 한 번의 사건으로 둘 다 사라집니다. 두 파일을 같은 클라우드 계정에 저장한 경우에도 하나의 계정 침해가 공통 위험이 됩니다. 백업의 수를 세는 것만으로는 복구 가능성을 충분히 설명할 수 없습니다.

실제 비밀 정보를 사용하지 않는 종이 연습으로 휴대전화 분실, 이메일 계정 탈취, 보관 장소 접근 불가를 각각 가정해 보세요. 각 상황에서 어떤 단계로 복구하는지, 그 단계가 이미 잃어버린 기기나 접근할 수 없는 계정에 의존하는지 확인합니다. 연습 문서에 진짜 개인키나 복구 구문을 복사해서는 안 됩니다.

복잡한 장치를 더한다고 항상 전체 위험이 줄어드는 것은 아닙니다. 한 가지 공격을 막는 대신 사용자가 절차를 잊거나 필요한 자료를 잘못 조합할 가능성이 커질 수 있습니다. 책임과 복구 순서는 이해하기 쉽게 정하되 모든 비밀을 한곳에 모으지 않는 설계가 필요합니다. 평상시의 편의와 장애 상황의 실행 가능성을 함께 검토하세요.