yarn vs npm vs pnpm — 설치 속도·디스크·monorepo 실측 비교

yarn npm pnpm 비교에서 셋의 진짜 차이는 설치 속도가 아닙니다. 잘못 고르면 CI 빌드 시간이 매주 누적되고 monorepo 디스크가 기가바이트 단위로 새 나갑니다.

프론트엔드·백엔드 monorepo 운영하면서 셋 다 실무에 붙여본 관점에서 2026년 한국 환경 기준 차이를 정리했습니다. 비교 끝나면 자기 환경에 어떤 매니저가 맞는지 답이 보입니다.

한눈에 — 셋의 핵심 스펙

각 매니저의 2026년 6월 기준 안정 버전과 핵심 차별점만 추렸습니다. pnpm 10.x가 설치 속도·디스크 두 축에서 우위, yarn 4 berry는 monorepo·PnP 모드 강점, npm 11은 Node 24 LTS 번들 호환성 1위라는 게 결론입니다.

항목	npm 11	yarn 4 (berry)	pnpm 10
번들 위치	Node.js 24 LTS 기본	corepack 활성화 후	corepack 활성화 후
설치 명령	npm install	yarn install	pnpm install
의존성 저장	평탄화된 node_modules	PnP (.pnp.cjs) 또는 node_modules	content-addressable store + hard link
워크스페이스	기본 지원	강력 (workspaces + plugin)	강력 (workspaces)
Phantom dependency	발생 가능	PnP 모드에서 차단	strict 모드 기본 차단
적합한 환경	호환성 최우선·CI 표준	대규모 monorepo·strict 관리	신규 프로젝트 default·디스크 빠듯

표가 모든 걸 말해주지는 않습니다. 실제로 결정에 영향을 주는 건 "우리 프로젝트가 React Native인가", "Windows 개발자 비율이 얼마인가", "CI 시간을 더 줄여야 하나" 같은 환경 변수입니다. 아래 H2 4개에서 그 부분을 풀어 씁니다. yarn npm pnpm 비교의 표면 수치보다 이 환경 변수가 답을 가릅니다.

설치 속도 실측 — cold install 5배 차이

공식 pnpm 벤치마크 페이지에 50개 의존성 프로젝트 기준 cold install (캐시·node_modules·lockfile 없음) 측정치가 공개돼 있습니다. npm 14.3초 vs pnpm 2.8초로 약 5배 차이가 납니다. yarn classic은 7.1초, yarn berry는 4.2초로 중간 위치입니다.

 

warm install (캐시·lockfile 보존) 기준으로도 격차는 유지됩니다. npm은 3.2초, yarn classic 1.8초, yarn berry 0.98초, pnpm은 755ms로 가장 빠릅니다. CI에서 install 단계가 매 빌드마다 반복되는 점을 감안하면 pnpm은 npm 대비 warm install에서 약 4.2배 빠릅니다.

 

다만 벤치마크 수치는 환경 편차가 큽니다. 디스크 종류(NVMe vs SATA), 네트워크 대역폭, 의존성 트리 깊이에 따라 결과가 바뀝니다. 자기 프로젝트에서 직접 측정하려면 hyperfine 'pnpm install' 'npm install' --prepare 'rm -rf node_modules' 같은 명령으로 비교하는 게 정확합니다. yarn npm pnpm 비교를 직접 해보면 위 수치에 ±20% 정도 편차가 생기는 게 일반적입니다.

 

CI 빌드 시간이 매일 합산되면 의미가 커집니다. 하루 50번 빌드되는 monorepo에서 install이 회당 10초만 줄어도 하루 8분, 월 4시간이 절약됩니다. GitHub Actions 분 단위 과금을 생각하면 매니저 교체만으로도 비용이 떨어집니다.

디스크 사용량 — pnpm이 79% 절감하는 원리

node_modules가 프로젝트마다 수백 메가씩 쌓이는 게 npm·yarn classic의 고질병입니다. 10개 패키지 monorepo에서 React를 공통 의존하면 npm은 약 1,200MB, yarn classic은 1,100MB를 차지합니다. 같은 구성에서 pnpm은 약 280MB로 75~79% 절감됩니다.

 

차이는 content-addressable store + hard link 구조 때문입니다. pnpm은 모든 패키지를 글로벌 store(예: ~/.local/share/pnpm/store) 한 곳에 저장하고, 각 프로젝트의 node_modules에서 hard link로 참조합니다. 같은 React 18.3.1 버전이면 디스크에 단 1번만 존재하고, 100개 프로젝트가 그 1개를 공유합니다.

 

