다양한 렌더링 전략에 빠져보자. 근데 이제 Next.js를 곁들인.

Jihan·2024년 11월 11일

들어가며

저는 올해 들어 처음으로 Next.js를 사용하기 시작했습니다. 여기서 기존의 SPA 형태의 React App이 아닌, 페이지 단위 혹은 컴포넌트 단위로 렌더링 전략을 구체화해서 성능을 극대화하는 렌더링 최적화 기법을 활용할 수 있다는 점이 가장 큰 차이점으로 느껴졌는데요.

항상 렌더링 전략에 관련해서 찾아볼 때면 이 렌더링이라는 단어가 의미하는 프로세스가 정확히 어떤 범위인지 알기가 쉽지 않았습니다. 어디서는 DOM을 화면에 그리는 과정을 렌더링이라 그러고, 어디서는 JavaScript로 HTML을 만들어서 serve하는 과정을 렌더링이라 그럽니다.

오늘은 이렇게 다양한 맥락에서 렌더링이 무슨 의미를 가지는지, 어쩌다가 이렇게 다양한 맥락이 생겼는지, 또 프레임워크들이 어떤 다양한 렌더링 전략을 구상하는지, 특히 Next.js에서의 렌더링 전략을 메인으로 정리해보는 시간을 한 번 가져보려 합니다.

렌더링이 무엇인가요?: 다양한 맥락에서의 렌더링

프론트엔드 엔지니어들은 렌더링이라는 단어를 지겹도록 많이 듣습니다. 저의 분야는 웹 프론트엔드 영역이지만, 어떤 영역에서든 소프트웨어의 프론트엔드는 Domain Data가 View/UI Data로 전환되는 일종의 커다란 어댑터를 뜻하며, 그 과정을 가장 간략하게 표현할 수 있는 단어가 렌더링이기 때문이죠.

다시 말해 렌더링은 프론트엔드 영역에서 가장 핵심적인 요소 중 하나인 것입니다.

프론트엔드를 공부하다 보면, 다양한 맥락에서 렌더링이라는 단어를 접하게 됩니다. 프레임워크의 렌더링 기법, 브라우저의 렌더링 과정, 컴포넌트의 리렌더링 등 다양한 상황에서 말이죠. 그리고 렌더링은 매우 포괄적인 개념이기 때문에 그 의미는 맥락에 따라 조금씩 달라집니다.

일반적으로 렌더링은 데이터가 특정 규칙에 따라 시각적 정보로 변환되는 과정을 뜻하며, 이를 간단히 데이터를 그리는 과정이라고 할 수 있습니다.

그렇다면 어떤 데이터를 어떤 시각 정보로 변환하는 것일까요?

바로 이 지점에서 렌더링의 맥락이 중요해집니다. 렌더링은 A를 B로 변환하는 과정이므로, 그 특정 맥락에서 A와 B가 무엇인지 명확히 이해해야 하죠.

"브라우저 렌더링"의 렌더링

전통적인 웹 프론트엔드에서의 렌더링은 브라우저가 HTML, CSS, JavaScript 같은 리소스를 사용자 화면에 그리는 일련의 과정을 말합니다. 이 과정은 DOM 트리와 CSSOM 트리 생성, 레이아웃, 페인트, 컴포지팅 등 여러 단계로 이루어집니다. 간단히 말해, 코드를 시각화하는 과정을 의미하죠.

"SPA"의 렌더링

최근에는 프론트엔드 프레임워크의 발전으로 React의 JSX나 Vue의 템플릿 문법처럼 JavaScript로 HTML을 생성하는 방식이 주류가 되었습니다. 이제는 HTML을 직접 작성하는 대신 JavaScript로 HTML과 CSS를 모두 제어하는 방식으로 바뀌었죠. 이로 인해, 기존의 HTML과 CSS코드를 시각화하는 단순한 과정에서, JavaScript가 런타임에서 HTML과 CSS를 생성하고, 이를 시각화하는 복잡한 과정으로 발전하게 되었습니다.

"SSR"의 렌더링

