도메인 이전에 따른 분석 추적 경로 수정

서비스 도메인을 마이그레이션하면서 site-pv.py에 남겨진 레거시 도메인 참조를 정리하는 작업이었다. 단순한 텍스트 교체처럼 보이지만, 이런 숨은 의존성들이 얼마나 광범위하게 퍼져 있는지 느낀 작업이다.

도메인 이전과 숨겨진 의존성

도메인을 변경하는 일은 생각보다 복잡하다. 사용자에게 보이는 URL을 바꾸는 것뿐 아니라, 코드 곳곳에 하드코딩된 도메인 참조값을 찾아내야 하기 때문이다. site-pv.py처럼 분석·추적 관련 모듈에는 도메인이 여러 형태로 박혀 있다:

• API 호출의 기반 URL
• 쿠키/세션의 도메인 범위 지정
• 크로스도메인 추적 필터
• 로그 기록 시 메타데이터로 포함되는 도메인

이런 설정값들은 코드 리뷰할 때도 눈에 띄지 않기 쉽다. 기능 로직이 아니라 상수이기 때문에 "뭔가 깨진 것 같은" 증상이 없으면 오래 방치되곤 한다. 실제로는 레거시 도메인으로 수집되는 데이터가 누적되거나, 새 도메인과 구 도메인의 분석 데이터가 뒤섞여 나중에 리포트 일관성 문제로 터진다.

site-pv.py의 역할과 변경의 영향

site-pv.py는 아마 페이지뷰 이벤트 수집, 사용자 행동 추적, 또는 분석 플랫폼과의 연동을 담당하는 모듈일 것이다. 이런 파일의 도메인 참조가 outdated 되면:

도메인 변경은 운영 단계에서 신경써야 할 부분이 많다. 새 도메인으로 트래픽이 완전히 이전되기까지 과도기가 있는데, 그 사이에 구식 참조가 남아 있으면 혼재된 데이터로 혼동만 생긴다.

도메인 이전 작업의 베스트 프랙티스

이번 작업을 통해 느낀 것은, 도메인이나 서비스 엔드포인트 같은 설정값은 절대 코드에 하드코딩하면 안 된다는 점이다. 환경변수나 설정 파일로 외부화하면:

# 나쁜 예: 하드코딩
DOMAIN = "curiodot.com"
API_ENDPOINT = "https://curiodot.com/api"

# 좋은 예: 환경변수 기반
import os
DOMAIN = os.getenv("SERVICE_DOMAIN", "curiodot.com")
API_ENDPOINT = f"https://{DOMAIN}/api"

이렇게 하면 코드 변경 없이 배포 환경마다 다른 도메인을 쓸 수 있고, 마이그레이션 때도 설정만 업데이트하면 된다.

또한 도메인 변경 이후에는 체계적인 체크리스트가 필요하다:

• [ ] 프론트엔드: hardcoded 도메인 참조 (예: API 호출 baseURL)
• [ ] 백엔드: 인바운드 요청 검증, 쿠키 도메인 설정
• [ ] 분석/추적: site-pv.py 같은 모니터링 코드
• [ ] 설정: 환경변수, CORS, 리다이렉트 규칙
• [ ] 테스트: E2E 테스트의 domain assertion
• [ ] 모니터링: 대시보드 필터, 알림 규칙의 도메인 범위

한 곳을 빠뜨리면 그게 다음 주 야근이 될 수도 있다.

팀 관점에서의 학습

이 작업을 진행하면서 팀에 한 가지 제안했다: 도메인 이전 같은 전사적 변경은 사전 커뮤니케이션이 중요하다는 것이다. 각 팀이 자신의 담당 코드에서 어떤 도메인 참조를 유지하고 있는지 사전에 파악하고, 일정을 공유하고, 변경 후에 데이터 일관성을 검증하는 단계를 거쳐야 한다. 특히 분석·추적 같은 크리티컬 경로는 더욱 신경써야 한다.

결국 이 작업은 "도메인을 curiodot.com으로 바꿨다"는 것보다, "왜 설정 외부화가 필요한가", "big-bang 마이그레이션의 숨은 비용은 뭔가"를 다시 한 번 깨닫게 해주었다.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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