Fat Gem 사용은 사용자에게 즉각적인 편리함을 제공하나, 최신 루비 버전으로의 신속한 업데이트를 저해하는 주요 원인이 됩니다. 매년 크리스마스에 출시되는 새로운 루비 버전은 성능 향상과 신규 기능을 제공하지만, 사용 중인 Fat Gem 중 단 하나라도 최신 버전을 지원하지 않으면 전체 애플리케이션의 업데이트가 불가능해지는 상황이 발생합니다. Nokogiri와 같이 신속하게 대응하는 젬도 있지만, 모든 Fat Gem 개발자에게 이러한 노력을 기대하기는 어렵습니다. 또한, Fat Gem이 외부 라이브러리를 포함하는 경우, 해당 라이브러리의 보안 취약점이 발견되더라도 Fat Gem 개발자가 업데이트를 제공하기 전까지는 위험에 노출될 수 있습니다. 일반적으로 시스템 패키지 관리자가 보안 업데이트에 더 빠르게 대응하는 경향이 있어, Fat Gem에 의존하는 것은 이러한 이점을 상실하게 만듭니다.
개발자 관점에서 Fat Gem의 유지보수 비용은 상상 이상으로 높습니다. 특히 크로스 컴파일은 빌드 환경과 실행 환경이 다른 경우에 필수적인데, 이는 매우 복잡하고 오류 발생 가능성이 높습니다. 루비는 현재 최소 4개의 주요 버전이 유지보수되며, 각 버전에 대해 11개 이상의 다양한 환경(운영체제, 라이브러리 버전 등)을 지원해야 하므로, 하나의 Fat Gem을 릴리스할 때마다 44개 이상의 빌드된 젬을 생성해야 하는 부담이 있습니다. 또한, 여러 Fat Gem이 동일한 외부 라이브러리(예: zlib, curl)를 정적으로 링크할 경우, 심볼 충돌이 발생하여 예상치 못한 오류를 초래할 수 있습니다. 이는 Fat Gem 개발자들의 엄청난 노고를 요구하며, 새로운 기능 개발이나 버그 수정에 할애할 시간을 잠식합니다.
이러한 문제에 대한 해결책으로, 발표자는 빌드 환경 자동화 시스템을 제안합니다. 윈도우용 루비 인스톨러2(RubyInstaller2)가 MSYS2를 기반으로 빌드 환경을 자동으로 설정하고 젬 설치 시 필요한 의존 라이브러리를 시스템 패키지 관리자를 통해 설치하는 방식과 유사합니다. 발표자는 이를 구현하기 위해 rubygems-requirements-system이라는 젬을 개발하여, gemspec 파일에 필요한 시스템 라이브러리 정보를 명시하면 자동으로 설치되도록 했습니다. 이 방식은 Fat Gem의 필요성을 줄여 위에서 언급된 문제들을 해결할 수 있습니다. 물론, 빌드 시간이 길어지거나 시스템 환경이 변경되는 것에 대한 사용자 불만이 있을 수 있지만, 병렬 빌드, 컨테이너 환경 활용, 또는 앱별 패키지 관리자(Conda, Conan, VCPKG 등) 사용을 통해 해결할 수 있다고 제안합니다.