법에는 날짜가 없지만, 현장에는 이미 세어지고 있는 날짜가 있습니다

점검 나온 담당자가 서류를 넘기다 한 곳에서 손을 멈춥니다. 지난해 종료한 서비스의 회원 데이터베이스가 언제 정리됐는지를 묻는 항목입니다. 담당자는 어렵지 않게 답합니다. 서비스 종료 공지를 낸 다음 달에 운영 데이터베이스에서 회원 테이블을 삭제했고, 삭제 스크립트를 돌린 날짜와 실행 로그도 남아 있습니다. 그런데 다음 질문이 이어집니다.

그 데이터베이스가 올라가 있던 서버의 디스크와, 매주 자동으로 돌던 백업 테이프는 어떻게 처리했느냐는 것입니다. 서버는 창고로 내려갔고, 백업 테이프는 아직 랙에 꽂혀 있습니다. 이 순간부터 담당자가 준비해 온 서류는 절반만 유효한 서류가 됩니다. 데이터를 지운 날짜는 있는데, 그 데이터가 담겨 있던 매체를 처리한 날짜는 없기 때문입니다.

이런 장면은 특별히 관리가 부실한 조직에서만 벌어지는 일이 아닙니다. 오히려 삭제 절차가 잘 정비된 조직일수록 데이터 쪽 기록은 촘촘한 반면, 그 데이터를 담고 있던 물리적 매체의 처리 기록은 비어 있는 경우가 많습니다. 데이터 삭제는 정보시스템 담당자의 업무이고 장비 처분은 자산관리나 총무 담당자의 업무여서, 두 기록이 애초에 다른 대장에 남기 때문입니다. 법이 보는 것은 그 둘을 합친 결과인데, 조직 안에서는 각자의 절반만 관리되고 있는 것입니다.

개인정보 보호법이 파기를 다루는 방식은 이 장면에 정확히 겹칩니다. 법은 개인정보가 불필요해졌을 때 지체 없이 파기하라고 정하고 있습니다(제21조 1항). 그리고 파기할 때는 복구 또는 재생되지 않도록 조치하라고 덧붙입니다(제21조 2항). 앞의 문장은 시점에 관한 의무이고, 뒤의 문장은 방법에 관한 의무입니다. 실무에서 문제가 되는 대부분의 사건은 둘 중 하나만 지켜진 상태에서 발생합니다. 방법은 그럴듯한데 시점이 늦었거나, 시점은 지켰는데 방법이 데이터를 실제로 없애지 못한 경우입니다.

"지체 없이"에는 며칠이 들어 있나

법전만 놓고 보면 "지체 없이"라는 표현에는 숫자가 없습니다. 그래서 많은 조직이 이 말을 "가능한 한 빨리" 정도로 해석하고, 실제로는 분기 단위나 연 단위 정리 일정에 맞춰 처리해 왔습니다. 그러나 개인정보보호위원회가 정한 표준 개인정보 보호지침은 이 말에 구체적인 숫자를 붙여 두었습니다. 보유 기간이 경과했거나 처리 목적이 달성됐거나 가명정보의 처리 기간이 지났거나 해당 서비스가 폐지됐거나 사업이 종료되는 등으로 개인정보가 불필요해졌을 때에는, 정당한 사유가 없는 한 그로부터 5일 이내에 파기해야 한다는 것입니다(제10조 1항).

5일이라는 숫자는 실무 감각과 상당한 거리가 있습니다. 창고에 내려간 서버를 5일 안에 처리하려면, 대상을 확인하고 내부 승인을 받고 처리 방식을 정하고 업체 일정을 잡는 과정이 그 안에 모두 들어가야 합니다. 많은 조직에서 이 과정은 5일이 아니라 5주가 걸립니다. 그런데 지침이 정한 기준은 5주가 아니라 5일이고, 그 기산점은 파기 작업을 시작한 날이 아니라 개인정보가 불필요해진 날입니다. 이 차이를 인식하는 것만으로도 일정 관리의 출발점이 달라집니다.

