Ruby 및 Rails 업그레이드: 개인적인 경험

Ruby and Rails upgrade: personal experience

작성자
Andrei Kaleshka
발행일
2025년 06월 13일
원문 보기
widefix.com

핵심 요약

  • 1 Ruby 3.1.4에서 3.4.4로, Rails 6.1.7.6에서 7.2로의 점진적 업그레이드 과정에서 발생한 다양한 기술적 문제와 해결책을 상세히 다루고 있습니다.
  • 2 OpenStruct, Logger 등 기본 로딩 변경, Regexp 클래스 변화, Zeitwerk 코드 로더 도입 등 Ruby 및 Rails 버전업에 따른 주요 변경사항과 그에 대한 대응 방안을 제시합니다.
  • 3 AI 도구가 반복적인 작업에는 유용했으나 복잡한 문제 해결에는 한계가 있었으며, 업그레이드 과정에서 오픈소스 기여 경험도 공유합니다.

도입

본 글은 Ruby 3.1.4 및 Rails 6.1.7.6 기반 프로젝트를 Ruby 3.4.4 및 Rails 7.2로 업그레이드한 개인적인 경험을 공유합니다. Heroku의 구버전 Ruby 지원 중단과 애플리케이션의 보안 유지를 위한 불가피한 결정이었으며, Ruby 업그레이드를 선행한 후 Rails 업그레이드를 진행하는 점진적인 방식을 채택하여 각 단계에서 발생한 문제점과 해결 과정을 상세히 기록하였습니다. 이는 단순한 튜토리얼이 아닌, 실제 프로젝트에서 겪었던 도전과 교훈에 대한 성찰입니다.

Ruby 업그레이드 (3.1.4 -> 3.4.4)

Ruby 업그레이드 과정에서는 Gemfile 업데이트 및 bundle install 후 다양한 테스트 및 자산 사전 컴파일 관련 오류가 발생했습니다. 주요 해결 사례는 다음과 같습니다.

  • 기본 라이브러리 로딩 변경: OpenStruct 및 Logger가 더 이상 기본으로 로드되지 않아 config/application.rb에 require 'ostruct' 및 require 'logger'를 추가했습니다.

  • Gem 호환성 문제: bootstrap gem으로 인한 Sass engine 오류는 sassc-rails gem 추가로 해결되었으며, sidekiq-cron 및 drb gem은 최신 버전으로 업그레이드하거나 Gemfile에 명시적으로 추가했습니다.

  • 자산 사전 컴파일 오류: Heroku 배포 시 digital envelope routines::unsupported 오류는 NODE_OPTIONS=--openssl-legacy-provider 환경 변수 설정으로 임시 해결했습니다.

  • Ruby 내부 변경: Regexp.new의 인자 변경으로 인한 오류는 Regexp.new('...', Regexp::FIXEDENCODING | Regexp::NOENCODING)와 같이 수정했습니다.

  • Rubocop: RSpec/BeEq cop은 비활성화하고, Rubocop v1.76.0의 Lint/EmptyInterpolation cop 버그는 오픈소스에 기여하여 v1.76.1에서 해결되었습니다.

Rails 업그레이드 (6.1.7.6 -> 7.2)

