Next.js 란?

2026.09.08 · 5분 읽기 · 조회 0

처음 Next.js 를 공부했을 땐 Page Router로 시작을 했다. App Router에 대해서는 아직 잘 모르기 때문에 공부해보려 했으나, 페이지라우터에 대한 기억이 많이 희석되었기 때문에 전체적으로 페이지 라우터에 대해 복습을 먼저 해보고자 한다.

Next.js 란?

Next.js는 리액트에 페이지 라우팅, 빌트인 최적화, 다이나믹 HTML 스트리밍 등을 추가해놓은 확장판이라고 생각하면 된다. Vercel에서 만들었으며 활발하게 사용되는 중이다. 이미 리액트를 아는 사람들은 쉽고 빠르게 배울 수 있다.

Next.js는 라이브러리가 아니라 Framework 이다. 리액트는 UI 개발을 위한 라이브러리이다.

뭔 차이일까?

기능 구현의 주도권

• 주도권이 개발자에 있다: Library
• 주도권이 개발자에게 없다: Framework

Library

라이브러리에서는 주도권을 개발자가 지니기 때문에 기능 구현을 원하는 방향으로 진행할 수 있다. 쓰고 싶은 도구, 쓰고 싶은 기술을 사용한다. 리액트에서 페이지 라우팅을 구현하고 싶다면 다양한 방법을 사용할 수 있다.

비교적 자유도가 높다. 자유도가 높다 = 기본적으로 제공되는 기능이 많지 않다는 뜻일 수 있으므로 항상 긍정적인 것은 아니다.

Framework

Framework 에서는 주도권을 Framework가 가진다. 프레임워크가 제공하는 기능을 이용하거나 허용하는 범위 내에서만 추가 도구 사용이 가능하다. Next에서 페이지 라우팅을 구현하고 싶다면 Page Router 또는 App Router를 사용해야 한다.

비교적 자유도가 낮다. 때문에 거의 모든 기본적인 기능들이 제공되기 때문에, 그것들을 가져와서 이용하기만 하면 된다.

사전 렌더링

사전렌더링이란? : 브라우저의 요청에 사전에 렌더링이 완료된 HTML을 응답해주는 렌더링 방식이다.
-> 기존의 리액트 앱이 따르던 Client Side Rendering의 단점을 효율적으로 해결하는 기술이다.

사용자 -> 브라우저에 접속 요청 -> 서버는 미리 렌더링된 HTML을 가져다준다.

클라이언트 사이드 렌더링에 대해 다시 복습해보자.

Client Side Rendering(CSR)

• React.js 앱의 기본적인 렌더링 방식
• 클라이언트(브라우저)에서 직접 화면을 렌더링하는 방식

사용자 -> 브라우저에 접속 요청 -> 서버는 index.html(빈껍데기)을 보내줌 -> 브라우저는 일단 빈 화면을 렌더링 -> 서버가 JS 코드를 번들링해서 뒤늦게 보내줌 -> 브라우저가 해당 JS 파일을 렌더링 -> 사용자 측에 컨텐츠 렌더링

이런 식으로 흐름이 구성된다.

해당 방식은 페이지 이동이 매우 빠르고 쾌적하다는 장점이 있다. 서버가 보내주는 JS 번들에는 웹사이트에 필요한 모든 페이지의 컴포넌트가 들어있다.

때문에 다른 페이지 이동 요청을 보내도 이미 브라우저가 다 가지고 있기 때문에 굉장히 빠른 속도로 페이지 이동을 할 수 있다.

단점

물론 당연히 단점이 있다.
초기 접속 속도가 느리다는 것이다. 초기 접속 요청 이후로 -> 빈화면 렌더링, JS 번들 요청, JS 실행, 컨텐츠 렌더링 까지의 과정이 너무 많기 때문이다.

FCP(First Contentful Paint)

"요청 시작" 시점으로부터 컨텐츠가 화면에 처음 나타나는데 걸리는 시간을 뜻하는데,
요청 시작 <---> 컨텐츠 렌더링 이라고 보면 된다.

해당 FCP는 웹브라우저의 성능을 대표할 정도로 굉장히 중요한 지표이다.

- 3sec 이상일 경우: 이탈률 32% 증가
- 5sec 이상일 경우: 이탈률 90% 증가
- 6sec 이상일 경우: 이탈률 106% 증가
- 10sec 이상일 경우: 이탈률 123% 증가

조금이라도 늦어질 경우 사용자의 이탈률이 증가하기 때문에 중요하다.
CSR(리액트)는 FCP(초기 접속 속도)가 꽤 늦어진다는 치명적인 단점을 가진다.

사전 렌더링

Next.js는 JS 실행을 서버 측에서 사전에 렌더링을 하고 완성된 HTML을 브라우저에 보내주기 때문에 빠르게 유저에게 컨텐츠를 전달할 수 있다.
접속 요청 <---> 화면에 렌더링 인 FCP 가 굉장히 단축된다고 볼 수 있다.

JS 렌더링 : 자바스크립트 코드(React 컴포넌트)를 HTML로 변환하는 과정
화면에 렌더링 : HTML 코드를 브라우저가 화면에 그려내는 작업

Hydration

화면에 렌더링되는 것만으로는 아직 상호작용을 할 수 없다. 화면에 렌더링 후 -> 서버가 JS 번들 보내줌 -> 브라우저가 JS를 실행(HTML과 연결) -> 상호작용 가능한 페이지
이런 과정으로 천천히 연결이 된다.

메마른 HTML 코드에 상호작용(JavaScript)을 불어 넣어준다고 해서, Next에서는 이것을 Hydration이라고 부른다.

상호작용이 가능해지는 시점을 TTI(Time To Interactive) 라고도 부른다. TTI가 3초라는 것은 접속 요청 <----> 상호작용 가능 시점까지 3초가 걸린다 라는 뜻이다.

페이지 이동 요청

이후에 페이지 이동 요청은 리액트와 마찬가지로 CSR(Client Side Rendering) 방식으로 처리한다. 브라우저가 JS를 실행해서 페이지를 교체해준다. 브라우저는 이미 JS 번들을 받았기 때문에 가능하다.

때문에 기존의 리액트의 단점인 느린 FCP를 해소하면서도 React App의 장점인 빠른 페이지 이동을 계승한다.

댓글

giscus로 동작하며 GitHub Discussions에 저장됩니다.

관련 글