최근에는 이러한 현대적인 의미를 넘어, JavaScript가 프레임워크 내에서 HTML, CSS, JS의 생성과 갱신에 미치는 영향 자체를 렌더링이라고 칭하는 경우도 많이 보입니다. 이렇게 생성되고 갱신된 렌더링 리소스들이 사용자에게 전송되는 과정까지 포함해서 말이죠. 우리가 SSR을 이야기할 때 렌더링이 여기에 포함될 것입니다. 프론트엔드 프레임워크에서의 렌더링은 JavaScript가 HTML이나 CSS 같은 리소스로 변환되고 전송되는 과정을 가리키는 경우가 많습니다.

프론트엔드 프레임워크에서 렌더링을 세부적으로 정의하는 이유

프론트엔드 프레임워크들이 렌더링을 세부적으로 정의하려는 이유는 성능 최적화와 밀접한 관련이 있습니다. JavaScript의 컴퓨팅 시점과 위치를 세분화하여 최적의 렌더링 전략을 수립하기 위함이죠.

프론트엔드 프레임워크에서는 JavaScript가 렌더링 리소스(HTML, CSS, JS)로 변환되는 과정에서 가장 많은 연산이 발생됩니다. 이 과정에서는 DOM 조작, 상태 관리, UI 업데이트와 같은 연산이 포함되기 때문에, JavaScript가 실행되는 시점과 위치에 따라 성능이 크게 달라집니다. 이러한 차이가 페이지 성능과 사용자 경험(UX)에 직접적인 영향을 미치죠.

따라서, 사용자에게 최대한 빠르고 부드러운 UX를 제공하기 위해 다양한 렌더링 전략들이 등장했습니다. 이러한 전략들은 최적화된 렌더링 전략을 통해 페이지 로딩 시간과 인터랙션 속도를 개선하고, 이를 통해 보다 나은 사용자 경험을 제공하는 것이 목표입니다.

또한 렌더링의 전 과정에서 제어권이 프레임워크에서 브라우저로 넘어가는 JavaScript 실행 시점까지의 전략을 최적화하려다보니, 프레임워크에서 말하는 렌더링 과정에서 JavaScript 실행 이후의 시점은 자연스럽게 고려되지 않았습니다.

다양한 맥락에서 렌더링의 의미

정리해보자면 크게 세 가지 맥락이 있다고 정리할 수 있을 것 같습니다.

브라우저의 렌더링: HTML/CSS가 시각화되는 과정
SPA의 렌더링: JavaScript가 HTML/CSS로 변환되고 시각화되는 과정
SSR의 렌더링: JavaScript가 HTML/CSS로 변환되고 전송되는 과정

이처럼 렌더링의 개념은 브라우저, 프레임워크, SPA 등 다양한 맥락에서 조금씩 다른 의미로 사용됩니다. 특히 프론트엔드 프레임워크들은 렌더링이 가져오는 성능적 영향을 최대한 활용하기 위해 다양한 전략을 발전시켜 왔습니다. 프레임워크 내부에서 JavaScript 실행 시점과 위치를 최적화함으로써 더욱 빠르고 효율적인 사용자 경험을 목표로 하는 것이죠.

프론트엔드 프레임워크의 다양한 렌더링 기법들

이제 프론트엔드 프레임워크들이 어떤 렌더링 기법들을 채택하여 이러한 성능 최적화를 이루는지 구체적으로 살펴보려 합니다.

일단 우리는 전통적인 브라우저의 렌더링에 대해 이야기하는 것이 아니라, (사실상 트랜스파일링이 더 가까운 표현으로 보입니다만) JavaScript 코드가 HTML로 변환되고 화면에 시각화되는 렌더링 과정에 대해서 다룰 것입니다. 이는 어딘가에서 언젠가는 JavaScript가 HTML과 CSS를 생성하고 있어야 함을 뜻하고, JavaScript 엔진이 존재해야 함을 뜻합니다. 우리는 HTML/CSS를 생성하는 JavaScript 엔진이 어디에 존재하는지, 언제 동작하는지에 따라 렌더링 기법을 분류할 수 있습니다.

이렇게 분류된 각 기법이 어떤 상황에서 최적의 성능을 발휘하는지, 그리고 이로 인해 사용자 경험이 어떻게 향상되는지 하나씩 알아보겠습니다.

어디에서 렌더링하는가?

