모노레포 vs 폴리레포 — 코드 저장소 전략과 트레이드오프

my-company/                    # 하나의 저장소
├── apps/
│   ├── web/                   # 프론트엔드 앱
│   ├── api/                   # 백엔드 API
│   └── admin/                 # 관리자 페이지
├── packages/
│   ├── shared-ui/             # 공유 UI 컴포넌트
│   ├── auth-utils/            # 인증 유틸리티
│   └── eslint-config/         # 공유 린트 설정
└── package.json

my-company-web/      ← 별도 저장소
my-company-api/      ← 별도 저장소
my-company-admin/    ← 별도 저장소
shared-ui/           ← 별도 저장소 + npm 패키지로 배포
auth-utils/          ← 별도 저장소 + npm 패키지로 배포

// package.json (루트)
{
  "name": "my-company",
  "private": true,
  "workspaces": [
    "apps/*",
    "packages/*"
  ]
}

// packages/shared-ui/src/Button.tsx
// 공유 컴포넌트 — apps/web과 apps/admin 모두 사용
export function Button({ children, variant }: ButtonProps) {
  return (
    <button className={`btn btn-${variant}`}>
      {children}
    </button>
  );
}

// apps/web/src/pages/Home.tsx
// 같은 저장소 내 패키지를 바로 import
import { Button } from '@my-company/shared-ui';

export function Home() {
  return <Button variant="primary">시작하기</Button>;
}

// turbo.json — Turborepo 설정
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],  // 의존하는 패키지를 먼저 빌드
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    },
    "lint": {}                   // 의존성 없이 병렬 실행
  }
}

# 변경된 패키지만 빌드 (캐시 활용)
npx turbo build --filter=...@my-company/web

# 결과:
# shared-ui: cache hit (변경 없음, 캐시 사용)
# web: building... (변경 있음, 실제 빌드)

# shared-ui 저장소에서
npm version patch
npm publish  # npm 레지스트리에 배포

# web 저장소에서
npm install @my-company/shared-ui@latest

// web 저장소의 package.json
{
  "dependencies": {
    "@my-company/shared-ui": "^2.3.0",
    "@my-company/auth-utils": "^1.5.2"
  }
}

상황: API 응답 형식 변경 (백엔드 + 프론트엔드)

모노레포:
  하나의 PR에서 api/와 web/을 동시에 수정
  → 빌드가 성공하면 둘 다 호환이 보장됨

폴리레포:
  api 저장소에 PR #1 (API 응답 변경)
  web 저장소에 PR #2 (프론트 대응)
  → 둘 중 하나만 먼저 머지되면 일시적으로 깨질 수 있음

# Sparse Checkout — apps/web만 체크아웃
git sparse-checkout init
git sparse-checkout set apps/web packages/shared-ui

모노레포가 적합한 경우:
- 프로젝트 간 코드 공유가 빈번
- 여러 프로젝트를 동시에 수정하는 경우가 많음
- 일관된 도구/린트/테스트 설정을 유지하고 싶음
- 팀 규모: 1~30명 정도

폴리레포가 적합한 경우:
- 팀(조직)별로 독립적인 릴리스 주기
- 오픈소스 라이브러리를 공개 배포하는 경우
- 저장소별 엄격한 접근 권한 관리가 필요
- 프로젝트 간 기술 스택이 완전히 다름

프론트엔드 모노레포/          ← 프론트엔드 앱 + 공유 UI
  ├── apps/web/
  ├── apps/admin/
  └── packages/shared-ui/

backend-order-service/        ← 백엔드 서비스별 폴리레포
backend-payment-service/
backend-user-service/