프론트엔드
그때는 맞고 지금은 틀리다. Yarn Berry에서 pnpm으로 패키지 매니저 전환기
두줄요약
카카오페이가 Yarn Berry에서 pnpm으로 전환한 배경과 검증 과정을 공유했습니다. 메모리 스파이크를 해결하고 배포 효율과 도커 이미지 크기도 개선했습니다.
문제 상황
- 전사 프론트엔드 표준 패키지 매니저로 Yarn Berry와 Zero-installs를 사용하던 환경에서, 레포지토리 규모 확대와 배포 파이프라인 변화로 새로운 병목 발생
- Git에 포함되는 의존성으로 인한 clone/checkout 비용 증가, PnP와 ZipFS로 인한 DX 저하, 일부 SSR 빌드에서 메모리 스파이크와 OOM 배포 실패 발생
원인 분석
- Yarn PnP가 빌드 초기 단계에서 .pnp.cjs를 메모리에 적재하는 구조와 다수 Worker의 병렬 실행이 메모리 급증을 유발
- 사내 환경에서는 Zero-installs라도 네이티브 의존성 재설치가 필요해 설치 생략 효과가 제한적
- Yarn의 pnpm 모드는 전환 비용은 낮지만 유지보수·생태계 리스크가 존재
해결 방법
- PnP가 아닌 패키지 매니저로 전환하되, 유령 의존성 문제를 피할 수 있는 pnpm을 선택
- 사내 배포 환경에서 메모리 사용량, 설치 시간, 도커 이미지 크기를 검증하고 대시보드로 전후 지표를 수집
- 표준 node_modules 구조를 활용해 메모리 스파이크를 해소하고 이미지 크기와 배포 시간을 함께 개선