[머니투데이방송] 쿠팡 사태, 로그 기준 없는 과징금 산정 기준은?

By PLURA 2026-06-15

쿠팡 개인정보 유출 및 침해 사안에 대규모 제재가 내려졌다.

개인정보보호위원회는 쿠팡에 과징금 6,246억 8,100만 원과 과태료 1,680만 원을 부과했고, 개인정보 유출과 관련해서는 인증 서명키 관리와 접근통제 소홀 등으로 약 3,755만 명의 개인정보가 유출됐다고 결론냈다.1

숫자만 보면 충격적이다.

그러나 이 사건의 핵심은 과징금 액수 그 자체가 아니다.

더 중요한 질문은 따로 있다.

무엇이 확인된 사실이고, 무엇이 기술적 추정이며, 무엇은 확인 불가인가

그리고 그 차이가 과징금 산정에 어떻게 반영되었는가다.

이 글은 쿠팡의 책임을 가볍게 보자는 글이 아니다.

서명키 관리가 부실했다면 문제다.
위·변조된 전자 출입증을 검증하지 못했다면 문제다.
개인정보가 포함된 페이지가 대량 조회되는 동안 탐지하지 못했다면 문제다.
사고 이후 로그 보존에 실패했다면 더 심각한 문제다.

기업은 책임져야 한다.

다만 책임을 묻는 방식은 정밀해야 한다.

행정제재는 여론의 분노를 대신하는 절차가 아니다.
확인된 사실, 법적 의무, 피해 규모, 예방 노력, 사후 대응 노력 위에 서야 한다.

즉,

개인정보 과징금은 로그 위에 서야 한다

핵심 요약

이 글의 주장은 다섯 가지다.

질문	답
과징금이 문제인가	액수보다 산정 기준이 중요하다
무엇이 기준인가	확인된 사실, 기술적 추정, 확인 불가의 구분이다
무엇으로 구분하는가	웹 요청·응답, 인증, 데이터 접근, 서버·네트워크 로그다
정책적으로 더 구체화할 것은 무엇인가	어떤 로그가 충분한 소명 근거가 될 수 있는지다
기업이 할 일은 무엇인가	접속기록 보관을 넘어 사고 설명 가능한 로그 체계를 갖추는 것이다

로그가 없으면 피해 규모는 추정에 가까워진다.
로그가 있으면 사실과 추정을 나눌 수 있다.
로그 기준이 명확하면 기업도 무엇을 준비해야 하는지 알 수 있다.

한눈에 보는 판단 구조

쿠팡 사태와 로그 기준 쟁점 흐름

개인정보 사고에서 로그 기준은 단순한 보관 항목이 아니다.

사고 요청과 응답이 남아 있어야 조회, 유출, 외부 전송 가능성을 나누어 볼 수 있다.

단계	핵심 질문	필요한 기준
사고 발생	어떤 개인정보가 노출됐는가	조회, 유출, 전송의 구분
조사·분석	무엇이 확인됐고 무엇이 추정인가	웹·인증·데이터·서버·네트워크 로그
제재 산정	로그 부재와 예방·대응 노력은 어떻게 반영되는가	사전 예방, 사고 인지, 증거 보전, 피해 산정 기준
재발방지	다음 기업은 무엇을 준비해야 하는가	위험도 기반 로그 수집·보호·보존 가이드

따라서 이 글의 핵심은 특정 기업을 두둔하거나 특정 기관을 비판하는 데 있지 않다.

사실과 추정을 나누는 기준, 그 기준을 가능하게 하는 로그 체계, 그리고 이를 행정제재와 재발방지 기준으로 연결하는 방법을 보자는 것이다.

수치부터 나누어 보자

이번 사건의 숫자는 발표 주체와 산정 기준에 따라 다르게 제시된다.

따라서 먼저 구분이 필요하다.