yarn berry PnP 모드는 더 극단적인 방향으로 갑니다. node_modules 자체가 없고 .pnp.cjs 단일 파일이 의존성 그래프를 해석합니다. 같은 monorepo에서 180MB로 가장 작은 footprint를 보입니다. 다만 일부 라이브러리(React Native·일부 번들러)가 PnP를 지원 안 해서 호환성 트레이드오프가 생깁니다. yarn npm pnpm 비교에서 berry의 강점이 가장 두드러지는 지점입니다.

디스크 사용량 (10 패키지 monorepo)	용량	절감률 vs npm
npm	1,200MB	기준
yarn classic	1,100MB	8%
pnpm	280MB	77%
yarn berry (PnP)	180MB	85% (호환성 트레이드오프)

monorepo workspace — yarn berry vs pnpm 갈래

단일 패키지면 셋 다 큰 차이 없습니다. monorepo로 가면 yarn berry와 pnpm 둘 중 하나로 답이 좁혀집니다. npm 11도 workspace 기본 지원은 되지만 의존성 해석 속도와 hoisting 제어가 두 매니저보다 약합니다.

 

yarn berry 경로는 강력한 plugin 시스템과 PnP 옵션이 무기입니다. yarn workspaces foreach 같은 명령으로 모든 패키지에 동시 작업을 거는 게 매끄럽고, .yarnrc.yml로 정책을 세밀하게 잠글 수 있습니다. 대규모 팀에서 strict 의존성 정책을 강제하기 좋습니다.

 

pnpm 경로는 학습 곡선이 더 평탄합니다. pnpm-workspace.yaml에 glob 패턴 한 줄 적으면 monorepo가 동작하고, strict 모드가 기본이라 phantom dependency가 자동 차단됩니다. 디스크 효율이 큰 monorepo에서 특히 유리합니다.

실무에서는 신규 monorepo는 pnpm, 기존 yarn classic monorepo에서 마이그레이션 비용이 부담스러우면 yarn berry로 점진 이전이 안전합니다. 이전에 정리한 개발자 필수 CLI 도구 13가지에서 다룬 CLI 워크플로우 관점에서도, monorepo 셋업이 자주 바뀌는 팀이면 pnpm 쪽이 명령 체계가 단순해 손에 빨리 잡힙니다.

한국 회사 도입 매트릭스 — 6갈래

벤치마크는 같은 조건이라 명확하지만 실제 도입은 회사 환경에 따라 답이 달라집니다. 한국 개발자가 자주 마주치는 6가지 상황별로 권장 매니저를 정리했습니다.

상황	권장 매니저	이유
스타트업 초기 (신규 프로젝트)	pnpm	디스크·속도 모두 유리, CI 비용 절감
기업 레거시 CI/CD	npm	기존 툴체인 호환성, 변경 비용 최소
대규모 monorepo	pnpm 또는 yarn berry	workspace 강력, 의존성 strict
개인 사이드 프로젝트	pnpm	디스크 효율 (여러 프로젝트 누적 시 큰 차이)
React Native 앱	npm 또는 yarn classic	PnP·pnpm 일부 이슈 잔존
Windows 환경 팀	pnpm + Developer Mode	심볼릭 링크 권한 필요, 설정만 잡으면 OK

솔직히 React Native가 메인이면 npm/yarn classic이 가장 안전합니다. 2024~2025년에 RN 0.74+ 일부 버전에서 pnpm hoisting 이슈가 보고됐고, 풀체인 호환성을 따지면 클래식 매니저가 우위입니다. 그 외 일반 웹 프로젝트는 2026년 기준 pnpm을 default로 두고 시작해도 무리 없습니다.

옮길 때 함정 3가지 — Windows·PnP·CI

매니저를 바꾸는 결정은 쉬워도 마이그레이션 과정에서 시간이 새 나가는 함정이 있습니다. 실무에서 가장 자주 부딪힌 3개만 정리합니다.

함정 1 — Windows pnpm 심볼릭 링크 권한

증상: pnpm install 시 EPERM 또는 symlink failed 에러.

원인: Windows는 기본 사용자 권한으로 심볼릭 링크 생성이 막혀있습니다. pnpm은 store에서 node_modules로 link를 거는 구조라 이 권한이 필수입니다.

해결: 설정 → 개인 정보 및 보안 → 개발자용 → "개발자 모드"를 켜면 일반 사용자도 symlink 생성이 허용됩니다. Windows 11 24H2 기준 설정 경로입니다.

함정 2 — yarn berry PnP 호환성

증상: 일부 라이브러리(특히 React Native·Next.js 일부 구버전·webpack plugin)가 PnP 모드에서 모듈 해석 실패.

원인: PnP는 node_modules가 없는 가상 파일시스템이라 require/import를 가로채는 방식인데, 이를 지원 안 하는 도구가 아직 남아있습니다.

해결: .yarnrc.yml에 nodeLinker: node-modules로 설정하면 yarn berry를 쓰면서도 전통적인 node_modules 모드로 폴백할 수 있습니다. PnP 이점은 포기하지만 호환성은 확보됩니다.

