도메인 통합으로 배포와 SEO 설정 일원화

개인 블로그가 운영하는 독립 도메인을 회사 서브도메인으로 이전하는 작업을 완료했다. 한 개발자의 개인 프로젝트였던 블로그와 프로필이 조직의 일부로 흡수되면서, 이전에는 분산되어 있던 도메인과 배포 인프라를 정리한 것이다.

왜 도메인 이전이 필요했나

팀 내에서 여러 서비스가 증가하면서 도메인 관리 전략이 중요해졌다. 개인 소유의 werebridge.com으로 운영되던 블로그는 기술적으로도, 조직 관점에서도 몇 가지 문제가 있었다. 첫째, 배포 인프라와 DNS 관리가 회사 통제 밖에 있어서 자동화하기 어려웠다. 둘째, 블로그가 팀 문화와 내용을 담는 중요한 채널이 되면서 접근성과 신뢰도를 높일 필요가 있었다. 셋째, 팀 내 다른 서비스들과 일관된 도메인 구조를 만들어 관리 부담을 줄이는 게 목표였다.

이런 상황에서 동료/mingsblog.hedvion.com으로의 이전은 단순한 도메인 변경이 아니라, 배포 자동화, SEO 설정, 그리고 팀 인프라의 중앙화를 함께 이루는 작업이었다.

변경 범위와 영향받은 파일들

특히 중요한 파일은 astro.config.mjs와 robots.txt다. 정적 사이트 생성기(Astro)는 빌드 시점에 site URL을 사용해 사이트맵과 OG 메타 태그를 생성하는데, 이 값이 틀리면 SEO와 소셜 공유가 제대로 되지 않는다. 또한 robots.txt는 검색 엔진이 크롤링할 때 참고하는 첫 번째 파일이라, 도메인 이전 후 올바르게 업데이트하지 않으면 오래된 주소가 여전히 크롤링될 수 있다.

도메인 이전 시 놓치기 쉬운 부분들

이런 작업을 하면서 느낀 점은, 도메인 이전이 단순히 "이전 주소에서 새 주소로 리다이렉트 걸기"만은 아니라는 것이다. 실제로 고려할 사항은 훨씬 많다.

SEO 리다이렉트 전략: 이전 도메인(werebridge.com)의 기존 블로그 글들이 검색 결과에 나타나고 있을 수 있다. 완전히 없어지지 않으려면 이전 주소에서 새 주소로 301(영구 이동) 리다이렉트를 설정해야 한다. 하지만 이 작업은 이번 커밋에 포함되지 않았는데, 이는 별도의 인프라 작업이거나 이전 도메인을 더 이상 관리하지 않기로 한 결정일 수 있다.

배포 설정과 환경 변수: CI/CD 파이프라인에서 배포 대상 경로나 URL을 참조하는 부분이 많을 수 있다. deploy.yml 외에도 숨겨진 설정이 있을 수 있으니 주의해야 한다.

클라이언트/외부 서비스 연동: 블로그가 다른 시스템과 연동되어 있다면(예: 뉴스레터, RSS, 소셜 미디어 자동 공유), 그 설정들도 함께 업데이트해야 한다.

이런 작업이 팀에 주는 의미

내 관점에서 이 작업은 작은 도메인 변경처럼 보일 수 있지만, 팀 리딩 입장에서는 몇 가지를 생각하게 한다. 첫째, 개인 프로젝트가 팀 자산으로 흡수될 때는 소유권과 책임 구조를 명확히 해야 한다는 것. 둘째, 인프라가 흩어져 있으면 자동화와 확장이 어렵다는 것. 셋째, 도메인 이전 같은 큰 변경은 영향받는 범위를 꼼꼼히 체크하는 게 필수라는 것이다.

특히 이번 경우 변경 파일 목록(deploy.yml, robots.txt, astro.config.mjs, Footer 컴포넌트 등)을 보면, "도메인을 바꾼다" = "이 모든 것들을 다시 봐야 한다"는 뜻이 명확해진다. 처음에 놓친 파일이 있으면 나중에 사용자가 발견하는 불일치(옛날 주소 표시, SEO 누락, 링크 오류)로 이어진다.

결론

도메인 통합 작업 자체는 기술적으로는 "몇 줄 바꾸기"처럼 보이지만, 실제로는 배포, SEO, 문서, UI 등 여러 레이어를 함께 검토하고 업데이트하는 조율 작업이다. 이번 경험에서 기억할 점은 큰 인프라 변경을 할 때는 체크리스트를 만들고, 영향받는 모든 파일을 명시적으로 검토하는 것. 나중에 "아, 그것도 변경해야 했네" 라고 하는 것보다 처음부터 꼼꼼히 하는 게 팀의 신뢰를 지키는 길이다.

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

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

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