Next.js에 열광했던 프론트엔드 엔지니어들
Next.js는 React 기반 풀스택 프레임워크로, 2016년 출시 이후 프론트엔드 개발자들의 사랑을 받아왔습니다.
서버 사이드 렌더링(SSR), 정럭 사이트 생성(SSG), API 라우트 등 다양한 기능을 통해 React 개발에 최적화된 경험을 제공했습니다. Vercel의 배포 플랫폼과의 시너지는 Next.js를 선택하게 만드는 중요한 요소입니다.
하지만, Next.js를 사용하면서 시간이 지날수록 다음과 같은 문제들이 드러나기 시작했습니다.
커져가는 Next.js의 단점
1. 복잡해진 데이터 패칭
Next.js에서는 getStaticProps, getServerSideProps등 데이터 패칭 메서드가 구분되어 있습니다.
이는 유연성을 제공하지만, 개발자에게는 오히려 혼란을 줍니다.
클라이언트 컴포넌트와 서버 컴포넌트 간의 데이터 흐름이 복잡해지면서 점점 코드 유지보수가 어려워졌습니다.
2. 서버와 클라이언트의 역할 분리 모호
Next.js는 서버와 클라이언트 로직이 섞이기 쉬운 구조를 가지고 있습니다.
어떤 코드가 서버에서 실행되는지, 클라이언트에서 실행되는지 헷갈릴 때가 많습니다.
React Server Components(RSC)가 도입되며 이 문제를 해결하려고 했지만, 아직도 개발자들에게는 진입장벽으로 작용하고 있습니다.
3. 복잡한 라우티팅과 설정
파일 기반 라이팅 시스템은 간단해 보이지만, 커스텀 설정이 필요할 때 복잡성이 급증합니다.
미들웨어 설정, 리다이렉션, 국제화(i18n) 등을 설정하다보면 의도와는 달리 많은 시간을 소모하게 되고,
빠른 개발과 배포가 잘 되지 않는 현실을 느끼게 됩니다.
틈새를 치고 나온 Remix의 장점
1. 데이터와 UI의 일관된 흐름
Remix는 데이터 로딩과 액션(폼 제출)이 표준 HTML 폼과 RESTful 패턴에 기반을 두고 있습니다.
로더(loader)와 액션(action)이라는 개념을 통해 서버와 클라이언트 사이의 데이터 흐름이 자연스럽고 지관적입니다.
서버에서 데이터를 가져오고, 폼을 제출하여 데이터를 처리하는 패턴이 명확하게 구분되어 있습니다.
2. 최적화된 UX
Remix는 페이지 전환 시 데이터 페칭과 트랜지션을 함께 처리하여 사용자가 체감하는 속도를 극대화했습니다.
데이터 로딩 상태, 에러 핸들링까지 자연스럽게 처리되며, React의 Suspense와 결합하여 더욱 부드러운 사용자 경험을 제공합니다.
3. 서버 우선 접근(Server-first approach)
Remix는 서버에서 데이터를 먼저 처리하고, 그 결과를 클라이언트에 전달하는 흐름을 기본으로 합니다.
서버와 클라이언트가 명확하게 분리되며, 서버사이트 로직을 자연스럽게 작성할 수 있습니다.
이는 서버 친화적인 애플리케이션 개발에 큰 도움이 됩니다.
4. 복잡한 설정에서 해방
Remix는 파일 기반 라우팅이지만, 데이터와 액션이 각 파일에 깔끔하게 묶여 있어 설정이 직관적이다.
라우트마다 loader와 action이 붙어 있어 유지보수와 확장성이 뛰어나다.
Next.js에서 Remix로 넘어가야하는 이유
1. 단순하고 명확한 데이터 흐름: getStaticProps, getServerSideProps로 인한 혼란에서 벗어나자.
2. 서버와 클라이언트의 자연스러운 역할 분리: 서버에서 데이터를 처리하고 클라이언트는 화면에 집중하게 만들자.
3. 더 나은 사용자 경험: 로딩 상태와 에러 핸들링이 자연스러운 Remix의 데이터 로딩 전략을 경험해 보자.
4. 생산성 향상: 복잡한 설정과 마주칠 시간이 줄어들고, 비즈니스 로직에 더 집중할 수 있다.
Next.js는 당연히 너무 훌륭한 프레임워크지만, 현재 프론트엔드 개발이 추구하는 방향성에 맞춰 스타트업은 Remix로의 전환을 고려해볼 시점이다. 데이터 흐름의 명확성, 서버 중심 개발, UX 최적화라는 Remix의 강점은 Next.js를 경험해본 개발자라면, 누구나 공감할 수 있는 내용일 것이다.
Next.js를 잘하면 분명 취업에 유리할 것이고, 큰 스타트업에 들어가기 유리할 것입니다.
하지만 진정한 메이커라면, 생산성을 포기할 수 있겠는가.
마지막으로, 최근 Remix 7와 React Route의 병합 소식은 Remix가 더 근본에 가까운 프레임워크임을 말해준다고 생각합니다.
Merging Remix and React Router
We've been building a bridge from React Router to Remix, and we made it so good that we're going to merge the two projects.
remix.run
병합소식은 따로 또 정리해보겠습니다.
앞으로 Remix의 발전이 기대되는 이유입니다.
NextJS vs RemixJS: How do they compare?
https://blog.radialcode.com/category/web/nextjs-vs-remixjs-how-do-they-compare
'소프트웨어 > ReactRemix' 카테고리의 다른 글
| Next.js vs Remix 2025 완전 비교 - 선택이 고민될때 (2) | 2025.03.30 |
|---|---|
| Remix와 React Router의 병합: FE 개발자들이 주목해야하는 이유 (3) | 2025.03.29 |
| 처음시작하는 프론트엔드 개발자를 위한 "한 입 크기로 잘라먹는" 시리즈 (0) | 2025.02.12 |
| 초보 프론트엔드 개발 입문자를 위한 React 가이드, 첫발 내딛기 (1) | 2025.02.11 |
| React 초보개발자를 위한 VScode 필수 플러그인 4가지 (1) | 2025.02.11 |