내가 Remix를 처음 들은곳은 내가 속한 React관련 정보를 공유하는 커뮤니티였다. 처음에 Remix를 들었을때는 음악을 리믹스 했다는 소리인가..? 라는 생각이 들었었는데 찾아보니 Next.js와 같은 프레임워크였다.
이때부터 Remix에 관심을 조금씩 가지게 되었는데, 어느날 커뮤니티에서 Next13 버전에서 부터 app router를 지원하면서 알수없는 많은 버그들이 발생했다는 이야기를 들었다.
그러면서부터 Remix에 대한 이야기가 슬금슬금 나오더니 본격적으로 내 호기심을 자극했다.
궁금하면 참지 못하는 성격이라 바로 찾아보았고 찾아본 내용들을 정말 간략하게 정리하고자 한다. 나도 대화에 끼고싶으니 Remix에 대해서 좀 찾아보았다.
첫번째로 Remix의 공식사이트에 접속을 해보았다. Remix의 철학과 핵심 가치 제안이 마중나와있었다.
Focused on web standards and modern web app UX, you’re simply going to build better websites.
Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience. People are gonna love using your stuff.
Remix는 웹 표준 중심의 철학을 바탕으로 개발자와 사용자 모두에게 이익이 되는 가치를 제안하고 있었다.
그러면 Remix와 Next.js의 핵심 철학의 차이는 뭘까?
Remix는 웹 표준과 플랫폼 API를 최대한 활용하는 것을 중시합니다. HTML form, HTTP 메서드, 브라우저 네이티브 기능을 적극 활용하여 JavaScript가 비활성화되어도 기본 기능이 작동하도록 설계되었습니다.
Next.js는 더 넓은 생태계와 다양한 렌더링 옵션을 제공하는 포괄적인 프레임워크입니다. 정적 사이트 생성부터 풀스택 애플리케이션까지 다양한 용도로 사용할 수 있습니다.
음... 위와 같다고 한다. 내가 관찰을 하면서 느낀게 있는데 이는 Remix와 Next.js의 차이는 Remix의 경우 보수적이고 Next는 진보적인 성향을 가졌다고 생각한다. 그 이유는 Remix의 Github과 Next.js의 Github을 보고 느꼇는데 버전과 이슈의 개수를 아래에 표로 정리했다.
| 2025.06.18 | 2021.09.15 | Issue | |
|---|---|---|---|
| Remix | v0.8.0 | v2.16.8 | 1 |
| Next.js | v11.1.3 | v15.4.0 | 2.4k |
Remix는 약 4년동안 메인버전이 v2가 증가한 반면에 Next.js는 4년동안 메인버전이 4만큼 Remix의 2배정도가 증가한것을 확인할 수 있었다. 내가 가장 충격을 받은 부분은 Remix의 이슈가 1개라는 것이었다...
그만큼 안정적이라는 뜻으로 나는 느껴졌고, 프레임워크를 이용해서 개발을 계속 해야하는 개발자의 입장에서는 안정적인 프레임워크라는게 정말 매력적으로 느껴졌다.
Remix 개발자들도 Next.js와의 차이가 무엇인지 많은 질문들을 받았다고 한다. 그래서 Remix 공식 블로그에서 공식적으로 개발한 예제 이커머스 사이트를 Remix로 클론하여 비교한 글을 작성했고 Remix와 Next를 비교 설명한 간단한 설명과 요약을 가져와보았다.
Remix 개발팀은 Remix와 Next.js를 비교하는 가장 공정한 방법은 Vercel 팀이 직접 작성한 Next.js 예제 앱을 사용하는 것이라고 생각했고, Vercel 팀이 직접 작성한 Next.js 예제 앱은 Vercel 팀이 여러분의 앱을 어떻게 빌드할지에 대한 의도를 반영해야 합니다. 또한 Vercel 팀이 가장 자랑스러워하는 기능들을 보여줄 수 있어야 합니다.
Next.js 예제 페이지의 Commerce 예제를 사용했고 이 예제에는 Remix 개발팀에서 좋아하는 몇가지 기능을 포함하고 있었다고 한다.
Remix 개발팀은 두 가지 버전을 만들었습니다.
최소 포트 - Next.js 대신 Remix에서 실행되도록 Next.js 코드를 복사/붙여넣기/조정했습니다. 이 코드는 Next.js 데모처럼 Vercel에 배포됩니다. 프레임워크를 제외한 모든 것이 동일하기 때문에 프레임워크 비교에 유용합니다.
재작성 - 두 프레임워크는 실제로 API가 크게 겹치지 않으며, Remix는 Next.js와는 다른 인프라에서 실행될 수 있습니다. Remix의 디자인을 실제로 시험해 보기 위해 예제를 직관적인 Remix로 재작성하고, 앱에 빠른 이미지 최적화 경로를 구축하여 100% Remix를 구현했습니다.
Remix 개발팀에서 테스트를 진행하였는데 결과는 ✅ Remix는 Next.js만큼 빠르다고 한다.

