App Router vs Pages Router

App Router와 Pages Router의 파일 구조·데이터 페칭·컴포넌트 경계·전환 비용을 비교해 선택 기준을 세웁니다.

Next.js를 처음 배우면 기능보다 먼저 구조 선택에서 막히는 경우가 많습니다.

Pages Router로 시작해도 되나?, App Router를 바로 쓰는 게 맞나? 같은 질문은 입문자뿐 아니라 기존 프로젝트를 운영하는 팀에서도 자주 나옵니다.

겉보기에는 폴더 구조 차이처럼 보이지만, 실제로는 데이터 페칭 방식과 컴포넌트 경계, 성능 전략까지 바뀌는 선택입니다.

이 절에서는 두 라우터를 단순 비교표로 끝내지 않고, 어떤 프로젝트에서 어떤 선택이 더 유리한지 판단 기준까지 함께 정리합니다.

읽고 나면 새 프로젝트 시작과 기존 프로젝트 유지보수에서 각각 어떤 결정을 내리는 것이 합리적인지 감을 잡을 수 있습니다.

Pages Router: 익숙함 속의 효율성

Next.js의 초기부터 함께 해온 Pages Router는 파일 시스템 기반 라우팅을 사용합니다.

pages 디렉터리 안에 React 컴포넌트를 정의하면, 해당 파일의 경로가 웹 애플리케이션의 URL 경로로 자동으로 매핑됩니다.

예를 들어, pages/about.js 파일은 /about 경로에 접근했을 때 렌더링됩니다.

Pages Router의 주요 특징

파일 시스템 기반 라우팅: 직관적이고 설정이 간단하여 빠르게 페이지를 만들 수 있습니다.
쉬운 학습 곡선: React 개발자에게 익숙한 방식으로, 새로운 개념을 많이 익히지 않아도 됩니다.
데이터 페칭 방식: getServerSideProps, getStaticProps, getStaticPaths와 같은 함수를 사용하여 서버 사이드 렌더링(SSR)이나 정적 사이트 생성(SSG)을 구현합니다.

기존 Pages Router 코드와 운영 경험을 활용할 수 있다면, 유지보수나 빠른 프로토타이핑에서 전환 비용을 줄일 수 있습니다. 프로젝트가 작다는 이유만으로 Pages Router가 더 적합한 것은 아닙니다.

다만 중첩 레이아웃, 서버 컴포넌트, 스트리밍을 중심으로 설계하려는 프로젝트에서는 App Router가 더 자연스러운 선택이 됩니다.

App Router: 최신 기본 구조

Next.js 13부터 도입된 App Router는 React의 최신 기능인 React Server Components(RSC)와 스트리밍(Streaming)을 기반으로 설계되었습니다.

App Router는 app 디렉터리 안에서 라우팅과 컴포넌트 구조를 정의하며, Pages Router와는 근본적으로 다른 접근 방식을 취합니다.

App Router의 주요 특징

React Server Components(RSC): 서버에서 처리할 UI와 클라이언트에 보내야 할 UI를 나누어 클라이언트 번들 크기를 줄일 수 있습니다.
스트리밍: 페이지의 일부를 먼저 전송하고 나머지 콘텐츠를 이어서 보내는 방식으로 초기 응답 경험을 개선할 수 있습니다.
레이아웃(Layouts): 여러 페이지에서 공유되는 UI를 쉽게 정의하고 중첩할 수 있어 코드 재사용성과 유지보수성이 뛰어납니다.
데이터 페칭: fetch API를 확장하여 데이터 페칭과 캐싱 전략을 세밀하게 제어할 수 있습니다.
SEO 및 성능 설계: HTML 출력, 메타데이터, 캐싱, 동적 렌더링 범위를 명확히 관리하면 검색 노출과 성능을 함께 개선할 수 있습니다.

App Router는 Pages Router에 비해 초기 학습 곡선이 다소 높을 수 있지만, 복잡한 애플리케이션에서 레이아웃, 서버/클라이언트 경계, 데이터 페칭 정책을 함께 설계할 때 강점이 큽니다.

Pages Router도 계속 지원되지만, 새 프로젝트라면 App Router를 기본 선택지로 두는 편이 공식 문서의 방향과도 잘 맞습니다.

두 라우터의 책임 위치를 비교하면 다음과 같습니다.

URL·레이아웃: Pages는 pages/about.js가 /about을 만듭니다. App은 app/about/page.js가 페이지를 노출하고 layout.js로 중첩된 공통 UI를 정의합니다.
서버 데이터: Pages는 페이지의 getServerSideProps·getStaticProps 등에서 데이터를 준비합니다. App은 Server Component에서 데이터 요청과 캐시 정책을 정할 수 있습니다.
실행 경계: App의 페이지·레이아웃은 기본 Server Component입니다. 상태·이벤트·브라우저 API가 필요한 곳에 Client Component 경계를 둡니다. Pages도 서버에서 HTML을 렌더링할 수 있으므로 전부 브라우저 전용이라는 뜻은 아닙니다.
초기 응답·메타데이터: App은 Suspense·로딩 UI와 Metadata API를 라우트 구조에 연결합니다. 어느 라우터든 실제 성능과 검색 노출은 출력·데이터·배포 조건을 함께 확인해야 합니다.

Client Component도 첫 진입에는 서버에서 HTML을 미리 만들 수 있습니다. use client는 브라우저에서만 렌더링한다는 선언이 아니라 클라이언트 모듈 경계를 정합니다. 자세한 실행 과정은 공식 Server/Client Components 문서를 기준으로 뒤에서 다룹니다.

