적어둔 문장이 이미 약속입니다
개인정보 보호법 제21조는 보유기간이 지났거나 처리 목적을 이룬 개인정보를 지체 없이 파기하라고 정합니다. 파기할 때는 복구하거나 재생할 수 없게 조치해야 합니다. 컴퓨터 안의 파일이라면 같은 법 시행령 제16조가 한 걸음 더 들어가, 복원이 불가능한 방법으로 영구 삭제하라고 적어두었습니다. 이를 어기면 3천만 원 이하의 과태료 대상입니다(같은 법 제75조 제2항 제4호).
여기서 놓치기 쉬운 점이 하나 있습니다. 기간을 정한 것은 법이 아니라 회사 자신입니다. 법이 3년을 정해준 게 아닙니다. 회사가 방침에 3년이라고 적었기 때문에 3년이 된 겁니다. 그러니 개인정보 파기는 법이 시켜서 하는 일이기 이전에, 우리가 홈페이지에 써 붙인 문장을 지키는 일입니다.
저희 방침에도 문의·상담 신청은 3년, 진단 신청 정보와 진단 결과도 3년이라고 적혀 있었습니다. 그리고 한동안 그 문장만 있었습니다. 문장은 있는데 문장을 실행하는 것이 없었습니다.
손으로 지우겠다는 계획은 왜 실패하나
지우는 일 자체는 어렵지 않습니다. 데이터베이스에서 오래된 줄을 골라 지우면 끝입니다. 어려운 건 그 일을 매일 빠뜨리지 않는 것입니다.
손으로 하려면 세 가지가 동시에 필요합니다. 오늘이 무언가를 지워야 하는 날인지 알아야 하고, 오늘 대상이 어느 것인지 골라야 하고, 실제로 지워야 합니다. 그리고 이 셋을 내일도, 모레도 해야 합니다. 하루 빠지면 그날 지났어야 할 데이터가 그대로 남습니다.
더 곤란한 건 안 지운 것은 티가 나지 않는다는 점입니다. 잘못 지우면 그날 바로 사고가 되지만, 안 지운 것은 아무 일도 일어나지 않습니다. 화면도 그대로고 문의도 그대로 들어옵니다. 아무도 불편하지 않으니 아무도 고치지 않습니다. 저희가 몇 달을 그렇게 보냈습니다.
그래서 이 일은 기억력의 문제가 아니라 구조의 문제라고 판단했습니다. 잊지 말자고 다짐하는 대신, 잊어도 되게 만들기로 했습니다.
만들면서 부딪힌 것 네 가지
절차 자체는 단순합니다. 매일 새벽에 한 번 깨어나서, 보유기간이 지난 줄을 찾아 지우고, 결과를 남깁니다. 그런데 만들다 보니 단순한 설명에는 안 나오는 판단이 네 번 필요했습니다. 개발자가 아니시더라도 맡기실 때 요구사항으로 그대로 넘기실 수 있는 것들이라 적어둡니다.
| 부딪힌 것 | 그냥 두면 생기는 일 | 저희가 택한 방법 |
|---|---|---|
| 지우는 순서 | 문의 데이터를 먼저 지우면 그것을 참조하던 진단 결과가 붕 뜬다 | 참조하는 쪽을 먼저, 참조되는 쪽을 나중에 지운다 |
| 대상 고르기 | “이건 빼고”라는 조건을 붙이면, 그 칸이 비어 있는 줄이 조건에 안 걸려 영원히 남는다 | 제외 조건을 아예 쓰지 않는다. 기간이 짧은 것부터 순서대로 돌린다 |
| 하나가 실패했을 때 | 한 종류에서 오류가 나면 그 뒤가 전부 멈춰서, 지켜지는 게 하나도 없게 된다 | 실패한 것만 실패로 남기고 나머지는 계속 돌린다 |
| 잘못 불렸을 때 | 데이터를 지우는 주소가 열려 있으면 누구든 부를 수 있다 | 열쇠가 설정돼 있지 않으면 아예 응답하지 않고 죽는다 |
두 번째 줄이 특히 위험했습니다. “이 종류는 기간이 다르니 빼자”는 조건은 언뜻 합리적으로 들립니다. 그런데 그 종류를 적는 칸이 비어 있는 줄은 “이 종류가 아님”에도 걸리지 않습니다. 결과적으로 그 줄들만 조용히 영원히 남습니다. 지운 개수는 매일 정상으로 보이는데 특정 줄만 안 지워지는, 가장 알아채기 어려운 형태의 실패입니다.
네 번째도 취향의 문제가 아닙니다. 지우는 기능은 되돌릴 수 없어서, 막히면 멈추는 쪽이 안전합니다. 설정이 빠졌을 때 조용히 아무나 부를 수 있게 열려 있는 것보다, 아예 응답을 안 하고 죽는 편이 낫다고 판단했습니다.
알림은 조용한 날에 보내지 않기로 했습니다
처음에는 매일 결과를 보내려고 했습니다. 오늘 몇 건 지웠습니다, 하는 식입니다. 그런데 실제로 돌려보니 대부분의 날은 0건입니다. 3년이 지난 데이터가 매일 생기지는 않으니까요.
매일 “0건”이 오면 며칠 만에 아무도 그 알림을 읽지 않게 됩니다. 그러면 정말 실패한 날의 알림도 같이 안 읽힙니다. 그래서 지운 게 있거나 실패한 날에만 보내도록 바꿨습니다. 알림이 오는 것 자체가 신호가 되도록 뒤집었습니다.
아직 못 한 것, 그리고 알면서 남겨둔 것
여기까지는 만든 이야기고, 이제 못 만든 이야기입니다.
이용자가 “지금 지워달라”고 요청하시면 아직 사람이 처리합니다. 방침에는 이용자의 권리로 적어두었지만, 그 요청을 받아 처리하는 부분은 자동으로 돌지 않습니다. 요청이 자주 오지 않는다는 이유로 뒤로 미뤄둔 상태입니다. 정직하게 말하면, 빈도가 낮다는 건 안 만들어도 되는 이유가 아니라 늦게 발견될 이유에 가깝습니다.
절차가 아예 안 불린 날은 조용한 날과 구분되지 않습니다. 앞에서 조용한 날에는 알림을 보내지 않기로 했다고 적었는데, 그 결정의 대가가 이겁니다. 절차가 죽어 있어도 알림이 안 오고, 아무 일 없는 날에도 알림이 안 옵니다. 화면상으로는 같습니다. 이건 알면서 남겨뒀습니다. 매일 0건을 보내는 쪽이 더 나쁘다고 봤기 때문입니다. 다음에 고친다면 “며칠째 소식이 없다”를 알리는 쪽으로 방향을 잡을 생각입니다.
이런 식으로 만들어도 남는 구멍이 있습니다. 저희가 블로그 자동화를 만들었을 때도 비슷했습니다. 자동으로 돌아가는 부분과 끝내 사람이 붙어야 하는 부분이 갈렸고, 그 경계를 인정하는 데서 실제 도움이 나왔습니다(블로그 자동화를 3주 돌려본 기록).
이걸 안 만드는 편이 나은 경우
모든 회사가 이걸 만들 필요는 없습니다.
보관하는 개인정보가 수십 건이고 앞으로도 크게 늘지 않는다면, 만들지 않는 편이 낫습니다. 스프레드시트에 다음 파기 예정일을 적고 분기마다 한 번 확인하는 편이 더 빠르고 더 안전합니다. 자동으로 지우는 장치는 잘못 만들면 지우면 안 되는 것을 지웁니다. 그리고 그건 되돌릴 수 없습니다.
판단 기준은 건수보다 이쪽이 낫습니다. 손으로 확인하는 데 걸리는 시간이 아깝다고 느껴질 만큼 데이터가 계속 쌓이고 있는가. 그렇지 않다면 달력 알림 하나가 정답입니다.
우리 회사에 붙이려면 무엇부터 정하나
맡기시든 직접 하시든, 먼저 정해야 할 것은 기술이 아니라 세 가지 답입니다.
| 정할 것 | 왜 먼저인가 |
|---|---|
| 무엇을 얼마나 보관하는가 | 방침에 적힌 기간과 실제로 지우는 기간이 같아야 한다. 다르면 고지 위반이다 |
| 그 정보가 어디에 있는가 | 데이터베이스만 지우고 메일함·엑셀·분석 도구에 남으면 지운 게 아니다 |
| 실패했을 때 누가 보는가 | 볼 사람이 정해지지 않은 알림은 안 온 것과 같다 |
두 번째가 가장 자주 빠집니다. 문의 데이터는 보통 한 곳에만 있지 않습니다. 접수된 데이터베이스, 알림이 쌓인 메신저, 담당자가 받은 메일, 방문 기록이 들어간 분석 도구까지 흩어져 있습니다. 한 곳만 지우고 지웠다고 말하면 그 말이 사실이 아니게 됩니다. 회사 자료가 어디까지 퍼져 있는지 세어보는 문제는 회사 자료를 다루는 원칙에서 따로 다뤘습니다.
세 번째는 사람 문제로 보이지만 실은 설계 문제입니다. 실패 알림을 어디로 보낼지, 그 채널을 누가 매일 보는지가 정해져 있지 않으면 알림 기능은 만들어도 없는 것과 같습니다. 저희는 팀 메신저 한 채널로 모으는 방식을 썼습니다. 자동화가 어떤 부품들로 이루어지는지는 자동화의 구성 요소에 정리해두었습니다.
자주 묻는 질문
개인정보 파기 기한은 누가 정하나요?
법이 특정 연수를 정해주지는 않습니다. 개인정보 보호법 제21조는 보유기간이 지나거나 처리 목적을 이루면 지체 없이 파기하라고만 합니다. 그 보유기간은 회사가 개인정보처리방침에 적어 고지한 기간입니다. 그러니 기한을 정하는 것은 회사이고, 정한 뒤에는 그 기간이 곧 지켜야 할 약속이 됩니다.
개인정보 파기 방법에 정해진 기준이 있나요?
있습니다. 같은 법 시행령 제16조는 컴퓨터 안의 파일이라면 복원이 불가능한 방법으로 영구 삭제하라고 정합니다. 종이 서류라면 파쇄하거나 소각합니다. 화면에서 안 보이게 감추는 것은 파기가 아닙니다. 데이터베이스에서 “삭제 표시”만 하고 실제 줄을 남겨두는 방식도 마찬가지입니다.
방문 기록 같은 것도 파기 대상인가요?
방침에 보유기간을 적어두었다면 대상입니다. 다만 분석 도구에 쌓이는 기록은 저희가 직접 지우는 것이 아니라 도구의 보관 기간 설정으로 지워집니다. 그래서 저희는 그 설정값을 방침에 적은 기간보다 짧게 맞춰두었습니다. 도구 설정을 확인하지 않으면, 데이터베이스는 비워도 분석 도구에는 몇 년치가 그대로 남아 있을 수 있습니다.
직원이 열 명도 안 되는데 이런 게 필요한가요?
필요 여부는 인원이 아니라 보관하는 정보의 양과 증가 속도로 판단하시는 편이 낫습니다. 문의가 한 달에 몇 건이고 늘지 않는다면 달력 알림으로 충분합니다. 반대로 폼·챗봇·이벤트 신청이 동시에 돌아 데이터가 여러 곳에 쌓이고 있다면, 인원이 적을수록 오히려 사람이 감당하기 어렵습니다.
—
방침에 적은 문장을 지키는 일은 대단한 기술이 아닙니다. 저희가 만든 것도 매일 한 번 깨어나서 오래된 줄을 지우고 결과를 남기는, 그 이상은 아닙니다. 다만 그걸 사람의 기억에 맡겨두는 동안에는 한 번도 지켜지지 않았습니다.
회사에서 이런 식으로 아무도 안 지키고 있는데 아무도 불편하지 않은 일이 몇 가지쯤 떠오르신다면, 그게 자동화를 붙일 첫 자리일 가능성이 높습니다. 어디부터인지 함께 짚어보고 싶으시면 무료 진단을 신청해 주세요. 무엇을 자동화할지부터 정리해 드립니다.