네, 쓰지 않는다고 창고에 방치해 둔 서버라도 법적 파기 의무에서 예외가 되지 않습니다

새벽 두 시, 한 대형 교육기업 전산실의 모니터링 화면이 일제히 빨간불로 바뀝니다. 2026년 1월, 가상 서버 600여 대가 몇 시간 만에 통째로 암호화됐고, 다음 날 아침 회사는 554만 명(중복 포함 960만 명)에 달하는 이용자 정보가 영향권에 들었다는 사실과 마주해야 했습니다. 홈페이지도 영업 시스템도 멈춰 섰고, 상담 전화는 종일 울렸습니다. 이 상황에서 담당자들이 가장 먼저 찾은 것은 다름 아닌 백업이었습니다.

언제 만든 백업인지, 어디에 보관돼 있는지, 그 백업이 담긴 매체 자체는 암호화되지 않고 온전한 상태인지부터 확인해야 했습니다. 복구의 성패가 결국 평소에 백업매체를 얼마나 꼼꼼히 관리해 왔는지에 달려 있었던 셈입니다. 사고가 나기 전까지는 아무도 눈여겨보지 않던 백업 랙 하나가, 사고가 난 순간부터는 회사 전체의 존폐를 좌우하는 물건으로 바뀌는 순간이었습니다.

올해도 반복된 침해사고, 신호로 읽어야 합니다

이 사고는 올해 벌어진 여러 침해사고 중 하나일 뿐입니다. 같은 해 3월에는 한 엘리베이터 제조사가 랜섬웨어 조직 '에베레스트'의 공격을 받아 1116GB에 달하는 설계도면과 안전 인증서, 임직원 개인정보가 통째로 빠져나갔습니다. 회사가 요구에 응하지 않자 공격 조직은 16년 치 엔지니어링 자산을 다크웹에 그대로 공개해 버렸고, 이 안에는 이미 파기됐어야 할 오래된 설계 이력과 퇴사자 정보까지 섞여 있었던 것으로 알려졌습니다.

6월에는 한 OTT 서비스가 개발 과정에서 노출된 클라우드 관리자 키 때문에 1953만 명 규모의 개인정보가 유출된 것으로 추정되는 사고를 겪었습니다. 주민등록번호를 대체하는 연계정보(CI)와 중복가입확인정보(DI)까지 함께 새어 나가면서, 단순 계정정보 유출보다 훨씬 무거운 파장으로 이어졌습니다. 비슷한 시기 한 창업 지원 프로그램에서는 API 권한 검증이 제대로 되지 않아 1차 합격자 5000명의 프로필과 사업 아이디어, 심사평이 노출될 뻔한 일도 있었습니다.

랜섬웨어처럼 시스템 전체를 멈춰 세우는 큰 사고가 아니더라도, 접근 권한 관리 하나가 허술하면 얼마든지 유출로 이어질 수 있다는 점을 보여준 사례입니다. 언론이 "랜섬웨어부터 개인정보 유출까지, 올해도 계속된 침해사고"라는 제목으로 이런 사건들을 한데 묶어 다룰 정도로, 사고 유형은 저마다 달라도 원인은 비슷하게 반복되고 있습니다. 내부 자격증명 관리 부실, 오래된 서버·백업 장비 방치, 유출 이후 초기 대응의 미숙함이 그것입니다.

뉴스 자체보다 중요한 것은 비슷한 상황이 우리 조직의 서버, 백업 장비, 문서, 저장매체 관리에서도 반복될 수 있는지 확인하는 일입니다. 정보보호는 총무, 전산, 보안, 개인정보보호 담당자가 평소에는 가볍게 넘기기 쉬운 영역이지만, 사고가 터진 뒤에는 무엇을 어떤 기준으로 처리했는지, 그 결과를 어떻게 확인했는지가 가장 먼저 도마 위에 오릅니다. 특히 백업매체는 평소 눈에 잘 띄지 않는 창고나 별도 랙에 보관되는 경우가 많아, 점검 대상에서 조용히 빠지기 쉬운 항목이기도 합니다.

재해복구용 백업이 유독 취약한 이유

운영 서버는 그래도 관리 대상이 명확합니다. 담당자가 지정돼 있고, 접근 기록이 남고, 교체 주기도 정해져 있는 경우가 많습니다. 문제는 만일의 사태에 대비해 별도로 마련해 둔 재해복구(DR)용 백업입니다. 이런 백업은 평소에는 조회할 일이 거의 없다 보니, 오프라인 상태로 창고나 외부 보관소에 몇 년씩 방치되는 경우가 흔합니다. 담당자가 바뀌면서 "누가 이 장비를 관리하는지"조차 불분명해지기도 하고, 암호화나 접근 통제 수준이 운영 시스템보다 낮게 설정된 채로 방치되는 일도 드물지 않습니다. 그런데 정작 랜섬웨어 공격을 받았을 때 회사의 존폐를 가르는 것은 바로 이 백업입니다.

