NextJS와 GatsbyJS 중 고민하는 당신에게
31 Jan, 2021
NextJS와 GatsbyJS 중 고민하는 당신에게
React를 배우다 보면 자연스레 한번쯤은 Facebook에서 만든 Create React App(React 웹 개발용 Boilerplate)를 접해 보셨을 겁니다. 이 이외에도 React를 토대로 만들어진 프레임워크들이 있다는 것을 알고 계신가요?
React가 웹 앱 개발에 자리잡아 가는 과정 속에서 많은 개발자들은 웹 앱 개발, 사용자 경험 향상 및 마케팅 측면에서 보다 효율적으로 할 수 있는 방법을 찾아가게 되었고, 그 과정 속에서 GatsbyJS와 Next.js가 이에 대한 대안으로 자리잡고 있습니다.
이미 Next.js나GatsbyJS 중 하나라도 들어보신 적이 있다면 아마 아래와 같은 Case들을 고민하다 찾으셨을 것이라 생각 됩니다.
- 🤔 : 흠.. Client Side Render(CSR)이 SEO 측면에서 불리하다는 이야기가 있던데.. React를 쓰면서 확실하게 SEO 고민을 떨쳐내는 방법이 있을까?
- 😇 : 서비스를 쉽고 빠르게 만들고 싶은데.. webpack, babel, route 세팅 등등 cra를 써도 프로젝트 세팅에 너무 시간이 드는데..?
- 🤥 : 초기 Rendering (TTI) 측면에서 CSR이 별로라고 하던데 이를 어떻게 하면 쉽게 개선할 수 있지?
- 😀 : 블로그와 같은 컨텐츠 등을 서버 없이 쉽게 구축할 수 는 없나? JAMStack이라는게 있다던데?
위의 케이스 외에 요즘 눈에 많이 띄어서나 다른 이유가 있을 수도 있구요.
이 글에서 이야기 하고자 하는 내용은 NextJS나 GatsbyJS를 도입을 하려 하고 이 중 어떤 것을 선택할 지 고민하는 사람들을 위해 제가 직접 서비스를 만들고 운영해보면서 느꼈던 장단에 대한 내용입니다.
NextJS와 GatsbyJS의 공통된 장단점은 무엇일까?
이런 프레임워크를 도입하는 것에 있어 여러 방면에서 고려사항들을 두고 선택하겠지만, 두개의 프레임워크 모두 훌륭하게 처리해주고 있는 것들이 있습니다. 고려사항 속 고민거리를 소거하고자 둘 다 공통된 장단점에 대해 이야기 해보려 합니다.
공통된 장점
SEO (search engine optimization)
검색 창에서 내 컨텐츠를 잘 노출시키기 위해서는 SEO 작업이 필요합니다. CSR 방식도 react-helmat 등을 사용하여 SEO 작업이 충분히 가능하고 검색엔진이 크롤링 하는데 큰 문제가 없다고 하나, 구글 외 다른 검색엔진 등에서의 불확실함을 가질 수 있습니다. 두개의 프레임워크 모두 SSG(static site generation) 또는 SSR(server side rendering) 등의 방식으로 Render가 되기 때문에 SEO 측면에서의 불안요소를 제거할 수 있습니다.
웹 개발 단순화 및 개발 속도 향상
두개의 프레임워크 모두 단순 Create React App이나 React보다 서비스 개발에 집중할 수 있도록 만들어 두었습니다. 더 자세한 도큐먼트, 더 쉬운 프로젝트 세팅, 더 편한 개발환경 및 배포방식 등등 CRA도 서비스 개발에 집중할 수 있게 여러 세팅들이 되어있지만, 이와 비교할 수 없을 정도로 다양한 case에서의 설명과 대응 방법이 제공되고 있습니다.
이 이외에도 JAMStack 등의 공통된 장점이 있습니다.
단점
블랙박스 영역 및 제어할 수 없는 영역
서비스를 쉽게 만들기 위해 만들어진 프레임워크 이기 때문에, 사용자가 제어할 수 없는 영역들이 생기게 되거나 기존의 개발 방식으로 구현하지 못하는 것들이 생깁니다. 대표적으로 NextJS에 hydration 이전 상태를 컨트롤 한다던지, SSR이나 SSG 빌드 단계에서는 Node 환경에서 빌드 되기 때문에 Window 객체 사용에 제약이 걸리는 등의 상황이 발생합니다.
GatsbyJS는 어땠어?
지금 이 블로그 뿐 아니라 회사의 채용페이지와 블로그를 GatsbyJS를 통해서 만들었었습니다.
기본적으로 개츠비는 SSG 형태(static 페이지 생성)의 페이지를 구성하는데 최적화 되어있다. 특히 markdown base의 JAMStack을 구성하는게 매우 쉬웠고, SSG 형태에에서의 최적화를 위한 노력을 정말 많이 했음을 부분부분에서 느낄 수 있었습니다.
가장 먼저 떠오르는 것은 gatsby-image 컴포넌트입니다. 이미지를 graphQL을 통해 fluid 형태로 가져올 경우 알아서 이미지를 dynamic import를 해준다. 이러한 기능들이 기본적으로 제공되고 있습니다.
이 뿐 아니라 GatsbyJS에는 플러그인 이라는 것이 제공되는데 적게는 코드 한줄, 또는 최소한의 작업으로 정말 많은 것들을 해결할 수 있습니다. 특히 채용 페이지를 만들면서 개발자 리소스가 없는 상황에서 Headless CMS와 관련된 블러그인을 통해 하루만에 CMS를 모두 제공했던 경험이 있었고. PWA를 만드는 것 부터 GA, sitemap 생성 등등 모든 것을 정말정말 쉽게 할 수 있었습니다. 그리고 NextJS보다 SSG 성능이 더 높다고 합니다.
하지만
이러한 이러한 장점 속에는 단점도 존재합니다. 우선 서비스가 커지면 커질수록 빌드시간, 파일 사이즈는 기하급수적으로 늘어나게 되었고 약 1~20개 사이의 글을 운영하는 블로그를 배포하는데 8~10분의 시간이 걸렸으며, 파일 용량 npm module과 local start 환경의 파일을 모두 포함하여 1.7GB에 육박했습니다.
사실 SSG 특성상 양이 많아지면 빌드 시간이 길어지는게 당연하기에 큰 문제가 아니라 여길 수 있을 것 같기도 합니다.
이와 별개로 GatsbyJS를 사용하면서 가장 힘들었던 점은 GatsbyJS 플러그인의 매직 속 디펜던시입니다. GatsbyJS가 버전업이 되면 GatsbyJS에서 제공하는 플러그인들도 함께 대응을 해줘야 하는 경우가 있었습니다. 한번은 버전 업에 대한 경험이 부족해서 아무 생각없이 GatsbyJS 버전업을 했던 적이 있었는데 버전업을 하면서 image와 관련된 라이브러리를 함께 업데이트 하라고 하기에 gatsby-image를 업데이트 하였고, 이를 업데이트하니 gatsby-remark-images도 업데이트를 하라 했습니다. 부분부분만 업데이트를 하면 버전이 달라 빌드가 되지 않다보니 그냥 모두 업데이트를 하였는데, 버전 업이 되면서 썸네일 url path 구조들이 모두 달라저 예전에 공유되었었던 썸네일들의 이미지가 모두 깨지는 상황이 발생했었습니다. 이 이외에도 GatsbyJS의 어떤 플러그인 들은 버전업 대응이 미처 되어있지 않아 GatsbyJS 버전업을 하면서 다른 라이브러리로 대응했던 경험도 있습니다.
물론 버전 업은 항상 신중해야하고, 내 경험이 부족해서 생긴 이슈일 수도 있습니다. 하지만 이러한 경험을 하고 나서 GatsbyJS를 회사 서비스에 적극적으로 도입하는 것에 살짝 조심스러움이 생겼습니다.
(당연히 내 역량 문제가 클 것이라 생각됩니다. React 공식 도큐먼트나 Figma, Airbnb Engineering과 같은 페이지는 GatsbyJS로 매우 잘 운영되고 있습니다.)
NextJS는 어땠어?
나는 NextJS를 9가 나오고 10 beta 이야기가 나올 때 쯤에 처음 접해보았고 NextJS를 통해서 iOS 컨퍼런스 페이지나 동아리 소개 및 동아리 내 인사 관리 페이지(backoffice)를 구현하고 운영했었습니다.
처음 NextJS를 사용하고 느낀 것은 ”와 정말 유연하다!” 였습니다. 물론 유연함은 GatsbyJS와 비교해서 인데 GatsbyJS는 SSG + CSR 형태의 방식만 제공하거나 데이터를 처리하는 것에 있어서 GraphQL만 사용할 수 있는 것에 비해, SSG, SSR의 방식을 모두 제공하고 데이터를 가져오는 작업에 있어서 CSR과 동일한 모든 방식을 제공합니다. 이것이 정말 큰 장점인 이유는 GatsbyJS는 컨텐츠의 양이 점점 많아지거나 데이터들이 수시로 주고받는 상황에서 GatbyJS는 매번 SSG를 만들기 위해 배포 하거나 SSG 로 빌드 이후 CSR방식의 API 호출을 해야합니다. 수시로 바뀌는 데이터를 매번 SSG 빌드를 하는 것은 불가능에 가깝기에 SSG보다 조금 느릴지언정 SSR을 통해 render 할 수 있다는 것이 매력적이었습니다.
하지만
다만, NextJS를 개발하면서 GatsbyJS의 플러그인이 그리울 때가 많았습니다. 특히 window 객체를 사용하는 애니메이션 등에서 빌드 단계에서 window 객체가 없는 상황을 고려해야할 때, 애니메이션 구현 등이 불가능한 것은 아니지만 gatsbyJS 플러그인의 매직에 비해서는 많은 공수가 들었습니다. 이 이외에도 RSS를 붙이거나 할 때에도..
그래서 둘 중 어떤 것을 추천해?
우선 NextJS와 GatsbyJS 모두 정말 엄청 좋은 프레임워크이기에 사실 무엇을 써도 좋은 결과물을 얻을 수 있을 것입니다.
하지만, 내가 만약 도입에 기준을 정한다면 서비스의 규모 및 사용할 데이터에 따라 위의 프레임워크를 적절하게 사용 할 예정입니다.
우선 앱내 웹뷰, 실험(a/b testing)을 하는 환경, 쇼핑몰 같은 서비스와 같이 유저에 따라 보여줘야 할 정보들이 다르거나, 데이터가 수시로 변경된다면 나는 무조건 NextJS를 사용 할 예정입니다. 유저 정보를 활용하는 등 동적인 데이터를 SSG로 하나하나 대응하기는 불가능에 가깝고 CSR로 처리한다면 SSG를 사용한 잇점이 많이 줄어들게 됩니다. 동적이진 않지만 데이터가 수시로 변경 된다면 매번 빌드하는 것과 빌드 속도도 무시하지 못할 것입니다. 또한 유연함 까지
GatsbyJS의 경우에는 소개를 위한 퍼블리싱 페이지나 CMS 기반의 WIKI, 블로그를 만들 때와 같이 정적인 데이터가 많거나 CMS등을 가볍게 사용할 때 많이 사용할 것 같습니다. NextJS보다 더 쉽게 구현할 수 있으며, CMS을 연동하기 좋은 구조로 되어있습니다. 게다가 정적인 데이터들의 경우 모두 SSG로 빌드 되어 나가기에 퍼포먼스 측면에서도 더 좋기 때문입니다.
