강좌 강좌
90일 데이터 보관 정책 입문: Trezor 사례로 읽는 보관 조건과 유출 범위
기업이 고객 정보를 얼마나 오래 두느냐는 사고가 났을 때 이야기의 크기를 바꿉니다. 2026년 8월 공개된 Trezor의 배송 협력사 유출 사례 하나만 따라가며, '90일 데이터 보관 정책'이라는 말이 이 사고에서 어디까지 설명해 주는지 살펴봅니다.
한 문장으로 이해하기
이 강좌에서 ‘90일 데이터 보관 정책’은 Trezor가 이번 사고를 설명하며 밝힌 90일 보관 조건을 가리킵니다. 주의할 점이 있습니다. 어떤 정보가 이 조건의 대상인지, 어느 시점을 기준으로 세는지, 실제로 어떻게 정리되는지는 입력 자료에 나와 있지 않습니다. 그래서 ‘90일이 지나면 자동으로 지워진다’고 단정하지 않고, 회사가 밝힌 조건이라는 범위 안에서만 다루겠습니다. 이 강좌를 마치면 세 가지를 할 수 있습니다. 첫째, 이 사례에서 90일 보관 조건이 무엇을 뜻하는지 자기 말로 설명할 수 있습니다. 둘째, 출처가 확인한 영향 범위와 회사가 밝힌 주장을 구분할 수 있습니다. 셋째, 이 조건이 설명해 주지 못하는 부분을 짚을 수 있습니다. 사전 지식은 온라인 주문에서 이름·주소·전화번호를 입력해 본 경험이면 충분합니다. 이 사례에서 문제가 된 상황은 고객 데이터가 있는 시스템에 무단 접근이 발생해 정보가 노출된 일입니다.
왜 필요한가
보관 조건 이야기는 회사 한 곳만 보고 끝낼 수 없습니다. 이 사례에서 Trezor는 주문 배송을 위해 고객 정보를 배송·물류 협력사 ShipMonk와 공유했습니다.
정보가 다른 회사로 건너간 뒤에도 조건이 이어지는지가 관건입니다. Trezor는 물류 협력사와도 같은 조건을 따르도록 협의했다고 밝혔습니다. 사고 설명에서 정보가 흘러간 경로가 함께 언급되는 이유입니다.
어떻게 이루어지는가
입력 자료가 확인해 주는 범위 안에서, 이 조건이 사고 설명에 등장하는 흐름은 다음과 같습니다.
- 회사가 특정 목적을 위해 고객 정보를 협력사에 전달합니다. Trezor의 목적은 주문 배송이었습니다.
- 회사는 정보를 받는 협력사에도 같은 보관 조건을 따르도록 협의합니다. Trezor는 물류 협력사와 이런 협의를 했다고 밝혔습니다.
- 사고가 일어나면, 회사는 그때까지 확인된 영향 범위를 공개할 수 있습니다. 공개된 범위가 사건의 최종 범위라는 뜻은 아닙니다.
- 회사는 그 범위를 설명하며 자사의 보관 조건을 근거로 제시할 수 있습니다. Trezor는 엄격한 90일 데이터 보관 정책이 유출 범위를 제한했다고 밝혔습니다.
3번과 4번은 성격이 다릅니다. 3번은 확인된 사실이고, 4번은 회사의 설명입니다. 초보자가 가장 헷갈리기 쉬운 지점이 이 둘의 구분입니다.
하나의 예시로 따라가기
위 흐름을 사례에 그대로 얹어 보겠습니다. 2026년 8월 10일, ShipMonk는 고객 데이터가 있는 시스템에 무단 접근이 발생했다고 Trezor에 알렸습니다. Trezor는 자사 시스템과 기기는 침해되지 않았다고 밝혔습니다.
영향을 받은 고객은 약 1만 4천 명입니다. 이 가운데 11,742명은 이름·이메일·전화번호·배송 주소가 노출되었고, 1,947명은 이름·도시·이메일이 부분적으로 노출되었습니다. 영향 범위에는 미국·영국·스웨덴·콜롬비아·브라질·이탈리아·포르투갈에서 2026년 5월 10일부터 8월 8일까지 주문을 받은 고객이 포함되었습니다.
이제 두 가지를 나눠서 읽어야 합니다. 하나는 출처가 확인한 사실입니다. 영향을 받은 주문 기간은 5월 10일부터 8월 8일까지였습니다. 다른 하나는 회사의 설명입니다. Trezor는 자사의 엄격한 90일 데이터 보관 정책이 유출 범위를 제한했다고 밝혔습니다. 두 이야기는 나란히 놓이지만, 앞의 기간이 뒤의 주장을 증명하지는 않습니다. 실제로 언제 어떤 정보가 정리되었는지는 입력 자료에 담겨 있지 않기 때문입니다. 연습할 것은 ‘기간이 90일쯤이니 정책 덕분’이라고 건너뛰지 않고, 확인된 범위와 회사의 설명을 따로 적어 두는 습관입니다.
언제 쓰고 언제 쓰지 않는가
이 조건은 만능이 아닙니다. 같은 사례 안에서 한계를 세 가지로 나눠 보겠습니다.
첫째, 침입 자체를 막는 장치가 아닙니다. 보관 조건이 있어도 사고는 일어났습니다. ShipMonk는 공격자가 제3자 분석 플랫폼 Metabase의 취약점을 악용해 데이터에 접근했다고 고객들에게 알렸습니다. 보관 기간과 침입 경로는 다른 차원의 문제입니다.
둘째, 예외가 남습니다. Trezor는 부분적으로 노출된 1,947명에 대해서는 더 오래된 주문 정보에 접근했을 가능성이 있다고 밝혔습니다. 확인된 것은 예외 가능성이 있다는 사실까지이고, 그 원인은 입력 자료가 설명하지 않습니다. 원인을 짐작해 채워 넣으면 그 순간 사실이 아니라 추측이 됩니다.
셋째, 노출된 정보는 이후의 위험으로 이어질 수 있습니다. Trezor는 자사 시스템과 기기가 침해되지 않았다면서도, 영향을 받은 고객이 더 정교한 피싱(사칭 메시지로 정보를 빼내려는 수법)의 표적이 될 수 있다고 밝혔습니다. 또 유출된 정보가 가짜 이메일·전화·편지와 은행·암호화폐 거래소·Trezor 사칭에 이용될 수 있다고 경고했습니다.
정리하면, 이 사례에서 보관 조건을 이야기할 때 함께 확인된 것은 두 가지입니다. Trezor가 물류 협력사와 같은 조건을 따르도록 협의했다고 밝힌 점, 그리고 그 설명 안에도 부분 노출 집단이라는 예외 가능성이 남는다는 점입니다.
핵심 정리와 확인문제
핵심은 하나입니다. 90일 데이터 보관 정책은 Trezor가 이번 사고에서 유출 범위를 제한했다고 밝힌 보관 조건입니다. Trezor는 정보를 넘겨받는 물류 협력사와도 같은 조건을 따르도록 협의했다고 밝혔습니다. 그리고 확인된 사실과 회사의 설명은 늘 따로 적어 두어야 합니다.
확인문제
- 이 강좌에서 ‘90일 데이터 보관 정책’은 무엇을 가리킵니까?
- Trezor 사례에서 영향을 받은 주문의 기간은 언제부터 언제까지이며, 90일 정책의 효과에 대해서는 무엇까지 말할 수 있습니까?
- 90일 보관 조건이 있었는데도 사고가 발생한 경위는 무엇이라고 알려졌습니까?
정답과 해설
- 정답은 ‘Trezor가 이번 사고를 설명하며 밝힌 90일 보관 조건’입니다. 보관 대상과 기준 시점, 정리 방식은 입력 자료에 나와 있지 않습니다.
- 정답은 ‘2026년 5월 10일부터 8월 8일까지이며, 정책이 유출 범위를 제한했다는 것은 Trezor의 설명’입니다. 해당 기간은 출처가 확인한 영향 범위이고, 그 범위가 보관 조건 때문이라는 인과는 회사가 밝힌 내용으로 구분해 두어야 합니다.
- 정답은 ‘ShipMonk가 공격자가 제3자 분석 플랫폼 Metabase의 취약점을 악용해 데이터에 접근했다고 고객들에게 알렸다’입니다. 사고 경위는 ShipMonk의 통지 내용이며, 보관 기간과는 성격이 다른 문제입니다.