SPA(Single Page Application)는 단일 HTML 페이지로 구성된다.
페이지 전환 시 전체 페이지를 새로 로드하지 않으며, 클라이언트 측(CSR)에서 JavaScript를 통해 콘텐츠를 동적으로 렌더링한다.
장점
: 빠른 페이지 전환 속도, 부드러운 사용자 경험, 서버 부하 감소, 개발 생산성 향상
단점
: 초기 로딩 지연, SEO 문제, 접근성 이슈, 초기 화면 깜박임
SPA는 동적으로 렌더링된다. 전체 페이지를 새로 로드하지 않고 필요한 부분만 업데이트할 수 있기 때문에 사용자에게 부드러운 화면 전환을 제공할 수 있다.
초기 로딩 시 필요한 모든 리소스(JavaScript, CSS 등)을 한 번에 가져오기 때문에 이후 페이지 전환 시 새로 로드할 필요가 없어 빠른 응답 속도를 보장할 수 있다. 단, 초기 로딩이 길어질 수 있으며 사용자가 페이지를 처음 방문할 때 빈 화면이나 깜박임이 발생할 수 있다.
SEO 문제는 주로 JavaScript로 동작하기 때문에 발생한다. 검색 엔진 봇은 JavaScript를 실행하기 전까진 SPA의 초기 콘텐츠를 제대로 인식하지 못한다. 동적으로 콘텐츠를 렌더링하기 때문에 이런 컨텐츠를 제대로 크롤링하고 인덱싱하기도 어렵다. 단일 URL에서 동작하기 때문에 고유한 URL을 가지기 힘들고, 메타데이터를 적절히 설정하기도 어렵다.
MPA(Muiti Page Appliction)는 여러 개의 HTML 페이지로 구성된다.
페이지 전환 시 전체 페이지를 새로 로드하며,서버 측(SSR)에서 HTML을 생성하여 클라이언트에 전송한다.
장점
: SEO 용이, 초기 로딩 속도 빠름, 접근성 높음단점
: 페이지 전환 시 지연 발생, 서버 부하 증가, 개발 복잡도 높음MPA는 각 페이지마다 고유한 URL을 가지므로, 검색 엔진 봇의 크롤링과 콘텐츠 인덱싱이 용이하다. 웹 표준을 준수하기 때문에 장애인, 노령자 등의 다양한 사용자의 접근성을 높일 수도 있다.
복잡한 프레임워크와 라이브러리를 사용하는 SPA와 다르게 MPA는 웹 개발 표준 기술을 사용하고, 전통적인 클라이언트 - 서버 아키텍처를 따르기 때문에 다른 복잡한 프레임워크나 라이브러리 없이도 개발이 가능하다.
페이지 단위로 리소스를 로딩하기 때문에 초기 로딩 속도가 상대적으로 빠르다. 다만 페이지 간 이동 시 지연 시간이 발생할 수 있고, 각 페이지에 대한 요청이 서버로 전송되므로 트래픽이 증가할수록 서버 부하가 커질 수 있다.
CSR(Client-Side Rendering)은 클라이언트 측에서 렌더링하는 방식이다.
SPA 아키텍처에서 주로 사용되는 방식으로, 초기 페이지 로드 시 전체 애플리케이션의 코드가 전송되고, 이후 클라이언트에서 동적으로 페이지를 렌더링한다.
React
, Angular
, Vue.js
등으로 구현할 수 있다.
SSR(Server-Side Rendering)은 서버 측에서 렌더링하는 방식이다.
MPA 아키텍처에서 주로 사용되는 방식으로, 각 페이지가 서버에서 생성되어 클라이언트로 전송된다.
Next.js
, Nuxt.js
, Express.js
, Django
등으로 구현할 수 있다.
SSG(Static Site Generation)은 웹사이트의 콘텐츠를 빌드 시점에 미리 렌더링하여 정적인 HTML 파일로 생성하는 기술이다.
주로 SSR과 혼용하여 사용한다. 정적 콘텐츠 중심의 웹 사이트나 블로그에서는 SSG를 사용해 빠른 로드 속도와 높은 가용성을 확보할 수 있다. 동적 데이터 처리가 필요한 곳에선 SSR을 사용해 실시간 데이터 반영이 가능하다. 정적 콘텐츠와 동적 콘텐츠가 혼재된 곳에선 두 기술을 적절히 혼용하여 사용할 수도 있다.
Next.js
는 React 기반의 프레임워크로, SSR을 구현하는 대표적인 기술 중 하나이다.
Server-Side Rendering
: React 애플리케이션을 서버 측에서 렌더링해 초기 로드 속도가 빠르다.
Static Site Generation
: 빌드 시점에 페이지를 미리 렌더링해 HTML 파일을 생성한다. 동적 콘텐츠를 가진 웹사이트에도 적용할 수 있어 성능 향상에 도움이 된다.
Incremental Static Regeneration
: 기존에 생성된 정적 페이지를 특정 간격으로 자동 갱신할 수 있다.
File-based Routing
: 파일 기반의 라우팅 시스템으로, 개발자가 파일 구조 만으로도 라우팅을 설정할 수 있다.
API Routes
: 서버 사이드 API 엔드포인트를 쉽게 생성할 수 있어, 클라이언트와 서버 간의 데이터를 효율적으로 교환할 수 있다.
Code Splitting
: 자동으로 코드 분할을 수행하여 초기 로드 시간을 최소화한다.
Next.js
는 렌더링을 할 때 pre-rendering
을 수행한다. 또한, Hydration
을 통해 미리 렌더링된 HTML에 JavaScript를 결합하여 이벤트가 동작할 수 있도록 만든다.
Next.js
는 기본적으로 서버 측에서 초기 HTML 페이지를 생성한다. 이 HTML 페이지에는 클라이언트 측 JavaScript 코드가 포함된다.
클라이언트가 HTML 페이지를 받으면, 포함된 JavaScript 코드가 실행되어 페이지를 활성화한다. 이 과정에서 클라이언트 측 JavaScript가 서버 측에서 생성된 HTML 요소와 상호작용할 수 있게 된다. > Hydration
Hydration
이후에는 클라이언트 측 JavaScript가 페이지의 상호작용과 동적 업데이트를 처리할 수 있다. 사용자 이벤트, 데이터 로드, 상태 변경 등의 처리가 이루어진다.
npx create-next-app@latest
What is your project named? my-app
Would you like to use TypeScript? No / Yes
Would you like to use ESLint? No / Yes
Would you like to use Tailwind CSS? No / Yes
Would you like to use `src/` directory? No / Yes
Would you like to use App Router? (recommended) No / Yes
Would you like to customize the default import alias (@/*)? No / Yes
What import alias would you like configured? @/*
Next.js
의 기본적인 프로젝트 구조는 다음과 같다. React와 유사한 구조를 갖고 있으나, 일부 차이점이 존재한다. 이외에도 프로젝트 요구사항에 따라 추가적인 폴더와 파일을 생성할 수 있다.
.next/
: Next.js가 빌드한 결과물이 저장된다.
pages/
: 이 폴더 안에 있는 파일들이 자동으로 라우팅 시스템에 매핑된다. 각 파일은 하나의 페이지를 나타내며, 이름이 URL 경로가 된다.
components/
: 재사용 가능한 일반적인 React 컴포넌트를 저장한다.
styles/
: CSS 스타일 파일을 저장한다.
public/
: 정적 리소스를 저장한다. 빌드 시 이 폴더의 내용은 루트 디렉토리로 복사된다.
next.config.js
: Next.js의 설정 파일이다. 웹팩 구성, 환경 변수, 리다이렉션 등을 설정할 수 있다.
Next.js에서 라우팅은 파일 기반이다. pages/
폴더 내에 있는 파일명이 URL 경로가 된다.
pages/
index.js
about.js
products/
index.js
[id].js
예를 들어 위와 같은 파일 구조가 있다고 가정했을 땐, 다음과 같은 라우팅이 자동으로 설정된다.
/
: pages/index.js/about
: pages/about.js/products
: pages/products/index.js/products/[id]
: pages/products/[id].jsimport { useRouter } from 'next/router'
export default function ProductPage() {
const router = useRouter()
const { id } = router.query
return (
<div>
<h1>{id}</h1>
{/* 제품 상세 정보*/}
</div>
)
}