프론트엔드 개발자의 화면 렌더링의 변화와 의미

특히 프론트엔드 개발자로 일하다보면 "렌더링(Rendering)" 이라는 단어를 많이 사용하게 된다.

렌더링이라는 것은 어떤 정보를 표현하는 것을 말하는데, 특히 웹 개발에서는 주로 데이터 처리를 통해 사용자에게 보여지는 특정 페이지를 생성하는 과정을 말한다.

 

개인적으로 프론트엔드 개발자 입장에서 아주 중요하다고 생각한다.

아무리 성능 좋은 백엔드 컴퓨팅 기능을 갖추고, 좋은 인프라를 구축해놨다고 하더라도 결국 유저 눈에 보이지 않으면, 그리고 사용성이 떨어지게 된다면 다른 대안을 찾기 마련이기 때문이다.

이렇게 중요한 렌더링이라는 것은 과거부터 많은 고민거리가 되었고, 그로 인해 다양한 경우에 맞는 패러다임의 적용이 필요했고, 그에 맞는 라이브러리나 프레임워크가 도입되기도 했다.

특히 React, Angular, Vue와 같은 것들의 등장을 시작으로 NextJS, Astro, Remix, Svelte 등 다양한 라이브러리 및 프레임워크가 등장했고, 그만큼 렌더링 방식이 다양하게 발전하고 있다.

 

 

초기의 웹

초기의 웹은 대부분 정적 HTML로 구성되어있었다.

서버에서 HTML 문서를 생성하여 클라이언트에 전달하는 방식이었다.

그러다보니 콘텐츠 업데이트가 어렵고 사용자와 상호작용 즉, 인터랙션이 제한적이었으며, 페이지 전환 시 마다 서버에 요청을 보내야하므로 UX가 좋지 못했다.

 

 

SSR

그러다 2000년대 초부터 PHP, ASP.NET 등 서버 사이드 언어의 발전으로 동적인 웹페이지 구현이 가능해졌는데 사용자의 요청에 따라 서버에서 데이터를 가져와 HTML을 생성하여 클라이언트로 전송하는 방식이다.

더불어 AJAX의 출현으로 인해 웹 패러다임이 크게 변화를 하게 됐는데 페이지를 새로고침 하지 않고 서버와 비동기적으로 통신할 수 있게 되었다. 

 

 

SPA

이 후 2000년대 후반부터 React, Angular, Vue와 같은 프론트엔드 3대장이 나오면서 SPA(Single Page Application) 개념이 부각되었다. 

이는 단일 페이지 어플리케이션으로써 전체 페이지를 새로고침 없이 필요한 부분만 따로 업데이트를 하는 방법이다.

사용자가 페이지에 요청을 해도 전체 페이지가 깜빡 하는 것이 아닌, 필요한 부분만 업데이트되므로 사용자의 UI/UX가 크게 향상 될 수 있었다.
또한, CSR(Client Side Rendering) 방식으로 동작함으로서 브라우저가 초기 HTML과 Javascript 파일을 받아오고, 이후에는 프레임워크가 브라우저 내에서 Javascript를 통해 뷰를 렌더링하여 화면을 구성하는 방식을 취했다.

 

이러한 방법으로 개발하는 것이 꽤 오랫동안 좋은 방법이라고 생각 되었고, 많은 프레임워크와 라이브러리들이 그와 비슷하게 그러나 개발하기는 조금 더 용이하도록 만들어져서 나왔다.

그런데 SPA를 사용하다보니 웹 자체만 보기에는 좋았지만 단점들이 눈에 보이기 시작했다.

가벼운 홈페이지 정도는 괜찮겠지만 무거운 경우, 유저가 사용을 하던 안하던 일단은 다 불러와야하다보니 필요없는 것까지 불러오느라 초기 렌더링이 느려 UX가 좋지 못한 경우가 발생했고, SEO에 대한 수요가 증가하고, 모바일이나 태블릿 등에서는 기기 성능에 따른 최적화 또한 필요해졌다.

 

그 때 즈음해서 나온 것이 NextJS, Remix 같은 것들이었는데 생각해보면 과거에도 PHP, ASP.NET 같은 것들이 있었다.
이 또한 SSR인데 왜 갑자기 이제와서 이슈가 된 것일까?
과거에는 백엔드 개발자가 프론트엔드 개발까지 모두 개발을 하기도 했었다.

그러나 모던 프론트엔드 개발에서는 복잡도가 크게 증가하였고, 그에 따라 여러 컴포넌트 기반 아키텍쳐, 상태관리, 데이터 패칭 기술들이 나타났다. 그러면서 사람들이 찾게 되는 것이 프론트엔드 프레임워크였다.

