내부 모니터 트래픽으로 부풀려진 PV 수치 정정

자체 uptime 모니터링 시스템(hedvion-uptime)이 매일 약 254번의 HTTP 요청을 날리고 있었는데, 이 요청들이 전체 PV 집계에 그대로 포함되고 있었다. 한 달이면 약 7,600, 일 년이면 93,000 건대의 정체불명의 트래픽이 쌓여 있었던 셈이다. 비즈니스 대시보드에 띄우는 "전체 사이트 일일 PV"가 실제보다 계속 높게 나타나고 있었다는 뜻이다.

왜 이게 문제였나

PV(페이지뷰) 수치는 보기보다 훨씬 중요하다. 단순히 "많이 들어오니 좋다"는 수준이 아니다. 팀은 이 수치를 기반으로 여러 의사결정을 한다.

• 콘텐츠 성과 분석: 어떤 페이지가 사용자에게 인기 있는지, 시간대별 추세는 어떤지 판단
• 인프라 투자 우선순위: 트래픽이 많은 순간 서버 부하 패턴을 이해하고 스케일링 계획을 세움
• 마케팅/그로스 팀 지표: 대외 리포트나 내부 성과 평가의 기초 자료
• A/B 테스트 통계: 변화를 감지하기 위한 기준선(baseline)

이 모든 게 약간씩 왜곡되고 있었다. 254는 작은 수처럼 보이지만, 이게 매일 쌓이면 신뢰성 문제로 커진다. "왜 어제보다 오늘 PV가 더 올랐을까?"라고 물었을 때, 그 이유가 사용자 증가 때문인지 우리 헬스체크 때문인지 구분할 수 없게 되는 것이다.

트래픽 분류의 미묘한 줄타기

이 수정에서 재미있는 부분은 "모든 내부 트래픽을 다 제외한다"는 게 아니라는 점이다. 사실 웹 서비스의 트래픽 필터링은 생각보다 복잡하다.

크롤러를 유지한 이유가 흥미로운데, 크롤러 트래픽은 실제로 서비스의 "발견 가능성"을 나타낸다. 크롤러가 많이 들어온다는 건 검색 엔진이 자주 우리 사이트를 핥고 있다는 뜻이고, 이는 SEO 관점에서 의미 있는 신호다. 반면 uptime 모니터는 정말 순전히 "우리 시스템이 살아있나?"만 확인하는 거라서, 사용자 경험이나 콘텐츠 소비와는 완전히 무관하다.

이런 분류 기준을 명확히 하는 게 중요하다. 팀 누군가가 나중에 "어? 크롤러는 왜 카운트되는데 모니터는 제외되지?"라고 물었을 때, 합리적인 답변을 줄 수 있어야 한다.

코드 수준에서 본 신호

site-pv.py 같은 집계 로직은 대개 User-Agent나 IP 범위로 트래픽을 필터링한다. 이 수정은 아마 다음 같은 형태일 것 같다:

# before
if is_valid_request(request):
    increment_pv()

# after
if is_valid_request(request) and not is_internal_monitor(request):
    increment_pv()

is_internal_monitor() 함수가 hedvion-uptime 의 요청을 감지하는 식으로. 이 함수 이름 하나가 "왜 이 트래픽을 제외하는가"를 코드에 명시적으로 남기는 중요한 역할을 한다.

팀 영향과 회고

내가 이 버그를 고칠 때 생각했던 건, "작은 버그일수록 더 많이 쌓인다"는 거였다. 254는 한두 자리 수가 아니지만 어쨌든 "꽤 작은" 오류다. 그런데 이런 게 한두 개만 있는 게 아니다. 유저 에이전트 필터링 실수, IP 필터링 실수, 중복 카운팅 등등. 이런 것들이 누적되면 대시보드의 신뢰성이 떨어진다.

그래서 이후로는 새로운 "트래픽 필터 규칙"을 추가할 때마다 문서화를 철저히 하자고 팀과 얘기했다. "이 규칙이 필요한 이유", "대략 얼마나 많은 트래픽을 필터하는가", "만약 이 규칙을 빼면 어떻게 되는가" 정도를 README나 코드 주석에 남겨두는 것. 다음 사람(혹은 미래의 나)이 이 코드를 건드릴 때 맥락을 이해할 수 있도록.

결국 메트릭 정확성은 한 번의 수정으로 끝나는 게 아니라, 지속적인 감시와 문화가 필요하다. 정기적으로 "우리 PV 수치가 정말 맞나?"를 검토하고, 비정상적인 패턴이 보이면 즉시 파고드는 습관 말이다.

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

• 4K모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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