Next.js 정리 - React와 Next.js, 서버컴포넌트와 클라컴포넌트, CSR과 SSR

개발 일기

Next.js 정리 - React와 Next.js, 서버컴포넌트와 클라컴포넌트, CSR과 SSR

Kody_with_the_K 2025. 3. 3. 14:50

안녕하세요, 프론트엔드 개발자 코디(Kody)입니다.

최근 저는 사내 관리자 페이지를 마이그레이션하면서, 기존에 Next.js 12로 운영되던 프로젝트를 React.js 기반으로 다시 구축하는 작업을 진행했던 일이 있습니다.

관련하여 최근에 Next.js 관련 여러 질문들을 받으며, 답변하는 과정에서 다시 한 번 Next.js에 대해 스스로 정리해볼 기회를 가졌는데요.

“왜 Next.js가 아니라 React로 다시 구축했나요?”, “서버 컴포넌트와 클라이언트 컴포넌트는 어떻게 다르고, 언제 사용해야 하나요?” 같은 질문들에 답변하는 과정에서 스스로도 다시 개념을 정리하고, 각각의 렌더링 방식이 어떻게 작동하는지 다시금 되새겨보게 되었습니다.

매일같이 쓰던 프레임워크였지만 막상 정제된 말로 이야기하려고하니 말이 정리가 되지 않는 부분이나, 설명하다가 마음에 들지 않는 부분들이 있더라구요.

그래서 이번 글에서는 React와 Next.js의 차이, 서버 컴포넌트와 클라이언트 컴포넌트, 그리고 CSR과 SSR의 동작 방식을 정리하고,

각각의 개념이 언제, 왜 필요하고, 어떤 선택이 더 적절한지에 대해 적어보며 정리하는 시간을 가져보려 합니다.

1. React와 Next.js, 어떨 때 쓰는게 좋을까?

React로 프로젝트를 시작하려고 하는데, Next.js가 더 좋다는 이야기를 들었다면? 🤔

“그럼 Next.js를 써야 하나? React로 해도 괜찮은가?” 이런 고민이 생길 거예요.

둘 다 React 기반이지만, 쓰임새가 조금 다릅니다.

이번 글에서는 React와 Next.js의 차이점과 각각 언제 사용하면 좋은지를 실제 사례와 함께 설명해볼게요.

💡 React와 Next.js의 차이점 먼저 짚어보기

React는?

• 컴포넌트 기반 UI 라이브러리

• 브라우저에서 실행되는 CSR(Client-Side Rendering) 방식

• 별도의 라우팅 기능이 없어서 React Router 필요

• HTML을 브라우저에서 생성하므로 SEO가 어렵고, 초기 로딩 속도가 느릴 수 있음

📌 언제 사용하면 좋을까?

• 한 번 로드된 후 빠르게 동작하는 SPA(Single Page Application)

• 대시보드, 내부 관리자 페이지처럼 SEO가 중요하지 않은 경우

• React Native와 함께 모바일-웹 통합 개발이 필요한 경우

Next.js는?

• React 기반의 프레임워크 (CSR + SSR + SSG 가능)

• 파일 기반 라우팅을 제공하여 React Router 불필요

• 서버에서 HTML을 미리 렌더링(SSR) → SEO 최적화 가능

• 정적 페이지 생성(SSG) 지원 → 속도 최적화

• API Routes 기능 제공 → 간단한 백엔드 기능도 구현 가능

📌 언제 사용하면 좋을까?

• 검색 최적화(SEO)가 중요한 사이트 → 블로그, 뉴스, eCommerce

• 정적 페이지가 많은 웹사이트 → 회사 홈페이지, 랜딩 페이지

• 빠른 페이지 로딩이 필요한 경우 → 서버에서 미리 HTML을 만들어둬야 할 때

⚡ React를 사용하면 좋은 경우 (예시)

1. SPA(Single Page Application)가 필요한 경우

React는 CSR 기반이라 한 번 로드된 후 새로고침 없이 빠르게 페이지를 전환할 수 있어요.

✅ 예시: 대시보드 & 관리자 페이지

• 구글 애널리틱스, Trello, Notion 같은 서비스

• SEO가 중요하지 않고, 실시간 데이터를 다루는 경우가 많음

✅ React를 사용하면 CSR 방식으로 즉각적인 UI 업데이트 가능!
❌ Next.js의 SSR은 오히려 불필요한 렌더링 비용을 발생시킬 수 있음.

2. SEO가 필요 없는 웹앱

로그인한 사용자만 접근하는 사내 시스템, 메신저, 이메일 클라이언트(Gmail) 같은 서비스는

