모노레포가 필요로 하는 것 (실제 요구사항)

Source: Dev.to

모노레포 패키지 매니저가 다뤄야 할 사항

• 워크스페이스(여러 패키지/앱)
• 대규모 레포지토리를 위한 빠른 설치
• 결정론적 lockfile(어디서든 동일한 의존성)
• 좋은 CI 캐시
• 최소한의 “의존성 이상”(phantom deps, hoisting 서프라이즈)
• 원활한 개발자 워크플로우(패키지 간 스크립트 실행, 필터링 등)

pnpm 장점

전역 콘텐츠‑주소 지정 스토어

• pnpm은 각 패키지 버전의 단일 복사본을 전역 스토어에 보관합니다.
• 각 프로젝트는 node_modules에 하드‑링크를 사용합니다.
• 결과: 반복 설치가 매우 빠르고, 거대한 모노레포에서 큰 이점을 얻습니다.

작은 레포지토리 풋프린트

• npm을 사용할 경우, 각 워크스페이스가 동일한 패키지를 서브프로젝트마다 복제할 수 있습니다.
• pnpm은 스토어에서 패키지를 재사용합니다.
• 결과: 레포지토리 크기가 작아지고 Docker/CI 레이어가 빨라집니다.

엄격한 의존성 처리

• 패키지는 자신의 package.json에 선언되지 않은 의존성을 가져올 수 없습니다.
• 이는 전형적인 모노레포 버그를 방지합니다: “내 머신에서는 작동했는데 hoisting 때문에… CI에서는 깨졌다.”

인체공학적인 워크스페이스 명령

• 모든 패키지에서 스크립트를 실행합니다.
• 영향을 받은 패키지만 필터링해서 실행합니다.
• 재귀적인 설치/빌드를 깔끔하게 정리합니다.

효과적인 캐싱

• pnpm 스토어가 재사용 가능하기 때문에 캐시가 더 간단하고 효과적입니다.
• 많은 CI 파이프라인에서 pnpm 설치는 첫 번째 캐시된 실행 이후 일관되게 빨라집니다.

npm 고려 사항

• npm은 기본적으로 Node와 함께 제공됩니다.
• 일부 오래된 도구와 스크립트는 npm‑스타일 hoisting 동작을 전제로 하므로, 엔터프라이즈 환경에서 npm이 “지루하고 안전”하게 보일 수 있습니다.
• 팀이 이미 npm에 익숙하고 레포지토리가 작다면 npm 워크스페이스도 “충분히 괜찮다”고 할 수 있습니다.
• npm은 종종 의존성을 hoist하여 선언되지 않은 패키지를 가져올 수 있게 하며, 이는 나중에 의존성 누락 문제를 숨길 수 있습니다.

pnpm과 npm 중 선택하기

pnpm을 선택해야 할 경우:

• 대형 모노레포를 위한 빠르고 결정론적인 설치
• 엄격한 의존성 강제
• 향상된 CI 캐시

npm을 선택해야 할 경우:

• hoisting을 기대하는 레거시 도구와의 호환성
• 작은 레포지토리에 대한 단순성

권장 설정 (pnpm)

• 레포지토리 루트에 단일 pnpm-lock.yaml을 유지합니다.
• pnpm 워크스페이스를 사용합니다.
• 팀 전체의 일관성을 위해 pnpm 버전을 고정합니다. 예:

{
  "packageManager": "pnpm@9.1.2"
}

• pnpm-workspace.yaml에 워크스페이스 레이아웃을 정의합니다:

packages:
  - "apps/*"
  - "packages/*"

2026년 현재 나의 기본 선택: 거의 모든 새로운 모노레포에 pnpm 사용.