먼저 JavaScript가 HTML로 어디에서 변환되는지에 따라 분류해보겠습니다. JavaScript 엔진이 동작할 수 있는 환경은 크게 두 가지가 있습니다. 페이지 요청을 보내는 사용자(Client Side)와 페이지 응답을 보내는 프론트엔드 서버(Server Side)입니다.

`CSR`(Client Side Rendering)

브라우저 성능이 향상됨에 따라 사용자의 로컬 환경에서 JavaScript가 원활히 동작할 수 있게 되었습니다. 이로 인해 사용자 경험에 집중한 CSR(Client Side Rendering) 방식이 점차 주목받기 시작했습니다. CSR은 특히 모바일 앱과 유사한 경험을 제공하는 SPA(Single Page Application)의 부상과 함께 프론트엔드의 주요 렌더링 방식이 되었습니다.

React로 작성된 SPA 웹페이지의 경우, 웹 서버에 빌드되어있던 JavaScript 덩어리를 유저의 페이지 접근 요청에 대해 뼈대가 되는 간략한 HTML에 주입하여 응답하는 방식으로 유저에게 전달됩니다. 그리고 유저의 브라우저에서 이 JavaScript가 동작하면서 비어있는 HTML을 채워나가기 시작하죠. 이러한 렌더링 동작을 Client Side에서 수행하기 때문에 우리는 이러한 렌더링 방식을 CSR(Client Side Rendering)이라 부릅니다.

이러한 방식으로 동작하는 SPA의 경우, 기존에는 페이지 전환으로 처리해야했던 이벤트나 플로우들이 가상의 페이지 전환으로 처리되면서, 사용자들의 인터랙션에 지연 없이 응답하는 애플리케이션을 구성할 수 있게 되었어요.

❗️ SPA와 CSR은 같은 말이 아닙니다.
SPA는 한 개의 페이지로 구성된 애플리케이션을 의미하며, CSR은 브라우저에서 렌더링이 이루어지는 것을 말합니다. 즉, 여러 페이지로 구성된 애플리케이션도 각 페이지에서 JavaScript가 브라우저에서 렌더링되면 CSR이라고 할 수 있습니다.

다만 CSR은 초기 로딩 시, 유저의 브라우저가 모든 JavaScript 파일을 받아 실행하기 전까지 화면이 비어 있는 문제가 발생할 수 있습니다. 특히 큰 페이지에서는 수백 KB에서 수 MB에 달하는 JavaScript 번들로 인해 초기 빈 화면 문제가 심화되었습니다. 지금에는 생각보다 크게 문제가 되지 않는다고는 하지만, 검색엔진 색인을 위한 웹 크롤러 로봇이 CSR로 생성되는 HTML 구조와 사이트맵 구조를 자동으로 파악하기 힘들다는 이야기도 CSR의 문제 중 하나로 이야기되었다고 해요. 성능 문제를 해결하기 위해 lazy loading이나 dynamic import를 통한 최적화 기법이 활용되었으나, 근본적인 대안으로 SSR(Server Side Rendering)이 대두되었습니다.

`SSR`(Server Side Rendering)

JavaScript 런타임이 사용자 브라우저(Client Side)에서 동작하는 CSR과 반대로, SSR(Server Side Rendering)의 경우 사용자의 웹페이지 접근 요청을 받은 프론트엔드 서버가 JavaScript 엔진을 동작해 JavaScript를 HTML, CSS로 변환하여 응답으로 전달하는 방식으로 동작합니다.

사용자 브라우저에서 JavaScript를 동작시켜 화면을 그리기 시작하는 CSR은 JavaScript 동작 시점 이후에나 페이지를 그릴 수 있는 반면에, SSR은 사용자가 서버 응답을 받자마자 화면에 페이지를 그릴 수 있다는 점에서 초기 로딩 속도에서의 강점을 가질 수 있습니다.

`CSR`과 `SSR`의 차이 1. 초기 로딩 속도

하지만 생각해보면 조금 이상합니다. 진짜 초기 로딩 속도에서 드라마틱한 차이가 날까요? CSR과 SSR의 로딩 시간은 다음 두 가지 공식으로 정리해볼 수 있습니다.

$T_{\text{CSR}} = A + B + C + D$

$A$ : 프론트엔드 서버로 페이지 요청 시간
$B$ : 프론트엔드 서버의 페이지 응답 시간(JavaScript)
$C$ : 브라우저의 JavaScript -> HTML 변환 시간
$D$ : 브라우저의 HTML 렌더링 시간

