✅ [14편] 리액트 서버 컴포넌트와 클라이언트 컴포넌트 완전 정복: 개념, 차이점, 구조, 실무 적용 전략까지

✅ 리액트 서버 컴포넌트와 클라이언트 컴포넌트 완전 정복: 개념, 차이점, 구조, 실무 적용 전략까지

리액트는 오랫동안 브라우저 기반 렌더링 방식(CSR, Client Side Rendering)에 의존해 왔습니다. 하지만 사용자 경험과 성능이 중요해지는 시대가 오면서, 서버 측에서 렌더링하는 SSR 방식이 주목받게 되었고, 그 발전형이 바로 React Server Component(RSC)입니다. 특히 Next.js 13 버전 이후 기본 렌더링 모델로 도입되면서 실제 실무에서도 널리 활용되고 있습니다. 이 글에서는 초보자라도 이해할 수 있도록 서버 컴포넌트와 클라이언트 컴포넌트의 개념, 차이점, 실행 구조, 장단점, 그리고 실제 프로젝트에서 어떻게 섞어 사용해야 하는지까지 상세하게 다뤄보겠습니다.

🟦 1. 서버 컴포넌트(Server Component)란 무엇인가?

서버 컴포넌트는 말 그대로 서버에서 렌더링되는 컴포넌트입니다. 브라우저에서 실행되지 않기 때문에 클라이언트 JS 번들에 포함되지 않습니다. 즉, 유저의 브라우저로 전달되는 코드 양이 줄어 성능이 크게 개선되고, 초기 페이지 로딩 속도도 빨라지는 효과를 제공합니다.

✔ 서버 컴포넌트의 특징

JS 번들 사이즈가 줄어 성능 향상
데이터베이스, 파일 시스템과 직접 상호작용 가능
SEO에 매우 강함
서버에서 실행되므로 브라우저 이벤트나 상태 관리 훅 사용 불가
API 요청이 필요 없는 구조 가능 (서버에서 직접 데이터 Fetch)
즉, 서버 컴포넌트는 “렌더링을 서버에서 미리 처리하고 HTML을 브라우저에 전달하는 방식”으로 이해할 수 있습니다.

🟦 2. 클라이언트 컴포넌트(Client Component)란 무엇인가?

클라이언트 컴포넌트는 기존의 우리가 알고 있는 일반적인 리액트 컴포넌트입니다.
브라우저에서 실행되고, 사용자 인터랙션을 처리할 수 있는 모든 기능을 포함합니다.
✔ 클라이언트 컴포넌트의 특징
onClick, onChange 같은 이벤트 처리 가능
useState, useEffect 등 훅 사용 가능
브라우저에서 실행되므로 JS 번들이 필요함
서버와 달리 환경 변수나 DB 접근 불가
즉, 사용자 입력, 버튼 클릭, 폼 제출 등 “상호작용이 필요한 영역”은 반드시 클라이언트 컴포넌트여야 합니다.

🟦 3. 서버 컴포넌트 vs 클라이언트 컴포넌트 비교

두 방식은 목적과 실행 환경이 완전히 다르기 때문에 정확히 구분하는 것이 중요합니다.
구분 서버 컴포넌트 클라이언트 컴포넌트
실행 위치 서버 브라우저
JS 번들 여부 포함되지 않음 포함됨
SEO 매우 강함 일반적
상태 관리 ❌ 불가 ⭕ 가능
이벤트 처리 ❌ 불가 ⭕ 가능
데이터 Fetch 서버에서 직접 가능 보통 API 필요
성능 우수 상대적으로 낮음
이 표만 잘 기억해도 언제 어떤 컴포넌트를 써야 할지 명확해집니다.

🟦 4. 서버 컴포넌트가 왜 등장했을까?

기존 CSR 방식은 다음과 같은 한계가 있었습니다.
첫 렌더링 전에 JS가 다운로드·파싱·실행되어야 해 초기 성능이 낮음
SEO에 취약
많은 컴포넌트가 불필요하게 클라이언트 번들에 포함됨
백엔드 API 호출이 필수라 서버 → 프런트로 데이터 전달 과정이 번거로움
서버 컴포넌트는 이러한 문제를 해결하기 위해 등장했습니다.
서버에서 렌더링된 HTML을 직접 보내주기 때문에 빠르고, 번들 크기를 줄여 브라우저 부담을 덜어줍니다.

