React Server Components: The Future of Full Stack React
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
웹 개발
대상자
- React 개발자 및 풀스택 엔지니어
- 성능 최적화와 서버-클라이언트 협업에 관심 있는 개발자
- 난이도: 중간 (기존 SPA 개념 이해 필요)
핵심 요약
- React Server Components(RSCs)는 서버에서 데이터를 직접 가져와 HTML을 렌더링하여
useEffect및 API 라우트를 제거함 - 성능 향상: FCP(0.4s → 1.2s), TTI(0.8s → 2.8s), JavaScript 번들 크기(23KB → 147KB)
- 서버/클라이언트 혼합 아키텍처:
'use client'지시어를 통해 클라이언트 컴포넌트를 분리 가능 - 핵심 용어:
use client,Promise.all,First Contentful Paint,Time to Interactive
섹션별 세부 요약
1. 전통적인 API 라우트 대비 RSCs의 혁신
- 기존 방식: API 라우트를 통해 데이터를 가져오는
useEffect사용 - RSCs 방식: 서버에서 직접 데이터를 가져와 HTML 렌더링 (API 레이어 제거)
- 코드 예시:
```jsx
// app/posts/page.jsx - Server Component
async function PostsPage() {
const posts = await db.posts.findMany()
return (
{posts.map(post => (
)
}
```
2. 서버/클라이언트 컴포넌트의 협업
- 서버 컴포넌트: 데이터 fetching, 정적 렌더링,
'use client'지시어 없음 - 클라이언트 컴포넌트:
'use client'지시어 필요, 상태 관리 및 이벤트 핸들링 가능 - 예제:
```jsx
// app/dashboard/RecentOrders.jsx - Client Component
'use client'
export function RecentOrders({ initialOrders }) {
const [orders, setOrders] = useState(initialOrders)
}
```
3. 성능 향상 분석
- RSCs 적용 전: JavaScript 번들 147KB, FCP 1.2s, TTI 2.8s
- RSCs 적용 후: JavaScript 번들 23KB, FCP 0.4s, TTI 0.8s
- 이유: 정적 콘텐츠는 HTML로 전송, 클라이언트에서만 hydrate
4. 주의사항 및 제약
- 서버/클라이언트 간 데이터 전달 제한: 함수/복잡한 객체 전달 불가
- 환경 변수 처리:
'use client'지시어가 있는 컴포넌트에process.env.SECRET_API_KEY노출 위험 - 예시:
```jsx
// ✅ Safe - server component
const secret = process.env.DATABASE_URL
// ❌ Dangerous if this becomes client-side
const apiKey = process.env.SECRET_API_KEY
```
5. RSCs의 적합한 활용 사례
- 좋은 사례: 블로그, 문서, 대시보드, 전자상거래 페이지
- 부적합한 사례: 게임, 실시간 협업 도구, 대부분 클라이언트 상태 기반 앱
결론
- 실무 적용 팁:
- Next.js 13+부터 시작 (RSCs 지원 최적)
- 간단한 프로젝트부터 시작 (프로덕션 마이그레이션은 후순위)
- 서버-최우선 사고방식 (
'use client'지시어는 필요한 경우만 사용) - 데이터 fetching 실험 (RSCs의 핵심 강점)
- 핵심 메시지: RSCs는 React의 풀스택 프레임워크 성숙화의 핵심이며, 성능과 개발자 경험을 근본적으로 개선함.