Rails 8이 드디어 공개되었으며, 꽤 흥미로운 방식으로 업계에 변화를 일으키고 있습니다. Rails 커뮤니티에서 활동 중이라면 "No PaaS Required(PaaS 불필요)"라는 슬로건을 들어보셨을 것입니다.
이는 다소 색다르지만 결코 놀랍지 않은 미션입니다. 이번 릴리스는 PaaS(Platform as a Service) 없이도 Rails 애플리케이션을 더 쉽게 배포할 수 있도록 만드는 데 초점을 맞추고 있습니다.
플랫폼은 개발자가 코드를 실행하는 기반 인프라를 직접 관리하지 않고도 앱을 웹에 올릴 수 있는 방법을 제공합니다. Heroku, Render, Fly, Railway 같은 서비스들이 Rails 커뮤니티에서 인기 있는 선택지였습니다. 개발자들은 플랫폼이 제공하는 편리한 개발 경험을 위해 추가 호스팅 비용을 감수해 왔지만, 이번 Rails 릴리스는 그 트레이드오프의 매력을 조금 덜어내려 하고 있습니다.
이 글에서는 이를 가능하게 만든 새롭고 개선된 기능들을 살펴보겠습니다. Solid Cache, Solid Queue, Solid Cable 같은 기능들은 Rails 8에 새로 도입되어 Redis 같은 기존 의존성을 제거해 줍니다. Kamal 2가 이제 기본 배포 도구가 되었고, 또 다른 젬(gem)의 필요성을 없애주는 새로운 인증 제너레이터도 추가되었습니다. 자세히 알아보겠습니다.
Rails 8에서 무엇이 바뀌었나?
Rails(특히 Rails 8)는 플랫폼 비용 없이 프로덕션 환경에 애플리케이션을 배포하는 일을 정말 쉽게 만들고자 합니다. 이번 릴리스의 대부분 변경 사항은 바로 이 미션을 중심으로 진행되었습니다. 즉, PaaS 없이 Rails 애플리케이션을 직접 호스팅하는 데 드는 수고를 줄이는 것이죠!
이제 각 주요 변경 사항을 하나씩 자세히 살펴보겠습니다.
Redis 없는 캐싱을 위한 Solid Cache
Rails는 웹 앱 성능에 필수적인 캐싱을 위해 ActiveSupport를 사용합니다. 전통적으로 개발자들은 빠르고 안정적이라는 이유로 캐싱에 Redis를 활용해 왔습니다.
Solid Cache는 한동안 전에 ActiveSupport용 Redis 프리 캐시 스토어로 출시되었습니다. 37signals 등에서 오랫동안 실제로 사용되어 왔으며, 이제 Rails가 이를 기본 선택지로 밀고 있습니다. RAM 대신 데이터베이스(기본값은 SQLite)를 캐시 스토어로 사용하기 때문에, 평소보다 훨씬 많은 데이터를 캐싱할 수 있다는 추가 장점도 있습니다. 데이터베이스 공간이 RAM보다 저렴하기 때문에, 데이터베이스 기반 캐싱이 RAM보다는 느리지만 더 많은 데이터를 더 오래 캐싱할 수 있어 오히려 일부 앱의 성능을 더 끌어올릴 수 있습니다.
이러한 성능 트레이드오프는 용도에 따라 적합할 수도, 그렇지 않을 수도 있습니다. 따라서 여전히 다른 캐시 스토어를 손쉽게 선택해 사용할 수 있습니다. 기본적으로 Redis나 Memcached의 필요성을 없애는 것은 Rails가 추구하는 "No PaaS Required" 미션에 한 걸음 더 가까워지는 결과입니다.
Redis 없는 백그라운드 작업을 위한 Solid Queue
Rails가 ActiveJob 라이브러리를 통해 백그라운드 작업을 더 쉽게 작성하고 실행할 수 있게 해준다는 것은 이미 잘 아실 겁니다. 캐싱과 마찬가지로 Rails는 ActiveJob을 구동할 백엔드를 자유롭게 선택할 수 있습니다. 많은 개발자들이 Sidekiq나 Good Job을 선호하지만, 오늘날 대부분의 옵션에는 두 가지 문제가 있습니다:
- 가져오고, 관리하고, 경우에 따라 비용까지 지불해야 하는 또 하나의 의존성이 됩니다
- 호스팅, 관리, 비용 지불이 필요한 Redis 같은 별도 서비스에 의존합니다
Solid Queue는 Redis에 의존하지 않고 백그라운드 작업을 관리함으로써 이 두 가지 문제를 동시에 해결합니다. Sidekiq나 Redis 기반의 다른 큐잉 솔루션을 사용 중이셨다면, Solid Queue는 복잡성을 줄이고 호스팅을 한결 수월하게 만들어 주는 훌륭한 대안입니다. Solid Cache와 마찬가지로 Solid Queue 역시 RAM 대신 애플리케이션의 데이터베이스를 사용해 백그라운드 작업을 추적합니다. 의존성을 줄이고 프로덕션 배포를 단순화하기 위해 Rails가 기본 제공하는 또 하나의 기능입니다.
Redis 없는 웹 소켓을 위한 Solid Cable
Rails는 Action Cable을 통해 개발자가 실시간 기능을 위해 웹 소켓을 손쉽게 활용할 수 있도록 지원합니다. 전통적으로 이 기능에는 Redis가 필요했습니다. 어디로 흘러가는지 짐작하고 계시겠죠!
'Solid' 테마를 이어가며, Rails 8은 또 다른 데이터베이스 기반 어댑터를 기본 탑재하고 있습니다. 반드시 사용할 필요는 없지만, 웹 소켓을 사용하면서 Redis 구성과 유지 관리 부담을 피하고 싶다면 훌륭한 퍼스트파티 옵션입니다. Solid Cache, Solid Queue와 함께 Solid Cable은 Redis 의존성을 제거하고 데이터베이스에 기대면서 PaaS 없이 Rails 애플리케이션을 배포하는 일을 더욱 쉽게 만듭니다.
더 쉬운 배포를 위한 Kamal 2
Rails 8의 다음 새 기능은 Solid 어댑터들과 성격이 상당히 다릅니다. 그럼에도 Kamal(특히 Kamal 2)은 자체 하드웨어로 애플리케이션을 배포하는 과정을 한층 간단하게 만들어 줍니다. Docker가 소프트웨어 모듈화를 쉽게 만들어 준 만큼, 언어에 관계없이 Docker 컨테이너를 배포해 주는 도구가 존재하는 것은 완전히 합리적인 일입니다.
솔직히 말하면, Kamal은 Rails 8의 다른 기능들과 함께 사용하더라도 대부분의 플랫폼이 제공하는 개발자 경험에는 아직 미치지 못합니다. 그럼에도 자체 웹 서버에 소프트웨어를 배포하는 일을 훨씬 쉽게 만들어 주며, Rails를 사용하지 않는 프로젝트에서도 활용할 수 있습니다! PaaS의 완전한 대체재는 아닐 수 있지만, 초기 설정만 완료하면 kamal deploy 명령 하나로 배포를 끝낼 수 있다는 점은 직접 배포하는 방식과 비교할 수 없는 큰 개선입니다.
인증 제너레이터(Devise 없이!)
사용자가 있는 Rails 앱을 만든다면 인증 기능이 필요할 것입니다. 지금까지 Rails는 인증을 프레임워크의 일부로 포함하지 않았습니다. 대신 커뮤니티에는 Rails 개발자의 인증 구현을 돕는 훌륭한 솔루션이 여럿 있었으며, 그중 가장 인기 있는 것이 Devise입니다.
Rails 8에는 인증 제너레이터(authentication generators)가 기본 포함되어 있습니다. 이것은 완전한 인증 시스템은 아니지만, 보안 같은 핵심 요소를 올바르게 구현하도록 도와줄 만큼은 충분합니다. 로그인 화면과 회원가입 흐름에 해당하는 뷰를 작성하는 것은 개발자의 몫이지만, 제너레이터가 세션, 비밀번호 인증, 심지어 비밀번호 재설정 이메일까지 처리해 줍니다. DHH는 인증기에서 뷰를 의도적으로 제외한 것은 모든 Rails 앱이 똑같은 모습을 갖는 것을 방지하기 위한 선택이라고 밝힌 바 있습니다.
새로운 제너레이터의 추가가 애플리케이션 배포를 직접적으로 단순화하지는 않지만, Rails가 너무 오랫동안 놓쳤던 웹 애플리케이션 개발의 공통 과제에 대한 퍼스트파티 솔루션을 제공했다는 점에서 의미가 큽니다.
에셋 파이프라인을 위한 Propshaft
Rails 8의 가장 큰 내부 변화 중 하나는 기본 에셋 파이프라인을 Sprockets에서 Propshaft로 전환한 것입니다. 필요하다면 Rails는 여전히 Sprockets를 지원하지만, 새로 생성되는 Rails 8 애플리케이션은 기본적으로 Propshaft를 사용합니다.
Propshaft는 에셋을 번들링하거나 압축(minify)하지 않는 방향에 대해 매우 확고한 철학을 갖고 있습니다. Rails가 PaaS를 불필요하게 만들려는 것처럼, 복잡한 빌드 파이프라인마저 불필요하게 만들려는 것입니다. Rails 8의 다른 많은 새 기본 설정들과 마찬가지로, Propshaft는 이전 버전의 Rails에서도 사용할 수 있고 Rails 8에서도 여전히 Sprockets를 선택할 수 있습니다!
SQLite와 Rails
SQLite는 엄밀히 말해 Rails의 일부는 아니지만, Rails는 이번 릴리스에서 SQLite에 더욱 깊이 기대고 있습니다. SQLite는 서버리스 데이터베이스 엔진으로 Postgres 같은 데이터베이스보다 훨씬 단순합니다. Rails 애플리케이션이 SQLite를 사용하면 웹 프로세스와 별도로 실행되는 데이터베이스 프로세스가 필요 없습니다. 물론 이는 웹 애플리케이션 배포를 더 단순하게 만들겠다는 Rails 8의 미션과 정확히 일치합니다.
Rails 8은 SQLite에 대한 퍼스트파티 지원과 함께 출시되어, 전통적인 데이터베이스 요구 사항을 충분히 처리하고 새로운 데이터베이스 기반 Solid 어댑터들도 안정적으로 지원합니다.
Rails 8의 모든 변화는 플랫폼의 필요성을 줄이기 위한 것
기존 Rails 앱을 Rails 8로 업그레이드한다면, 업그레이드를 위해 해야 할 일은 많지 않습니다. 제거된 기능은 몇 가지뿐이며, 대부분 이미 한동안 폐기 예정(deprecation) 통지가 있었던 Active Record 관련 항목들입니다. 물론 "Rails 8의 새로운 기본 설정"들을 활용해 배포를 단순화할 수도 있지만, 이는 선택 사항입니다.
Rails 8의 가장 큰 변화는 새로 시작하는 Rails 앱을 위한 것입니다! 새 Rails 앱에는 백그라운드 작업에 Solid Queue, 캐싱에 Solid Cache, 웹 소켓에 Solid Cable, 에셋 파이프라인에 Propshaft, 배포에 Kamal 2가 기본 적용됩니다.
Rails는 최근 복잡성을 압축하고 현대적인 웹 앱을 만들기 위한 풀 기능 프레임워크를 제공하겠다는 미션을 꾸준히 수행해 왔습니다. Rails 8은 웹 앱을 만드는 것을 넘어 웹 앱을 배포하는 영역까지 나아가면서도 기존 옵션과의 호환성을 그대로 유지합니다.
Rails 8의 기본 설정을 전부, 일부, 혹은 전혀 사용하지 않고도 선호하는 개발자 경험을 위해 플랫폼을 계속 이용할 수 있습니다. 하지만 이번 릴리스는 플랫폼 없이 인프라에 대한 소유권을 더 많이 가질 수 있는 선택지를 개발자에게 제공하는 것을 목표로 합니다.
이 글이 유익했다면 Honeybadger 뉴스레터를 구독하고 Ruby와 Rails 관련 뉴스와 튜토리얼을 받아보세요!