Rails 8은 과감한 전제로 출시되었습니다: 바로 “PaaS 불필요(No PaaS Required)”입니다. 클라우드 플랫폼 비용이 점점 더 부담스러워지면서, Ruby on Rails는 외부 인프라 의존성을 줄이는 방향으로 나아가고 있습니다. 그 목표는 개발자가 더 적은 서비스 의존성만으로 애플리케이션을 배포하고 운영할 수 있도록 하는 것입니다.
전통적으로 Rails 앱을 인터넷에 배포하려면 데이터베이스 서버(PostgreSQL 등)를 프로비저닝하고, 캐싱·백그라운드 작업·웹소켓 처리를 위한 Redis 같은 추가 서비스까지 준비해야 했습니다. 하지만 Rails 8의 핵심 팀은 이런 관행을 바꾸고자 했습니다. 캐싱, 잡 큐(job queue), 실시간 웹소켓 기능을 프레임워크 자체에 내장하고, 모두 애플리케이션의 데이터베이스만으로 구동되도록 설계한 것입니다.
이 글에서는 “Solid 트리펙타(Solid Trifecta)”라고 불리는 세 가지 핵심 요소부터 시작해, Rails 8이 어떻게 “No PaaS Required”라는 약속을 실현하는지 살펴보겠습니다.
Solid Cache: Redis 없이 캐싱하기
Rails 8에서 가장 마음에 드는 추가 기능 중 하나는 Solid Cache입니다. Redis나 Memcached 없이도 캐시 저장소 역할을 대신해 주는 새로운 캐시 스토어입니다. Solid Cache는 인메모리 키-값 저장소 대신 데이터베이스에 캐시 데이터를 영구 저장합니다. 디스크에 캐시 객체를 보관하는 것이 기술적으로는 RAM보다 느리지만, 그만한 장점이 분명히 존재합니다.
첫째, 디스크 스토리지는 메모리보다 훨씬 저렴하고 용량도 넉넉합니다. Solid Cache를 사용하면 RAM 한계에 걱정하지 않고 훨씬 많은 데이터를 캐싱하고 오래 보관할 수 있습니다. 실제로 Basecamp와 HEY를 만든 37signals는 Redis에서 Solid Cache로 전환한 후 캐시 용량을 10TB 이상으로 확장했고, 그 결과 P95 렌더링 시간을 무려 50% 단축했습니다.
물론 메모리에서 읽는 것이 디스크보다 빠른 것은 사실입니다. 하지만 Basecamp의 사례처럼, 더 많은 데이터를 캐싱할 수 있다는 이점이 속도 손실을 충분히 상쇄하는 경우가 많습니다.
기본적으로 Rails 8은 SQLite를 백엔드로 하는 Solid Cache를 사용합니다. 물론 Rails의 관례대로 언제든 Redis 같은 다른 옵션을 선택할 수 있습니다. 다만 이 기본값을 그대로 사용하면 Redis 같은 별도의 운영 서비스를 유지할 필요 없이 캐싱을 구현할 수 있어, 인프라 관리 부담이 크게 줄어듭니다.
Solid Queue: Redis 없이 백그라운드 작업 처리하기
“Solid” 트리펙타의 두 번째 주인공은 Solid Queue입니다. Redis는 물론 Sidekiq 같은 별도의 잡 시스템 의존성 없이 백그라운드 작업을 처리하는 새로운 Active Job 백엔드입니다.
많은 Rails 개발자들이 백그라운드 작업을 위해 Redis에 의존하는 Sidekiq이나 Delayed Job 같은 젬(gem)을 사용해 왔습니다. Solid Queue는 Rails가 이런 추가 의존성의 필요성 자체를 없애려는 시도입니다. 잡 큐잉을 애플리케이션의 데이터베이스에 통합했기 때문에, 별도의 메모리 솔루션이나 큐잉 시스템이 필요하지 않습니다.
Solid Queue는 작업을 데이터베이스 테이블의 레코드로 저장하고, 효율적인 SQL 기능을 활용해 잡 큐를 관리합니다. 단일 서버 환경이라면 Puma 플러그인 형태로 Rails 웹 프로세스에 내장해서 실행할 수도 있고, 별도의 워커 프로세스로 실행할 수도 있습니다.
Rails 코어 팀 멤버는 이렇게 말했습니다. 목표는 개발자가 “Rails를 설치하고 데이터베이스만 설정하면, 일곱 가지 서로 다른 젬과 시스템을 관리할 필요 없이 백그라운드 작업 처리를 바로 사용할 수 있게 하는 것”이라고요.
Solid Cable: 웹소켓도 Redis 없이 구현하기
Rails 8의 “Redis 불필요” 퍼즐 세 번째 조각은 Solid Cable입니다. 예상하셨겠지만, 이것 역시 데이터베이스를 활용하는 새로운 Action Cable 어댑터입니다. 과거 Action Cable은 여러 Rails 프로세스 간에 메시지를 브로드캐스트하려면 반드시 Redis 서버가 필요했습니다. Solid Cache 덕분에 이제는 추가 서비스를 띄우지 않고도 Action Cable의 실시간 웹소켓 기능을 활용해 채팅, 알림 같은 라이브 업데이트 기능을 구현할 수 있습니다.
이쯤 되면 “Solid” 트리펙타의 장점이 명확해집니다. Redis 서버나 다른 pub/sub 서비스를 구축하지 않고도 장기 데이터 캐싱, 고처리량 백그라운드 작업 처리, 실시간 기능 배포가 모두 가능해집니다. 이 세 가지 기능은 소규모 앱의 복잡도를 낮춰주고(단 하나의 데이터베이스로 모든 것을 단일 호스트에서 실행 가능), 배포를 쉽게 만들자는 Rails 8의 철학과도 잘 맞아떨어집니다.
Redis 의존성 제거, 정말 그렇게 큰 의미가 있을까?
Rails 8의 상당 부분이 Redis 의존성 제거에 초점을 맞추고 있다는 점을 보면, 이것이 실제로 얼마나 중요한지 궁금해질 수 있습니다. 답은 여러분의 상황에 따라 다르지만, 분명히 눈여겨볼 만한 이점들이 있습니다.
움직이는 부품이 적다는 것은 곧 복잡성 감소를 의미합니다. 특히 배포 과정에서 그렇습니다. 추가되는 서비스(Redis, 별도의 백그라운드 잡 러너 등) 하나하나가 잠재적인 고장 지점이자 스케일링 대상입니다. 데이터베이스를 더 많이 활용하면 운영이 단순해집니다. Redis 메모리를 모니터링하거나 Redis 인스턴스가 항상 살아있는지 확인할 필요가 없어지는 것입니다.
많은 Rails 개발자들이 익숙한 시나리오가 있습니다. 개발 환경에서는 캐시 서버를 띄우지 않거나 다른 큐 어댑터를 사용하지만, 운영 환경에서는 Redis/Sidekiq를 사용하는 경우입니다. 새로운 Rails 기본값을 사용하면 개발과 운영에서 동일한 설정으로 실행할 수 있어 예기치 못한 문제를 최소화할 수 있습니다. 스택이 더욱 자족적(self-contained)이 되어, 운영 환경을 위한 특별한 설정 없이도 “바로 작동”합니다.
서버와 애드온이 줄어들면 호스팅 비용도 절감됩니다. 규모가 커져도 인프라 통합에는 일정 수준의 비용 효율성이 따릅니다. 데이터베이스 공간은 메모리보다 저렴하니까요!
중요한 점은, Rails가 Redis나 다른 서비스 사용을 막는 것이 아니라 선택 사항으로 만들었다는 것입니다. 내장된 Solid 어댑터로 시작하고, 필요해지면 그때 Redis나 다른 솔루션을 도입하면 됩니다.
SQLite: 데이터베이스 프로세스조차 필요 없이
Rails 8의 또 다른 의미 있는 변화는 SQLite를 실제 운영 환경에서 사용할 수 있는 데이터베이스로 받아들인 것입니다. Rails의 SQLite 어댑터에 수많은 개선이 이루어진 덕분입니다. 앱이 운영 환경에서 SQLite를 사용할 수 있다면 별도의 데이터베이스 서버가 필요 없습니다. 대신 데이터는 앱 프로세스 자체가 관리하는 디스크상의 단순한 파일에 저장됩니다. Rails 8의 SQLite 개선으로 이 방식이 과거보다 훨씬 현실적이 되었습니다.
SQLite를 사용하면 배포가 한결 간단해집니다. 서버에 MySQL이나 PostgreSQL을 설치·관리할 필요가 없고, 관리형 DB 서비스를 사용하며 비용을 지불할 필요도 없습니다. 그저 Rails 앱이 읽고 쓰는 하나의 파일일 뿐입니다.
물론 SQLite로 감당하기 어려운 규모가 되면, 나중에 완전한 기능을 갖춘 데이터베이스 시스템으로 마이그레이션할 수 있습니다. Rails 코어 팀은 기본값을 가벼운 옵션으로 변경했을 뿐인데, 이것이 “No PaaS” 내러티브와 완벽하게 어울립니다.
Kamal 2: 배포까지 간편하게
Rails 8은 운영 환경에서 앱을 실행하는 것을 단순화했습니다. 그렇다면 앱을 운영 환경으로 배포하는 문제는 어떨까요? Kamal 2의 출시가 그 질문에 대한 답입니다.
Kamal은 Docker 컨테이너를 통해 최소한의 수고로 어떤 Linux 서버에든 앱을 배포하는 오케스트레이션 도구입니다. 앱 이미지를 빌드하고, 푸시하고, 서버에서 실행하는 과정을 자동화해 줍니다. 서버 설정을 일일이 손으로 작성할 필요가 없습니다.
몇 가지 설정 후 kamal setup 명령어 한 번이면, Kamal이 깨끗한 Linux 머신에 Docker 컨테이너 실행에 필요한 것들을 자동으로 프로비저닝합니다.
이후 배포는 kamal deploy 명령 하나면 끝입니다. 최신 이미지를 가져와 기존 컨테이너를 새 컨테이너로 교체하며, 무중단(zero-downtime) 배포가 이루어집니다.
Kamal 2는 어떤 Linux 호스트에서든 PaaS와 유사한 배포 경험을 제공하는 것을 목표로 합니다. 명령어 하나로 어떤 서버든 여러분의 앱을 실행하는 Rails 서버로 탈바꿈시킬 수 있습니다. 초기 설정은 다소 번거로울 수 있지만, 이후 배포는 훨씬 수월해집니다. Heroku 같은 플랫폼에 푸시하는 것만큼 셀프 호스팅을 편리하게 만들려는 큰 진전입니다.
'No PaaS'는 좋은 선택일까?
Rails 8이 정말로 플랫폼을 과거의 유물로 만들었을까요? 그리고 중소 규모 팀이 셀프 호스팅으로 실제로 비용을 절약할 수 있을까요?
저는 최근 Kamal을 사용해 VPS에 개인 프로젝트를 배포해 보았는데, 다소 답답한 경험이었습니다. 일단 동작하게 만든 후에는 배포가 비교적 매끄러웠지만, 초기 설정 과정은 결코 순탄하지 않았습니다. 게다가 이 프로젝트를 확장해야 할 때가 온다면 해야 할 일이 산더미처럼 남아 있습니다.
따라서 저에게 답은 “아니다 — Rails 8은 플랫폼의 가치를 대체하지 못한다”입니다. 저는 앱 개발에 집중하고, Heroku 같은 플랫폼이 인프라를 대신 처리하게 두는 편이 낫습니다.
솔로 개발자와 소규모 팀은 규모의 경제를 좇기보다 사용자에게 집중하는 것이 더 큰 이익입니다. 호스팅, 배포, 스케일링에서 탁월한 성능을 발휘하는 플랫폼에 이런 업무를 아웃소싱하고, 고객이 사랑하는 제품을 만드는 데 집중하면 안 될까요?
물론 팀과 애플리케이션이 성장하면 플랫폼의 가격이 부담스러워질 수 있습니다. 어느 시점이 되면 SRE와 운영 업무를 전담할 시간과 인력을 두는 것이 합리적이 되는데, 그때 Kamal(그리고 훌륭한 Rails 8 기본값들)은 그 전환을 훨씬 쉽게 만들어 주는 큰 걸음입니다.
마치며
Rails 8은 셀프 호스팅과 플랫폼 사용 사이의 격차를 좁혔지만, 솔직히 “PaaS 불필요”라고 주장하기에는 아직 부족합니다. 다만 분명한 것은, Rails 8이 개발자 경험을 크게 희생하지 않고도 PaaS 대신 VPS를 선택할 수 있게 만들었다는 점입니다. 다만 저는 이것이 플랫폼 킬러라고 생각하지 않습니다.
Solid Cache, Solid Queue, Solid Cable은 웹 앱에 필수였던 서드파티 요구사항들을 퍼스트파티 지원으로 끌어왔고, 이 점은 고맙게 생각합니다. 애플리케이션을 시작하는 데 가볍지만 강력한 기본값이 있다는 것은 훌륭한 일이고, 더 좋은 점은 이것들이 많은 인프라를 필요로 하지 않는다는 것입니다. 셀프 호스팅을 선택한다면 Kamal이 배포 부담을 덜어줄 것입니다.
플랫폼 사용 여부와 관계없이, 에러와 장애에 신속하게 대응하고 고객에게 훌륭한 사용자 경험을 제공하려면 모니터링이 필수입니다. Honeybadger에 가입하여 Rails 애플리케이션의 건강 상태와 성능에 대한 실시간 인사이트를 확인해 보세요.