보유 기간

Retention Period

개념

개인정보 항목마다 얼마나 보관할 수 있는지를 정해 둔 한도로, 그 기한이 지나면 지우거나 알아볼 수 없게 만들어야 합니다.

등장 배경

데이터를 지우는 일에는 아무도 상을 주지 않습니다. 새 기능을 만들면 사용자가 알아보고 매출이 움직이지만, 3년 전 탈퇴한 회원의 기록을 지우는 작업은 아무 지표도 바꾸지 않습니다. 저장 비용까지 싸지면서 지울 이유는 하나씩 사라졌습니다.

그래서 회사의 데이터베이스는 대개 회사보다 오래된 상태로 커집니다. 서비스를 3년 돌린 회사의 회원 표에는 지금 쓰는 사람과 한 번 가입하고 떠난 사람과 몇 해 전 탈퇴를 누른 사람이 같이 들어 있습니다. 그 표가 유출됐을 때 문제가 드러납니다.

현재 사용자 3만 명을 가진 회사가 유출 신고를 하면서 통지 대상을 세 보니 21만 명이었다는 상황이 실제로 생깁니다. 나머지 18만 명은 이미 떠난 사람들인데, 회사가 그들의 정보를 계속 갖고 있었기 때문에 피해자에 포함됩니다. 안 쓰는 데이터가 위험만 남기고 쌓여 있었던 것입니다.

보유 기간은 이 쌓임에 끝을 정한 원칙입니다. 정보를 모을 때 언제까지 갖고 있을지를 함께 정하게 하고, 그 기한이 지나면 지우게 했습니다.

원칙에 해당하는 말은 셋이고 각각 다른 순간에 걸립니다. 최소 수집은 모으는 순간에, 목적 제한은 쓰는 순간에, 보유 기간은 버리는 순간에 걸립니다.

작동 방식

항목마다 기간을 따로 정하고, 그 기간의 근거를 법이나 목적에서 가져오고, 기한이 되면 사람 손이 아니라 자동으로 지워지게 만듭니다.

기간을 정하는 근거는 두 가지뿐입니다.

  1. 법이 정해 둔 기간 — 이쪽은 회사가 줄일 수 없습니다. 전자상거래에서 계약과 대금 결제 기록은 5년, 소비자 불만과 분쟁 처리 기록은 3년을 보관해야 합니다. 개인정보를 다루는 시스템의 접속 기록은 1년 이상 남겨야 합니다. 탈퇴한 회원의 결제 기록을 즉시 지울 수 없는 이유가 여기 있습니다.
  2. 목적이 끝나는 시점 — 법이 정한 것이 없으면 회사가 정합니다. 기준은 그 정보를 받은 목적이 언제 끝나는지입니다. 배송을 위해 받은 주소는 배송이 끝나고 교환·반품 기간이 지나면 목적이 끝납니다. 나중에 쓸지도 모른다는 것은 기간을 늘리는 근거가 되지 않습니다.

정한 다음에 할 일은 셋입니다.

  1. 표로 만듭니다. 항목, 목적, 기간, 그 기간의 근거를 네 칸으로 적습니다. 회원 정보라고 뭉치지 않고 이메일, 결제 기록, 접속 로그, 문의 내역을 따로 적습니다.
  2. 지우는 작업을 자동으로 돌립니다. 기한을 정해 두고 지우는 코드를 만들지 않으면 문서에만 적힌 기한이 됩니다. 매일 새벽에 기한이 지난 행을 골라 지우는 작업 하나가 있는지 없는지가 실제 차이를 만듭니다.
  3. 지우는 방식을 정합니다. 완전히 지우는 것과 누구인지 알아볼 수 없게 만드는 것 둘 중 하나입니다. 월별 가입자 수 같은 통계를 남겨야 하면 이메일과 이름만 걷어내고 집계에 필요한 값만 남깁니다.

기한 전에도 쓰지 않는 정보를 떼어 두는 방법이 있습니다. 1년 넘게 접속하지 않은 계정을 따로 옮겨 잠가 두는 것이 흔한 방식이고, 이렇게 하면 평소 접근 범위에서 빠져 사고 때 피해가 줄어듭니다.

쓰이는 곳

