[Next.js 마이그레이션 1편] 프로젝트 도입배경

1. 상황

22년 8월경 우리는 react.js로 운영중인 서비스를 next.js로 대대적인 마이그레이션 작업을 2개월 가량 작업 후 배포했다(중간에 직매입, 선물하기 프로젝트와 병행)

 

이번 포스팅은 Next 마이그레이션 프로젝트를 시작한 배경에 대한 글이다. 

 

우선 프로젝트 시작 전 당시의 상황은 이랬다.

우리 서비스는 앱 출시를 위해 힘쓰고 있었다. 앱 개발은 외주에 맡겼었는데

기존의 플랫폼 코드 베이스에 하이브리드 앱으로 씌우는 형태로 제작하기 때문에 결과물을 확인하기 까지 긴 시간이 필요하지 않았다. 

 

2. 문제 / 원인

1. 하지만 결과물을 확인해 보니 문제가  있었는데, 바로 앱 진입 시 초기 로드 속도가 너무 느리다는 것이었다.

느림의 정도가 체감적으로 느껴지는 정도였기 때문에 치명적이었다. 

 

2. 또한 당시 마케팅팀이 막 창설되던 시점이어서 우리 서비스가 검색에 어떻게 노출되는 지에 대한 논의가 막 이루어지던 시점이었는데 현재의 구조로는 검색 엔진에 잘 노출하기 쉽지 않았다.

 

이유는 아래와 같다.  

CSR / SPA

당시 쇼핑몰의 코드는 React.js로 만들어져 있었는데 이는 브라우저 렌더링이 CSR(Client-Side-Rendering) 방식으로 동작한다. 

클라이언트 사이드 렌더링이란 사용자의 요청에 따라 필요한 데이터만 응답 받아 렌더링 하는 방식이다.

 

https://www.omnisci.com/technical-glossary/server-side-rendering

이 CSR 활용한 기술이 react, vue와 같은 SPA(Single-Page-Application)인데 말그대로 하나의 페이지로 구성된 웹 어플리케이션이다. 브라우저에서 최초 로드 시 HTML, JS파일, 각종 리소스를 모두 다운로드 받은 후 브라우저에서 렌더링한다.

그렇기 때문에 CSR 방식은 사용자의 행동에 따라 필요한 부분만 다시 읽기 때문에 유저의 빠른 인터렉션을 가능하게 한다.

 

하지만 이는 곧 단점이 되고 한다.

최로 로드 시 모든 파일을 다 다운로드 받기 때문에 초기 로드속도가 느릴 수 밖에 없다. 

 

또한 이 CSR 방식은 브라우저에서 View를 생성하기 위해 JS를 실행시켜야 하는데

대부분의 웹크롤러 봇들은 JS를 실행시키지 못하기 때문에 HTML에서만 콘텐츠를 수집하게 되고,

CSR 페이지를 빈 페이지로 인식하게 된다. 그렇기 때문에 SEO(검색엔진 최적화) 방식에 취약하고 그것을 가능하게 할려면 

추가 보완작업이 필요하다.

3. 해결

위 두 가지 문제를 해결하기 아주 적합한 방식이 있었다. 바로 SSR(Server-Side-Rendering)이다.

SSR

서버사이드 렌더링은 View를 서버에서 렌더링하여 가져오기 때문에 첫 로딩 속도가 매우 빠르다. 

물론 JS파일을 모두 다운로드하고 적용하기 전까지 인터렉션에 반응하지 않지만(기억하고 있다가 후에 반영) 사용자 입장에서 로딩이 매우 빠르다고 느낄 수 있다는 장점이 있다. 이는 서버에서 이미 렌더 가능한 상태로 클라이언트에 전달하기 때무에 JS가 다운로드가 되는 동안 사용자는 무언가를 보고 있을 수 있는 것이다. 

 

https://www.omnisci.com/technical-glossary/client-side-rendering

또한 페이지가 로드되기 전에 콘텐르를 렌더링할 수 있으므로 검색 엔진에서 콘튼체를 쉽게 인덱싱하고 크롤링할 수 있어 SEO가 용이하다는 장점이 있다.

 

이 SSR 방식을 사용한 대표적인 프레임워크가 Next.js로 나는 위 두 문제를 해결하기 위해 Next.js 마이그레이션을 제안했다.

 

4. 결과

그렇게 바로 마이그레이션 프로젝트에 들어갔다면 순조로웠겠지만 삶은 언제나 고난의 연속이다. 

다음 편에서 어떤 어려움이 있었는 지 얘기해보겠다.