발표 주체	핵심 수치	의미
민관합동조사단	내정보 수정 페이지 이용자 정보 33,673,817건 유출 확인	성명·이메일이 포함된 특정 페이지 기준 산정
민관합동조사단	배송지 목록 페이지 148,056,502회 조회	성명·전화번호·주소 등 배송지 목록 조회 횟수
민관합동조사단	실제 외부 전송 여부는 기록 부재로 확인 불가	공격 스크립트의 전송 기능과 실제 전송은 구분 필요
개인정보보호위원회	약 3,755만 명 개인정보 유출 결론	최종 제재 처분에서 제시된 개인정보 유출 규모
개인정보보호위원회	과징금 6,246억 8,100만 원, 과태료 1,680만 원	유출 및 기타 개인정보 침해 사안에 대한 제재

민관합동조사단은 내정보 수정 페이지에서 성명과 이메일이 포함된 이용자 정보 33,673,817건이 유출됐고, 배송지 목록 페이지가 148,056,502회 조회됐다고 발표했다.2

또한 공격자 PC에서 정보 수집 및 외부 서버 전송이 가능한 공격 스크립트를 확인했지만, 실제 전송이 이루어졌는지는 기록이 남아 있지 않아 확인할 수 없었다고 밝혔다.2

반면 개인정보보호위원회는 최종 제재 처분에서 약 3,755만 명의 개인정보가 유출됐다고 결론냈다.1

이 차이가 중요하다.

조회 횟수와 고유 피해자 수는 다르다.
특정 페이지 기준 유출 건수와 최종 유출 인원도 다를 수 있다.
공격 도구의 기능과 실제 외부 전송 사실도 구분해야 한다.

이 구분을 가능하게 하는 기준이 바로 로그다.

수치와 출처를 읽는 기준

이 글의 핵심 수치는 2026년 6월 15일 기준으로 개인정보보호위원회 최종 제재 보도자료와 과학기술정보통신부 민관합동조사단 브리핑을 대조해 정리했다.1

이후 결정문 전문, 정정 보도자료, 법원 판단, 분쟁조정 결과가 공개되면 해당 자료를 기준으로 갱신하는 것이 바람직하다.

개인정보위는 2026년 6월 12일 쿠팡 개인정보 유출 관련 집단분쟁조정 절차 재개도 별도로 발표했다.4

다만 이 글은 피해 구제 절차보다 과징금 산정과 로그 기준 문제에 초점을 둔다.

이 글의 자료 기준

이 글은 2026년 6월 15일 작성 시점에 공개된 공식 자료를 기준으로 한다.

개인정보보호위원회의 2026년 6월 11일 보도자료는 쿠팡에 대한 과징금 6,246억 8,100만 원, 과태료 1,680만 원, 약 3,755만 명 개인정보 유출 결론을 제시했다.1

대한민국 정책브리핑에 공개된 2026년 2월 11일 민관합동조사단 발표는 내정보 수정 페이지 33,673,817건, 배송지 목록 페이지 148,056,502회 조회, 실제 외부 전송 여부 확인 불가 등의 내용을 담고 있다.2

또한 개인정보처리시스템 접속기록 보관·점검 의무는 2025년 10월 31일 시행된 「개인정보의 안전성 확보조치 기준」 제8조를 함께 참고했다.3

다만 개인정보 사고 관련 수치는 후속 정정, 결정문 공개, 소송 과정, 추가 조사 결과에 따라 표현이 달라질 수 있다.

따라서 이 글의 수치와 표현은 2026년 6월 15일 현재 공개 자료 기준의 해석이라는 점을 전제로 읽어야 한다.

문제는 과징금 규모가 아니라 기준이다

대규모 개인정보 유출 사고가 발생하면 사회적 분노는 커질 수밖에 없다.

피해자는 불안하다.
기업은 책임을 져야 한다.
제재기관은 법과 원칙에 따라 판단해야 한다.

여기까지는 이견이 없다.

문제는 그 다음이다.

과징금이 커졌다는 사실만으로 재발방지가 되는 것은 아니다.

기업이 앞으로 무엇을 남겨야 하는지, 무엇을 보존해야 하는지, 어떤 로그가 있으면 피해 규모를 소명할 수 있는지, 어떤 로그가 없으면 불리하게 평가되는지 분명해져야 한다.

그 기준이 없다면 현장은 보안을 강화하기보다 행정 리스크 회피에 집중할 수 있다.

신고 문구를 다듬고, 법무 대응을 준비하고, 대관 전략을 세우는 일에 더 많은 시간을 쓸 수 있다.

