레거시 Rails 모놀리스 업그레이드: 기술을 넘어선 정치적 의지와 전략

Rocky Mountain Ruby 2025 - Upgrading Rails: The Non-Technical Parts by Max VelDink

작성자
jeff
발행일
2025년 10월 27일
원문 보기
www.youtube.com

핵심 요약

  • 1 Rails 업그레이드는 단순한 기술적 과제가 아닌, 팀의 주인의식, 명확한 계획 수립, 그리고 조직 내 정치적 의지 확보가 성공의 핵심입니다.
  • 2 업그레이드 계획은 Gemfile 의존성 감사, Rails 가이드 활용, 구체적인 마일스톤 날짜 설정, 배포 및 롤백 플레이북, 그리고 팀별 테스트 계획 수집을 포함해야 합니다.
  • 3 성공적인 배포는 적극적으로 축하하고 다음 마일스톤을 즉시 계획하며, 실패 시에는 원인을 분석하고 신속하게 재시도하여 모멘텀을 유지해야 합니다.

도입

많은 개발자가 새로운 회사에 합류하여 '위대한 모놀리스'(레거시 Rails 애플리케이션)를 접할 때, 구식 Rails 버전으로 인한 `NoMethodError`와 같은 문제에 직면합니다. Rails 6.0, 6.1, 심지어 7.1과 같은 버전들이 이미 지원 종료(End-of-Life, EOL)되었거나 곧 될 예정임을 인지하지 못하는 경우가 많습니다. 이러한 EOL 버전의 사용은 보안 취약점 노출, 신규 기능 부재, 그리고 잠재적인 강제 업그레이드 상황을 초래하며, 이는 비즈니스에 심각한 위험을 안겨줍니다. 하지만 현실에서는 '이전에 실패했다', '아무도 코드베이스를 모른다', '기능 개발이 우선이다'와 같은 이유로 업그레이드 시도가 좌절되는 경우가 빈번합니다. 본 강연은 이러한 기술적 부채 문제를 해결하기 위한 기술을 넘어선 조직적, 정치적 전략에 초점을 맞춥니다.

Rails 업그레이드 성공을 위한 핵심 전략

1. 주인의식 확보 (Ownership)

Rails 업그레이드의 첫걸음은 문제에 대한 주인의식을 갖는 것입니다. 종종 팀들은 이 책임을 DevOps나 인프라 팀에 전가하려 하지만, 만약 강제 업그레이드(예: CVE 발생 시)로 인해 본인 팀이 직접적인 영향을 받는다면, 이는 해당 팀의 문제이며 최우선 과제로 다루어져야 합니다. DevOps 팀은 애플리케이션 컨텍스트가 부족하고 리소스가 제한적인 경우가 많으므로, 그들에게 모든 책임을 넘기는 것은 실패를 자초하는 행위입니다. 주인의식을 갖고 업그레이드를 주도하는 것은 애플리케이션의 다양한 영역에 대한 깊이 있는 이해와 빠른 경력 성장의 기회를 제공합니다.

2. 체계적인 계획 수립 (Crafting the Plan)

업그레이드 계획은 단순히 코드를 변경하는 것을 넘어선 체계적인 접근이 필요합니다.

  • 의존성 감사: Gemfile을 면밀히 검토하고, 다음 Rails 마이너 버전으로 로컬에서 업그레이드를 시도하여 발생하는 오류들을 목록화합니다. 실패하는 Gem들을 하나씩 해결하며 의존성 목록을 정리합니다.

  • 기능적 레이아웃: Rails 공식 가이드의 업그레이드 섹션을 활용하여 주요 비권장(deprecation) 사항들을 파악하고, 코드베이스에서 해당 패턴들을 검색합니다. 프로덕션 환경에서의 데이터베이스 마이그레이션(예: Active Storage 변경 사항) 및 배포 전략(예: 듀얼 부트)을 미리 고려해야 합니다.

  • 계획 문서화: 무질서한 목록을 바탕으로 구체적인 ‘물리적 날짜’(분기 단위가 아닌)가 명시된 마일스톤을 설정합니다. 목표는 현실적이면서도 도전적으로 설정하고, 초기 계획은 유연하게 조율할 수 있음을 명심합니다. 후반 마일스톤일수록 세부 사항은 줄여나가고, 반복적인(iterative) 방식으로 채워나갑니다.

  • 세부 구현 지양: 계획에는 ‘Faraday 다음 버전으로 업그레이드’ 또는 ‘비권장 호출 사이트 제거’와 같이 ‘무엇을 할 것인가’에 초점을 맞추고, ‘어떻게 할 것인가’와 같은 구현 세부 사항은 나중에 해결합니다.

  • 부록 추가: 배포 플레이북(인프라 팀과 협력하여 롤백 계획 및 데이터베이스 작업 포함)과 테스트 플랜(다른 팀의 핵심 기능 테스트 경로 수집)을 추가하여 만반의 준비를 합니다.

  • AI 활용: AI 도구를 활용하여 Rails 또는 Ruby 버전 간의 차이점을 분석하거나, 코드 경로를 식별하고, 심지어 초기 Pull Request를 생성하는 데 도움을 받을 수 있습니다.

