Boaz
이번 글에서는 Next.js 공식 문서가 14버전에서 15버전으로 넘어가며 어떻게 변했고, 그 변화가 왜 중요한지를 짚어봅니다. 공식 문서에는 단순한 가이드를 넘어서 프레임워크 팀이 개발자에게 보내는 “우리는 앞으로 이렇게 갈 거야”라는 메세지가 포함되어 있기도 해서요. 어떤 방향이 될지 함께 알아볼게요.
Linking and Navigating → Server and Client Components → Fetching Data → Updating Data → Error Handling 순으로 실제 페이지를 만들 때의 흐름을 그대로 따라갑니다.거대한 챕터를 없애고 키워드 단위로 쪼갠 건 LLM·검색 친화 문서를 만들려는 의도같아요. 개발자든 AI든 필요한 주제를 바로 인덱싱할 수 있도록이요.
서버 렌더링, 클라이언트 렌더링을 따로 떼지 않고 “경계(edge)를 어떻게 자를까?”에 집중합니다.
use client 지시어 하나로 경계를 명시하고, Composition Patterns까지 이어서 보여줘요.이제 ISR은 사이드 가이드로 내려가고, PPR이 기본 렌더링 전략입니다.
Route Handlers + Middleware + Edge Runtime 조합으로 권한, 로깅, 국제화까지 처리하라는 메시지.
별도 Node 서버 없이도 "프론트 특화 백엔드 레이어"를 운영하라는 의도 같아 보여요.
CI Build Caching, Data Security, Package Bundling, Self-Hosting, Multi-tenant
Next.js를 제품 운영 플랫폼으로 바라보라는 신호입니다. “Vercel 쓰면 더 쉽다”는 서브텍스트도 있고요. 다만 self hosting 도 가능하다고 열어준 것 같습니다.
Turbopack 문서가 “패키지 번들링” 챕터로 올라온 것도 눈여겨봐야 해요. 빌드-타임 최적화를 프레임워크 레벨로 끌어올렸다는 의미에 가까워서요.
“가능한 한 서버에서 처리하고, 읽기·쓰기·캐시를 명확히 쪼개라.” 리액트 팀의 방향성과 일치하네요.
정적·동적 혼합을 표준으로 삼아 TTFB와 DX 사이에 트레이드 오프를 해결해보겠다는 의미인 것 같습니다.
프론트엔드 팀이 API 경계까지 직접 다뤄라는 메세지인것 같아요.
Dev→Deploy→Observe→Secure 전 과정이 Next.js 안에서 이뤄질 수 있도록 진화할 것 같아요.
키워드 단위 문서로 AI 검색·인덱싱 최적화를 했네요.
Next.js 15 문서는 “프론트엔드 프레임워크”를 넘어 “서버-우선 데이터·렌더링·운영 플랫폼”으로의 진화를 공식화한 것 같아요. 프론트엔드 개발자는 더 이상 컴포넌트-단위 구현에만 머무를 수 없는 것 같아요.
문서 개편을 새롭게 이해하려면 시간이 필요하지만, 읽어보면서 천천히 방향성을 이해한다면 Clean F.S.D 같은 아키텍처와도 연결되는 부분이 있다는 걸 발견할 수 있어요. 결국 “단순 구현”보다 “데이터·렌더링·운영 설계”가 핵심 역량이 되는 시대—Next.js 문서가 그 변화를 미리 보여준 것 같아요.