1. Page Router의 장점
1.1 직관적인 파일 기반 라우팅
폴더와 파일을 생성하는 것만으로 라우트를 설정할 수 있어 설정이 간편하고 구조가 직관적이다.
1.2 다양한 방식의 사전 렌더링 제공
Page Router는 다양한 렌더링 방식을 지원한다.
- SSR (Server-Side Rendering):
getServerSideProps()를 사용 - SSG (Static Site Generation):
getStaticProps()와getStaticPaths()를 사용 - ISR (Incremental Static Regeneration):
revalidate옵션을 통해 정적 페이지를 주기적으로 갱신 가능
1.3 Next.js의 오랜 기본 방식
Next.js의 기존 프로젝트 대부분이 Page Router를 사용하고 있으며, 커뮤니티 자료가 풍부하다. 따라서 학습 자료나 해결 방법을 찾기 쉽다.
2. Page Router의 단점
2.1 레이아웃 관리의 어려움
페이지별로 설정할 레이아웃이 많아지게 되면 코드의 중복도 발생하고 복잡해진다.
반면, App Router는 layout.tsx를 활용해 페이지별 레이아웃을 더 쉽게 관리할 수 있다.
2.2 데이터 패칭이 페이지 컴포넌트에 집중된다.
getServerSideProps() 또는 getStaticProps()를 사용하면 데이터 로직이 페이지 컴포넌트 내에서 처리되어야 하기 때문에, 컴포넌트 간 재사용성이 떨어지고, 상태 관리가 어려워질 수 있다.
redux, recoil등 상태 관리 라이브러리를 사용하면 어느정도 해결할 수 있지만 추가적인 관리가 필요한 구조 자체가 불편하다.
2.3 불필요한 컴포넌트들도 JS Bundle에 포함된다.
일반적으로 사용자와 상호작용이 없는 컴포넌트는 서버에서 한 번만 실행되고, 클라이언트 측 하이드레이션 과정에서는 다시 실행될 필요가 없다.
그러나 Page Router에서는 이러한 구분 없이 현재 페이지에서 사용되는 모든 컴포넌트를 클라이언트 JS 번들에 포함하여 브라우저로 전달한다.
이로 인해 다음과 같은 문제가 발생할 수 있다.
- 불필요한 코드가 클라이언트에서 다운로드되면서 JS 번들 크기가 증가
- 번들 크기가 커질수록 하이드레이션 시간 증가로 TTI(Time to Interactive) 지연
- 성능 최적화가 어려워지고, 사용자 경험이 저하될 가능성
반면, App Router에서는 상호작용이 없는 컴포넌트를 서버 컴포넌트(Server Components)로 분리하여, 클라이언트 JS 번들에 포함되지 않도록 최적화할 수 있다.
이를 통해 불필요한 코드 로딩을 방지하고, 클라이언트 측 성능을 더욱 향상시킬 수 있다.
2.4 동적 경로의 제약
getStaticPaths()를 사용해야 하는 경우 동적 경로를 미리 정의해야 한다.- 많은 경로가 필요한 경우 빌드 시간이 길어질 수 있다.
3. 결론
Page Router는 Next.js의 오랜 기본 라우팅 방식으로 직관적인 파일 기반 라우팅, SSR/SSG/ISR 지원, API Routes 제공 등의 장점을 갖고 있다. 하지만 서버 컴포넌트 미지원, 레이아웃 관리의 어려움, 데이터 관리의 복잡성, 불필요한 JS 번들 포함 등의 단점도 존재한다.
최근 Next.js 13부터 App Router가 도입되면서, 서버 컴포넌트와 새로운 라우팅 방식을 활용할 수 있는 옵션이 생겼다. 그러나 여전히 Page Router는 강력한 기능을 제공하며, 기존 프로젝트에서는 안정적인 선택지가 될 수 있다.
따라서 프로젝트의 요구사항에 따라 Page Router와 App Router 중 적절한 방식을 선택하는 것이 중요하다.
