레거시 도메인 참조 제거로 통계 정확성 복구

site-pv.py 에서 비활성화된 도메인의 매핑을 정정했다. 서비스 이관 과정에서 구 도메인 참조가 남아 있던 것을 발견하고 현재 라이브하는 도메인으로 수정한 작업이다.

도메인 매핑이 왜 운영 부채가 되는가

페이지뷰 추적 시스템은 여러 도메인·서비스를 일관된 ID로 통합하기 위해 도메인-ID 매핑 테이블을 관리한다. 기술적으로는 간단해 보이지만, 서비스 라이프사이클 동안 도메인은 자주 변한다.

• 브랜드 리뉴얼 후 도메인 변경
• 테스트/스테이징 서버 → 프로덕션 마이그레이션
• 리젼별 서비스 분리 (예: old.service.com → service-asia.com)
• 서드파티 인수 후 도메인 통합

이 과정에서 구 도메인을 빨리 제거하지 않으면, 트래킹 쿼리는 여전히 그 도메인을 찾으려 시도하고, 분석 로직이 헷갈리거나 누락된다.

이번 수정이 중요했던 이유

무엇이 문제였나:

# site-pv.py 의 매핑 테이블 (이전)
domain_mapping = {
    'werebridge.service.com': 'service_id_123',    # ← 더 이상 운영 중이 아님
    'new-service.live.com': 'service_id_456',
    ...
}

죽은 도메인 werebridge.service.com 이 여전히 매핑 테이블에 있으면:

1. 트래킹 누락: 해당 도메인으로 들어오는 요청을 처리하지 않거나, 잘못된 서비스 ID로 기록
2. 데이터 오염: 정산·분석 시 도메인 기준 필터링 로직이 복잡해지고 버그 발생 가능
3. 운영 혼란: 신입이나 다른 팀이 코드를 볼 때 "이 도메인은 왜 있지?" 라는 의문 발생
4. 마이그레이션 불완전: 도메인 이관은 끝났지만 추적 시스템은 동기화되지 않음

이런 상황은 당장 명백한 에러는 아니지만, 시간이 지날수록 데이터 신뢰도를 갉아먹는다.

수정 내용과 일반론

# site-pv.py (수정 후)
domain_mapping = {
    'new-service.live.com': 'service_id_456',    # ✓ 현재 라이브 도메인만 유지
    'backup-service.live.com': 'service_id_789',
}

간단해 보이지만 중요한 원칙들:

회고: 이런 작업을 얼마나 자주 해야 할까

팀 리딩 입장에서 생각해보니, 이런 "작은 정정"들이 누적되지 않으려면:

• 마이그레이션 체크리스트: 도메인 변경 시 "추적 시스템 동기화" 항목을 필수로 포함
• 정기 감사: 분기 1회 정도 사용 중이 아닌 항목들을 정리하기
• 코드 리뷰 습관: 매핑 테이블 변경 PR이 들어오면, "정말 모두 필요한가" 한 번씩 물어보기

작은 수정처럼 보이지만, 이런 작업의 근본은 "현재 상태를 정확히 유지하는 것"이고, 그게 결과적으로 팀의 운영 부채를 줄인다.

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

• 모니터암 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식 키보드 쿠팡에서 보기 →

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