React Server Components: Next.js에서 실제로 써보며 느낀 점

 

React 18과 함께 등장한 React Server Components(RSC) 는

2025년 현재, Next.js App Router에서 기본값으로 채택되며 점점 보편화되고 있습니다.

저도 최근 중소형 SaaS 프로젝트에서 실제로 RSC를 도입하여 Next.js 14 기반으로 구성해보았고,
그 경험을 기반으로 **“이게 진짜 실무에서 쓸만한가?”**라는 질문에 솔직하게 답해보려 합니다.

---

1. RSC의 정체: 기대 vs 현실

✅ 기대했던 점

• JS 번들 사이즈 확 줄어들겠지?
• DB 호출을 바로 컴포넌트에서 처리하면 편하겠지?
• 데이터 의존성과 컴포넌트 트리를 깔끔히 나눌 수 있겠지?

 

😐 현실은?

• 예, 줄어듭니다. 하지만... 관리 포인트가 늘어납니다.
• 클라이언트 컴포넌트로의 “승격”이 잦아지면, 생각보다 JS 번들은 다시 커집니다.
• 데이터 계층과 컴포넌트 계층이 겹치기 때문에 개발자 간 협업이 꼬일 수 있습니다.

 

---

2. 실제 코드 구조는 어떻게 달라졌을까?

기존 방식 (Client Components only):

// Dashboard.tsx
useEffect(() => {
  fetch("/api/users").then(setData);
}, []);

 

RSC 방식:

// Dashboard.server.tsx
import { getUsers } from "@/db";

export default async function Dashboard() {
  const users = await getUsers();
  return <UserList users={users} />;
}

 

📌 장점:

• 데이터 호출과 렌더링이 함께 있어 코드 집중도가 높음
• Suspense를 활용하면 비동기 렌더링 UX도 꽤 괜찮음

 

📌 단점:

• Server → Client 경계가 애매해지며 디버깅과 SSR 에러 추적이 어려움
• RSC에선 상태 관리 라이브러리(Zustand, Redux 등)를 쓸 수 없음

---

 

3. 팀 협업 시 혼란 포인트

• .server.tsx, .client.tsx, .tsx 파일 구분이 생기고, 실수로 클라이언트 전용 훅을 Server 컴포넌트에서 호출하면 에러도 늦게 감지됨
• 디자이너 or 프론트엔드 개발자가 서버 코드가 섞인 컴포넌트를 마주했을 때 당황스러움

✅ 협업을 위해선 다음 규칙이 필요했습니다:

1. 서버 전용 컴포넌트는 routes/ 안에서만 사용한다
2. 클라이언트 전용 기능은 반드시 분리된 파일에 작성
3. loading UI는 전부 Suspense fallback으로 처리

---

 

4. 성능은? 정말 빨라졌을까?

실제로 비교한 Lighthouse 지표 (Next.js 13 vs Next.js 14 RSC 도입 이후):

항목 Next.js 13 Next.js 14 (RSC)

JS Bundle Size	470kb	320kb
TTFB (서버 응답 시간)	180ms	150ms
First Contentful Paint	1.8s	1.4s

 

📌 결론: 초기 렌더링 성능은 개선
하지만 복잡한 대시보드에서 부분적으로 클라이언트 컴포넌트가 증가하면 JS 리소스도 점점 늘어남

---

 

5. 결론: 지금 RSC를 써야 할까?

✅ 이런 경우 추천:

• 정보성 페이지, 블로그, SEO 중심 콘텐츠
• 초기 상태가 고정적인 SSR 기반 앱
• JS 최소화가 중요한 마케팅 페이지

 

❌ 이런 경우 고민 필요:

• 실시간 UI (채팅, 커머스 인터랙션)
• heavy form + 클라이언트 상태 많은 앱
• 디자이너/프론트 중심의 협업이 많은 팀

---

 

💬 한 줄 요약

RSC는 “마법”이 아닙니다.
성능은 좋아지지만, 복잡도와 개발 흐름은 달라집니다.

---