최근 Next.js로 프로젝트를 진행하면서 다양한 렌더링 방식을 사용할 수 있다는 것을 알게 되었다. 그러나 특정 상황에 장점을 발휘할 수 없는 방식을 사용하게 된다면 오히려 성능이 저하되고, 원하는 방식대로 동작하지 않을 수 있다. 그렇다면 '적재적소'는 언제일까? 최적의 개발을 진행할 수 있도록 성장하기 위해 각 렌더링 방식에 대한 개념과 특징을 학습하려고 한다.
웹 개발의 흐름 되돌아 보기
웹 개발에 있어서 Frontend, Backend라는 분류가 생겨난 것은 그리 오래된일이 아니다. 과거 php, jsp 등으로 서버에서 완성된 html을 받아와 브라우저에 렌더링 하는 방식에서는 사용자의 상호작용에 제한이 많았지만, 점점 기술이 발전함에 따라 2005년 이후 Ajax 및 jQuery의 유행 등 자바스크립트를 활용해 사용자와의 상호작용을 처리하기 시작했다. 이때부터 클라이언트에서의 동작을 만들고 제어하기 위한 개발자 Frontend가 생겨났다고 볼 수 있다.
이후 2011년 경, Facebook의 경우 메세지 기능에 필요한 실시간 업데이트의 어려움을 극복하기 위해 사용자의 행동에 즉각적으로 반응하기 위한 솔루션이 필요했고, 이를 해결하기 위해 React가 탄생하게 되었다.
CSR의 시대
이러한 흐름에 따라 React를 필두로 아무런 내용을 담지 않고 있는 HTML파일을 받아 온 후 브라우저가 화면을 그리는 단계에서 Javascript로 Node를 만들어 사용자에게 보여주는 방식(CSR)이 유행이 되면서 이러한 개발을 손쉽게 하게 해주는 라이브러리들의 대유행이 시작되었다.
이러한 방식의 장점은 화면의 반응이 굉장히 빠르고 유연하다는 점이다. 처음 화면을 렌더링 할 때 모든 페이지에 들어갈 js파일을 읽음으로써 페이지를 이동할 때 서버에 다시 가서 HTML을 더이상 화면의 버벅임이나 깜빡임 없이 굉장히 빠르게 이동할 수 있게 되었다.
Who's Next?
그러면 장점만 있을까? 그렇지 않다. CSR 방식에는 몇가지 단점이 있는데,이 단점들이 내가 만드는 서비스에 치명적일 수 도 있다.
먼저 초기 페이지 로딩 속도가 느리다.
앞서 말했듯이 사용할 모든 js 파일을 가져와서 시작하기 때문에 로딩하는 데에 물리적인 시간이 필요하다. 물론 이 후의 모든 이동과 동작은 매우 빠르게 진행되지만 간과해서는 안되는 단점이다.
SEO 최적화 문제
이 부분도 동일한 원인에서 시작되는데 앞서 언급한 것과 같이 1개의 HTML 파일(Single Page Application)에 최소한의 내용만 들어있기 때문에 각각의 페이지가 검색엔진에 노출되기 원하거나 메타 태그를 활용해야하는 상황이라면 적합하지 않다.
시간이 지남에 따라 이러한 문제들을 해결할 수 있는 새로운 도구들이 제시되었고, 그 중 하나가 Next.js이다.
CSR (Client Side Rendering)
- 장점 : 빠른 반응성, 유연한 움직임
- 단점 : 최초 로딩 속도 느림, SEO 최적화가 어려움
Next.js는 이를 극복하기 위해 SSR 뿐만 아니라 SSR, SSG, ISR 등 여러 렌더링 방식을 지원한다.
SSR(Server Side Rendering)
서버 사이드 렌더링은 클라이언트 사이드 렌더링과 다르게 페이지 요청 시 서버에서 HTML을 생성해 클라이언트로 전송하는 방식이다. 앞서 언급한 php, jsp가 유행하던 시절의 렌더링 방식도 서버에서 html을 만들기 때문에 비슷하다고 볼 수 있지만, 과거 전통적인 방식의 SSR과 현대 next.js에서 사용하고 있는 SSR은 조금 차이가 있다.
hydration
하이드레이션은 next.js의 서버에서 생성된 HTML에 클라이언트의 Javascript를 연결해 핸들러나 Hook등의 상태를 변경함으로써 사용자 인터렉션이 가능하게 하는 방법이다. 이는 전통적인 SSR 방식에서 요청마다 페이지가 깜빡이거나 리로딩 되는 문제가 발생하지 않고, 마치 CSR에서 작동하는 것처럼 보이지만 CSR의 단점을 극복할 수 있는 방식이다.
적용
Next.js에서 SSR은 기존 CSR에서 사용하는 실시간 데이터 반응 (웹소켓 같은 실시간을 말하는 것이 아니다.)이 필요한 곳에서 대부분 사용 가능하다. 그러나 주의할 점은 React의 Hook은 오직 클라이언트에서만 작동하기 때문에 이 경우 클라이언트 컴포넌트를 사용하는 것이 적절하다.
SSR(Server Side Rendering)
- 장점 : 초기 로딩이 상대적으로 빠름, SEO 최적화
- 단점 : 페이지 별 요청으로 인한 시간 소요
SSG(Static Site Generation)
SSG는 정적 사이트 생성이라고 직역할 수 있는데, 프로젝트를 배포하는 빌드 단계에서 정적 페이지를 완성해 놓고 해당 파일을 사용하는 것을 말한다.
특이한 점은 완성된 페이지를 사용하는 방식에 있어 CDN으로 전세계에 있는 엣지 로케이션에 배포된다는 점인데, 이로 인해 사용자들이 가까운 엣지에 페이지를 요청할 수 있어 빠른 접근이 가능하다는 점이다.
SSG 또한 하이드레이션을 통해 사용자의 인터렉션은 가능하지만 빌드 시점에서 정해진 데이터는 변경이 어렵기 때문에 다시 배포할 때 까지 변경될 데이터가 없는 페이지에 사용하는 것이 적합하다.
적용
한번 정해진 데이터의 변경이 어렵기 때문에 자주 변경되지 않는 정적 페이지에 사용할 수 있다. 주로 마케팅 페이지나 제품 문서 등 새로운 배포 및 버전이 나오기 전까지 변경되지 않는 상황에 적합하다.
SSG(Static Site Generation)
- 장점 : CDN으로 인해 빠른 로딩, SEO 최적화
- 단점 : 실시간 데이터 반영이 어려움
ISR(Incremental Static Regeneration)
ISR은 점진적 정적 재생성이라고 직역할 수 있다. SSG의 실시간 데이터 반영이 어려운 점을 극복한 방식이다. 데이터에 대해 revalidate 시간을 설정해 해당 시간에 도달하면 백그라운드에서 새 데이터를 요청하고 다음번 페이지에 진입 시 업데이트된 정보를 보여주는 방식이다.
이때, 새 데이터를 요청하는 과정에서도 기존 CDN에 캐싱된 이전 데이터를 보여줌으로써 빠른 페이지로딩을 유지할 수 있다. 이로 인해 SSR이나 CSR처럼 실시간 반영이 빠르게 되는 것은 아니지만 다시 배포를 해야하는 SSG의 단점을 일부 극복하고, 성능을 보장할 수 있다는 장점이 있다.
적용
주로 데이터가 자주 변경되긴 하지만 실시간성이 크게 중요하지 않아 주기적으로 업데이트 해주기만 하면 되는 경우에 적절하다. 날씨정보, 뉴스피드(속보x) 등에 활용해볼 수 있겠다.
ISR(Incremental Static Regeneration)
장점 : CDN으로 인한 빠른 로딩, 데이터 업데이트 가능
단점 : 데이터 일관성 문제(엣지마다 다른 캐싱), 실시간성의 한계
마무리
지금까지 Next.js를 사용하면서 마주할 수 있는 여러 렌더링 상황에 대해서 알아보았다. SPA가 유행하고 CSR이 유행하던 시절을 지나 프론트엔드 개발자들이 더 복잡한 상황을 마주하게 되었다. 그렇다면 이제는 모든 서비스가 Next.js와 비슷한 서비스를 사용해야할까? 꼭 그렇지는 않다. 여전히 SPA로 충분한 서비스를 제공할 방향이 있고, 그 장점을 가볍게 여길 수 없기 때문에 무조건적인 수용은 옳지 못하다고 생각한다. 그래서 이러한 학습을 통해 개념을 이해하고 기획 단계에서 우리 서비스에 필요한 방향성을 가진 도구를 선택하는 능력이 매우 중요할 것이라 생각한다.
