C 라이브러리, 패키지 관리의 '보이지 않는' 의존성 문제

토론에서는 C 언어가 다양한 플랫폼과 아키텍처를 지원하기 위해 표준 부재(Lack of Standard)로 인해 발생하는 문제를 지적한다. 특히, C 코드는 특정 운영체제와 하드웨어에 밀접하게 결합되어 있어, 이식성(Portability)에 어려움이 있다. 이러한 특성 때문에 C 패키지를 관리하는 것은 각 플랫폼의 특성을 고려해야 하는 복잡한 작업이 된다. 결과적으로, 언어별 패키지 관리자는 C 라이브러리 의존성을 처리하기 위해 시스템 패키지 관리자의 도움을 받아야 하는 상황에 직면한다. ⚠️

게시물에서는 시스템 패키지 관리자와 언어별 패키지 관리자가 동일한 문제를 해결하려 하면서 발생하는 마찰을 분석한다. 시스템 패키지 관리자는 배포판의 일관성을 유지하는 데 초점을 맞추는 반면, 언어별 패키지 관리자는 프로젝트의 의존성(Dependencies)을 관리하는 데 중점을 둔다. 이러한 역할 중복은 C 라이브러리와 같이 두 관리자 모두에게 필요한 경우, 상호 운용성(Interoperability) 문제를 발생시킨다. ⚠️

토론에서는 C 언어가 자체적인 패키지 레지스트리를 갖추지 못한 점을 지적한다. pkg-config는 설치된 라이브러리를 검색하는 데 사용되지만, 의존성을 선언하거나 가져오는 기능은 제공하지 않는다. 이러한 부재는 언어별 패키지 관리자가 C 라이브러리 의존성을 처리하는 데 어려움을 겪게 만든다. Conan과 vcpkg와 같은 도구가 등장했지만, crates.io나 npm과 같은 보편적인 지위를 얻지 못했다. ⚠️

게시물에서는 Conda, Nix, Guix와 같은 대안을 제시하며, 각 솔루션의 장단점을 분석한다. Conda는 C 라이브러리, Python, R 등을 단일 의존성 그래프로 관리하여 과학 분야에서 널리 사용되지만, 모든 경우에 적합하지 않다는 평가를 받는다. Nix와 Guix는 콘텐츠 주소 지정 저장소를 사용하여 재현성을 강조하지만, 시스템 패키지 관리자의 한계를 벗어나지 못한다. 이러한 솔루션들은 C 라이브러리 의존성 문제를 해결하려는 시도이지만, 아직 보편적인 해결책으로 자리 잡지 못했다. ⚠️