도메인 전수 정리, 설정부터 배포까지 한눈에 확인

도메인과 경로명을 이전 명칭에서 새 명칭으로 전체 통일하는 작업을 마쳤다. 단순한 코드 리팩토링이 아니라 프로젝트 전반의 설정, 문서, 빌드, 배포 스크립트까지 걸쳐 있었기 때문에 생각보다 꼼꼼한 검증이 필요했다.

도메인 마이그레이션이 생각보다 광범위

처음엔 단순하게 생각했다. 도메인 문자열을 찾아 바꾸고 끝이겠지, 싶었다. 하지만 실제론 그게 아니었다. 도메인이나 경로명은 단순히 소스 코드 속 몇 줄이 아니라, 프로젝트가 외부와 상호작용하는 여러 경계에 산재해 있다.

내가 변경한 파일들을 보면 그게 명확하다:

한 건의 도메인 변경 commit이 5개 파일을 건드린다는 것은, 단순 리팩토링이 아니라 전체 파이프라인의 일관성을 맞추는 작업이라는 뜻이다.

놓치기 쉬운 부분들

도메인 마이그레이션을 하면서 자주 발견되는 함정들:

• 환경 변수 예제 파일의 불일치: .env.example이 구 도메인을 가리키면, 신입이 온보딩할 때 자신의 .env 파일을 만들면서 실수하기 쉽다. "왜 이 도메인으로 설정했는데 페이지를 찾을 수 없지?" 같은 문제가 발생.

• 배포 스크립트의 숨겨진 참조: publish.sh는 단순 배포 명령어만 있는 게 아니라, 경로 검증, 리소스 복사, 도메인 기반의 조건부 로직 등이 들어있을 수 있다. 이런 부분을 놓치면 배포는 성공하지만 실제 서비스는 구 리소스를 여전히 가리킬 수 있다.

• 문서와 코드의 불일치: README는 가장 자주 발목을 잡는 파일이다. "이 주소로 설정하세요"라고 쓰여 있는데 실제 도메인이 다르면, 사용자는 문서를 신뢰하기 어렵다. 특히 팀이 커질수록 이런 작은 불일치가 누적된다.

• 빌드 스크립트의 조건부 로직: 빌드 시점에 특정 도메인을 확인하거나, 다양한 환경(dev, staging, prod)에 따라 다른 도메인을 사용한다면, 각 경로를 일일이 검증해야 한다.

체계적으로 접근하는 법

이런 전수 작업을 안전하게 하려면:

# 1. 구 도메인명이 정말 모두 제거되었는지 확인
grep -r "psy" .

# 2. 새 도메인명이 일관되게 들어갔는지 확인  
grep -r "curiodot" . | wc -l

# 3. 스크립트 파일들이 실행 가능한 상태인지 확인
bash -n publish.sh
node build-ads/build-ads.js --dry-run  (가능하면)

단순한 commit이지만, 이 작은 변경이 여러 경계를 넘나든다. 팀원이 이 코드를 클론 받아서 문서를 따라 개발하고, 빌드하고, 배포할 때까지 일관되게 같은 도메인을 가리킬 수 있도록 보장하는 것. 그게 "전수 정리"의 진짜 의미다.

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

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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