복구할 수 있는 백업이 있느냐 없느냐, 그 백업 자체가 오염되지 않았느냐에 따라 며칠 만에 정상화되는 회사와 몇 주씩 마비되는 회사로 갈립니다. 그래서 백업매체는 평소의 보안 점검뿐 아니라, 수명이 다했거나 세대교체가 이뤄질 때의 파기 점검에서도 운영 장비와 동일한 기준으로 다뤄야 합니다. 아울러 새 백업 장비로 교체할 때는 복구 테스트를 거쳐 데이터가 실제로 정상 복원되는지를 확인한 뒤에야 기존 장비를 처리 대상으로 넘기는 순서를 지켜야 합니다. 새 장비의 백업이 제대로 작동하는지 확인하지도 않은 채 옛 장비부터 파기해 버리면, 정작 사고가 났을 때 되돌릴 수 있는 지점 자체가 사라져 버릴 수 있습니다.

포맷과 삭제만으로는 왜 안심할 수 없나

저장매체와 업무 데이터는 파일을 지우거나 포맷하는 것만으로 안전해졌다고 보기 어렵습니다. 일반적인 삭제나 포맷은 파일 시스템의 색인 정보만 지울 뿐, 실제 데이터가 저장된 영역은 그대로 남겨두는 경우가 대부분이기 때문입니다. SSD는 특히 더 까다롭습니다. 웨어 레벨링이라는 내부 방식 때문에 같은 파일이 여러 물리적 위치에 흩어져 저장되고, 겉보기에는 지워진 것처럼 보여도 실제로는 복구 도구로 상당 부분을 되살릴 수 있는 상태가 남아 있을 수 있습니다.

개인정보 보호법은 이 지점을 분명히 짚고 있습니다. 개인정보처리자는 보유기간의 경과, 처리 목적 달성 등 해당 개인정보가 불필요하게 됐을 때에는 지체 없이 개인정보를 파기해야 하고(제21조 1항), 다른 법령에 따라 보존해야 하는 경우가 아니라면 목적을 다한 개인정보는 파기하거나 다른 정보와 분리해 관리해야 합니다(제21조 3항). 여기서 말하는 파기는 단순 삭제가 아니라 복구나 재생이 불가능한 상태로 만드는 조치를 뜻하며, 구체적인 방법은 시행령에서 전자적 파일과 물리적 매체를 나눠 정하고 있습니다. 전자적 파일은 복원이 불가능한 방식의 영구 삭제를 원칙으로 하고, 하드디스크나 백업테이프 같은 물리적 매체는 파쇄나 소각, 자기 정보 자체를 지우는 디가우징 방식을 원칙으로 삼습니다.

실제로 이 기준을 지키지 않아 적발된 사례도 있습니다. 한 여행사는 2010년부터 2011년 사이 수집한 고객정보 1000여 건을 5년 넘게 보유하면서, 그 안에 평문 형태의 주민등록번호까지 그대로 남겨둔 채 방치하다 적발됐습니다. 문제는 이런 자료가 늘 운영 중인 시스템이 아니라 예전 시스템을 옮기며 남겨둔 백업이나 오래된 서버 이미지 안에 잠들어 있는 경우가 많다는 점입니다. 당장 쓰지 않는다는 이유로 처리 대상에서 빠진 채 몇 년씩 방치되다가, 사고나 감사가 계기가 되어서야 뒤늦게 존재가 드러나는 식입니다. 

담당자 입장에서는 "언제 만들어졌는지도 모르는 백업"을 함부로 지우기도, 그렇다고 계속 끌어안고 있기도 부담스러운 상황이 됩니다. 그럴수록 오래된 백업일수록 먼저 목록에 올려 존재 자체부터 확인하고, 그 안에 무엇이 담겨 있는지 파악한 뒤 보존 기한이 지났다면 지체 없이 처리 대상으로 넘기는 원칙을 세워두는 편이 안전합니다.

증빙 없는 파기가 만드는 더 큰 리스크

