- Hardcover 팀은 Next.js 기반 구조의 성능 저하, 높은 비용, 개발 속도 저하 문제로 인해 Ruby on Rails + Inertia.js로 마이그레이션함
- SEO가 가능한 SSR 지원, 직접 DB 연결, React 유지라는 요건을 만족하기 위해 Inertia.js를 선택
- Vercel 및 Cloud Run에서의 예상치 못한 요금 폭증과 Next.js의 캐싱 불확실성이 결정적인 전환 계기였음
- Inertia.js는 Rails 백엔드와 React 프론트엔드를 연결하는 이상적인 방식으로, SSR과 캐시 관리가 쉬워짐
- 전환 이후 Google Pagespeed와 SEO 점수가 향상되며 사이트 방문 시간과 검색 노출이 증가함
전환 배경
- 초기에는 SEO와 SSR 지원이 가능한 Next.js를 선택하여 GraphQL API 기반의 아키텍처로 구축함
- 대부분의 데이터는 브라우저에서 클라이언트 측으로 요청하되, 정적 데이터는 서버에서 캐싱
- 시간이 지날수록 캐싱 부재로 API 요청 증가, 성능 저하 및 개발 환경 속도 저하 발생
Next.js에서 발생한 문제들
- App Router 전환 후에도 속도 향상 미미, Apollo POST 요청은 캐싱되지 않아 예상한 효과 없음
- Vercel 가격 정책 변경으로 월 요금이 $30 → $354로 급증함
- Cloud Run도 초기엔 저렴했지만, $524까지 증가
- Next.js 캐싱 구조 파악이 어려워, 효율적 관리 불가
- 개발 속도는 현저히 느려져 신규 인원 온보딩에 어려움 초래
Rails + Inertia.js 선택 이유
- SSR을 유지하면서 직접 DB에서 데이터 가져오기 원함
- React를 계속 사용하고 싶었고, Remix, react-rails, react_on_rails도 검토했지만 최종적으로 inertia-rails 채택
- Inertia.js는 프론트엔드 라우팅 없이 Rails 라우팅 사용 가능, SSR도 수월함
- 컨트롤러에서
inertia: '페이지명'으로 렌더링 처리하고, 캐싱은Rails.cache.fetch로 구현 - React 컴포넌트에서
usePage()로 props 수신
SSR 및 빌드 구조
- SSR을 위해
application.tsx에서hydrateRoot/createRoot분기 처리 - Vite를 독립 서버로 운영하며 개발 중 핫리로드 지원
- Docker와 Kamal을 통한 Rails + Vite 배포 자동화, staging과 production 구분
- 배포 시
make deploy명령어로 실행, asset host는 CloudFlare로 캐시 최적화
전환 효과
- 2025년 3월 18일 마이그레이션 배포 후 Google 검색 노출 증가, 페이지 속도 향상
- Total Blocking Time이 대폭 개선되며, Pagespeed 점수 상승
- 방문자 평균 체류 시간 3분 → 6분으로 상승 추세
- 트래픽은 유지되면서 회원 가입 수는 안정적으로 유지
향후 과제 및 개선점
- 공통 레이아웃 재사용 어려움, 각 페이지 완전 재렌더링 문제 존재
- SSR 디버깅 어려움, 환경 세팅이 복잡
- Inertia.js와 Rails 조합에 대한 문서 부족, Discord 커뮤니티를 통해 해결
- Suspense 대신 Inertia 방식에 적응 필요
- 현재는 Hasura를 계속 사용 중으로, Inertia의 form, flash 등 일부 기능은 미활용
결론 및 기대
- React + Rails를 자연스럽게 통합한 구조로 개발 생산성과 유지보수성 향상
- Inertia.js의 선택으로 속도, SSR, 타입 안정성을 동시에 확보함
- 앞으로 오픈소스화 및 기여자 확보를 계획 중