Next.js 전환 후기

기존 프로젝트

기존에는 CRA(create-react-app)로 구축되어 있었고 정적 파일로 빌드되어 단순히 S3에 호스팅 되는 구조로 심플하고 인프라 관리가 쉬운 형태이다. 브라우저 환경에서만 구동되는 것을 가정하고 작성한 아주 심플한 프로젝트였다. 규모는 비교적 작은 수준으로 서버 API는 graphQL 사용해서 아폴로 클라이언트가 API 레이어를 담당하고 styled-components로 스타일링 하고 있었다.

Next.js로 전환

니즈는 방대한 컨텐츠에 대한 동적 SEO 지원이었다. 정적 파일로는 규모가 큰 콘텐츠의 SEO를 지원하는 데에 분명한 한계가 있었고 이를 해결하고자 SSR(server-side-rendering)이 필요했다.

브라우저 환경과 서버(Node)환경

두 가지 환경에서 동시에 하나의 코드로 작성한다는 것은 굉장히 효율적이다. 하지만 두 환경에 대한 차이를 이해하지 못한다면 버그 및 갖가지 에러와 마주하게 된다.

 

브라우저 환경에서 작동해야 하는 로직들은

- 브라우저 런타임 시 작동할 수 있도록 지원한다.(onClick과 같은 유저 상호 작용 시점에 window api에 접근하듯이)

- useEffect 안에서 구현한다.

 

위의 두 가지만 신경 써서 구현하면 어렵지 않게 CRA프로젝트에서 Next.js로 전환할 수 있을 것이다. 물론 다양한 로직과 라이브러리가 존재하고 있다면 두 가지만 신경 쓰는 것만으로도 큰 작업이 된다. 실제로 apollo client를 사용하는 이번 프로젝트에서 Next.js를 위한 최적화 작업에 비교적 오랜 시간 동안 할애했다. 또한 locale에 따른 영문 지원도 하는 국제화 작업 때문에 좀 더 신경을 써줘야 했다.

페이지별 최적화(SSR / SSG / Static / ISR)

페이지별로 어떻게 빌드할지 정해야 한다. initail props api 사용에 따라서 Next.js가 최적화해주는데 SSG / Static 방식의 정적 페이지로 서비스하는 것을 권장한다. 정적 파일로만 서비스하는게 서버 자원 사용이 낮으며 성능이 좋기 때문이다. 대신 무수히 많은 데이터에 동적으로 대응하지 못하는 한계가 있으므로 이럴경우 SSR이나 ISR을 사용해야 하는지 생각해봐야 한다. SSR은 서버에서 클라이언트 요청 타임에 렌더링 후 서비스하는 방식. ISR은 클라이언트 요청 시기에 페이지가 없을 경우 정적페이지를 만들어 서비스해주고 이후 요청에는 만들어진 정적 자산을 서비스하는 방식.

 

- SSR: server side rendering으로 웹서버에 요청이 왔을 때 웹서버에서 렌더링 후 응답해주는 방식(getServerSideProps API 사용시)

- SSG: 빌드타임에 정적 파일로 응답해주는 방식(getStaticProps API 사용시)

- Static: 빌드타임에 정적 파일로 응답해주는 방식(initail props가 없을 경우)

- ISR: 해당 기술은 vercel에서 서비스할 때 사용할 수 전략으로 흥미로운 방식이다. 기본적으로 정적파일로 서비스해주며 클라이언트에서 요청시 해당 페이지가 없을 경우 정적파일을 서버에서 만들고 이후 요청에는 만들어진 정적 자산으로 제공한다. 새롭게 정적파일을 만들어주도록 요청할 수 있는 시간을 설정할 수 있어 더 오랜 캐시로 빠른 응답 전략과 더 느린 응답으로 비교적 신선한 데이터 전략 중 하나를 균형있게 선택할 수 있다(일종의 캐시 사용 시간 설정). 참고(vercel 문서, Next.js 문서)

배포 및 서버

vercel이라는 Next.js를 훌륭하게 지원해주는 플랫폼이 있다. 자체적으로 호스팅 기능과 더불어 쉽게 배포해주고 프리뷰라는 별도의 환경을 제공해 Headless API의 배포 전 내용을 확인할 수 있도록 제공한다. Next.js API 레이어와 CDN 등 서버 인프라를 쉽게 최적화해주므로 웹 개발자는 비즈니스 로직에만 최대한 신경 쓸 수 있도록 서비스한다.

 

배포 또한 Github와 연동되어 branch에 merge 되면 자동으로 배포되는 시스템으로 손쉽게 배포 관리를 할 수 있다.

Next.js 와 Gatsby

개인적으로 CRA, Next.js, Gatsby 플랫폼 중 선택을 해야 한다면 낮은 수준에서 시작하는 CRA는 스터디 스타터 용도 외에 실무에서 사용할 필요는 없어 보이고 Next.js와 Gatsby 플랫폼 중 하나를 선택하면 될 것으로 보인다.

 

- 블로그나 프로모션 혹은 회사 소개 페이지 같은 한정된 콘텐츠를 서비스할 목적이라면 Gatsby.

- 다양한 기능과 콘텐츠가 존재하는 서비스를 제공할 목적이라면 Next.js

 

Next.js도 갯츠비의 SSG를 기본적으로 지원하고 권장하기 때문에 두 플랫폼 중 고민이 된다면 Next.js로 가는 것을 추천하며 실제로 Next.js의 성장과 도입은 급격히 늘어나는 추세이다.

나오며

서버 렌더링은 굉장히 까다로운 주제이지만 Next.js는 이를 쉽게 해결하도록 추상화했고 vercel이라는 플랫폼으로 쉬운 통합과 배포를 지원한다. Next.js 전환은 쉽지 않은 작업이었지만 생각만큼 많이 어렵지도 않았고 훌륭한 개발 경험과 성능으로 개발자 및 서비스 사용자들에게 좋은 웹 경험을 선사하고 있다고 생각한다.

 

더불어 typescript를 지원하고 있어 신규로 작성한 코드는 typescript로 작성했고 typescript로 점진적인 마이그레이션이 가능하기 때문에 기존 프로젝트가 JS라면 점진적으로 시도하기 좋다.