#Frontend

그때는 맞고 지금은 틀리다. Yarn Berry에서 pnpm으로 패키지 매니저 전환기

Summary

메모리 스파이크부터 Docker 이미지 경량화까지, 데이터로 증명한 패키지 매니저 마이그레이션

프로젝트의 성장에 따라 과거의 최적화 기법이 오히려 병목이 된 사례를 분석하고, pnpm으로의 전환을 통해 기술적 난제를 해결한 과정을 소개합니다. 단순한 도구 교체를 넘어 실제 배포 지표와 인프라 환경을 고려한 의사결정의 정석을 보여줍니다.

모노레포 규모가 커지면서 CI/CD 빌드 속도나 메모리 부족 문제를 겪고 있는 프론트엔드 팀에게 강력히 추천합니다. 특히 Next.js 기반의 SSR 서비스를 운영한다면 배포 이미지 최적화 관점에서 pnpm 도입을 검토해야 합니다.

과거 사내 레지스트리 불안정 문제를 해결하기 위해 도입했던 Yarn Berry의 Zero-installs 방식이 프로젝트 규모가 커짐에 따라 Git 저장소 비대화, DX 저하, 그리고 SSR 빌드 시 메모리 초과(OOM) 현상을 유발했습니다.

유령 의존성 문제를 방지하면서도 표준 node_modules 구조를 활용하는 pnpm으로의 전환을 결정하였으며, 실제 사내 배포 환경과 유사한 조건에서 메모리 점유율 및 설치 속도에 대한 데이터 검증을 거쳐 도입을 확정했습니다.

도커 이미지 크기가 약 83% 감소하고 최대 메모리 사용량이 약 64% 줄어들었으며, pnpm의 효율적인 설치 구조 덕분에 우려했던 배포 시간 지연 없이 빌드 안정성과 개발 생산성을 동시에 확보했습니다.

Trade-off

Zero-installs의 장점인 의존성 설치 생략 이점을 포기하게 되었으나, 본문에 명시된 대로 실제 네이티브 의존성 재빌드 비용을 고려했을 때 실질적인 배포 속도 차이는 없었으며 전환에 따른 개발자 피로도는 개선된 지표 공유를 통해 완화했습니다.

Concept · 01

의존성 패키지를 압축 파일 형태로 Git 저장소에 직접 포함시켜 배포 시 별도의 설치 과정을 생략하는 Yarn Berry의 기법입니다.

Concept · 02

node_modules를 생성하지 않고 .pnp.cjs 파일을 통해 의존성 위치를 런타임에 해석하여 메모리에 로드하는 방식입니다.

Concept · 03

중복된 패키지를 글로벌 스토어에 하나만 저장하고 프로젝트 내 node_modules에는 심링크로 연결하여 공간을 절약하는 구조입니다.

Continue reading · same source