📘 [번역] NPM의 중첩된 종속성

이번 포스트는 NPM(Node Package Manager)이 다른 언어의 패키지 매니저와는 다른 특징인 Nested Dependencies에 대해 다루는 글을 번역한 글입니다. 원문: Nested Dependencies입니다. (첫번역글이라 오역이 있을 수 있습니다.)

✌ 중첩된 종속성과 평평한 종속성 (Nested Dependencies and Flat Dependencies)

오늘날 많은 패키지 매니저들이 있지만, 기본적으로 중첩된 종속성(Nested Dependencies)으로 작동하도록 설계된 패키지 매니저는 npm 밖에 없다. (적어도 내가 알기에는)

위 다이어그램에서 deps 컨테이너들은 종속성의 격리된 집합을 나타낸다. 대부분의 패키지 매니저들은 모든 종속성에 대해서 하나의 ‘네임스페이스’를 갖는다. 나는 이 상태를 ‘flat(평평한)’ 이라고 부른다. 왜냐하면 종속성을 풀 때 오직 한 단계의 검색 용이성을 가진다는 것을 의미하기 때문이다. 그것은 앱 전체에서 ‘foo’ 라는 이름을 가진 종속성이 하나만 있다는 것을 의미한다.

🥙 평평한 종속성 (Flat Dependencies)

평평한 종속성 시스템에서 종속성을 푸는 작업이 어떻게 일어나는지에 대해 알아보기 위해 예제를 살펴보도록 하자.

이 예제에는 세 개의 종속성이 있다. 검정색 선들은 ‘의존’ 관계를 의미한다. 즉, 우리 앱은 a, b, 그리고 c를 의존하고 있고, c는 a를 의존하고 있다. 우리 앱과 c는 모두 a를 의존하고 있다.

종속성이 평평하기 때문에 (우리 앱 전체에 오직 하나의 복사본만 가지고 있다는 것을 의미함) 우리 앱과 c가 모두 a의 호환되는 버전에 의존하도록 해야한다는 것을 의미한다. 만약 우리가 c를 새로운 버전으로 업그레이드하고 싶다면, 그러나 새 버전이 우리 앱과 의존하고 있는 a와 호환되지 않는 버전의 a로 업그레이드한다면, 종속성 충돌이 발생한다. 이 현상은 “DLL 지옥” (Windows) 또는 더 일반적으로 “종속성 지옥” 이라고 한다.

🐦 중첩된 종속성 (Nested Dependencies)

이번에는 중첩된 종속성 시스템의 같은 예제를 살펴보자.

여기서는 한 단계의 종속성이 아니라 여러 단계의 종속성을 가지고 있다. a와 b가 종속성을 가지고 있지 않다고 가정하자. 우리 앱과 c는 모두 여전히 a에 의존하고 있다.

중첩된 종속성에서는 a의 두 복사본을 가지고 있다. 우리 앱이 a의 버전 1이 필요하고 c가 a의 버전 2가 필요하다면 a의 두 버전을 모두 설치한다. c의 종속성들이 c에게만 이용 가능하고, 어떤 것도 그것들에 접근할 수 없다. 추가적으로, 우리 앱과 c가 모두 a와 호환되는 버전에 의존한다는 것이 드러난다면, c's deps 폴더를 생성할 필요가 없다. 이 경우에는 평평한 종속성처럼 보일 것이다. (이것이 npm dedupe가 동작하는 방법이다.)

🔖 장점과 단점

평평한 종속성 (Flat Dependencies)

• 두 가지 설계 중 더 단순하다. 얼마나 복잡한지를 결정하는 것은 사용자에게 달려있다.
• 종속성 충돌이 일어날 수 있다. (a.k.a 종속성 지옥)
• 종속성을 독립적으로 불러올 수 없는 언어의 유일한 옵션이다.

중첩된 종속성 (Nested Dependencies)

• 종속성 충돌이 일어나지 않는다.
• 작고 고립된 모듈의 사용을 권장한다.
• 더 복잡하다.
• 서로의 종속성을 격리하기 위해 1급 객체 범위 지정을 지원하는 자바스크립트 같은 언어에 좋다.
• 필요하다면 종속성의 여러 복사본을 설치한다. 즉, 더 많은 디스크 공간을 차지한다. (실제로 코드가 작기 때문에 거의 문제가 되지 않는다.)
• 모듈형으로 설계되지 않은 종속성을 사용하는 사용자를 혼란스럽게 한다. (예: ‘왜 내 앱에 jQuery 5개 버전이 있지?‘)

Personal blog by Jon Jee.
I hope to explain with words and code.