$T_{\text{SSR}} = A + E + B + D$

$A$ : 프론트엔드 서버로 페이지 요청 시간
$E$ : 프론트엔드 서버의 JavaScript -> HTML 변환 시간
$B$ : 프론트엔드 서버의 페이지 응답 시간(HTML)
$D$ : 브라우저의 HTML 렌더링 시간

CSR과 SSR의 차이는 JavaScript가 HTML로 변환되는 런타임이 Client Side에서 이루어지는지, Server Side에서 이루어지는지의 차이에 불과합니다. 사실상 $|C - E|$ 만큼 초기 로딩 시간 차이가 난다는 것인데, 이를 위해서는 여러 가지 조건이 선행되어야 합니다.

Server Side 컴퓨팅 파워와 Client Side 컴퓨팅 파워의 차이가 클수록 로딩 시간에 차이가 날 수 있다.
프론트엔드 서버의 캐싱 환경 구축 정도에 따라 로딩 시간에 차이가 날 수 있다.
$(JS 번들의 사이즈 - HTML 산출물의 사이즈)$ 에 따라 네트워크 지연시간이 달라질 수 있다.

대표적으로 위와 같은 부분에서 차이가 나지 않는다면, CSR과 SSR은 초기 로딩 속도에 큰 차이가 있기 힘들 것입니다.

그래서 Next.js의 경우 Hydration 기법을 통해 초기에 뼈대가 되는 HTML을 먼저 브라우저에 렌더링 시키고, 그 동안 JavaScript를 동작시켜 로딩 시간동안 비어있는 레이아웃을 임시로 채워주는 등의 최적화 전략을 구현하여 이를 최소화하려 합니다.

`CSR`과 `SSR`의 차이 2. 검색 엔진 최적화(SEO)

$C$ , $E$ 가 크게 차이가 없다고 해도, SSR에 강점이 아예 없는 것은 아닙니다. 이 둘은 검색 엔진 최적화(SEO)에서 차이를 가집니다. CSR은 초기 로딩 시점에 브라우저에서 JavaScript가 실행된 이후에나 콘텐츠가 표시되기 때문에, SSR보다 검색 엔진 최적화에 불리합니다.

이에 대한 자세한 내용들은 글에 대한 범위를 넘어서는 것 같으니, 제가 참고한 글들을 몇 가지 남기는 걸로 대신해볼까 합니다.

SEO 톺아보기 – 정말 SSR이 SEO에 좋을까? - 한컴테크
(번역) 구글이 색인 과정에서 자바스크립트를 처리하는 방법

물론 모든 면에서 SSR이 CSR을 웃도는 것은 아닙니다. 보통 CSR은 SPA를 구축하는 데에 많이 쓰이고, SSR은 MPA(Multi Page Application)을 구축하는 데에 많이 쓰입니다. CSR은 이에 있어서 추가적인 네트워킹 요청 없이 페이지 전환과 UI 업데이트가 빠르게 이루어질 수 있다는 장점이 있고, 클라이언트 상태 관리 비용을 SSR에 비해 적게 가져갈 수 있다는 장점이 있습니다.

언제 렌더링하는가?

이번에는 JavaScript를 HTML로 어떤 시점에 변환하는가를 가지고 렌더링 기법을 분류해볼까 합니다. Next.js에서 제시하는 분류인데, 사용자 요청 이전에 JavaScript를 HTML로 미리 변환해놓는 Static Rendering(정적 렌더링)과 실시간으로 변환하는 Dynamic Rendering(동적 렌더링)입니다.

정적 렌더링(`Static Rendering`): `SSG`, `ISR`

Static Rendering은 사용자가 페이지를 요청하기 이전에 미리 JavaScript를 정적 HTML로 전환해놓는 방식을 의미합니다. 그리고 빌드해놓은 페이지에 대한 사용자 요청이 들어오면, 정적 HTML을 응답합니다. 페이지가 사용자 요청에 따라 갱신되지 않기 때문에, 페이지 내부의 내용들이 자주 변경되지 않는 서비스들에 유리한 방식입니다. 전통적인 정적 배포가 여기에 해당하는데요. 이러한 방식을 SSG(정적 페이지 생성, Static Site Generation) 라 부릅니다. 이러한 배포 형태에 CDN을 함께 구축할 경우 JavaScript 변환에 대한 서버 부하를 거의 제로에 가깝게 만들 수 있습니다. 그리고 속도에 대한 이점도 가져갈 수 있죠.

