App Router를 이해할 때 가장 먼저 봐야 하는 것들

Next.js에서 Page Router를 쓰다가 App Router로 넘어오면 처음에는 폴더 구조가 바뀐 것처럼 보인다.

pages/index.tsx가 app/page.tsx가 되고,
pages/blog/[id].tsx가 app/blog/[id]/page.tsx가 된다.

겉으로 보면 단순한 라우팅 방식의 변화처럼 느껴진다.

하지만 실제로 App Router를 써보면 핵심은 폴더 구조가 아니다.
더 중요한 변화는 렌더링을 바라보는 관점이다.

Page Router에서는 보통 페이지 단위로 생각했다.

이 페이지는 SSR로 할까?
이 페이지는 SSG로 할까?
이 페이지는 클라이언트에서 데이터를 가져올까?

반면 App Router에서는 조금 더 세밀하게 생각하게 된다.

이 컴포넌트는 서버에서 실행돼도 되는가?
이 부분은 정말 브라우저에서 실행되어야 하는가?
이 데이터는 언제 가져오고, 언제 사용자에게 보여줄 것인가?
에러와 로딩 상태는 어디에서 책임져야 하는가?

즉, App Router는 단순히 라우터가 바뀐 것이 아니라,
서버와 클라이언트의 역할을 다시 나누게 만드는 구조에 가깝다.

App Router의 기본은 Server Component다

아무 표시도 하지 않은 컴포넌트는 기본적으로 Server Component다.

Page Router에 익숙하면 React 컴포넌트는 자연스럽게 브라우저에서 실행된다고 생각하기 쉽다.

그래서 컴포넌트 안에서 당연하게 이런 것들을 썼다.

useState()
useEffect()
onClick
window
localStorage

하지만 App Router에서는 기본값이 다르다.

// app/blog/page.tsx

export default async function BlogPage() {
  const posts = await getPosts();

  return (
    <main>
      <h1>블로그</h1>

      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.summary}</p>
        </article>
      ))}
    </main>
  );
}

이 코드는 브라우저에서 실행되는 컴포넌트가 아니다.
서버에서 실행되는 컴포넌트다.

그래서 컴포넌트 안에서 바로 await를 사용할 수 있다.
DB에서 데이터를 가져오거나, 서버 API를 호출하거나, 쿠키를 확인하는 작업도 가능하다.

처음에는 이 방식이 조금 낯설다.
기존 Page Router에서는 데이터를 가져오는 위치가 따로 있었기 때문이다.

export async function getServerSideProps() {
  const posts = await getPosts();

  return {
    props: {
      posts,
    },
  };
}

Page Router에서는 대체로 이런 흐름이었다.

getServerSideProps에서 데이터 조회
→ props로 페이지에 전달
→ 페이지 컴포넌트 렌더링

App Router에서는 이 흐름이 더 직접적으로 바뀐다.

서버 컴포넌트에서 데이터 조회
→ 바로 렌더링

App Router에서는 “데이터가 필요한 서버 컴포넌트가 직접 데이터를 가져온다”는 느낌에 가깝다.

Server Component가 좋은 이유

Server Component의 장점은 명확하다.

예를 들어 블로그 글 목록을 보여주는 페이지를 생각해보자.

블로그 글 제목, 요약, 작성일은 사용자가 클릭해서 바꾸는 데이터가 아니다.
대부분 서버에서 가져와서 화면에 보여주면 끝나는 데이터다.

이런 화면까지 클라이언트 컴포넌트로 만들면 브라우저가 더 많은 일을 해야 한다.

데이터 요청
로딩 상태 관리
상태 업데이트
렌더링
에러 처리

물론 클라이언트에서 처리해야 하는 경우도 있다.
하지만 단순히 “서버에서 가져와서 보여주기만 하는 데이터”라면 서버에서 처리하는 편이 자연스럽다.

Server Component를 사용하면 이런 장점이 있다.

클라이언트로 보내는 JavaScript 양을 줄일 수 있다.
서버 전용 로직을 안전하게 둘 수 있다.
DB 조회나 인증 확인을 컴포넌트 가까이에서 처리할 수 있다.
초기 렌더링에 필요한 데이터를 서버에서 미리 준비할 수 있다.

이렇게 되면 책임의 위치가 명확해진다

데이터를 가져오고, 권한을 확인하고, 화면에 필요한 초기 결과를 만드는 일은 서버가 잘하는 일이다.
반대로 클릭, 입력, 모달, 드롭다운처럼 사용자의 행동에 반응하는 일은 브라우저가 잘하는 일이다.