물론 표준지침은 법률이 아니라 고시이고, 5일을 넘겼다고 곧바로 제재가 확정되는 구조는 아닙니다. 지침 자체도 "정당한 사유가 없는 한"이라는 단서를 달고 있습니다. 다만 점검이나 조사에서 파기 지연이 문제가 됐을 때, 판단의 기준선으로 먼저 놓이는 숫자가 5일이라는 점은 달라지지 않습니다. 5일을 넘겼다면 왜 넘겼는지를 설명할 책임이 조직 쪽에 생긴다고 보는 편이 현실에 가깝습니다.

시계는 언제부터 돌기 시작합니까

실무에서 더 까다로운 것은 기한 자체보다 기산점입니다. 5일을 세려면 첫날이 언제인지부터 정해야 하는데, 파기 사유마다 그 첫날이 다릅니다. 그리고 대부분의 조직은 이 첫날을 따로 정의해 두지 않은 채 일을 처리해 왔습니다. 파기가 필요하다는 인식은 있지만, 그 필요가 언제 생겼는지를 문서로 확정해 두는 절차가 없는 것입니다. 그러다 보니 실제 처리는 담당자가 여유가 생긴 시점이나 창고 정리가 필요해진 시점에 이뤄지고, 그 시점과 법이 보는 시점 사이에 몇 달의 간격이 생깁니다.

가장 명확한 것은 보유기간 경과입니다. 수집 당시 고지하고 동의받은 보유기간이 3년이었다면, 그 3년이 끝나는 날이 첫날입니다. 계약서나 처리방침에 날짜가 박혀 있으므로 다툼의 여지가 적습니다. 문제는 이 유형이 가장 명확한데도 가장 자주 놓친다는 점입니다. 보유기간 만료는 아무도 통보해 주지 않기 때문입니다. 회원 탈퇴는 시스템이 알려 주고 서비스 종료는 회의에서 결정되지만, 3년 전에 수집한 데이터의 보유기간이 오늘 끝났다는 사실은 누군가 미리 달력에 표시해 두지 않으면 조용히 지나갑니다.

두 번째는 처리 목적 달성입니다. 이 유형은 기산점이 흐릿합니다. 채용 전형이 끝난 날인지 최종 합격자 발표일인지, 배송이 완료된 날인지 반품 가능 기간이 끝난 날인지, 계약이 만료된 날인지 정산이 끝난 날인지를 조직이 스스로 정의해야 합니다. 여기서 중요한 것은 정의를 내려 두는 일 자체입니다. 정의가 문서로 남아 있으면 그 기준에 따라 시계가 돌기 시작하고, 정의가 없으면 사후에 조사자가 가장 이른 날짜를 기산점으로 잡아도 반박할 근거가 없습니다. 그리고 이 판단은 객관적으로 이뤄져야 하며, 아직 쓸 데가 있을지 모른다는 이유로 조직에 유리하게 늘려 잡는 것은 인정되기 어렵습니다.

세 번째는 해당 서비스의 폐지 또는 사업의 종료입니다. 이 유형이 실무에서 가장 큰 물량을 만들어 냅니다. 서비스 하나가 닫히면 운영 데이터베이스만 사라지는 것이 아니라 개발 서버, 스테이징 서버, 로그 저장소, 백업 세트, 담당자 노트북, 지사에 남아 있던 사본까지 함께 정리 대상이 됩니다. 그런데 서비스 종료 프로젝트의 일정표에는 대개 서비스 중단일과 공지일, 환불 처리일까지만 적혀 있고, 그 서비스를 담고 있던 저장매체를 처리하는 날짜는 빠져 있는 경우가 많습니다. 종료를 결정한 날부터 시계가 돌기 시작하는데, 정작 그 시계를 보고 있는 사람이 없는 셈입니다.

여기에 가명정보의 처리 기간 경과가 더해집니다. 가명처리를 전제로 정해 둔 처리 기간이 끝나면 그 역시 파기 사유가 됩니다. 분석 목적으로 만든 가명 데이터셋은 원본과 달리 별도 서버나 분석용 스토리지에 따로 올라가 있는 경우가 많아, 정리 대상 목록에서 통째로 누락되기 쉬운 유형입니다.

"정당한 사유"로 인정되는 것과 그렇지 않은 것

