최근 개선 사항
- 자동화된 루비 코어 릴리스: Hiroshi는 GitHub Actions를 활용하여 루비 코어 릴리스 워크플로우를 자동화함으로써 릴리스 시간을 4-6시간에서 1시간으로 단축하고, 2-3개월 주기의 안정적인 버전 출시를 가능하게 했습니다.
- Active Support JSON 최적화: John은 Active Support JSON의 성능을 최적화하여 불필요한 객체 순회 및 HTML 엔티티 이스케이프를 개선, Rails 8.1에서 상당한 성능 향상을 이끌어냈습니다.
- 개발 환경 및 성능: Aaron은 사전 컴파일된 Gem, LSP(Language Server Protocol) 지원, GC(Garbage Collector) 개선 등을 언급하며 전반적인 개발 환경의 발전을 강조했습니다. 루비 3.2+에 도입된 정규 표현식 엔진 개선 및 전역 타임아웃 기능은 특정 유형의 보안 취약점을 효과적으로 제거했습니다.
- Active Record 및 라우터 개선: Aaron은 Active Record 내부 속도 향상과 Rails 라우터 재작성 등이 위험했지만, 성공적으로 적용되어 사용자에게 긍정적인 영향을 미쳤다고 평가했습니다.
여전히 어려운 과제
- 개발 환경 설정의 복잡성: 신규 사용자들이 OpenSSL 컴파일 문제나 C 확장 설치 오류 등으로 인해 개발 환경 설정에 어려움을 겪는 것이 큰 문제로 지적되었습니다.
- Windows 지원: Hiroshi는 루비의 공식 Windows 패키지 부재와 MinGW 기반의 RubyInstaller 한계를 지적하며, 2025년까지 Windows에 대한 완전한 지원 확대를 통해 사용자 기반을 넓혀야 한다고 주장했습니다.
- 레거시 코드 및 변경의 어려움:
frozen_string_literal기본값 변경이나 Active Record의serialize컬럼 문제처럼 과거의 설계 결정이 현재의 개선을 어렵게 만드는 경우가 많습니다. 특히YAML.load를YAML.safe_load로 기본 변경한 사례는 많은 앱에 영향을 주었지만, 보안 강화를 위한 불가피한 조치였습니다.
유지보수 철학 및 커뮤니티 기여
- 엣지 버전 사용: 핵심 기여자들은 문제점을 조기에 발견하기 위해 루비 및 레일즈의 엣지(edge) 버전을 일상적으로 사용하고 있다고 밝혔습니다.
- CI/CD의 중요성: John은 대규모 CI 시스템의 중요성을 강조하며, 커뮤니티가 애플리케이션을 엣지 루비/레일즈에 대해 주기적으로 테스트하여 호환성 문제를 미리 보고해 줄 것을 요청했습니다.
- 성능 최적화의 현실: John은 마이크로 벤치마크보다는 실제 애플리케이션 프로파일링을 통한 전역적인 성능 개선에 집중하는 것이 중요하며, 불필요한 메모리 할당 최적화에 대한 과도한 집착은 지양해야 한다고 조언했습니다.
미래를 위한 제안
- 사전 컴파일된 Gem: C 확장 컴파일 문제를 해결하기 위해 사전 컴파일된 Gem 제공 시스템의 필요성이 제기되었습니다.
- 대화형
rails new:rails new명령어가 너무 많은 기본 기능을 포함하고 있어, 신규 사용자를 위해 대화형 옵션으로 필요한 기능만 선택할 수 있도록 하는 아이디어가 제시되었습니다. - Windows 지원 강화: Windows 파일 시스템 및 병렬 처리 지식을 가진 기여자들이 루비 프로젝트에 참여하여 Windows 지원을 강화할 것을 촉구했습니다.