카카오페이가 Yarn Berry를 버리고 pnpm으로 갈아탄 진짜 이유

의존성 설치에 10분이 걸리던 시절, Yarn Berry의 Zero-installs는 구원자였어요. 설치 시간이 최대 95%까지 단축됐으니까요. 그런데 그 구원자가 몇 년 뒤 배포를 멈추게 만드는 주범이 될 줄은 아무도 몰랐죠. 카카오페이 전사 프론트엔드 표준 패키지 매니저가 Yarn Berry에서 pnpm으로 전환된 이야기예요.

성장과 함께 문제들이 수면 위로 올라왔어요. 모든 의존성이 Git에 포함되니 fetch와 clone 비용이 늘어났고, PR diff가 3,000개를 넘어가면서 코드 리뷰가 사실상 불가능해졌죠. IDE 설정의 번거로움, 디버깅의 어려움도 쌓여갔어요.

SSR 도커 빌드에서 OOM이 터졌다

가장 치명적인 문제는 배포 빌드 단계에서 발생한 메모리 스파이크였어요. SSR 서비스의 도커 이미지 빌드 단계에서 OOM(Out of Memory)으로 배포가 실패하는 경우가 반복됐죠. 원인을 파고 들어가보니, Yarn PnP가 의존성 데이터를 메모리에 로드하는 짧은 순간에 메모리 한도를 초과하고 있었어요.

pnpm은 심링크(Symlink) 기반의 표준 `node_modules` 구조를 사용하기 때문에 메모리 사용량이 안정적으로 유지돼요. 검증 결과 메모리 스파이크 문제는 깔끔하게 해결됐어요. 의존성 설치 단계가 추가되면서 배포 시간이 늘어날 거라 예상했지만, 놀랍게도 pnpm이 더 빨랐죠.

npm도 Yarn pnpm 모드도 후보에서 탈락했다

대안 선택도 신중했어요. npm은 유령 의존성 문제에서 자유롭지 못해서 제외됐고, Yarn의 pnpm 모드는 비주류라 레퍼런스가 부족했죠. pnpm은 설계부터 PnP가 아니었고, 이미 충분히 성숙한 생태계를 가지고 있어서 최종 선택됐어요. 과거의 해결책이 현재의 병목이 되는 건 기술 세계의 자연스러운 흐름이에요. 중요한 건 그 변화를 감지하고 전환할 타이밍을 놓치지 않는 거죠.