법은 다른 법령에 따라 보존해야 하는 경우를 예외로 두고 있습니다(제21조 1항 단서). 전자상거래 관련 기록이나 세무 관련 자료처럼 다른 법에서 일정 기간 보관을 요구하는 정보가 여기에 해당합니다. 다만 이 예외를 적용받으려면 조건이 붙습니다. 파기하지 않고 보존하는 개인정보는 다른 개인정보와 분리해 저장하고 관리해야 합니다(제21조 3항). 분리하지 않고 기존 데이터베이스에 그대로 둔 채 "법정 보존 대상이라 남겨 뒀다"고 설명하는 방식은 인정되지 않습니다.

현장에서 자주 나오는 사유 중 상당수는 정당한 사유로 보기 어렵습니다. 담당자가 바뀌어 인수인계가 되지 않았다, 예산이 다음 분기에 배정된다, 파기 업체 견적을 아직 받지 못했다, 물량이 모이면 한 번에 처리할 예정이다 같은 이유들입니다. 이런 사정이 실제로 존재한다는 점은 조사자도 알고 있습니다. 다만 그것이 법정 의무를 늦출 근거가 되지는 않습니다. 오히려 이런 사유가 반복적으로 기록되어 있다면, 개별 건의 지연이 아니라 파기 절차 자체가 설계되어 있지 않다는 방증으로 읽힐 수 있습니다.

데이터를 지운 날과 매체를 처리한 날은 다릅니다

여기서 앞의 장면으로 돌아옵니다. 파기 방법을 정한 규정은 개인정보를 전자적 파일 형태와 그 외의 기록매체로 나눕니다. 전자적 파일은 복원이 불가능한 방법으로 영구 삭제하고, 그 밖의 기록물과 인쇄물, 서면 등은 파쇄하거나 소각하도록 정해져 있습니다(시행령 제16조 1항). 여기서 말하는 복원이 불가능한 방법이란, 현재의 기술 수준에서 사회통념상 적정한 비용으로 복원할 수 없게 만드는 조치를 뜻합니다(표준 개인정보 보호지침 제10조 2항).

이 기준을 저장매체에 대입하면 판단이 명확해집니다. 데이터베이스에서 테이블을 지우는 것은 논리적 삭제이지, 그 데이터가 물리적으로 기록되어 있던 디스크를 복원 불가능한 상태로 만드는 조치가 아닙니다. 삭제 명령은 대개 파일 시스템의 색인만 정리하고 실제 기록 영역은 그대로 남겨 둡니다. 서버가 살아 있고 계속 다른 데이터를 덮어쓰는 동안에는 이 차이가 잘 드러나지 않지만, 그 서버를 꺼서 창고로 내리는 순간부터는 상황이 달라집니다. 더 이상 덮어쓰이지 않은 채, 지웠다고 믿는 데이터가 그대로 보존된 매체가 되기 때문입니다.

백업은 이 문제를 한 단계 더 어렵게 만듭니다. 운영 데이터베이스에서 데이터를 지워도, 그보다 앞선 시점에 만들어진 백업 세트에는 지워지기 전 상태가 고스란히 들어 있습니다. 파기 사유가 발생한 시점을 기준으로 시계가 돌기 시작하는 대상에는 이 백업도 포함됩니다. 백업 정책상 세대 관리가 자동으로 돌아 일정 기간 뒤 덮어쓰인다면 그 주기를 근거로 설명할 수 있지만, 오프라인으로 빼내 보관 중인 테이프나 외장 매체라면 별도로 처리 대상에 올려야 합니다.

실제 제재 사례에서도 이 지점이 문제가 됐습니다. 한 인공지능 대화 서비스 개발사는 자사 애플리케이션을 탈퇴한 이용자의 회원 정보 일부와 대화 내용을 학습용 데이터베이스에 남겨 둔 채 파기하지 않아 제21조 1항 위반으로 판단됐습니다. 서비스에서 탈퇴 처리는 정상적으로 이뤄졌지만, 그 데이터가 이미 복제되어 옮겨 간 다른 저장소는 파기 대상 목록에 들어 있지 않았던 것입니다. 원본이 어디까지 복제됐는지를 파악하지 못하면, 원본을 지운 사실만으로는 파기했다고 말하기 어렵습니다.

우리 손을 떠난 데이터의 시계도 함께 돌고 있습니다