특히 이런 프론트엔드 프레임워크들이 SSR 뿐 아니라 SSG(정적 사이트 생성) 기능도 지원하면서 필요에 따라 잘 개발하기만 하면 성능을 더욱 향상 시킬 수 있게 된 것이다.

또한, React는 강력한 생태계를 가지고 있었는데 NextJS를 사용하면 다양한 라이브러리나 도구들을 쉽게 통합할 수 있고, 접근성이 용이 했기 때문에 많은 사람들이 선택하게 되었다.

 

ISR

그리고 ISR 이라는 것도 있는데 Incremental Static Regeneration 이라고 해서, 정적 페이지 생성과 SSR의 장점을 결합해 특정 페이지를 정적으로 생성하고 필요에 따라서 업데이트를 하는 방법을 말한다.

서버의 부하를 줄이면서 최신 데이터를 제공할 수 있는 유연성을 제공하는데 이런 SSR, ISR 같은 것들은 NextJS를 접하게 되면서 많이 얘기를 나눴었다.

 

CSR, SSR, SSG, ISR 정도가 내가 사용하던 대부분의 렌더링 방법이었는데, 이 후 리액트가 19버전 출시를 압두고, 또 NextJS 15버전 얘기가 나오면서 PPR, RSC 과 같은 얘기들도 들리기 시작했다.

 

PPR

우선 PPR이라고 하는 것은 AJAX 호출이나 서버 전송을 통해서 전체 페이지가 아닌 특정 부분만 서버에서 렌더링해 클라이언트에 전달하는 방식을 말한다. 특정 부분만 변경한다는 부분에서는 CSR과 비슷하게도 들리는 것 같다. 어떤 차이가 있을까?
CSR의 경우 클라이언트 측에서 HTML을 생성하는 방식이다. 
사용자가 페이지 요청을 하면 서버는 Javascript 파일과 필요한 리소스를 클라이언트에 전달하고, 브라우저가 이를 실행하여 DOM을 생성하고, 페이지 전환 시 클라이언트는 필요한 데이터만 요청하고 이를 기반으로 새로운 컨텐츠를 렌더링하게 되는 것이다.

PPR의 전체 명칭을 보면 Parital Page Rendering 즉, 부분 페이지 렌더링이다.

PPR은 AJAX를 사용하여 서버와 통신하고, 필요한 데이터만 서버에서 가져와 특정 요소만 동적 업데이트하는 것이다.

 

 

RSC

RSC의 경우, React 19버전이 나온다는 얘기가 들리면서 가장 많이 접했던 것 같다.

CSR만 지원했던 리액트에서 서버 컴포넌트 렌더링이 가능해지면서 클라이언트에 필요한 데이터만 전송하는 방식을 말한다.

이를 통해 CSR만 사용할 때는 무거운 자바스크립트 번들을 가져오느라 초기 렌더링이 늦었었는데, 클라이언트 측의 자바스크립트 번들을 줄이고 성능을 향상 시킬 수 있게 된 것이다.

특히 데이터 패칭과 성능을 최적화하는데 큰 이점을 두고 있다.

 

 

---

 

 

 

여기까지만 봐도 프론트엔드 렌더링 기법은 2000년 대를 기반으로 현재까지, 그리고 앞으로도 다양한 것들이 접목되고 섞일 것으로 보인다.

지금은 많은 회사들이 Vite를 이용한 React, NextJS를 주로 사용하는 것으로 보이지만 프론트엔드 쪽은 하루가 멀다하고 새로운 것들이 바뀌고 업데이트 되고 있다.

내가 본 최근의 자료는 vike.dev 였는데 제일 첫 페이지부터 Next.js/Nuxt altternative. 라고 나와있는걸 보니 어쩌면 또 한번 격변이 오지 않을까 하는 생각이 들기도 한다.

 

요즘 많은 경우, React나 Next.js, 앱을 사용해도 PWA나 React Native를 사용하다보니 React의 노예(?)가 되는 느낌이다.

그러나 마음을 조금 다 잡자면 나는 리액트 개발자가 아니고 프론트엔드 개발자인 만큼 다양한 것들에 대해서 대응 할 수 있어야하고, 필요에 의해서 새로운 프레임워크나 라이브러리를 사용하면서 더 최적화 되고 좋은 UX를 줄 수 있는 환경에 빠르게 적응하기 위한 밑바탕을 잘 만들어야겠다는 생각을 하게 된다.