기한을 지키기 어려운 자리는 정해져 있습니다.

  1. 회원 탈퇴 — 탈퇴 버튼 하나에 항목마다 다른 기한이 걸립니다. 이메일과 이름은 바로 지우고, 결제 기록은 5년간 따로 보관하고, 문의 내역은 3년 뒤에 지우는 식입니다.
  2. 로그와 분석 파이프라인 — 회원 표에서 지워도 분석 도구로 보낸 이벤트에는 사용자 식별자가 남아 있습니다. 보낸 곳마다 기한과 삭제 방법을 확인해야 하는데, 외부 서비스는 회사가 직접 지우지 못하는 경우가 많습니다.
  3. 백업 — 어제 받은 백업에는 오늘 지운 정보가 그대로 있습니다. 백업 자체의 보관 기간을 짧게 잡고 순환시키는 것으로 맞추는 것이 보통입니다.
  4. 채용 지원자 정보 — 불합격자의 이력서는 채용이 끝나면 목적이 끝납니다. 다음에 또 연락하려고 남겨 두려면 그 목적으로 따로 동의를 받아야 합니다.

기한을 표로 관리하는 일은 개인정보만의 과제가 아니라 데이터 거버넌스가 다루는 범위와 겹칩니다.

실무 용례

"이 테이블 보유 기간 뭐로 잡혀 있어요? 문서엔 1년인데 2년 전 행이 남아 있어요."

문서상 기한과 실제 데이터가 어긋났다는 지적입니다.

"탈퇴하면 바로 지우는 게 아니라 결제 기록만 5년 따로 둡니다."

법정 의무 보관과 나머지를 갈라서 처리한다는 설명입니다.

"분석 도구에 보낸 이벤트는 어떻게 지워요? 거기도 사용자 아이디가 들어 있는데요."

지우는 범위가 자기 데이터베이스 밖까지 이어진다는 문제 제기입니다.

페이지덱은 첫 삭제 요청을 받고 나서야 이 기한을 표로 만들었습니다. 한 사용자가 자기 정보를 전부 지워 달라고 요청했고, 태오가 회원 표에서 한 행을 지우는 데는 1분이 걸렸습니다. 그 뒤에 남은 곳을 찾는 데 이틀이 걸렸습니다.

문의 내역, 결제 대행사에 남은 기록, 분석 도구로 보낸 이벤트, 이틀 전 백업에 같은 사람의 정보가 흩어져 있었습니다. 규원은 그날 항목별 기한 표를 만들게 했고, 지우는 작업을 새벽에 자동으로 돌리게 바꿨습니다. 표에 올라온 항목은 열한 개였고, 그중 넷은 기한이 정해진 적도 없었습니다.

흔한 오해

데이터를 오래 갖고 있는 것이 안전하다고 생각하는 경우가 많습니다. 나중에 분쟁이 생겼을 때 기록이 있으면 유리하다는 생각 때문입니다. 법이 보관하라고 정한 항목은 실제로 그렇습니다. 그런데 법이 정하지 않은 항목까지 남겨 두면 그 데이터는 쓰이지 않으면서 사고 때 피해 범위만 늘립니다. 유출 규모는 지금 사용자 수가 아니라 데이터베이스에 남아 있는 사람 수로 세어집니다.

회원 표에서 지우면 끝이라고 읽는 오해도 흔합니다. 삭제를 명령 한 줄로 떠올리기 때문입니다. 실제로는 같은 사람의 정보가 결제 기록, 문의 내역, 분석 도구, 백업, 로그 파일에 나뉘어 있습니다. 회원 표만 지우면 겉으로는 사라졌는데 다른 곳에서 여전히 그 사람을 특정할 수 있는 상태가 됩니다. 이 상태가 더 나쁜 것은, 회사가 지웠다고 믿고 있어서 아무도 나머지를 찾지 않는다는 점입니다.

같이 보면 좋은 페이지

  • 개인정보 보호

    이 기한이 어느 규칙 묶음의 한 칸인지 먼저 봅니다

  • 목적 제한

    기간의 근거가 되는 목적을 어떻게 정하는지 확인합니다

  • 데이터 거버넌스

    기한을 지킬 수 있게 데이터를 관리하는 체계 쪽으로 넘어갑니다

마지막 업데이트 2026-09-16