Next.js 13 App Router는 데이터 패칭 아키텍처를 근본적으로 바꿨다. 기존 Pages Directory에서는 페이지 수준의 getServerSideProps/getStaticProps로만 서버 데이터를 가져올 수 있었지만, App Router에서는 모든 컴포넌트가 기본적으로 Server Component가 되어 컴포넌트 단위로 직접 데이터를 패칭할 수 있다. 이는 중복 코드를 제거하고 병렬 요청을 가능하게 해 성능과 보안 모두를 개선한다.
핵심 포인트- App Router에선 모든 컴포넌트가 Server Component 기본값이다 — 레이아웃·페이지·개별 컴포넌트 모두 직접 데이터를 패칭할 수 있어 페이지 레벨 함수에 의존할 필요가 없다.
- 요청 deduplication: 여러 컴포넌트가 같은 URL을 각자 fetch해도 React가 단일 네트워크 요청으로 합쳐준다. Props drilling 없이 컴포넌트 독립성을 유지한다.
- fetch() 확장 옵션: 기본값은 빌드 타임 정적 캐시, `{cache: 'no-store'}`는 매 요청 신규 데이터, `{next: {revalidate: n}}`은 n초 주기 재검증이다.
- 보안 향상: 백엔드 접근이 서버 사이드에서만 이뤄져 API 키나 DB credentials가 클라이언트에 노출되지 않는다.
- Loading UI + Suspense로 서버 컴포넌트 로딩 중 스켈레톤을 보여주어 LCP 개선과 Core Web Vitals 향상이 가능하다.
상세 정리- Pages Directory 한계: getServerSideProps(SSR, 매 요청), getStaticProps(SSG, 빌드 타임), ISR(revalidate 속성)이 모두 페이지 레벨에서만 작동했다. 특정 컴포넌트만 데이터가 필요해도 페이지 전체에서 props로 내려줘야 했다.
- 클라이언트 사이드 폴백 문제: useEffect나 SWR로 클라이언트 패칭을 하면 서버-클라이언트 왕복이 늘어 성능 손실이 있고, credentials를 숨기기도 어렵다.
- Server Component 기본값: App Router에서 컴포넌트는 기본적으로 Server Component다. async/await으로 직접 fetch()를 호출하면 서버에서 실행된다. 클라이언트 기능(useState, useEffect 등)이 필요하면 'use client'를 명시한다.
- 요청 deduplication: 같은 URL을 여러 Server Component가 각자 fetch해도 React가 자동으로 단일 요청으로 합쳐준다. 컴포넌트 트리 전체에서 props drilling 없이 각자 데이터를 요청해도 네트워크 비용이 늘지 않는다.
- 정적 캐시 기본값: fetch() 기본 동작은 빌드 타임에 데이터를 가져와 캐시한다. ISR처럼 {next: {revalidate: 60}}으로 60초마다 갱신하거나, {cache: 'no-store'}로 항상 최신 데이터를 요청할 수 있다.
- 병렬 요청 개선: 컴포넌트별 독립 fetch는 직렬 폭포(cascading waterfall)를 방지한다. 기존에 부모가 데이터를 받고 자식에게 넘기던 구조가 각자 병렬로 패칭하는 구조로 바뀐다.
- Loading UI: loading.tsx 파일을 두면 Server Component가 데이터를 받는 동안 스켈레톤이 보여진다. Suspense와 통합되어 부분 렌더링이 가능하다.
- Core Web Vitals 연계: LCP 개선(빠른 첫 의미있는 콘텐츠 표시)과 CLS 감소(스켈레톤으로 레이아웃 시프트 방지)로 검색 엔진 순위에도 영향을 준다.
왜 읽나Next.js 12 Pages Directory에서 13 App Router로 마이그레이션하거나, React Server Components의 데이터 패칭 패턴을 처음 접하는 프론트엔드 개발자에게 핵심 차이와 실제 적용 방법을 제시한다.
Vercel Blog·
LINE Engineering·