하지만 정작 사고를 입증하고 피해를 줄일 로그 체계는 그대로일 수 있다.

그것은 재발방지가 아니다.

기업이 원하는 것은 막연한 공포가 아니다.

기업이 실질적으로 움직이게 만드는 것은 예측 가능한 기준이다.

기업 책임과 기준 설명은 함께 보아야 한다

이번 사안에서 쿠팡의 책임은 분명히 따져야 한다.

민관합동조사단은 공격자가 위·변조한 전자 출입증을 사용해 정상 로그인 없이 쿠팡 서비스에 무단 접속했다고 발표했다.2

또한 서명키 관리 체계, 전자 출입증 검증 체계, 비정상 접속 탐지, 접속기록 저장·관리 기준에 문제가 있었다고 설명했다.2

이런 내용이 사실이라면 기업 책임은 가볍지 않다.

다만 기업 책임과 제재 기준 설명은 충돌하는 개념이 아니다.

오히려 함께 가야 한다.

제재권이 행사될 때 기준 설명이 함께 제공될수록 제재의 예측 가능성과 재발방지 효과도 커진다.

“로그 관리가 부실했다”는 판단이 내려졌다면, 그와 함께 “어떤 로그를 어떻게 남겨야 충분한가”에 대한 정책적 설명도 필요하다.

“피해 이용자 식별과 유출 규모 산정에 어려움이 있었다”는 지적도 마찬가지다. 어떤 로그가 있었다면 더 정확한 산정이 가능했는지 함께 제시될 때 현장의 개선 방향이 분명해진다.

제재 발표가 재발방지 안내서가 되려면 사실, 추정, 확인 불가가 가능한 한 분리되어 설명될 필요가 있다.

그래야 기업도 무엇을 준비해야 하는지 알 수 있다.

조회, 유출, 전송은 같은 말이 아니다

개인정보 사고에서 “조회”, “유출”, “전송”은 서로 연결될 수 있다.

그러나 사고 분석과 과징금 산정에서는 각각의 의미를 분리해서 보아야 한다.

구분	의미	로그로 확인해야 할 것
조회	시스템이 특정 요청에 개인정보를 반환한 상태	누가, 어떤 계정·토큰으로, 어떤 API를 호출했고, 어떤 응답이 반환됐는가
유출	권한 없는 주체에게 개인정보가 노출되거나 제공된 상태	요청이 정상 권한인지, 위·변조인지, 어떤 개인정보 항목이 노출됐는가
외부 전송	조회한 정보를 외부 인프라로 옮긴 상태	목적지 IP·도메인, 전송량, 프로세스, 네트워크 세션, 파일 생성·압축·업로드 흔적
공격 도구 존재	자동화 수집 또는 전송 도구가 존재한 상태	도구 실행 여부, 실행 시간, 명령행, 네트워크 연결, 생성 파일
확인 불가	로그 또는 증거 부족으로 사실 판단이 어려운 상태	어떤 로그가 없어 판단하지 못했는지, 어떤 범위까지 추정했는지

이 구분은 책임을 줄이기 위한 것이 아니다.

정확한 책임을 묻기 위한 것이다.

확인된 피해는 확인된 피해로 다루어야 한다.
기술적 추정은 기술적 추정으로 설명해야 한다.
확인할 수 없는 부분은 왜 확인할 수 없는지 함께 설명되어야 한다.

그래야 행정제재가 법적 기준이 되고, 기업의 재발방지 기준이 된다.

접속기록만으로는 부족하다

많은 기업은 “접속기록을 보관하고 있다”고 말한다.

하지만 접속기록이라는 말은 너무 넓다.

어떤 기업은 IP, 시간, URL, 상태 코드 정도만 남긴다.
어떤 기업은 사용자 ID, 세션, API 이름, 응답 시간까지 남긴다.
어떤 기업은 요청 본문과 응답 본문 일부를 마스킹·암호화해 남긴다.

세 경우는 모두 “로그를 남긴다”고 말할 수 있다.

하지만 사고가 나면 차이는 결정적이다.