🟦 5. 실제 코드로 이해하는 서버/클라이언트 컴포넌트

✔ 서버 컴포넌트 예시 (Next.js)
export default async function Page() {
const data = await getProducts();
return (
<div>
<h1>상품 목록</h1>
{data.map(item => (
<p key={item.id}>{item.name}</p>
))}
</div>
);
}
서버에서 데이터베이스 조회 가능
useState, onClick 사용 불가
컴포넌트 자체가 async 함수여도 문제 없음
✔ 클라이언트 컴포넌트 예시
"use client";
import { useState } from "react";
export default function Counter() {
const [count, setCount] = useState(0);
return (
<button onClick={() => setCount(count + 1)}>
{count} 증가
</button>
);
}
onClick 이벤트 처리 가능
상태 관리 가능
로직이 브라우저에서 실행됨

🟦 6. 서버 컴포넌트만으로는 해결할 수 없는 부분

서버 컴포넌트가 아무리 강력해도 다음 기능은 불가능합니다.
사용자 이벤트 처리
유저 입력값 관리
로컬 스토리지 접근
애니메이션 처리
클라이언트 네이티브 API(window, document 등)
결국 대부분의 UI는 서버 컴포넌트 + 클라이언트 컴포넌트를 혼합해서 구현해야 합니다.

🟦 7. 두 컴포넌트를 조합하는 실무 구조

가장 추천되는 구조는 다음과 같습니다.
✔ 1. 페이지, 레이아웃 → 서버 컴포넌트
SEO와 초기 로딩 성능이 중요하므로 기본적으로 서버에서 렌더링합니다.
✔ 2. 리스트 데이터, 텍스트 데이터 → 서버 컴포넌트
불필요한 클라이언트 JS 번들 크기 감소.
✔ 3. 버튼, 입력창, 폼 → 클라이언트 컴포넌트
사용자 상호작용이 필요한 UI는 클라이언트에서만 가능.
✔ 4. 서버에서 데이터 Fetch → 클라이언트로 전달
프런트에서 별도 API 호출이 줄어 전반적인 구조가 명확해짐.

🟦 8. 실무에서 자주 구성하는 컴포넌트 구조 예시

src/app/
├ layout.js (서버 컴포넌트)
├ page.js (서버 컴포넌트)
├ components/
│ ├ ProductList.js (서버 컴포넌트)
│ ├ ProductCard.js (서버 컴포넌트)
│ ├ CartButton.js (클라이언트 컴포넌트)
│ └ Counter.js (클라이언트 컴포넌트)
서버 컴포넌트는 데이터 중심,
클라이언트 컴포넌트는 인터랙션 중심이라고 이해하면 좋습니다.

🟦 9. 성능 관점에서 서버 컴포넌트의 강력함

서버 컴포넌트는 성능에서 엄청난 이점을 제공합니다.
✔ 클라이언트 JS 번들 감소 → TTI(Time to Interactive) 개선
JS가 적게 로드되므로 UX 향상.
✔ 백엔드와 직접 연결되어 API 비용 감소
프런트 → 서버 → DB의 긴 구조가 필요 없음.
✔ SEO 최적화
검색 엔진이 완성된 HTML을 바로 수집 가능.
✔ 캐싱이 매우 유리
서버에서 렌더된 결과물을 캐싱하면 비용 절약 가능.

🟦 10. 결론: 언제 서버 컴포넌트, 언제 클라이언트 컴포넌트?

✔ 서버 컴포넌트 추천 상황

SEO 중요한 페이지
리스트/상품/텍스트 내용 렌더링 초기 렌더링 속도가 중요한 화면
외부 API/DB 접근이 많은 페이지

 

✔ 클라이언트 컴포넌트 추천 상황

입력 폼, 버튼, 드롭다운 등 상호작용 필수
useState/useEffect 필요
애니메이션/모달/알림 UI
브라우저 API가 필요한 경우
서버와 클라이언트를 적절히 섞는 것이 최고의 성능과 유지보수성을 만드는 핵심입니다.