개츠비(Gatsby)와 Next.js는 현재 웹 개발 분야에서 가장 주목받는 두 가지 기술입니다. 커뮤니티 게시판이나 유튜브 댓글에서도 "어느 쪽을 선택해야 하는가?"라는 질문을 자주 볼 수 있습니다. 필자는 지난 12개월간 Next.js와 Gatsby 생태계에 깊이 몰두해 왔기에, 이 논쟁에 대해 어느 정도 자격을 갖춘 의견을 낼 수 있다고 생각합니다.
프로젝트에 Next.js를 사용할지 Gatsby를 사용할지 고민할 때 "적재적소에 맞는 도구"라는 표현이 떠오릅니다. 하지만 걱정하지 마세요. 막연한 답변으로 여러분을 내버려 두지 않겠습니다.
핵심 요약(TLDR)
- Gatsby와 Next.js는 모두 React 프레임워크이며, 둘 다 SSR(서버 사이드 렌더링)을 기본 제공합니다(SEO에 매우 유리).
- Next.js가 상대적으로 덜 독선적이지만 학습 곡선이 가파르고 기본 포함 기능이 적어, 스스로 해결해야 할 부분이 더 많습니다.
- 대량의 데이터를 자주 업데이트해야 하는 사이트에는 Next.js가 더 유리하다고 평가됩니다.
Next.js와 Gatsby.js의 공통점
사람들이 Gatsby와 Next.js를 비교하는 데에는 이유가 있습니다. 두 기술은 차이점보다 공통점이 훨씬 많습니다. 먼저 공통점을 살펴본 후 차이점을 논의해 보겠습니다.
Gatsby와 Next.js의 공통점:
- 둘 다 기본 설정만으로도 뛰어난 성능을 제공합니다.
- 둘 다 JavaScript 프레임워크이며 React 기반입니다.
- SSR(서버 사이드 렌더링)과 CSR(클라이언트 사이드 렌더링)을 모두 기본 지원합니다.
- SSG(정적 사이트 생성)와 DSG(동적 사이트 생성)를 모두 제공합니다.
- 코드 스플리팅과 우수한 캐싱을 기본 탑재하고 있습니다.
- 페이지 데이터 프리페칭(prefetching)을 지원합니다. Gatsby는 자동으로 처리하고, Next.js는
Link컴포넌트(라우팅용)에서 사용할 수 있는prefetchprop을 제공합니다. - 자체 라우터를 통한 페이지 자동 라우팅을 제공합니다(Gatsby는 Reach Router, Next.js는 Next.js Router 사용).
- REST API에서 데이터를 가져올 수 있으며, WordPress, Contentful, Prismic 등을 CMS 백엔드로 활용할 수 있습니다.
기본 상태에서 Gatsby와 Next.js는 SSR과 CSR이라는 두 세계의 장점을 모두 제공합니다. SSR은 SEO에 탁월하고, CSR은 네이티브 모바일 앱을 사용하는 듯한 부드러운 즉시 페이지 전환(새로고침 없이) 경험을 사용자에게 선사합니다.
Next.js와 Gatsby.js의 차이점
먼저 분명히 해두자면, 아래 내용은 각 프레임워크의 기본 제공 기능을 기준으로 한 것이며, 커스터마이징을 통해 잠재적으로 변모할 수 있는 가능성까지 포함한 것은 아닙니다. Next.js와 Gatsby 모두 매우 유연한 프레임워크입니다.
Gatsby와 Next.js는 사실상 "무한하게" 커스터마이징할 수 있습니다. 두 진영 모두 이 점을 강조하기 위해 애쓰고 있죠. "모든 사람에게 모든 것이 되고자 한다"는 고전적인 표현이 떠오릅니다. 어느 쪽도 잠재 고객을 놓치고 싶지 않기 때문에, 좋은 비즈니스 파트너답게 약점보다는 강점을 부각하는 데 집중합니다. 당연한 일이기도 합니다.
어느 쪽도 거짓말을 하는 것은 아닙니다. 하지만 Next.js와 Gatsby 모두 충분한 재정적 지원을 받으며 끊임없이 발전하고 있어서, 장기적인 관점에서 특정 용도에 어느 도구가 더 낫다고 단정하기는 어렵습니다.
필자는 어느 쪽에도 이해관계가 없으므로, 편견 없는 시각으로 말씀드리겠습니다. Next.js와 Gatsby를 구분 짓는 주요 영역은 다음과 같습니다:
- Gatsby는 GraphQL 사용을 강제합니다(독선적). 반면 Next.js에서는 선택 사항입니다.
- Gatsby는 이미지 변환 기능을 기본 제공합니다(다소 독선적이지만 강제는 아님).
- Gatsby는 이미지에 lazy-loading을 자동으로 적용합니다(독선적).
- Gatsby 사이트는 작은 플러그인 하나 설치만으로 PWA(프로그레시브 웹 앱)로 전환할 수 있습니다. Next.js에서는 이렇게 간단한 방법을 찾기 어렵습니다.
- Next.js는 동적 라우팅과 정적 라우팅을 모두 지원합니다. 필자가 확인하기로는 Gatsby는 정적/하드코딩된 라우팅만 제공하는 것 같습니다. 명확한 정보를 찾기 어려워 100% 확신하지는 못합니다(추후 확인되면 업데이트하겠습니다).
- Gatsby는 사이트 빌드(SSG) 단계에서 SSR을 수행합니다.
- Next.js는 페이지 요청 시점에 동적으로 SSR을 수행하지만, static export 기능을 통해 SSG도 제공합니다.
커스터마이징 측면에서 보면, Gatsby는 댓글부터 Algolia 검색까지 설치가 비교적 간단한 유용한 플러그인을 다수 보유하고 있습니다. Next.js는 GitHub 저장소의 /examples 디렉터리에서 다양한 라이브러리("플러그인")를 Next.js와 함께 사용하는 예제를 보여줍니다. 하지만 필자의 경험상 Next.js 예제를 구성하는 것이 Gatsby 플러그인을 사용하는 것보다 더 까다롭습니다.
동적 데이터 페칭
Gatsby는 기본적으로 정적으로 생성되지만, 다양한 서버 API를 쿼리하여 데이터를 동적으로 가져올 수 있습니다.
Next.js도 유사한 방식으로 동적 데이터 페칭이 가능합니다.
SSR이 필요하다면 Gatsby의 내장 GraphQL API를 사용하여 WordPress나 Contentful 같은 CMS("헤드리스 CMS")에서 데이터를 소비하고, CMS에서 제공하는 웹훅(webhook)을 활용해 콘텐츠가 게시될 때마다 자동 배포를 처리할 수 있습니다.
컨벤션 vs 설정
전반적으로 Gatsby가 두 프레임워크 중 더 독선적입니다. 그 장점은 결정해야 할 사항이 줄어든다는 점입니다. Next.js는 실행 환경을 구축하는 데 더 많은 설정이 필요하지만, 그 대가로 어떤 것도 강요당하지 않습니다.
Next.js는 "앱을 바닥부터 직접 구축"하는 방식의 제품으로, 일부 유용한 배터리(SSR, 라우팅, 프리페칭, 코드 스플리팅)가 포함되어 있습니다.
Gatsby는 "출발점에 어차피 원할 만한 것들이 이미 들어 있다"는 방식의 제품으로, 많은 배터리(GraphQL, 프리페칭, SSR, 코드 스플리팅, lazy loading, 이미지 변환)가 포함되어 있습니다.
제품의 구석구석까지 세밀한 커스터마이징이 필요하다면, 기본 상태가 더 "베어본(barebone)"에 가깝고(덜 대신 해주는 것이 적음) Next.js가 더 나은 선택입니다.
프레임워크에서 기능을 제거하는 작업부터 프로젝트를 시작하는 일은 결코 즐겁지 않습니다. 따라서 어떤 이유로든 GraphQL이 마음에 들지 않는다면 Gatsby는 적합하지 않습니다.
GraphQL은 현재 큰 인기를 얻고 있고(그럴 만한 이유가 있습니다), 그렇기에 Gatsby가 이를 프레임워크의 일부로 만든 것을 반대하기는 어렵습니다. 필자는 이것을 보너스라고 생각하지만, 여러분의 선호는 다를 수 있습니다. 참고로 Apollo(GraphQL 엔진)는 Next.js 앱에 가장 인기 있는 추가 요소 중 하나입니다.
Gatsby가 이미지 변환과 lazy loading을 대신 처리해주는 것은 독선적이긴 하지만, 이로 인한 막대한 성능 향상 덕분에 그 결정을 용서하게 될 것입니다. 물론 이미지 변환을 자신만의 방식으로 처리하고 싶다면 Next.js가 더 나은 선택입니다.
SEO 관점에서의 Gatsby vs Next.js
Gatsby와 Next.js는 모두 서버 사이드 렌더링을 기본 제공하므로, 훌륭한 SEO(검색 엔진 최적화)가 필요한 웹사이트—즉 오늘날 거의 모든 공개 웹사이트—에 모두 훌륭한 선택입니다.
하지만 Next.js가 Gatsby보다 빛을 발하는 특정 SEO 사용 사례가 있습니다.
Twitter나 Reddit처럼 끊임없이 콘텐츠 업데이트를 푸시해야 하는 플랫폼을 구축하면서, 모든 콘텐츠에 대해 최적의 SEO가 필요하다면 Next.js가 최선의 선택입니다.
왜 그럴까요? Next.js는 변경 사항이 발생하는 즉시 자체 서버에서 콘텐츠 업데이트를 동적으로 서버 사이드 렌더링할 수 있기 때문입니다.
반면 Gatsby에서 새 콘텐츠를 표시하려면 콘텐츠가 변경될 때마다 앱을 리빌드하고 재배포해야 합니다. 하루에 한 번 또는 한 시간에 한 번 정도 업데이트만 푸시하면 되는 블로그, 전자상거래 사이트 및 대부분의 다른 유형의 웹사이트에는 이 정도면 충분합니다.
반면 Gatsby 사이트가 외부 API에서 동적으로 데이터를 가져와 업데이트를 표시하는 경우(예: Talkyard나 Disqus 같은 댓글 서비스) 실시간 콘텐츠 업데이트는 가능하지만, SEO 혜택은 받을 수 없습니다. 업데이트가 클라이언트 사이드에서 렌더링되기 때문입니다. SEO를 위해서는 서버 사이드 렌더링이 필요합니다.
실무 관찰
규모가 큰 회사들은 Gatsby보다 Next.js를 사용하는 경향이 있습니다. 물론 오해는 마세요. ReactJS 공식 문서 페이지는 Gatsby를 사용합니다. 필자가 관찰한 바를 말씀드리는 것뿐입니다.
Next.js를 사용하는 대형 웹사이트:
- Marvel.com
- Netflix
- Uber Marketplace
- Invisionapp
- Material UI
Gatsby를 사용하는 대형 웹사이트:
- ReactJS
- MarvelApp.com
흥미롭게도 Marvel은 둘 다 사용합니다. 메인 사이트에는 Next.js를, MarvelApp(디자인 플랫폼)에는 Gatsby를 사용합니다.
블로깅과 관련해서는, 괜찮은 Next.js 블로그 예제는 몇 개밖에 보지 못했지만 훌륭한 Gatsby 블로그 예제는 상당히 많이 보았습니다. Tania Rascia의 블로그가 필자가 가장 좋아하는 예제 중 하나입니다.
Gatsby는 "블로거를 위한 또 하나의 정적 사이트 생성기"(Jekyll처럼)로 보이는 것을 원하지 않는다고 분명히 밝히고 있지만, 블로깅 분야에서 실제로 인기가 많다는 사실은 변하지 않습니다. 그리고 많은 WordPress 사용자가 그 이유로 Gatsby로 이동하고 있습니다(위에서 언급한 Tania 포함).
Gatsby 또는 Next.js와 함께 사용하는 헤드리스 CMS
많은 개발자들이 트렌디한 "헤드리스 CMS" 또는 "디커플드 CMS"에 대해 이야기하고 있습니다. WordPress를 백엔드로 사용하고, React(또는 Angular/Vue)를 통해 REST API/GraphQL로 데이터를 소비하는 방식입니다. Next.js와 Gatsby 모두 헤드리스 CMS 제품의 프론트엔드 앱으로 사용할 수 있습니다. 이론상 매우 유망해 보이지만, 지금까지 필자가 본 좋은 예제는 몇 개 되지 않습니다:
- Kata.ai의 Next.js + WordPress
- Chase McCoy의 Gatsby + WordPress
- Indigo Tree의 Gatsby + WordPress
- Adam Rasheed의 Gatsby + WordPress
Adam과 Chase의 Gatsby + WordPress 예제는 둘 다 정말 빠릅니다. 반면 Kata의 Next.js 예제는 웹사이트가 아름답긴 하지만 다소 느립니다. 고성능이 Next.js의 주요 판매 포인트 중 하나인 만큼, Kata의 예제는 Next.js를 WordPress와 함께 사용해야 하는 이유로는 가장 설득력 있는 사례가 아닙니다.
헤드리스 CMS는 아직 비교적 새로운 개념입니다. 헤드리스 WordPress뿐 아니라 헤드리스 CMS 전반이 2020년 이후로도 뜨거운 화두가 될 것임은 분명합니다. 그리고 Gatsby와 Next.js 모두 SSR을 대신 처리해주기 때문에, 헤드리스 프론트엔드로서 모두 훌륭한 선택지입니다.
Gatsby와 Next.js의 배포/호스팅
Gatsby는 배포 전에 정적으로 생성(프리빌드)되기 때문에 자체 서버 없이 어디서든 실행할 수 있습니다. 일반적으로 Next.js는 Node.js 서버가 필요하지만, Gatsby처럼 전체 앱을 정적 사이트로 export하면 예외입니다(네, 가능합니다). 일부 호스팅 솔루션은 한쪽에 더 특화되어 있습니다.
Gatsby + Netlify
Gatsby와 Netlify는 천생연분입니다. 사이트가 서버리스라면, Gatsby 사이트를 Netlify에 배포하는 것은 문자 그대로 30초 안에 설정할 수 있습니다.
gatsby-plugin-netlify 플러그인을 사용한다면, 이후 지속적인 배포는 터미널에서 git push origin master 명령 하나로 끝납니다.
Next.js + Now
Next.js는 Now 호스팅 서비스와 잘 어울리는데, 그 이유는 Now(호스팅 서비스)와 Next.js(프레임워크) 모두 Zeit라는 회사가 만들었기 때문입니다.
Netlify와 마찬가지로 Now에 배포하는 것도 몇 초 만에 가능하지만, 배포하는 앱의 유형에 따라 다릅니다.
참고: Gatsby와 Next.js가 특정 호스팅 서비스와 잘 어울린다고는 하지만, 정적/프론트엔드 Next.js 앱을 Netlify에 호스팅하는 것도 가능하고(예제 있음), Gatsby를 Now에 호스팅하는 것도 가능합니다(예제 있음).
두 프레임워크 모두 DigitalOcean, Heroku 등에 호스팅할 수 있습니다.
서버리스 방식 대신 Next.js 또는 Gatsby 앱을 위한 자체 백엔드 서버/API를 호스팅하고 싶다면 DigitalOcean, Heroku 또는 Now 같은 서비스를 살펴보세요. 단, Zeit의 Now v2.0부터는 Docker를 더 이상 지원하지 않는데, 이는 많은 개발자에게 치명적인 단점입니다.
Next.js vs Gatsby 배포 시간
Gatsby는 리빌드 후 재배포 과정에서 업데이트 지연이 발생합니다. 지연 시간은 사이트 규모에 따라 달라집니다. 사이트가 클수록 리빌드와 재배포에 더 많은 시간이 걸립니다. 필자는 최근 이 사이트를 Gatsby로 구축했는데, 비교적 작은 사이트임에도 리빌드부터 재배포 완료까지 약 2분이 걸립니다.
Next.js에는 이러한 리빌드 > 재배포 > 다운타임 문제가 없습니다. 자체 백엔드 서버를 운영하면 새 콘텐츠가 즉시 업데이트됩니다.
Gatsby가 다운타임이나 지연 없이 증분 업데이트를 쉽게 처리할 수 있게 된다면 이것이 문제가 되지 않겠지만, 현재로서는 websocket 등을 활용해 스스로 해결책을 찾아야 합니다.
참고 자료
- Postlight.com이 GitHub에 흥미로운 WordPress + Next.js 스타터 키트를 공개했습니다.
- 헤드리스 CMS의 경우, WordPress의 견실한 대안으로 Prismic, Contentful, Sanity, Ghost, ButterCMS 등이 있습니다.