하지만 페이지의 콘텐츠가 빌드 시점에 고정되기 때문에, 갱신이 필요할 경우 CDN의 캐시 무효화와 함께 빌드를 새로 해주어야 한다는 문제가 생깁니다. 이를 위해 Next.js에서는 일정 기간마다 페이지를 새로 빌드하거나, 콘텐츠가 재검증(revalidation)되었을 때 페이지를 새로 빌드하여 저장하는 ISR(증분적 정적 재생성, Incremental Static ReRendering) 방식이 제안됩니다.

Next.js에서의 ISR은 사실상 SSG와 SSR을 결합한 방식인데요. 빌드된 페이지의 정적 배포를 통해 서버 부하를 최소화하면서, 사용자 요청이 있을 경우 페이지에 대한 CDN 캐시 확인과 콘텐츠 갱신에 대한 재검증(revalidation) 과정을 거쳐 최신의 페이지가 필요할 경우에만 SSR을 수행합니다.

그럼에도 불구하고 정적 페이지의 콘텐츠는 실시간으로 변할 수 없습니다. 일정 수준 이상의 실시간성이나 페이지 콘텐츠가 유저 정보 등 클라이언트 상태에 의존할 경우, 빌드 타임에 모든 콘텐츠를 정의할 수는 없겠지요.

동적 렌더링(`Dynamic Rendering`)

Dynamic Rendering은 사용자가 프론트엔드 서버에 페이지를 요청한 이후에 JavaScript의 변환이 이루어지는 방식을 일컫습니다. 이에 따라 사용자의 요청에 따라 매번 다른 콘텐츠를 페이지에 로드할 수 있습니다. 실시간성이 필요한 데이터를 그리거나, 사용자 정보, 특히 브라우저에 의존성이 있는 쿠키나 URL param등을 기반으로 한 데이터를 페이지에서 활용해야할 때 필요한 기법입니다.

이렇게 JavaScript 변환 시점을 기준으로 Dynamic Rendering을 정의한다면, JavaScript 동작이 Client Side에서 이루어지면 CSR, Server Side에서 이루어지면 SSR로도 세분화할 수 있겠지요.

물론 위의 그림에서 볼 수 있듯이 Dynamic Rendering은 각각의 사용자에게 JavaScript 변환에 대한 시간적 오버헤드가 발생하는 것이 가장 큰 문제입니다.

고도화되는 렌더링 기법들

각 렌더링 기법은 고유의 장단점이 있기 때문에, 우리가 어떤 페이지를 만들고자 하는지에 따라 전략을 달리 선택해야 합니다. 일반적인 선택 기준은 다음과 같습니다:

분류	설명	예시
`SSG` (Static Site Generation)	빌드 시점에 정적 HTML을 생성하여, 요청 시 빠르게 제공하는 방식	블로그 포스트, 제품 상세 페이지
`ISR` (Incremental Static Regeneration)	일정 주기마다 정적 페이지를 다시 생성해 최신 데이터를 반영하는 방식	뉴스 헤드라인, 제품 목록
`SSR` (Server-Side Rendering)	요청 시마다 서버에서 HTML을 생성하여 최신 데이터를 제공하는 방식	사용자 맞춤형 대시보드, 주문 상태 페이지
`CSR` (Client-Side Rendering)	클라이언트에서 JavaScript를 통해 HTML을 생성하고 동적으로 렌더링하는 방식	실시간 데이터 차트, 검색 필터 기능

같이 정리해본 CSR, SSR, SSG, ISR 등의 렌더링 기법들은 Next.js 생태계에서 정말 빈번하게 등장하는 키워드들인데요. 재밌는 점은 우리가 실제로 페이지를 개발할 때, 각 페이지마다 한 가지 전략만을 선택할 수 있는 것은 아닙니다. 아마 Next.js로 개발하고 계신 많은 분들이 이미 SSR과 CSR을 결합한 형태로 페이지를 구축하고 계실 겁니다.

