[프로젝트][WAVED] Next.js를 선택했다고 끝난게 아니다? 라우팅 방식과 렌더링 방식에 대한 고민들

 

 

때는 Sprint1. 웨이브드의 대략적인 기획이 완료되어 프로토타입 디자인을 기다리던 중이었다. 이 기간 동안 프로젝트 스케폴딩을 하고 기술 스택을 확정하는 시간을 가졌다. 프론트엔드 3명이 모두 다룰 수 있는 React는 확정인 상태였기 때문에 React의 개발 도구 선택지로 Vite와 Next.js 중에서 고민했다.

 

 

Vite vs Next.js

https://ko.vitejs.dev/

Vite

Vite는 React 등 다양한 프레임워크를 지원하는 빌드 도구로 '차세대 프론트엔드 개발 도구'라는 슬로건을 걸고 있다. CRA(create-react-app)과 비교하여 빠른 응답 속도와 개발 편의성을 지원한다. 우리 팀의 모든 프론트엔드 개발자들은 모두 Vite 사용 경험이 있고, React 프로젝트에서 필수로 사용할 만큼 긍정적이었다.

 

https://nextjs.org/

Next.js by Vercel - The React Framework

Next.js는 React 기반의 프레임워크이다. React 문법을 그대로 사용하면서, React가 제공하는 유일한 렌더링 방식 CSR(client-side rendering) 뿐만 아니라 SSR(server-side rendering)와 SSG(static site generation) 등 다양한 렌더링 방식을 사용할 수 있다. 최근 가장 핫한 React 프레임워크라고 봐도 무방했다.

Vite와는 달리 Next.js는 팀원 중 사용 경험이 있는 사람은 단 한 명, 나머지는 전혀 모른다고 볼 수 있었다. 만일 기술 스택으로 선택하게 될 경우, 공부와 동시에 프로젝트를 진행해야 하는 상황이었으나.. 그럼에도 불구하고 우리는 Next.js를 사용하기로 결정했다!

 

나를 포함하여 모두들 새로운 기술을 선호했다. 사실 프로젝트만큼 빠르고 확실하게 새로운 기술을 흡수하는 방법은 없다고 생각한다. 특히 Next.js는 최근 프론트엔드 생태계에서 가장 핫하다고 여겨지기에, '왜 Next.js가 핫한지'를 느낄 이만한 기회는 없을 것 같았다.

 

 

 

App Router vs Pages Router

Next.js를 선택한 이후 놓인 두 번째 고민.. 바로 라우팅 방식이다.

 

Next.js는 기존까지 Pages Router만을 지원하다가, 22년 10월 26일 대규모 업데이트가 일어난 Next.js 13을 통해 App Router를 추가로 지원하게 됐다. 13이 특히 파격적인 업데이트로 평가받은 만큼 다양한 시도가 많았고 App Router도 그중 하나다. 때문에 Page Router의 단점을 보완하기 위해 나온 방식이지만 버그가 존재하는 등 아직은 불안정하다는 것이 전반적인 평가였다.

next.js doucment 내 선택지. 어떤 Router를 선택하느냐에 따라 문서 내용이 다르다

 

 

우리는 두 Routing 방식의 차이점에 집중하기보다는 안정성에 초점을 맞춰 선택을 고민했다. 프로젝트를 진행하는 시점은 24년 2월, Next.js는 14를 발표하며 App Router의 불안정함을 일부 보완했지만 그래도 아쉬운 점이 있단 평가가 많이 보였고, 결론적으로 '그래도 전부터 누적된 문서가 많을 Page Router 방식이 더 안정적일 것이다'라는 의견에 따라 Page Router를 채택하고 스케폴딩을 진행했다.

(+ 사실 이후 프로젝트 진행 중에는 이 선택을 좀 후회했다. 우리한테만 그렇게 보이는 건가 App Router 관련한 문서 또는 레퍼런스들이 생각보다 많았고, Page Router의 단점을 느낄 상황이 종종 발생했다. 이후에 프로젝트를 진행한다면 App Router를 채택할 것이다.)

 

 

 

페이지 별 렌더링 방식 선택하기

Page Routing을 선택하고 나니 다음 고민은 서비스의 페이지 별로 어떤 렌더링 방식을 사용할지에 대한 것이였다. Next.js가 지원하는 렌더링 방식을 CSR / SSR / SSG / ISR 4가지로 분류해 각 방식의 용도와 장단점을 정리하고 어떤 페이지에 사용해야 할 지 미리 고민해 봤다.

깊은 고찰의 흔적 11

깊은 고찰의 흔적 22

 

나름대로 세웠던 기준은 아래와 같다.

• 검색 엔진 최적화(SEO)가 된다면 좋을 것 같아 => SSR
• 반대로 고객의 데이터여서 검색에 노출되면 안 돼 => CSR
• 초기 렌더링 이후 사용자와의 상호작용이 없거나 그 비중이 작아 => SSR + 상호작용 있을 때마다 useEffect 활용
• 반대로 사용자와의 상호작용이 많아 => CSR
• 빌드 이후 변경되는 내용이 없어 => SSG
• 모두가 같은 화면을 봐 => SSG
• 빌드 이후 변경되는 내용이 거의 없는데 필요할 수도 있어 => ISR

 

 

이렇게 대략적인 렌더링 방식을 지정해 두고 나머지는 직접 페이지를 작업하면서 변동사항이 있다면 반영하기로 했다.

Next.js의 다양한 렌더링 방식에 대해 개념만 습득하는 것이 아닌 실제로 어떤 방식을 채택해야 좋을 지에 대해 상세하게 고민해 보는 기회였다 🤔