JAMStack

과거에는 사용자가 서버에 요청하는 페이지마다 SSR(Server Side Rendering)을 통해 HTML을 만들어서 제공해 주었습니다. ‘jthcast.dev/login.jsp’, ‘jthcast.dev/home.jsp’처럼요.(물론 지금도 많습니다. 😞)

이후 기술이 발전함에 따라 SPA(Single Page Aplication)을 통으로 제공해 주었는데, SEO의 필요성에 따라 처음 요청받은 페이지만 SSR로 제공하고 그 이후는 마찬가지로 CSR(Client Side Rendering)로 정보를 제공하였습니다.

그리고 최근엔 각 페이지를 HTML로 만들어 캐시 한 후 이를 저장소에서 제공하는 형태로 이루어지는 서비스 형태가 생겼습니다. 따로 SSR할 서버가 필요 없는 Javascript, Api, Markup만 필요하므로 이를 JAMStack이라고 부르고 있습니다.

즉 JAMStack 이란, Javascript와 HTML Markup된 정적인 페이지만을 제공한 후 필요하다면 Api 호출을 통해 데이터를 주입받는 형태입니다.

정적 사이트 생성기(SSG, Static Site Generator)

앞서 설명한 JAMStack은 정적 사이트를 제공해야 합니다. 손으로 HTML을 마크업 할 수도 있겠지만, 이 정적 사이트를 쉽게 제작해 주는 프레임워크가 존재합니다.

이 프레임워크는 쉽게 데이터를 주입하고 템플릿화 하여 페이지를 만들어낼 수 있으며, Prefectch와 같은 강력한 기능을 제공하고 있습니다.

이러한 프레임워크를 정적 사이트 생성기라고 부르며 Jekyll(Ruby), Hugo(go), Gatsby(react), Next.js(react) 등 여러 가지가 존재합니다.

저는 React를 주로 사용하므로 Gatsby와 Next.js 중에 선택하기로 결정하였는데, 둘 중에 무엇을 선택할지가 굉장히 어려웠습니다. 🤔

gatsby-vs-next-npmtrends
Npmtrends에서는 Next.js가 앞서고 있습니다.

Gatsby

우선 Gatsby를 먼저 알아보겠습니다. 저는 Gatsby를 이 블로그를 만드는데 사용했습니다. Next.js를 두고 선택한 이유는 GraphQL을 사용해 보고 싶다는 것, 그리고 Gatsby에서 지원하는 Image 플러그인이 굉장히 잘 돼있어서 블로그를 꾸미는 데 더 적합하다고 판단했습니다. (Next.js에서 지원하는 것과 다르게, Blur up 기능을 지원합니다. 근데 정작 블로그에는 일부러 사용 안 했어요. 이유는 생각보다 안 예뻐서.. 😅)

사용 후 느낀 장점과 단점을 요약하면 아래와 같습니다.

장점

  • GraphQL을 사용하여 내부 데이터를 조회합니다. GraphQL은 진짜 선녀에요.
  • 플러그인 및 커뮤니티 생태계가 풍부합니다.
  • 오직 SSG에 집중하여 SSR로 인한 이슈가 없습니다.

단점

  • Gatsby Officiar 플러그인의 업데이트가 늦습니다.
  • SSR을 지원하지 않습니다.
  • 공식 홈페이지의 정보가 최신이 아닌 경우가 많습니다.
  • 알 수 없는 프레임워크의 도움 기능, 최적화 기능 때문에 버그 혹은 오류가 생기는 부분이 존재합니다.

전체적으로는 매우 만족했습니다만, 프레임워크에서 통제하는 부분에서 문제가 있는 경우가 몇 가지 존재했습니다.

  1. favicon이 svg 타입인 경우 icon 파일을 만들 때 무한 빌드가 되는 현상입니다. 취소했다가 다시 빌드 하면 정상 작동이 되며 호스팅 업체의 컴퓨팅 과정에서는 발생하지 않고 로컬에서만 발생했습니다.
  2. 빌드 시 사용하지 않은 CSS Module이 실행되며 오류 로그를 남겨놓는 현상입니다. 저에겐 아직까진 문제가 되고 있지는 않지만, 검색을 해보니 문제를 겪는 분도 계신듯합니다.

Next.js

개인 프로젝트로 TechBlogPosts를 개발할 때 Next.js를 사용했습니다. Gatsby에서 마이그레이션 하는 방법까지 제공할 정도로 튜토리얼 및 문서가 아주 잘 되어있습니다. 덕분에 블로그 개발에 사용하던 소스 대부분을 그대로 가져다 쓸 수 있었습니다.

장점

  • SSG뿐만 아니라 SSR도 지원합니다.
  • 홈페이지의 기술 문서가 아주 잘 되어있습니다.
  • 예상치 못한 프레임워크의 작동이 없습니다.

단점

  • 기본 지원 플러그인이 약간 불편합니다.
  • SSR로 인한 라이브러리 호환성 이슈가 존재합니다.
  • Gatsby에 비해 자동화가 부족하여 직접 Node 코드를 작성하는 경우가 많았습니다.

Gatsby로 프로젝트를 진행 후, Next.js를 써서 그런지 Gatsby에 비해 프레임워크로서 자동화가 부족하다는 느낌이 들었습니다. 하지만 이 부분은 오히려 선택의 폭이 그만큼 넓다고도 생각할 수 있습니다. SSR을 할지 SSG를 할지, GraphQL을 쓸지 fetch를 쓸지 등 Gatsby에 비해 개발자로서 선택할 기회가 많았습니다.

Next.js 또한 전체적으로 만족했습니다만, 마찬가지로 몇 가지 문제를 겪었습니다.

  1. React Router를 사용하지 못합니다. 자체 제작된 next/link 라이브러리를 사용하여야 하는데 activeClass 등 익숙하게 사용하던 것을 지원하지 않아 직접 구현해야 했습니다.
  2. Gatsby에서는 자체 지원하는 GraphQL로 데이터를 뚝딱 꺼내오던 것을 직접 Node 코드를 작성하며 꺼내와야 했습니다. 이처럼 사용자가 직접 Node 코드를 작성해야 하는 경우가 Gatsby에 비해 많았습니다.

마치며

Gatsby와 Next.js는 둘 다 SSG로써 손색이 없는 프레임워크입니다. 둘 다 사용해보고 느낀 결과 어떤 것이 우월한지 겨루는 것은 의미가 없다고 판단하였습니다. 😅

성능을 가지고 결정하기보다는, 사용 목적과 개발 성향으로 접근해야 한다고 생각합니다.

개발하는 애플리케이션의 볼륨이 작은 경우에는 플러그인이 빠르게 뚝딱 처리해 주는 Gatsby가 유리하다고 생각되었으며, 볼륨이 중간 이상 되는 경우에는 개발자가 직접 선택하고 제어하는 Next.js가 유리하다고 느꼈습니다.

JAMStack으로 두 가지 프로젝트를 진행하며 기존 Create react app으로 작업한 경우보다 결과물의 속도와 SEO 면에서 정말 만족했습니다. 특히 클라우드 환경과 조합하여 사용하는 경우 최고의 개발 경험을 하실 수 있을 것입니다. 앞으로 JAMStack이 더 많이 사용될 것이라 생각하며 JAMStack + Cloud 조합을 강력 추천드립니다. 💯