우리는 렌더링의 위치와 시점에 따라 렌더링 기법을 분류했지만, 이는 각 영역에서 이분법적인 분류에 불과합니다. 페이지 렌더링 전략을 모색하는 프레임워크들에서는 각 렌더링 전략에서의 장점들을 모아서 최고의 사용자 경험을 제공하기 위해 노력하기 때문에, 개발자들은 자연스럽게 이들의 장점만을 취한 방법으로 페이지들을 구축하게 됩니다.

고도화된 렌더링 전략의 예시들

⚛️ React ServerComponent(`RSC`)

React Server Component는 React 18 버전부터 실험적으로 도입된 React의 컴포넌트 분류 중 하나입니다. 기존의 컴포넌트 구조에서 발생하는 request waterfall 문제와 번들링 최적화 문제를 해결하기 위해 도입된 개념으로, CSR을 기본 렌더링 전략으로 가져가는 Pure React에서도 SSR 전략을 취할 수 있도록 도와줍니다.

React에서는 선택적으로 컴포넌트를 Server Component로 선언하는 방식으로 사용하지만, Next.js에서는 이를 정식으로 지원하고 있어 'use client'등을 명시하지 않으면 기본적으로 RSC로 컴포넌트가 구현됩니다. 그렇기 때문에 RSC가 가진 특징들은 Next.js를 제대로 다루기 위해서 반드시 알아야 한다고 볼 수 있겠네요.🤔

RSC의 뒤를 이어 React 19 배포에서는 ⚛️ use, ⚛️ React 컴파일러가 계속해서 언급되고 있는 뜨거운 감자 같은 아이들이죠!

⚛️ React의 `hydrateRoot API`

React에서는 특유의 Life Cycle에 따라 DOM과 컴포넌트, 상태들을 관리합니다. React에서는 초기 뼈대가 되는 HTML을 사용자에게 빠르게 serve하고(React에서는 이것을 신기루라 부릅니다.), 사용자가 그것을 보는 동안 JavaScript를 실행시켜 그 콘텐츠를 채우는 식의 렌더링 전략을 구축하기 위한 hydrateRoot API를 제공합니다. hydrateRoot API는 정적인 HTML에 React의 관리 기능을 주입하는 기능을 지원하며, 이를 통해 특정한 정적 DOM element에 React의 Life Cycle을 주입시켜 React Client Component로써 다룰 수 있도록 만들어줍니다.

  if (isError) {
    if (process.env.NODE_ENV !== 'production') {
      const createDevOverlayElement =
        require('./components/react-dev-overlay/client-entry').createDevOverlayElement
      const errorTree = createDevOverlayElement(reactEl)
      ReactDOMClient.createRoot(appElement as any, reactRootOptions).render(
        errorTree
      )
    } else {
      ReactDOMClient.createRoot(appElement as any, reactRootOptions).render(
        reactEl
      )
    }
  } else {
    React.startTransition(() =>
      (ReactDOMClient as any).hydrateRoot(appElement, reactEl, {
        ...reactRootOptions,
        formState: initialFormStateData,
      })
    )
  }

위의 코드는 Next.js에서 Root App element에 App Component를 주입하는 로직(으로 추정되는) 코드입니다.
코드를 보면, 앞서 잡힌 error 값이 false인 경우(아무래도 RSC 호환 업데이트에 관련한 flag일 것 같네요.), Client Component의 element target인 ReactDOMClient에 hydrate를 시행하는 방식으로 작성된 것 같습니다. 이런 식으로 프레임워크 레벨에서도 hydration을 구축하기 위해 React의 hydrateRoot API를 활용하는 것을 확인할 수 있습니다.

🄽 Next.js의 Partial Prerendering(`PPR`)

앞서 소개한 RSC나 hydration 기법이 CSR과 SSR의 적절한 혼합을 목적으로 하는 전략들이라면, 이번에 소개해드릴 Partial Prerendering(PPR)은 Static Rendering과 Dynamic Rendering을 적절히 혼합한 방식의 렌더링 전략입니다.

Next.js에서 아직 실험적으로 도입된 PPR은, Server Side에서 스켈레톤 HTML을 생성하고 Client Side에서 내부 콘텐츠를 렌더링하는 기존의 hydration 기법과 유사하게, 스켈레톤 HTML을 Static Rendering을 통해 정적 HTML로 빌드한 뒤, 사용자 응답이 발생한 시점에 Dynamic Rendering을 통해 내부 콘텐츠를 렌더링하는 전략입니다.