3. 계획 공유 및 실행 (Socialization and Execution)

수립된 계획은 조직 내에서 공개적으로 접근 가능하도록(예: Confluence, Google Docs) 공유하고, 팀원 및 리더십과 논의하여 피드백을 반영해야 합니다. 업그레이드를 통해 얻을 수 있는 이점(예: Ruby 3.1의 해시 생략 문법, 새로운 라이브러리 사용 가능)을 강조하여 팀의 동기를 부여합니다. 이 작업은 다른 기능 개발 프로젝트와 동일하게 프로젝트 관리 도구(Jira, Kanban 등)를 사용하여 관리합니다. 때로는 반복적이고 지루한 작업이 필요할 수 있으므로, 팀원들에게 적절한 격려와 보상(예: 피자 파티)이 중요합니다.

4. 테스트 및 배포 (Testing and Deployment)

다른 팀들과 협력하여 테스트 및 배포를 진행합니다. 배포 날짜에 대해 확고한 태도를 유지하고, ‘X주 내에 배포될 예정이니 문제가 있다면 알려달라’는 식으로 대화를 재구성하여 다른 팀에 책임감을 부여합니다. 인프라 파트너와 함께 플레이북을 기반으로 게임 데이를 진행하고, 롤백 계획을 포함하여 실제와 유사한 환경에서 배포를 시뮬레이션합니다. 각 팀으로부터 핵심 기능 테스트 계획을 수집하여 문서화하고, 향후 업그레이드 시 다시 활용할 수 있도록 합니다.

5. 성공과 실패 (Success and Failure)

  • 성공: 업그레이드가 성공하면 크게 축하하고(팀 예산 내에서), 리더십에 성과를 알립니다. 그리고 즉시 다음 마일스톤을 계획하여 모멘텀을 이어갑니다. 초기 업그레이드 후에는 새로운 기능을 많이 사용하지 않았기 때문에 다음 버전으로의 전환이 더 쉬울 수 있습니다.

  • 실패: 실패하더라도 포기하지 않고, 무엇이 잘못되었는지 원인을 파악하는 데 집중합니다. 계획을 재평가하고, 필요한 경우 수정하여 ‘매우 신속하게’ 다시 시도해야 합니다. 하루 만에 재시도하는 것도 좋은 방법입니다.

결론

Rails 업그레이드라는 거대한 과제 앞에서 좌절감을 느끼거나, 반대로 새로운 가능성에 대한 동기 부여를 받을 수 있습니다. 하지만 '최악의 경우 무엇이 일어날까?'라는 질문에 답하는 것은 두려움을 극복하는 데 도움이 됩니다. 설령 리더십이 당장 리소스를 배정하지 않더라도, 계획 자체를 수립해두는 것은 매우 중요합니다. 이는 치명적인 CVE(보안 취약점)가 발생하여 강제 업그레이드가 필요할 때, 미리 준비된 계획이 당신을 '영웅'으로 만들 수 있기 때문입니다. 현재의 직급이나 리더십과의 관계와 상관없이, 이 과정에 참여하는 것만으로도 Rails 5.2에 머물러 있는 것보다는 훨씬 발전한 상태입니다. Rails 공식 가이드, Fast Ruby의 호환성 테이블, Next Rails와 같은 도구들을 활용하여 이 여정을 시작할 수 있습니다. 적극적인 주인의식과 체계적인 접근으로 Rails 업그레이드의 성공을 이끌어낼 수 있습니다.

관련 글들

레거시에서 최신으로: Zendesk가 모놀리스를 Rails 8.0으로 업그레이드한 방법

Zendesk의 Ruby Platform Core 팀은 대규모 Rails 모놀리스를 대상으로 '영구적 업그레이드' 전략을 성공적으로 구현했습니다.

03/17 읽어보기 →

Rails 기본값: 업그레이드된 앱 속 시한폭탄 해체하기

Rails 업그레이드 시 `config.load_defaults` 설정과 `new_framework_defaults_*.rb` 파일 관리가 필수적이며, 이를 간과할 경우 잠재적 문제 발생 가능성이 높습니다.

07/24 읽어보기 →

Ruby 프로젝트 의존성 관리를 위한 효과적인 전략 및 도구

Ruby 프로젝트의 의존성 관리는 보안 취약점 및 호환성 문제 예방에 필수적입니다.

01/13 읽어보기 →

Ruby 개발자의 장기적인 기술 성장 전략: 통합적 접근 방식

코드 학습은 단순히 읽는 것을 넘어, 콘솔과 문서 활용을 통해 문법과 어휘를 체화하고 능동적으로 탐구하는 통합적 접근 방식이 중요합니다.

07/24 읽어보기 →

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

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