NEXT · CH1-2

같은 URL도 책임을 두는 파일이 다릅니다

두 열은 서로 다른 라우터의 선택지입니다. Pages도 서버 HTML을 만들 수 있고, App의 Client Component도 첫 진입에 서버 HTML을 준비할 수 있습니다.

Pages Router

URL /about: pages/about.js
공통 UI: pages/_app.js와 페이지별 구성으로 관리합니다.
서버 데이터: 페이지의 getServerSideProps·getStaticProps 등에서 준비합니다.
실행 경계: 서버 HTML 렌더링과 브라우저 상호작용을 지원합니다. App의 Server Component 모델과 구분합니다.

App Router

URL /about: app/about/page.js
공통 UI: layout.js를 중첩하고 children에 페이지를 넣습니다.
서버 데이터: Server Component에서 데이터 요청과 캐시 정책을 정합니다.
실행 경계: 페이지·레이아웃은 기본 Server Component입니다. 상태·이벤트에 Client 경계를 둡니다.

점진 전환할 때

두 디렉터리는 공존할 수 있지만 같은 URL을 양쪽에서 정의할 수는 없습니다. 전환할 라우트의 URL·사용자 흐름·초기 화면·배포 절차를 확인합니다.

새 프로젝트의 App Router 선택과 기존 Pages 서비스의 전환 비용은 별도로 판단합니다. 어느 쪽도 성능·검색 순위를 자동 보장하지 않습니다.

어떤 라우터를 선택해야 할까요?

이 책에서는 App Router를 중심으로 Next.js 16의 주요 기능을 다룰 예정입니다.

App Router는 서버 컴포넌트, 스트리밍, 중첩 레이아웃, 캐싱 전략을 한 흐름에서 설계할 수 있게 해 줍니다.

기존 Pages Router 마이그레이션도 다루지만, 새 프로젝트 기준은 App Router를 중심으로 설명합니다.

다만 모든 프로젝트가 즉시 App Router로 전환해야 하는 것은 아닙니다.

이미 안정적으로 운영 중인 서비스라면, 라우트 단위로 점진 전환하면서 테스트/배포 리스크를 관리하는 편이 현실적입니다.

즉 무조건 최신을 선택하기보다 현재 서비스 안정성과 전환 비용을 함께 계산하는 것이 좋은 선택입니다.

선택 전 점검 체크리스트

아래 항목을 먼저 정리하면 라우터 선택 실수를 줄일 수 있습니다.

신규 프로젝트인가, 기존 서비스 점진 전환인가
서버 컴포넌트와 스트리밍을 당장 활용할 계획이 있는가
팀이 getServerSideProps/getStaticProps 중심 코드를 얼마나 보유하고 있는가
배포 일정상 마이그레이션 리스크를 감당할 수 있는가

다음 절 연결 포인트

다음 절에서는 학습 범위와 전제 지식을 정리합니다. 이후 프로젝트 구조 실습에 앞서 아래 기준을 미리 정해두면 좋습니다.

새 프로젝트는 App Router 기본 구조로 시작하고, 기존 서비스는 라우트 단위 전환 범위를 먼저 정의합니다.
팀 규칙 문서에 "서버 컴포넌트 우선, 클라이언트 컴포넌트 최소화" 원칙을 명시합니다.
전환 전후의 빌드 시간, 번들 크기, 초기 로딩 지표를 같은 조건에서 비교합니다.

Pages Router와 App Router는 점진 전환을 위해 함께 둘 수 있지만, 같은 URL을 양쪽에서 정의할 수는 없습니다. 전환할 라우트마다 기존 URL·사용자 흐름의 회귀, 초기 JavaScript와 첫 화면 성능, 배포 절차·팀 규칙의 변경 비용을 확인합니다. 공존과 전환 제약은 공식 App Router 마이그레이션 안내를 따릅니다.

예시

기존 pages/about.js가 /about을 제공하는 서비스에 새 app/about/page.js를 추가했다고 해 보겠습니다. 폴더 이름이 다르더라도 두 파일이 만들려는 URL은 같습니다. 공존을 이용한 점진 전환은 같은 URL의 두 구현을 동시에 활성화하는 뜻이 아닙니다. /about을 전환할 때는 App 쪽 구현을 준비하고 그 URL을 소유하던 Pages 파일을 제거하거나 라우트 밖으로 옮긴 뒤 기존 요청·화면을 다시 확인합니다. 공통 컴포넌트는 해당 라우터 규칙을 검토해 재사용할 수 있습니다.

파일 경로로 확인하기

프로젝트에는 pages/about.js와 pages/contact.js가 있습니다. 다른 라우트를 유지하면서 /about만 App Router로 옮기려면 어느 기존 페이지의 URL 소유를 바꿔야 할까요? 새 기능을 app/products/page.js에 추가하는 경우도 같은 충돌일까요?

각 파일이 노출하는 URL로 풀이하기

app/about/page.js를 활성화하려면 기존 /about을 정의한 pages/about.js와의 중복을 없애야 합니다. pages/contact.js는 /contact이므로 이 URL 전환 때문에 모두 지울 필요는 없습니다. app/products/page.js는 /products를 정의합니다. 그 URL의 다른 구현이 없다는 조건이라면 앞의 두 Pages 경로와 충돌하지 않습니다. 이후에는 옮긴 /about의 데이터 준비·레이아웃·라우팅 훅을 App 규칙으로 확인하며, 파일 이동만으로 모든 Pages API가 호환된다고 판단하지 않습니다.