1. 개요
Package Manager특정 플랫폼 위에 응용 소프트웨어 패키지를 설치 및 관리하는 프로그램. 단순히 이야기하면 설치된 프로그램을 관리하는 프로그램으로써 프로그램을 깔거나 업데이트, 제거하는 용도로 쓰이는 프로그램이다.
2. 특징
일반적인 설치 매니저를 이용한 설치에 익숙한 사람이라면 왜 이런게 필요한가 싶겟지만 패키지 관리자를 쓸 경우 대량의 프로그램을 스크립트를 통해서 한꺼번에 깔거나 패키지에 따라서는 의존성이 필요한 다른 패키지에 대해서 경고하고 같이 설치할수도 있는등[1]소프트웨어 개발에 쓰는 외부 라이브러리 또한 이렇게 패키지 관리자를 통해 관리하는것이 보편화 되었으며 덕분에 디펜던시 관리에 있어서 매우 편하게 관리할 수 있게 되었다. 이런 패키지 매니저를 에플리케이션 레벨 패키지 관리자 라고 부른다.
2.1. 통일성
만약 응용 프로그램 A는 Windows식 MSIX 형식이고 응용 프로그램 B는 iOS용 IPA, 응용 프로그램 C는 리눅스용 AppImage 형식, 응용 프로그램 D는 Java용 JAR 파일로 배포된다면 어떨까? 분명 한 플랫폼 위에 설치하기 힘들고, 소스에서 직접 빌드를 한다고 해도 매우 번거로운 과정을 거칠 것이 분명하다.대부분의 패키지 관리자는 통일된 규격(protocol)을 하나로 정하고 모든 프로그램이 해당 규격을 따르게 강제함으로써 이런 문제를 해결한다. 만약 개발자가 패키지 관리자가 허용하지 않는 형식으로 응용 프로그램을 배포한다면? 이를 (기술적으로 가능한 경우) 자신이 사용하려는 패키지 매니저가 수용하는 포맷으로 변환해 올바른 패키지로 등록할 수 있는데, 이를 packaging이라고 한다. 한번 패키징을 해내면 재사용이 가능하므로, 다른 사람이 미리 패키징해둔 소프트웨어를 자신이 그대로 사용할 수 있다.[2]
2.2. 종속성
대부분의 응용 프로그램은 실행하기 앞서 필요한 몇몇 데이터들이 있다. 이러한 데이터는 라이브러리부터 프레임워크나 런타임[3], 아이콘 파일 등등 다양한 종류가 있다. 또한 요구되는 라이브러리들도 수많은 다른 라이브러리 등을 종속성으로 가질 수 있다. 이렇게 패키지가 요구하는 데이터들을 종속성(dependency)이라고 한다.2.3. 자동화와 재현성
일반적인 방식으로 패키지를 개별 회사의 웹사이트에서 검색하고, 다운로드하고 경우에 따라 압축을 풀거나 설치하는 방식은 매우 번거롭거나 실수하기 쉽고, 결정적으로 절차적(procedural)이다.반면에 패키지 관리자를 사용하면 대량의 패키지를 한번에 설치하도록 자동화하거나, 심지어 자신의 컴퓨터가 아닌 원격 접속 환경, 클라우드 환경 등에서도 똑같은 내용을 수행할 수 있다. 이를 응용하면 특정 형식의 프로파일(profile)[4]에 자신이 어떤 패키지를 무슨 버전으로 설치했는지를 선언적으로(declarative) 기록해 다른 컴퓨터에서도 같은 패키지들을 설치함으로써 정확히 똑같은 환경을 재현(reproduable)할 수 있다. 이러한 활용의 극단적인 예시로 NixOS가 있는데, 패키지 매니저 Nix로 운영체제 자체를 하나의 패키지 묶음으로 정의해
configuration.nix 파일만 같으면 완벽히 동일한 운영체제 환경을 재구축해낼 수 있다.3. 레지스트리
Registry패키지 매니저를 사용하는 경우 설치할 패키지들에 대한 정보를 등록해 놓은 데이터베이스가 필요한데, 이를 레지스트리라고 부른다. 레지스트리가 필요한 이유는 크게 세 가지가 있는데, 우선 A 회사 웹사이트에서 A 응용 프로그램을 내려받고[5] B 회사 웹사이트에서 B 응용 프로그램을 내려받을 필요 없이 하나에 데이터베이스에서 필요한 모든 데이터를 얻을 수 있게 하기 위해서이며, 둘째로 이러한 패키지들의 버전을 전부 보존하고 관리하기 위해서[6], 마지막으로 패키지 간 종속성을 기록하기 위해서이다.
3.1. 종류
레지스트리는 크게 두 종류로 나눌 수 있는데, 특정한 중심 레지스트리만이 유일한 기준(signle source of truth)으로 사용되는 방식을 중앙 집중형(centralized) 레지스트리, 별도의 공식 레지스트리가 없는 경우를 분산형(decentralized)[7] 레지스트리라고 한다.구조가 단순하기 때문에 중앙 집중형 레지스트리가 더 흔한 편이며, 이러한 중앙 레지스트리 내용을 복사해 똑같이 가지고 있는 레지스트리를 미러라고 한다. 예를 들어 레지스트리를 전부 복사해서 로컬 미러를 만들면, 오프라인 상태에서도 패키지를 설치할 수 있다. 또한 중앙 집중형 레지스트리는 모든 종속성 트리의 데이터가 다 한 데이터베이스 안에 보존되어 있음이 보장되므로, 상술한 재현성의 관점에서도 매우 안전하다. 더불어 모든 패키지가 다 등록되어 있으므로, (존재 여부조차 불투명한) 서드파티 레지스트리를 일일히 추가하지 않으면 검색되지 않는 분산형 레지스트리에 비해 검색이 훨씬 수월하고 쉽다.
중앙 레지스트리도 단점이 많은데, 우선 네임스페이스가 단 하나뿐이라 비슷한 이름의 패키지가 겹치거나, 이름만 같은 다른 프로그램이 딸려오거나[8], 심지어 이름 선점 등의 분쟁이 발생하기도 한다. 이를 해결하기 위해 리버스 도메인 네임이나 org depth를 도입하는 등의 시도를 보이는 경우도 종종 보이지만, 해당 문제가 근본적으로 발생이 불가능한 분산형 레지스트리에 비해 한계가 있다.
또한 중앙 레지스트리가 공개(open)되어 있을 경우, 기업 내부적으로 개발하는 비공개 코드가 유출될 가능성도 있어 별도의 필터 프록시[9]를 운영해야 하는데, 분산형 레지스트리를 사용하면 이러한 문제가 완벽히 해결된다.
4. 패키지 매니저 목록
4.1. 시스템 레벨 패키지 관리자
- Winget: 정식 명칭은 Windows Package Manager로 MS에서 내놓은 윈도우용 패키지 관리자이다.
- Chocolatey: 오픈소스 윈도우용 패키지 매니저.
- Advanced Package Tool: 약어인 APT더 잘 알려진 툴로써 데비안쪽 계열의 OS에서 사용하는 패키지 매니저.
4.2. 에플리케이션 레벨 패키지 관리자
- vcpkg - Microsoft가 오픈소스로 제공하는 C++용 패키지 관리자
- Conan - 스크립트로 Python을 사용하는 C++용 패키지 관리자
- npm - JavaScript용 패키지 관리자
- NuGet - .NET쪽(거의 C#) 라이브러리 패키지 관리자. Visual Studio에 기본적으로 통합되어 있다.
- pip - Python용 패키지 관리자
- 아나콘다(파이썬/R)
- Cargo - Rust 설치 시 자동으로 같이 설치되는 패키지 관리자
4.3. ESD
코드를 주는게 아닌 설치과정까지 관리하는 ESD는 엄밀히 말하면 패키지 매니저의 일종이다. 비슷하게 앱스토어나 구글 플레이같은 소프트웨어도 패키지 매니저다.
[1] 일반적인 설치 매니저는 설치환경이 해당 의존성이 설치되어 있는지 확인 자체가 안되기 때문에 그냥 무식하게 매니저에 다 포함시켜 놓는 식으로 대처한다. 이때문에 플랫폼에 따라 설치 매니저가 다 달라야 하는 귀찮은 구분이 필요하나 패키지 관리자를 이용하면 알아서 사용사 플랫폼에 맞는 버전으로 긁어오기 때문에 덜 귀찮아 진다.[2] 대표적으로 AUR 등에서 이런 모습이 흔하다.[3] Microsoft .NET등.[4] 어떤 형태인지는 패키지 매니저마다 천차만별이다. 유명한 예시로
package.json, requirements.txt, flake.nix 등등이 있다.[5] Windows를 처음 설치하고 MS 엣지로 다운로드 하는 게 구글 크롬이라는 우스갯소리가 있다. 그만큼 윈도우 유저들에게는 특정 회사의 웹사이트로 들어가 인스톨러를 다운로드 받는 프로세스가 흔하다는 소리.[6] 따라서 대부분의 레지스트리는 아카이브의 성격 또한 띄게 된다. 모든 패키지의 과거 버전들이 전부 보존되어 있고, 필요하다면 구버전을 조회하고 설치하는 것도 가능하기 때문.[7] 경우에 따라 탈중앙이라고 번역하는 경우도 간혹 있다.[8] MS스토어와 패키지 관리자 깃허브를 동시에 참조하는 winget이 이런 문제가 자주 발생하는 대표적인 경우. 양쪽에 동일한 이름의 프로그램이 있을 경우 패키지 관리자 설치가 중단되고 정확히 어떤 프로그램을 설치하는지 확인하는 과정이 추가된다.[9] NPM의 경우 Verdaccio 등이 있다.