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

배경

Next.js 13이 출시된 지 거의 1년이 지났지만, 프로덕션 적용은 미뤄왔다. 이번에 새 프로젝트 시작을 앞두고 app directory와 Server Components를 본격적으로 검토했다.

기존 구조의 한계

현재 운영 중인 서비스는 pages directory 기반이다. API Routes로 BFF 패턴을 구현하고, 클라이언트에서 React Query로 데이터를 fetching한다.

// pages/products/[id].tsx
const ProductPage = () => {
  const { id } = useRouter().query;
  const { data } = useQuery(['product', id], () => fetchProduct(id));
  
  return <ProductDetail product={data} />;
};

문제는 waterfall이다. 페이지 로드 → 클라이언트 hydration → API 호출 → 렌더링. 초기 로딩이 느리다는 피드백이 계속 있었다.

Server Components 실험

app directory에서는 기본적으로 모든 컴포넌트가 서버 컴포넌트다.

// app/products/[id]/page.tsx
async function ProductPage({ params }: { params: { id: string } }) {
  const product = await fetchProduct(params.id);
  
  return <ProductDetail product={product} />;
}

서버에서 데이터를 fetch하고 HTML을 생성해서 내려준다. 클라이언트는 즉시 컨텐츠를 볼 수 있다.

충돌 지점

1. Context API 사용 불가: 전역 상태 관리를 Context로 하고 있었는데, Server Components에서는 사용할 수 없다.
2. 이벤트 핸들러: 'use client' 디렉티브로 클라이언트 컴포넌트를 명시해야 한다.
3. 학습 곡선: 팀원들이 서버/클라이언트 경계를 이해하는 데 시간이 필요하다.

결론

새 프로젝트는 app directory로 시작하기로 했다. 기존 서비스 마이그레이션은 보류. RSC의 성능 이점은 명확하지만, 전면 전환은 리스크가 크다. 점진적 적용 전략을 고민 중이다.