피드로 돌아가기
Dev.toFrontend
원문 읽기
pnpm 도입으로 Cold Install 53% 단축 및 디스크 사용량 50% 이상 절감
pnpm vs npm vs yarn en 2026: lo corrí en mi monorepo real y el resultado me obligó a cambiar de criterio
AI 요약
Context
Next.js 16 기반 Monorepo 환경에서 npm의 Flat Hoisting으로 인한 의존성 불투명성과 느린 설치 속도 문제 발생. 특히 CI 환경에서의 Cold Install 시간과 대규모 node_modules로 인한 디스크 낭비가 병목 지점으로 작용.
Technical Solution
- Content-addressable store 기반의 Symbolic Link 구조를 통해 중복 패키지 제거 및 디스크 사용량 최적화
- Strict Hoisting 모델을 적용하여 package.json에 명시되지 않은 Phantom Dependency 접근을 원천 차단하는 설계
- Radix UI 등 특정 라이브러리의 의존성 누락 문제 해결을 위해
.npmrc내public-hoist-pattern을 활용한 선별적 Hoisting 허용 workspace:*프로토콜 도입으로 로컬 패키지 간 참조를 강제하여 Registry 의존성 제거 및 개발 속도 향상shamefully-hoist=true설정을 배제하여 pnpm의 Strictness 이점을 유지하고 런타임 에러를 빌드 타임으로 전이
Impact
- Cold Install 시간: npm(87s) 대비 pnpm(41s)으로 약 53% 성능 개선
- Disk Usage: npm(1.4GB) 대비 pnpm(610MB)으로 50% 이상 용량 절감
- Warm Cache Install: npm(18s) 대비 pnpm(9s)으로 2배 빠른 배포 속도 달성
Key Takeaway
단순한 벤치마크 수치보다 Strict Hoisting으로 인한 호환성 비용(Compatibility Cost)을 인지하는 것이 중요하며, 전역 허용보다는 특정 Scope에 한정한 점진적 Hoisting 전략이 실무적으로 유효함.
실천 포인트
- pnpm 마이그레이션 시 `public-hoist-pattern`을 통해 UI 프레임워크의 누락된 의존성 범위를 사전에 정의할 것 - `shamefully-hoist` 옵션을 지양하고 TypeScript Strict 모드를 통해 의존성 누락을 빌드 단계에서 검출할 것 - Monorepo 내부 패키지 참조 시 반드시 `workspace:*` 프로토콜을 사용하여 버전 정합성을 유지할 것 - CI 파이프라인 구축 시 pnpm store를 캐싱하여 Warm Install 효율을 극대화할 것