Next.js 15 App Router, 이것만 잡으면 된다

App Router의 핵심 관점

Next.js 15의 App Router는 단순한 폴더 기반 라우팅이 아니라 서버 중심으로 화면을 조립하는 방식이다. app/ 디렉터리 안의 폴더가 URL 세그먼트가 되고, page.tsx가 실제 화면, layout.tsx가 공통 UI를 담당한다. 기존 Pages Router처럼 페이지 단위로만 생각하기보다, 레이아웃·로딩·에러·데이터 흐름을 세그먼트별로 나누는 감각이 중요하다.

서버 컴포넌트가 기본값

App Router에서는 컴포넌트가 기본적으로 Server Component다. 덕분에 DB 조회, 내부 API 호출, 비밀 키 사용 같은 작업을 서버에서 바로 처리할 수 있다. 브라우저 상호작용이 필요한 경우에만 파일 상단에 "use client"를 붙인다.

• 서버: 데이터 조회, 렌더링, 보안 로직
• 클라이언트: 클릭, 입력, 상태, 브라우저 API
• 경계: Client Component는 꼭 필요한 곳에만 작게 둔다

캐싱은 더 명시적으로

Next.js 15에서 특히 주의할 부분은 캐싱이다. fetch 요청과 라우트 캐싱을 예전처럼 막연히 기대하면 안 된다. 데이터가 항상 최신이어야 하면 cache: "no-store", 일정 주기로 갱신하면 next: { revalidate: 초 }, 태그 기반 무효화가 필요하면 revalidateTag를 고려한다.

파일 규칙으로 UX를 나눈다

App Router의 장점은 상태별 UI를 파일로 분리할 수 있다는 점이다.

• loading.tsx: 스트리밍 중 보여줄 로딩 화면
• error.tsx: 세그먼트 단위 에러 처리
• not-found.tsx: 404 전용 UI
• route.ts: API 엔드포인트 작성
• layout.tsx: 중첩 레이아웃 구성

실무 적용 팁

Next.js 15 App Router를 잘 쓰려면 “페이지를 만든다”보다 “서버에서 데이터를 가져오고, 세그먼트별 UI를 조립한다”는 흐름으로 접근해야 한다. 서버 컴포넌트를 기본으로 두고, 클라이언트 컴포넌트는 인터랙션이 필요한 섬처럼 배치하자. 캐싱 정책은 기능 요구사항에 맞춰 명시하고, 로딩·에러·404 파일을 초기에 잡아두면 유지보수가 훨씬 쉬워진다.

참고: Next.js 15 공식 발표, App Router 캐싱 가이드