Part 1: Next.js와 작별하고 Ruby on Rails 및 Inertia.js와 다시 사랑에 빠진 방법

Part 1: How We Fell Out of Love with Next.js and Back in Love with Ruby on Rails & Inertia.js

Unknown 2025년 03월 18일 https://hardcover.app/blog/part-1-how-we-fell-out-of-love-with-next-js-and-back-in-love-with-ruby-on-rails-inertia-js

3줄 요약

  • Hardcover는 Next.js 프론트엔드의 캐싱 문제, 예측 불가능한 비용, 느린 개발 속도로 인해 Ruby on Rails 및 Inertia.js로 마이그레이션을 결정했습니다.
  • Rails의 견고한 백엔드와 Inertia.js를 활용한 서버 사이드 렌더링, 직접적인 데이터베이스 접근 방식을 통해 성능과 비용 효율성을 개선했습니다.
  • 마이그레이션 결과 Google Pagespeed 점수 향상, 방문 시간 증가 등 긍정적인 성과를 얻었으며, 'Railsy React' 방식에 만족하며 개선 작업을 진행 중입니다.

Hardcover 팀은 웹 애플리케이션의 프론트엔드 기술 스택을 Next.js에서 Ruby on Rails와 Inertia.js 조합으로 성공적으로 마이그레이션한 경험을 공유합니다. 이 글은 'Alexandria 릴리스' 시리즈의 첫 번째 글로, 마이그레이션 결정의 배경과 Next.js 사용 중 겪었던 주요 문제점에 초점을 맞춥니다. Rails 개발자였던 저자는 Hardcover 시작 시 SEO를 위해 SSR이 가능한 Next.js를 선택했으나, 시간이 지남에 따라 여러 문제에 직면했습니다.

Next.js 사용 중 겪은 문제점

초기 Next.js Pages Router 아키텍처에서는 GraphQL API를 통해 사용자별 데이터를 클라이언트 사이드에서 가져왔습니다. 이는 프론트엔드를 단순하게 유지했지만, 사용자 데이터 캐싱을 어렵게 만들고 API 부하를 증가시켰습니다. 페이지 로딩 속도도 점차 느려졌습니다.

Next.js App Router로 마이그레이션하여 서버 사이드 데이터 페칭을 시도했으나, GraphQL POST 요청에 대한 캐싱이 제대로 작동하지 않아 성능 개선 효과가 미미했습니다. 또한, Next.js의 캐싱 메커니즘을 이해하고 디버깅하기 어려웠습니다.

클라우드 기반 서버리스 아키텍처(Vercel, Google Cloud Run)는 예측 불가능하고 빠르게 증가하는 호스팅 비용 문제를 야기했습니다. 몇 달 만에 비용이 10배 이상 증가하기도 했습니다.

로컬 개발 환경에서는 페이지 컴파일 시간이 최대 1분까지 소요되는 등 개발 속도가 현저히 느려져 팀 생산성을 저해했습니다. Next.js의 Turbopack 도입 시도도 성공하지 못했습니다.

GraphQL 대신 데이터베이스에 직접 접근하고 싶었으나, 서버리스 환경의 DB 연결 제한 문제를 해결하려면 고비용의 클라우드 DB 솔루션이 필요했습니다.

Ruby on Rails & Inertia.js로의 전환

Next.js의 문제점들이 지속되자, 팀은 SSR 유지, 직접적인 DB 접근, React 사용을 목표로 하는 대안을 모색했습니다. Remix를 고려했으나 학습 곡선을 감안하여 이미 백엔드로 사용 중인 Ruby on Rails에 집중했습니다. Rails에서 React를 연동하기 위한 react-rails, react_on_rails, inertia-rails 젬을 비교 검토한 결과, 성능, SSR, React 연동 측면에서 inertia-rails가 가장 적합하다고 판단했습니다. Inertia.js는 서버 사이드 렌더링과 클라이언트 사이드 라우팅을 결합하여 SPA처럼 작동하면서도 전통적인 서버 렌더링 방식의 장점을 제공합니다.

Rails + Inertia.js 아키텍처에서는 Rails 컨트롤러가 React 컴포넌트를 렌더링하며, inertia_share를 통해 전역 데이터를 공유합니다. Rails.cache.fetch를 활용하여 서버 사이드에서 효율적으로 데이터를 캐싱할 수 있게 되었습니다. React 컴포넌트는 usePage 훅을 통해 서버에서 전달된 props를 사용하며, Rails 라우터를 그대로 사용하므로 React Router가 필요 없습니다. 자산 관리는 Vite를 사용하며, 프로덕션 환경에서는 Kamal을 통해 Rails 및 Vite 서버를 배포합니다. types_from_serializers 젬은 Ruby 직렬화 객체로부터 TypeScript 타입을 자동 생성하여 개발 편의성을 높였습니다.

개선의 여지

이 설정에도 몇 가지 개선점은 있습니다. shared layouts 기능이 완벽하게 작동하지 않아 페이지 전환 시 전체 컴포넌트가 다시 렌더링되는 문제, 프로덕션 SSR 디버깅의 어려움, Inertia.js 및 Rails/Inertia 통합 문서의 부족 등이 있습니다. 하지만 Discord 커뮤니티의 도움으로 대부분 해결 가능했습니다.

2025년 3월 18일 Rails + Inertia.js로 마이그레이션 배포 후 즉각적인 긍정적 효과가 나타났습니다. Google Pagespeed 점수가 크게 향상되었고, Google 검색 노출이 증가했습니다. 사이트의 안정성과 사용성이 개선되면서 방문 시간도 두 배 가까이 증가했습니다. 가입자 수는 안정적으로 유지되었습니다. 친숙한 Ruby 및 Rails 도구를 사용하여 React 프론트엔드를 구축하는 'Railsy React' 방식에 만족하며, 앞으로 버그 수정, 페이지 최적화, 마케팅 강화, 오픈 소스화 등을 진행할 계획입니다. 다음 글에서는 인프라를 클라우드에서 서버로 옮긴 경험에 대해 자세히 다룰 예정입니다.