Next14 랜더링 방식

고민해볼 이슈...

최근 있었던 프로젝트의 랜더링 방식 관련으로 고민을 해볼 겸 한 번 정리를 해보려고 한다. 이슈 사항은 다음과 같다. 페이지가 검색엔진에 노출이 되고 빠르게 로드될 수 있도록 SSG로 운영하던 프로젝트가 있었는데, 몇가지 변경사항으로 인해 다이나믹 라우팅을 수행해야만 했다. 페이지 자체는 수가 많지 않을 것으로 예상하지만, 일정 기간동안만 존재하는 특성을 가지고 있기 때문에, 해당 기간이 지나면 페이지에 접근하게 둬서는 안된다. 문제는 SSG가 빌드 시점에 페이지들이 생성되는 특성으로 인해 해당 기간이 지나더라도 페이지가 여전히 접근될 수 있다는 점이다.

 

어떻게 하면 최대한 공수를 줄이면서 SEO를 챙길 수 있는지 생각해보기 위해 Next14에서 제공하는 네 가지 랜더링 방식에 대해 여기 정리해둔다.

 

CSR (Client Side Rendering)

https://www.patterns.dev/react/client-side-rendering/

사실 해당 랜더링 방식은 현재 고려중인 부분이 아니다. 말 그래도 클라이언트의 브라우저에서 랜더링 되는 방식이기 때문에 서버의 부하를 분산시킬 수 있다는 최대의 장점이 존재하나, SEO를 챙기기 어렵다는 단점이 있다. 서버에서 간직하고 있는 파일은 비어있는 html 파일이기에 검색 로봇이 제대로 크롤링하지 못하기 때문이다.

 

SSR (Server Side Rendering)

https://www.linkedin.com/pulse/enhancing-web-performance-comprehensive-guide-server-side-c1bhe/

말 그대로 서버에서 랜더링이 끝난 페이지를 보여주는 방식의 랜더링이다. 때문에 CSR과 달리 서버의 부하가 있을 수 있다. 빈 페이지가 아니라 랜더링된 페이지를 서버에서 가지고 있기 때문에 SEO가 가능하다. React를 사용하는 대신 Next를 사용하는 것도 이러한 SSR 방식의 랜더링이 지원하기 떄문인 이유가 크다.

 

만약 기존에 SSG 방식이 적용된 페이지들을 SSR로 변경한다면 프론트엔드 쪽은 다른 프로젝트와 같이 새로 추가할 페이지에 대해서 SSR을 적용하는 것으로 충분하다. 문제는 SSG 방식으로 사전에 미리 랜더링된 SSG 방식으로 배포되던 Jenkins의 배포 구조에 수정이 필요하다 보니, DevOps에서도 공수가 발생한다는 것이다.

 

SSG (Static Site Generation)

https://tapajyoti-bose.medium.com/frontend-rendering-ssg-vs-isg-vs-ssr-vs-csr-when-to-use-which-1bf9f39ff07c

현재 적용되어있는 랜더링 방식인 SSG. 간단하게 말하자면 모든 경로를 정적 페이지로 생성해서 제공하는 방식이다. 때문에 다이나믹 라우팅이 필요한 페이지에 대해 처리를 어떻게 해주는지가 관건이다.

 

SEO가 굳이 필요하지 않다면 쿼리 스트링을 통해 id를 받아오고 추후 api로 데이터를 받아오는 방식을 취할 수 있다. 이 방법은 정확히 정적 페이지를 만드는 방식은 아니기에 검색엔진에 노출시키기 어렵지만, 페이지가 많으면 많을 수록 랜더링이 오래 걸리게 되는 문제를 해결하기에는 효과적이다.

 

다만, 현재 필자의 경우에는 SEO를 챙겨야 하는 상황으로 이러한 쿼리 스트링의 방식은 적합하지 않다. 다이나믹 라우팅을 하지 않되, 필요한 페이지가 처음 로딩될 때 빌드되도록 하여 지속적으로 사용할 수 있는 방법은 없는 것일까?

ISR (Incremental Static Regeneration)

https://dexlock.com/blog/frontend-rendering-ssg-vs-ssr-vs-csr-vs-isr/

 

놀랍게도 위의 문제에 대해 같은 고민을 한 개발자들은 해결 방법을 마련해 두었다. 바로 최초 요청 시에 해당 페이지를 generate 하여 캐시를 업데이트 하는 방식인 ISR이다. 이 경우 최초로 필요한 페이지를 불러오는 시점에 해당 페이지를 빌드하여 캐시를 업데이트하는 방법으로 정적 페이지를 구성해 사용할 수 있다. 그러나 문제는 해당 페이지의 갱신 요청 시간을 어떻게 하느냐에 따라 서버의 부하가 발생할 수 있다는 점과, 해당 페이지의 기간이 만료된 경우 데이터의 만료를 체크할 수 없다면 계속해서 접근이 가능하다는 것이다. 만료된 페이지를 핸들링한다 해도 빌드 후 캐시된 페이지가 사라지는 것은 아니라는 문제도 있다. 이러한 부분에 대해서 별도의 처리가 필요한 문제가 있다.

 

그래서 가장 좋은 방법은 무엇일까?

문제의 근본적인 원인은 결국 SEO 적용을 해야 한다에 있다. 때문에 CSR은 제외해야 하며, SSG의 쿼리 스트링 방식 또한 제외되어야 한다. 그렇다면 남은 것은 SSR 방식과 ISR 방식이다.

 

해당 부분에 대해서 우선적으로 SSR 방식을 변경하는 것에 있어 DevOps의 의견을 듣고, 얼마만큼의 공수가 들지에 대해 파악이 이루어진 뒤 가능하면 SSR 방식을 차용하고자 한다. AWS를 이용하고 있는 만큼, 불필요한 캐싱과 자원의 낭비가 일어나는 것은 지양하고 싶기 때문이다. Next14에서 여러가지 랜더링 방식과 빌드 지원을 하고 있지만, 이러한 자원과 SEO, 개발 공수와 같은 부분들에 대한 딜레마는 여전히 결정하기 힘든 부분인 듯 하다.