개인 프로젝트를 하나씩 만들다 보면 어느 순간 "이걸 어디에 올리지?"라는 고민이 생긴다. 처음엔 하나의 도메인에 경로로 구분하면 되겠다고 생각했다. /chart, /baby 이런 식으로. 근데 막상 프로젝트 성격이 달라지고 코드베이스가 분리되면서, 그 방식이 점점 불편해졌다.
결국 cyh-lab.com을 허브로 두고, chart.cyh-lab.com, baby.cyh-lab.com 같은 서브도메인 구조로 전환했다. 이 글은 그 구조를 선택한 배경과 이유를 정리한 것이다.
처음엔 단일 Next.js 프로젝트였다
초반에는 하나의 Next.js 앱에 경로로 구분하는 방식을 썼다.
cyh-lab.com/chart ← 주식 차트
cyh-lab.com/baby ← 임신·육아 가이드배포는 한 번이면 되고, 공통 컴포넌트 공유도 쉬웠다. 처음 빠르게 만들어보는 단계에서는 이게 맞는 방법이었다.
불편함이 쌓이기 시작한 지점
문제는 두 프로젝트가 커지면서 생겼다.
의존성 충돌. 차트 사이트는 실시간 주식 데이터를 다루다 보니 특정 패키지에 의존하는 부분이 있다. 육아 사이트는 정적 콘텐츠 위주라 필요한 패키지 셋이 완전히 다르다. 한쪽 패키지를 업데이트했더니 다른 쪽에서 에러가 나는 상황이 생겼다.
배포 단위 문제. 차트 페이지 버그 하나 고치려고 전체 앱을 배포하면 육아 쪽도 같이 영향을 받는다. 분리된 서비스라면 각자 배포 이력을 가져가는 게 맞다.
롤백이 무섭다. 단일 앱에서 롤백하면 두 사이트 모두 이전 버전으로 돌아간다. 한쪽만 되돌리고 싶을 때 방법이 없었다.
서브도메인 구조로 전환한 이유
서브도메인 방식의 장점은 각 프로젝트가 완전히 독립된 배포 단위가 된다는 것이다.
cyh-lab.com ← 허브 (Next.js)
chart.cyh-lab.com ← 주식 차트 (Next.js, 별도 레포)
baby.cyh-lab.com ← 임신·육아 가이드 (Next.js, 별도 레포)각 프로젝트는 GitHub 레포도 분리되어 있고, Vercel에서도 독립 프로젝트로 올라간다. 한쪽 배포가 다른 쪽에 영향을 줄 수 없는 구조다.
SEO 관점에서도 다르다. cyh-lab.com/chart보다 chart.cyh-lab.com이 구글 입장에서는 별도 사이트처럼 인식된다. 나중에 각 사이트를 독립적으로 성장시키기에 유리한 구조다.
이 방식이 항상 맞는 건 아니다
솔직히 말하면 트레이드오프가 있다.
레포가 늘어나면 관리 포인트도 늘어난다. Next.js 버전 업데이트가 있으면 레포마다 따로 올려야 한다. 공통 컴포넌트를 수정하면 각 프로젝트에 동일하게 반영해줘야 한다.
프로젝트가 하나이거나, 빠른 런칭이 우선이거나, 혼자 소규모로 운영하는 초반 단계라면 경로 기반 단일 프로젝트가 훨씬 단순하다. 처음부터 서브도메인으로 시작한 게 아니라 중간에 분리한 거라, 그 마이그레이션 과정이 더 번거로웠다.