[패키지 매니저] NPM / Yarn

최종 수정 : 24.12.21

Yarn

2016년 Fackbook에서 개발됐으며, 당시 NPM의 여러 문제점을 해결하기 위해 등장했다.

 

당시 NPM의 문제와 Yarn의 해결 방식

1. 의존성 설치 속도 문제

NPM은 패키지를 하나씩 순차적으로 설치하는 방식이었다. 하나의 패키지 설치가 완료된 후에야 다음 패키지 설치를 시작하는 방식이다. 이로 인해 수십 개의 패키지를 설치할 경우에는 많은 시간이 소요될 수밖에 없다.

 

-> Yarn은 이 문제를 병렬 설치 방식으로 해결했다. 동시에 설치할 수 있게 되어 시간을 많이 단축할 수 있다.

 

2. 버전 일관성 문제

NPM은 초기에 package-lock.json 파일이 없었다. package.json에서 ^나 ~ 같은 버전 범위를 사용할 때, 개발자마다 다른 버전의 패키지가 설치될 수밖에 없었다. 예를 들어, 기간에 따라 어떤 개발자의 컴퓨터에는 React 16.8.0이 설치외도, 다른 개발자에게는 16.9.0.이 설치되는 경우가 있었다. 이는 "내 컴퓨터에서만 작동하는" 문제의 원인이 됐다.

 

-> Yarn은 yarn.lock 파일을 도입하여 이 문제를 해결했다. 이 파일은 모든 패키지의 정확한 버전을 고정하여, 팀의 모든 개발자가 항상 동일한 버전의 패키지를 사용하도록 보장했다.

 

3. 보안 취약성

초기 NPM은 패키지 설치 과정에서 자동으로 실행되는 코드에 대한 보안 검증이 부족했다. 악의적인 패키지가 설치 과정에서 해로운 코드를 실행할 수 있는 위험이 있었다.

 

-> Yarn은 더 엄격한 보안 정책을 도입했다. 패키지의 체크섬을 확인하고, 설치 스크립트를 더 안전하게 관리했으며, 의존성 트리를 더 철저하게 검증하는 방식을 도입했다.

 

4. 오프라인 지원 부재

초기에는 오프라인 환경에서의 패키지 설치를 제대로 지원하지 않았다. 인터넷이 없는 환경에서는 이미 설치했던 패키지도 다시 설치할 수 없는 경우가 많았다.

 

-> Yarn은 처음부터 효율적인 캐시 시스템을 갖추어, 한 번 다운로드한 패키지는 오프라인 환경에서도 설치할 수 있게 했다. 이는 네트워크가 불안정한 환경이나 폐쇄된 개발 환경에서 특히 유용했다.

 

5. 의존성 해결의 비일관성

NPM 초기 버전은 의존성을 해결하는 알고리즘이 비결정적이었다. 이는 동일한 package.json으로도 설치할 때마다 다른 node_modules 구조가 만들어질 수 있다는 것을 의미한다. 결국, 또 "내 컴퓨터에서만 작동하는" 문제의 원인이 된다.

 

-> Yarn은 결정적인 설치 알고리즘을 도입해, 동일한 package.json으로는 항상 동일한 node_modules 구조가 만들어지도록 보장했다. 이는 개발 환경의 일관성을 크게 향상시켰다.

 

---

NPM

NPM(Node Package Manager)는 2010년에 등장했다. 당시 Node.js가 인기를 얻기 시작했지만, 패키지를 관리할 수 있는 도구가 없었다. 개발자들은 라이브러리를 수동으로 다운로드하고 관리해야 했으며, 이는 매우 비효율적이었다. 또한 코드를 재사용하거나 다른 개발자와 공유하는 과정도 복잡했다. 이런 문제를 해결하기 위해 NPM이 Node.js의 공식 패키지 매니저로 등장했다.

 

초기 NPM은 매우 기본적인 기능만 제공했다. package.json 파일을 통해 프로젝트의 기본 정보와 의존성을 관리할 수 있었고, 간단한 패키지 설치와 배포 기능을 제공했다. 하지만 패키지 설치 속도가 느리고, 버전 관리가 불완전했으며, 보안 측면에서도 취약점이 있었다. 이런 문제점들로 인해 Yarn이나 PNPM 같은 경쟁 도구들의 등장하며 NPM이 발전하게 됐는데, 덕분에 현재의 NPM은 초기 버전과 비교하면 획기적으로 발전했다.

 

1) 특히 보안 측면에서 큰 개선이 이루어졌는데, npm audit 명령어를 통해 프로젝트의 의존성에 있는 보안 취약점을 자동으로 검사하고 수정할 수 있게 됐다. 악성 패키지를 탐지하는 시스템도 강화되어, 더욱 안전한 패키지 설치가 가능해졌다.

 

2) 성능 면에서 현재는 여러 패키지를 동시에 설치할 수 있는 병렬 설치를 지원했다. 캐싱 시스템도 개선되어 한 번 설치한 패키지는 더 빠르게 재설치할 수 있게 됐다.

 

3) 의존성 관리 측면에서도 많은 개선이 이루어졌다. package-lock.json 파일이 도입되어 모든 개발자가 동일한 버전의 패키지를 사용할 수 있게 됐고, workspaces 기능을 통해 모노레포 프로젝트도 효율적으로 관리할 수 있게 됐다. 특정 패키지의 버전을 강제로 지정할 수 있는 overrides 기능도 추가되어, 의존성 충돌 문제를 더 쉽게 해결할 수 있게 됐다.

 

이러한 발전 덕분에 다른 패키지 매니저들이 등장했지만, 여전히 Node.js의 기본 패키지 매니저로서 많은 개발자들에게 사랑받고 있으며, 특히 간단한 프로젝트나 새로운 개발자들에게 진입 장벽이 낮은 도구로 평가받고 있다.