사내 서비스 중 next를 기반으로 page 라우터로 구성된 서비스가 있는데요.
최근에 app 라우터로 마이그레이션을 진행하게 되면서, app 라우터와 page 라우터의 차이점에 대해 공부한 것을 공유드리려고 합니다.
먼저 next 13 버전부터 도입된 App Router 는 단순한 기능 개선이 아니라,
React 의 렌더링 철학 자체를 클라이언트 중심에서 서버 중심으로 전환한 대규모 변화입니다.
App Router 는 폴더 중심 트리 구조를 기반으로 하며, 각 구간마다 layout.tsx 를 정의해 중첩 레이아웃을 구성할 수 있습니다.
예를 들어, /app/dashboard/layout.tsx 에서 사이드바를 정의하면,
/app/dashboard/settings 에서도 자동으로 동일한 구조를 유지합니다.
Page Router 는 파일 이름 기반으로 _app.tsx 를 통해 전역 레이아웃을 관리할 수 있었기 떄문에 부분적인 공통 UI 를 구성하기가 쉽지 않았습니다.
Page 라우터는 클라이언트 중심으로, getServerSideProps 와 getStaticProps 와 같은
Next 전용 API 를 사용해서 데이터를 패칭했으며, 스트리밍 렌더링을 지원하지 않고 캐싱을 직접 설정해야 했습니다.
App 라우터는 서버 중심으로, fetch 또는 async 함수를 사용하여 데이터를 패칭하며,
Suspense 기반 스트리밍이 가능하고, 자동 캐싱 (fetch 단위) 를 지원합니다.
또한, RSC 를 적극 활용하여
컴포넌트를 서버에서 먼저 렌더링하고, 필요한 데이터만 클라이언트로 스트리밍하기 때문에,
초기 로딩 속도가 개선되고, SEO 최적화에도 유리하며, 자바스크립트 번들 크기 감소, 서버 리소스 활용을 극대화할 수 있는 장점이 있습니다.
즉 "서버에서 할 수 있는 건 서버에서 처리하자" 는 NextJS 의 새로운 철학이 반영된 구조입니다.
첫 번째, 클라이언트 컴포넌트는 명시적으로 선언해야 합니다.
useState, useEffect 를 사용하는 컴포넌트는 반드시 파일 상단에 use client 를 선언해야 합니다.
두 번째, API Routes구조가 /app/api 로 이동합니다.
기존 /pages/api 도 여전히 작동하지만, App Router 에서는 /app/api 가 권장 경로입니다.
세 번째, 상태 관리 라이브러리 호환성 확인을 꼭 해야 합니다.
Redux, Zustand, React Query 등은 클라이언트 전용 컴포넌트에서만 사용할 수 있습니다.
네 번째, 점진적 전환이 가능합니다.
/app 와 /pages 디렉토리를 동시에 유지할 수 있어, 라우트 단위로 점진적 이전이 가능합니다.
App 라우터를 추천하는 경우는
첫 번째는, 새로운 프로젝트를 시작하는 경우로 최신 기능과 서버 컴포넌트 기반의 더 유연한 구조로 작업이 가능합니다.
두 번째는, 서버 데이터 중심이고, SEO 최적화가 중요한 경우로 App 라우터의 서버 중심 렌더링과 스트리밍 덕분에 성능과 SEO 모두 개선이 가능합니다.
세 번쨰는, 장기적으로 유지보수할 신규 서비스의 경우로 미래 지향적 구조이며 NextJS 의 주력 방향이기 때문입니다.
반면, Page 라우터가 더 적합한 경우는
첫 번째는, 기존 NextJS 12 이하 버전의 프로젝트를 유지보수하는 경우로 안정적이고 기존 코드를 그대로 유지할 수 있기 때문입니다.
두 번째는, SSR 보다 CSR 이 중심인 SPA 형태의 프로젝트인 경우로 클라이언트 렌더링이 많다면 App Router 의 장점이 크지 않기 때문입니다.
마지막으로, App Router 는 단순히 라우팅 디렉토리 위치가 바뀐 게 아니라,
NextJS 의 핵심 구조와 개발 철학을 완전히 재정의한 기능입니다.
Page Router 는 '클라이언트 중심, 페이지 단위 설계'
App Router 는 '서버 중심, UI 트리 단위 설계'
따라서, 프로젝트 요구사항과 팀 역량에 맞춰 신중하게 선택하는 것이 중요합니다.