Rails 업그레이드 시에는 여러 Gem의 호환성 문제가 발생했으며, Zeitwerk 코드 로더 도입으로 인한 구조적 변경이 가장 큰 도전이었습니다.

  • Gem 업그레이드: paper_trail, paranoia, devise, listen, graphql 등 다수의 Gem을 Rails 7.2와 호환되는 최신 버전으로 업그레이드했습니다.

  • JavaScript 컴프레서: Uglifier::Error 발생으로 uglifier를 terser로 대체하고 config.assets.js_compressor = :terser로 설정했습니다.

  • Zeitwerk 코드 로더: Rails 7.2의 기본 코드 로더인 Zeitwerk의 엄격한 규칙으로 인해 많은 문제가 발생했습니다. config/initializers/zeitwerk.rb를 생성하여 커스텀 클래스의 인플렉션 매핑을 정의하고, Zeitwerk 규칙을 따르지 않는 특정 폴더는 무시한 후 파일을 수동으로 require하는 방식으로 해결했습니다.

  • 메서드 변경: to_s 메서드가 더 이상 포맷 인자를 받지 않아 to_fs로 변경했으며, ActiveRecord 오류 처리 방식(errors.each, object.errors.add) 및 alias_attribute 사용법도 Rails 7.2에 맞춰 수정했습니다.

  • YAML 역직렬화: PaperTrail에서 발생한 Psych::DisallowedClass 오류는 config.active_record.use_yaml_unsafe_load = true 설정으로 해결했습니다.

AI 도구 활용 및 결론

AI 도구는 to_s를 to_fs로 변경하는 등 반복적이고 정형화된 작업에서 유용했으나, Zeitwerk 설정이나 dry-auto_inject와 같은 복잡한 문제 해결에는 한계가 있었습니다. AI는 개발자를 완전히 대체하기보다는 효율성을 높이는 도구로 활용될 것이며, 엔지니어는 AI의 한계를 인지하고 효과적으로 활용하는 능력을 키워야 합니다. 업그레이드 과정에서 Rubocop에 풀 리퀘스트를 제출하는 등 오픈소스 커뮤니티에 기여한 경험도 공유되었습니다.

결론

Rails 업그레이드는 프로젝트의 고유한 종속성과 코드베이스에 따라 그 과정이 크게 달라질 수 있는 복잡한 작업입니다. 본 경험을 통해 점진적인 변경 접근 방식이 문제 격리 및 해결에 효과적임을 확인했으며, 이를 통해 목표 달성 시간을 단축할 수 있었습니다. AI 도구는 반복적인 작업에 유용하지만, 복잡한 문제에는 개발자의 깊이 있는 지식과 경험이 필수적입니다. AI의 비효율적인 사용을 피하기 위한 엔지니어의 판단력 개발이 중요합니다. 또한, 오픈소스 기여를 통해 커뮤니티와 연결되는 가치를 강조하며, Rails를 API 전용 백엔드로 활용하고 별도의 프런트엔드 프레임워크를 사용하는 방식이 업그레이드 시 프런트엔드 관련 어려움을 줄이는 데 도움이 될 수 있음을 시사합니다.

관련 글들

Rails 8 업그레이드 성공 사례: 재작성 없이 레거시 Rails 앱 현대화하기

오래된 Rails 앱은 재작성 대신 점진적 업그레이드를 통해 Rails 8로 성공적으로 현대화할 수 있으며, 이는 비용과 위험을 줄이고 비즈니스 연속성을 보장합니다.

10/28 읽어보기 →

Ruby on Rails 애플리케이션 업그레이드: 단계별 가이드

Rails 업그레이드는 보안 강화, 성능 향상, 최신 기능 접근 및 기술 부채 감소를 위한 필수적인 투자입니다.

11/04 읽어보기 →

JuggleBee의 위대한 도약 — Rails 4 앱을 Rails 8로 재구축하기 (1부)

이 글은 2015년에 개발된 Ruby on Rails 4.2 기반의 JuggleBee 온라인 경매 플랫폼을 최신 Rails 8로 대규모 업그레이드한 과정을 상세히 설명합니다.

07/30 읽어보기 →

Rails 업그레이드 전략 가이드: 성공적인 전환을 위한 5단계 접근법

Rails 업그레이드는 보안 취약점, 성능 저하, 기술 부채 증가를 방지하며, 체계적인 5단계 전략을 통해 위험을 줄이고 성공적인 전환을 이룰 수 있습니다.

12/12 읽어보기 →

댓글 0

로그인이 필요합니다

댓글을 작성하거나 대화에 참여하려면 로그인이 필요합니다.

로그인 하러 가기

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!