Navigation - App Router

이 글은 App Router(next/navigation) 기준으로 작성되었습니다.
Page Router에서는 useRouter가 next/router에서 제공됩니다.

Next.js App Router에서도 페이지 이동 방식의 기본 개념은 동일하다.

• 선언적인 네비게이션 → Link
• 프로그래매틱 네비게이션 → useRouter

하지만 내부 동작 방식과 리소스 처리 구조는 Page Router와 비교했을 때 중요한 차이를 가진다.

Navigation 기본 개념

App Router 역시 기본적으로 클라이언트 사이드 네비게이션 전략을 사용한다.
이는 전통적인 MPA 방식과 달리:

• 전체 페이지 리로드 없이
• 필요한 UI만 갱신
• 상태 유지 가능

SPA 방식의 이동 모델에 가깝다.
즉, 페이지 이동은 발생하지만 브라우저 관점에서는 화면 전체가 다시 로드되지 않는다.

Navigation 내부 동작

App Router의 페이지 이동은 겉보기에는 SPA처럼 보이지만, 내부적으로는 기존 React 애플리케이션과 다른 메커니즘을 사용한다. 핵심 차이는 Server Component의 존재다.

App Router에서는 렌더링 책임이 분리된다.

• Client Component → JavaScript Bundle
• Server Component → RSC Payload

JavaScript 번들에는 서버 컴포넌트의 실제 데이터가 포함되지 않는다.
대신 서버에서 생성된 RSC Payload가 별도로 전달된다.

페이지 이동이 발생하면 브라우저는:

1. Client Component 실행을 위한 JS 번들
2. Server Component 정보를 담은 RSC Payload

이 두 가지를 함께 전달받는다.
이후 브라우저는 JavaScript를 실행하고, RSC Payload와 조합하여 필요한 UI만 교체한다.

결과적으로:

• 전체 페이지 리로드 없음
• 필요한 컴포넌트만 갱신
• 기존 상태 유지 가능

이라는 App Router 특유의 이동 방식이 완성된다.

Page Router와의 구조적 차이

페이지 이동이라는 개념 자체는 동일하지만, 전달되는 리소스 구조에는 중요한 차이가 있다.
Page Router에서는 모든 UI가 클라이언트 컴포넌트 기반으로 구성되었기 때문에
페이지 이동 시 필요한 정보가 대부분 JavaScript 번들에 포함된다.

반면 App Router에서는:

• 서버 컴포넌트 → RSC Payload
• 클라이언트 컴포넌트 → JS Bundle

이렇게 역할이 분리된다.

이 구조 덕분에:

• 번들 크기 감소
• 클라이언트 JS 실행 비용 감소
• 서버 중심 렌더링 가능

같은 성능상의 이점이 생긴다.

왜 RSC Payload 구조가 성능에 유리할까?

기존 클라이언트 중심 렌더링 모델에서는:

• UI 로직
• 데이터 처리 로직
• 상태 관리 로직

이 모두 브라우저로 전달된다.
문제는 브라우저가 번들을 받은 이후에도 파싱, 컴파일, 실행 과정을 거쳐야 한다는 점이다.

즉, 다운로드 비용뿐만 아니라 CPU 실행 비용이 함께 증가한다.

App Router의 접근 방식

App Router에서는 책임이 분리된다.

• Client Component → JS Bundle
• Server Component → RSC Payload

여기서 가장 중요한 차이는 "Server Component는 브라우저에서 실행되지 않는다"이다.
서버 컴포넌트는 서버에서 이미 처리되고, 브라우저에는 결과 정보만 전달된다.

결과적으로:

• JavaScript 번들 크기 감소
• 브라우저 실행 비용 감소
• 메인 스레드 부담 완화

라는 효과가 발생한다.

RSC Payload 구조는 단순한 데이터 전달 방식이 아니라 “클라이언트에서 실행해야 할 코드 자체를 줄이는 전략”에 가깝다.

App Router의 Prefetching

App Router 역시 페이지 이동 성능 최적화를 위해 Prefetching 전략을 사용한다.
Prefetching은 사용자가 이동할 가능성이 있는 페이지 리소스를 미리 준비하는 것이다.
다만 App Router에서는 페이지 유형에 따라 동작 방식이 달라진다.

Static Page

정적으로 생성 가능한 페이지의 경우:

• RSC Payload
• JavaScript 번들

이 모두 사전에 준비될 수 있다.
즉, 이동 시점의 네트워크 비용이 거의 발생하지 않는다.

Dynamic Page

쿼리 스트링, URL 파라미터, 요청 시점 데이터 의존 등
빌드 타임에 확정할 수 없는 요소가 포함되면 페이지는 동적으로 처리된다.

이 경우 일반적으로:

• RSC Payload → 사전 준비 가능
• JS Bundle → 실제 이동 시 로드

형태로 동작한다.
이 차이는 App Router가 서버 데이터 특성, 렌더링 시점, 캐싱 전략을 고려해 최적화하기 때문이다.

Prefetch가 체감 성능에 미치는 영향

페이지 이동 성능에서 사용자가 실제로 느끼는 요소는:

• 클릭 이후 반응 속도
• 화면 전환 지연
• 깜빡임 여부

같은 UX 요소들이다.

Prefetch가 없는 경우

페이지 이동 시점에:

• RSC Payload 요청
• JavaScript 번들 요청

이 동시에 발생한다.
결과적으로 사용자는 로딩 지연을 경험할 가능성이 높다.

Prefetch가 있는 경우

이미 필요한 리소스가 준비되어 있기 때문에:

• 네트워크 대기 시간 감소
• 즉각적인 화면 전환
• 부드러운 UI 갱신

이 가능해진다.
사용자 입장에서는 거의 로딩 없는 이동처럼 느껴진다.

정리

App Router의 네비게이션은 단순한 페이지 이동 방식이 아니라, 렌더링 모델과 성능 전략이 결합된 구조다.

• RSC Payload → 클라이언트 실행 비용 절감
• JS Bundle 최소화 → 번들 최적화
• Prefetching → 체감 속도 개선

이 세 가지가 함께 작동하면서:

• 빠른 화면 전환
• 부드러운 사용자 경험
• 효율적인 리소스 사용

이라는 결과를 만들어낸다.