삭제 요구권

한번 넘긴 정보를 되돌릴 방법은 오랫동안 없었습니다. 탈퇴 버튼이 아예 없는 서비스도 흔했고, 있는 경우에도 그 버튼이 무엇을 지우는지는 적혀 있지 않았습니다. 가입은 30초면 되는데 빠져나오는 데는 방법이 없는 구조였습니다.

그래서 이런 일이 생겼습니다. 어떤 사용자가 쇼핑몰을 탈퇴하고 반년이 지난 뒤 그 회사 이름으로 할인 안내 메일을 받습니다. 문의하면 탈퇴 처리는 정상적으로 됐다는 답이 옵니다. 회원 표에서는 사라졌지만 메일 발송 목록에는 그대로 남아 있었던 것입니다. 사용자 쪽에서는 지워졌다는 말과 메일이 온다는 사실을 함께 받아들 방법이 없었습니다.

정보가 검색 결과에 남는 문제까지 겹치면서 다툼이 커졌습니다. 2010년대에 유럽에서 자기 이름으로 검색되는 오래된 기록을 내려 달라는 요구가 잊힐 권리라는 이름으로 제도화됐고, 그 흐름이 각국 법으로 퍼졌습니다.

삭제 요구권은 지운다는 말에 범위와 기한을 붙인 권리입니다. 정보주체의 요구를 받은 회사는 어디에 무엇이 남아 있는지 확인해 지우고, 법 때문에 남겨야 하는 항목이 있으면 그것이 무엇이고 왜 남는지를 알려야 합니다. 지웠다는 통보만으로 끝나지 않는다는 점이 이전과 다릅니다.

요구를 접수해 본인을 확인하고, 남겨야 하는 항목을 갈라 따로 보관하고, 나머지를 실제로 지운 뒤 무엇을 지우고 무엇을 남겼는지 알립니다.

1. 접수와 본인 확인 — 창구는 개인정보처리방침에 적어 둔 곳입니다. 남의 계정을 지우려는 요구를 막아야 하지만, 확인 서류를 과하게 요구하면 권리 행사를 막는 것으로 봅니다.
2. 지울 범위를 찾습니다. 한 사람의 정보는 회원 표 한 줄에 모여 있지 않습니다. 문의 내역, 결제 기록, 접속 로그, 분석 도구로 보낸 이벤트, 메일 발송 목록, 어젯밤 백업에 나뉘어 있습니다. 목록을 미리 만들어 두지 않았으면 요구를 받은 날 이것부터 해야 합니다.
3. 남겨야 하는 것을 가릅니다. 전자상거래에서 대금 결제 기록은 5년을 보관해야 하므로 지울 수 없습니다. 계약이 아직 진행 중이거나 분쟁이 걸려 있는 경우도 그렇습니다. 이때는 남길 항목을 따로 떼어 접근을 막아 두고 나머지를 지웁니다.
4. 지우는 방식을 정합니다. 완전히 지우는 것과 비식별 처리로 누구인지 알아볼 수 없게 만드는 것 둘입니다. 월별 매출이나 이용량 통계를 유지해야 하면 식별자만 걷어내고 집계에 필요한 값을 남깁니다.
5. 기한 안에 회신합니다. 국내 규정은 10일을 기준으로 삼습니다. 회신에는 지운 항목과 남긴 항목, 남긴 이유와 그 보관 기한을 적습니다.
6. 밖으로 전달합니다. 처리를 맡긴 업체와 정보를 제공한 곳에도 삭제를 요청해야 합니다. 우리가 지우고 수탁사가 갖고 있으면 지워진 것이 아닙니다.

이 권리가 제품 설계로 내려오는 자리는 넷입니다.

1. 탈퇴 흐름 — 누르는 즉시 지우는 방식과 30일 뒤에 지우는 방식이 있습니다. 유예 기간을 두면 실수로 누른 사용자를 되돌릴 수 있지만, 그 기간과 그동안의 상태를 화면에 적어 두어야 합니다.
2. 로그와 분석 파이프라인 — 이미 외부 분석 도구로 보낸 이벤트에는 사용자 식별자가 남아 있습니다. 도구마다 삭제 요청을 넣는 방법이 다르고, 아예 지원하지 않는 곳도 있어서 어떤 값을 보낼지부터 정해 두는 편이 낫습니다. 사용자 아이디 대신 되돌릴 수 없는 해시값을 보내 두면 나중에 지울 필요 자체가 줄어듭니다.
3. 백업 — 어제 백업에는 오늘 지운 사람이 그대로 있습니다. 백업을 골라 고치는 대신 보관 주기를 짧게 잡고 순환시키는 것으로 맞춥니다.
4. 협업 제품의 기록 — 여러 사람이 함께 쓴 문서에서 한 사람을 지우면 편집 이력과 댓글에 그 사람의 이름이 남습니다. 이름을 익명 표시로 바꾸고 계정 연결만 끊는 방식이 흔합니다.

"삭제 요구 들어왔는데 결제 기록은 5년 보관이라 그건 남긴다고 회신할게요."

전부 지우는 것이 아니라 예외를 밝혀 회신한다는 말입니다.

"탈퇴랑 삭제 요구를 같은 처리로 묶어 두면 나중에 둘 다 틀려요."

두 요청의 범위가 다르다는 지적입니다.

"분석 도구 쪽은 식별자를 지우는 API가 없어요. 아예 안 보내는 쪽으로 바꿔야 합니다."

지울 수 없는 곳에는 처음부터 보내지 않는 것이 해결책이라는 뜻입니다.

페이지덱은 탈퇴 기능을 만들 때 이 요구를 함께 설계하지 않았습니다. 탈퇴를 누르면 회원 표에 탈퇴 표시만 붙었고 데이터는 그대로 남았습니다. 첫 삭제 요구가 들어온 날 태오가 확인한 결과, 탈퇴한 계정 1,400건이 표시만 달린 채 전부 살아 있었습니다.

규원은 두 가지를 나눠 정했습니다. 탈퇴는 30일 유예를 두고 그 뒤에 자동으로 지우게 하고, 삭제 요구는 접수한 날부터 10일 안에 결제 기록만 남기고 지우게 했습니다. 두 절차의 범위가 다르다는 것을 문서에 적어 두는 데 반나절이 걸렸고, 지우는 코드를 만드는 데 사흘이 걸렸습니다.

요구가 들어오면 무조건 전부 지워야 한다고 생각하는 경우가 많습니다. 권리라는 말이 그렇게 들리기 때문입니다. 실제로는 법이 보관을 의무화한 항목과 계약 이행에 필요한 항목은 남습니다. 결제 기록을 지워 달라는 요구를 그대로 따르면 다른 법을 위반하게 됩니다. 요구를 거절하는 것과 예외를 밝히고 나머지를 지우는 것은 다른 처리인데, 이 구분을 놓치면 전부 지웠다고 회신해 두고 실제로는 남겨 두는 상태가 됩니다.

계정을 비활성으로 바꾸는 것을 삭제로 보는 오해도 흔합니다. 개발 쪽에서는 지운 표시만 세워 두고 데이터를 남기는 방식이 흔하고, 화면에서 사라지니 지워진 것처럼 보입니다. 그런데 표시만 붙은 데이터는 여전히 조회할 수 있고 백업에도 들어가고 사고가 나면 유출 대상에 포함됩니다. 사용자에게 지웠다고 알린 뒤에 그 데이터가 남아 있으면, 지우지 않은 것보다 회신 내용이 사실과 다르다는 점이 더 무겁게 걸립니다.