yarn berry는 4가 되었고 zeroinstall 은 못생겼다.

yarn berry는 2023년 10월 23일에 4.0 릴리즈라인이 마침내 스테이블로 들어오게되었습니다.

메이저 버전이 바뀐만큼 많은 부분에서의 개선이 있었는데요

 

개인적으로는 무리를 해서라도 버전을 올려도 될 만큼

성능적으로 매우 드라마틱한 개선이었다고 생각합니다.

 

yarn release image

 

주요 변경점

 

위 메인테이너의 글에서 잘 요약이 되어있는데요

 

1. node.js 18 이상

2. zero-install은 더이상 default 설정이 아님

3. official plugin 들이 기본 설정에 포함

4. 명령어 쪼끔 바뀌었어용

 

---

왜 Zero Install은 ugly 한가?

 

주요변경점 2번에서도 알 수 있듯이 yarn berry는 이제

사람들이 zeroinstall을 좋아하지 않는다는 것을 인정하기로 한 것 같아보입니다.

 

사실 zeroinstall 전략은 말로 듣기엔 그럴듯하지만 수많은 문제점을 안고있는 전략이기도 했습니다.

zeroinstall의 착안점을 생각해보면 이해가 쉬운데요

 

1. 기존 nodemodule에 들어가던 의존성들을 압축해서 용량이 크게 줄어들었다.

2. 어..? 이정도 용량이면 그냥 깃에 올려놓고 써도 되지않나?

3. 와! 의존성이 다 깃에 올라갔으니까 install 안해도 됨 제로인스톨 !

 

그런데 문제는 용량이 압축되었다해도 엄청 가벼운 수준까지는 아닌 것과

압축파일이 엄청나게 많이 생성되는 것이었습니다.

 

기본적으로 프론트엔드 개발에 필요한 의존성들만 설치하더라도 .yarn/cache의 크기는

100mb 가량을 넘기는 것이 평균적입니다.

 

거기에 이것저것 추가된 무거운 프로젝트의 경우에는 의존성이 500mb를 넘는 경우도 잦았습니다.

그렇다보니 git에서는 한커밋에 50mb 이상의 파일을 업로드 하지 못하는 정책을 우회하기 위해

git lfs와 같은 솔루션을 채택하고 캐시파일을 업로드하곤하는데요

https://github.com/orgs/community/discussions/68492

github issue image

 

그렇게 하다보면 위 이슈와 같이 github 한달 무료 대역폭 1gib를 다 소모해버리고 말아

돈을 내든가 | 내 레포지토리에 푸시도 못하는 몸이 되든가

죽음의 양자택일을 해야하는 상황에 놓입니다.

 

필자가 직접 마주한 대역폭 초과 상황

 

zeroinstall이라는 개념은 물론 장점도 많은 방법입니다.

하지만 장점만 보고 사용하기에는 고려해야하는 점들이 조금 많습니다.

 

커밋 히스토리가 쌓이고 쌓여가다보면 종속성에 변화가 생기는일도 있을 것인데

그럴때마다 커밋히스토리에는 커다란 캐시파일들이 쌓이게 될 것이며

이는 git에 부하를 불러 일으켜 속도에 영향을 줄 수 있습니다.

 

거기에 저나 저 이슈당사자와 같이 깃허브 무료 대역폭을 넘겨버리는 일도 생길 수 있고요

이걸 회피하기 위해 git filter-branch와 같은 작업을 주기적으로 하는것도 조금... 힘겹습니다.

 

저같이 개인프로젝트에 사용하는 것이 아니라 긴밀히 협업해야하고 동료가 있는 상황에서는

의존성 하나라도 바꾸는 날엔 코드리뷰가 힘겨워진다는 부수효과는 덤이고요

 

---

yarn 4.0 퍼포먼스 측정

퍼포먼스 이미지

퍼포먼스 문서를 보면 자체 벤치마크 결과 4.0 버전은 3.6 버전대비 약 3배의 퍼포먼스 향상이 있었으며

대부분의 경우 pnpm보다 빠르거나 비슷한 결과를 보였다고 합니다.

 

사실 특별히 벤치마크를 직접 측정해보지 않더라도 사용할때마다 체감될만큼

"어..? 어떻게 이렇게 빠른거지..?" 싶을때가 많았어서 크게 놀랍진 않았습니다만

 

궁금하니까 약식으로 install 속도를 측정해보았습니다.

yarn berry는 nodelinker를 pnp, pnpm, node-modules 총 세개를 모두 지원하기에

각각 세개씩 측정을 해보았는데요 꽤 흥미로운 결과가 나왔습니다.

 

