열심히 만져본 next와 nuxt

SSR의 양대 산맥

 

nextjs와 nuxtjs는 SSR의 대표주자로 각각 vue와 react 문법을 사용하여 서버사이드 렌더링을 지원 해 줍니다.
기존의 CSR만 사용하던 프레임워크의 구조와 다르게 각각 서버영역코드, 클라이언트영역코드 등 2가지 형태로 구분되는 것 또한 러닝커브에 높은 영향을 끼치지 않았나 싶습니다.

---

몇몇 프로젝트를 진행하면서 제가 느껴본 SSR 특징을 정리 해 보았습니다.

어디까지나 주관적인 생각 입니다!

1. 디렉토리 구분
next와 nuxt 프레임워크는 디렉토리를 구분하여 컨벤션을 강제로 정의 합니다.
예를 들어 "pages 디렉토리는 뷰 파일을 보관", "components 디렉토리는 클라이언트용 컴포넌트를 보관" 등 역할을 아에 나누어 놓았습니다.
이렇게 코드의 표준화 및 유지보수성을 위해 채택한 전략은 어느정도의 규칙을 통해 일관적인 생산을 유도하는 데 큰 도움이 되지 않았나 싶습니다.

2. 정적 페이지(SSG)와 동적 페이지의 구분
정적 페이지를 구분짓고 재 사용이 가능하기 때 문에 클라이언트의 지연속도를 줄일수가 있습니다.
next에서는 기본적으로 SSR을 사용하기 때 문에 "use client" 를 활용하여 클라이언트를 명시할 수 있습니다.
nuxt에서는 동적 페이지를 명확하게 하기 위해서 <ClientOnly> 테그를 사용해야 합니다.
또한 플러그인이나 추가 기능을 부여하기 위해서는 plugin 디렉토리에 .client 또는 .server를 명시 해야만 적용해야되는 대상을 구분지을수가 있었습니다.
nuxt에서는 스크립트가 들어가는 자체가 클라이언트로 되어 있기에, 서버코드를 혼재해야하는 경우에는 공식 doc를 일일이 보면서 어떠한 함수인지 확인한 후 적용해야 했습니다.(nuxt에서 서버용 코드는 async같은게 전반적으로 붙어있었습니다)

그렇다보니 next가 좀더 서버코드와 클라이언트 코드가 구분되기 쉽다라고 느꼈던 부분이 이러한 부분이였던 거 같습니다.

next에서는 딱 보입니다!

nuxt에서는 ClientOnly를 하거나 async 같은 함수를 사용 해 주어야 합니다.

3. 라우팅의 편리함
pages 같은 디렉토리를 만들어 두고 원하는 디렉토리를 추가하면 알아서 라우팅해야 되는 페이지로 이동이 가능한 것이 정말 좋았습니다.
예전에는 무슨 요청이 들어오면 어디가라 어디가라 일일이 다 해 주어야했는데...
알아서 스스로 해 주니 참 좋았던 거 같습니다.

4. 서버 API 개발 가능
API의 엔드포인트를 직접 만들 수 있는점도 좋았던 거 같습니다.
api 디렉토리에 각각 원하는 코드를 넣으면 코드 자체가 서버에서 요청하는 방식으로 전달되니 따로 cors에 대해서 신경쓰지 않아도 되었습니다.

물론 DB 같은 서버에도 접속은 가능 했습니다(RDB, 레디스 등)

그렇지만 그러한 행위는 클라이언트 프로그램 같지가 않아서..연습삼아만 해 보고 적용은 하지 않았습니다.

5. 간단한 소셜 로그인 연동 기능
next-auth를 활용하면 소셜 로그인 연동은 무척 쉽게 가능했었습니다.
대부분의 연동이 가능하였으며 심지어 카카오, 네이버도 존재 하였습니다!!

마찬가지로 사용자가 구현한 일반 서버와의 연동도 가능하였기에, 로그인과 관련된 스트레스를 줄일 수 있었습니다.

로그인에 성공하면 next와 nuxt는 둘다 세션쿠키 기반에 정보를 저장하였으며 getUserSession 같은 함수를 사용하여 서버, 클라이언트 등 분리하여 로그인 정보를 가져와 사용가능 하였습니다.

6. 프리패칭 전략을 활용한 데이터 재사용
어떠한 가게의 메뉴를 보여주는 기능이 있다고 가정햐아 봅니다.
그러한 경우 서버에서 데이터를 미리 불러온 뒤 이후 재사용을 하게 된 다면 로딩속도를 개선할 수가 있었습니다.
next에서는 fetch 함수나 탠스택쿼리를 활용해서 구현이 가능했으며, nuxt에서는 useAsyncData 함수를 써야 가능했었습니다.
역시나 next가 구분짓기는 좀더 좋았습니다.

왜 nuxtjs에서는 클라이언트와 서버의 경계선을 명확하게 하지 않는지 좀 아쉬웠습니다.

그래서 제가 느낀 두 프레임워크의 차이는 아래와 같았습니다.

 

서버코드와 클라이언트 코드가 깔끔하게 분리됨을 원하면 next가 좋았고,
뷰를 사용하고 싶으면 nuxt가 좋았던 거 같습니다.(속도도 nuxt가 빠르다고는 합니다)

---

 

끝으로..

어디선가 본 글에..
"nextjs를 사용하면 생산성이 좋아지고.." 라는 내용의 글을 본 적이 있는데,
next든 nuxt든지간에 생산성은 안좋아 집니다.
정적 페이지 로딩 또는 패칭 같이 성능이나 기능을 위해서면 모를까..

클라이언트와 서버사이드를 고려해야 하므로 오히려 더 작업이 오래 걸렸습니다.
어디까지 정적으로할지, 동적으로할지 구분 지을지 매 고민을 해야 했으며,
특히 하이드레이션과 디하이드레이션 부분 이슈에 대해서 매번 신경써야 했기에, 개발시 관리해야되는 포인트가 더 늘어나게 되었던거 같습니다.
마치 내가 클라이언트를 개발하고 있지만 jsp로 무언가 개발하는 듯한 느낌이 무척 강해서..
이게 클라이언트인가 풀스택인가 햇갈릴 때도 많았습니다.

용량 이슈도 존재 하였습니다.
도커로 빌드만 해 보아도 용량은 거진 10배이상 next나 nuxt가 훨씬 큽니다.
vuejs나 react를 nginx에 묶어서 배포하면 10~20메가 내외이지만, 이 두 친구는 기본 200mb 내외 입니다. (큰 이미지가 없다는 가정)
만약 aws의 ecr을 운영중이라면 매번 용량체크 필수가 될 것 입니다.

SSR 기술인 next와 nuxt를 도입한다면 정말 규모가 있는 프로젝트가 아니면 비추합니다.
규모가 크고 다양한 기술이 요구 된 다면 SSR을 도입 해 보는 것도 좋다 생각합니다.
그래도 프론트엔드 개발자이면 꼭! 한번쯤 경험하여 보세요!!