Prologue

Next.js 세계관에 대격변이 일어난 지도 벌써 꽤 시간이 흘렀습니다..

하지만 여전히 우리를 괴롭히는 질문이 있죠.

"구관이 명관인 Pages Router인가, 신문물의 결정체 App Router인가?"

결정 장애가 온 당신을 위해, 지루한 기술 명세는 걷어내고 핵심만 툭 던져봅니다.

주소창의 철학: pages vs app

가장 먼저 체감되는 건 폴더 구조입니다.

• Pages Router: 파일 이름이 곧 URL입니다. about.tsx를 만들면 바로 /about이 됩니다. 단순하고 직관적이죠. 마치 이름표가 붙은 사물함 같습니다.
• App Router: 폴더가 URL이 되고, 그 안에 무조건 page.tsx가 있어야 합니다. /about/page.tsx 구조죠. 처음엔 "왜 이렇게 복잡해?" 싶지만, 레이아웃(layout.tsx)이나 로딩 UI(loading.tsx)를 폴더별로 격리하기엔 이만한 게 없습니다.

서버 컴포넌트: "누가 일을 할 것인가"

이게 바로 App Router의 진짜 존재 이유입니다.

• Pages Router: 기본적으로 클라이언트 중심적입니다. getServerSideProps 같은 함수를 써서 데이터를 가져오지만, 결국 브라우저가 할 일이 많습니다.
• App Router: React Server Components(RSC)가 주인공입니다. 데이터 연산을 서버에서 끝내고 결과물만 브라우저에 던집니다. 브라우저는 가벼워지고, 사용자는 쾌적해집니다. "서버가 빡세게 구를 테니, 클라이언트는 쉬어라"는 마인드죠.

데이터 패칭: 안녕, getStaticProps

Pages Router에서 우리를 괴롭히던 복잡한 데이터 패칭 함수들이 App Router에서는 사라졌습니다. 이제는 그냥 평범한 fetch() 하나면 끝납니다.

캐싱을 할지, 실시간으로 가져올지 옵션만 살짝 건드리면 됩니다. 문법이 단순해지니 코드가 훨씬 깔끔해지는 마법을 경험할 수 있습니다.

요약 비교

특징	Pages Router	App Router
난이도	낮음 (익숙함)	높음 (러닝 커브 있음)
성능	보통	매우 뛰어남 (RSC)
트렌드	유지보수 모드	Next.js의 미래

생략을 생략

Epilogue

결론은 간단합니다. 이미 돌아가고 있는 거대한 서비스라면 굳이 위험을 무릅쓰고 옮길 필요는 없습니다. 하지만 오늘 밤, 새로운 프로젝트를 시작한다면? 묻지도 따지지도 말고 App Router로 가세요. 처음엔 조금 매울 수 있지만, 적응하고 나면 Pages Router 시절로 돌아가기 싫어질 겁니다.

이 가이드가 당신의 선택에 작은 확신이 되었기를 바랍니다.