로그 보관 기간 설정 기준을 정하지 않으면 저장소가 무한정 쌓이거나 필요한 기록이 사라진다. 접속 기록 관리부터 시작해 인프라 전체 로그 정책으로 확장하는 절차를 먼저 수립해야 비용 낭비와 규제 위험을 동시에 피할 수 있다.
빠른 판단 포인트
- 현재 로그를 모두 보관하고 있거나 기간을 정하지 않았다면 즉시 정책 수립 시작 신호
- 접속 기록은 보안 감시, 감사, 트러블슈팅 목적별로 보관 기간을 달리 설정해야 함
- 서비스 종류, 사용자 규모, 규제 요건, 인프라 비용을 모두 고려해 기준을 정해야 실제 운영 가능
체크리스트
- 접속 기록, API 호출 로그, 시스템 이벤트 로그를 목적별로 분류했는가
- 각 로그 유형별로 법적 요구 사항이나 규제 기준을 확인했는가
- 현재 저장 중인 로그의 용량과 월별 증가율을 파악했는가
- 보관 기간 종료 후 로그 삭제 또는 아카이빙 절차를 정했는가
- 감사, 보안 대응, 성능 분석 등 각 팀이 필요로 하는 보관 기간을 수집했는가
핵심포인트
원인과 문제 상황: 로그 보관 기간 기준이 없으면 담당자마다 다르게 운영하거나, 필요한 기록이 사라지거나, 저장 공간을 낭비한다. 특히 접속 기록은 보안 사건 추적, 규제 대응, 성능 분석에 모두 사용되므로 목적에 따라 서로 다른 기간이 필요하다.
자주 놓치는 포인트: 한 번 정한 기간으로 모든 로그를 관리하려는 시도. 실제로는 단기 모니터링용 로그, 중기 감시용 로그, 장기 감사용 로그를 분리해서 관리해야 효율적이다. 또한 접속 기록만 해도 정상 접근, 실패 기록, 관리자 작업이 각각 다른 보관 기간을 필요로 한다.
먼저 볼 승인 기준: 기간 결정 전에 보안팀, 감시팀, 개발팀이 최소 필요 기간을 제시하도록 수집한다. 그 다음 저장 비용, 검색 속도, 규제 요구사항을 비교해 최종 기간을 정한다. 이때 협상 지점은 ‘기간’이 아니라 ‘로그 유형별 접근 권한’이다.
대응 절차
- 상황 확인: 현재 보관 중인 로그 유형을 모두 나열하고, 각각 시작일을 확인한다. 접속 기록, 시스템 로그, API 로그, 에러 로그 등을 분류한다.
- 영향 범위 파악: 현재 저장소 용량과 월별 증가율을 계산한다. 보관 기간이 1년이라면 연간 증가 용량이 얼마인지 파악하고, 향후 5년 예상 비용을 산출한다.
- 우선 조치: 각 팀에서 필요로 하는 최소 보관 기간을 수집한다. 보안팀이 원하는 기간, 감사팀이 원하는 기간, 운영팀이 필요로 하는 기간을 분리해 기록한다.
- 내부 확인: 접속 기록 중 가장 오래된 데이터가 실제로 사용되는지 샘플링으로 확인한다. 최근 3개월 데이터 사용률과 6개월 이상된 데이터 사용률을 비교한다.
- 후속 대응: 보관 기간 정책을 문서화하고, 자동 삭제 또는 아카이빙 규칙을 설정한다. 분기마다 실제 사용 패턴을 점검해 기간 조정 필요성을 평가한다.
공식 정보 확인 안내
서비스 종류와 규모에 따라 로그 보관 기간이 달라질 수 있다. 규제 요구사항이 있는 경우 해당 기관의 공식 지침을 먼저 확인한 뒤 내부 기준을 수립하는 것이 필요하다.
자주 묻는 질문 FAQ
Q1. 접속 기록은 최소 몇 개월 보관해야 하는가?
기간은 서비스 특성과 보안 요구도에 따라 다르다. 일반적인 운영 환경에서는 최소 3~6개월을 기준으로 두고, 접속 실패나 비정상 접근 기록은 더 오래 보관하는 팀이 많다. 자신의 서비스가 규제 대상인 경우 해당 요구사항을 우선 확인한다.
Q2. 오래된 로그를 삭제하지 않고 아카이빙하면 보관 기간 기준이 달라지는가?
삭제와 아카이빙은 다르게 계획해야 한다. 아카이빙된 로그는 검색 속도가 느리고 접근이 제한될 수 있으므로, 실제 운영 로그의 보관 기간과 아카이브 기간을 따로 설정한다. 예를 들어 접근 기록은 3개월 온라인 보관, 그 이후 12개월 아카이브 보관 같은 식으로 구분할 수 있다.
Q3. 팀마다 필요한 보관 기간이 다를 때 어떻게 조정하는가?
통합 기준을 정하는 것이 기본이지만, 로그 유형별로 차등 적용하는 것이 실무에서 더 효율적이다. 보안팀이 필요로 하는 접속 실패 기록 기간과 개발팀이 필요로 하는 성능 로그 기간을 별도로 관리하면서, 공통으로 필요한 감사 로그는 더 오래 보관하는 방식을 검토한다.
Q4. 로그 보관 기간을 정한 후 변경해야 할 상황이 생기면?
처음 정한 기간이 운영 경험에 맞지 않을 수 있다. 이 경우 분기별 검토 일정을 미리 정해두고, 실제 사용 데이터를 바탕으로 단계적으로 조정한다. 특히 새로운 규제 요구사항이나 보안 사건이 발생하면 영향을 받는 로그 기간을 즉시 재평가한다.
이 글은 일반적인 정보 제공과 참고 목적으로 작성되었으며, 법률 자문·보안 컨설팅·컴플라이언스 판단을 대체하지 않습니다. 소개하는 설정과 절차는 소프트웨어 버전이나 조직 환경에 따라 다르게 동작할 수 있으며, 어떤 보안 조치도 완전한 안전을 보장하지는 않습니다. 실제 적용 전에는 반드시 소속 조직의 정책과 담당 부서(보안·IT·법무)의 확인을 거치고, 중요한 시스템에는 백업과 사전 테스트 후 적용하시기 바랍니다. 규제 해석과 합법·불법 여부는 사안과 시점마다 달라질 수 있으므로 공식 규정과 전문가 상담으로 확인이 필요합니다. 본 사이트는 내용의 정확성과 최신성을 보장하지 않으며, 이 글의 내용을 적용하여 발생하는 어떠한 결과에 대해서도 책임을 지지 않습니다.