관심 있게 보는 개발 유튜브에서 next.js 리액트 프레임워크에 대해서 리액트를 배운 후 찾아볼 것을 추천하였고, 채용공고에서도 사용 여부를 원하는 경우를 많이 보았다. 많이 사용하고 추천하는 데는 분명히 이유가 있을 것이라 생각이 들고(아직은 이 단계라고 생각한다.), 분명히 장점이 존재할 것이라는 전제를 깔고 어떤 자료를 통해 학습을 할까를 찾아봤다. 제일 먼저 자주 애용하는 인프런에서 강의로 제작된 부분은 없는지 확인 후, 없는걸 확인하고 개발 오픈 채팅방에 도움을 구했더니 어느 한 분이 공식 문서를 추천해 주셨다. 첫 공부를 공식 문서로 시작하기엔 좀 어렵지 않을까 싶었지만, 다른 공식 문서에 비해 유독 잘 나와있다는 말을 믿고 도전해 보기로 했다. 튜토리얼의 첫 번째로 기존의 리액트로 애플리케이션을 만들 때 어떤 점을 보완해 주는지부터 시작했다. 이 부분을 읽은 후의 첫 느낌은 기존에 리액트를 사용하면서 고민했던 부분을 해결해 주는 느낌을 바로 받아 충분히 배울만한 가치가 있다고 느꼈고, 바로 배워보고 싶었다. 항목은 다음과같다.
1.어떤 점을 보완해 주는가.
1) 코드 스플리팅(code-Spliting) 자동지원.
무작정 만들었던 프로젝트에 대해서 최적화를 경험해 보고자 구글링을 한 결과 spa로 동작하는 리액트 특성상 번들링 사이즈가 커지게 되면 처음 유저가 페이지에 접근했을 때 모든 자바스크립트 파일을 한 번에 받아옴으로 첫 화면을 보기까지가 오래 걸린다고 한다. 따라서 최적화로써 할 수 있는 조치는 이를 한 번에 전부 불러오지 않고, 해당 페이지에서 필요한 js 파일만 불러올 수 있도록 조치를 취해주면 된다.(물론 이렇게 되면 페이지를 전환했을 때 해당 페이지를 구성하는 js에 대한 요청 시간은 감수해야 한다.) 이를 실질적으로 구현하는 코드로는, 웹 팩에서의 진입점 분리(코드 스플리팅), 동적 임포트가 있다. 하지만 웹 팩에 대해서 강의를 통해 배우면서 느꼈지만, 프로젝트 규모가 커지면 진입 전을 분리해 추가해 주는 과정( +분리로 인해 발생하는 중복된 빌드 파일 제거 설정), 동적 임포트 시기 등을 고려하면서 작성하게 되면 프로젝트구조를 이해하는 데 혼란을 줄 수 있을 것 같다는 생각이 들었다. 이를 next.js에선 자동으로 지원해 준다는 점이 결국엔 최적화에 대해서 어느 정도 해결해 준다는 의미로 받아들였다.(뭔가 코드 작업이 점점 더 자동화돼가는 느낌이 든다. 리액트의 cra, next.js의 코드 스플리팅 지원)
2) 서버사이드 렌더링.(pre-rendering)
개발 유튜브에서도 이 부분에 대한 이점을 강조했었고, 실제로 공부하면서 spa, csr 등 정확한 이해를 위해 알고 있어야 하는 추가적인 렌더링에 대한 지식을 자연스럽게 더 공부하게 됨으로써 이전보다 좀 더 성장했음을 느끼게 해주는 개념이었다. 위에서도 언급했지만 리액트는 spa로써 동작하기 때문에 초기 로딩 속도가 느리다. 이에 대한 장점으로는 초기 로딩 이후로는 추가적인 파일을 받아오지 않기 때문에 화면전환이 빠르다( 서버로부터 불러오지 않기 때문에 화면 깜빡임 현상이 나타나지 않게 된다). 또한 페이지 내에서 이벤트를 발생시켜 화면을 변화시키는 일이 발생한다면(좋아요를 눌렀을 때 좋아요 색이 칠해진 페이지를 보여주는 상황) 이를 서버로 요청하여 좋아요가 칠해진 페이지를 받아오는 형식이 아닌 js로 돔 을 조작하여 별도의 페이지 요청 없이 바로바로 바뀐 부분을 업데이트해주기 때문에 좀 더 인터랙티브한 페이지를 만들 수 있게 해준다. 이러한 기존의 spa의 특징 중에서 어떤 부분을 next.js는 보완을 해주는 것일까를 생각해 보면 우선 공식 문서를 읽어본 결과 기존에 공부하기 전에 알고 있던 서버사이드 렌더링은 pre-rendering을 가리키는 용어이지 않았을까 싶다. 이 pre-rendering는 html 파일을 빌드 시간에 만드냐, 런 타임에 만드냐에 따라 1.static-site-generation, 2.server-side-rendering 이렇게 두 가지로 나뉘게 된다. 빌드 시간이란 배포하기 전, 빌드 파일을 만들 때를 의미하고 런타임이란 애플리케이션이 빌드 되고 배포까지 완료된 상태에서 사용자의 요청이 발생했을 때 이를 처리하는 시간 중을 나타낸다. 그래서 이 pre-rendering의 장점이 무엇이냐라고 하면 우리가 리액트에서 작성했던 jsx 문법 중 html에 해당하는 부분을 미리 만들어준다. 좀 더 세분화하면 예를 들어 버튼에 onClick 함수를 달아놓았다고 가정하면, 이 onClick 함수는 클라이언트단에서 적용시켜주고 버튼 태그 자체는 이미 만들어 놓게 된다. 그래서 결론적으로 TTV(time to view)의 시간이 CSR로 렌더링을 하게 되었을 때보다 단축되게 된다. 또한 이런 미리 만들어 놓을 수 있는 특징으로 1. 검색엔진을 다루고 있는 구글, 네이버 같은 포털 사이트에서 크롤링 하여 사이트를 찾을 때 html이 미리 만들어져 있기 때문에 원하는 페이지에 대해서 SEO를 보장해 준다. 2. cdn을 활용하여 응답속도를 더 빠르게 높일 수 있다. 확실히 next.js가 장점이 있고, 화면 렌더링에 있어서 다양한 선택지를 제공하는 기능들이 있다고 생각한다.
3) 이외기능
우선은 전체적인 느낌은 이렇다. 뭐 추가적으로 리액트에서 사용했던 router 라이브러리에 대한 지원, 이미지 리사이징 지원, SWR을 통한 CSR에서의 중복 요청 제거 등등 react에서 부족한 부분들을 많이 지원해 주는 느낌을 받았는데 이 부분은 이후에 코드를 통해서 좀 더 확인하면서 진행해 보겠다.
2.공식문서를 읽고나서 느낀점
공식문서가 다른 문서에비해 읽기쉽게 작성되어있었고,(비록 영어지만 번역기돌려가면서 볼만했다) 혹시라도 공식문서를통해 next.js에대해서 공부해보고싶다면 create a next.js App 부분앞에있는 foundations부분먼저 읽어보라고 추천하고싶다. 이부분이 왜 처음봤을떄 안보였는지모르겠는데 create a next.js App를 시작으로 공부해본 입장으로봤을때 create a next.js App첫 부분에 소개되어있던 여러 장점들을 알기쉽게 작성해놓았다.(어쩌면 앞부분에있으니 당연한 말이긴한데..) 무튼 어느정도의 배경에대해서 이해가 되었다라고 생각이들어 다음엔 직접 코드를 통해 확인해보는 글을 작성하겠다.