Remix에서 RSC가 없는 건 약점일까?

 

2025년 현재, React Server Components(RSC) 는 React 생태계에서 가장 뜨거운 기술 중 하나입니다.
Next.js는 App Router를 통해 RSC 기반의 개발 구조를 기본값으로 채택했고, 많은 개발자들이 이에 적응해가고 있습니다.

하지만, 풀스택 React 프레임워크의 또 다른 대표 주자 Remix는?
여전히 RSC를 지원하지 않습니다.
그렇다면 이건 기능적 공백이자 약점일까요? 아니면 철학의 차이일까요?

이 글은 그런 질문에 대해 기술적으로 차분하게 분석해보는 글입니다.

---

 

1. 🔍 RSC란 무엇인가?

React Server Components는 React가 공식적으로 도입한 서버에서 실행되는 컴포넌트 시스템입니다.

특징 요약:

• 브라우저에 JavaScript를 보내지 않고 HTML로만 렌더링
• 클라이언트 컴포넌트와 서버 컴포넌트를 구분 (.server.js, .client.js)
• DB 호출, API 연동을 서버 컴포넌트 내부에서 직접 수행 가능
• React hydration과 무관하게 초경량 클라이언트 렌더링 가능

RSC의 이점:

• JS 번들 사이즈 감소
• 네트워크 요청 감소
• 보안성 향상 (데이터 노출 없음)

---

 

2. Remix는 왜 RSC를 채택하지 않았을까?

Remix의 철학은 "웹 표준 기반 서버 중심 아키텍처" 입니다.

즉, React에 새로운 기능이 생겼다고 해도, 그것이 웹의 철학과 맞지 않으면 서둘러 통합하지 않는 태도를 유지해 왔습니다.

Remix는 RSC보다 먼저부터 다음과 같은 구조를 갖고 있었습니다:

기능 Remix에서의 기존 방식

서버에서 렌더링	loader() 함수에서 데이터 패칭 후 SSR
서버 전용 로직 분리	action()과 loader()로 분리된 구조
JS 번들 최소화	중첩 라우트 + 코드 스플리팅
낙관적 UI 처리	useFetcher()로 상태 처리와 UI 전환 분리

 

📌 즉, Remix는 RSC 없이도 유사한 목적(성능, 보안, 제어) 을 이미 다른 방식으로 달성하고 있었습니다.

---

 

3. RSC가 필요한 경우 vs Remix 방식으로 충분한 경우

사용 시나리오 RSC가 유리 Remix로 충분

복잡한 대시보드 UI, 부분 데이터 로딩	✅	✅ (with defer + fetcher)
클라이언트 JS 번들 최소화	✅	✅ (라우트 기반 코드 분할)
비동기 컴포넌트 로딩	✅	✅ (defer + Suspense)
데이터 보호 (API Key, DB 접근)	✅	✅ (loader 내부 처리)
마이크로 컴포넌트 단위로 서버 호출	✅	❌ (현재는 전체 라우트 단위 처리)
코드 재사용 (서버/클라이언트 통합 컴포넌트)	✅	❌ (Remix는 명시적 분리 추구)

 

📌 결론:
✔ RSC는 컴포넌트 단위의 서버 실행 컨셉
✔ Remix는 라우트 단위의 서버 실행 컨셉
이다.

---

 

4. Remix에 정말 RSC가 필요할까?

단도직입적으로 말하면:

Remix는 RSC 없이도 괜찮습니다.

Remix는 이미 다음 기능으로 많은 문제를 해결합니다:

• defer() + Suspense로 비동기 병렬 로딩
• useFetcher()로 클라이언트 요청-응답 처리
• loader()에서 DB/API 직접 접근 가능
• app/routes/*.tsx 구조로 중첩 UI 처리

 

단점은?

• 매우 세밀한 UI 단위의 서버 호출 → 불가능 or 복잡
• 컴포넌트가 DB 호출 → Remix에서는 불가능 (라우트 밖에서는 실행 불가)
• 클라이언트 번들 사이즈 극소화 → RSC보다 한계 있음

즉, RSC가 필요한 대형 SaaS/Dashboard에는 약점일 수 있습니다.
그러나 대부분의 비즈니스 웹앱/마케팅 사이트/블로그/커머스 등에서는 Remix의 설계가 오히려 더 명확하고 생산적입니다.

---

 

5. 향후 가능성: Remix도 RSC를 도입할까?

공식적으로 Remix 팀은 아직 RSC를 도입할 계획은 없다고 밝히고 있습니다.
다만, React 팀과 밀접한 관계를 유지하고 있고, 필요 시 점진적으로 흡수할 가능성은 열려 있습니다.

대신 Remix는 다음을 우선시합니다:

• 웹 표준 중심 설계 (Form, HTTP, Fetch)
• 명시적인 데이터 흐름 (loader, action)
• 플랫폼 유연성 (Cloudflare, Vercel, Express 등 어디든 배포 가능)

---

 

✅ 결론: RSC는 "필요한가?"가 아니라 "어떤 앱인가?"가 먼저다

RSC가 없는 것이 무조건 약점은 아닙니다.
오히려 “무거운 프레임워크가 되지 않기 위한 Remix의 전략적 선택”입니다.

요약 정리:

질문 Remix는… RSC 필요 여부

서버에서 데이터 가져올 수 있어?	✅ loader에서 가능	❌
클라이언트 JS 줄일 수 있어?	✅ 코드 스플리팅	❌
컴포넌트 단위로 서버 실행할 수 있어?	❌ 라우트 단위만 가능	✅
Suspense 기반 로딩 가능해?	✅ defer() + Suspense	❌
DB 쿼리를 UI 컴포넌트에서 바로 할 수 있어?	❌	✅
전체 구조가 예측 가능해?	✅ 명확한 라우팅 흐름	✅

---

 

Remix는 아직 RSC를 지원하지 않지만, 그 철학과 구조 자체가 다르며, 목표도 다릅니다.
“필요한 만큼 서버에서 실행”이 아니라,
“서버 중심으로 웹 전체를 설계하는 방식”이기 때문에 RSC는 Remix에 필수적이지 않습니다.

---

 

당신의 앱이 복잡한 대시보드인가요? 아니면 명확한 흐름의 웹 애플리케이션인가요?
정답은 프레임워크가 아니라, 문제의 성격에 있습니다.