Yarn Berry 버리고 pnpm으로 갈아탄 카카오페이, 그 놀라운 변화!

카카오페이는 초기 Yarn Berry + Zero-installs 방식을 통해 의존성 설치 시간을 95%까지 단축했지만, 레포지토리 규모가 커지면서 Git 부담, IDE 설정, 디버깅 어려움 등의 문제에 직면했다. 특히, 배포 빌드 단계에서 메모리 스파이크(Memory Spike)로 인해 OOM(Out of Memory) 에러가 발생하여, 근본적인 해결책으로 PnP 방식에서 벗어나 pnpm을 선택했다. 사내 인프라 개선으로 레지스트리 서버가 안정화된 점도 pnpm 전환의 배경이 되었다.

pnpm 도입 전, 카카오페이는 메모리 스파이크 문제 해결과 배포 시간 증가 우려를 검증했다. Yarn PnP는 빌드 초기 단계에서 .pnp.cjs 파일을 파싱하여 메모리에 적재하는 과정에서 메모리 사용량이 폭증했지만, pnpm은 심링크(Symlink) 기반의 표준 node_modules 구조를 사용하여 메모리 사용량을 안정적으로 유지했다. 또한, pnpm의 글로벌 스토어와 하드 링크를 활용하여 의존성 설치 속도를 개선, 배포 시간 증가 우려를 불식시켰다.

pnpm 전환 과정에서 예상치 못한 도커 이미지 크기 감소라는 부가적인 이점을 얻었다. Next.js의 Standalone 빌드 시, Yarn PnP는 ZipFS와 가상 파일 시스템 경로를 사용하기 때문에 의존성 tracing 기능을 온전히 활용할 수 없었고, 전체 의존성이 포함된 .yarn/cache 디렉터리를 이미지에 포함해야 했다. 반면, pnpm은 표준 node_modules를 사용하므로 Next.js가 생성한 경량화된 디렉터리를 그대로 활용할 수 있었고, 이는 도커 이미지 push/pull 시간 단축으로 이어졌다.

카카오페이는 pnpm 전환을 단순히 기술적인 변경이 아닌, 개발자 경험을 개선하는 기회로 삼았다. 전환 전후 성능 수치를 시각화하는 대시보드를 구축하여 객관적인 지표를 제시하고, 개발자들의 긍정적인 피드백을 수집했다. 표준 node_modules 구조에 대한 익숙함, 로컬과 배포 환경에서의 속도 개선, 전반적인 쾌적함 등 개발자 경험(DX) 향상을 통해 성공적인 전환을 이끌었다. 이는 기술 도입 시 개발자들의 공감대를 형성하고, 변화에 대한 긍정적인 인식을 심어주는 중요한 요소로 작용했다.