Astro 인수, Remix 3 재설계 — 2026 메타프레임워크 판이 뒤집혔다
Cloudflare의 Astro 인수, Remix 3 batteries-included 재설계, SvelteKit Svelte 5 runes 엔터프라이즈 채택까지. 2026년 4월 메타프레임워크 3강의 판이 다시 짜였다. 직접 써보고 정리한 비교.
On this page (11)
2026년 4월 · AI 소식 · GoCodeLab
Astro vs SvelteKit vs Remix — 2026 메타프레임워크 3강 재대결
2026년 들어 메타프레임워크 판이 또 한 번 흔들렸다. Cloudflare가 1월에 Astro를 인수했다. 3월에는 Astro 6 정식 버전이 나왔다. 같은 시기 Remix 팀은 React 자체를 버리고 Preact 포크 기반의 Remix 3을 만들겠다고 했다.
Next.js만 쓰던 사람도 한 번쯤은 들여다볼 만한 변화다. Astro는 콘텐츠 사이트에서 점유율을 빠르게 끌어올리고 있다. SvelteKit은 Svelte 5 Runes로 반응성을 다시 설계했다. Remix는 두 갈래로 갈라졌다. 안정화된 React Router v7과 실험적인 Remix 3이다.
셋 다 써본 입장에서 정리한다. 어디에 어떤 프레임워크가 맞는지, 2026년 4월 기준 뭐가 새로 바뀌었는지, 인디 개발자가 지금 무얼 골라야 하는지 직접 따져봤다.
- Astro 6 (2026-03-10) — Cloudflare workerd 기반 dev server, Live Content Collections 안정화, 빌트인 Fonts API.
- SvelteKit — Svelte 5 Runes 안정 단계. 점진적 도입 가능. npm 주간 다운로드 약 168만.
- React Router v7 — 기존 Remix v2 사용자가 가야 할 길. 안정 단계. 주간 5,400만 다운로드.
- Remix 3 — React 버리고 Preact 포크. 2026 초 목표였으나 4월 기준 preview 미공개.
- 콘텐츠 사이트 = Astro, 풀스택 SaaS = SvelteKit 또는 RR v7, 실험 = Remix 3.
목차
귀찮은개발자 시리즈
SaaS를 7일 만에 만들었다 — 메타프레임워크 선택부터 배포까지
Next.js 16으로 피드백 SaaS를 7일 만에 끝낸 기록. 메타프레임워크를 고르는 기준과 실전 트레이드오프를 정리했다.
EP.04 읽기 →3강이 다시 갈라진 이유
2025년만 해도 메타프레임워크 시장 구도는 단순했다. Next.js가 React 생태계 최강자, SvelteKit이 새 강자, Astro가 콘텐츠 사이트의 다크호스, Remix가 그 중간 어디였다. 1년 사이 이 그림이 뒤집혔다.
2026년 1월 16일 Cloudflare가 Astro Technology Company를 인수했다. 라이선스는 MIT 그대로다. 어댑터 구조도 변경 없다. 다만 Cloudflare workerd 런타임이 Astro 개발 서버에 통째로 들어왔다. 출처는 Cloudflare 공식 블로그(blog.cloudflare.com/astro-joins-cloudflare)와 Astro 6 발표문(astro.build/blog/astro-6)이다.
Remix 팀은 정반대 방향으로 움직였다. 2025년 5월 Remix 3 계획을 발표하면서 React를 버리겠다고 못 박았다. Preact 포크 위에 batteries-included, zero-dependencies, bundler-free 프레임워크를 만들겠다는 선언이었다. 한편 React Router v7이 2024년 11월에 안정 출시되면서 기존 Remix v2 사용자가 갈 길은 정해졌다. Remix는 사실상 두 갈래로 쪼개졌다.
SvelteKit은 조용한 길을 갔다. Svelte 5가 2024년 10월에 나왔고 1년 반이 지난 지금 Runes는 안정 단계다. Svelte 4 문법도 그대로 동작한다. 강제 마이그레이션이 없다. 큰 사고 없이 점유율을 천천히 올리는 패턴이다.
전체 비교 — 한눈에 보기
2026년 4월 기준으로 셋을 같은 표에 놓고 본다. 같은 항목으로 비교해야 차이가 보인다.
| 항목 | Astro 6 | SvelteKit | React Router v7 / Remix 3 |
|---|---|---|---|
| 기반 라이브러리 | UI 무관 (React/Vue/Svelte) | Svelte 5 | React 19 / Preact 포크 |
| 2026 안정 버전 | Astro 6 (2026-03-10) | SvelteKit 2 + Svelte 5 | RR v7 안정 / Remix 3 미공개 |
| 기본 렌더링 | 정적 + Islands | SSR + Hydration | SSR + Hydration |
| 라우팅 | 파일 기반 | 파일 기반 | 파일 기반 (framework mode) |
| 반응성 모델 | Islands별로 다름 | Runes ($state, $derived) | React useState/use |
| npm 주간 다운로드 | 235만 (astro) | 168만 (@sveltejs/kit) | 5,467만 (react-router) |
| 강한 영역 | 콘텐츠·블로그·docs | 인터랙티브 앱·SaaS | React 생태계 풀스택 |
| 인수/소속 | Cloudflare (2026-01) | Vercel 후원 | Shopify (Remix Run) |
npm 다운로드 수치는 2026-04-22~28 기준이다(api.npmjs.org). React Router 5,400만은 라우팅 라이브러리 단일 패키지로 셈해서 다른 두 메타프레임워크와 단순 비교가 어렵다. 풀스택 모드 사용량은 그중 일부다.
Astro 6 — Cloudflare가 인수한 다음에 뭐가 바뀌었나
Astro 6 정식 버전이 2026년 3월 10일에 나왔다. 가장 큰 변화는 개발 서버다. Vite의 새 Environment API 위에 다시 짰다. Cloudflare workerd, Bun, Deno 같은 비-Node 런타임을 개발 단계에서부터 정확히 시뮬레이션한다. 비유하면 운전면허 시험을 시뮬레이터가 아니라 실제 도로에서 보는 셈이다. "dev에서는 됐는데 prod에서 안 된다"는 사고가 줄어든다.
@astrojs/cloudflare 어댑터는 모든 단계에서 workerd를 돌린다. 개발, 사전 렌더링, 프로덕션이 같은 런타임이다. KV, D1, R2, Durable Objects를 로컬에서 그대로 테스트할 수 있다. Cloudflare 인수 후 첫 메이저 버전인 만큼 통합 깊이가 한 단계 깊어졌다. 다른 어댑터(Vercel, Netlify, AWS)는 그대로다. MIT 라이선스 그대로라 호스팅 종속 우려는 없다.
기능적으로는 빌트인 Fonts API와 Live Content Collections가 핵심이다. Fonts API는 폰트 최적화, 자체 호스팅, 폴백 생성, 프리로드 링크를 설정 한 줄로 처리한다. Live Content Collections는 외부 CMS 콘텐츠를 빌드 없이 요청 시점에 가져온다. 빌드 타임 콘텐츠와 런타임 콘텐츠를 같은 API로 다룰 수 있다. 5에서 베타였는데 6에서 안정화됐다.
Server Islands는 Astro 5에서 도입된 server:defer 지시어 그대로다. 6 발표문에서 추가 언급이 없었지만 기능은 그대로 유지된다. 정적 HTML 안에 동적 섬을 비동기로 끼워 넣는 패턴이다. 비유하면 빵 위에 토핑을 따로 구워서 마지막에 얹는 것과 같다. CMS에서 가져오는 일부 데이터만 따로 렌더링하고 나머지는 정적으로 미리 빌드한다.
SvelteKit — Svelte 5 Runes 1년 후 평가
Svelte 5가 2024년 10월에 나왔다. Runes가 핵심이었다. $state, $derived, $effect, $props 같은 명시적 반응성 프리미티브로 기존의 암묵적 반응성을 대체했다. 기존 Svelte 4의 let, $: 문법이 컴파일러 매직에 가까웠다면 Runes는 함수 호출처럼 보이는 명시적 호출이다.
1년 반이 지난 지금 가장 칭찬받는 부분은 호환성이다. Svelte 4 문법을 강제로 못 쓰게 만들지 않았다. 새 컴포넌트만 Runes로 짜고 기존 컴포넌트는 그대로 두는 점진적 도입이 가능하다. 마이그레이션 데드라인이 없다. 큰 코드베이스가 한 번에 갈아엎을 필요가 없다는 점이 채택 결정에서 생각보다 큰 변수다.
- $state — 반응형 상태. let count = $state(0)으로 선언한다.
- $derived — 파생값. doubled = $derived(count * 2).
- $effect — 사이드 이펙트. useEffect 비슷하나 의존성 배열이 자동이다.
- $props — 컴포넌트 props 선언. let { name } = $props().
SvelteKit 2는 SvelteKit 자체 스토어($page, $navigating, $updated)를 Runes 호환 API($app/state)로 옮겼다. 옛 import도 그대로 동작한다. 새 코드는 새 API를 쓰면 된다. 어댑터 구조는 안정적이다. Vercel, Netlify, Cloudflare, Node, 정적 출력까지 다 지원한다. New York Times의 인터랙티브 요소처럼 까다로운 시각화 페이지에 SvelteKit을 쓰는 사례가 확인된다.
npm 주간 다운로드는 약 168만(@sveltejs/kit, 2026-04-22~28 기준, api.npmjs.org)이다. Astro의 235만보다 적지만 Svelte 같은 비-React 생태계 메타프레임워크 기준으로 의미 있는 규모다. State of JS 2025에서도 reactive framework sentiment 1위 자리를 유지했다.
Remix는 둘로 쪼개졌다 — RR v7와 Remix 3
Remix 이야기를 하기 전에 정리할 게 있다. "Remix v3"라는 이름이 두 가지를 가리킨다. 2024년 시점에 Remix 팀이 "v3 계획이었던 것"은 결국 React Router v7으로 출시됐다. Remix v2와 React Router가 합쳐졌다. 이건 안정 단계다. 출처는 remix.run/blog/merging-remix-and-react-router.
React Router v7은 framework mode를 켜면 풀스택 메타프레임워크가 된다. Vite 기반 컴파일러, SSR, 번들 분할, 타입 안전성, HMR이 다 들어 있다. Remix v2 future flag를 다 켜둔 사용자라면 dependency 업데이트 정도로 마이그레이션이 끝난다. React 19와도 호환된다. npm 주간 다운로드는 5,467만(react-router, 2026-04-22~28 기준)인데 이 수치는 라우팅 라이브러리로 쓰는 비중이 압도적으로 크다는 점을 감안해야 한다.
Remix 3은 그와 별개의 새 프로젝트다. 2025년 5월 26일 발표 기준 React를 완전히 버리고 Preact 포크 위에 다시 짓는다. 출처는 infoq.com/news/2025/08/remix-run-v3-drops-react. batteries-included, zero-dependencies, bundler-free, Web API 직접 사용, LLM 친화적 구조가 핵심 원칙이다. React의 라이프사이클을 통째로 들어내고 명령형 모델로 갔다.
2026년 4월 기준 Remix 3은 아직 preview 미공개다. 초기 목표는 2026년 초였지만 여러 자료에서 imminent로만 표기되고 정식 alpha/beta 일정은 공개되지 않았다. 출처는 blog.logrocket.com/remix-3-ditched-react. 인디 개발자가 지금 Remix 3을 프로덕션 후보로 둘 수는 없다. 실험 프로젝트나 사이드 프로젝트로 미리 살펴보는 정도가 현실적이다.
데이터 로딩 방식 비교
메타프레임워크 차이가 가장 크게 드러나는 곳이 데이터 로딩이다. 셋이 접근법이 다르다.
| 방식 | Astro | SvelteKit | React Router v7 |
|---|---|---|---|
| 정적 데이터 | Content Collections | +page.ts (prerender) | loader (prerender) |
| SSR 데이터 | .astro frontmatter | +page.server.ts load | loader 함수 |
| 동적 부분 렌더 | Server Islands (server:defer) | streamed promise in load | defer / Await |
| 폼 액션 | Actions (베타) | form actions | action 함수 |
| 실시간/스트리밍 | Live Content Collections | streamed load | defer + Suspense |
Astro는 정적 + 부분 동적이 강하다. SvelteKit과 RR v7는 SSR 풀스택 형태가 기본이다. 폼 액션 같은 mutation 패턴은 SvelteKit과 RR v7가 거의 같은 모양이다. 둘 다 progressive enhancement를 지원한다. JavaScript가 꺼져 있어도 폼이 동작하는 구조다.
용도별 추천
상황별로 어떤 프레임워크가 맞는지 정리했다. 한 줄 답이 아니라 실제 트레이드오프를 본다.
| 상황 | 추천 | 이유 |
|---|---|---|
| 기술 블로그·docs | Astro 6 | 정적 + Markdown + Islands가 가장 빠르다 |
| 콘텐츠 + 가벼운 인터랙션 | Astro 6 + Svelte Islands | 정적 페이지 안에 Svelte로 인터랙션만 따로 |
| 인터랙티브 SaaS 대시보드 | SvelteKit | Runes 반응성과 작은 번들 크기 |
| React 생태계 풀스택 | React Router v7 | Remix v2 안정성 + React 19 호환 |
| Cloudflare 풀스택 (KV, D1) | Astro 6 | workerd dev server, 바인딩 로컬 테스트 |
| 실험적 사이드 프로젝트 | Remix 3 (출시 시) | bundler-free, Web API 학습용 |
| 데이터 시각화 사이트 | SvelteKit | 반응성 모델이 차트 라이브러리에 잘 맞는다 |
| Next.js 마이그레이션 후보 | RR v7 또는 Astro | React 코드 재사용 가능 여부로 결정 |
조합 활용법 — 모노레포 멀티프레임워크
하나만 골라 쓸 필요는 없다. 도메인을 나눠 다른 프레임워크를 쓰는 멀티프레임워크 패턴이 늘고 있다. 마케팅 사이트는 Astro, 본 SaaS 앱은 SvelteKit, 실험 프로젝트는 Remix 3 식이다. 한 모노레포 안에 함께 둔다.
# 모노레포 구조 예시 (pnpm workspaces)
my-saas/
├── apps/
│ ├── marketing/ # Astro 6 — 랜딩, 블로그, docs
│ ├── app/ # SvelteKit — 본 SaaS 대시보드
│ └── api/ # Hono on Cloudflare Workers
├── packages/
│ ├── ui/ # 공유 디자인 토큰 (CSS variables)
│ ├── db/ # Drizzle ORM 스키마 + 클라이언트
│ └── config/ # tsconfig, eslint 공유
└── pnpm-workspace.yaml
# 라우팅 분리 (Cloudflare Workers Routes)
gocodelab.com/ → apps/marketing # Astro
gocodelab.com/app/ → apps/app # SvelteKit
gocodelab.com/api/ → apps/api # Hono
디자인 토큰만 CSS 변수로 공유하면 UI 컴포넌트는 각 프레임워크에서 따로 만들어도 된다. 폰트, 컬러, 간격이 통일돼 있으면 사용자는 같은 사이트로 인식한다. 다만 인증 세션 공유는 별도 설계가 필요하다. 도메인 쿠키 또는 JWT 기반 토큰을 두 앱이 같이 읽는 구조여야 한다.
팀 사이즈가 작다면 풀스택 하나로 가는 게 단순하다. 1인 인디라면 SvelteKit이나 React Router v7 하나로 끝내는 편이 운영 비용이 낮다. 트래픽이 분리되거나 콘텐츠 양이 많아지는 단계에서 멀티프레임워크를 도입해도 늦지 않다. 80% 먼저 빠르게 만들고, 나머지 20%는 실제 문제가 생겼을 때 고치는 식이 좋다.
인디 개발자가 지금 골라야 할 것
정리하면 이렇게 갈린다. 콘텐츠 중심이면 Astro 6. 인터랙티브 SaaS면 SvelteKit. React 코드 자산이 있다면 React Router v7. Remix 3은 출시 후 평가다. Next.js를 쓰고 있다면 일단 RR v7 마이그레이션부터 보면 된다. Remix v2 future flag를 다 켜둔 코드라면 의존성 업데이트로 끝난다.
한 가지 분명한 건 더 이상 단일 정답이 없다는 점이다. Next.js가 모든 답이던 시절은 지났다. 콘텐츠 사이트에서 Astro의 페이지 무게가 압도적으로 가볍다. 인터랙션에서는 Svelte 5 Runes의 반응성이 React보다 직관적인 경우가 많다. 직접 둘 다 만들어 보고 골라라. 한 시간 안에 hello world를 띄울 수 있는 도구들이라 비교 비용이 작다.
자주 묻는 질문
Q. Cloudflare가 Astro를 인수하면 다른 호스팅에서는 못 쓰나?
쓸 수 있다. Astro는 MIT 라이선스 그대로 유지된다. 어댑터 구조도 변경 없다. Vercel, Netlify, AWS 모두 지금까지 쓰던 어댑터로 그대로 배포 가능하다. 달라진 건 Cloudflare 어댑터의 통합도가 더 높아진 정도다.
Q. Remix 3와 React Router v7는 같은 프로젝트인가?
아니다. 완전히 다르다. React Router v7은 기존 Remix v2가 합쳐진 결과물이고 이미 안정 단계다. Remix 3은 React 자체를 버리고 Preact 포크 위에 새로 짓는 별도 프로젝트다. 2026년 4월 기준 아직 preview도 공개되지 않았다.
Q. Svelte 5 Runes를 꼭 써야 하나?
지금 당장은 아니다. Svelte 5는 기존 Svelte 4 컴포넌트 문법을 그대로 지원한다. 강제 마이그레이션 일정도 없다. 새 컴포넌트만 Runes로 짜고 기존 코드는 천천히 옮기는 점진적 도입이 권장된다.
Q. 콘텐츠 사이트인데 Next.js에서 Astro로 갈아탈 가치가 있나?
정적 비중이 높으면 그렇다. 블로그, 문서 사이트, 마케팅 페이지처럼 빌드 타임에 결정되는 콘텐츠가 80% 이상이면 Astro가 빠르고 단순하다. 인터랙션이 필요한 부분만 Islands로 React, Vue, Svelte를 골라 쓸 수 있다. SaaS처럼 인증·실시간이 핵심이면 Astro보다 SvelteKit 또는 React Router v7이 낫다.
Q. 셋 다 써야 한다면 어떻게 조합하나?
용도가 분리된다. 마케팅·블로그·docs는 Astro, 본 SaaS 앱은 SvelteKit 또는 React Router v7, 실험적 사이드 프로젝트로 Remix 3을 시도해보는 흐름이 자연스럽다. 한 모노레포 안에서도 도메인별로 다른 프레임워크를 쓰는 멀티프레임워크 패턴이 늘고 있다.
마무리
2026년 메타프레임워크 판은 단일 정답에서 용도별 분화로 가고 있다. Astro는 Cloudflare에 들어가서 콘텐츠와 엣지 컴퓨팅에 더 깊이 박혔다. SvelteKit은 Runes로 반응성을 명시적으로 만들었고 점진적 도입 경로를 열어뒀다. Remix는 안정 노선(RR v7)과 실험 노선(Remix 3)으로 분리됐다.
고를 때 기준은 단순하다. 무엇을 만드는지, 기존 코드 자산이 무엇인지 먼저 본다. 그 다음에 호스팅 환경, 팀 규모, 마이그레이션 비용을 본다. 셋 다 한 시간이면 hello world가 뜨는 도구다. 직접 만들어 보고 결정하는 비용이 가장 싸다. 운영 단계의 잘못된 선택보다 백 배 작다.
- Astro 6 발표 — astro.build/blog/astro-6/
- Cloudflare Astro 인수 — blog.cloudflare.com/astro-joins-cloudflare/
- Remix v3 React 결별 — infoq.com/news/2025/08/remix-run-v3-drops-react
- Remix와 React Router 합병 — remix.run/blog/merging-remix-and-react-router
- Svelte 5 Runes 소개 — svelte.dev/blog/runes
- npm 다운로드 데이터 — api.npmjs.org (2026-04-22~28 기준)
귀찮은개발자 시리즈
매일 한 가지 자동화, 매일 한 줄 덜어낸다
CLAUDE.md 자동화부터 SaaS 7일 개발기, 결제·보안·위젯 SDK까지. 1인 인디 개발자의 실전 자동화 기록.
시리즈 전체 보기 →이 글은 2026년 4월 30일 기준 정보다.
기재된 npm 다운로드 수치, 버전 정보는 시점에 따라 달라질 수 있다. 본 글은 광고가 아니며 직접 사용·확인한 내용을 정리한 것이다.