Pages Router vs App Router — 기능 비교가 아닌 설계 철학과 사고 방식
Pages Router와 App Router의 설계 철학, 라우팅·레이아웃·데이터 처리 차이를 비교
게시 
By okorion
6 분읽는 시간 
Pages Router vs App Router — 기능 비교가 아닌 설계 철학과 사고 방식
기능 비교가 아닌, 설계 철학과 사고 방식의 차이
NextJS를 어느 정도 사용해 본 개발자라면 깨닫는다.
Pages Router와 App Router의 차이는 API 차이가 아니라 “애플리케이션을 바라보는 관점”의 차이다.
이 글은
- 어떤 라우터가 더 “새롭다”를 말하지 않고
- 어떤 라우터가 어떤 문제를 전제로 설계되었는지를 중심으로 설명한다.
1. Pages Router의 설계 철학: “페이지 중심 + 서버 보조”
Pages Router의 출발점은 명확하다.
React SPA를 서버 친화적으로 보완하자.
핵심 전제
- 페이지가 애플리케이션의 최소 단위
- 클라이언트 렌더링이 기본
- 서버는 데이터 공급자 + HTML 생성자
그 결과
pages/= URLgetStaticProps,getServerSideProps로 서버 개입- React 컴포넌트 = 기본적으로 클라이언트 컴포넌트
👉 Pages Router는 “SPA에 SSR을 얹은 구조”다.
2. App Router의 등장 배경: “렌더링을 서버에서 시작하자”
App Router는 단순한 리팩터링이 아니다.
문제 인식 자체가 다르다.
기존 문제
- 클라이언트 JS 과다
- 데이터 페칭 시점 제어 어려움
- 레이아웃 중복
- SEO/성능 최적화가 옵션 취급
App Router의 전제
서버에서 렌더링을 시작하고,
클라이언트는 필요한 만큼만 사용한다.
이 전제에서 모든 설계가 출발한다.
3. 라우팅·레이아웃·데이터 처리 방식 비교
핵심 차이 요약 표
| 구분 | Pages Router | App Router |
|---|---|---|
| 기본 렌더링 | 클라이언트 | 서버 |
| 라우트 단위 | 페이지 | 세그먼트 |
| 레이아웃 | _app.js 기반 | 중첩 레이아웃 |
| 데이터 페칭 | 페이지 전용 함수 | 컴포넌트 단위 |
| 서버 코드 위치 | 분리됨 | 컴포넌트와 공존 |
| 사고 중심 | SPA 확장 | 서버 중심 UI |
3-1. 라우팅 사고 방식의 차이
Pages Router
- URL → 페이지 컴포넌트
- 페이지 단위 사고
- 중첩 구조 표현 어려움
App Router
- URL → UI 트리
- 세그먼트 단위 사고
- 라우팅 = 레이아웃 구성
👉 App Router에서는 라우팅이 UI 설계의 일부다.
3-2. 레이아웃 처리의 차이 (가장 큰 체감 포인트)
Pages Router
- 전역 레이아웃 위주
- 조건부 레이아웃 처리 복잡
- 페이지 간 레이아웃 공유 어려움
App Router
- 디렉터리 기반 중첩 레이아웃
- URL 구조 = 레이아웃 구조
- 레이아웃 재사용이 자연스러움
👉 “레이아웃이 먼저고, 페이지는 그 안의 일부”라는 사고 전환이 필요하다.
3-3. 데이터 페칭과 서버 컴포넌트
이 지점이 가장 많은 혼란을 만든다.
Pages Router
- 데이터는 페이지에서만 가져온다
- 컴포넌트는 UI 역할에 집중
App Router
- 서버 컴포넌트에서 직접 데이터 접근
- 데이터 페칭 = 렌더링의 일부
- 클라이언트 상태 최소화
👉 App Router는 “데이터 → UI” 흐름을 서버에서 완성한다.
4. 실무 선택 기준: 어떤 프로젝트에 어떤 라우터를 써야 하는가
Pages Router가 더 나은 경우
- 기존 Pages Router 기반 대형 서비스
- App Router 전환 비용이 큰 조직
- SPA 중심 사고가 명확한 팀
- 서버 컴포넌트 개념 도입이 부담스러운 경우
👉 안정성과 예측 가능성 우선
App Router가 적합한 경우
- 신규 프로젝트
- SEO, 초기 로딩이 중요한 서비스
- 서버 주도 렌더링이 필요한 구조
- 풀스택 NextJS를 적극 활용할 계획
👉 성능·확장성·장기 유지보수 우선
결론 요약
- Pages Router는 React SPA의 확장
- App Router는 서버 중심 UI 프레임워크
- 선택 기준은 “신규 vs 기존”이 아니라
“클라이언트 중심 vs 서버 중심 사고”
App Router는 단순히 새로운 API가 아니다.
NextJS가 무엇을 책임지는 프레임워크인가에 대한 선언이다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.