남긴 로그	사고 조사에서 가능한 일	한계
IP, 시간, URL, 상태 코드	특정 URL에 접근했다는 사실 확인	어떤 개인정보가 반환됐는지 알기 어려움
사용자 ID, 세션, API명	누가 어떤 기능을 호출했는지 확인	응답 내용과 데이터 항목 확인이 제한적
요청 파라미터, 응답 크기, 레코드 수	대량 조회와 비정상 패턴 판단	실제 노출 항목 판단은 여전히 어려울 수 있음
요청 본문·응답 본문 또는 보호된 원본 로그	어떤 입력에 어떤 개인정보가 반환됐는지 판단	민감정보 보호, 암호화, 접근통제, 보존정책이 필요
웹·서버·계정·네트워크 상관 로그	공격 흐름과 외부 전송 가능성 판단	전사적 수집·분석 체계가 필요

로그를 보관하는 것과 사고를 설명할 수 있는 것은 다르다.

웹 접속기록을 남기는 것과 개인정보 유출 범위를 입증할 수 있는 것도 다르다.

로그 수준은 다음처럼 계층으로 보아야 한다.

수준	로그 유형	사고 시 설명 가능성
1	접속 메타데이터	누가 어느 URL에 접근했는지 확인
2	인증·권한 로그	정상 토큰과 위·변조 토큰, 키 버전 확인
3	데이터 접근 로그	조회 대상, 항목, 레코드 수 확인
4	보호된 요청·응답 로그	실제 반환된 개인정보 항목과 범위 확인
5	상관분석 타임라인	웹·서버·계정·네트워크 흐름 연결

수준이 높아질수록 저장과 보호의 부담은 커진다.

하지만 사고가 났을 때 원인과 범위를 설명할 수 있는 힘도 커진다.

핵심은 웹의 요청 본문과 응답 본문이다

개인정보 유출 사고에서 가장 중요한 기록 중 하나는 웹의 요청 본문과 응답 본문이다.

쉽게 말하면 사용자가 무엇을 입력했고, 시스템이 무엇을 보여줬는지에 대한 기록이다.

요청 본문에는 검색 조건, 조회 대상, 인증 정보, 파라미터, API 호출 내용이 담길 수 있다.

응답 본문에는 성명, 이메일, 전화번호, 주소, 주문 정보, 배송지 정보, 내부 식별자 등 실제로 화면이나 API로 반환된 데이터가 담길 수 있다.

사고가 발생했을 때 이 기록이 있어야 다음 질문에 답할 수 있다.

어떤 계정 또는 토큰으로 요청했는가
어떤 API 또는 페이지가 호출됐는가
요청은 정상 권한으로 이루어졌는가, 위·변조된 권한으로 이루어졌는가
응답에는 어떤 개인정보 항목이 포함됐는가
몇 명의 정보주체가 영향을 받았는가
중복 조회와 고유 피해자를 구분할 수 있는가
외부 전송 흔적과 연결되는가
사고 이후 피해자 통지 범위를 어떻게 산정할 수 있는가

물론 요청·응답 본문을 그대로 무제한 저장하자는 뜻은 아니다.

그 자체가 또 다른 개인정보 저장소가 될 수 있기 때문이다.

따라서 원본 로그를 남기려면 보호 기준도 함께 설계해야 한다.

마스킹, 암호화, 접근권한 통제, 위·변조 방지, 보존 기간, 파기 절차, 감사 기록이 필요하다.

핵심은 단순 저장이 아니다.

사고가 났을 때 설명 가능한 방식으로, 보호된 원본 로그를 남기는 것

이것이 중요하다.

모든 API에 같은 수준의 로그가 필요한 것은 아니다

요청·응답 본문 로그가 중요하다고 해서 모든 API의 모든 본문을 무제한 저장하자는 뜻은 아니다.

로그 기준은 위험도에 따라 달라져야 한다.

특히 개인정보 유출과 직접 연결되는 고위험 기능부터 우선 적용해야 한다.