앞서 소개했던 Static Rendering과 Dynamic Rendering의 구분에 따르면 PPR은, ISR과 SSR, CSR을 동시에 사용할 수도 있도록 해줍니다. 그리고 그 장점들만을 취할 수도 있게 해주는데요. 이게 한 페이지에 이론적으로 모두 포함될 수 있다는 게 참으로 놀랍네요.

온라인 쇼핑몰 페이지를 구현한다고 해봅시다. 여기서 PPR을 적용하면, 페이지 내의 섹션마다 우리는 렌더링 전략을 다르게 가져갈 수 있습니다. 내용의 갱신이 거의 이루어지지 않는 제품 상세 페이지 섹션은 Static Rendering(SSG, ISR)로 처리할 수 있을 것입니다. 사용자 정보 등 Client와의 통신은 필요 없지만 동적으로 실시간성을 가져야 하는 리뷰 섹션은 SSR로 처리할 수 있을 것이며, 로그인 상태에 따라 달라지는 버튼이나 사용자 프로필 정보에 따라 렌더링되는 헤더 프로필 등은 CSR로 처리할 수 있을 것입니다.

이런 식으로 PPR을 적절히 구축하면, 각각의 데이터가 사용성이 보장된 최적의 시기에 렌더링되도록 할 수 있어 최적의 렌더링 경험을 유저에게 전달해줄 수도 있을 것으로 보입니다.

그 외의 예시들

제가 사용하는 생태계에서도 이 정도의 고도화된 전략들을 채택하고 있는데, 다른 프레임워크들도 난리가 아니겠거니 해서 GPT의 도움을 받아 다른 예시들도 찾아봤습니다. 다양한 프론트엔드 프레임워크에서 다음과 같은 고도화된 렌더링 전략들을 그들의 무기로 내세우고 있더라구요. 기회가 된다면 이들을 조사해서 비교분석해보는 것도 재밌고 유익한 경험이 될 것 같습니다.

마치며

지금까지 React와 Next.js를 사용해왔고, 앞으로도 꽤 오랜 시간동안 Next.js를 사용할 대부분의 프론트엔드 분들에게 필수적으로 정리해야할 개념이라고 생각해서 함께 렌더링에 대해 알아봤습니다. 어떻게, 유익하셨나요?

저는 맨 처음에 SSR이라는 단어를 듣고 공부할 때 아무리 생각해도 내가 알고 있던 렌더링이라는 단어가 여기에서 사용되는 렌더링이라는 단어랑 뜻이 다른 것 같다는 느낌을 떨칠 수가 없더라구요. 그래서 이번 Next.js 15 배포 때문에 공식 문서를 훑어보면서, 내친 김에 제가 생각하는 렌더링 패러다임에 대해 좀 더 정갈하게 정리할 생각으로 작성해봤습니다.

단순히 현재 사용하고 있는 기술에 대해서만 공부할 것이 아니라 지금까지 그 기술이 왜 등장했는지에 대한 배경들도 함께 공부한다면 당장의 학습에도 도움을 줄 수 있을 것이고, 나아가 앞으로 그 기술이 나아갈 방향도 예상할 수 있어 기술 습득에 대한 로드맵을 구체화하는데 큰 도움이 될 것 같아요. 여러분은 앞으로 프론트엔드 렌더링 패러다임이 어떻게 발전할 것 같으신가요? 🤔

글의 내용에서 잘못된 점에 대한 지적이나 피드백 등은 너무너무 감사 드리겠습니다. 🫠
긴 글 읽어주셔서 감사드리며, 도움이 되셨으면 좋겠습니다. 🤓

Jihan

DIVIDE AND CONQUER

이전 포스트

모노레포 브랜치 관리 전략 수립과 PR 하나로 패키지별 파이프라인 트리거링하기

다음 포스트

다양한 렌더링 전략에 빠져보자. 근데 이제 Next.js를 곁들인.

들어가며

렌더링이 무엇인가요?: 다양한 맥락에서의 렌더링

"브라우저 렌더링"의 렌더링

"SPA"의 렌더링