파기 시점을 관리할 때 자주 빠지는 또 하나의 영역이 위탁입니다. 고객 상담을 외부에 맡겼거나 정산 업무를 대행사에 넘겼거나 마케팅 발송을 별도 업체가 처리하고 있다면, 같은 개인정보의 사본이 우리 서버 밖에도 존재합니다. 과태료 조항은 이 상황을 명시적으로 다루고 있습니다. 제21조 1항 위반에 관한 과태료 규정은 위탁 시 준용되는 경우를 포함한다고 적어 두고 있습니다(제75조 2항 4호). 즉 위탁했다는 이유로 파기 의무가 사라지지 않으며, 수탁자가 보유한 사본이 남아 있으면 그 역시 미파기 상태로 평가될 수 있습니다.

문제는 수탁자 쪽의 파기 시점을 확인할 방법이 계약서에 들어 있지 않은 경우가 많다는 점입니다. 위탁 계약이 종료되면 데이터를 반환하거나 파기한다는 문장은 대부분 들어 있지만, 언제까지 어떤 방식으로 처리하고 그 결과를 어떻게 통보할지까지 적혀 있는 계약은 드뭅니다. 계약 종료일이 곧 파기 사유 발생일이 되는데, 그날 이후 수탁자가 실제로 무엇을 했는지 알 수 없다면 위탁자 입장에서 설명할 수 있는 것은 계약서 문구뿐입니다. 계약 단계에서 파기 완료 기한과 결과 통보 방식을 함께 정해 두는 편이, 종료 이후에 요청해서 받아 내는 것보다 훨씬 수월합니다.

5일을 지키려면 일정을 거꾸로 계산해야 합니다

5일이라는 기준을 실제로 맞추는 방법은 하나뿐입니다. 파기 사유가 발생한 뒤에 절차를 시작하는 것이 아니라, 사유가 발생하기 전에 절차를 준비해 두는 것입니다.

먼저 파기 사유별로 기산점을 문서에 정의해 둡니다. 보유기간 경과는 만료일, 처리 목적 달성은 조직이 정한 특정 이벤트, 서비스 폐지는 종료 결정일 또는 서비스 중단일이라는 식으로 정해 두면, 사유가 발생했을 때 첫날을 두고 논의할 필요가 없어집니다. 그다음으로 각 사유에 연동되는 대상 목록을 미리 만들어 둡니다. 어떤 서비스가 종료되면 어떤 서버와 어떤 백업 세트, 어떤 단말이 함께 정리 대상이 되는지를 평소에 매핑해 두는 작업입니다. 이 매핑이 있으면 종료 결정이 난 날 바로 대상 수량이 나오고, 수량이 나오면 처리 방식과 일정이 곧바로 정해집니다.

여기에 리드타임을 역산해 두는 일이 남습니다. 매체 유형에 따라 처리 방식이 달라지고, 방식에 따라 준비 시간도 다릅니다. 자성 매체인 하드디스크와 LTO 테이프는 디가우징으로 자기 기록 자체를 지울 수 있지만, 플래시 기반의 SSD와 NVMe, eMMC에는 디가우징이 통하지 않아 인증된 소프트웨어 기반 영구삭제나 물리적 파기를 적용해야 합니다. 대량 물량을 한 번에 처리해야 하는 상황과 소량을 정기적으로 처리하는 상황도 준비 시간이 다릅니다. 이 리드타임을 미리 파악해 두지 않으면, 사유가 발생한 날부터 업체를 찾기 시작해 5일은커녕 첫 통화조차 그 안에 끝나지 않습니다.

마지막으로 결과를 기록으로 남깁니다. 개인정보처리자는 파기에 관한 사항을 기록하고 관리해야 하며(표준 개인정보 보호지침 제10조 3항), 개인정보 보호책임자는 파기가 시행된 뒤 그 결과를 확인해야 합니다(제10조 4항). 즉 파기는 처리 담당자의 작업으로 끝나는 것이 아니라, 책임자의 확인까지 이뤄져야 완결되는 절차입니다. 어떤 매체를 언제 어떤 방식으로 처리했고 누가 확인했는지가 남아 있어야, 나중에 기산점부터 완료일까지의 간격을 숫자로 설명할 수 있습니다.

미이행이 남기는 것

