로그 rotate 후 새 파일이 대시보드 통계에서 빠지던 버그 수정

지난주 주간 리포트를 확인하다가 수치가 이상한 걸 발견했다. 대시보드에 표시되는 통계와 실제 로그를 수동으로 세어본 결과가 맞지 않는 거다. 특히 월간 대시보드가 더 심했다. 이유는 로그 rotate 후 새로 생성된 파일들이 집계 스크립트에서 빠지고 있었기 때문이었다.

왜 이런 일이 발생했을까

로그 rotate는 보통 자동화된 작업이다. 일정 크기 이상이 되거나 매일 정해진 시간에 현재 로그 파일을 압축하고 새로운 파일을 만든다. 여기까진 문제없다. 문제는 대시보드 집계 로직에 있었다.

특히 주간/월간 대시보드처럼 장시간 데이터를 수집해야 하는 경우, rotate 타이밍과 집계 스크립트 실행 타이밍이 겹칠 가능성이 높다. A는 어제까지의 로그를 집계하고, rotate가 일어나서 새 파일이 생기고, B는 그 이후부터 새 파일의 데이터만 보게 되는 식이다. 결국 그 사이에 생긴 파일들이 갭이 되는 것.

수정 작업: stats-dashboard.py 개선

scripts/stats-dashboard.py 에서 주기적으로 파일 목록을 다시 읽도록 변경했다. 특히 시간 범위 기반 집계 시 마다 디렉토리를 스캔하고, rotate 후 새로 생긴 파일도 포함하도록 로직을 개선했다.

핵심은 이거다:
- 파일 목록을 함수 진입 때 한 번만 읽지 않기
- 날짜/시간 범위별로 필요한 파일을 동적으로 찾기
- 이미 집계한 파일인지 추적해서 중복 계산 방지

# 개선 전: 전체 파일을 처음 한 번에 받아서 처리
files = os.listdir(log_dir)
for period in periods:
    stats = aggregate_from_files(files, period)

# 개선 후: 각 기간별로 필요한 파일을 다시 탐색
for period in periods:
    files = get_files_for_period(log_dir, period)  # 동적 조회
    stats = aggregate_from_files(files, period)

이렇게 하면 주간/월간 각각 필요한 시간대의 파일을 제대로 찾을 수 있다.

회고: 왜 이런 버그가 운영 중에 발견되었나

솔직히 이 부분은 팀 리딩 차원에서 한 번 생각해볼 필요가 있다.

첫째, 대시보드 데이터의 정합성 테스트가 약했다. 집계 로직을 바꾸거나 주기를 연장할 때는 rotate 시나리오까지 포함해서 테스트해야 한다. 예를 들어 "로그 파일이 rotate 되는 와중에 대시보드 스크립트가 실행되면?" 이런 엣지 케이스를 명시적으로 다뤄야 한다.

둘째, 모니터링이나 검증 로직이 없었다. 대시보드에 보여주는 통계가 실제와 일치하는지 주기적으로 검증하는 헬스 체크가 있었다면 훨씬 빨리 잡을 수 있었다. 이른 탐지(early detection)는 버그의 영향을 최소화한다.

셋째, 코드 리뷰 시점의 질문. 애초에 이 스크립트를 작성할 때나 수정할 때 "rotate 시나리오를 고려했나?"라는 질문이 코드 리뷰에서 나왔어야 한다. 팀 문화로서 "이 데이터 수집 로직이 시스템 변화(rotate, 재시작 등)에 얼마나 강한가?"를 자동으로 묻는 습관이 필요하다.

이제부터는 비슷한 데이터 집계 스크립트를 짤 때마다:
- 파일 시스템 변화(create, rotate, delete)를 명시적으로 고려
- 수집 범위를 명확히 문서화
- 헬스 체크나 데이터 정합성 검증 로직 포함

이 세 가지는 필수 항목으로 체크리스트에 넣기로 했다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 책상조명 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.