엄밀하게 테스트한건 아니고 각각 한두번씩밖에 측정해보지 않았기에 신뢰하기는 조금 힘들지만

그럼에도 불구하고 어느정도의 추세를 볼 수 있는 수치였습니다.

 

yarn의 경우 한번 인스톨한것들을 자동으로 캐싱하는 동작 때문에

매번 캐싱된것들을 모두 날려주는 작업이 필요해서 조금 귀찮았습니다.

 

npm 패키지들은 install 하는 데 걸린 시간을 측정한 것이며 설치한 패키지의 목록은 모두 동일합니다.

 

패키지매니저	최초 설치	의존성트리 분석이 끝난 상태에서의 설치 (lock file이 있는 상태)
yarn 4.1.0 (pnp)	15.315 s	모든 캐시를 완벽히 지운 상태 : 10.518s 통상적인 캐시만 지운 상태 : 2.087 s
yarn 4.1.0 (pnpm)	22.701 s
yarn 4.1.0 (node-modules)	6.203 s
yarn 3.2.3 (pnp)	37.333 s
yarn 3.2.3 (pnpm)	20.750 s
yarn 3.2.3 (node-modules)	14.416 s
pnpm	28.7 s	6.8 s
npm	65.11 s	16.84 s

 

각 패키지매니저마다 시간 차이가 너무 드라마틱하다보니 조금 당황스러운 것 같습니다.

특히 npm은 언급이 필요없을정도로 지표가 좋지 않네요

 

반면 yarn 4.1.0 버전은 거의 모든 상황에서 다른 비교군을 능가하는 결과를 보였습니다.

특히 pnp 방식으로 설치할때에 걸리는 시간이 3버전 대비 굉장히 줄어든것을 확인할 수 있었는데요

 

그간 사람들이 yarn berry의 zero install 전략을 주목하기도 했던 이유에는

캐싱이나 제로인스톨 전략이 적용되어 있지 않은 최초 설치 시점에는

pnpm보다 성능이 좋지 않다는 점도 한몫 했다고 생각합니다. 

 

실제로도 zeroinstall을 사용하지 않는 경우의 yarn berry는

대부분의 벤치마크 결과에서 pnpm에게 밀리는 형태이기도 했고요

 

그러나 4 버전으로 오면서 pnp 부분의 성능이 크게 개선된 것으로 보입니다.

거기에 yarn berry는 pnpm , node-modules 등

pnp 를 포기해야할 때에 유연하게 다른 전략으로 대체할 수도 있기에

저는 pnpm 진영에 큰 개선이 있지 않는 이상은 yarn berry를 계속 채택할 것 같습니다.

 

그리고 이정도까지 성능이 올라왔다면 더이상 zeroinstall 전략을  많은 손해를 감수하면서 쓰지 않더라도

충분히 의존성 설치를 빠르게 끝낼 수 있을 거라는 확신이 들었습니다.

 

다음은 실제로 제가 사용중인 프로젝트의 github actions 의 running 시간입니다.

zeroinstall 전략을 포기하고 깃에 올라가있던 모든 의존성 압축 파일을 깃에서 제거했음에도 불구하고

dependencies install에 4s 밖에 소모하지 않습니다.

 

---

마치며

 

블로그에 yarn berry에 대한 글을 처음 작성했던게 2023.04.27입니다.

약 일년동안 yarn berry를 꾸역꾸역 사용하면서 제게 yarn berry는 약간

애증의 관계처럼 느껴지기도 합니다.

 

프론트엔드 개발을 시작한지 이제 약 1년여밖에 되지 않았지만

그동안 눈부시게 프론트엔드 생태계가 발전했다는 것을

저는 yarn berry와 vite을 보면서 많이 체감하는 것 같습니다.

 

작년에는 저 둘의 생태계가 아직 빈약한 상황이었어서 많이 고생하면서 환경설정을 했던 기억이 있는데

이제는 둘다 어느정도 보편적인 사용사례들은 편리하게 지원되는 수준까지 발전한 것 같아요

 

사실 yarn berry는 issue 탭만 뒤져보고 소스코드를 볼 생각을 안해봤었는데

얼마전에 소스코드를 흝어보니 모든 코드를 typescript로 작성하였더라구요

도대체 어떤 흑마술을 부려서 성능개선을 이렇게나 해낸건지 궁금하기도 해서

틈틈히 berry 소스코드를 훔쳐봐야겠다는 다짐을 하면서 글 마무리하겠습니다.

 

읽어주셔서 감사합니다.

 

---

레퍼런스

https://engineering.ab180.co/stories/yarn-to-pnpm

Yarn 대신 pnpm으로 넘어간 3가지 이유

https://yarnpkg.com/blog

Blog | Yarn