파기 절차와 증빙이 왜 중요한지 보여주는 사례가 있습니다. 2025년 7월 18일, 한국인터넷진흥원은 한 통신사에 정보 유출 정황을 인지하고 이를 안내했습니다. 그런데 회사는 안내를 받은 지 열흘 남짓 지난 7월 31일, 관련 관리 서버 한 대를 물리적으로 파기하고 계정 권한 관리 시스템 서버의 운영체제까지 업그레이드해 버렸습니다. 이후 8월 13일 회사는 "침해사고 흔적이 없다"고 통보했지만, 10월 뒤늦게 꾸려진 민관합동조사단은 서버 재설치와 파기 작업 때문에 침해사고의 흔적을 확인할 수 없는 조사 불가 상황에 놓였다고 결론지었습니다. 결국 정부는 그해 12월, 위계에 의한 공무집행 방해 혐의로 이 회사를 경찰에 수사 의뢰하는 데까지 이르렀습니다.

이 회사가 실제로 조사를 방해할 의도였는지와는 별개로, 이 사례가 보여주는 것은 분명합니다. 언제, 무엇을, 어떤 사유로, 누구의 확인을 거쳐 파기했는지에 대한 기록이 없으면 아무리 정당한 업무 처리였더라도 사후에 이를 소명할 방법이 없다는 것입니다. 담당자 입장에서는 단순히 노후 장비를 교체하거나 정기 유지보수 차원에서 진행한 파기였다 해도, 그 시점과 절차를 뒷받침할 기록이 없다면 억울한 상황에서도 그 억울함조차 증명하기 어려워집니다.

같은 이유로 개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 않도록 기술적·관리적·물리적 조치를 다해야 하는 안전조치의무를 지고 있습니다(제29조). 이 의무는 개인정보가 살아 있는 동안뿐 아니라, 파기하기로 결정한 순간부터 실제로 파기가 끝나는 순간까지도 그대로 이어집니다. 처리 중인 매체가 잠깐이라도 통제 밖에 놓이면, 그 공백이 곧 유출 경로가 되거나, 혹은 유출 여부를 영영 확인할 수 없는 블랙박스가 되어버립니다. 실무에서는 이 통제의 공백이 하루 이틀의 아주 짧은 순간에 생기는 경우가 많습니다. 파기 업체에 인계하기 전 임시 보관 장소에 며칠 쌓아 두거나, 담당자 교체 시기와 파기 일정이 겹치면서 확인 절차가 흐지부지되는 식입니다. 결국 파기는 한순간의 작업이 아니라, 인계·보관·처리·확인이라는 연속된 과정으로 봐야 통제가 끊기지 않습니다.

점검 기준은 목적에 따라 갈립니다

현장에서 이 문제가 까다로운 이유는 기술 설명만으로 끝나지 않기 때문입니다. 실제로는 일정과 비용, 보안 수준, 외부 반출 여부, 내부 승인 절차가 동시에 얽혀 돌아갑니다. 담당자 한 사람이 이 모든 변수를 그때그때 판단하려 하면 결정이 늦어지거나, 반대로 급한 마음에 절차를 건너뛰고 처리부터 해버리는 상황이 생기기 쉽습니다. 그래서 처음부터 몇 가지 기준을 세워 처리 방식을 나누는 편이 안전합니다.

우선 HDD와 SSD, 외장하드, NAS, 백업테이프처럼 매체 종류부터 구분해야 합니다. 매체마다 데이터가 저장되는 방식이 다르고, 그만큼 완전히 지우는 방법도 달라지기 때문입니다. 자기 방식으로 데이터를 저장하는 HDD나 테이프는 디가우징으로 자기 정보 자체를 지울 수 있지만, 플래시 메모리를 쓰는 SSD는 디가우징이 통하지 않아 물리적 파쇄나 검증된 소프트웨어 삭제가 필요합니다.

다음으로 그 매체 안에 개인정보나 고객자료처럼 민감한 정보가 실제로 있었는지를 확인해야 합니다. 오래된 백업일수록 "무엇이 들어 있는지 이제는 아무도 정확히 모른다"는 상태에 빠지기 쉬운데, 바로 이 지점에서 위에서 본 여행사 사례처럼 방치된 개인정보가 뒤늦게 발견되곤 합니다. 그다음은 앞으로 다시 쓸 장비인지, 아예 완전히 파기할 장비인지를 나누는 일입니다. 재사용할 장비라면 초기화 후 검증까지 마쳐야 안심할 수 있고, 완전히 파기할 장비라면 삭제와 디가우징, 물리 파쇄 중 목적에 맞는 방식을 골라야 합니다. 여기에 더해 현장 입회가 필요한 작업인지도 미리 정해두어야 합니다.