파기하지 않은 상태는 두 방향에서 부담이 됩니다. 하나는 제재입니다. 제21조 1항을 위반해 파기 등 필요한 조치를 하지 않으면 3천만 원 이하의 과태료 대상이 되고(제75조 2항 4호), 보존이 허용되는 경우인데도 분리해 저장하고 관리하지 않으면 1천만 원 이하의 과태료 대상이 됩니다(제75조 4항 2호). 금액 자체는 대형 사고의 과징금에 비하면 크지 않지만, 이 항목은 사고가 없어도 정기 점검만으로 확인되는 항목이라는 점이 다릅니다.

과태료 항목의 성격을 조금 더 짚어 둘 필요가 있습니다. 유출이나 해킹처럼 외부 요인이 개입해야 드러나는 위반과 달리, 미파기는 서류와 현장만 대조하면 확인됩니다. 개인정보파일 목록에 적힌 보유기간과 실제 데이터베이스의 잔존 여부를 비교하거나, 폐서비스 관련 자산 목록과 창고 실물을 대조하는 것만으로 판단이 끝나는 항목이기 때문입니다. 조직 입장에서는 사고가 나지 않아도 언제든 확인될 수 있는 항목을 방치해 두는 셈이 됩니다.

다른 하나는 사고가 났을 때의 피해 규모입니다. 파기했어야 할 데이터가 남아 있으면, 유출 사고가 발생했을 때 유출 범위에 그 데이터가 그대로 포함됩니다. 이미 목적을 다해 아무런 사업적 가치가 없는 데이터가 피해 규모만 키우는 셈입니다. 특히 올해 9월 11일부터 시행되는 개정 개인정보 보호법은 과징금 산정 기준을 강화하는 방향으로 바뀝니다. 유출 규모가 곧 제재 규모로 이어지는 구조에서, 진작 없었어야 할 데이터가 유출 건수에 더해지는 것은 그 자체로 회피 가능했던 손실입니다.

파기 시점을 지킬 수 있게 만드는 실행 단계

알테크코리아는 이 흐름의 마지막 단계, 즉 매체를 실제로 복원 불가능한 상태로 만드는 작업을 맡습니다. 데이터파기 브랜드 DieHDD™를 통해 디가우징과 유압천공, 분쇄파기, 소각파기 네 가지 방식을 운용하며, 매체 유형과 반출 조건에 맞는 방식을 선택해 처리합니다. 자성 매체인 하드디스크와 LTO 테이프에는 디가우징을 적용하고, 물리적 파괴가 필요한 대상에는 유압천공이나 분쇄파기, 소각파기를 적용합니다. 재사용이나 반납이 예정되어 매체 자체는 살려야 하는 경우에는 블랑코(Blancco) 기반의 인증 영구삭제를 적용해 데이터만 복구 불가능한 수준으로 지우고 검증 리포트를 남깁니다. 알테크코리아는 블랑코 코리아 공식 파트너사이자 한국정보보호산업협회(KISIA) 회원사로서 이 절차를 운영하고 있습니다.

매체 판별이 앞서야 한다는 점도 함께 짚어 둘 만합니다. 같은 서버에서 빠져나온 디스크라도 하드디스크와 SSD는 요구되는 처리 원리가 다르고, 겉으로는 구분이 어려운 경우도 있습니다. 자성 매체에만 유효한 방식을 플래시 매체에 적용하면 처리는 했으나 데이터는 남아 있는 상태가 되고, 이는 복원 불가능한 방법으로 파기했다는 요건을 충족하지 못합니다. 대상 목록을 만들 때 수량뿐 아니라 매체 유형까지 함께 적어 두면 이 단계에서 시간이 줄어듭니다.

일정 측면에서 중요한 것은 처리 방식마다 필요한 준비 시간이 다르다는 점입니다. 현장에서 바로 처리해야 하는 상황인지, 물량을 모아 이송해 처리하는 편이 나은 상황인지, 담당자 입회가 필요한 등급의 자료인지에 따라 준비 절차가 달라집니다. 파기 사유가 발생하기 전에 이 조건을 한 번 정리해 두면, 실제로 사유가 발생했을 때 대상 목록을 전달하는 것만으로 일정이 잡힙니다. 처리 후에는 대상 매체의 종류와 시리얼, 작업 일시와 적용 방식, 결과 확인 자료를 함께 정리해 전달하므로, 기산점부터 완료일까지의 간격을 문서로 설명할 수 있게 됩니다.

