안녕하세요. 실무에서 Next.js로 서비스를 운영하고 있는 프론트엔드 개발자입니다. 솔직히 말하면 Next.js 13에서 App Router가 처음 나왔을 때는 "이거 써도 되나?" 싶을 만큼 불안정했습니다. 그런데 Next.js 15에 와서는 이야기가 완전히 달라졌어요. 실제 프로덕션에 올려서 몇 달 운영해보니, 이제는 자신 있게 추천할 수 있는 수준이 됐습니다. 이 글에서는 마케팅 문구가 아니라, 실제로 부딪히면서 배운 내용을 정리해보려 합니다.
1. 목차
- App Router를 다시 봐야 하는 이유
- 서버 컴포넌트, 제대로 이해하기
- 실전에서 막혔던 부분과 해결 팁
- 장단점 비교와 추천 대상
2. App Router를 다시 봐야 하는 이유
2-1. Pages Router와 무엇이 다른가
기존 Pages Router는 모든 컴포넌트가 기본적으로 클라이언트 번들에 포함됐습니다. 반면 Next.js 15 App Router에서는 서버 컴포넌트가 기본값입니다. 즉, 데이터 페칭과 렌더링을 서버에서 끝내고, 브라우저로는 완성된 HTML만 보냅니다. 처음엔 사고방식을 바꾸기가 어려웠지만, 익숙해지니 번들 크기가 눈에 띄게 줄었습니다.
2-2. 폴더 구조가 곧 라우팅
app 디렉터리 안에서 layout.tsx, page.tsx, loading.tsx, error.tsx 파일이 각자 역할을 가집니다. 특히 loading.tsx 하나만 만들어도 자동으로 Suspense 기반 로딩 UI가 붙는 점은 정말 편했습니다. 별도 설정 없이 폴더 구조만으로 중첩 레이아웃이 완성되니, 유지보수할 때 구조 파악이 빨라집니다.
3. 서버 컴포넌트, 제대로 이해하기
3-1. 서버 컴포넌트가 가져온 변화
서버 컴포넌트의 핵심은 "데이터가 있는 곳에서 렌더링한다"는 발상입니다. 컴포넌트 안에서 직접 async/await로 DB나 API를 호출할 수 있어, 별도의 useEffect나 데이터 페칭 라이브러리 없이도 코드가 깔끔해졌습니다. 민감한 API 키가 클라이언트로 노출되지 않는 점도 보안상 큰 장점입니다.
3-2. 클라이언트 컴포넌트와의 경계
모든 걸 서버 컴포넌트로 만들 수는 없습니다. onClick, useState처럼 상호작용이 필요한 부분은 파일 맨 위에 'use client'를 선언해야 합니다. 실무 팁이라면, 서버 컴포넌트를 부모로 두고 인터랙션이 필요한 작은 단위만 클라이언트 컴포넌트로 떼어내는 구조를 추천합니다. 그래야 클라이언트 번들을 최소한으로 유지할 수 있습니다.
3-3. 캐싱 동작의 변화
Next.js 15에서는 fetch의 기본 캐싱 정책이 바뀌었습니다. 이전 버전과 달리 기본적으로 캐시되지 않으므로, 캐싱이 필요하면 명시적으로 설정해야 합니다. 이 변화를 모르고 넘어가면 "왜 데이터가 갱신 안 되지?" 혹은 "왜 매번 호출되지?" 하고 한참 헤매게 됩니다. 저도 여기서 반나절을 날렸습니다.
4. 실전에서 막혔던 부분과 해결 팁
4-1. 꼭 알아두면 좋은 실전 팁 3가지
- 팁 1 — 'use client'는 잎(leaf)에서만: 클라이언트 지시어를 상위 레이아웃에 붙이면 그 아래 전부가 클라이언트로 끌려갑니다. 가능한 한 가장 말단 컴포넌트에만 선언하세요.
- 팁 2 — 데이터 페칭은 Suspense와 함께: 느린 API는 컴포넌트를 Suspense로 감싸고 loading.tsx를 활용하면, 사용자는 빈 화면 대신 스켈레톤을 보게 됩니다. 체감 속도가 확 좋아집니다.
- 팁 3 — Server Actions로 폼 처리: 별도 API 라우트를 만들지 않고도 폼 제출을 서버에서 직접 처리할 수 있습니다. 코드가 절반으로 줄어드는 경험을 했습니다.
4-2. 자주 만나는 함정
서버 컴포넌트에서는 window나 localStorage 같은 브라우저 전용 객체를 쓸 수 없습니다. 빌드 시점엔 멀쩡하다가 런타임에 에러가 나는 경우가 많으니 주의하세요. 또한 서버 컴포넌트에 이벤트 핸들러를 props로 넘기면 에러가 납니다. 이 경계만 명확히 잡아도 디버깅 시간이 크게 줄어듭니다.
5. 장단점 비교와 추천 대상
5-1. 장단점 비교표
| 구분 | 장점 | 단점 |
|---|---|---|
| 성능 | 서버 컴포넌트로 번들 크기 감소, 초기 로딩 빠름 | 잘못된 클라이언트 경계 설정 시 오히려 느려짐 |
| 개발 경험 | 폴더 기반 라우팅, 직관적인 레이아웃 구조 | Pages Router에서 넘어올 때 학습 곡선 존재 |
| 데이터 처리 | async 컴포넌트, Server Actions로 코드 간결 | 캐싱 정책 변화로 초기 혼란 가능 |
| 생태계 | 안정성 향상, 공식 문서 충실 | 일부 서드파티 라이브러리 호환성 이슈 |
5-2. 이런 분께 추천합니다
솔직하게 정리하면, 새로 시작하는 프로젝트라면 Next.js 15 App Router를 적극 추천합니다. 특히 SEO가 중요한 서비스, 초기 로딩 성능이 곧 매출로 직결되는 커머스나 콘텐츠 플랫폼이라면 서버 컴포넌트의 효과를 가장 크게 누릴 수 있습니다. 반대로 기존 Pages Router로 잘 돌아가는 안정적인 서비스를 무리하게 마이그레이션하는 건 권하지 않습니다. 단계적으로 익히면서 새 기능부터 App Router로 도입하는 방식이 가장 현실적입니다. Next.js 15는 이제 실험이 아니라 실전입니다. 한 번 익혀두면 분명히 든든한 무기가 될 거예요.