민감도가 높은 자료일수록 담당자가 직접 파기 현장을 지켜보고 확인하는 절차가 요구되는 경우가 많기 때문입니다. 마지막으로 이 모든 과정을 사진이나 리포트 같은 결과 기록으로 남길 수 있는지를 확인해 두어야, 나중에 "그때 분명히 처리했다"는 말이 아니라 실제 증빙으로 상황을 설명할 수 있습니다.

이 다섯 가지 기준을 매번 처음부터 새로 정하려 하면 담당자마다 판단이 달라지고, 시간이 지날수록 기준 자체가 흐려집니다. 그래서 한 번이라도 정리해 둔 기준이 있다면 문서로 남겨 다음 담당자에게 그대로 물려주는 편이 낫습니다. 매체 종류별로 어떤 파기 방식을 쓸지, 민감도 판단은 누가 내릴지, 현장 입회가 필요한 기준 금액이나 자료 등급은 무엇인지를 정해 두면, 실제 상황이 닥쳤을 때 매번 새로 회의를 열지 않고도 정해진 절차대로 움직일 수 있습니다. 이런 기준표는 거창한 규정집일 필요가 없습니다. 한 장짜리 체크리스트만으로도, 담당자가 바뀌거나 여러 부서가 동시에 장비를 처리해야 하는 상황에서 판단 기준이 흔들리는 일을 크게 줄일 수 있습니다.

처리 방식은 목적에 따라 달라집니다

재사용 여부는 특히 판단이 갈리는 대목입니다. 다시 쓸 장비나 자료라면 초기화 기록과 검증 결과가 핵심이 됩니다. 예를 들어 퇴사자가 쓰던 노트북을 다음 입사자에게 재지급하려 한다면, 단순히 공장 초기화 버튼을 누르는 것이 아니라 검증된 삭제 도구로 지우고 그 결과를 리포트로 남겨야 이후 문제가 생겼을 때 "이 장비는 안전하게 초기화됐다"고 설명할 수 있습니다. 반대로 검증 없이 눈대중으로 "초기화했으니 괜찮겠지"라는 판단만으로 넘기면, 몇 달 뒤 그 장비를 받은 사람이 이전 사용자의 자료를 그대로 열어보는 일이 생길 수 있습니다. 한편 완전히 파기하거나 외부로 반출해야 하는 경우에는 처리 방식이 목적에 맞는지, 운송 과정에서 통제가 끊기지 않는지, 결과를 어떻게 증빙할지가 더 중요해집니다.

외부 업체가 개입하는 순간부터는 특히 그렇습니다. 사내에서만 처리할 때는 관행적으로 넘어가던 부분도, 매체가 문 밖을 나서는 순간부터는 별개의 문제가 됩니다. 장비나 자료가 사내를 벗어나는 시점부터 인수인계, 운송, 작업 완료 확인까지 책임 범위를 문서로 정리해 두지 않으면, 문제가 생겼을 때 어디까지가 우리 조직의 책임이고 어디부터가 위탁업체의 책임인지조차 가리기 어려워집니다. 위탁 업무의 재위탁 여부나 운송 중 보관 방식처럼 세부적인 부분까지 사전에 합의해 두는 편이, 나중에 분쟁이 생겼을 때 훨씬 유리합니다.

예를 들어 지방 지사에서 쓰던 노후 서버 랙을 본사로 옮겨 파기하려 한다면, 이동 중 분실 위험을 줄이기 위해 가능한 한 현장에서 직접 파기하는 방식을 검토하는 편이 안전합니다. 반대로 소량의 문서형 자료를 정기적으로 파기하는 경우라면, 매번 현장 파기 인력을 부르기보다 정해진 주기로 위탁 업체에 맡기고 결과 리포트만 받는 방식이 더 효율적일 수 있습니다. 결국 정답은 하나로 정해져 있지 않고, 자료의 민감도와 이동 거리, 빈도를 함께 따져 그때그때 가장 통제가 끊기지 않는 방식을 고르는 것이 핵심입니다.

결과 증빙까지 남겨야 설명이 쉬워집니다

많은 조직이 작업이 끝났다는 사실만 확인하고 넘어갑니다. 하지만 실제로 문제가 생겼을 때 필요한 것은 처리 과정 자체의 기록입니다. 어떤 장비를 처리했는지, 누가 확인했는지, 어떤 방식으로 처리했는지, 그 결과를 어떤 자료로 남겼는지가 함께 있어야 나중에 설명이 가능해집니다. 장비 목록과 시리얼 정보를 파기 이전에 먼저 정리해 두고, 반출 시점의 인수인계자와 운송 책임 범위를 기록하고, 처리가 끝난 뒤에는 파쇄 전후 사진이나 작업 일시, 담당자 서명이 담긴 결과 증빙을 내부 보안 문서와 함께 보관해 두는 흐름이 이어져야 합니다.