검색 엔진이 접근할 필요가 없어요.

✅ 예시: 로그인 기반 서비스

• 기업 내부 시스템, 챗봇 서비스, 온라인 문서 편집기

✅ SEO가 필요하지 않으므로 React의 CSR 방식이 유리!
✅ 클라이언트에서만 렌더링되므로 서버 부담도 없음.

3. React Native와 동일한 구조를 유지해야 하는 경우

React Native는 React와 동일한 컴포넌트 구조를 가지므로,

웹과 모바일 앱을 함께 개발할 때 React를 사용하는 것이 일관성을 유지하기 좋아요.

✅ 예시: SNS & 모바일 웹 연동 서비스

• 페이스북, 인스타그램, 트위터, 슬랙 웹앱

✅ React Native와 동일한 구조를 유지하려면 React 사용이 유리!
❌ Next.js의 SSR/SSG는 모바일 앱 개발과 관련성이 낮음.

⚡ Next.js를 사용하면 좋은 경우 (예시)

1. SEO(검색 최적화)가 중요한 경우

Next.js는 **SSR(서버 사이드 렌더링)과 SSG(정적 페이지 생성)**을 지원해서,

검색 엔진이 HTML을 쉽게 크롤링할 수 있어요.

✅ 예시: 블로그, 뉴스 사이트, 상품 상세 페이지

• 네이버 블로그, 브런치, 이커머스 쇼핑몰 상품 페이지

✅ 검색 엔진이 페이지를 빠르게 읽을 수 있도록 SSR/SSG 적용!
✅ 정적 페이지를 미리 생성하여 SEO 최적화.

2. 정적 페이지가 많은 웹사이트

변경이 자주 없는 페이지는 미리 HTML을 생성(SSG)해서 캐싱하면,

더 빠르게 로딩할 수 있어요.

✅ 예시: 회사 홈페이지, 랜딩 페이지, SaaS 소개 사이트

• 스타트업 랜딩 페이지, 채용 사이트, 제품 소개 페이지

✅ Next.js는 SSG로 미리 HTML을 생성 → 서버 부하 감소 & 속도 향상!
❌ React의 CSR 방식은 첫 로딩 속도가 느릴 수 있음.

3. API 서버 없이 간단한 백엔드 기능이 필요할 때

Next.js의 API Routes 기능을 활용하면,

백엔드 없이도 간단한 API를 만들 수 있어요.

✅ 예시: 폼 제출, 이메일 전송, 간단한 데이터 저장

• 연락처 폼 제출, 간단한 CRUD API

✅ 백엔드 없이 Next.js API Routes로 처리 가능!
✅ 별도의 서버 구축이 필요 없음.

💡 React vs Next.js, 선택 가이드 정리

렌더링 방식	CSR (Client-Side Rendering)	CSR + SSR + SSG
SEO 최적화	❌ 어렵다	✅ 검색엔진 최적화(SEO) 가능
페이지 로딩 속도	❌ 초기 로딩이 느릴 수 있음	✅ 서버에서 HTML을 렌더링하여 빠름
라우팅	React Router 필요	✅ 파일 기반 라우팅 (자동 설정)
정적 페이지 생성(SSG)	❌ 지원하지 않음	✅ 지원
API Routes	❌ 별도 백엔드 필요	✅ API 구축 가능
사용 사례	대화형 웹앱 (SNS, 대시보드)	블로그, eCommerce, SaaS, SEO가 중요한 사이트

✅ React를 사용해야 하는 경우

✔ SPA(Single Page Application) → 대시보드, 관리자 페이지, SNS

✔ SEO가 중요하지 않은 웹앱 → 로그인 기반 서비스, 사내 시스템

✔ React Native와 통합 개발이 필요한 경우

✅ Next.js를 사용해야 하는 경우

✔ SEO가 중요한 사이트 → 블로그, 쇼핑몰, 뉴스 사이트

✔ 정적 페이지가 많은 사이트 → 회사 홈페이지, 랜딩 페이지

✔ 빠른 페이지 로딩이 필요한 경우 → SSR(서버 사이드 렌더링) 필요

✔ 백엔드 없이 간단한 API가 필요 → Next.js API Routes 활용

2. 서버 컴포넌트 vs. 클라이언트 컴포넌트?

Next.js 13(App Router)부터 서버 컴포넌트(Server Components) 개념이 등장했는데요.

기존 React의 방식과 무엇이 다르고, 언제 사용해야 할까요? 🤔

💡 서버 컴포넌트란?

