블로그보다 오래 갈 저장소 구조를 먼저 정했습니다

기술 블로그를 만들기로 했지만 저장소와 애플리케이션을 blog에만 맞추지 않았습니다. 지금 필요한 것은 글을 읽는 화면이지만, 오래 운영하면 콘텐츠 관리와 방문·검색·수익 통계를 함께 확인해야 하기 때문입니다.

배포 단위는 하나로 유지하기

첫 번째 기준은 화면마다 서버를 늘리지 않는 것입니다. 공개 사이트, 블로그, 관리자, 통계를 하나의 Next.js 애플리케이션 안에서 route group과 기능 모듈로 구분합니다.

apps/web
├── app/(public)   공개 홈페이지와 글
├── app/(admin)    관리자와 통계
└── features       콘텐츠와 외부 연동 경계

공개 영역과 관리 영역은 레이아웃의 정보 밀도는 다르지만 같은 색상, 서체, 버튼 규칙을 사용합니다.

미래의 빈 패키지를 만들지 않기

확장 가능한 구조를 만든다는 이유로 사용하지 않는 API, 워커, UI 패키지를 먼저 만들면 현재 구조를 이해하기 어려워집니다. 실제 중복이나 독립 배포 요구가 생길 때만 새 워크스페이스를 만듭니다.

문서와 검사 코드로 경계를 유지하기

문서만 있으면 시간이 지나면서 규칙이 쉽게 누락됩니다. 루트의 AGENTS.md에 작업 규칙을 두고 구조 검사로 이름, 공개 여부, 중첩 Git 저장소 같은 불변 조건을 확인합니다.

구조는 완성된 그림이 아니라 다음 변경의 비용을 예측할 수 있게 하는 계약에 가깝습니다.