정리하며

제21조 1항이 요구하는 것은 결국 두 개의 날짜입니다. 개인정보가 불필요해진 날과, 그 개인정보가 담긴 매체가 복원 불가능한 상태가 된 날입니다. 이 두 날짜의 간격이 짧고, 그 간격을 설명할 수 있는 기록이 있으면 이 조항과 관련된 대부분의 질문은 해소됩니다. 반대로 앞의 날짜를 정의해 두지 않았거나 뒤의 날짜가 아예 존재하지 않으면, 아무리 성실하게 업무를 처리해 왔더라도 그 사실을 증명할 방법이 없습니다.

지금 조직 안에 목적을 다한 데이터가 어디에 남아 있는지, 그 사유가 발생한 날이 언제였는지, 오늘까지 며칠이 지났는지를 한 번 세어 보시기 바랍니다. 숫자가 나오면 다음에 무엇을 해야 하는지도 함께 나옵니다. 그리고 그 숫자가 이미 5일을 훨씬 넘겼다면, 그것을 늦게라도 정리하는 일 자체가 앞으로의 기록을 다시 만들기 시작하는 지점이 됩니다.

법령 원문

제21조 1항 : 개인정보처리자는 보유기간의 경과, 개인정보의 처리 목적 달성, 가명정보의 처리 기간 경과 등 그 개인정보가 불필요하게 되었을 때에는 지체 없이 그 개인정보를 파기하여야 한다. 다만, 다른 법령에 따라 보존하여야 하는 경우에는 그러하지 아니하다.

제21조 2항 : 개인정보처리자가 제1항에 따라 개인정보를 파기할 때에는 복구 또는 재생되지 아니하도록 조치하여야 한다.

제21조 3항 : 개인정보처리자가 제1항 단서에 따라 개인정보를 파기하지 아니하고 보존하여야 하는 경우에는 해당 개인정보 또는 개인정보파일을 다른 개인정보와 분리하여서 저장ㆍ관리하여야 한다.

제75조 2항 4호 : 제21조제1항(제26조제8항에 따라 준용되는 경우를 포함한다)을 위반하여 개인정보의 파기 등 필요한 조치를 하지 아니한 자 (3천만원 이하의 과태료)

제75조 4항 2호 : 제21조제3항(제26조제8항에 따라 준용되는 경우를 포함한다)을 위반하여 개인정보를 분리하여 저장ㆍ관리하지 아니한 자 (1천만원 이하의 과태료)

개인정보 보호법 시행령 제16조 1항 : 개인정보처리자는 법 제21조에 따라 개인정보를 파기할 때에는 다음 각 호의 구분에 따른 방법으로 해야 한다. 1. 전자적 파일 형태인 경우: 복원이 불가능한 방법으로 영구 삭제. 다만, 기술적 특성으로 영구 삭제가 현저히 곤란한 경우에는 법 제58조의2에 해당하는 정보로 처리하여 복원이 불가능하도록 조치해야 한다. 2. 제1호 외의 기록물, 인쇄물, 서면, 그 밖의 기록매체인 경우: 파쇄 또는 소각

표준 개인정보 보호지침 제10조 1항 : 개인정보처리자는 개인정보의 보유 기간이 경과하거나 개인정보의 처리 목적 달성, 가명정보의 처리 기간 경과, 해당 서비스의 폐지, 사업의 종료 등 그 개인정보가 불필요하게 되었을 때에는 정당한 사유가 없는 한 그로부터 5일 이내에 그 개인정보를 파기하여야 한다.

표준 개인정보 보호지침 제10조 2항 : 영 제16조제1항제1호의 '복원이 불가능한 방법'이란 현재의 기술수준에서 사회통념상 적정한 비용으로 파기한 개인정보의 복원이 불가능하도록 조치하는 방법을 말한다.

표준 개인정보 보호지침 제10조 3항 : 개인정보처리자는 개인정보의 파기에 관한 사항을 기록ㆍ관리하여야 한다.

표준 개인정보 보호지침 제10조 4항 : 개인정보 보호책임자는 개인정보 파기 시행 후 파기 결과를 확인하여야 한다.