서버 컴포넌트(Server Components) 는 Next.js 서버에서 실행되는 React 컴포넌트입니다.

브라우저에서 실행되지 않고, 서버에서 렌더링한 HTML을 클라이언트에 전달하는 방식이에요.

✅ 서버 컴포넌트의 특징

✔ 브라우저에서 실행되지 않음 (JS 번들이 클라이언트로 전달되지 않음)

✔ 데이터를 직접 불러올 수 있음 (DB, API 호출 가능)

✔ SEO에 유리함 (완성된 HTML을 클라이언트에 제공)

✔ useState, useEffect, useContext 같은 React Hook 사용 불가

📌 서버 컴포넌트 예제

// 기본적으로 Next.js의 컴포넌트는 서버 컴포넌트
async function ServerComponent() {
  const res = await fetch(url);
  const post = await res.json();

  return <h1>{post.title}</h1>;
}

export default ServerComponent;

✅ fetch()를 서버에서 실행하여 데이터를 가져옴 → API 응답이 클라이언트로 직접 전달되지 않음

✅ 클라이언트에 JS가 전송되지 않고, HTML만 전송됨 → SEO에 유리함

💡 클라이언트 컴포넌트란?

클라이언트 컴포넌트(Client Components) 는 기존 React 컴포넌트와 동일합니다.

즉, 브라우저에서 실행되는 JavaScript 기반의 컴포넌트이며, 사용자 인터랙션을 처리할 수 있어요.

✅ 클라이언트 컴포넌트의 특징

✔ 브라우저에서 실행됨 (JS 번들 필요)

✔ useState, useEffect 같은 React Hook 사용 가능

✔ 이벤트 핸들링 가능 (onClick, onChange 등)

✔ SEO에는 불리할 수 있음 (CSR 방식)

📌 클라이언트 컴포넌트 예제

'use client'; // ✅ 클라이언트 컴포넌트 선언

import { useState } from "react";

