Remix 3 Beta, React를 버리고 웹 표준 중심으로 전환
Remix 3 Beta가 공개되면서 프레임워크의 방향이 크게 바뀌었다. 가장 눈에 띄는 변화는 React 의존성을 완전히 제거한 것이다. 대신 포크된 Preact를 프론트엔드 렌더링 레이어로 채택했으며, 전체 아키텍처를 웹 플랫폼 표준(Web Platform Primitives) 중심으로 재설계했다. 이는 단순한 라이브러리 교체가 아니라 프레임워크 철학 자체의 전환이다. React 생태계에 의존하던 기존 Remix의 정체성을 버리고, 브라우저와 서버가 공유하는 표준 API 위에서 동작하는 풀스택 프레임워크로 거듭나겠다는 선언이다.
백엔드 개발자 관점에서 주목할 부분은 서버 소유권(Server Ownership of the Request Lifecycle) 개념이다. Remix 3는 요청의 생명주기 전체를 서버가 주도하는 구조를 명시적으로 강조한다. 클라이언트 중심으로 상태를 관리하던 기존 SPA 패러다임과 달리, 서버가 라우트 해석부터 응답 생성까지 전 과정을 제어한다. 이는 Java 백엔드 개발자들이 익숙한 서버 사이드 렌더링의 철학과 맥락이 닿아 있다.
단일 구조로 통합된 라우트·핸들러·UI
Remix 3의 핵심 아키텍처 변화는 라우트, 요청 핸들러, UI 컴포넌트를 하나의 단일 구조로 통합한 것이다. 기존에는 이 세 가지가 느슨하게 연결되어 있었다면, 이제는 파일 하나가 세 역할을 동시에 수행하는 방식으로 구성된다.
// Remix 3 스타일 라우트 모듈 예시
export async function loader({ request }: LoaderArgs) {
const data = await fetchFromDB(request);
return Response.json(data);
}
export default function Page({ loaderData }) {
return <main>{loaderData.title}</main>;
}
이 구조는 Spring MVC의 Controller-View 분리 방식과는 다르지만, 하나의 관심사(라우트 단위)를 완전히 캡슐화한다는 점에서 오히려 응집도가 높다. 서버 함수와 UI가 동일 파일에 위치하기 때문에, 데이터 흐름을 추적하기 쉽고 타입 안전성도 확보하기 유리하다. 풀스택 Java 팀이 Node.js 기반 BFF(Backend For Frontend)를 구성할 때 이런 구조는 유지보수 비용을 줄이는 데 실질적인 이점이 있다.
Remix 2에서의 마이그레이션, 단순하지 않다
Remix 팀은 Remix 2에서 3로의 마이그레이션이 단순하지 않음을 명확히 밝히고 있다. 기존 애플리케이션의 상당 부분을 수정해야 하며, React 기반으로 작성된 컴포넌트와 훅은 Preact 환경에 맞게 재검토가 필요하다. React 전용 라이브러리에 의존하는 코드가 많을수록 마이그레이션 비용은 커진다.
실무적으로는 현재 Remix 2를 사용 중인 팀이라면 섣불리 업그레이드를 서두를 이유는 없다. Beta 단계인 만큼 API 안정성도 아직 보장되지 않는다. 반면 새로운 프로젝트에서 웹 표준 기반의 풀스택 프레임워크를 검토 중이라면, Remix 3의 방향성은 충분히 살펴볼 가치가 있다. 특히 React 생태계 의존도를 줄이고 싶은 팀, 또는 서버 중심 아키텍처를 선호하는 팀에게 매력적인 선택지가 될 수 있다.
정리
- Remix 3는 React를 제거하고 포크된 Preact와 웹 플랫폼 표준을 기반으로 재설계된 풀스택 프레임워크다.
- 라우트·요청 핸들러·UI를 단일 모듈로 통합하고, 서버가 요청 생명주기 전체를 소유하는 아키텍처를 지향한다.
- Remix 2에서의 마이그레이션은 상당한 코드 변경이 수반되므로, 신규 프로젝트에서의 도입 검토가 현실적이다.