우선순위	대상 API·화면	필요한 로그 수준
1	개인정보 조회·수정 화면	요청자, 대상 정보주체, 요청 파라미터, 반환 항목, 반환 레코드 수
2	배송지·주문·민감 상품 정보 화면	응답 항목, 제3자 정보 포함 여부, 반복 조회 패턴
3	인증·토큰·세션 API	토큰 발급·검증 결과, 서명키 ID, 키 버전, 실패 사유
4	다운로드·내보내기·대량 조회 API	사유, 승인자, 파일명, 레코드 수, 해시, 전송 경로
5	관리자·운영자 API	관리자 계정, 권한 사용, 변경 전후 값, 작업 근거
6	외부 연계·배치 API	호출 주체, 연계 대상, 전송량, 실패·재시도 기록

로그 방식도 하나만 고집할 필요는 없다.

위험도에 따라 원문 저장, 필드 목록 저장, 부분 마스킹 저장, 해시·토큰화, 사고 시 별도 보전 저장을 조합할 수 있다.

중요한 것은 “본문을 남길 것인가 말 것인가”라는 이분법이 아니다.

중요한 것은 사고가 났을 때 다음을 설명할 수 있는가다.

누가 접근했는가.
어떤 권한으로 접근했는가.
어떤 개인정보가 반환됐는가.
몇 명의 정보주체가 영향을 받았는가.
외부 전송 흔적은 있는가.

정책적으로 권고할 최소 로그 기준

감독기관이 기업 대신 보안을 운영할 수는 없다.

로그를 수집하고, 시스템을 설계하고, 사고 대응 체계를 갖추는 것은 기업의 책임이다.

다만 제재의 예측 가능성과 현장 개선 효과를 높이려면 최소 기준은 더 명확히 제시될 필요가 있다.

특히 개인정보 유출과 관련해서는 다음과 같은 기준이 정책 권고나 가이드라인 형태로 정리될 필요가 있다.

기준 영역	포함되어야 할 항목
웹 요청·응답	시각, IP, 세션, 사용자 ID, API, Method, 요청 파라미터, 응답 상태, 응답 크기, 반환 항목, 반환 레코드 수
인증·권한	토큰 발급·검증 결과, 서명키 ID, 키 버전, 키 발급·교체·폐기 이력, 관리자 권한 사용, 퇴사자 권한 회수
데이터 접근	조회 항목, 정보주체 수, 중복 조회 여부, 제3자 정보 포함 여부, 대량 조회 여부, 다운로드·내보내기 행위
외부 전송	프로세스 실행, 명령행, 파일 생성·압축, DNS, 외부 IP·도메인, 전송량, 클라우드 업로드 흔적
사고 보전	자동 삭제 중지, 관련 로그 별도 백업, 해시 생성, 접근권한 제한, 보관 체인 기록, 누락 구간 문서화

현행 개인정보 안전성 확보조치 기준은 개인정보처리시스템 접속기록 보관을 요구한다.3

그러나 대규모 개인정보 처리 시스템에서는 “법정 보관 기간을 채웠는가”만으로 충분하지 않을 수 있다.

사고 설명 가능성을 기준으로, 평상시 접속기록은 법정 의무 기간을 하한으로 삼고, 고위험 API 원본 로그는 별도 보호 저장하며, 사고 의심 시점에는 자동 삭제 정책을 즉시 중지하는 운영 기준을 권고할 수 있다.

로그 보존은 무조건 오래 저장하는 문제가 아니다.

사고를 설명할 만큼 충분해야 하고, 동시에 또 다른 개인정보 위험이 되지 않도록 보호되어야 한다.

과징금 정상참작 기준도 로그 중심으로 구체화할 필요가 있다

기업이 가장 알고 싶은 것은 추상적인 “보안 강화”가 아니다.

무엇을 하면 충분한 예방 노력으로 인정되는지, 무엇을 하면 사후 대응 노력으로 인정되는지, 무엇이 없으면 불리하게 평가되는지다.

이를 위해서는 정상참작 기준도 로그 중심으로 구체화될 필요가 있다.

