Next.js 앱 라우터와 페이지 라우터 진화 탐색

소개

웹 개발 환경은 성능, 유지보수성, 개발자 경험에 대한 증가하는 요구를 충족하기 위해 새로운 패러다임과 도구가 등장하면서 끊임없이 변화하고 있습니다. 최근 몇 년간 가장 영향력 있는 발전 중 하나는 React 애플리케이션 구축 방식에 있어 중요한 진전을 나타내는 앱 라우터의 도입, 특히 확립된 페이지 라우터의 후속작이라는 점에서 Next.js 프레임워크 내의 진화입니다. 이 결정적인 아키텍처 변화는 데이터 가져오기, 렌더링 및 라우팅에 대한 향상된 기능을 제공하며 React 애플리케이션 구축 방식에서 중요한 발걸음을 나타냅니다. 이 두 라우팅 메커니즘 간의 미묘한 차이를 이해하는 것은 더 이상 단순한 학문적 관심사가 아니라 견고하고 확장 가능하며 효율적인 웹 경험을 구축하고자 하는 개발자에게 실질적인 필수 요소입니다. 이 글에서는 앱 라우터와 페이지 라우터를 철저히 조사하고, 기본 아키텍처를 분석하고, 각자의 강점과 약점을 평가하고, 기존 애플리케이션을 마이그레이션하거나 새로운 애플리케이션을 시작하기 위한 명확한 경로를 제공할 것입니다.

Next.js 라우팅 패러다임 이해

모든 웹 애플리케이션의 핵심에는 사용자 간에 애플리케이션의 다른 부분으로 이동하는 방법을 결정하고 콘텐츠가 제공되는 방식을 결정하는 라우팅 시스템이 있습니다. Next.js는 두 가지 주요 접근 방식을 제공합니다. 페이지 라우터와 앱 라우터입니다. 이들의 차이점을 파악하려면 기본 원칙과 개발 패턴에 미치는 영향을 이해하는 것이 중요합니다.

페이지 라우터: 파일 시스템 기반 기반

Next.js의 원래 라우팅 시스템인 페이지 라우터는 파일 시스템 기반 라우팅 원칙에 따라 작동합니다. pages 디렉터리 내에 배치된 모든 JavaScript, TypeScript 또는 JSX 파일은 자동으로 라우트가 됩니다. 예를 들어 pages/index.js는 루트 경로(/)에 해당하고 pages/about.js는 /about에 매핑됩니다.

페이지 라우터의 주요 개념:

• 파일 시스템 기반 라우팅: pages 디렉터리 내의 파일 구조에 의해 라우트가 정의됩니다.
• 데이터 가져오기: 데이터 가져오기는 주로 getServerSideProps, getStaticProps, getStaticPaths를 사용하여 페이지 수준에서 처리됩니다. 이러한 함수는 구성 요소가 렌더링되기 전에 서버에서 실행되어 서버 측 렌더링(SSR) 및 정적 사이트 생성(SSG)과 같은 사전 렌더링 전략을 허용합니다.

// pages/posts/[id].js
export async function getServerSideProps(context) {
  const { id } = context.params;
  const res = await fetch(`https://api.example.com/posts/${id}`);
  const post = await res.json();
  return { props: { post } };
}

function Post({ post }) {
  return (
    <div>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </div>
  );
}

export default Post;

• 클라이언트 측 탐색: next/link는 페이지 간의 클라이언트 측 전환에 사용되어 빠른 SPA(단일 페이지 애플리케이션)와 유사한 경험을 보장합니다.

// pages/index.js
import Link from 'next/link';

function HomePage() {
  return (
    <div>
      <Link href="/about">
        <a>About Us</a>
      </Link>
    </div>
  );
}

export default HomePage;

페이지 라우터의 장점:

• 단순성과 친숙함: 기존의 파일 기반 라우팅 시스템을 사용하는 개발자에게 이해하기 쉽습니다.
• 성숙한 생태계: 오랜 기간 동안 잘 지원되어 왔으며 방대한 양의 문서 및 커뮤니티 리소스를 보유하고 있습니다.
• 관심사의 명확한 분리: 각 페이지는 일반적으로 별도의 라우트와 관련 데이터 가져오기 논리를 나타냅니다.

페이지 라우터의 단점:

• 데이터 가져오기 및 UI의 결합: 데이터 가져오기 논리는 종종 페이지 구성 요소에 직접 연결되어 중첩된 구성 요소 간에 데이터 가져오기를 공유하거나 재사용하기 어렵습니다.
• 제한된 레이아웃 중첩: 복잡한 레이아웃을 관리하기가 번거로울 수 있으며, 종종 상위 구성 요소나 prop drilling이 필요합니다.
• 깊은 트리에 대한 성능 문제: 깊게 중첩된 라우트 및 복잡한 데이터 종속성이 있는 애플리케이션의 성능을 최적화하는 것은 전체 페이지가 라우트 변경 시 다시 렌더링되는 경우가 많기 때문에 어려울 수 있습니다.

앱 라우터: React 서버 구성 요소 패러다임

React 서버 구성 요소(RSC) 위에 구축된 앱 라우터는 패러다임 변화를 나타냅니다. 페이지를 라우팅 및 데이터 가져오기의 기본 단위로 취급하는 대신 앱 라우터는 보다 세분화된 구성 요소 수준 접근 방식을 도입합니다. app 디렉터리 내의 파일과 폴더는 레이아웃, 로딩 상태, 오류 경계 및 API 라우트에 대한 추가 규칙과 함께 라우트를 정의합니다.

앱 라우터의 주요 개념:

• 폴더 기반 라우팅: 페이지 라우터와 유사하지만 이제 폴더가 라우트를 정의하고 page.js 파일이 해당 라우트의 UI를 정의합니다.

  app/
  ├── layout.js       // 루트 레이아웃, 모든 라우트에 적용
  ├── page.js         // 홈 페이지
  ├── dashboard/
  │   ├── layout.js   // 대시보드 레이아웃, 대시보드 라우트에 적용
  │   ├── page.js     // 대시보드 홈
  │   ├── analytics/
  │   │   └── page.js // 대시보드 분석
  │   └── settings/
  │       └── page.js // 대시보드 설정
  

• React 서버 구성 요소(RSCs): 이것이 기본 빌딩 블록입니다. RSC를 사용하면 구성 요소를 번들링하여 클라이언트로 보내지 않고 서버에서 렌더링할 수 있습니다. 이를 통해 클라이언트 측 JavaScript 번들 크기를 크게 줄이고 초기 페이지 로드 성능을 향상시킬 수 있습니다. app 디렉터리에서는 구성 요소가 기본적으로 서버 구성 요소입니다. 구성 요소를 클라이언트 구성 요소로 만들려면 `