사고가 났을 때 가장 먼저 찾는 것이 로그인데, 그때서야 '그 로그는 안 남기고 있었다' 거나 '2주 전 건 이미 지워졌다' 는 것을 알게 되는 경우가 많습니다. 로그 관리는 도구보다 무엇을·얼마나·어디에·누가 보나 네 가지를 정하는 일입니다.
1. 무엇을 남기나
모든 것을 남기면 아무것도 못 봅니다. 위 다섯 묶음이 기준이고, 특히 개인정보·중요 데이터에 대한 접근 기록(누가·언제·어떤 데이터를·어떻게)은 법적 요구이기도 합니다. 각 기록에는 시각·행위자(계정)·대상·결과·출발지(IP)가 있어야 나중에 사람 이야기가 됩니다.
2. 얼마나 남기나
보안·감사 로그는 1년 이상을 기본으로 보는 경우가 많고, 법령이나 인증 기준에 따라 더 길게 요구되기도 합니다(개인정보 접근 기록 등은 해당 고시를 확인). 애플리케이션 디버그 로그는 짧게(수 주)로 나눠 비용을 줄입니다. 중요한 것은 기간이 '정해져 있고 문서에 있다' 는 것입니다.
3. 어디에 모으나 — 서버 밖으로
서버 로컬 파일은 서버가 뚫리면 지워지고, 로테이션으로 사라지고, 장애 때 접근이 안 됩니다. 중앙 수집(syslog 서버, 로그 수집기, 클라우드 로그 서비스)으로 모으고, 원본 서버에서는 쓰기 전용으로 보내게 합니다. 관리자라도 수집된 로그를 수정·삭제할 수 없거나, 했을 때 흔적이 남아야 무결성이 말이 됩니다.
4. 시간을 맞춘다
로그 분석의 첫 단계는 여러 시스템의 기록을 시간순으로 늘어놓는 것입니다. NTP 가 안 맞으면 이 단계에서 무너집니다. 모든 서버·장비가 같은 시간 소스를 보게 하고, 로그의 시간대 표기를 통일합니다.
5. 민감 정보는 로그에 넣지 않는다
비밀번호, 주민번호, 카드번호, 인증 토큰이 로그에 그대로 찍히는 일이 흔합니다. 로그 자체가 유출 지점이 됩니다. 애플리케이션 단에서 마스킹하고, 수집 단계에서 패턴 기반으로 한 번 더 거릅니다.
6. 누가 언제 보나
로그는 쌓는 것이 아니라 보는 것입니다. 관리자 로그인 실패 반복, 새벽의 대량 데이터 조회, 권한 변경 같은 핵심 이벤트는 즉시 알림으로, 나머지는 주 1회 정해진 사람이 정해진 보기(대시보드·쿼리)로 검토하고 한 줄이라도 기록을 남깁니다. 이 '검토 기록' 이 운영 증적이 됩니다.
로그 관리의 성패는 수집량이 아니라 사고 당일 '그 기록이 있고, 찾을 수 있고, 믿을 수 있는가' 에 달려 있습니다.
댓글