App Router는 이 둘을 억지로 섞지 말고 나눠서 생각하게 만든다.

`"use client"`를 남발하면 App Router의 장점이 사라진다

App Router를 처음 쓰면 에러를 만났을 때 가장 쉬운 해결책이 있다.

"use client";

파일 맨 위에 이걸 붙이면 많은 에러가 사라진다.
useState도 쓸 수 있고, onClick도 쓸 수 있고, 익숙한 React 방식으로 돌아온다.

하지만 이건 조심해야 한다.

"use client"를 페이지 상단에 붙이는 순간, 그 컴포넌트는 클라이언트 컴포넌트가 된다.
그리고 그 아래에 연결된 많은 코드가 클라이언트 번들에 영향을 줄 수 있다.

즉, 서버에서 처리해도 되는 코드까지 브라우저 쪽으로 끌고 가게 된다.

이건 작은 프로젝트에서는 크게 티가 나지 않을 수 있다.
하지만 서비스가 커질수록 차이가 난다.

초기 로딩 JavaScript 증가
불필요한 클라이언트 렌더링 증가
서버에서 처리할 수 있는 책임이 브라우저로 이동
컴포넌트 경계가 흐려짐

loading.tsx, error.tsx, not-found.tsx

App Router에서 또 하나 인상적인 변화는 상태별 UI를 파일 단위로 나눌 수 있다는 점이다.

Page Router에서는 보통 페이지 내부에서 로딩, 에러, 빈 상태를 직접 처리했다.

if (isLoading) {
  return <div>로딩 중...</div>;
}

if (isError) {
  return <div>에러가 발생했습니다.</div>;
}

if (!data) {
  return <div>데이터가 없습니다.</div>;
}

처음에는 괜찮지만, 페이지가 복잡해질수록 읽기 어려워진다.

로딩이면?
에러면?
데이터가 없으면?
권한이 없으면?
정상 데이터면?

이런 분기들이 페이지 안에 계속 섞이면, 페이지 컴포넌트의 책임이 흐려진다.

App Router는 이 부분을 파일 구조로 분리한다.

app/
  blog/
    page.tsx
    loading.tsx
    error.tsx
    not-found.tsx

각 파일의 책임은 명확하다.

page.tsx → 정상 화면
loading.tsx → 기다리는 화면
error.tsx → 문제가 생긴 화면
not-found.tsx → 없는 리소스를 요청한 화면

이 구조의 장점은 단순히 파일이 깔끔해진다는 것이 아니다.
상태별 UI가 라우트 구조와 연결된다는 점이 중요하다.

loading.tsx: 빈 화면 대신 기다릴 수 있는 화면

서버에서 데이터를 가져오는 페이지는 시간이 걸릴 수 있다.

// app/blog/page.tsx

export default async function BlogPage() {
  const posts = await getPosts();

  return (
    <main>
      <h1>블로그</h1>

      {posts.map((post) => (
        <article key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.summary}</p>
        </article>
      ))}
    </main>
  );
}

getPosts()가 빠르면 사용자는 거의 느끼지 못한다.
하지만 데이터가 많거나 네트워크가 느리거나 서버 응답이 늦으면 화면이 늦게 뜰 수 있다.

이때 loading.tsx를 둘 수 있다.

// app/blog/loading.tsx

export default function Loading() {
  return (
    <main>
      <h1>블로그</h1>
      <p>블로그 글을 불러오는 중입니다...</p>
    </main>
  );
}

사용자가 /blog로 이동했을 때 페이지가 준비되는 동안 이 화면을 먼저 볼 수 있다.

여기서 중요한 건 단순히 “로딩 문구를 보여준다”가 아니다.
사용자에게 화면이 멈춘 것이 아니라 진행 중이라는 신호를 주는 것이다.

웹에서 빈 화면은 사용자에게 불안감을 준다.

페이지가 느린 건가?
에러가 난 건가?
클릭이 안 된 건가?
기다려야 하는 건가?

loading.tsx는 이 애매함을 줄여준다.

loading.tsx는 라우트 단위로 적용된다

App Router의 특수 파일들은 폴더 기준으로 동작한다.

app/
  dashboard/
    page.tsx
    loading.tsx

  blog/
    page.tsx
    loading.tsx

이렇게 하면 /dashboard와 /blog는 각각 다른 로딩 UI를 가질 수 있다.

대시보드는 대시보드에 맞는 로딩 화면을 보여줄 수 있고,

// app/dashboard/loading.tsx

