*이 글은 핵클 프론트엔드 엔지니어 Peter님의 수기 컨텐츠 입니다.
핵클의 홈페이지와 대시보드 관리에 사용되고 있던 패키지 매니저는 Yarn Classic(v1) 이었습니다. 2017년에 출시된 Yarn은 초기 npm이 가지고 있던 가장 큰 문제인 설치 프로세스 속도를 개선해 줬지만, 2020년부터는 새로운 기능 업데이트는 중단되고, 유지 보수 정도만 되고 있는 레거시 프로젝트 입니다.
저희팀은 최근까지 Yarn Classic(v1)을 사용했는데, 의존성(dependency)을 설치하는 과정에서 CI/CD 빌드 파이프라인 시간이 늘어나 배포 효율이 감소하는 문제를 지속적으로 겪어 왔고 마침내 패키지 매니저 변경이 필요하다는 결론에 도달 했습니다.
패키지 매니저 교체를 결정하고, 여러가지 패키지 매니저들을 검토해 보았는데요. 사실 모던 패키지 매니저들은 기능상으로 큰 차이가 없기 때문에 설치 속도나 스토리지 사용량, 기존 시스템과의 적합성 등 기능 외적인 요소들을 고려하게 됩니다.
아래와 같이 패키지 매니저를 비교 분석하여 정리해놓은 표를 참고하면 효율적으로 검토가 가능합니다.
저희팀에서는 Yarn Berry와 pnpm를 상세하게 검토했고, 결과적으로는 pnpm 도입을 결정 했습니다.
Yarn Berry와 pnpm은 요즘 가장 보편적으로 사용되는 모던 패키지 매니저 인데요. 두 가지의 가장 큰 차이는 Zero Install 지원 유무와 패키지 호이스팅 지원 여부이고, 공통점은 두가지 다 package.json에 명시된 의존성에만 접근할 수 있다는 점입니다.
Yarn Berry를 사용하면서 의존성 설치에서 큰 개선을 보려면 Zero install의 사용이 필요한데, 이는 git에 zip 파일로 관리가 되는 방식이며 의존성 자체가 git으로 관리되기 때문에 매번 의존성을 설치하거나 하지 않아도 되는 장점은 있습니다.
하지만 git에 모든 파일 기록을 저장하는 만큼 .git 디렉토리 자체가 무거워지며, PR을 만들었을 때 의존성이 변경되면 해당 파일들도 변경되기 때문에 코드 리뷰가 번거롭고 불편하다는 단점이 있죠.
이외에도 pnpm은 로컬 디렉토리에 캐싱된 의존성이 있다면 symbolic link를 거는 방식이기 때문에 새로운 프로젝트 환경이라도, 이미 PC에 설치한 적이 있는 의존성이라면 캐싱을 이용해서 로컬 환경에서 빠르게 의존성 설치가 가능하고, CI/CD 환경에서도 영구적으로 캐싱해서 사용하는 것도 가능하기 때문에 최종적으로 pnpm을 도입을 결정하게 되었습니다. (실제로 도입 시에는 테스트 해본 AWS EFS의 I/O 속도가 빠르지 않아서 제외함)
pnpm은 다른 패키지 매니저(npm, yarn) 등의 lock 파일 내용을 가져올 수 있는 import 명령어를 지원 합니다.
node.js의 실험적 기능인 Corepack을 이용해서 대시보드 프로젝트의 패키지 매니저 버전 명시하기
pnpm은 기본적으로 package.json에 명시되지 않은 의존성(직접 설치하지는 않았지만 내가 설치한 의존성이 가지고 있는 의존성)을 직접 import 하는 것을 허용하지 않기 때문에 이를 제거하거나 직접 명시적으로 설치를 해야 합니다.
해당 패키지를 직접 설치하여 명시적으로 package.json의 dependencies에 추가한다.
해당 패키지를 직접 import 하는 코드를 제거한다.
배포 환경(Argo CI)에서 빌드 스크립트 yarn에서 pnpm으로 변경 할 경우 예시
패키지 매니저 변경을 통해 CI 파이프라인 배포 속도가 크게 개선되는 성과를 얻을 수 있었습니다.
prebuilt 시 job duration 속도가 50% 이상 개선 되었고, 의존성 설치에 소요되는 시간은 무려 90% 이상 감소 하였습니다.
build 시 job duration 속도도 prebuild와 마찬가지로 50% 이상 개선 되었고, build 속도도 약 50% 개선 되었습니다.
이 개선으로 인해 월간 배포 효율성이 약 160% 향상되는 성과를 얻을 수 있었습니다.
.png)
%20(1).jpg)
