App Router vs Pages Router 구조¶
Next.js는 파일 시스템 기반 라우팅을 사용하며,
Pages Router와 App Router는 단순한 디렉터리 차이가 아니라
렌더링·캐시·데이터 패칭 방식까지 포함한 운영 모델 차이를 가진다.
어떤 라우터를 사용하는지에 따라
성능 특성, 장애 영향 범위, 운영 난이도가 달라진다.
1. Pages Router¶
pages/디렉터리 기준 라우팅- 기존 Next.js의 표준 구조
- 주요 특징:
- CSR / SSR 중심
getServerSideProps,getStaticProps기반 데이터 패칭- 비교적 단순한 캐시 모델
운영 특성¶
- 렌더링 흐름이 명확함
- 장애 발생 시 영향 범위 예측이 쉬움
- 기존 Node.js/Express 운영 감각과 비교적 유사
2. App Router¶
app/디렉터리 기준 라우팅- 최신 Next.js 기본 권장 구조
- 주요 특징:
- React Server Components 기본
- Server Actions, streaming, nested layout
- 컴포넌트 단위 데이터 패칭과 캐시
운영 특성¶
- 프레임워크 내부 캐시 개입이 많음
- 렌더링·데이터 흐름이 암묵적으로 결정됨
- 잘못된 캐시 설정 시:
- 데이터 최신성 문제
- 장애 범위 확산
가능성 존재
3. 운영 리스크 비교¶
| 항목 | Pages Router | App Router |
|---|---|---|
| 운영 난이도 | 낮음 | 높음 |
| 캐시 제어 | 명시적 | 프레임워크 주도 |
| 장애 분석 | 비교적 단순 | 복잡 |
| 점진적 변경 | 용이 | 주의 필요 |
4. 운영 기준 (Baseline)¶
- 프로젝트에서 사용하는 라우터를 명확히 문서화한다
- App Router 사용 시:
- 캐시 전략(
fetch,revalidate)을 명시적으로 관리한다 - 실시간 데이터 요구 사항을 재검토한다
- 캐시 전략(
- Pages Router → App Router 전환은
- 구조 변경이 아닌 운영 모델 변경으로 간주한다
5. 운영 체크리스트¶
-
pages//app/사용 여부 확인 - 라우터별 렌더링 방식(SSR/SSG/RSC) 파악
- 캐시 정책 문서화 여부 점검
- 장애 발생 시 영향 범위 정의