함정 3 — CI에서 매니저별 캐시 경로 차이

증상: 매니저를 바꿨는데 GitHub Actions 빌드 시간이 그대로거나 더 느려짐.

원인: actions/setup-node의 cache 옵션이 매니저별로 다른 디렉터리를 참조합니다. npm은 npm 캐시 폴더, yarn berry는 yarn cache 폴더, pnpm은 pnpm store 폴더로 경로가 갈려서 기본 캐시 설정이 무력화됩니다.

해결: setup-node에 cache: 'pnpm'처럼 명시하거나, actions/cache로 store 경로를 직접 지정합니다. pnpm은 pnpm/action-setup 전용 액션이 가장 깔끔합니다.

추가로 Node 25+부터 corepack이 번들에서 제외 예정이라는 점도 기억해두면 좋습니다. 한국 기업의 LTS 정책상 Node 24를 오래 쓸 가능성이 높지만, 25 이상으로 올릴 땐 corepack enable을 별도로 실행해야 yarn·pnpm이 정상 동작합니다. Windows 11 24H2 환경에서 Node·Git·VS Code 같은 기본 셋업이 안 잡혀있다면 그 단계부터 먼저 챙기는 게 순서입니다 (아래 관련 글 박스 참고).

자주 묻는 질문

Q. 셋 다 함께 쓸 수 있나요?
A. 같은 프로젝트에 둘 이상 섞는 건 비추천합니다. lockfile이 충돌하고 phantom dependency가 발생합니다. 대신 package.json의 packageManager 필드("packageManager": "pnpm@10.0.0")와 corepack을 함께 쓰면 팀원 PC에서 매니저 버전까지 강제할 수 있습니다.

Q. 기존 npm 프로젝트를 pnpm으로 옮기는 비용은 얼마나 드나요?
A. 단일 패키지는 보통 30분~1시간이면 끝납니다. npm uninstall && pnpm install로 lockfile만 다시 생성하면 됩니다. monorepo면 workspace 구성과 hoisting 정책을 옮기는 데 반나절 정도 잡으면 안전합니다. CI 파이프라인 수정이 별도 작업입니다.

Q. yarn classic(v1)을 아직 써도 되나요?
A. 유지 보수만 되는 단계라 신규 프로젝트엔 비추천합니다. 다만 React Native 등 호환성이 까다로운 영역에선 여전히 안정적이라 기존 프로젝트를 굳이 마이그레이션할 이유는 없습니다. 신규는 berry 또는 pnpm으로 가는 게 안전합니다.

Q. CI에서 가장 빠른 조합은 뭔가요?
A. pnpm + GitHub Actions cache + frozen-lockfile이 가장 빠릅니다. pnpm install --frozen-lockfile 옵션을 켜면 lockfile 검증만 하고 resolve를 건너뛰어 warm install에서 추가로 시간이 줄어듭니다. 캐시 적중 시 5초 안쪽으로 끝나는 경우도 많습니다.

Q. 회사 정책상 매니저 자유롭게 못 바꾸는데 어떻게 하나요?
A. 새 사이드 프로젝트부터 pnpm을 적용해 데이터를 모으는 게 가장 빠른 설득 방법입니다. CI 시간 단축치, 디스크 절감치, 개발자 PC install 대기 시간 등을 실측한 뒤 팀 회의에서 공유하면 기술 검증 자료로 쓰입니다. 기존 프로덕션 코드를 한 번에 바꾸는 건 위험합니다.

마무리

요약하면 신규 프로젝트는 pnpm을 default로 두고, React Native·레거시 CI 환경이면 npm 유지, 대규모 monorepo는 yarn berry vs pnpm을 팀 정책으로 선택하는 게 2026년 기준 안전한 결정입니다. 벤치마크 수치는 결정의 근거가 되지만 최종 답은 팀 상황에 따라 달라집니다.

 

블로그에 비슷한 비교·세팅 글들을 카테고리별로 정리해두고 있으니 다른 글도 한번 둘러봐 주세요. 여러분 환경에 맞는 쪽을 위 매트릭스에서 고르면 됩니다.

---

📎 이 카테고리의 다른 글

• 개발자 필수 CLI 도구 13가지 — 하루 워크플로우 순서대로 정리 — 2026-05-10
• 2026 VS Code 확장 15가지 — 개발자가 진짜 쓰는 BEST — 2026-05-07
• Windows 11 개발 환경 세팅 — 14가지 필수 설치 체크리스트 (2026) — 2026-05-12

같은 개발 정보 & 최신 동향 카테고리에서 이어서 읽기

---

설치 환경: Windows 11 24H2 · Node.js v24 LTS · npm 11.x · yarn 4.x (berry) · pnpm 10.x · 측정 기준일 2026-06-22