Next.js를 사용하는 이유
Next.js를 활용해 다수의 프로젝트를 구현하면서 관련된 정리를 해보고자 글을 쓰기로 했다.
Next.js는 무엇인가?
공식 문서를 살펴보면 React framework for building full-stack web applications이라고 설명이 되어있다.
React Components를 사용하여 사용자 인터페이스를 빌드하고 Next.js를 사용하여 추가 기능과 최적화를 구현하는 프레임 워크임을 나타내고 있다.
Next.js의 주요 특징
1. 파일 기반 라우팅
- pages 폴더나 app 디렉토리 기반으로 자동으로 라우팅 생성
- pages/about.tsx 만들면 자동으로 /about 경로 생성됨
2. 서버 사이드 렌더링 (SSR) / 정적 사이트 생성 (SSG)
- 페이지별로 렌더링 전략 선택 가능 (getServerSideProps, getStaticProps 등)
- 검색엔진 최적화(SEO)나 초기 로딩 속도에 유리
3. API Routes
- 백엔드 서버 없이 간단한 API 구축 가능.
예: pages/api/hello.ts → /api/hello로 호출 가능
4. 이미지 최적화
- next/image 컴포넌트로 자동 리사이징, lazy loading, WebP 변환 등 지원.
5. 앱 디렉토리 (app directory) 기반의 새로운 라우팅 시스템 (Next 13 이상)
- 레이아웃 기반의 라우팅, 서버 컴포넌트 지원 등 더 나은 구조 제공
6. TypeScript, ESLint, Tailwind 등 통합 세팅이 간편
- create-next-app 으로 시작하면 대부분 자동 설정
7. Code Splitting
- Next.js는 자동 코드 스플리팅을 통해 페이지별로 필요한 코드만 로드함
8. Built-in CSS & Sass Support
- CSS Module, Sass, Tailwind, PostCSS 등 다양한 스타일링 방식 지원
9. Fast Refresh
- 개발 도중 코드 변경 시 상태를 유지한 채 실시간 반영되는 기능
10. 정적 파일 제공 (public 디렉토리)
- public/ 폴더 안에 이미지, 문서 파일 넣으면 자동으로 정적 제공
React와 Next.js의 차이점
| 항목 | React | Next.js |
| 개발 형태 | 라이브러리 | 프레임워크 |
| 라우팅 | 수동 (React Router 등 필요) | 자동 (파일 기반) |
| 렌더링 방식 | CSR 중심 | CSR + SSR + SSG + ISR |
| 설정 | 자유도 높음 (초기 설정 직접 해야 함) | 대부분 설정되어 있음 |
| SEO | 기본적으로 약함 | SSR/SSG로 강력한 SEO 지원 |
| 폴더 구조 | 자유 | 약간의 구조 제약 (pages, app) |
Next.js 렌더링 방식
Next.js는 기본적으로 "정적 생성(SSG)"을 우선적으로 사용하려는 방향을 가지고 있음
| 렌더링 방식 | HTML 생성 시점 | 사용 예시 | 특징 | 사용 시기 |
| SSG (Static Site Generation) |
빌드 타임에 HTML 생성 |
getStaticProps 사용 |
⦁ 퍼포먼스 가장 우수 ⦁ CDN에 캐싱 가능 → 빠른 응답 ⦁ 정적인 데이터에 적합 (자주 안 바뀌는 콘텐츠) |
⦁ 블로그 글, 마케팅 페이지,제품 소개 등 ⦁ 자주 변경되지 않는 콘텐츠 |
| SSR (Server Side Rendering) |
매 요청 시 서버에서 HTML 생성 |
getServerSideProps 사용 | ⦁ 항상 최신 데이터 제공 ⦁ 초기 페이지 로딩 속도는 CSR보다 빠를 수 있음 ⦁ 서버 리소스 소비 많음 |
⦁ 로그인된 사용자 정보 기반 콘텐츠 ⦁ 자주 바뀌는 데이터 (날씨, 주식 등) |
| CSR (Client Side Rendering) |
초기 HTML만 있고 JS로 데이터 불러옴 (클라이언트 측) |
useEffect + fetch 등 | ⦁ React 기본 동작과 동일 ( SPA와 유사 ) ⦁ 페이지 진입 시 데이터 로딩 필요 → 초기 로딩 느릴 수 있음 ⦁ 사용자 상호작용 많은 경우 유리 |
⦁ 관리자 대시보드 ⦁ 페이지마다 사용자 상호작용 많은 SPA 구조 |
| ISR (Incremental Static Regeneration) |
빌드 + 일정 주기 재생성 |
revalidate 옵션 활용 | ⦁ 정적 페이지처럼 빠르면서도, 일 정 주기로 최신화 가능 ⦁ 백엔드 연동하면서도 캐시 성 유지 가능 ⦁ SSG + 유연성 |
⦁ 자주 바뀌진 않지만 최신 정보 유지가 필요 한 경우 ⦁ 상품 상세 페이지, 뉴스 등 |
실제로 겪었던 이슈들
1. window is not defined
Next.js는 서버에서도 코드가 실행되기 때문에,
브라우저 전용 객체인 `window`, `document`, `localStorage` 등을 서버에서 직접 사용하면 오류가 발생함.
→ useEffect를 사용해 클라이언트에서만 실행되도록 처리 or dynamic import 사용
2. Hydration failed: content mismatch
서버에서 렌더링 한 HTML과 클라이언트에서 렌더링 된 결과가 다를 경우 발생
보통 window나 document를 사용한 조건부 렌더링이 없거나, 랜덤/시간 기반 렌더링 차이가 원인
예시 코드
<p>{window.innerWidth > 500 ? "PC" : "Mobile"}</p>
해결
→ useEffect를 사용 ( 브라우저 환경에서만 렌더링 되도록 조건 처리 )
import { useState, useEffect } from 'react';
const [isClient, setIsClient] = useState(false);
useEffect(() => setIsClient(true), []);
return isClient ? <p>{window.innerWidth > 500 ? "PC" : "Mobile"}</p> : null;
관련글 : https://minsun309.tistory.com/entry/Hydration-failed-%EC%97%90%EB%9F%AC
3. App Router 전환 초기의 혼란
app/ 디렉토리 도입 이후 layout.tsx, page.tsx, loading.tsx 등 구조 변화.
→ 장점은 많지만, 기존 pages 방식과 개념이 달라 익숙해지는 데 시간 걸림
Next.js를 선호하는 이유
처음엔 React만으로도 충분하다고 생각했는데, 실제로 서비스를 만들어보니까 생각보다 신경 써야 할 게 많았다.
라우팅, SEO, 데이터 처리, 이미지 최적화 같은 것들이 하나둘 생기기 시작했고, 그 대부분은 Next.js가 이미 기본으로 잘 챙겨주고 있는 환경이었다.
Next.js는 단순히 "빠르게 만들 수 있는 도구"를 넘어서, 서비스를 실제로 운영하고, 나중에 유지보수하거나 확장할 때도 훨씬 효율적인 프레임워크라는 걸 직접 느껴서 지금은 거의 모든 프로젝트를 Next.js로 시작하게 된다.