왜 Next.js를 사용할까?
이 글은 사내 세미나 자료를 바탕으로 작성되었습니다. 틀린 내용이 있을 수 있습니다. leetekwoo@gmail.com으로 질문 혹은 피드백 주시면 정말 감사하겠습니다!
꼭 Next.js를 사용해야할까? 프로젝트 리빌딩에 Next.js 사용이 결정되었다. 전직장에서 사용한 경험이 있었지만 팀원 중 다수는 경험이 없었고, 학습에 대한 부담을 느꼈다. 팀원들의 부담감을 덜어주기 위해서, 생각보다 어려운 것이 아님을 전달하고자 발표를 준비하게 되었다.
어떤 점이 좋고, 왜 사용해야하는지를 설득하기 위해 발표를 준비하면서 선뜻 답하기 어려운 의문이 생겼다. 대체 왜 쓸까? 이 블로그를 개발하면서도 사용했기에 면접에서 자주 받던 질문이었다. 그리고 매번 SEO 대응이라는 틀에 박힌 대답을 하면서도 늘 꺼림칙했다. 뒤늦게 알았지만, CSR 또한 대부분의 검색엔진에서 SEO 대응이 가능하다. 그럼 굳이 더 쓸 이유가 없지 않나?
Next.js를 사용하는데 분명한 이점들이 있다. 또한 최근의 업데이트를 통해 조금 더 선명한 이유가 생겼다. 장단점을 살펴보면서 이 프레임워크를 선택하게 될 이유를 따져보고자 한다. 따라서 이 글은 Next.js의 깊은 곳 보다는, 사용 목적에 중점을 두고 가볍게 살펴볼 것이다. 아직 Next.js를 도입하지 않았거나, 사용 중이어도 그 이유를 모르는 나같은 주니어들에게 조금이나마 도움이 되길 바란다. 혹은 왜 서버사이드 렌더링이나 next.js를 공부해야 하는지 납득이 가지 않는 분들에게 약간의 힌트가 됐으면 좋겠다.
1 Next.js란?
빠른 웹앱을 만들기 위한 리액트 프레임워크이다. 프레임워크이기에 따라야하는 기본적인 구조가 있고, 자동화된 부분이 많다. 예를 들면 SWC라는 성능 좋은 내장 컴파일러가 있으며, 많은 경우 컴파일러를 크게 손 볼 일이 없다. (기존 webpack보다 7배 빠르다고 한다.) 또한 file-based routing이 적용되기에, 라우팅 경로를 따로 개발할 필요가 없다. DX, UX와 관련된 핵심적인 부분을 큰 수고없이 미리 해결해주기 때문에 확실히 생산성이 올라간다. 폴더 구조 등 프레임워크가 강제하는 규칙들 때문에 CRA의 가이드라인 없는, 가능성의 혼란 속에서 Next.js 한줄기 빛처럼 느껴지기도 한다.
2 Next.js의 장단점
이어서 Next.js의 장단점에 대한 간략한 리스트를 먼저 살펴보자. 상당히 주관적으로 작성되었기에 피드백 주시면 감사드리겠습니다.
장점
- 쉽고 빠르게 습득할 수 있다.
- 더 나은 DX (developer experience)
- 많은 부분을 간소화시켜준다
- 서버사이드 렌더링 (SSG, SSR, ISR)
- 성능 (최적화, 캐싱, 서버사이드 렌더링)
- 리액트 18에 빠르게 대응하고 있다.
단점
- 프레임워크가 알아서 해주는 부분이 많다.
- 프레임워크 자체의 문제라면 해결하기 상당히 까다롭거나 불가능할 수 있다.
- 프레임워크가 처리해주는 부분을 이해하지 못하고 넘어가기 쉽다.
- 많은 부분이 바뀔 예정이다. (Next.js 13)
- 한 회사(vercel)에 종속적인 느낌이 든다.
- 그들의 주장만큼 오픈소스로 느껴지지 않는다.
- 상대적으로 레퍼런스가 부족하다.
- 더 의견이 있으시다면 꼭 알려주세요. (너무 궁금합니다.)
3 UX / DX
위의 장점들은 상당 부분 성능(UX)과 개발자 경험(DX) 개선과 관련된 것을 알 수 있다. 이젠 처음 들었던 의문에 당연히 UX와 DX 개선을 들고 싶다. 그럼 구체적으로 어떤 부분에서 성능 개선에 도움이 되는걸까?
- SWC - 더 빠른 컴파일러 특히 swcMinify는 빌드 개선에 큰 도움이 된다. (참고 자료)
- Sever Side Rendering
- 공식문서에서도 권장하듯이 사이트 정적생성 SSG이 주는 성능 상의 이점이 크다.
- 성능 상의 우위를 차지할 수 있는 여러 서버사이드 렌더링 방식을 제공한다.
- FCP 단축으로 CSR에서의 화면 깜빡임 문제를 해결할 수 있다. UX 개선으로 이어진다.
- 이전까지 애매했지만 리액트 Suspense와 함께 사용하여 성능 개선이 가능해졌다. (Streaming SSR)
- 리액트 서버 컴포넌트와 유사하다. 리액트 18로 마이그레이션 후 RSC 또한 어렵지 않게 터득할 수 있을 것이다.
- 적절한 캐싱이 가능하다. 특히 정적 사이트 생성과 함께 사용하면 큰 성능 개선을 이룰 수 있다.
- 리액트의 Suspense를 가장 빠르게 대응하고 있다.
출처 : 리액트 베타 공식문서 Suspense
- next/image 컴포넌트를 이용한 이미지 최적화, 폰트 자동 최적화 등 편리한 최적화 도구를 제공한다.
- 이미지 도메인, rewrite, redirect config를 이용한 보안 개선.
- Vercel을 사용하여 자동화 배포 또한 매우 간단히 할 수 있다.
- 초기 설정, 캐싱이 어렵지 않다.
이 블로그 또한 Next.js의 성능 최적화 덕을 많이 보았다. DX에 대해선 따로 리스팅을 하지 않았는데, 써보시면 알 것이다. (이제는 react-router-dom이 잘 기억나지 않는다.) 앞서 프레임워크가 많은 부분을 알아서 처리해주기 때문에 되려 많은 걸 모르고 지나칠 수 있다고 하였는데, Next를 쓰다가 CRA로 돌아가면 약간 위화감이 들 수 있다. 하지만 여전히 Next.js는 리액트 프레임워크이기에 크게 어렵지 않을 것이다. 오히려 문제는 프레임워크 자체의 오류와 한계, 빌드 에러, 호환성 문제처럼 더 깊은 곳에 있다.
4 사전 렌더링 Pre Rendering
서버사이드 렌더링에 대한 언급이 많았는데, Next.js의 핵심 개념이 사전 렌더링이기 때문에 함께 살펴보면 좋다. Next.js는 기본적으로 모든 페이지를 사전 렌더링 (Pre-Render) 한다. 서버사이드 렌더링을 위해 실행되는 getStaticProps, getServersideProps 함수는 프론트 프로젝트의 서버에서 실행된다. 이 점을 몰라서 백엔드에서 무언가 처리를 해주어야 하나 고민할 필요는 없다. 공식문서의 사전 렌더링을 읽어보자.
사전 렌더링
기본적으로 Next.js는 모든 페이지를 사전 렌더링합니다. 이는 Next.js가 클라이언트 측 자바스크립트에 의해 모든 것을 수행하는 대신 각 페이지에 대해 미리 HTML을 생성한다는 것을 의미합니다. 사전 렌더링을 수행하면 성능과 SEO가 향상될 수 있습니다. 생성된 각 HTML은 해당 페이지에 필요한 최소한의 자바스크립트 코드와 연관되어 있습니다. 페이지가 브라우저에 의해 로드될 때, 자바스크립트 코드가 실행되고, 페이지를 완전히 상호작용하게 만듭니다. (이 과정을 Hydration라고 합니다.)
5 마치며
Next.js 사용의 이점에 대해 간략히 살펴보았다. 간단한 내용이라 참고가 될지는 모르겠다. 마지막으로 꼭 하고 싶은 얘기는 Next.js를 새로운 언어를 학습하는 것만큼이나 어렵게 생각할 필요가 없다는 점이다. Next.js를 사용하면서 느끼는 점은 도구는 편하게 쓰기 위해 사용한다는 점이다. 많은 경우에 대해 프레임워크가 이미 대비를 해두었다. 우리는 그저 사용법을 익히고, 적절한 상황에 가져다 쓰면 될 뿐이다. 특히 취업 준비를 하면서 타입스크립트니, SSR이니 너무 겁먹을 필요 없다. 개인적으로 직접 사용하고, 그 후에 공식문서를 살펴보는 방법을 선호하는데, 아직 사용해보지 않으셨다면 간단한 앱을 만들어 보시는 걸 추천드린다.
긴 글 읽어주셔서 감사합니다!
6 참고자료
- 스트리밍 SSR : https://www.youtube.com/watch?v=9xl9X2pfHeI
*너무 좋은 발표이니 꼭 보셨으면 좋겠다!* Next.js 뿐만 아니라, 리액트 18의 서버 컴포넌트와 use, cache 훅에 대해 조리있게 설명을 잘해주셨다. 제발 보세요.
- 서버 사이드 렌더링과 관련된 공식 문서의 번역
- SSR 공식문서 번역 https://teklog.site/blog/25
- SSG 공식문서 번역 https://teklog.site/blog/24
- ISG(ISR) 공식문서 번역 https://teklog.site/blog/26
- 리액트 베타 문서의 Suspense : https://beta.reactjs.org/apis/react/Suspense