개인정보보호법 개정안이 지난 2월 국회를 통과했다. 뉴스 헤드라인은 전부 "매출 10% 과징금"에 꽂혀 있다. 맞다, 무섭긴 하다. 근데 과징금보다 개발팀을 더 뒤흔들 조항이 하나 있다.
유출 "가능성" 통지 의무.
기존에는 "유출이 된 사실을 알았을 때" 통지하면 됐다. 개정안은 이걸 "유출 가능성이 있음을 알게 된 때"로 바꿨다. 한 글자 차이인데, 지각변동이 어마어마하다.
과징금 10%는 생각보다 먼 얘기다
솔직히 말하자. 매출 10% 과징금은 "고의 또는 중대한 과실로 3년 내 반복 위반"이거나 "1천만 명 이상 대규모 피해"가 발생했을 때 적용된다. 시정조치 명령을 씹고도 유출이 터진 경우도 해당. 대부분의 서비스에는 해당 안 되는 극단적 시나리오다.
게다가 예산·인력·설비에 사전 투자한 기록이 있으면 감경도 가능하다. 과징금 조항은 "최악의 최악"을 겨냥한 천장이지, 일상적 위협이 아니다.
EU GDPR이 매출 4% 상한을 도입했을 때도 비슷한 공포 마케팅이 있었다. 결과적으로 GDPR 시행 5년간 최대 과징금을 실제로 맞은 건 Meta, Amazon 같은 빅테크 몇 곳뿐이다. 한국도 비슷한 패턴을 밟을 가능성이 높다. 10%라는 숫자 자체가 억지력으로 기능하는 것이지, 실제 적용 빈도가 높을 구간은 아니다.
유출 가능성 통지는 다르다
반면 "가능성 통지"는 당장 내일부터 모든 서비스에 영향을 준다. 예를 들어보자.
WAF 로그에 SQL injection 시도가 잡혔는데 성공 여부가 불확실한 상황
개발자 계정 크리덴셜이 퍼블릭 레포에 5분간 노출됐다가 revoke한 상황
서드파티 라이브러리에 CVE가 뜨고 우리 서비스가 해당 버전을 쓰고 있는 상황
전부 "가능성"이다. 전부 통지 대상이 될 수 있다.
여기서 실무적으로 가장 곤란한 건 두 번째 케이스다. GitHub secret scanning 알림이 오거나 TruffleHog 같은 도구가 크리덴셜 노출을 잡아냈다고 해보자. revoke까지 5분 걸렸다면, 그 5분 사이에 누군가 클론했는지 안 했는지는 확인이 불가능하다. Git 호스팅 측 액세스 로그를 제출해야 "가능성 없음"을 입증할 수 있는데, 그 로그를 확보하는 데 며칠이 걸릴 수도 있다. 그 사이 통지를 안 하면? 법 위반이다.
세 번째 케이스도 만만찮다. Log4Shell 사태를 떠올려 보라. CVE 공개 후 PoC가 몇 시간 만에 돌았고, 실제 공격은 패치 전에 시작됐다. 해당 라이브러리를 쓰고 있다는 사실만으로 "가능성"이 성립한다면, CVE 하나 뜰 때마다 통지 검토를 해야 한다는 뜻이다.
"가능성"의 범위가 아직 불분명하다
법 조문만 놓고 보면, 어디까지가 통지 대상인지 해석의 여지가 넓다. 개인정보위가 시행령이나 가이드라인을 통해 구체화하겠지만, 시행 초기에는 혼란이 불가피하다. 일본의 경우 2022년 개인정보보호법 개정 때 비슷한 "가능성 통지" 조항을 도입했는데, 초기 2년간 기업들의 과잉 통지(over-notification)가 문제가 됐다. 모든 의심 이벤트를 다 통지하니 정작 진짜 위험한 건이 묻혀버린 것이다. 한국도 같은 함정에 빠질 수 있다.
반론도 있다. "가능성 통지"가 보안 투자를 강제하는 긍정적 효과가 크다는 시각이다. 통지 의무가 무거울수록 기업은 모니터링에 더 투자하고, 결국 실제 유출 건수가 줄어든다는 논리. 틀린 말은 아닌데, 그건 충분한 인력과 예산이 있는 대기업 얘기다. 개발자 5명짜리 스타트업이 모든 WAF 알림에 법적 통지 검토를 붙이는 건 현실적으로 불가능하다.
인시던트 리스폰스 파이프라인을 다시 짜야 한다
지금까지 보안 인시던트 대응은 "확인 → 분석 → 보고" 순서였다. 실제 유출이 확정돼야 통지 의무가 발동했으니까. 이제는 "탐지 → 즉시 보고 → 분석"이다. 확인 전에 통지부터.
이건 법무팀만의 문제가 아니다. 모니터링 파이프라인, 알럿 체계, 온콜 프로세스를 전면 재설계해야 한다. 로그에 의심 패턴 하나 잡히면 개인정보위 통지 프로세스를 트리거할 수 있는 자동화가 필요하다. 지금 수동으로 Slack 채널에 올려서 판단하는 구조로는 법적 요건을 충족할 수 없다.
구체적으로 뭘 해야 하는지 정리하면 이렇다.
탐지 단계에서: SIEM(Splunk, Elastic 등)의 탐지 룰에 "개인정보 관련 이벤트" 태그를 추가한다. DB 쿼리 이상 패턴, 인증 실패 급증, 비정상적 대량 데이터 조회 같은 시그널이 잡히면 별도 채널로 분기시킨다. 기존에는 "보안팀이 판단해서 에스컬레이션"이었지만, 이제는 특정 조건이 맞으면 자동으로 법무 검토 워크플로가 시작돼야 한다.
판단 단계에서: 모든 이벤트를 통지하면 과잉 통지 문제가 생긴다. 내부적으로 3단계 분류 기준을 만들어야 한다. 예를 들어 Level 1은 "자동 차단 완료, 데이터 접근 흔적 없음"으로 내부 기록만. Level 2는 "차단했으나 접근 여부 불확실"로 24시간 내 분석 후 결정. Level 3은 "접근 확인 또는 확인 불가"로 즉시 통지. 이 기준이 문서화돼 있지 않으면 온콜 담당자마다 다른 판단을 내리게 되고, 그게 곧 컴플라이언스 리스크다.
통지 단계에서: 개인정보위 통지 양식과 필수 기재 항목을 템플릿화해둔다. 사고 발생 시점에 양식을 찾고 항목을 채우는 데 시간을 낭비하면 72시간 통지 기한을 못 맞출 수 있다. 자동화까지는 아니더라도, Jira 티켓이나 PagerDuty 인시던트에 연동된 템플릿 정도는 준비해놔야 한다.
ISMS-P 인증 의무화(2027년 7월 시행)도 같은 맥락이다. 인증 심사에서 "유출 가능성 인지 시 즉시 통지" 프로세스가 문서화되어 있는지 확인할 거다. 미인증 시 과태료 3천만 원은 덤.
정리하면
과징금 헤드라인에 겁먹을 시간에, 인시던트 리스폰스 파이프라인부터 점검하라. 당장 할 수 있는 건 세 가지다. 첫째, SIEM 탐지 룰에 개인정보 이벤트 태그 추가. 둘째, 3단계 분류 기준 문서화. 셋째, 통지 양식 템플릿 준비. 이 세 가지만 해놔도 시행 초기 혼란기를 버틸 수 있다. 법 시행은 공포 후 6개월. 시간 없다.