그리고 각 테스트가 빠른 이유를 설명해주었는데,
Next.js가 빠른 이유 : 홈페이지는 정적 사이트 생성 (SSG)을 사용합니다 getStaticProps. 빌드 시 Next.js는 Shopify에서 데이터를 가져와 페이지를 HTML 파일로 렌더링하여 공개 디렉터리에 저장합니다. 사이트가 배포되면 정적 파일은 단일 위치의 원본 서버에 접속하는 대신 Vercel의 CDN 외부에서 엣지 서버로 전송됩니다. 요청이 들어오면 CDN은 파일을 바로 제공합니다. 데이터 로딩 및 렌더링은 미리 완료되어 방문자가 다운로드 및 렌더링 비용을 지불하지 않아도 됩니다. 또한, CDN은 사용자와 가까운 전 세계("엣지")에 분산되어 있으므로 정적으로 생성된 문서에 대한 요청이 단일 원본 서버로 전송될 필요가 없습니다.
Remix 포트가 빠른 이유 : Remix는 SSG를 지원하지 않기 때문에 HTTP stale-while-revalidate 캐싱 지시어 (SWR, Vercel의 swr클라이언트 페칭 패키지와 혼동하지 마십시오)를 사용했습니다. 최종 결과는 동일합니다. (같은 CDN인 Vercel의 경우에도) 정적 문서가 엣지에 저장됩니다. 차이점은 문서가 엣지에 도달하는 방식입니다.
빌드/배포 시점에 모든 데이터를 가져와 페이지를 정적 문서로 렌더링하는 대신, 트래픽이 발생할 때 캐시가 준비됩니다. 문서는 캐시에서 제공되고 다음 방문자를 위해 백그라운드에서 재검증됩니다. SSG와 마찬가지로, 트래픽이 발생할 때는 방문자가 다운로드 및 렌더링 비용을 지불하지 않습니다. 캐시 미스에 대해 궁금하시다면 잠시 후에 자세히 설명하겠습니다.
SWR은 SSG의 훌륭한 대안입니다. Vercel에 배포하는 것의 또 다른 장점은 CDN이 이를 지원한다는 것입니다.
Remix 포팅이 Next.js만큼 빠르지 않은 이유가 궁금하실 겁니다. Remix에는 아직 내장된 이미지 최적화 기능이 없기 때문에 Next.js 앱으로 이미지를 전송했습니다. 🤫. 브라우저는 두 도메인 모두에 연결을 해야 하므로 이미지 로딩이 0.3초 지연됩니다( 네트워크 워터폴 에서 확인할 수 있습니다 ). 이미지가 자체 호스팅되었다면 다른 두 이미지와 마찬가지로 약 0.7초 안에 로딩되었을 것입니다.
Remix 재작성이 빠른 이유 : SSG 또는 SWR을 사용하여 엣지에서 문서를 캐싱하는 대신, 이 버전은 Redis 의 엣지에서 데이터를 캐싱합니다 . 실제로 Fly.io를 사용하여 엣지에서 애플리케이션도 실행합니다 . 마지막으로, 영구 볼륨 에 쓰는 빠른 이미지 최적화 리소스 경로를 제공합니다 . 사실상 자체 CDN이라고 할 수 있습니다. 😎
몇 년 전만 해도 이런 걸 만드는 게 어려웠을지 몰라도, 지난 몇 년 동안 서버 환경이 상당히 바뀌었고 점점 더 좋아지고 있습니다.
그렇다고 합니다. 블로그의 양이 생각보다 많아 더 많은 내용을 적고싶지만 저는 이정도로 글을 마치겠습니다. Remix 개발팀에서 내놓은 요약입니다.
부족하지만 이 정도면 Remix에 대해서 간략하게 뭐구나~ 정도는 설명이 되었을거 같습니다. Remix와 Next.js의 자세한 비교를 보고싶으면 Remix vs Next.js를 참고하시면 됩니다.