export default function Loading() {
  return <p>대시보드 데이터를 불러오는 중입니다...</p>;
}

블로그는 블로그에 맞는 로딩 화면을 보여줄 수 있다.

// app/blog/loading.tsx

export default function Loading() {
  return <p>블로그 글 목록을 불러오는 중입니다...</p>;
}

error.tsx: 예외 상황을 라우트 단위로 격리한다

error.tsx는 해당 라우트에서 에러가 발생했을 때 보여줄 화면이다.

// app/blog/error.tsx

"use client";

export default function Error() {
  return (
    <main>
      <h2>문제가 발생했습니다.</h2>
      <p>블로그 글을 불러오지 못했습니다.</p>
    </main>
  );
}

error.tsx에는 "use client"가 필요하다.

에러 화면은 단순히 메시지만 보여줄 수도 있지만,
보통은 사용자가 다시 시도할 수 있는 버튼을 제공한다.

// app/blog/error.tsx

"use client";

export default function Error({
  error,
  reset,
}: {
  error: Error;
  reset: () => void;
}) {
  return (
    <main>
      <h2>문제가 발생했습니다.</h2>
      <p>잠시 후 다시 시도해주세요.</p>

      <button onClick={() => reset()}>
        다시 시도
      </button>
    </main>
  );
}

여기서 reset()은 해당 라우트 구간을 다시 렌더링하도록 시도한다.

예를 들어 일시적인 API 실패나 네트워크 문제라면,
사용자가 다시 시도했을 때 정상적으로 페이지가 렌더링될 수 있다.

not-found.tsx

not-found.tsx는 요청한 리소스가 없을 때 보여주는 화면이다.

예를 들어 블로그 상세 페이지가 있다고 해보자.

/blog/1
/blog/2
/blog/3

사용자가 /blog/9999로 접근할 수도 있다.
이 글이 실제로 존재하지 않는다면 어떻게 해야 할까?

이건 서버 에러가 아니다.
DB가 터진 것도 아니고, 코드가 잘못된 것도 아니다.

그냥 요청한 글이 없는 것이다.

이럴 때는 notFound()를 사용한다.

// app/blog/[id]/page.tsx

import { notFound } from "next/navigation";

export default async function BlogDetailPage({
  params,
}: {
  params: { id: string };
}) {
  const post = await getPost(params.id);

  if (!post) {
    notFound();
  }

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

그리고 같은 라우트 구간에 not-found.tsx를 둔다.

// app/blog/[id]/not-found.tsx

import Link from "next/link";

export default function NotFound() {
  return (
    <main>
      <h2>존재하지 않는 블로그 글입니다.</h2>
      <p>삭제되었거나 잘못된 주소일 수 있습니다.</p>

      <Link href="/blog">
        블로그 목록으로 돌아가기
      </Link>
    </main>
  );
}

이렇게 하면 없는 글에 접근했을 때 사용자에게 명확한 안내를 줄 수 있다.

page.tsx는 정상 흐름에 집중할 수 있다

loading.tsx, error.tsx, not-found.tsx를 사용하면 page.tsx의 책임이 줄어든다.

// app/blog/[id]/page.tsx

import { notFound } from "next/navigation";

export default async function BlogDetailPage({
  params,
}: {
  params: { id: string };
}) {
  const post = await getPost(params.id);

  if (!post) {
    notFound();
  }

  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.content}</p>
    </article>
  );
}

이 페이지는 정상 흐름에 집중한다.

1. id로 글을 조회한다.
2. 글이 없으면 notFound()를 호출한다.
3. 글이 있으면 화면을 렌더링한다.

로딩 화면은 loading.tsx가 담당한다.
예상하지 못한 에러는 error.tsx가 담당한다.
없는 글은 not-found.tsx가 담당한다.

이렇게 되면 페이지 코드가 훨씬 읽기 쉬워진다.

App Router의 특수 파일들은 이 책임 분리를 라우팅 구조 안에서 자연스럽게 만들어준다.

내 생각

App router로 변경하는것은 작업시간도 꽤 걸렸고 말들이 많은걸로 알지만

그럼에도 책임소재를 명확히하고 서버에서는 서버의 일을 클라이언트에서는 브라우저가 할수있는 일을 하게하는게 더 명확히 구분된다는 점에서

훨씬 좋다고 생각이 든다.

서버, 클라이언트 뿐 아니라 loading, error 와 같은 파일도 유지보수하는 측면에서는 아주 가독성이 좋아보여서 page router 방식보다는

훨씬 편해진것 같은 느낌이다.

App Router 로 변경하면서