Next.js App Router(1) - Next.js의 새로운 패러다임 이해하기

Next.js가 App Router를 도입 한 13 버전 이후 벌써 15 버전이 되었습니다.

기존에 Page Router를 사용하던 곳들도 이제는 App Router 도입을 고민하고 또 도입하고 있습니다.

이번 글에서는 Next.js App Router가 등장한 배경, 철학, 그리고 Pages Router와의 차이점에 대해 알아보겠습니다.

1. Next.js App Router의 등장 배경

Next.js는 React를 기반으로 한 프레임워크로서 항상 React의 변화를 빠르게 도입하는 프레임워크입니다.
React 18에서 도입된 Concurrent Rendering과 React Server Components(RSC) 지원은 기존 SPA 한계를 극복하기 위한 도전이었습니다.
Next.js도 SPA의 한계를 깨고 더 쉽고 강력한 서버-클라이언트 협업, 데이터 패칭, 성능 최적화를 위해 App Router를 탄생시켰습니다.

 

Next.js의 기존 Pages Router는 단순히 페이지 단위로 라우팅을 하는 구조로, pages/ 디렉터리 아래 파일이 곧 라우트가 되는 방식이었습니다.

이것만으로도 출시 초기에는 무척 혁신적이었지만 서비스가 커질수록 상태관리, 데이터 패칭, 레이아웃 재사용 등을 관리하기 불편해졌습니다.

그래서 App Router는 언뜻 Page Router에 비해 더 복잡해 보이지만 많은 고민이 보이는 새로운 App 기반의 라우팅 주고를 만들었습니다.

2. Pages Router와 비교: 뭐가 달라졌나?

1) 폴더 구조의 변화

App Router는 각 라우트마다 page, layout, error 등의 파일을 명시적으로 두도록 변경되었습니다.

• http://localhost:3000
  • (Page Router) /pages/index.tsx
  • (App Router) /app/page.tsx
• http://localhost:3000/about
  • (Page Router) /pages/about.tsx
  • (App Router) /app/about/page.tsx

2) 레이아웃 재사용과 중첩

• Page Router는 _app, _document에서 공통 Layout을 제공했지만, 다양한 Layout을 대응하기 불편한 점이 많았습니다.
• App Router는 layout 파일을 도입해 폴더 단위로 중첩된 Lyaout을 구성할 수 있도록 변경하였습니다.

3) 데이터 패칭과 렌더링 방식

• Pages Router에서는 SSR과 CSR이 함께 존재하는 구조였기 때문에 SSR을 원한다면 꼭 page에서 getServersideProps로 데이터를 패칭하고 이후 다른 컴포넌트에서 사용하고 싶다면 hydrate해주는 등의 복잡한 처리가 필요했습니다.
• App Router에서는 Server Component와 Client Component를 명확하게 구분되어, 데이터 패칭과 렌더링이 훨씬 선언적이고, 최적화가 쉬워졌습니다.

3. React Server Components 도입 배경

App Router의 핵심은 React Server Components(RSC)입니다.

Server Component는 Node.js 환경에서 렌더링 되어 브라우저로 전달. DB 쿼리, 파일 접근 등 서버 전용 작업을 안전하게 처리.

Client Component는 브라우저에서만 동작하며, 상호 작용, 상태 관리, 이벤트 핸들링 작업을 처리.

이런 식으로 명확히 분리되어, 하이브리드 구조가 가능하도록 변경되었으며 아래와 같은 장점을 얻게 되었습니다.

• 보안(비밀키/DB 쿼리 등 노출 X)
• 성능(불필요한 JS 전송 최소화, 초기 로드 성능 개선)
• 코드 구조의 명확한 분리(컴포넌트 역할별 구분)

4. 파일 구조가 곧 라우팅 철학 이해하기

Next.js의 핵심 철학이라면 바로 "파일 구조가 곧 라우팅" 일 것입니다.

App Router는 이런 Next.js의 핵심 철학을 더욱 구체화해, 단순히 page뿐 아니라 layout 등의 다양한 파일들을 정의해 두었습니다.

• page.tsx: 폴더 경로가 곧 URL. 예: /app/products/page.tsx → /products
• layout.tsx: 해당 폴더 내 모든 하위 라우트를 감싸는 레이아웃(UI 래퍼)
• template.tsx: 페이지 전환마다 상태가 초기화되는 래퍼(특별한 경우만 사용)
• loading.tsx / error.tsx: Suspense fallback 및 에러 UI 전용 파일로, 코드 분리와 일관된 관리가 쉬움

app/
  ├── dashboard/
  │     ├── layout.tsx
  │     └── page.tsx
  ├── blog/
  │     ├── [blog_id]/
  │     │     ├── page.tsx
  │     │     └── loading.tsx
  └── layout.tsx

 

마지막으로 App Router에서 강조하는 부분들을 끝으로 글을 마치겠습니다.

• 개발 및 구조화의 단순화 : 더 이상 라우팅/데이터 패칭/에러/로딩 등 별도 API나 파일이 필요 없이, 미리 정의된 파일 사용.
• 중첩 레이아웃과 UI 상태 유지 : layout을 통한 중첩 레이아웃 구조로, 페이지 이동 시에도 Nav와 같은 공통 UI의 상태 유지.
• 코드 분리 및 최적화 : 불필요한 클라이언트 번들 최소화하고 Suspense와 스트리밍 지원을 통한 성능 최적화.
  
  

Next.js App Router는 물론 복잡도도 올라가고, 옛날 FE로 돌아가는 듯한 느낌도 들긴 했던 업데이트였습니다.

하지만 React 최신 아키텍처를 적극 활용하고 성능, DX, 구조화에 신경 쓴 업데이트임은 확실하다고 느끼고 있습니다.