앱마다 서브도메인을 쪼갠 게 맞았나

apex 에 허브를 두고 앱마다 서브도메인을 하나씩 줬다.

ttakochan.com             허브
longshort.ttakochan.com   타코쨩
map.ttakochan.com         합방지도
counter.ttakochan.com     지금, 세계

BrainDancer 자리도 하나 잡아뒀는데 아직 주소가 없다.

지금 상태

서버가 두 종류다. 하나는 Vultr 서울에 Coolify 로 컨테이너를 굴리고 앞에 Cloudflare 프록시를 세웠다. 다른 하나는 Cloudflare Workers 다.

배포 방식이 다르다. 로그 보는 곳도 다르다. 뭔가 안 되면 어디를 봐야 하는지부터 생각해야 한다. 이게 서브도메인을 쪼갠 대가다.

합쳤다면

경로로 나누는 방법이 있었다. ttakochan.com/longshort, ttakochan.com/map 처럼.

이러면 배포가 하나로 묶인다. 도메인 설정도 한 번만 하면 되고, 인증서도 하나다. 헤더 하나 바꾸려고 네 군데를 돌지 않아도 된다.

대신 하나 고치려고 전체를 다시 올려야 한다. 그리고 하나가 죽으면 전부 죽는다.

왜 안 합쳤나

앱마다 만든 시기와 스택이 다르다. 합방지도는 Next.js 로 컨테이너에 올라가 있고, 이 허브는 Astro 정적 빌드를 Workers 가 서빙한다. 빌드 도구도 배포 대상도 겹치는 게 없다.

억지로 한 저장소에 넣었으면 지금쯤 서로를 붙잡고 있었을 것이다. 한쪽 의존성 업그레이드가 다른 쪽 빌드를 깨는 상황을, 나 혼자 굴리는 사이드 프로젝트에서 감당할 이유가 없다.

지금 구조에서는 합방지도가 죽어도 허브와 나머지는 산다. 실제로 각각 따로 배포하고 따로 고치고 있다.

대가는 한 군데에 몰려 있다

문제는 apex 에 있다.

이 도메인은 원래 타코쨩이 쓰던 주소다. 검색 유입과 북마크가 살아 있어서, 옛 경로만 골라 하위 도메인으로 넘기는 Worker 를 앞에 세웠다.

const PAGES = ["predict", "market", "guide", "disclaimer", "result"];

이 목록이 문제다. 사이트가 커질수록 새 페이지 이름이 이 목록과 부딪힐 확률이 올라간다. 실제로 /about, /contact, /privacy 를 새로 만들었더니 셋 다 301 로 튕겼다. 옛 앱에도 같은 이름의 페이지가 있었기 때문이다.

서브도메인을 쪼갠 대가가 여기 한 군데에 쌓여 있다. 앱을 나눈 만큼 apex 는 교통정리를 계속 해야 한다.

판단

맞았다고 본다. 실패가 격리되는 값어치가 배포 창구가 넷인 불편보다 크다.

다만 이 목록은 언젠가 정리해야 한다. 지금은 다섯 개라 눈으로 보이는데, 열 개가 넘어가면 새 페이지를 만들 때마다 목록을 확인하는 걸 잊게 될 것이다.

남은 것

이 목록을 언제 지울 수 있는지 모르겠다. 옛 주소로 들어오는 유입이 아직 있는지 확인해야 판단이 되는데, 그걸 안 재고 있다. 재기 시작해야 지울 수 있다.