13주차 위클리 페이퍼

Q1) 리액트만 사용할 때와 비교해 Next.js를 사용하는 이유에 대해 설명해 주세요.

(1) 리액트의 단점

리액트는 기본적으로 CSR(Client-side Rendering)에서만 작동한다는 단점이 있다. 사용자의 웹 브라우저에서만 실행되기 때문에 리액트를 사용한 웹 애플리케이션은 검색엔진 최적화(SEO)의 효과를 거의 볼 수 없으며, 첫 화면에 웹 애플리케이션을 제대로 표시하기 위해 애플리케이션 실행 초기에 성능 부담이 생긴다. 웹 앱을 완전히 표시하려면 브라우저가 전체 웹 애플리케이션 번들을 다운로드한 다음, 그 내용을 분석하고 코드를 실행해서 결과를 얻어야 하기 때문에, 아주 큰 웹 애플리케이션에서는 첫 화면을 표시하기까지 수 초가 소요되기도 한다.

(2) Next.js의 등장

Next.js는 리액트를 위해 만든 오픈소스 자바스크립트 웹 프레임워크로, 리액트에는 없는 SSR(서버사이드 렌더링), SSG(정적 사이트 생서), ISR(증분 정적 재생성)과 같은 다양하고 풍부한 기능을 제공한다. 이 외에도 타입스크립트에 대한 기본 지원, 자동 polyfill 적용, 이미지 최적화, 웹 애플리케이션의 국제화 지원, 성능 분석 등 다양한 기능 또한 제공해 주고 있다.

Next.js와 비슷한 프레임워크로는 Gatsby, Razzle, Nuxt.js, Angular Universal 등이 있다. 하지만 이러한 프레임워크들이 존재하지만, 굳이 Next.js를 사용하는 이유는 Next.js가 제공하는 뛰어난 기능들 때문이다.

Q2) Next.js에서 SSR을 실행하는 과정과 hydration에 대해 설명해 주세요.

(1) SSR 실행과정

서버사이드 렌더링에서의 렌더링은 HTML 파일 내에 내용이 있느냐 없느냐를 의미한다. 쉽게 생각해서 내용이 있으면, 렌더링이 된 것이다. 브라우저는 렌더링이 가능한 HTML을 받아 렌더링한 후 JS 파일을 다운받는다. 이렇게 브라우저가 해당 파일을 실행시키면, 페이지의 상호작용까지도 가능해지게 된다.

Next.js는 모든 페이지를 미리 렌더링(pre-rendering)한다. Next.js에서 미리 렌더링하는 방식은 SSG와 SSR로 나뉜다.

• SSG(Static-site Generation)
  빌드 타임에 HTML이 생성되어 매 요청마다 이를 재사용한다. 즉, 빌드 시점 이후에 서버에 따로 request를 보내지 않는다.

• SSR(Server-Side Rendering)
  매 request마다, 즉 웹 사이트의 페이지를 접속하거나 페이지를 새로고침할 때마다 HTML을 생성한다. SSR 방식에서는 클라이언트의 각 request마다 서버가 해당 페이지의 데이터와 리소스를 가져와서 HTML을 동적으로 생성한다.

(2) Hydration

Next.js는 서버에서 HTML을 문자열로 가져온 후에, 클라이언트에서 버서로부터 보내준 HTML을 render(), hydrate()하여 브라우저에 렌더링하는 과정을 hydration이라고 부른다.

리액트는 클라이언트 렌더링만 있어, 유저에게 보여줄 HTML, CSS 그리고 JS 모두 render() 함수를 이용해 생성하여, 모든 리소스를 한번에 렌더링한다.

반면, Next.js는 서버에서 보여줄 HTML을 미리 렌더링하여 가져오기 때문에 render() 함수로 HTML 뼈대만 렌더링하고, hydrate()를 통해 서버에서 받아온 HTML에 유저가 상호작용할 수 있는 이벤트 리스너(JS)를 연결하는 것이다.