React Server Components 도입 검토하며 느낀 점

배경

Next.js 13이 출시된 지 1년이 지났고, 팀 내에서 새 프로젝트에 App Router를 적용할지 논의가 있었다. React Server Components(RSC)의 개념은 매력적이었지만, 실제 도입 가능성을 판단하기 위해 검토 작업을 진행했다.

주요 검토 사항

1. 번들 크기 감소

서버에서만 실행되는 컴포넌트는 클라이언트 번들에 포함되지 않는다. 실제로 간단한 프로토타입에서 약 30% 정도 번들 크기가 줄어드는 것을 확인했다.

// app/posts/page.jsx
import { db } from '@/lib/db';

// 이 컴포넌트는 서버에서만 실행됨
export default async function PostsPage() {
  const posts = await db.post.findMany();
  
  return (
    <div>
      {posts.map(post => (
        <PostCard key={post.id} post={post} />
      ))}
    </div>
  );
}

2. 라이브러리 호환성 문제

문제는 기존 생태계였다. useState, useEffect 같은 훅을 사용하는 컴포넌트는 'use client' 지시어가 필요한데, 많은 서드파티 라이브러리들이 아직 RSC를 고려하지 않고 있었다.

특히 UI 라이브러리나 상태 관리 도구들이 대부분 클라이언트 컴포넌트로만 동작해서, 결국 'use client' 바운더리를 어디에 둘지 고민이 많았다.

3. 학습 곡선과 멘탈 모델 변화

팀원들과 함께 샘플 프로젝트를 만들어보면서, 서버/클라이언트 컴포넌트를 구분하는 새로운 사고방식이 필요함을 느꼈다. 특히 props로 함수를 전달할 수 없다는 제약이 기존 패턴을 많이 바꿔야 했다.

결론

당장은 Pages Router로 진행하기로 했다. RSC는 분명 미래지향적이지만, 2023년 말 시점에서는:

• 안정적인 레퍼런스와 베스트 프랙티스 부족
• 서드파티 라이브러리 대응 미흡
• 팀 전체의 학습 비용

을 고려했을 때 성급한 도입은 리스크가 크다고 판단했다. 2024년 중반쯤 다시 검토해볼 예정이다.