React, 서버 중심 렌더링으로 전환 가속화!
CSR(Client Side Rendering) 중심의 기존 React 개발 방식은 프로젝트 규모 증가 시 번들 크기(Bundle Size)와 hydration 비용(Hydration Cost) 증가 문제 발생
Next.js App Router 도입 이후 Server Components, Streaming UI, Server Actions 등 서버 중심 렌더링 구조가 React 생태계 전반으로 확산됨
React Compiler는 useMemo, useCallback 같은 최적화 코드 직접 관리 부담을 줄여 개발 생산성 향상 및 렌더링 최적화(Rendering Optimization) 지원
Streaming UI는 준비된 UI부터 먼저 전달하고 필요한 부분을 점진적으로 렌더링하여 초기 로딩 성능(Initial Loading Performance) 개선
CSR의 한계와 서버 중심 렌더링으로의 전환 동기
기존 CSR(Client Side Rendering) 방식은 프로젝트 규모가 커질수록 클라이언트 측 JavaScript 번들 크기(Client-side JavaScript Bundle Size)가 증가하는 필연적인 문제를 안고 있었습니다. 이는 곧 초기 로딩 시간(Initial Loading Time) 지연과 hydration 비용(Hydration Cost) 증가로 이어져 사용자 경험을 저해하는 주요 원인이었습니다.
특히 모바일 환경에서는 이러한 성능 저하가 더욱 두드러졌습니다. React Query나 SWR 같은 라이브러리가 클라이언트 측 데이터 페칭 및 캐싱을 개선했지만, 근본적으로는 브라우저에서 JavaScript 실행 후 데이터를 요청하는 구조 자체의 한계를 완전히 극복하지는 못했습니다. 이러한 배경에서 서버 컴포넌트(Server Components)와 같은 서버 중심 렌더링 구조는 클라이언트 부담을 줄이고 초기 렌더링 성능(Initial Rendering Performance)을 획기적으로 개선할 수 있는 대안으로 부상했습니다.
Server Components와 데이터 페칭 방식의 변화
Server Components 기반 아키텍처는 기존의 useEffect 기반 데이터 Fetching 흐름과는 근본적으로 다른 접근 방식을 취합니다. 전통적인 방식에서는 컴포넌트가 렌더링된 후 `useEffect` 훅을 통해 데이터를 비동기적으로 가져오는 구조였으나, 이는 렌더링 이후 데이터 요청(Post-rendering Data Fetching)이라는 구조적 한계로 인해 초기 사용자 경험에 아쉬움을 남겼습니다.
반면, Server Components는 컴포넌트 렌더링 이전에 서버에서 직접 데이터를 가져오는 선(Server-first) 데이터 페칭을 지원합니다. 이를 통해 클라이언트에는 필요한 UI 정보만 전달하고, 서버 측에서 데이터 처리 로직을 집중시킴으로써 클라이언트로 전달되는 JavaScript 양을 최소화할 수 있습니다. 이는 초기 로딩 성능 향상뿐만 아니라, 클라이언트 측 상태 관리 복잡성(Client-side State Management Complexity) 감소에도 기여합니다.
Streaming UI를 통한 점진적 렌더링 구현
기존 SSR(Server Side Rendering)은 페이지 전체에 필요한 HTML을 서버에서 생성한 후 전달하는 방식이었습니다. 페이지 규모가 커질수록 이 과정에서 전체 페이지 렌더링 시간(Full Page Rendering Time)이 길어지고, 이후 클라이언트에서의 hydration 과정 부담도 커지는 문제가 있었습니다.
Streaming UI는 이러한 문제를 해결하기 위해 Suspense boundary를 활용하여 렌더링 흐름을 분리합니다. 준비된 UI 컴포넌트부터 먼저 사용자에게 전달하고, 나머지 부분은 점진적으로 로드하여 렌더링하는 방식입니다. 이를 통해 사용자는 페이지 전체가 준비될 때까지 기다릴 필요 없이 먼저 보이는 영역부터 상호작용할 수 있게 되어, 사용자 경험(User Experience)을 크게 개선할 수 있습니다. App Router 이후 이러한 점진적 렌더링(Incremental Rendering)** 기법이 실무에 점차 도입되고 있습니다.
React Compiler의 등장 배경과 역할
기존 React 개발에서는 성능 최적화를 위해 개발자가 직접 `useMemo`, `useCallback`, `memo`와 같은 훅을 사용하여 수동 메모이제이션(Manual Memoization)을 관리해야 했습니다. 이는 개발자에게 상당한 제어권을 부여했지만, 동시에 최적화 코드 관리의 복잡성(Complexity of Optimization Code Management)과 잠재적인 역효과를 야기하기도 했습니다.
Vue나 Svelte와 같은 경쟁 프레임워크들이 상대적으로 단순하고 쉬운 개발 경험을 강조하며 성장해 온 점, 그리고 서비스 규모 증가와 함께 UX에 대한 기대 수준 상승 및 모바일 성능 확보의 중요성 증대라는 시대적 요구에 부응하기 위해 React Compiler가 등장했습니다. React Compiler는 컴파일 타임(Compile Time)에 이러한 메모이제이션 및 렌더링 최적화 일부를 자동으로 처리하여, 개발자의 부담을 줄이고 일관된 성능 최적화(Consistent Performance Optimization)를 지원하는 것을 목표로 합니다.
