자체 모니터링 트래픽으로 부풀려진 PV 집계 정확화
목차
지난주 통계 대시보드의 일일 PV 데이터에서 약 254개의 중복 집계를 발견하고 제거했다. 원인은 생각보다 흔한 패턴이었다 — 시스템 자체가 모니터링 목적으로 띄우는 uptime 체크 요청들이 사용자 PV로 잘못 섞여 들어간 거다.
문제의 발견
주간 리뷰에서 site-pv.py(우리의 기준 통계 수집 스크립트)와 stats-dashboard.py(대시보드 렌더용 통계 계산)의 수치가 지속적으로 어긋난다는 걸 발견했다. 차이가 하루에 250~260개 정도로 꽤 일관되었다. 처음엔 타임존 이슈나 배치 타이밍 문제를 의심했는데, 로그를 파고 들어보니 hedvion-uptime이라는 내부 모니터링 서비스의 모든 health-check 요청이 일반 사용자 접근으로 집계되고 있었다.
생각해보면 자명한 버그였다. 우리가 서비스 운영을 위해 매분 여러 지점에서 "내 서비스 잘 떠있나?" 확인하는 요청들은 실제 사용자 활동의 지표가 될 수 없다. 그런데 HTTP 로그 수집 단계에서 이를 구분하지 않았으니, 결과적으로 거짓 트래픽이 누적된 거다.
수정 내용과 선택
stats-dashboard.py에 간단한 필터를 추가했다:
# hedvion-uptime 같은 자체 모니터링 서비스의 요청 제외
is_monitoring = request_source in ['hedvion-uptime', 'internal-healthcheck']
if not is_monitoring:
pv_count += 1
동시에 site-pv.py와의 로직을 동기화했다. 두 스크립트가 다른 기준으로 데이터를 필터링하면 안 되니까다.
왜 이 우선순위였는가:
- 통계 신뢰도는 의사결정의 기반이다. 거짓 수치를 들고 매출 분석이나 트렌드 판단을 하면, 작은 오류가 쌓여 큰 기회비용을 만든다
- 254는 작은 수처럼 들리지만, 매일 누적되면 월 단위로 7000+의 허상이 된다
- 대시보드를 신뢰하는 팀원들(마케팅, 기획)을 위해서도 정확성이 중요했다
회고
이건 흔한 패턴이다. 시스템이 자신을 관찰하기 위해 발생시키는 트래픽과 실제 사용자 신호를 섞는 일은 대시보드/메트릭스 초기 구축 단계에서 자주 본다. 다른 팀도 비슷한 실수를 할 가능성이 높으니, 우리 통계 수집 가이드 문서에 "모니터링 트래픽 필터링 체크리스트"를 추가하기로 결정했다.
더 근본적으로는, site-pv.py와 stats-dashboard.py처럼 같은 데이터를 다루는 시스템들의 로직을 자동으로 검증하는 테스트도 고려 중이다. 두 스크립트의 결과 값이 일정 범위 내에서 일치하지 않으면 경고를 띄우는 식으로. 이렇게 하면 이런 류 불일치를 수작업 리뷰에 의존하지 않아도 된다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.