같은 브랜드와 같은 코드베이스는 다릅니다
생태계 문서가 정한 기본 원칙은 서비스 하나에 저장소와 배포 하나를 대응시키는 것입니다. 루트 도메인은 이 정적 허브 저장소가 담당하고, 몽글 아케이드와 앱 소개는 각자의 저장소와 Cloudflare Pages 프로젝트에서 배포됩니다. 랭킹용 Supabase 코드도 아케이드 저장소 범위에 있습니다.
예를 들어 이 사이트의 글 한 문장을 고칠 때 아케이드 게임을 다시 빌드할 필요가 없습니다. 반대로 게임의 점수 계산 방식을 바꿔도 허브의 HTML은 별도 배포 전까지 그대로입니다. 어느 부분을 함께 배포해야 하는지가 저장소를 나누는 기준입니다.
루트 허브가 맡는 정보
허브는 프로젝트를 발견하고 제작 배경을 읽는 출발점입니다. 프로젝트의 목적, 서로 다른 서비스가 연결되는 방식, 공통으로 적용한 설계 판단은 루트에서 설명할 수 있습니다. 실행 버튼은 그 설명을 대신하지 않고, 내용을 읽은 뒤 실제 서비스로 이동하는 경로로 둡니다.
반대로 게임 규칙, 최신 기능, 계정과 랭킹 처리처럼 서비스 변경에 따라 자주 달라지는 정보는 해당 서비스가 정본으로 관리합니다. 허브가 같은 설명을 복사하면 두 문서가 서로 다른 시점의 사실을 말할 위험이 있기 때문입니다.
경계가 있어도 교차 정보는 어긋날 수 있습니다
2026년 8월 30일 사전 조사에서 루트 홈은 아케이드를 17종으로 소개했지만 실제 공개 아케이드 목록은 22종이었습니다. 모든 게임이 최대 3분이라는 루트 문구도 최대 시간이 더 긴 2인용 게임과 맞지 않았습니다.
이 차이는 서비스 경계를 없애야 한다는 뜻이 아닙니다. 숫자처럼 자주 바뀌는 값을 루트에 반복해서 적을 때는 배포 전 대조하거나, 장기적으로 아케이드의 게임 목록을 안전하게 내보내는 방식을 별도 저장소에서 설계해야 한다는 신호입니다.
분리로 얻는 것과 치르는 비용
변경 범위가 분명해집니다
허브의 글과 탐색을 고치는 작업이 게임 로직, 인증, 데이터베이스까지 번지지 않습니다. 배포 실패가 영향을 주는 서비스 범위도 작아집니다.
교차 확인이 필요합니다
프로젝트 상태와 개수처럼 여러 사이트에 나타나는 정보는 자동으로 같아지지 않습니다. 각 배포의 운영 URL을 확인하고 변경 책임을 문서로 남겨야 합니다.
세 가지 변경 요청을 실제 경계에 대입해 보기
도메인 이름을 나눴다는 설명만으로는 분리의 이득을 알기 어렵습니다. 아래는 현재 저장소 구조에 가상의 변경 요청을 넣어 본 영향 분석입니다. 실제 장애나 배포 성공을 측정한 표가 아니라, 어디까지 수정·검증해야 하는지를 결정하는 표입니다.
좁은 화면에서는 아래 표만 좌우로 스크롤할 수 있습니다. 키보드로는 표에 포커스를 둔 뒤 방향키를 사용하세요.
| 변경 요청 | 수정할 정본 | 함께 확인할 것 | 이유 없이 바꾸지 않을 것 |
|---|---|---|---|
| 제작 노트의 잘못된 문장 수정 | 허브의 해당 HTML | 본문·관련 링크·실제 수정일. 공용 스타일을 바꾸면 다른 페이지도 확인 | 게임 점수 계산, Supabase 정책 |
| 새 게임 공개 | 아케이드의 게임 등록·조작법·검증 | 아케이드의 실행·랭킹과 허브의 링크·현재 개수 설명 | 과거 날짜의 업데이트 기록을 새 개수로 덮어쓰기 |
| 가족 초대 만료 방식 변경 | 박물관의 인증·초대·데이터 접근 경로 | 유효/만료/취소된 초대의 실제 서버 응답, 소개 문구의 약속 | 허브에 초대 토큰·작품 원본 복제 |
첫 요청은 HTML 하나로 끝날 수 있지만 공통 메뉴나 assets/site.css를 건드리면 허브 전체로 확인 범위가 넓어집니다. 두 번째 요청은 게임 기능을 고치지 않아도 허브의 소개가 낡을 수 있습니다. 세 번째 요청은 허브 문구만 고쳐서는 완료될 수 없습니다. 이 차이가 ‘저장소를 분리했으니 서로 무관하다’고 말하지 않는 이유입니다.
17개와 22개의 어긋남을 어떤 방식으로 막을까?
앞에서 본 개수 불일치를 해결하는 방법은 숫자를 한 번 고치는 것만이 아닙니다. 다음 갱신까지 고려하면 세 가지 선택이 있습니다.
- 현재처럼 수동 대조: 배포할 때 서비스 목록과 허브 링크를 함께 확인합니다. 구현은 단순하지만 담당자가 잊을 수 있습니다. 변동이 잦은 숫자는 소개의 핵심 문장에서 빼고 정본 목록으로 연결할 수도 있습니다.
- 공개 목록을 빌드 때 가져오기: 일관성을 자동 검사할 수 있지만 목록의 형식과 버전 계약, 가져오기 실패 시 배포를 멈출지 정해야 합니다. 빌드가 없는 이 허브에 이 방식만을 위해 새 빌드 체계를 붙이는 비용도 생깁니다.
- 방문할 때마다 목록을 가져오기: 최신성은 높일 수 있지만 서비스 API의 지연·실패가 소개 화면으로 전파됩니다. 중요한 설명을 JavaScript 뒤에만 두면 최초 HTML도 빈약해질 수 있습니다.
이 허브는 아직 첫 번째 방식을 사용합니다. 자동 동기화를 구현했다고 표시하지 않습니다. 변경 빈도가 늘어나 수동 누락이 반복될 때 공개 목록 계약을 검토할 수 있지만, 단지 도메인이 여러 개라는 이유로 공용 API를 먼저 만들 필요는 없습니다. 본문 전달 방식과 목록 갱신 방식을 따로 결정할 수 있습니다.
실제로 이 글을 보강하던 2026년 9월 22일에도 공개 게임 목록은 26종인데 허브 소개는 22종이었습니다. 공개 HTML의 게임 링크를 대조해 탁구·딱 멈추기·체커·네모 따기 네 링크를 허브에 추가하고 현재 소개를 정정했습니다. 8월 기록의 22종은 당시 사실이므로 유지했습니다. 정적 본문이 정상으로 전달돼도 그 안의 사실이 최신인지는 별도로 대조해야 한다는 사례입니다.
나눠도 남는 공통 위험
저장소가 달라도 같은 DNS 관리 계정, 공용 외부 서비스, 잘못 복제한 운영 정보에 의존할 수 있습니다. 분리는 ‘장애가 절대 전파되지 않는다’는 약속이 아닙니다. 변경 요청에 정본·영향 범위·교차 확인을 한 줄씩 적으면, 어느 저장소 작업이 끝났고 어느 확인이 남았는지 설명할 수 있습니다.
새 프로젝트를 나누기 전에 묻는 세 가지
- 서로 다른 시점에 배포할 수 있나요? 소개 글 수정과 게임 기능 변경의 일정이 다르면 독립 배포가 편합니다. 항상 같은 시점에 바뀌는 화면이라면 같은 앱의 경로로 유지하는 쪽이 변경 누락을 줄일 수 있습니다.
- 한쪽의 장애가 다른 쪽에도 번져야 하나요? 공개 설명을 읽는 데 게임 서버가 필요하지 않다면 분리할 근거가 됩니다. 다만 계정·DNS 등 공유 서비스의 장애까지 없어지는 것은 아닙니다.
- 같은 사실을 두 곳에서 누가 갱신하나요? 숫자와 기능 목록을 복제하면 검토 책임이 생깁니다. 자동 동기화가 아직 필요하지 않은 규모에서는 숫자를 빼고 변하지 않는 제작 목적을 설명하는 방법도 있습니다.
분리 자체가 목표는 아닙니다. 프로젝트별로 저장소·배포 설정·환경값을 관리하는 비용도 늘어납니다. 작은 앱의 화면 두 개를 독립 서비스로 나누기 전에, 같은 저장소의 두 경로로 충분한지 먼저 확인하는 편이 낫습니다.
게임이 한 개 늘었을 때의 갱신 예
아케이드가 새 게임을 추가했다고 가정하면, 게임 목록과 조작법은 아케이드에서 갱신합니다. 허브가 총개수를 표시하고 있다면 운영 목록과 대조해 수정하고, 오래된 월별 기록은 당시 상태를 말하므로 그대로 둡니다. 현재 소개와 과거 기록을 같은 숫자로 일괄 바꾸지 않는 것이 중요합니다.
다른 제작처의 사이트를 가져오는 경우에는 배포 경계에 데이터 경계도 더해집니다. 사이트 이전 판단 가이드에서 로그인, 파일 저장, 원래 주소를 각각 어떻게 확인할지 이어서 설명합니다.
관련 글
허브 자체가 본문을 전달하는 방식은 초기 HTML에 본문을 담는 이유에서, 현재 공개 프로젝트는 프로젝트 목록에서 볼 수 있습니다.
제작 노트 목록으로 돌아가기