[개념부터 NextJs] 페이지 라우터와 앱라우터 차이

     

목차

 

 

 

페이지 라우터, 앱 라우터 차이를 물어보면 항상 답변이 파일 구조밖에 떠오르지 않아 사용해 보지는 않지만 중요한 변천사이기 때문에 한번 더 조사를 해보았다.

 

파일 구조

Page Router

페이지 별로 파일이 분리된다. 또한 파일 네이밍이 곧 경로가 되기 때문에, 주의해야 할 점이다. 페이지가 되는 모든 파일은 pages/ 폴더 안에 분리되며, 해당 폴더 안의 모든 파일이 페이지가 된다. 즉, 컴포넌트로 사용할 파일, 유틸 파일 등은 pages/ 폴더 밖으로 분리해야 한다는 소리이다.

pages/about.js 혹은 pages/about/index.js 로 사용할 수 있다. 해당 파일의 경로는 /about 이 된다.

 

App Router

페이지 구조가 폴더로 정리된다. 폴더의 네이밍이 경로가 되며, Page Router와 비슷한 양상을 띈다. 폴더 내부에는 page.js 파일이 필수로 들어가야 하며, 해당 파일이 없으면 페이지를 찾을 수 없다. 또한. index.js는 특별한 의미를 가지지 않는다.

 

중첩 레이아웃(layout.js)

App Router

• layout.js
• nested layout
• shared fetching
• parallel routes
• intercepting routes

Pages Router에는 이런 기능 자체가 없다.

 

랜더링

결국 nextjs에서 현 공식 문서가 설명하는 ssr과 csr의 작동 원리가

앱라우터와 페이지 라우터의 차이를 말하고 있다.

페이지 라우터

 

• 서버에서 getServerSideProps 실행
• 모든 데이터 준비
• 모든 HTML 렌더링
• 렌더링이 끝나야 완성된 HTML을 한 번에 클라이언트로 전송

 

앱 라우터

• 라우트 구조 분석: layout → template → page 순서로 어떤 컴포넌트가 필요한지 확인함.
• 서버에서 서버 컴포넌트 렌더링 시작: 필요한 데이터 fetch도 여기서 실행됨.
• HTML Shell 먼저 스트리밍: 레이아웃과 Suspense fallback 같은 빠른 UI를 즉시 클라이언트로 보냄.
• 느린 데이터는 RSC Payload 청크로 나중에 스트리밍: 서버 fetch가 끝날 때마다 조각(chunk)으로 클라이언트에 전송.
• 클라이언트가 받은 RSC Payload로 UI를 점진적으로 완성 fallback을 실제 UI로 교체하며 화면이 점점 완성됨.
• 클라이언트 컴포넌트만 hydration useState/useEffect 등 이벤트가 필요한 컴포넌트만 JS와 연결함.

 

경로 세그먼트

Next는 URL 경로를 기준으로 페이지를 구성하는데, 각 페이지는 세그먼트로 나뉜다. 이들은 각각 독립적인 페이지로 렌더링 될 수 있으며, /products/[id] 와 같은 동적 경로에서 [id] 는 하나의 세그먼트로 간주된다.

 

서스펜스 바운더리

React의 서스펜스(Suspense) 기능을 사용하여 데이터 로딩 상태를 관리한다. 특정 컴포넌트가 데이터를 비동기적으로 로딩하는 동안 UI 일부를 대기 상태로 유지할 수 있게 하는데, 이 바운더리 내의 컴포넌트는 데이터가 준비될 때까지 로딩 상태를 표시할 수 있다.

 

청크

렌더링 작업이 청크로 나뉘는 것은 최적화에 관련이 있다. 각 경로의 세그먼트와 서스펜스 바운더리에 따라 렌더링 작업이 청크로 분리되어 작업이 진행되면 필요한 부분만 렌더링할 수 있어 효율적으로 로드할 수 있다.

 

 

 

참고하면 좋을 것 같은 토론

https://www.reddit.com/r/nextjs/comments/1gdxcg5/why_do_you_still_prefer_page_router_over_app/?tl=ko

Reddit의 nextjs 커뮤니티