72. 개인정보 파기 정책 및 로그 보존 기간 준수 감리

⚠️ 이 문서는 기업의 데이터베이스와 서버에 쌓이는 고객의 개인정보와 접속 기록(로그)이 영원히 방치되어 대형 유출 사고의 뇌관이 되는 것을 막기 위해, 수집 목적이 달성된 개인정보를 즉각적이고 영구적으로 삭제(파기)하는 로직과, 법령이 정한 기간 동안 로그를 보존하는 상충되는 두 가지 컴플라이언스(법적 요건)가 시스템에 100% 구현되었는지 점검하는 보안 감리 지침을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: "우리는 탈퇴한 회원의 데이터를 잘 지우고 있습니다"라는 개발자의 구두 보고를 믿지 않고, DB 내의 자동화된 삭제 배치(Batch) 프로그램의 작동 여부와 물리적 파일 삭제의 완전성(복구 불가)을 기술적으로 추적하는 감사(Audit)다.
  2. 가치: 불필요한 개인정보를 쥐고 있다가 해킹당하면 회사가 감당할 수 없는 징벌적 과징금(전체 매출의 최대 3%)을 맞게 되므로, 데이터 다이어트를 강제하여 회사의 법적 리스크를 근본적으로 제거한다.
  3. 기술 체계: 회원이 탈퇴하거나 유효기간(예: 1년 미접속)이 지난 데이터를 찾아내는 조건 검색 로직, DB 테이블의 DELETE 후 스토리지 내 찌꺼기 파기(Wipe), 그리고 이 모든 과정을 기록으로 남기는 파기 관리 대장의 자동화 여부를 점검한다.

Ⅰ. 수집보다 무서운 파기: 개인정보보호법의 철퇴

개인정보는 기업의 자산이 아니라 '언제든 터질 수 있는 시한폭탄'이다.

  1. 파기 원칙 (지체 없이 파기):
    • 개인정보보호법에 따르면, ① 보유 기간이 경과했거나, ② 서비스가 종료되었거나, ③ 회원이 탈퇴를 요청하여 '수집 목적이 달성된' 개인정보는 그 즉시(지체 없이, 통상 5일 이내) 파기해야 한다.
  2. 논리적 삭제(Soft Delete)의 꼼수 적발:
    • 개발자들은 DB 테이블에서 데이터가 완전히 날아가는 것을 두려워하여, is_deleted = 1 이나 status = '탈퇴' 처럼 상태 값만 슬쩍 바꾸고 데이터는 DB에 그대로 놔두는(Soft Delete) 꼼수를 자주 쓴다.
    • 감리 포인트: 감리인은 이런 논리적 삭제를 엄격히 적발하며, 배치 스크립트가 돌아 DELETE FROM users WHERE... 명령으로 물리적인 레코드(Hard Delete)를 완전히 날려버리는지 소스코드를 확인한다.
  3. 분리 보관의 유효성:
    • 상법이나 전자상거래법 등 다른 법률에 의해 탈퇴한 회원의 결제 내역(5년 보관 등)을 어쩔 수 없이 보관해야 할 때가 있다.
    • 이때는 운영 DB에 그대로 놔두는 것이 아니라, 접근 권한이 완전히 분리된 별도의 '분리 보관 DB'로 데이터를 복사한 뒤 운영 DB에서는 즉시 삭제하는 아키텍처가 구현되었는지 감리한다.

📢 섹션 요약 비유: 식당에서 손님이 밥을 먹고 나가면, 테이블을 치우고 손님이 쓰던 냅킨(개인정보)을 즉시 쓰레기통에 버려야 합니다. 손님이 나갔는데도 "언젠가 또 올지 몰라"라며 냅킨을 서랍(Soft Delete)에 계속 모아두면 위생 점검(감리)에서 영업정지 처분을 받습니다.

Ⅱ. 파기의 완전성: 복구 불가능성 점검

그냥 지웠다고 끝이 아니다. 해커의 포렌식 복구를 막아야 한다.

  1. 물리적 파기의 기준:
    • 하드디스크의 파일을 지울 때 휴지통에 버리거나 rm 명령어만 치면 데이터의 실제 내용은 디스크에 남아있고 목차(포인터)만 지워져 복구 프로그램으로 쉽게 살려낼 수 있다.
  2. 로우 레벨 포맷과 덮어쓰기 (Wipe/Shredding):
    • 감리인은 서버를 폐기하거나 백업 테이프를 버릴 때, 디스크를 천공기(드릴)로 아예 물리적으로 박살 내 거나(파쇄), 무작위 데이터(0과 1)를 디스크 전체에 3번 이상 덮어써서(DoD 5220.22-M 표준 등) 절대 영구 복원이 불가능하도록 조치하는 지침이 존재하는지 점검한다.
  3. 백업 파일 속의 좀비 데이터:
    • 1년 전에 탈퇴한 회원의 데이터가 운영 DB에서는 잘 지워졌는데, 시스템 관리자가 보관 중인 3년 치 DB 백업본 파일(.bak) 안에는 여전히 살아 숨 쉬고 있는 경우가 감리의 가장 흔한 단골 적발 사례다.
    • 감리인은 백업 데이터 복원 시 파기된 데이터가 다시 살아나지 않도록 운영 절차(매뉴얼)가 수립되어 있는지 깐깐하게 묻는다.

📢 섹션 요약 비유: 기밀문서를 버릴 때 그냥 구겨서 쓰레기통에 버리면(일반 삭제), 산업 스파이가 쓰레기통을 뒤져 문서를 펴서 다 읽습니다. 법에서는 반드시 문서 세단기(파쇄기)에 넣고 형체를 알아볼 수 없게 가루로 만들어(완전 파기) 버려야만 파기로 인정해 줍니다.

Ⅲ. 로그 보존 기간 준수 (상충하는 컴플라이언스)

개인정보는 빨리 지워야 하지만, 범인을 잡을 로그는 오래 들고 있어야 한다.

  1. 접속 기록(로그) 보관의 의무:
    • 직원이 고객 DB에 언제, 누구의 데이터를, 어떤 IP로 접속해서 조회했는지를 남기는 '개인정보 취급자 접속 기록'은 해킹 사고 발생 시 범인을 잡기 위한 유일한 단서다.
  2. 보존 기간 컴플라이언스 (1년 vs 2년):
    • 개인정보보호법 고시에 따라 이 접속 로그는 최소 1년 이상 보관해야 한다.
    • 단, 통신사나 포털 등 5만 명 이상의 개인정보를 보유하거나 고유식별정보(주민번호 등)를 처리하는 덩치가 큰 시스템은 무조건 2년 이상 로그를 보관해야 한다.
  3. 감리인의 점검 시나리오:
    • "서버 용량이 꽉 찬다고 시스템이 6개월 지난 로그를 자동 삭제하게 세팅해 두지는 않았는가?"
    • "2년이 지난 로그는 법적 보존 의무가 끝났으니, 반대로 즉시 자동 파기하여 불필요한 데이터를 쥐고 있지 않는가?" (로그에도 파기 정책이 적용되어야 함)

📢 섹션 요약 비유: 회사의 장부(개인정보)는 목적을 달성하면 즉시 불태워야 하지만, 그 장부를 누가 열어봤는지 기록한 '방명록(로그)'은 경찰 수사(해킹 사고)를 대비해 법적으로 무조건 금고에 2년 동안 보관해야 합니다. 감리인은 방명록이 1년 만에 버려지지도 않고, 반대로 10년 치가 무단 방치되지도 않는지, 정확한 시계(스케줄러)를 검사합니다.