<aside>

두 개 이상의 프로젝트 코드를 하나의 버전 관리 저장소에서 관리하는 방법이다.

</aside>

프로젝트 구조

root/
├─ apps/
│    ├─ api-admin/
│    │   ├─ src/main/java/
│    │   │   ├─ project-1/
│    │   │   │   ├─ common.controller
│    │   │   │   ├─ config
│    │   │   │   ├─ home.controller
│    │   │   │   ├─ notice
│    │   │   │   │   ├─ adaper
│    │   │   │   │   ├─ model
│    │   │   │   │   ├─ persistence
│    │   │   │   │   │   ├─ entity
│    │   │   │   │   │   ├─ mapper
│    │   │   │   │   │   └─ repository
│    │   │   │   │   └─ service
│    │   │   │   ├─ security
│    │   │   │   ├─ upload
│    │   │   │   └─ user
│    │   │   └─ resources
│    │   ├─ test/
│    │   └─ build.gradle.kts
│    └─ api-user/
├─ buildSrc/
├─ containers/
│    ├─ project-1/
│    │   └─ Dockerfile
│    └─ project-2/
│        └─ Dockerfile
├─ docs/
├─ libs/
│    ├─ common-util/
│    │   ├─ src/main/java/
│    │   │   ├─ project-1/
│    │   │   │   ├─ audit
│    │   │   │   ├─ auth
│    │   │   │   ├─ config
│    │   │   │   ├─ converter
│    │   │   │   ├─ intercepter
│    │   │   │   ├─ jwt
│    │   │   │   └─ model
│    │   │   └─ resources
│    │   ├─ test/
│    │   └─ build.gradle.kts
│    ├─ spring-security-stater/
│    ├─ spring-mail-starter/
│    ├─ common-exception/
│    ├─ tiktok-client/
		(...)
│    
└─ scripts/

장단점

<aside>

장점

1. 코드 재사용성 및 공유 구조 강화
   1. 공통 UI 컴포넌트, 유틸리티, 설정 등을 단일 저장소에서 공유 가능
   2. 중복 코드 감소, 변경 시 모든 패키지에 즉시 반영
2. 일관된 개발 환경 유지
   1. ESLint/Prettier/TSConfing/BAbel 등 설정을 한 번에 관리
   2. 패키지 간 빌드/테스트/릴리즈 방식 표준화 용이
3. 개발자 경험 향상
   1. 의존성 버전 관리 규칙 통일
   2. 패키지 간 이동, 코드 참조가 직관적
   3. 로컬에서 여러 패키지를 동시에 개발/테스트 하기 좋음
4. 원활한 협업 및 변경 관리
   1. 멀티 패키지를 아우르는 대큐모 리팩터링이나 API 변경을 단일 PR에서 수행 가능
   2. 변경 이력을 한곳에서 추적
5. CI/CD 최적화
   1. 러너 캐싱, 터보레포나 NX 등으로 빌드/테스트 병렬화 및 캐싱
   2. 변경있는 패키지만 빌드/테스트하는 incremental workflow 가능 </aside>

<aside>

단점

1. 초기 설계/구축 비용 증가
   1. 구조 설계, 워크스페이스 세팅, 빌드 파이프라인 구성 등이 복잡
   2. 패키지 경계 정의 실패 시 장기 유지보수 비용 증가
2. 저장소 규모 증가
   1. Git 히스토리가 비대해지고 clone 속도, 용량 관리 필요
   2. 대규모 리포에서 IDE 성능 부담 증가 가능
3. 의존성 충돌/버전 전략 난이도
   1. 모든 패키지가 동일 버전을 쓸지, 독립 버전을 가질지 결정 필요
   2. workspace hoisting 전략에 따라 예기치 못한 충돌 발생 가능
4. CI/CD 리소스 부담
   1. 전체 패키지 기준으로 돌릴 경우 빌드 시간 증가
   2. smart caching을 구성하지 않으면 단점만 커짐
5. 접근 권한 관리 어려움
   1. 저장소가 하나이므로 패키지 단위 접근 제어가 어려움
   2. 민감한 서비스와 오픈된 패키지가 섞이면 위험 </aside>

단일객체 - libs

autoConfig

립스

커넥션풀 db

레튜스 - 라이브러리