모노레포 · SSOT · 계층 분리 사고

서비스가 3 개를 넘으면 구조 결정이 개별 라이브러리 선택보다 더 큰 영향을 줍니다. 모노레포 · SSOT · 계층 분리 — 이 셋이 "같은 함수를 여기서도 저기서도 고친다" 같은 피로를 없애는 기본기.

누구를 위한 강좌인가

• 사이드프로젝트 여러 개를 한 곳에서 운영하고 싶은 분
• "같은 코드가 세 군데서 돈다" 는 느낌이 드는 분
• 아키텍처 결정 때마다 감으로 하고 있다 느끼는 분

다 끝내면 가능한 것

• 모노레포 vs 멀티레포 선택 기준
• SSOT (Single Source of Truth) 위치 결정 원칙
• 폴더를 계약으로 보기 · "URL = 폴더" 정합
• SQL = SSOT · DB 는 거울
• 점진 리팩터 · 트레이드오프
• 문서를 사람과 에이전트 양쪽을 위해

단계 흐름

구조 결정을 남기는 순서

1저장소 경계

모노레포와 다중 저장소의 소유권·배포 결합도를 비교합니다.

2단일 원본

코드·설정·데이터 중 어떤 산출물이 SSOT인지 명시합니다.

3물리 계약

폴더 경계와 SQL 스키마가 책임과 데이터 계약을 드러내게 합니다.

4점진 개선

작은 리팩터링과 판단 중심 문서로 구조를 안전하게 진화시킵니다.

뒤로 갈수록 "결정의 결과가 코드 외부에 남는" 패턴 — 폴더 구조 · DB 스키마 · 문서.

단계 구성

1. 모노레포 vs 멀티레포 — 코드 공유 · CI · 릴리스 · 팀 경계
2. SSOT — 어디에 두는가 — 코드 · DB · 문서 중 선택 규칙
3. 폴더를 계약으로 — URL = 폴더 · 파일명 규약 · 진입점 안정화
4. SQL = SSOT — DB 스키마의 진실 · ALTER 전략 · 시드 멱등
5. 점진 리팩터 · 트레이드오프 — 큰 재작성을 피하는 몇 가지 규칙
6. 에이전트 친화 문서 — CLAUDE.md · rules.md · skill · 시맨틱 네이밍

전제 — 최소 2 개 서비스 운영 경험.