보안 사고가 터지면 지금까지의 첫 질문은 “막았느냐”였다. 최근에는 질문이 하나 더 붙는다. “그때 무슨 일이 있었는지 증명할 수 있느냐.” 조사기관도, 고객사도, 보험사도 결국 같은 것을 요구한다. 기록이다.
차단은 확률의 문제라 100%가 없다. 반면 기록은 준비의 문제라 100%가 가능하다. 대응 수준의 차이는 갈수록 여기서 갈린다.
무엇이 달라지고 있나
2026년 3월 국무회의를 통과한 정보통신망법 개정안은 침해사고 대응 체계를 크게 손봤다. 실무적으로 체감되는 변화는 세 가지다.
1) 조사 착수 문턱이 낮아졌다
기존에는 사고가 확인된 뒤 신고·조사로 이어지는 흐름이 일반적이었다. 개정안은 침해사고조사심의위원회를 신설해 해킹이 의심되는 정황만으로도 직권조사가 가능하도록 했다. “아직 피해가 확인되지 않았다”는 말이 시간을 벌어 주지 않는다는 뜻이다.
2) 자료 보전이 별도 의무가 됐다
조사에 대비해 내부 시스템 로그의 보존 기간과 절차를 정비하도록 하고, 자료 보전 의무를 어기면 형사처벌까지 규정하고 있다. 사고 직후 흔히 벌어지는 “일단 서버부터 재설치하고 보자”가 그 자체로 위험한 선택이 된다.
3) 반복 사고에 대한 제재가 무거워졌다
같은 유형의 사고가 되풀이될 경우 매출액에 연동한 과징금과 이행강제금이 논의되고 있다. 한 번의 사고보다 “고쳤다고 해 놓고 또 뚫린 것”을 더 무겁게 본다는 신호다.
그래서 무엇을, 얼마나 남겨야 하나
로그를 다 모으라는 조언은 현실에서 지켜지지 않는다. 우선순위를 정해 두는 편이 낫다.
- 인증 로그 — 관리자 로그인 성공·실패, 접속 IP, 시각. 침해 조사의 8할은 여기서 시작한다.
- 권한 변경 이력 — 계정 생성·삭제, 권한 상향, 비밀번호 초기화.
- 웹 접근 로그 — 최소 3개월, 가능하면 6개월. 용량이 부담이면 압축 보관으로도 충분하다.
- 파일 변경·배포 이력 — 언제 어떤 파일이 바뀌었는지. 웹셸 여부를 가르는 결정적 증거다.
- DB 스키마·대량 조회 기록 — 유출 규모를 산정할 때 이것이 없으면 “모른다”로 끝난다.
핵심은 보존 기간보다 ‘변조 불가’다. 같은 서버에만 쌓아 둔 로그는 침입자가 지우면 그만이다. 하루 한 번이라도 외부 저장소로 복사해 두면 증거로서의 가치가 완전히 달라진다.
인원이 적은 회사가 이번 주에 할 수 있는 일
- 로그 위치 목록화 — 웹서버·DB·방화벽·업무 시스템의 로그 경로를 문서 한 장에 적는다. 사고 당일 이 문서 유무가 초기 대응 속도를 가른다.
- 보존 기간 통일 — 시스템마다 제각각인 순환 삭제 주기를 최소 90일로 맞춘다.
- 외부 백업 1개 — 로그만 따로 다른 저장소로 하루 1회 복제한다.
- 연락 체계 정리 — 사고 인지 시 누가 신고하고 누가 서비스 중단을 결정하는지 이름으로 적어 둔다.
- 운영 위탁 범위 확인 — 외주로 만든 시스템이라면 로그 설정이 계약에 포함되어 있는지 확인한다. 유지보수 계약에 “로그 보존·제출 협조” 문구 한 줄을 넣는 것이 나중에 큰 차이를 만든다.
여러 시스템이 얽혀 있어 로그 기준을 통일하기 어렵다면 SI 구축 단계에서 로그 정책을 표준으로 박아 두는 편이 결국 싸게 먹힌다. 사내 데이터가 회계·인사까지 흩어져 있는 회사라면 ERP 구축 단계에서부터 감사 로그를 요구 사항에 넣어야 하고, 이미 운영 중인 서비스라면 앱 유지보수 범위에 로그 점검을 넣는 것으로 시작할 수 있다.
자주 하는 오해 세 가지
- “우리는 작아서 대상이 아니다” — 공격은 규모가 아니라 취약점을 보고 들어온다. 자동화된 스캐너에는 회사 크기가 보이지 않는다.
- “클라우드라 알아서 남는다” — 인프라 로그는 남지만 애플리케이션 수준의 행위 로그는 직접 켜지 않으면 남지 않는다.
- “복구가 먼저다” — 이미지를 뜨지 않고 재설치하면 원인 규명이 불가능해진다. 최소한 디스크 스냅샷 한 장은 남기고 복구에 들어가야 한다.
정리하면 이렇다. 방어는 계속 실패할 수 있다는 전제에서 출발해야 하고, 그 전제 위에서 조직이 통제할 수 있는 유일한 변수는 기록의 품질이다. 사고가 났을 때 “무슨 일이 있었는지 정확히 말할 수 있는 회사”가 되는 것, 그것이 2026년의 대응 기준이다.
