배송업체 해킹으로 드러난 제3자 공급망 취약성
하드웨어 암호화폐 지갑 제조사 트레저(Trezor)가 2026년 8월 13일, 배송 및 물류 제공업체 쉽멍크(ShipMonk)의 시스템 해킹으로 약 1만4,000명의 고객 데이터가 유출되었다고 공식 발표했다. 이름·배송 주소·이메일·전화번호가 포함된 이번 유출은 트레저 자사 시스템이나 하드웨어 지갑 자체와는 무관하게, 물류·배송 단계의 제3자 파트너에서 발생했다. 장치 보안이 완벽해도 공급망의 한 고리가 뚫리면 사용자 정보가 공격자의 손에 넘어갈 수 있다는 사실을 이번 사고는 명확히 증명했다(Privacy Guides·Bleeping Computer, 2026-08-13).
트레저는 쉽멍크로부터 2026년 8월 10일에 시스템 무단 접근 사실을 통보받았고, 사흘 뒤인 8월 13일 고객에게 공지했다. 이번 데이터 유출은 2026년 5월 10일부터 8월 8일 사이에 접수된 주문을 대상으로 하며, 미국·영국·스웨덴·콜롬비아·브라질·이탈리아·포르투갈 등 여러 국가의 고객이 영향을 받았다.
트레저는 자사 운영·서비스·하드웨어 장치는 이번 침해로 영향을 받지 않았다고 강조했으나, 공급망의 취약 고리 하나가 수만 개의 개인 기록을 위험에 노출시켰다는 사실은 변하지 않는다(트레저 공지, 2026-08-13). 이번 유출 규모와 범위는 단순 집계 이상의 의미를 지닌다. 약 1만4,000명이라는 숫자는 국제 배송을 통해 여러 국가의 개인정보가 단일 물류업체 시스템에 집중되는 구조적 현실을 반영한다.
물리적 제품의 이동과 고객 데이터의 중앙화가 결합될 때 어떤 위험이 생기는지를 이번 사고는 구체적 수치로 보여줬다. 특히 암호화폐 하드웨어 지갑 사용자의 경우 실명·주소·연락처가 디지털 자산 보유 사실과 연결되므로, 단순 쇼핑몰 개인정보 유출과는 위협의 성격이 다르다. 트레저의 제3자 보안 문제는 이번이 처음이 아니다.
2024년 1월에도 제3자 지원 티켓 포털 해킹으로 6만6,000명의 사용자 정보가 유출된 전력이 있다. 당시 공격자들은 탈취한 이름·이메일 정보를 활용해 피싱 공격을 시도했으며, 목표는 사용자들의 24단어 복구 시드(recovery seed)였다.
광고
동일 기업에서 반복된 제3자 유출 사례는 우연한 사고가 아니라 체계적 취약성의 신호로 읽힐 수 있다. 공급망 파트너와의 데이터 접근 통제 기준, 보안 검증 주기, 사고 대응 시나리오가 얼마나 실효성 있게 설계되어 있는지 근본적으로 점검해야 할 근거다(트레저 공지, 2024-01).
하드웨어 지갑 자체 보호와 현실적 위험의 간극
공격자가 유출 정보를 활용하는 방식은 이미 알려진 경로를 따른다. 트레저는 유출 정보가 피싱 이메일·전화 사기·위조 편지 등으로 악용될 수 있으며, 은행·암호화폐 거래소·심지어 트레저를 사칭하는 시도가 늘어날 수 있다고 경고했다(트레저 공지, 2026-08-13). 개인정보와 실물 배송 정보가 결합하면 공격자가 표적의 신뢰를 쌓는 데 필요한 재료가 갖춰진다.
이름·주소·주문 내역을 알고 접근하는 사칭 전화는 모르는 번호의 일반 피싱보다 성공률이 훨씬 높으며, 궁극적으로는 24단어 복구 시드 탈취 시도로 이어질 수 있다. 2024년 유출 사고 이후 실제로 이 경로의 피싱 공격이 보고됐다는 사실이 이 위협의 현실성을 뒷받침한다. 이 사건이 드러내는 산업 구조의 문제는 세 층위로 나뉜다.
하드웨어 지갑 제조사는 장치 보안에 집중하는 동시에 공급망 전반의 데이터 흐름을 통제하는 역량을 갖춰야 한다는 것이 첫 번째 층위다. 물류·배송업체는 전통적 운송 기능에 더해 개인정보 보호와 사이버 보안 역량을 갖춰야 한다는 것이 두 번째 층위다. 사용자 차원에서는 물리적 배송 과정에서 노출될 수 있는 정보를 최소화하는 선택이 요구된다.
이 세 층위는 서로 연결되어 있으며, 어느 한 층위의 취약성은 전체 체인의 안전성을 무너뜨린다. 일부에서는 "하드웨어 지갑은 복구 시드만 안전하면 된다"는 관점을 내세운다.
트레저 역시 자사 시스템 침해는 없었으며 장치와 시드 관리의 중요성을 반복해서 강조했다(트레저 공지, 2026-08-13). 그러나 이 논리는 공급망 공격이 사회공학적 수단으로 복구 시드를 노린다는 사실을 간과한다.
광고
유출된 이름·주소·연락처는 공격자가 표적의 신뢰를 확보하는 도구가 되고, 그 신뢰가 쌓이면 시드 탈취 시도를 촉발한다. 2024년 사례가 이미 이 경로를 실증했다. 장치 보안과 공급망 보안은 상호 보완적이며, 하나만으로는 사용자를 완전히 보호할 수 없다.
국내 트레저 사용자와 해외 직구로 하드웨어 지갑을 구매하는 사용자에게도 실무적 대응이 필요하다. 배송 단계에서 노출될 수 있는 연락처·주소 정보를 최소화하고, 물류업체의 개인정보 취급 방침을 사전에 확인해야 한다. 배송 추적 알림에 포함된 링크를 클릭하기 전 발신 출처를 반드시 검증하고, 의심스러운 연락에는 어떤 경우에도 복구 시드를 공유해선 안 된다.
기업 차원에서는 해외 물류 파트너에 대한 보안 감사 기준을 높이고, 계약서에 데이터 접근 권한 최소화와 사고 통지 의무를 명문화해야 한다.
한국 사용자와 업계가 준비해야 할 대응 과제
정책·산업 차원의 과제도 분명해졌다. 국제 전자상거래·물류 분야에서 개인정보 처리 기준을 강화하고, 유출 발생 시 신속한 공지와 구제 절차를 의무화하는 규제가 필요하다. 산업 차원에서는 물류·배송업체의 보안 역량을 정량적으로 평가·공개하는 공급망 보안 인증·감사 프레임워크를 도입해야 한다.
단기적으로는 비용이 수반되겠지만, 반복되는 제3자 유출 사고가 초래하는 신뢰 손실과 사후 대응 비용을 감안하면 선제적 투자가 합리적이다. 2026년 8월 13일 트레저 유출 사건의 핵심 교훈은 명확하다.
하드웨어 지갑의 물리적 안전성은 공급망 전체의 데이터 관리가 뒷받침될 때만 실질적 의미를 갖는다. 장치 보안과 공급망 보안을 별개로 보는 시각은 공격자가 활용하는 허점을 스스로 열어두는 것과 같다.
기업은 공급망 파트너 선정과 관리 기준을 디지털 자산 시대에 맞게 높여야 하고, 규제는 그 기준을 의무화하는 방향으로 작동해야 하며, 사용자는 배송 단계에서 발생하는 정보 노출을 하드웨어 보안의 연장선으로 인식해야 한다(Privacy Guides·Bleeping Computer, 2026-08-13). ※ 이 기사는 Privacy Guides와 Bleeping Computer 보도를 참조하여 작성하였다.
광고
FAQ
Q. 이번 유출 사고로 하드웨어 지갑의 복구 시드가 위험해질 수 있는가?
A. 트레저 공식 발표 기준으로 자사 시스템과 하드웨어 장치는 이번 침해로 영향을 받지 않았다(트레저 공지, 2026-08-13). 다만 유출된 이름·주소·이메일·전화번호는 사회공학적 공격의 핵심 재료로 쓰일 수 있다. 공격자는 유출 정보로 표적의 신뢰를 먼저 확보한 뒤 피싱을 통해 복구 시드 입력을 유도하는 방식을 사용하며, 2024년 1월 유출 사고 이후 이 경로의 피싱 공격이 실제로 보고됐다. 트레저를 포함해 어떤 경로로도 복구 시드를 요청받았다면 즉시 거절하고, 공식 채널을 통해 진위를 확인해야 한다.
Q. 유출 여부가 불확실한 사용자는 어떻게 대응해야 하는가?
A. 2026년 5월 10일부터 8월 8일 사이에 쉽멍크 물류망을 통해 주문한 이력이 있다면 영향 대상자일 가능성이 있다. 우선 트레저 공식 공지 페이지에서 개인 확인 절차를 따르고, 이후 수신되는 이메일·문자·전화에서 링크 클릭이나 개인정보 제공을 자제해야 한다. 거래소·은행·트레저를 사칭하는 연락이 올 경우 해당 기관의 공식 번호나 웹사이트를 통해 직접 확인하는 것이 안전하다. 주요 계정에 2단계 인증(2FA)이 적용되어 있지 않다면 즉시 설정을 추가하는 것이 권장된다.
Q. 기업은 반복되는 제3자 유출 사고를 막기 위해 어떤 조치를 우선해야 하는가?
A. 계약 단계에서 공급망 파트너의 데이터 접근 권한을 최소화하고, 정기적 보안 감사와 사고 통지 의무를 계약서에 명문화하는 것이 출발점이다. 트레저 사례처럼 같은 기업에서 2024년과 2026년 두 차례 제3자 유출이 발생한 경우, 파트너 선정 기준과 재계약 주기를 전면 재검토할 필요가 있다. 장기적으로는 물류·배송 파트너에 대한 제3자 보안 인증 요건을 높이고, 데이터 처리 현황을 상호 검증할 수 있는 프로토콜을 도입하는 것이 반복 사고를 줄이는 구조적 해법이다.
){kind=small}
){kind=small}
){kind=small}
){kind=small}
