원래는 하루 단위로 수행해야하는 일정인데.. 하루에 소화하기에 분량이 상당히 넉넉하게 잡혀있어, 가능하다면 며칠 분을 하루에 수행하기로 하였다.

1. 기초 지식

Next.js?

-> React.js를 기반으로 SSR이 가능하도록 요소들을 추가한 확장판 개념.

프레임워크와 라이브러리의 차이점

-> 주도권이 개발자에게 있냐 없냐의 차이.
-> 자유도가 높냐 낮냐의 차이.

=> 프레임워크는 주도권이 개발자에게 없다. 대신에 제공해주는 기능이 풍부하기 때문에 개발자가 뭔가를 구현하는데 필요한 요소들이 대부분 갖춰져있다. 다만 기능 구현에 필요한 요소를 선택하는 자유도는 낮은 편.

=> 라이브러리는 그 반대. 주도권이 개발자에게 있고 자유도도 높지만, 기본적으로 제공해주는 기능이 없거나 적어서 뭔가 구현하는데 방법과 도구를 알아서 찾아야 한다.

사전 렌더링

CSR과 SSR의 차이 및 장단점은 과거 포스팅 참고.

Hydration수화

-> Next.js에서 서버에서 렌더링 된 프로젝트 파일이 유저에게 1차적으로 전달되는 (화면에 렌더링) 시점에서는 상호작용이 불가능한 상태. 서버에서 JS 번들 파일을 다시 제공해주고, 이것이 브라우저에서 프로젝트 파일과 결합되어. 화면도 잘 출력되고 기능도 잘 동작하는 완성된 웹 프로젝트가 된다.

Next.js의 특징

-> SSR 기법으로 유저가 최초로 마주하는 화면은 비어있는 index뿐이라는 React.js의 문제를 해결. 그리고 최초 렌더링은 서버에서 처리하되 그 이후의 페이지 이동 등의 기능은 CSR 기법을 그대로 채용하여 신속하게 처리. React.js의 장점은 계승하고, 단점을 해결했다.

Page Router VS App Router

-> Page Router는 기존부터 사용하던 전통 방식. App Router는 13버전부터 새롭게 제공되는 새로운 방식. Vercel은 App Router를 추천하는 모양이지만.. 신기술이라는게 늘 그렇듯이 완전히 정착할 때까지, 제대로 안정될 때까지는 시간이 필요하다. 레거시 코드 문제도 생각하면 Page Router는 한동안 현역.

Next.js의 SSR과 CSR의 성능적 비교

-> 사용자가 요청을 보내면, 서버에서는 요청을 받고 웹 파일을 렌더링. 렌더링 된 상태에서 사용에게 응답을 보내어 처음부터 완성된 화면을 보여주는게 SSR의 강점. 그런데 이 때까지는 화면만 완성이 되었을 뿐, JS 코드가 로딩되지 않아서 기능은 동작하지 않는다. 그렇기에 서버에서는 JS 코드를 빌드해서 브라우저로 보내고, 브라우저에서는 완성되어있는 화면에 Hydration - JS 코드를 주입하여 기능이 동작하도록 만든다.

-> SSR과 CSR 비교 포스트에서도 정리해두었지만, SSR과 CSR은 어느 한쪽이 더 뛰어난 관계가 아니다. 각자의 특징과 장단점이 있으니 상황에 맞게 적절한 녀석을 골라 사용해야 한다.
-> SEO 문제에서도 검색 엔진을 통해 외부 사용자에게 노출될 필요가 없거나, 검색 결과 순위가 중요한 역할을 하지 않는 웹 사이트는 SEO를 중시할 이유가 하등 없다. (인트라넷, 회원 전용 사이트, 테스트 중인 웹 어플리케이션, 단순 안내 페이지 등..)
-> SSR은 결국 요청 - 응답 - 화면 렌더링 - JS 번들 제공 및 수화 - 기능 동작 정상화의 복잡한 순서를 거쳐야하기 때문에, 사용자에게 완성된 화면을 렌더링하는 것 까지는 빠르지만, 기능이 동작하기까지의 과정은 길기 때문.

2. 학습 프로젝트 세팅.

create-next-app@14

-> React.js의 프로젝트 세팅 명령어인 CRA의 next 버전. @ 키워드를 통해 특정 버전을 설치할 수 있다.

_app? _document?

-> CRA와 다르게 index.html, app.js 대신에 pages 폴더가 따로 생성되고 (페이지 라우트 버전에서) 그 내부에는 _app과 _document라는 처음 보는 파일들이 존재한다.
-> pages 폴더에 위치해 있지만 이들은 라우팅 용도로 사용되는 파일은 아니다. App의 모든 페이지에 공통적으로 적용될 로직 혹은 레이아웃 혹은 데이터를 다루는데 사용된다.
-> _document는 React.js의 index.html와 흡사한 역할을 수행한다. 모든 페이지에 공통적으로 적용이 되어야 하는, HTML 코드를 설정하는 역할을 수행. 메타 태그, 폰트, 캐릭터셋 설정, 서드파티 스크립트 추가 등의 HTML 태그를 관리.
-> _app은 모든 페이지 컴포넌트의 부모 역할을 수행하는 '루트' 컴포넌트 역할을 수행. 현재 페이지 역할을 하는 인자 Component을 받고, 같이 전달될 Props들을 저장하는 객체 pageProps을 받는다. 그리고 App은 이들을 받아 return 해준다. 만약 여기에 레이아웃을 작성하면, 모든 페이지에 공통되어 출력된다. 비즈니스 로직도 작성이 가능.

Next.js 설치시 주의

• ESLint, Tailwind CSS의 사용 여부를 물어온다. 자신이 사용하는 기술인지 확인하고 고르면 된다.

• src 경로를 기본으로 사용할 것이냐는 물음. 경로 이름을 다르게 하고 싶다면 No를 선택하면 된다.

• App Router의 사용 여부. Next.js의 Page Router는 구버전에서 사용되었고, 지금도 사용할 수는 없지만 공식적으로 App Router의 사용을 권장한다.

• Next.js 프로젝트를 설정할 때 import alias를 설정할지를 물어본다. 기본적으로 Next.js에서는 @/*를 사용하여 특정 경로를 참조할 수 있는 import alias 기능을 제공한다.

기본 경로를 사용하지 않는 경우:

import MyComponent from '../../../components/MyComponent';

import alias를 사용하는 경우

import MyComponent from '@/components/MyComponent';

• No를 선택하면 기본적으로 @/*가 사용, Yes를 선택하면 본인이 원하는 방식으로 import alias를 커스터마이징할 수 있다.

• 해당 학습은 이정환 Winterlood님의 한 입 크기로 잘라먹는 Next.js(15+)을 기반으로 진행되고 있습니다.