React Server Components와 Next.js 13 App Router 도입 검토

배경

회사 대시보드 프로젝트를 Next.js 13으로 업그레이드하면서 App Router를 본격적으로 검토하게 되었다. 지난 11월 출시 당시엔 베타였지만, 이제 프로덕션 레디로 판단했다.

Server Component의 이점

데이터 fetching 로직을 서버에서 처리하니 클라이언트 번들 사이즈가 확실히 줄었다. 특히 차트 라이브러리 같은 무거운 의존성을 서버 컴포넌트에서 사용하지 않게 분리하니 효과가 컸다.

// app/dashboard/page.tsx
async function Dashboard() {
  const data = await fetch('https://api.example.com/stats', {
    next: { revalidate: 60 }
  });
  const stats = await data.json();
  
  return <StatsView data={stats} />;
}

겪은 문제들

1. 'use client' 경계 설정

어디까지를 서버 컴포넌트로 둘지 판단하기 애매했다. useState나 useEffect를 쓰는 순간 'use client'를 붙여야 하는데, 컴포넌트 계층 설계를 다시 고민해야 했다.

2. 라우팅 구조 변경

Pages Router의 getServerSideProps 패턴에 익숙했던 팀원들이 혼란스러워했다. 파일 시스템 기반 라우팅은 비슷하지만 layout.tsx, loading.tsx 등 새로운 컨벤션을 학습해야 했다.

3. 캐싱 전략

fetch의 next.revalidate 옵션과 cache 옵션을 제대로 이해하는 데 시간이 걸렸다. 문서가 아직 부족한 부분이 있어 시행착오가 많았다.

결론

전면 마이그레이션은 보류하고, 신규 기능부터 App Router로 개발하기로 했다. 성능 이점은 분명하지만 팀 전체의 학습 곡선과 안정성을 고려한 결정이다. 연말쯤 다시 검토 예정이다.