분석 데이터 누락·중복 제거로 정확한 모니터링 복구

PV(페이지뷰) 분석 추적 시스템에서 누락되거나 중복 집계되던 사이트들을 정리했다. 전체 커버리지를 완성하면서 동시에 부정확한 로깅으로 인한 중복 제거까지 함께 처리한 작업이다.

왜 이런 누락과 중복이 발생하는가

보통 사이트별 PV 추적 시스템은 점진적으로 성장한다. 처음엔 핵심 서비스 몇 개만 추적하다가, 신규 서비스가 생기거나 통합 대상이 늘어나면서 차례대차례 추가되기 마련이다. 하지만 그 과정에서 다음 같은 문제가 쉽게 발생한다.

누락 시나리오:
- 신규 사이트 출범 후 제때 PV 추적 시스템에 등록 안 됨
- 여러 팀이 병렬로 관련 코드를 작성했을 때 설정 싱크 누락
- 문서와 코드 사이의 간격 (리스트는 있는데 실제 추적 로직엔 빠짐)

중복 시나리오:
- 같은 사이트를 다른 이름이나 경로로 중복 등록
- 레거시 이름과 신규 이름이 함께 존재
- 서로 다른 로깅 경로가 같은 사이트를 중복 계산

이번엔 bible이라는 사이트가 완전히 누락돼 있었고, formpack 같은 항목은 중복으로 집계되고 있었다. 데이터 기반 의사결정을 하는 팀 입장에서 이런 불일치는 심각한 신호다. 분석 대시보드가 실제 트래픽을 제대로 반영하지 못하면 어떤 통계도 신뢰할 수 없기 때문이다.

세 가지 수정 사항

특히 daily-bible과 pdf2api는 로깅 방식이 특수하다는 점이 흥미롭다. 이 두 서비스는 일반적인 웹 PV 로그와는 다른 구조를 가지거나, 발생 빈도/시간대가 다를 수 있다. 그래서 별도의 추적 로직으로 격리하는 게 정확도 개선에 핵심이었다.

이런 버그를 반복하지 않으려면

이런 류의 누락·중복 버그는 한 번 발생하면 시간이 지날수록 찾기 어려워진다. 누적된 분석 데이터를 신뢰할 수 없게 되기 때문이다. 팀 차원에서는 몇 가지 패턴을 도입하면 좋다.

1단계: 설정의 중앙화
추적할 사이트 목록을 YAML이나 JSON으로 한곳에 정의하고, 코드는 이를 참조하게 한다. 하드코딩된 리스트 여러 군데 산재 금지.

# 한 곳에서 정의
tracked_sites:
  - name: bible
    log_path: /var/log/bible
    parser: default
  - name: daily-bible
    log_path: /var/log/daily-bible
    parser: specialized  # 특수 로직
  - name: pdf2api
    log_path: /var/log/pdf2api
    parser: specialized

2단계: 정기적 검증
실제 데이터와 설정 사이의 차이를 주기적으로 감시한다. 예를 들어 주 1회 자동화된 스크립트가 모든 사이트의 로그 파일을 스캔해서, 설정에 있는 모든 사이트의 최신 데이터 포인트가 도착했는지 확인하는 식이다.

3단계: 코드 리뷰 체크리스트
신규 서비스 추가나 추적 로직 변경 시 다음을 확인:
- 이미 등록된 서비스와 이름/경로 중복 아닌가?
- 전용 로깅이 필요한가? 아니면 기본 파서로 충분한가?
- 문서와 코드가 일치하는가?

남은 생각

이번 작업을 하면서 느낀 점은 "작은 누락과 중복은 자동으로 드러나지 않는다"는 것. PV 수가 늘어나거든 "아, 예상보다 많네"라고 지나칠 수 있다. 반대로 줄어드는 경우엔 "서비스 인기가 떨어진 거겠지"라고 착각하기 쉽다. 데이터 기반의 판단을 하는 조직일수록 이런 "조용한 오류"의 위험을 간과하면 안 된다.

같은 맥락에서 다음에 레거시 코드를 정리하거나 통합할 땐 먼저 "현재 추적 중인 항목이 정말 맞나"를 한번 더 검증하는 단계를 넣어야겠다는 생각도 든다.

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

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

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