[Next.js] SSG와 SSR의 차이점

ryusudol·2023년 7월 17일

SSG vs SSR

Build time vs Run time

SSG와 SSR의 차이점을 이해하기 위해선 Build time과 Run time의 구분이 선행되어야 한다. 이 둘의 차이는 간단하다.

Build time

현재 제작하고 있는 프로그램의 production을 위해 build 하는 시간 - npm run build

Run time

프로그램이 작동되고 있는 시간 - npm start or npm run dev

SSG (+ISR)

SSG(Static Site Generation)는 프로그램 production을 위해 build 하는 기간인 build time에 페이지를 생성하여 서버 Cache에 저장하고, request가 날아올 때마다 이를 재사용하는 방식으로 사용한다.

SSG로 페이지를 생성하기 위해서는 getStaticProps 메소드를 사용한다. 해당 메소드는 page 파일에서만 사용될 수 있으며, 이 메소드가 포함된 파일은 Build time에 생성되어 서버 Cache에 저장된다.

이러한 특성으로 인해, Build 시 한 번 생성된 page 파일은 데이터 변화에 따른 업데이트가 즉각적으로 화면 상에 적용되지 않을 수 있다는 단점이 있는 반면, Client 측에서 request가 왔을 때 Cache에서 바로 전달해줌으로써 우수한 사용자 경험을 제공한다는 장점이 있다.

SSG의 위 단점을 해결하기 위해 Next.js는 ISR 기능을 제공한다. 이는 'Incremental Static Regeneration'으로, 이미 build 된 page 내 데이터가 업데이트 될 수도 있는 경우 getStaticProps 메소드에서 revalidate 값(단위: second)을 설정하여 얼마마다 데이터를 업데이트 할지 결정할 수 있도록 한다.

SSR

SSR(Server-Side Rendering)은 request가 올 때마다 Server에서 page를 사전생성 하여 전달해준다.
즉, build time이 아닌, server가 작동하고 있는 run time에 페이지를 생성하는 것.

Next.js는 기본적으로 Server-Side Rendering으로 page를 띄운다. 이때 서버 내에서 처리해버려서 User가 브라우저 상에선 확인 불가능 하도록 하고 싶은 코드가 있을 땐 getServerSideProps 메소드를 사용한다. 대표적으로, API Key를 사용하거나 데이터베이스에 접근하는 경우처럼 보안적으로 취약한 작업을 하는 경우 활용할 수 있다.

SSR은 request가 올 때마다 Server에서 페이지를 생성해서 User에게 전달하므로, User가 최초로 페이지를 전달받는 시점이 SSG에 비해서 늦춰질 수 있다. 이에 반해, 매번 페이지를 새로 생성하므로 최신 data를 page에 띄울 수 있다는 장점이 있다.

SSG vs SSR 차이점 정리

Data Staleness

SSG - Build 시 page를 생성하므로, 이후 별도의 re-build를 통해 배포하지 않으면 데이터가 stale 해질 수 있다.
SSR - 매번 Server에서 page를 생성하므로 data를 비교적 최신으로 유지할 수 있다.

Responsiveness

SSG - 페이지가 미리 생성되어 서버 Cache에 저장되어 있기 때문에 User에게 빠르게 전달해줄 수 있다.
SSR - 매번 Server에서 페이지를 생성한 후 전달하므로 SSG에 비해 최초 렌더링까지 시간이 오래 걸린다.

위 특성들을 고려하여 SSG는 정보 변화가 거의 없는 정적인 페이지(e.g. 블로그, 뉴스 페이지)에 적용하고, SSR은 실시간으로 변화하고 있는 데이터는 아니더라도 어느 정도의 가변성을 가진 데이터를 띄우는 페이지(e.g. 사용자 대시보드, 댓글창)에 적용하면 적절할 것이다.

아래 이미지는 rendering technique; CSR(Client-Side Rendering), SSR, SSG, ISR에 따른 특성들은 시각화해서 잘 보여준다. 아래 이미지를 참고하면 이해하기 수월할 듯 하다.