function ClientComponent() {
  const [count, setCount] = useState(0);

  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

export default ClientComponent;

✅ "use client"를 선언하면 Next.js가 해당 파일을 클라이언트에서 실행되는 컴포넌트로 인식

✅ useState()를 사용할 수 있음 → 사용자 인터랙션 처리 가능

✅ 하지만 브라우저에서 실행되는 JS 번들이 필요함

💡 서버 컴포넌트 vs 클라이언트 컴포넌트 비교

서버 컴포넌트(Server Components)클라이언트 컴포넌트(Client Components)

실행 위치	서버에서 실행	브라우저에서 실행
JS 번들 전송 여부	❌ 없음 (HTML만 전달됨)	✅ 있음 (JS 코드가 포함됨)
React Hook 사용	❌ 불가능 (useState, useEffect 사용 불가)	✅ 가능
데이터 요청(fetch, DB 쿼리)	✅ 가능	❌ 불가능 (useEffect 사용 필요)
이벤트 핸들링	❌ 불가능 (onClick, onChange 등 사용 불가)	✅ 가능
SEO 최적화	✅ 검색 엔진 크롤링 가능	❌ CSR 방식이면 SEO가 어려움

💡 언제 서버 컴포넌트 vs 클라이언트 컴포넌트를 사용해야 할까?

✅ 서버 컴포넌트를 사용해야 할 때

✔ 초기 로딩 속도가 중요한 경우

✔ SEO가 중요한 페이지 (블로그, 상품 페이지, 뉴스 사이트)

✔ 백엔드에서 데이터를 직접 가져와야 하는 경우

✔ 클라이언트에 불필요한 JavaScript를 줄이고 싶을 때

📌 예제: 서버에서 데이터를 가져와야 하는 경우

import ClientComponent from './ClientComponent';

async function ServerComponent() {
  return (
    <div>
      <h1>서버에서 렌더링된 HTML</h1>
      <ClientComponent />
    </div>
  );
}

✅ 클라이언트 컴포넌트를 사용해야 할 때

✔ 사용자 입력, 이벤트 핸들링이 필요한 경우

✔ useState, useEffect를 사용해야 하는 경우

✔ 애니메이션, WebSocket, 브라우저 API (localStorage, window 등)를 사용해야 하는 경우

📌 예제: 버튼 클릭 시 상태 변경이 필요한 경우

'use client';

import { useState } from "react";

function ClientComponent() {
  const [count, setCount] = useState(0);

  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

💡 서버 컴포넌트와 클라이언트 컴포넌트 함께 사용하기

Next.js에서는 서버 컴포넌트 안에서 클라이언트 컴포넌트를 포함할 수 있음.

import ClientComponent from './ClientComponent';

async function ServerComponent() {
  return (
    <div>
      <h1>서버에서 렌더링된 HTML</h1>
      <ClientComponent />
    </div>
  );
}

✅ 서버에서 HTML을 미리 생성하고, 클라이언트에서 추가적인 UI 상호작용을 할 수 있음

💡 “서버 컴포넌트는 번들이 제로다”는 무슨 뜻일까?

“서버 컴포넌트는 번들이 제로다”라는 말은,

👉 서버에서 실행되므로 브라우저로 전달되는 JavaScript 번들이 없다는 의미입니다.

📌 왜 그럴까?

1. 서버에서 HTML을 렌더링하여 클라이언트에 전달

2. JS 번들이 없으므로 브라우저에서 불필요한 JS 실행이 없음

3. 결과적으로 초기 로딩 속도가 빨라지고, 클라이언트 성능이 최적화됨

✅ 즉, 서버 컴포넌트는 클라이언트에서 실행되지 않으므로 JS 번들이 필요하지 않다!

💡 그럼 "use client"를 사용하면 무조건 클라이언트에서 렌더링될까?

네, "use client"를 선언하면 해당 파일과 포함된 모든 컴포넌트가 무조건 클라이언트에서 실행됩니다.

📌 즉, useState, useEffect를 사용하지 않더라도 "use client"를 선언하면 클라이언트 컴포넌트가 됨.

'use client';

function SimpleComponent() {
  return <h1>이 컴포넌트는 클라이언트에서 실행됨</h1>;
}

✅ useState, useEffect를 사용하지 않아도 "use client"를 선언하면 클라이언트에서 실행됨

✅ 서버에서 실행하려면 "use client"를 제거해야 함

3. SSR과 CSR의 동작방식

그럼 이제, 브라우저에서 React 컴포넌트가 렌더링되는 과정을 살펴보고,

CSR(Client-Side Rendering)과 SSR(Server-Side Rendering)의 차이를 비교해 해보려 합니다.

💡 브라우저에서 일반 HTML이 렌더링되는 과정

먼저, React 없이 일반적인 HTML 페이지가 어떻게 렌더링되는지 알아볼게요.

일반 HTML 페이지 렌더링 과정

1️⃣ 사용자가 웹사이트에 접속하면, 브라우저는 서버에 HTTP 요청을 보냄

2️⃣ 서버는 완성된 HTML 파일을 브라우저에 응답으로 전달

3️⃣ 브라우저는 HTML을 해석하고, DOM(Document Object Model)을 생성

4️⃣ CSS 파일을 다운로드하고 적용

5️⃣ JavaScript 파일을 다운로드하고 실행

6️⃣ JS가 실행되면서 기존 HTML을 변경할 수도 있음 (DOM 조작)

7️⃣ 완성된 페이지를 브라우저 화면에 표시

✅ 이 방식은 서버에서 HTML을 미리 만들어 보내므로, SEO(검색엔진 최적화)에 유리합니다.

❌ 하지만, 동적 UI(버튼 클릭, 상태 변경 등)는 JavaScript를 통해 직접 변경해야 하므로 비효율적입니다.

💡 브라우저에서 React 컴포넌트가 렌더링되는 과정 (CSR - Client-Side Rendering)

React는 일반 HTML과 다르게, Virtual DOM을 사용하여 UI를 효율적으로 업데이트하는 방식을 채택하고 있습니다.

React의 기본 렌더링 방식은 CSR(Client-Side Rendering, 클라이언트 사이드 렌더링) 입니다.

React CSR 렌더링 과정

1️⃣ 사용자가 웹사이트에 접속

2️⃣ 브라우저가 서버에서 HTML을 요청

3️⃣ 서버는 빈 HTML과 JavaScript 번들을 반환

<html>
  <head>
    <script src="/static/js/main.js"></script>  <!-- React 코드 포함 -->
  </head>
  <body>
    <div id="root"></div>  <!-- React가 여기에 렌더링됨 -->
  </body>
</html>

4️⃣ 브라우저가 JavaScript 파일을 다운로드하고 실행

5️⃣ React가 실행되면서 Virtual DOM을 생성하고, 실제 DOM을 업데이트 → 화면 표시

CSR 방식의 특징

• ✅ 첫 요청에서 서버 부하가 적음 (HTML을 미리 생성하지 않음)

• ❌ 초기 로딩 속도가 느릴 수 있음 (JS 다운로드 → 실행 후 렌더링)

• ❌ SEO가 어려움 (검색 엔진이 빈 HTML을 먼저 받게 됨)

📌 CSR 방식이 적합한 경우

✔ 대시보드, 관리자 페이지 (로그인 후 사용)

✔ 검색엔진(SEO)이 필요 없는 웹앱

✔ 실시간 데이터가 많은 서비스 (채팅, SNS)

💡 React에서 상태 업데이트가 발생할 때의 렌더링 과정

React에서 useState()를 사용하여 상태가 변경될 때, 내부적으로 Reconciliation 이 발생합니다.

상태 변경 시 React 렌더링 과정

1️⃣ 컴포넌트 내에서 setState()가 호출됨

2️⃣ React가 Virtual DOM을 사용하여 새로운 UI를 계산

3️⃣ 이전 Virtual DOM과 새로운 Virtual DOM을 비교(Diffing 알고리즘 실행)

4️⃣ 변경된 부분만 실제 DOM에 반영 (최적화된 업데이트 수행)

📌 예제: 상태 변경 시 React 렌더링 과정

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

✅ React는 Virtual DOM을 활용하여 불필요한 DOM 업데이트를 최소화하고, 성능을 최적화합니다.

❌ 하지만, CSR 방식에서는 첫 페이지 로딩이 느릴 수 있습니다.

👉 그래서 Next.js 같은 프레임워크에서는 SSR(Server-Side Rendering)을 활용해 CSR의 단점을 보완합니다!

💡 React가 서버에서 실행되는 과정 (SSR - Server Side Rendering)

Next.js 같은 프레임워크를 사용하면 React 컴포넌트를 서버에서 먼저 실행하여 HTML을 만들어 클라이언트에 전달할 수 있어요.

이를 SSR(Server-Side Rendering) 이라고 합니다.

SSR 렌더링 과정

1️⃣ 사용자가 웹사이트에 접속

2️⃣ 서버에서 React 컴포넌트를 실행하여 HTML을 생성

3️⃣ 완성된 HTML을 브라우저에 전달

4️⃣ 브라우저가 HTML을 렌더링 (JS 없이도 화면 표시 가능)

5️⃣ JavaScript 번들을 다운로드하고, React가 Hydration을 수행하여 이벤트 추가

SSR 방식의 특징

• ✅ 초기 로딩 속도가 빠름 (서버에서 HTML을 미리 생성)

• ✅ SEO(검색엔진 최적화)에 유리함

• ❌ 서버 부하가 증가 (요청마다 React를 실행해야 함)

• ❌ 페이지 이동 시마다 서버 요청 필요 (캐싱 필수)

📌 SSR 방식이 적합한 경우

✔ 블로그, 뉴스 사이트, 상품 상세 페이지 (SEO 중요)

✔ 빠른 로딩이 필요한 서비스 (eCommerce, SaaS)

✔ 초기 데이터가 중요한 페이지 (로그인 없이 접근 가능)

💡 CSR vs SSR 비교

CSR(Client-Side Rendering)SSR(Server-Side Rendering)

실행 위치	브라우저에서 실행	서버에서 실행
초기 로딩 속도	❌ 느림 (JS 실행 후 렌더링)	✅ 빠름 (HTML 미리 생성)
SEO 최적화	❌ 어려움	✅ 검색엔진 최적화 가능
페이지 전환	✅ 즉시 이동 가능	❌ 서버 요청 필요 (캐싱 필수)
서버 부하	✅ 적음	❌ 요청마다 React 실행 (서버 부하 증가)
사용 사례	대시보드, 내부 관리자 페이지, SNS	블로그, 뉴스 사이트, 상품 상세 페이지

React와 Next.js, CSR과 SSR, 그리고 서버 컴포넌트와 클라이언트 컴포넌트까지.

이 모든 개념들은 각각의 장점과 단점을 가지고 있으며, 프로젝트의 목적과 요구사항에 따라 적절한 선택이 필요합니다.

이번 마이그레이션을 진행하면서 Next.js를 React로 작업하는 결정을 하게 되었지만,

그렇다고 해서 Next.js가 불필요한 프레임워크라는 의미는 아니었습니다.

오히려 프로젝트의 특성에 따라 적절한 렌더링 방식을 선택하는 것이 얼마나 중요한지 다시 한번 깨닫는 계기가 되었어요.

기술의 선택은 단순히 최신 트렌드나 유행이 아니라, 현재 프로젝트에서 가장 적절한 방식이 무엇인지 고민하는 과정에서 나와야 합니다.

이 글이 렌더링 방식에 대한 이해를 정리하고, 올바른 선택을 하는 데 도움이 되었기를 바랍니다.