구분	정상참작으로 볼 수 있는 요소	불리하게 볼 수 있는 요소
사전 예방	개인정보 접근 로그, 인증 로그, 원본 웹 로그, 이상행위 탐지 체계 운영	로그 항목 불명확, 대량 조회 탐지 부재, 키 관리 이력 부재
사고 인지	이상행위 탐지 후 즉시 조사 착수, 관련 계정·토큰 차단	고객 제보 이후에도 탐지 지연, 내부 보고 지연
증거 보전	로그 삭제 중지, 별도 백업, 해시 보존, 접근통제	자료보전 명령 이후에도 로그 삭제 또는 누락 발생
피해 산정	고유 피해자, 항목, 조회 횟수, 전송 여부를 근거로 산정	조회 수와 피해자 수 구분 불가, 외부 전송 여부 확인 불가
재발 방지	탐지·차단 정책 반영, 키 교체, 권한 회수, 모니터링 강화	보고서 작성에 그치고 운영 체계 개선 미흡

이 표가 곧바로 법적 기준이라는 뜻은 아니다.

다만 이런 수준의 정책 설명이 제공될 때 기업이 실질적인 보안 개선으로 움직이기 쉽다는 뜻이다.

ISMS-P와 연결되는 지점

이 문제는 ISMS-P 논의와도 연결된다.

ISMS-P는 필요하다.

정보보호와 개인정보보호 관리체계를 갖추게 만드는 중요한 제도다.

하지만 ISMS-P가 있다고 해서 실제 침해사고 대응 능력이 자동으로 생기는 것은 아니다.

로그를 보관하는가.
접근권한을 관리하는가.
보안정책이 있는가.
사고 대응 절차가 있는가.

이 질문들은 모두 중요하다.

그러나 실제 사고가 발생하면 질문은 더 구체적으로 바뀐다.

그 로그로 공격 흐름을 볼 수 있는가
누가 어떤 개인정보를 조회했는지 설명할 수 있는가
정상 토큰과 위·변조 토큰을 구분할 수 있는가
대량 조회를 실시간으로 탐지했는가
외부 전송 여부를 확인할 수 있는가
사고 원인과 피해 범위를 근거 로그로 설명할 수 있는가

즉,

로그를 보관하는 것과 로그로 침해를 설명하는 것은 다르다

ISMS-P가 정보보안의 출발점이라면, 사이버보안은 실제 공격 흐름을 보고 대응하는 운영 체계다.

이번 사안이 던지는 질문도 같다.

“접속기록을 보관했는가”가 아니다.

그 접속기록으로 개인정보 유출의 원인과 범위를 설명할 수 있는가

기업이 지금 점검해야 할 10가지

쿠팡 사안을 남의 일로만 볼 수는 없다.

개인정보를 다루는 모든 기업은 다음 질문부터 점검해야 한다.

점검 질문	확인할 내용
원본 웹 요청과 응답을 남기는가	URL, IP, 상태 코드만이 아니라 요청·응답 본문 또는 보호된 대체 기록을 확보하는가
어떤 개인정보 항목이 반환됐는가	성명, 이메일, 전화번호, 주소, 주문 정보, 배송지 정보 등 응답 항목을 판단할 수 있는가
조회 횟수와 고유 피해자를 구분하는가	중복 조회, 반복 조회, 제3자 정보 포함 여부를 분석할 수 있는가
정상 토큰과 위·변조 토큰을 구분하는가	토큰 발급 경로, 서명키 버전, 검증 결과를 추적하는가
서명키 사용 이력을 남기는가	키 발급, 저장 위치, 사용 주체, 교체, 폐기, 접근 이력을 감사할 수 있는가
대량 조회를 실시간 탐지하는가	평소 패턴과 다른 조회량, 비정상 API 호출, 다중 IP 접근을 탐지하는가
외부 전송 흔적을 확인하는가	서버 프로세스, 파일 생성, 압축, DNS, 네트워크 연결, 클라우드 업로드 흔적을 보는가
사고 직후 로그 삭제를 멈추는가	자동 삭제 정책을 중단하고 관련 로그를 별도 백업하는가
사고 타임라인을 만들 수 있는가	공격 시작, 대량 조회, 탐지, 차단, 노출 데이터를 시간축으로 설명할 수 있는가
로그가 과징금 소명 자료가 되는가	고객 통지, 조사 대응, 소송 대응, 재발방지 대책의 근거로 활용 가능한가

로그는 보안팀만 보는 자료가 아니다.

사고가 나면 고객 통지, 조사 대응, 과징금 산정, 소송 대응, 재발방지 대책의 근거가 된다.