이렇게 남긴 기록은 감사나 조사가 들어왔을 때뿐 아니라, 고객사나 상위 기관에 처리 경위를 설명해야 하는 상황에서도 그대로 근거 자료가 됩니다. 잘 갖춰진 파기확인서에는 대개 처리 대상 장비의 종류와 시리얼 번호, 처리 일시와 장소, 적용한 파기 방식, 입회자와 작업자 서명, 파기 전후 사진이 함께 담깁니다. 이 중 하나라도 빠지면 나중에 "그 장비를 정말 파기했는가"라는 질문에 온전히 답하기 어려워집니다.

알테크코리아가 이 흐름에서 하는 역할

 알테크코리아는 이 흐름 전체를 현장에서 마무리하는 역할을 합니다. 데이터파기 브랜드인 다이하드(DieHDD™) 서비스로 하드디스크와 SSD를 현장에서 직접 천공·분쇄해 매체가 사내를 벗어나기 전에 파기를 마칠 수 있고, 재사용을 전제로 데이터만 완전삭제해야 하는 경우에는 국제 인증을 받은 블랑코(Blancco)와 협력해 소프트웨어 방식의 삭제와 검증 리포트를 함께 제공합니다. 자기 방식 매체는 디가우징 장비로 별도 처리하고, 대량 파기가 필요한 상황에서는 파쇄와 소각까지 연계해 진행합니다.

처리 절차도 앞서 살펴본 점검 기준을 그대로 따라갑니다. 먼저 처리 대상 장비의 종류와 수량, 민감도를 사전에 확인하고 견적과 일정을 협의합니다. 필요하다면 담당자가 입회한 상태에서 현장 파기를 진행하고, 그렇지 않은 경우에도 인수인계 시점과 운송 책임 범위를 문서로 남깁니다. 작업이 끝나면 처리 대상 목록, 작업 일시와 담당자, 파기 전후 사진과 결과 리포트를 함께 전달해, 고객사가 나중에 같은 내용을 다시 확인할 수 있도록 합니다. 담당자가 바뀌거나 시간이 한참 지난 뒤에 그 시절 처리 내역을 다시 확인해야 하는 상황이 오더라도, 문서만 찾아보면 언제 무엇을 어떻게 처리했는지 그대로 답할 수 있게 하는 것이 이 리포트의 목적입니다. 이 주제는 불안을 과장하기보다, 담당자가 실제로 확인할 수 있는 기준으로 정리할 때 더 설득력을 갖습니다.

마무리 점검

정보보호 업무는 한 번 처리하고 끝나는 일이 아니라, 내부 관리 기준과 외부 설명 책임까지 이어지는 과정입니다. 처리 대상과 보관 위치가 정리돼 있는지, 처리 목적과 보안 수준이 명확한지, 담당자와 최종 확인자가 지정돼 있는지, 처리 방식이 목적에 맞는지, 그리고 결과 증빙을 나중에 다시 확인할 수 있는 형태로 보관하고 있는지를 순서대로 짚어보는 것만으로도 불필요한 리스크를 상당 부분 줄일 수 있습니다. 랜섬웨어든 내부 관리 소홀이든, 결국 문제를 키우는 것은 사고 자체보다 그 이후를 설명하지 못하는 상황이기 때문입니다. 

지금 창고에 방치된 백업 장비가 없는지, 재사용과 완전 파기 사이에서 결정을 미뤄둔 매체가 없는지 한 번쯤 목록을 꺼내 확인해 보는 것만으로도, 다음번 사고가 났을 때 설명할 수 있는 조직과 그렇지 못한 조직의 차이가 갈릴 수 있습니다. 지금 5분을 들여 확인해 두는 목록 하나가, 몇 달 뒤 조사나 감사 앞에서 몇 주를 벌어주는 자료가 될 수도 있습니다.

법령 원문

개인정보 보호법 제21조(개인정보의 파기) 제1항 "개인정보처리자는 보유기간의 경과, 처리 목적 달성 등 해당 개인정보가 불필요하게 됐을 때에는 지체 없이 개인정보를 파기해야 한다."

개인정보 보호법 제21조(개인정보의 파기) 제3항 목적을 달성한 개인정보는 파기하거나, 다른 법령에 따라 보존해야 하는 경우가 아니면 다른 개인정보와 분리하여 저장·관리해야 한다는 취지를 정하고 있다.