TurboRepo 모노레포를 Yarn Classic에서 Pnpm으로 전환하기

Yarn Classic을 쓰던 TurboRepo 모노레포에서 유령 의존성 문제를 해결하려고 Pnpm으로 전환한 과정과 결과를 정리한다.

Yarn Classic은 호이스팅으로 중복 의존성을 줄이지만, 그 과정에서 직접 선언하지 않은 패키지를 암묵적으로 참조하는 유령 의존성이 생길 수 있다. 모노레포에서는 이 문제가 더 자주, 더 치명적으로 드러났고 실제로 depcheck로 여러 유령 의존성이 확인됐다.

대안으로는 Yarn Berry와 Pnpm이 있었지만, 프로젝트가 TurboRepo를 사용 중이라 Yarn Berry의 PnP는 선택하기 어려웠다. 결국 성능, 보안, 마이그레이션 난이도를 고려해 Pnpm을 택했고, npm과 비슷한 사용법도 장점으로 작용했다.

Pnpm은 호이스팅 대신 Content-addressable Store 방식으로 동작한다. 패키지를 전역 스토어에 한 번만 저장한 뒤, 프로젝트의 node_modules/.pnpm에 하드링크하고 최종적으로 심볼릭 링크로 연결해 디스크 절약과 엄격한 의존성 관리를 동시에 달성한다.

도입 절차는 다음 순서로 진행됐다.

• pnpm을 전역 설치
• 루트에 pnpm-workspace.yaml 생성해 workspace 선언
• 각 앱의 package.json에서 내부 패키지를 workspace:*로 참조
• 기존 node_modules와 캐시를 삭제한 뒤 pnpm install
• depcheck로 유령 의존성을 찾아 정리
• resolution 등 기존 의존성 설정을 Pnpm 환경에 맞게 이관

배포 환경에서는 한 가지 예외 처리가 필요했다. Amplify Preview는 심볼릭 링크를 지원하지 않아 기본 Pnpm 설정으로는 동작하지 않았고, 빌드 단계에서만 .npmrc에 node-linker=hoisted를 써서 해결했다. 반면 프로덕션은 GitHub Actions를 사용했기 때문에 Pnpm 캐시를 붙여 정상적으로 운영할 수 있었다.

전환 후에는 프로덕션 배포가 문제없이 완료됐고, 설치 속도도 크게 개선됐다. Amplify Preview에서는 Done in 74.52s에서 Done in 25.1s 수준으로 약 3배 빨라졌고, GitHub Actions에서도 평균 45~50초 걸리던 설치가 25~30초로 줄었다.

다만 node_modules 크기는 오히려 약간 늘었는데, 유령 의존성을 직접 설치하게 된 점과 모노레포 내에서 같은 라이브러리의 서로 다른 버전을 쓰는 구조가 영향을 준 것으로 봤다. 이런 경우에는 syncpack으로 버전 불일치를 정리하는 최적화가 유효하다.

결론적으로 TurboRepo 모노레포라면 Pnpm 전환이 특히 잘 맞고, 유령 의존성 제거와 설치 속도 개선을 동시에 노릴 수 있다. Yarn Berry PnP보다 설정 부담도 적어, 모노레포를 운영하는 팀이라면 충분히 도입을 검토할 만한 선택지다.