리액트, next.js 개발환경 구축
1. 리액트 소개
리액트는 프레임워크가 아니라 라이브러리이다. 가벼운 구조를 가진다.
1.1. Component 기반 개발구조
컴포넌트는 화면을 구성하는 개별 뷰 단위이다.
레고 블록처럼 컴포넌트를 조합하여 페이지를 구성할 수 있으며, 애플리케이션 내에서 컴포넌트는 쉽게 재사용할 수 있다.
리액트의 구조는 성능보다는 유지보수의 편리성을 고려해 설계되었다.
1.2. JSX 문법 구조로 화면 표시
JSX는 리액트 기반 UI 표현을 위한 자바스크립트 문법이다.
페이스북이 주도한 XHP에서 기원하였으며, Babel을 통해 순수 자바스크립트로 변환된다.
JSX는 HTML과 유사한 구조로 작성하지만, 실제로는 HTML이 아닌 자바스크립트이다.
JSX는 자바스크립트를 통해 HTML 요소를 만들고 관리하는 기술이다.
1.3. Virtual DOM
Virtual DOM은 리액트의 DOM 관리 기술로, HTML DOM의 비효율적인 부분을 해결한다.
HTML DOM은 웹페이지의 특정 영역이 바뀌면 전체 페이지를 다시 렌더링하지만, Virtual DOM은 변경된 부분만 실제 DOM에 적용하여 성능을 향상시킨다.
2. 번들링과 번들링 도구
2.1. 번들링이란
번들링은 독립적인 제품들을 묶어 새로운 결과물을 만들어내는 전략이다.
프론트엔드에서의 번들링은 여러 기술과 리소스를 묶어 최종 애플리케이션을 만드는 과정을 의미한다.
2.2. 번들링의 장점
번들링은 다양한 기술 요소를 통합해 개발 결과물을 만들고, 이를 압축하여 실행 속도와 로딩 속도를 개선한다.
또한 난독화를 통해 안전성을 높이고, 번들링 과정에서 발생할 수 있는 변수 중복 선언 등의 에러를 방지할 수 있다.
2.3. 웹팩 번들링 도구
리액트는 여러 기술을 조합해 개발되며, 이를 번들링하여 웹브라우저에서 작동하는 자바스크립트 파일과 정적 웹 리소스를 생성한다.
Webpack은 이러한 번들링 과정을 통해 리액트 개발 소스를 관리하는 도구이다.
3. 패키지 관리자 비교
3.1. NPM
Node.js 설치 시 기본으로 제공되는 패키지 관리 소프트웨어이다.
npm 명령어를 통해 다양한 자바스크립트 패키지를 설치하고 관리할 수 있다.
3.2. NPX
NPM v5.0.2부터 추가된 기능으로, 전역 패키지 설치의 버전 관리 문제를 해결한다.
패키지를 임시로 설치하고 사용 후 삭제함으로써 저장 공간을 효율적으로 활용할 수 있다.
3.3. YARN
YARN은 NPM의 단점을 보완해 패키지 설치 속도를 개선한 패키지 관리 소프트웨어이다.
프론트엔드 프로젝트에서 많이 사용되며, yarn 명령어로 패키지를 설치하고 관리할 수 있다.
3.4. PNPM
PNPM은 패키지를 물리적으로 중복 설치하지 않고, 링크 방식을 통해 빠르고 효율적으로 관리하는 최신 패키지 관리 소프트웨어이다.
pnpm 명령어를 통해 패키지를 설치한다.
4. Yarn 패키지 관리자 설치하기
4.1. Yarn 설치 방법
npm install -g yarn
Yarn의 버전 확인은 yarn --version으로 가능하며, 리액트 앱 프로젝트를 생성하려면 다음 명령어를 사용한다.
yarn global add create-react-app
5. 리액트 프로젝트 만들기 – 3가지 방법
리액트 프로젝트를 생성하는 세 가지 방법이 있다.
5.1. CRA(Create React App) 방식
가장 오래된 방식으로, create-react-app 패키지를 설치하여 리액트 프로젝트를 생성한다.
하지만 현재는 이 방식이 지양되고 있어 많이 사용되지 않는다.
yarn create react-app cra-react-app
5.2. VITE 방식
VITE는 CRA보다 더 빠르고 효율적으로 번들링을 처리한다.
다음 명령어로 Vite 기반의 리액트 프로젝트를 생성할 수 있다.
yarn create vite vite-react-app --template react
5.3. NEXT.JS 방식
Next.js는 SSR과 SSG를 지원하며, 최신 리액트 개발 방식으로 권장된다.
다음 명령어로 Next.js 프로젝트를 생성할 수 있다.
npx create-next-app@latest next-react-app
6. Next.js 프로젝트 실행 흐름 설명
6.1. 실행 순서
-
사용자가 웹 브라우저에서 사이트를 방문하면, Next.js가 도메인 주소로부터
NextApp을 로드한다. -
Next.js의
_app.tsx파일이 서버에서 실행된다. -
사용자가 방문한 페이지가 서버에서 호출되고,
_document.tsx파일이 실행된다. -
서버에서 HTML을 생성하고, 이를 클라이언트에 전달한다.
-
클라이언트에서 React가 페이지를 동적으로 렌더링한다.
- _document.tsx가 가장 바깥쪽에서 HTML 문서의 틀을 제공하고,
- _app.tsx가 그 안에서 공통 레이아웃과 상태 관리를 담당하며,
- pages/index.tsx가 실제로 사용자에게 보여지는 페이지다.
이 흐름을 통해 서버에서 HTML을 생성하고 클라이언트로 전달한 후에, React가 페이지를 동적으로 렌더링하여 SPA(Single Page Application)의 특징을 유지하는 것이다.
7. SPA(Single Page Application)
SPA(Single Page Application)는 특정 기술에 국한되지 않은 개념으로, 리액트나 Next.js 모두 SPA 형태로 개발할 수 있다. SPA는 애플리케이션의 구조를 나타내며, 리액트와 Next.js는 이를 구현할 수 있는 도구이다.
7.1 SPA의 정의
SPA는 사용자가 새로운 페이지로 이동할 때마다 전체 페이지를 다시 로드하는 대신, 현재 페이지 내에서 자바스크립트를 이용해 필요한 부분만 동적으로 업데이트하는 방식이다. 이를 통해 페이지가 전환될 때마다 서버로부터 전체 페이지를 다시 받지 않으므로 부드럽고 빠른 사용자 경험을 제공한다.
7.2 리액트와 SPA
리액트는 SPA를 구축하는 데 널리 사용되는 UI 라이브러리이다. 리액트는 CSR(Client-Side Rendering)을 기반으로 하며, 페이지 전환 시 전체 페이지를 다시 로드하지 않고 클라이언트 측에서 필요한 부분만 업데이트하는 SPA의 주요 특징을 지원한다. 즉, 리액트는 기본적으로 SPA를 구현하기 위한 도구로 많이 사용된다.
7.3 Next.js와 SPA
Next.js는 리액트를 기반으로 하는 프레임워크로, 더 다양한 렌더링 방식을 제공한다. 기본적으로 SSR(Server-Side Rendering)과 SSG(Static Site Generation)을 지원하지만, CSR(Client-Side Rendering)을 사용해 SPA 형태로 구현할 수 있다.
Next.js에서 CSR을 사용한 SPA를 구현하려면, getStaticProps나 getServerSideProps를 사용하지 않고, 리액트처럼 페이지를 클라이언트 측에서 렌더링하면 된다.
7.4 정리
SPA는 리액트와 Next.js 모두 지원하는 웹 애플리케이션 구조이다. 다만, 리액트는 주로 SPA를 구현하기 위한 라이브러리이며, Next.js는 SPA를 포함해 SSR, SSG 등 다양한 렌더링 방식을 지원하는 프레임워크이다.
- 리액트: 기본적으로 SPA를 구현하기 위한 라이브러리이다.
- Next.js: SPA, SSR, SSG 등 다양한 렌더링 방식을 지원하는 프레임워크이다.
8. 기존 리액트와 Next.js의 렌더링 방식
8.1. 기존 리액트 렌더링방식 (CSR방식)
기존 리액트는 기본적으로 클라이언트 사이드 렌더링(Client-Side Rendering, CSR)을 사용한다.
CSR은 브라우저가 HTML 파일과 자바스크립트 번들을 받아와서 렌더링을 진행하는 방식이다.
특징:
- 초기 로딩 속도가 느릴 수 있지만, 이후의 페이지 전환은 빠르다.
- SEO 성능이 좋지 않다. 클라이언트 측에서 렌더링되기 때문에, 검색 엔진 봇이 자바스크립트 실행을 제대로 처리하지 못하면 콘텐츠를 인식하지 못할 수 있다.
- 주로 싱글 페이지 애플리케이션(SPA) 형태로 동작한다.
8.2. Next.js의 렌더링 방식 (기본은 SSG이다.)
Next.js는 서버사이드 렌더링(Server-Side Rendering, SSR), 정적 사이트 생성(Static Site Generation, SSG), 클라이언트 사이드 렌더링(CSR)을 모두 지원한다.
특징:
- 서버사이드 렌더링(SSR):
요청 시 서버에서 HTML을 생성하여 클라이언트에 전달한다.
SEO 성능이 우수하고,초기 로딩 속도가 빠르다. - 정적 사이트 생성(SSG): 빌드 시 HTML을 생성하고, CDN에 배포한다.
각 페이지는 정적 파일로 제공되어빠른 로딩 속도를 보인다. - 클라이언트 사이드 렌더링(CSR): 일부 페이지나 컴포넌트는 클라이언트 사이드에서 동적으로 렌더링할 수 있다.
Next.js는 SSR, SSG, CSR을 혼합하여 사용할 수 있으며, 각 페이지별로 적절한 렌더링 방식을 선택할 수 있다.
SEO 최적화와 초기 로딩 속도 개선에 강점을 가지고 있으며, 현대적 웹 프론트엔드 개발을 위한 유연한 렌더링 옵션을 제공한다.
9. Next.js의 렌더링 방식
Next.js는 리액트 기반의 프레임워크로, 다양한 렌더링 방식을 지원한다. 대표적으로 CSR(Client-Side Rendering), SSR(Server-Side Rendering), SSG(Static Site Generation) 방식을 제공하며, 각 방식은 애플리케이션의 요구사항에 맞춰 선택적으로 사용할 수 있다. 아래는 각 렌더링 방식에 대한 설명과 장단점이다.
9.1. CSR (Client-Side Rendering)
CSR(Client-Side Rendering)은 전통적인 SPA 방식으로, 모든 렌더링이 클라이언트(브라우저) 측에서 이루어진다. 서버는 주로 데이터를 전달하는 역할을 하고, 클라이언트는 자바스크립트를 통해 HTML과 UI를 동적으로 생성하여 사용자에게 보여준다.
작동 방식:
- 초기 페이지 로드 시 최소한의 HTML과 자바스크립트를 서버에서 받아온다.
- 자바스크립트가 실행되며, 클라이언트 측에서 필요한 데이터를 서버에 요청하고 받아온다.
- 클라이언트는 받은 데이터를 이용해 동적으로 UI를 렌더링한다.
장점:
- 빠른 페이지 전환: 한 번 자바스크립트를 받아오면, 페이지 간 전환이 매우 빠르다.
- 유동적인 사용자 경험: 사용자가 페이지를 새로고침하지 않고도 다양한 상호작용을 할 수 있다.
- 서버 부담이 적음: 서버는 단순히 데이터를 제공하는 역할만 하므로 부하가 적다.
단점:
- SEO 성능이 낮음: 클라이언트 측에서 렌더링이 이루어지기 때문에, 초기 HTML이 비어있어 검색 엔진이 크롤링하기 어렵다.
- 초기 로딩 속도 느림: 자바스크립트와 데이터를 모두 받아와야 페이지가 렌더링되므로, 초기 로딩이 느릴 수 있다.
- 자바스크립트 의존성: 자바스크립트가 비활성화된 환경에서는 제대로 동작하지 않을 수 있다.
9.2. SSR (Server-Side Rendering)
SSR(Server-Side Rendering)은 클라이언트가 요청할 때마다 서버에서 HTML을 미리 생성하여 전달하는 방식이다. 이는 전통적인 웹 애플리케이션 방식으로, SEO 문제와 초기 로딩 속도를 해결하기 위해 사용된다.
작동 방식:
- 클라이언트가 페이지를 요청할 때, 서버에서 해당 페이지에 필요한 데이터를 조회하고 HTML을 생성한다.
- 서버는 완성된 HTML을 클라이언트에 전달하고, 클라이언트는 이를 바로 렌더링한다.
- 이후 클라이언트에서 자바스크립트를 로드하여 동적 기능을 활성화한다.
장점:
- 향상된 SEO 성능: 서버에서 완성된 HTML을 제공하므로 검색 엔진이 페이지를 쉽게 크롤링할 수 있다.
- 빠른 초기 로딩: 클라이언트는 완성된 HTML을 받으므로 초기 로딩 속도가 빠르다.
- 자바스크립트 비활성화 환경에서 동작: 자바스크립트가 비활성화된 환경에서도 기본적인 콘텐츠가 렌더링된다.
단점:
- 서버 부하: 각 요청에 대해 서버에서 HTML을 생성해야 하므로 서버의 부하가 증가한다.
- 복잡한 개발 구조: 클라이언트와 서버 모두에서 렌더링 로직을 관리해야 하므로 코드의 복잡성이 증가할 수 있다.
- 페이지 전환 시 서버 요청 필요: 페이지를 전환할 때마다 서버에서 다시 HTML을 받아와야 하므로, CSR에 비해 페이지 전환 속도가 느릴 수 있다.
9.3. SSG (Static Site Generation)
설명:
SSG(Static Site Generation)는 빌드 시점에 페이지를 미리 렌더링하여 정적인 HTML 파일로 생성하는 방식이다. 한 번 생성된 정적 페이지는 CDN을 통해 서빙되며, 이후에 클라이언트가 페이지를 요청할 때는 서버에서 새로 렌더링할 필요 없이 미리 생성된 정적 파일을 제공한다.
작동 방식:
- 빌드 시에 서버에서 필요한 데이터를 가져와 페이지를 렌더링하고, 정적인 HTML 파일로 생성한다.
- 클라이언트가 페이지를 요청하면 서버는 미리 생성된 HTML 파일을 바로 제공한다.
- 클라이언트는 서버에서 받아온 HTML을 렌더링하고, 필요한 경우 자바스크립트로 동적 기능을 활성화한다.
장점:
- 최고의 성능: 정적 페이지를 미리 생성해 CDN을 통해 제공하므로 로딩 속도가 매우 빠르다.
- SEO 최적화: SSR처럼 정적인 HTML 파일을 제공하므로 검색 엔진 크롤링에 유리하다.
- 서버 부하 감소: 서버는 정적 파일을 제공하는 역할만 하므로 부하가 적다.
단점:
- 실시간 데이터 반영이 어려움: 페이지가 빌드 시점에 생성되므로, 실시간으로 변동되는 데이터를 반영하기 어렵다.
- 대규모 사이트에서 빌드 시간이 길어짐: 페이지 수가 많아지면 빌드 시간이 길어질 수 있다.
- 동적 페이지 한계: 주기적으로 업데이트해야 하는 데이터가 많은 경우에는 적합하지 않을 수 있다.
9.4. 비교 정리
- CSR(Client-Side Rendering): 클라이언트에서 모든 렌더링을 처리. 빠른 페이지 전환과 유동적인 사용자 경험을 제공하지만, SEO에 취약하고 초기 로딩 속도가 느림.
- SSR(Server-Side Rendering): 서버에서 렌더링 후 HTML을 제공. SEO와 초기 로딩 속도가 우수하지만, 서버 부하가 크고, 페이지 전환 시마다 서버 요청이 필요함.
- SSG(Static Site Generation): 빌드 시점에 미리 정적 페이지를 생성. 최고의 성능과 SEO를 제공하지만, 실시간 데이터 반영에 한계가 있음.
Next.js는 이 세 가지 렌더링 방식을 혼합하여 사용할 수 있기 때문에, 프로젝트 요구사항에 맞춰 적절한 렌더링 방식을 선택할 수 있는 유연성을 제공한다.
10. 확장 도구 설치
10.1. Code Snippets 확장 도구
Code Snippets는 코드 블록을 빠르게 생성해주는 도구이다.
VSCode에서 Next.js와 리액트 개발을 할 때 유용하게 사용할 수 있다.
확장 도구 설치 방법:
- VSCode 확장 도구에서 “Next.js snippets”을 검색하여 설치한다.
10.2. Next.js snippets 단축키 소개
naf: 화살표 함수형 컴포넌트 생성nafe: export default 기반 화살표 함수형 컴포넌트 생성napage: 기본 함수형 컴포넌트 생성natemplate: 자식 요소를 포함한 함수형 컴포넌트 생성nf: 기본 함수형 컴포넌트nfe: export default 기반 함수형 컴포넌트 생성nspage: getServerSideProps 함수 포함 템플릿nstaticpage: getStaticProps와 getStaticPaths 포함 템플릿
이러한 단축키를 사용하면 리액트 컴포넌트 작성 시 빠르게 코드 구조를 생성할 수 있다.
댓글남기기