따라서 로그는 기술 자료이면서 동시에 법적 소명 자료다.

PLURA-XDR이 의미를 갖는 지점

PLURA-XDR이 의미를 갖는 지점도 여기에 있다.

개인정보 유출 사고는 웹 요청 하나로 끝나지 않는다.

웹 요청에서 시작된 공격은 인증 우회, 서버 접근, 계정 사용, 데이터 조회, 파일 생성, 외부 통신으로 이어질 수 있다.

따라서 필요한 것은 개별 로그의 단순 보관이 아니다.

필요한 것은 공격 흐름을 하나의 타임라인으로 연결하는 체계다.

PLURA-XDR의 관점은 다음과 같다.

웹 요청과 응답 분석
인증·계정 행위 분석
서버 실행 행위 분석
PC 행위 분석
데이터 접근 행위 분석
외부 통신 흔적 분석
원본 로그 기반 증적 확보
웹·서버·PC·계정 로그 상관분석
실시간 탐지와 대응
사고 원인과 피해 범위 설명 지원

중요한 것은 AI가 모든 판단을 대신한다는 말이 아니다.

AI와 XDR은 사람이 놓치기 쉬운 로그의 연결 관계를 찾고, 위험도를 설명하고, 대응 우선순위를 제시해야 한다.

즉,

보안 로그는 저장되는 데이터가 아니라, 사고를 설명하는 증거가 되어야 한다

제재 발표가 재발방지 안내서가 되려면

제재 발표가 재발방지 안내서가 되려면 과징금 규모만으로는 부족하다.

다음 질문에 더 구체적으로 답할수록 현장의 개선 방향도 분명해진다.

제재 발표에서 다룬 내용	추가로 설명되면 좋은 내용
로그 관리가 부실했다	어떤 로그 항목이 부족했는가
피해 이용자 식별이 어려웠다	어떤 기준의 로그가 있었다면 식별 가능했는가
유출 규모 산정이 어려웠다	조회 횟수, 고유 피해자, 제3자 정보를 어떻게 구분해야 하는가
외부 전송 여부를 확인할 수 없었다	어떤 서버·네트워크 로그가 필요했는가
안전조치가 미흡했다	어떤 탐지·차단 체계가 필요했는가
과징금을 부과했다	로그 부재와 보존 노력은 산정에 어떻게 반영됐는가

기업은 두려움만으로 움직이지 않는다.

예측 가능한 기준이 있을 때 더 빠르게 움직인다.

정책적으로 제시되면 좋은 기준은 어렵지 않다.

웹의 요청 본문과 응답 본문을 어디까지 남겨야 하는가.
그 로그를 어떻게 보호하고 보존해야 하는가.
사고가 나면 무엇을 즉시 보전해야 하는가.
그 노력이 과징금 산정에서 어떻게 정상참작되는가.

이 설명이 함께 제공될수록 제재는 단순 처분을 넘어 재발방지 기준으로 기능할 수 있다.

맺음말

쿠팡 사안의 핵심은 과징금 액수만이 아니다.

핵심은 기준이다.

기업은 책임져야 한다.

동시에 제재 기준에 대한 충분한 설명도 함께 필요하다.

어디까지가 확인된 사실인지, 어디부터가 기술적 추정인지, 무엇은 로그가 없어 확인하지 못했는지, 그 차이가 과징금 산정에 어떻게 반영됐는지 가능한 한 투명하게 설명되어야 한다.

개인정보 사고에서 로그는 단순한 기술 기록이 아니다.

로그는 피해자를 식별하는 근거다.
유출 범위를 판단하는 기준이다.
기업의 예방 노력과 사후 대응 노력을 보여주는 증거다.
행정제재의 정당성을 뒷받침하는 자료다.

그래서 개인정보 과징금은 로그 위에 서야 한다.

그리고 그 로그 기준은 사고가 난 뒤 사후적으로만 논의되어서는 안 된다.

사고 전에 권고되고, 점검되고, 현장에서 적용될 수 있어야 한다.

기업이 필요로 하는 것은 두려움보다 명확한 기준이다.

행정제재는 법 위에 서야 한다.