Fat Gem이 야기하는 문제점
발표자는 Fat Gem이 사용자 및 개발자 관점에서 세 가지 주요 문제를 발생시킨다고 설명합니다.
1. 최신 루비 버전 즉시 사용 불가 (사용자 관점)
- 루비는 매년 크리스마스에 새 버전이 출시되며, 사용자들은 성능 향상 및 신기능을 위해 빠르게 업데이트하기를 원합니다.
- 하지만 사용하는 Fat Gem 중 단 하나라도 최신 루비 버전을 지원하지 않으면 전체 애플리케이션 업데이트가 지연됩니다.
- 예시:
nokogiri젬은 루비 3.4.0 출시 당일 빠르게 대응했으나, 모든 Fat Gem 개발자가 이러한 신속한 대응을 할 수는 없습니다. - 이는 결국 Fat Gem 개발자의 부담을 가중시키고, 확장 라이브러리 개발 및 유지보수 의지를 저해하여 장기적으로 루비 생태계에 악영향을 미칠 수 있습니다.
2. 취약성 관리의 어려움 (사용자 관점)
- 바인딩 Fat Gem은 종속 라이브러리까지 젬 내부에 포함하기 때문에, 해당 라이브러리에 취약성이 발견되어도 Fat Gem 개발자가 업데이트를 해주기 전까지는 사용자가 직접 대응하기 어렵습니다.
- 이는 보안 업데이트의 불확실성을 높이며, 시스템 패키지 매니저를 통한 업데이트보다 지연될 수 있습니다.
- 예시:
nokogiri가 사용하는libXLT의 취약성 수정 후nokogiri는 2일 만에 업데이트되었으나, 일반적인 패키지 매니저가 더 빠를 수 있습니다. 그러나 이 경우nokogiri가 더 빨랐던 예외적인 상황이었습니다.
3. 높은 유지보수 비용 (개발자 관점)
- Fat Gem, 특히 바인딩 젬은 크로스 컴파일이 필요한 경우가 많아 유지보수 비용이 매우 높습니다.
- 크로스 컴파일은 빌드 환경과 실행 환경이 달라 어려우며,
rake-compiler-dock와 같은 도구가 환경 구축을 돕지만, 컴파일 자체의 난이도는 여전히 높습니다. - 루비 버전(4개)과 환경(11개, libc 버전 등)을 조합하면 단일 젬을 위해 44가지 빌드 버전을 만들어야 하는 부담이 있습니다.
- 정적 링크(static link) 또한 복잡하며, 여러 Fat Gem이 동일한 라이브러리(예:
zlib,curl)의 다른 버전을 포함할 경우 심볼 충돌 등의 문제가 발생할 수 있습니다.
해결책 제안: 자동 빌드 환경 구축
발표자는 빌드 환경을 자동으로 구축해주는 메커니즘을 제안합니다.
* RubyInstaller2 (Windows): 이미 MSYS2 기반의 자동 빌드 환경 및 패키지 관리 기능을 제공하며, gemspec의 requirements 메타데이터를 통해 종속 라이브러리를 자동으로 설치합니다. 이를 통해 컴파일러나 라이브러리 누락으로 인한 설치 실패를 크게 줄입니다.
* rubygems-requirements-system 젬: 발표자가 2025년에 개발한 이 젬은 RubyGems 및 Bundler 플러그인으로 작동하며, gemspec의 requirements 필드에 시스템 의존성을 명시하면 해당 시스템의 패키지 매니저를 통해 자동으로 설치합니다. 이는 다양한 플랫폼에서 Fat Gem 없이도 설치 실패 문제를 해결할 수 있게 합니다.
Fat Gem 제거 시 발생 가능한 문제 및 해결 방안
- 설치 시간 증가: 빌드 과정으로 인해 설치 시간이 길어질 수 있으나, 병렬 빌드 등 리소스 증가를 통해 완화할 수 있습니다.
- 시스템 변경에 대한 거부감:
gem install시 시스템이 변경되는 것을 꺼리는 사용자들을 위해, 컨테이너 환경 사용, 애플리케이션별 패키지 매니저(Conda, Conan, VCPKG 등) 활용, 또는 Homebrew와의 통합 등을 대안으로 제시합니다.