App Router vs Pages Router
Next.js를 처음 배우면 기능보다 먼저 구조 선택에서 막히는 경우가 많습니다.
Pages Router로 시작해도 되나?, App Router를 바로 쓰는 게 맞나? 같은 질문은 입문자뿐 아니라 기존 프로젝트를 운영하는 팀에서도 자주 나옵니다.
겉보기에는 폴더 구조 차이처럼 보이지만, 실제로는 데이터 패칭 방식과 컴포넌트 경계, 성능 전략까지 바뀌는 선택입니다.
이 절에서는 두 라우터를 단순 비교표로 끝내지 않고, 어떤 프로젝트에서 어떤 선택이 더 유리한지 판단 기준까지 함께 정리합니다.
읽고 나면 새 프로젝트 시작과 기존 프로젝트 유지보수에서 각각 어떤 결정을 내리는 것이 합리적인지 감을 잡을 수 있습니다.
Pages Router: 익숙함 속의 효율성
Next.js의 초기부터 함께 해온 Pages Router는 파일 시스템 기반 라우팅을 사용합니다. pages 디렉터리 안에 React 컴포넌트를 정의하면, 해당 파일의 경로가 웹 애플리케이션의 URL 경로로 자동으로 매핑됩니다. 예를 들어, pages/about.js 파일은 /about 경로에 접근했을 때 렌더링됩니다.
- 파일 시스템 기반 라우팅: 직관적이고 설정이 간단하여 빠르게 페이지를 만들 수 있습니다.
- 쉬운 학습 곡선: React 개발자에게 익숙한 방식으로, 새로운 개념을 많이 익히지 않아도 됩니다.
- 데이터 페칭 방식:
getServerSideProps,getStaticProps,getStaticPaths와 같은 함수를 사용하여 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)을 구현합니다.
Pages Router는 특히 소규모 프로젝트나 빠른 프로토타이핑에 매우 효율적입니다. 하지만 복잡한 레이아웃이나 데이터 관리가 필요한 대규모 애플리케이션에서는 관리가 어려워질 수 있다는 단점도 있습니다.
App Router: 미래를 위한 혁신
Next.js 13부터 도입된 App Router는 React의 최신 기능인 React Server Components(RSC)와 스트리밍(Streaming)을 기반으로 설계되었습니다. App Router는 app 디렉터리 안에서 라우팅과 컴포넌트 구조를 정의하며, Pages Router와는 근본적으로 다른 접근 방식을 취합니다.
- React Server Components(RSC): 컴포넌트를 서버에서 렌더링하여 클라이언트로 전송함으로써 초기 로딩 속도를 획기적으로 개선하고, 클라이언트 번들 크기를 줄여줍니다.
- 스트리밍: 페이지의 일부만 먼저 클라이언트에 전송하여 사용자에게 빠르게 보여주고, 나머지 콘텐츠는 백그라운드에서 로딩하는 방식으로 사용자 경험을 향상시킵니다.
- 레이아웃(Layouts): 여러 페이지에서 공유되는 UI를 쉽게 정의하고 중첩할 수 있어 코드 재사용성과 유지보수성이 뛰어납니다.
- 데이터 페칭:
fetchAPI를 확장하여 더욱 유연하고 강력한 데이터 페칭 기능을 제공하며, 캐싱 전략을 세밀하게 제어할 수 있습니다. - 향상된 SEO 및 성능: 서버에서 렌더링되는 부분이 많아 검색 엔진 최적화에 유리하며, 전반적인 성능이 향상됩니다.
App Router는 Pages Router에 비해 초기 학습 곡선이 다소 높을 수 있지만, 대규모의 복잡한 애플리케이션을 구축하고 최적의 성능을 끌어내야 할 때 그 진가가 발휘됩니다. Next.js 16는 App Router를 기본 라우터로 권장하며, 앞으로의 Next.js 개발은 App Router 중심으로 이루어질 것입니다.
어떤 라우터를 선택해야 할까요?
이 책에서는 App Router를 중심으로 Next.js 16의 모든 기능을 다룰 예정입니다. App Router는 Next.js의 미래이며, 웹 애플리케이션 개발에 있어 더 많은 유연성과 성능 최적화 기회를 제공합니다.
물론 기존 Pages Router 프로젝트를 App Router로 마이그레이션하는 방법도 간략히 다루겠지만, Next.js의 최신 트렌드와 강력한 기능을 온전히 경험하기 위해 App Router에 집중하는 것이 현명한 선택입니다.
다만 모든 프로젝트가 즉시 App Router로 전환해야 하는 것은 아닙니다.
이미 안정적으로 운영 중인 서비스라면, 라우트 단위로 점진 전환하면서 테스트/배포 리스크를 관리하는 편이 현실적입니다.
즉 무조건 최신보다 현재 서비스 안정성과 전환 비용을 함께 계산하는 것이 좋은 선택입니다.
이제 App Router와 Pages Router의 차이에 대해 이해하셨으리라 생각합니다.
선택 전 점검 체크리스트
아래 항목을 먼저 정리하면 라우터 선택 실수를 줄일 수 있습니다.
- 신규 프로젝트인가, 기존 서비스 점진 전환인가
- 서버 컴포넌트와 스트리밍을 당장 활용할 계획이 있는가
- 팀이
getServerSideProps/getStaticProps중심 코드를 얼마나 보유하고 있는가 - 배포 일정상 마이그레이션 리스크를 감당할 수 있는가
다음 절 연결 포인트
다음 절에서는 App Router를 기준으로 실제 프로젝트 구조를 다루므로, 아래 기준을 미리 정해두면 학습 전환이 빠릅니다.
- 새 프로젝트는 App Router 기본 구조로 시작하고, 기존 서비스는 라우트 단위 전환 범위를 먼저 정의합니다.
- 팀 규칙 문서에 "서버 컴포넌트 우선, 클라이언트 컴포넌트 최소화" 원칙을 명시합니다.
- 전환 전후의 빌드 시간, 번들 크기, 초기 로딩 지표를 같은 조건에서 비교합니다.
Next.js 학습 연결 체크
라우터 비교를 끝냈다면 다음 절로 넘어가기 전에 전환 기준을 짧게 고정합니다.
- 신규 프로젝트는 App Router 우선, 기존 프로젝트는 단계적 전환 원칙을 유지합니다.
- 서버/클라이언트 컴포넌트 경계를 문서화해 팀 합의를 맞춥니다.
- 전환 전후 성능 지표를 같은 조건에서 비교합니다.