Yarn 설치 방법은 예전과 많이 달라졌다. 예전 방식 그대로 따라 하고 있다면 잠깐 멈추자. 검색하면 npm install -g yarn 한 줄로 끝내라는 글이 아직도 1페이지에 뜬다. 그런데 2026년 기준으로 이건 권장 방식이 아니다. 지금은 Node.js에 내장된 Corepack으로 관리하는 게 표준이다. 이 글에서 달라진 Yarn 설치 흐름을 처음부터 정리한다.
Yarn이 뭐고, 왜 아직 쓸까
Yarn은 2016년에 나온 자바스크립트 패키지 매니저다. 등장 당시엔 npm보다 빠른 설치 속도로 주목받았다. 핵심 장점은 셋이다. 받은 패키지를 캐시해 재설치가 빠르고, 체크섬으로 무결성을 확인하며, lockfile로 어느 환경에서나 같은 버전이 깔리도록 보장한다.
물론 지금은 npm도 많이 따라잡았다. 그래도 Yarn을 택하는 이유는 워크스페이스(모노레포) 관리, Plug’n’Play, 빠른 CI 캐싱 같은 영역에서 여전히 강하기 때문이다. 패키지 매니저 자체가 처음이라면 Node.js 설치 및 NPM 사용 가이드부터 보고 오는 걸 권한다.
Classic과 Berry, 먼저 구분하자
Yarn 설치에 들어가기 전에 버전부터 정리해야 한다. Yarn은 크게 둘로 나뉜다.
- Yarn Classic: 1.x 버전. 지금은 레거시 상태로, 버그 픽스만 들어간다.
- Yarn Berry: 2.x 이상. 현재 메이저는 4.x이고, 실제 개발이 이어지는 쪽이다.
새 프로젝트라면 당연히 Berry(4.x)로 시작하는 게 맞다. 무엇이 바뀌었는지는 Yarn 4.0 공식 릴리스 노트에 잘 정리돼 있다.
2026년 Yarn 설치 방법: Corepack
예전 방식인 글로벌 설치는 버전이 꼬이기 쉬웠다. 그래서 지금은 Corepack을 쓴다. Corepack은 Node.js 16.9 이상에 기본 포함돼 있다. 다만 기본은 꺼져 있어서 한 번 켜 줘야 한다.
corepack enable이제 프로젝트마다 쓸 Yarn 버전을 지정한다. 아래 명령은 최신 안정 버전을 그 프로젝트에 묶어 준다.
yarn set version stable이렇게 하면 package.json의 packageManager 필드에 버전이 기록된다. 덕분에 팀원이 누구든 같은 Yarn 버전을 쓰게 된다. 설치 방식의 공식 설명은 Yarn Corepack 문서와 설치 가이드에서 확인할 수 있다.
설치가 잘 됐는지 확인하기
버전이 찍히면 준비 끝이다.
yarn --version옛날 글로벌 설치가 권장되지 않는 이유
그럼 왜 npm install -g yarn이 권장에서 빠졌을까. 글로벌 설치는 컴퓨터 전체에 Yarn 하나를 깔아 두는 방식이다. 문제는 프로젝트마다 필요한 Yarn 버전이 다를 때 생긴다. A 프로젝트는 Yarn 1.x를, B 프로젝트는 4.x를 요구하면 글로벌 하나로는 둘을 못 맞춘다. 결국 버전을 바꿀 때마다 충돌이 나고, “내 PC에선 됐는데”라는 말이 반복된다.
Corepack은 이 문제를 프로젝트 단위로 푼다. 버전을 컴퓨터가 아니라 프로젝트의 package.json에 묶어 두기 때문이다. 그래서 폴더를 옮겨 다녀도 그 프로젝트가 요구하는 정확한 Yarn 버전이 자동으로 적용된다. 팀원이 새로 합류해도 별도 안내 없이 같은 버전을 쓰게 된다. 설치 환경 자체를 코드로 관리하는 셈이다.
여기에 Yarn Berry는 한 걸음 더 간다. node_modules 폴더를 통째로 두지 않고 .yarn 폴더에 압축된 형태로 의존성을 관리하는 Plug’n’Play 방식을 지원한다. 수만 개 파일이 쌓이던 node_modules가 사라지니 설치도, 버전 관리도 가벼워진다. 물론 일부 도구와의 호환 문제가 남아 있어 선택은 프로젝트 상황에 맞추면 된다.
자주 쓰는 명령어, npm과 비교
npm을 써 봤다면 손에 금방 익는다. 자주 쓰는 명령만 모아 봤다.
# 프로젝트 초기화 (Berry는 -2 옵션으로 최신 구조 생성)
yarn init
# package.json 기준으로 의존성 전체 설치
yarn install
# 패키지 추가 (npm install 대응)
yarn add 패키지이름
# 버전이나 태그를 지정해 추가
yarn add 패키지이름@4.0.0
# 개발용 의존성으로만 추가
yarn add 패키지이름 --dev
# 패키지 제거
yarn remove 패키지이름
# 패키지 업그레이드 (Berry는 yarn up)
yarn up 패키지이름명령 구조가 npm과 거의 1:1로 대응한다. npm의 --save처럼 길게 붙일 필요가 없어 타이핑이 줄어든다. npm·npx의 기본기가 헷갈린다면 자바스크립트 프로젝트 생성의 기본: npm, npx, npm create 이해하기를 같이 보면 그림이 맞춰진다.
package.json과 yarn.lock의 역할
두 파일은 짝이다. package.json은 이 프로젝트가 어떤 패키지에 의존하는지 적어 둔 명세서다. 반면 yarn.lock은 실제로 설치된 패키지의 정확한 버전과 구조를 박제한 파일이다.
yarn.lock이 중요한 이유는 재현성이다. 같은 package.json이라도 설치 시점에 따라 하위 패키지 버전이 달라질 수 있다. lockfile이 있으면 내 노트북에서 되던 게 동료 PC나 배포 서버에서도 똑같이 된다. 그래서 이 파일은 반드시 git에 함께 커밋해야 한다. 지우고 다시 설치하는 습관은 협업에서 사고를 부른다.
npm과 Yarn, 실제로 얼마나 다를까
처음 쓰는 분들이 가장 궁금해하는 건 결국 속도다. 솔직히 말하면 요즘은 npm도 캐시와 병렬 설치가 좋아져서 체감 차이가 예전만큼 크지는 않다. 작은 프로젝트 하나만 보면 둘 다 비슷하다. 차이가 벌어지는 지점은 규모가 커질 때다. 패키지 수백 개를 다루는 모노레포나, 하루에 수십 번 설치를 반복하는 CI 환경에서 Yarn Berry의 캐시 전략이 빛을 발한다. 한 번 받아 둔 패키지를 영리하게 재사용하기 때문에, 반복 설치가 많을수록 시간이 크게 줄어든다.
또 하나, Yarn은 출력 메시지가 깔끔하다. 무엇이 추가됐고 무엇이 충돌하는지 한눈에 보인다. 처음 패키지 매니저를 배우는 사람에게는 이 가독성도 무시 못 할 장점이다. 결국 선택은 취향과 규모의 문제지, 정답이 하나로 정해진 영역은 아니다.
그래서 언제 Yarn으로 갈아탈까
정리하면 이렇다. 혼자 작은 프로젝트를 한다면 npm으로도 충분하다. 하지만 모노레포를 다루거나, CI 설치 속도가 답답하거나, 팀 전체가 같은 패키지 매니저 버전을 강제로 맞춰야 한다면 Yarn Berry가 답이 된다.
처음 시작하는 분을 위한 오늘의 체크리스트는 간단하다.
- Node.js가 16.9 이상인지 먼저 확인한다.
corepack enable로 Corepack을 켠다.- 프로젝트에서
yarn set version stable로 버전을 묶는다. yarn.lock은 git에 꼭 커밋한다.
프레임워크까지 바로 붙여 보고 싶다면 React 시작 및 사용해보기로 이어 가면 된다. 도구는 결국 손에 익어야 내 것이 된다. 오늘 한 프로젝트만이라도 Corepack 방식으로 새로 깔아 보자.
참고 자료
- Yarn 공식 문서, “Installation”
- Yarn 공식 블로그, “Release: Yarn 4.0”