Next.js 15 마이그레이션 할 게 없다?

Composite·2024년 5월 31일

JavaScript React frontend js next.js nextjs react.js ts typescript web 리액트 웹 프론트엔드

(이 글은 RC 기준으로, 정식 출시될 때 공식 문서가 변경되면 이 글이 맞지 않을 수 있으므로 100% 맹신하지 않도록 한다.)

눈 깜짝할 사이에 Next.js 15 버전을 앞두고 있다.

별거 없다고 생각하고 넘어간 사이 RC 발표했는데, 여기서 발표한 키포인트가 뭐냐
내가 개인적으로 기대한 부분은 강조 표시하겠다.

최소 요구사항: React 19 이상
React Compiler 지원 (실험적)
좀 더 친절해진 오류 안내(알고보니 React의 한계였다고)
이제 캐시는 기본값이 아님(이제 정신 차렸구나)
GET 라우트 핸들러 또한 캐시 기본값이 아님(이거 때문에 개빡친 일 한두번이 아니다)
점진적 부분 렌더링 지원(실험적)
서버 후처리(next/after) 지원(실험적)
create-next-app 개선
next/image 기능의 필수였던 sharp 패키지는 이제 선택 사항
next/font 기능을 제거하고 @next/font 패키지로 분리
export const dynamic = 'force-dynamic' 일일이 달 필요가 없어졌음
페이지 라우터에 번들 여부 설정 가능(기본 비활성화, 기존에는 일부 번들링할 패키지 설정 가능, 앱 라우터는 기본 활성)
서버 실행 패키지에 번들링 예외 지정 가능 (클라이언트의 경우 이미 next/dynamic 및 React.lazy로 가능)

위 기능에 대한 여러 분석은 나중에 하도록 하겠다. (어쩌면 정식 출시 후에 작성할 수도 있다.)
본론으로, 이제 제목 값을 해야겠다. 먼저 공식 문서의 마이그레이션 부분을 참고하면서 시작해 보자.

업그레이드

버전업 하려면 업그레이드 해야 한다. 현재 RC 버전이므로, 공식 페이지에 갈음한다.
갈음이라 쓰고 패스라 읽는다.

fetch 함수

만약 동적 호출을 염두해 두고 별도로 캐시 옵션 지정 안했으면, 할 거 없다.
오히려 동적 호출을 염두해 뒀을 때에 유리해진 개선 사항이기 때문이다.
반대로, 캐시를 유지하고자 한다면, 캐시 옵션을 지정해야 한다.
그 어느 백엔드도 이렇게 캐시를 빡시게 한 놈은 내 경험 상 Next.js 가 처음이다.
내가 왠만하면 캐시 쓰겠는데, 이녀석은 캐시가 쓰기 싫어지는 심리적 압박을 준 최초의 백엔드 기능을 가진 프레임워크다.

근데 공식 문서에 괴랄한 기능이 생겼는데,

export const fetchCache = 'default-cache'

위 문구를 app/layout.jsx 에 넣으면 기존처럼 캐시가 기본값인 서버가 탄생한다.
여기까지는 뭐라 안하는데, 이게 layout에 걸면 하위 페이지 모두에게 전파된다. 따라서 일부 캐시가 싫은 페이지는,

export const fetchCache = 'force-no-store'

걸어야 한다... 이거 좀 피곤해지겠는데... layout에 잘못 거면 전파력 무시 못 하겠다.

일단 기존에는 우리가 원하던 대로 원하는 곳에 캐시 옵션을 붙이는 방향이기 때문에, 특별한 일 없으면 대응 안해도 된다.

GET 라우트 핸들러

내가 Next.js 쓰면서 개빡쳤던 부분이 바로 GET 라우터의 무분별한 캐싱이었다.
드디어 캐시 지옥에서 벗어날 수 있게 됐다.

export const dynamic = 'force-dynamic'

이걸 걸어도 엿장수 마음대로 캐시가 적용되기도 했는데 그럴 필요 없어졌다. 기본 위 문구 적용이다.
하지만 반대로 걸고 싶은 경우가 있을 것이다.

export const dynamic = 'force-static'

이렇게 하면 된다. 그럴 일은 잘 없겠지만. 물론 기존에 force-dynamic 걸었을 때, 지우지 않아도 동작하니 걱정 말길 바란다.

클라이언트단 캐시

기존에는 클라이언트 간 페이지를 이동할 때, 캐시된 페이지 컴포넌트를 무조건 활용했다.
하지만, 이제 기본적으로는 캐시가 완화되었으며, 기존 라우팅 캐시대로 하고 싶으면 아래와 같이 옵션 지정하면 된다고 한다.
단, layout 과 loading 컴포넌트 파일은 여전히 캐시되고 재사용하니 참고하자.

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30, //원래 기본값은 0, 페이지 이동 시 캐시 없다.
      static: 180, //원래 기본값은 300, 페이지를 미리 불러올 때 캐시를 사용한다.
    },
  },
}
module.exports = nextConfig

next/font

만약 혹시 구글 폰트 쓸 때는 마이그레이션 해야 한다. 15 버전부터는 삭제되며 별도 패키지로 설치해야 하기 때문이다.
나눔고딕이나 디자이너들이 선호하는 영문 폰트 사용 시 일부 사용했을 것이다.
나같은 경우, 웹폰트를 원격에서 <link> 태그로 불러오거나 아예 패키지 깔고 css import 해서 사용했기 때문에 대응할 필요가 없다.

어쨌든, next/font 를 @next/font 로 바꾸면 준비 끝이니 패키지 깔고 어자피 전역 레이아웃에 정의했을 터니 어렵지 않게 마이그레이션할 수 있을 것이다.

bundlePagesRouterDependencies

페이지 라우터 아직도 많이 쓰는 거 안다. 그지같은 캐시 때문에 때려쳤던 사람도 있을 터고.
근데 bundlePagesExternals 는 사용할 일 없을 테니, 일부 사용한 개발자들에게 필요하다고 보면 되겠다.
어자피 Vercel 호스팅해서 서비스하는 사용자들은 이걸 쓸 일 없으니 해당사항 없을 것이다.

serverExternalPackages

나같은 경우 ssh2 패키지 때문에 이 망할 번들링 예외 옵션을 webpack 번들러 옵션에서 지정했는데,
turbo는 의외로 왜인지 딴 짓 안해도 정상 작동 하길래 왜인가 했더니 이녀석이 실험적 기능으로 있었다.
어쩐지 번들링 예외 옵션이 turbopack에 없는 이유가 프레임워크 차원에서 할 생각이었구나...
다시한번 말하지만, 클라이언트 패키지는 next/dynamic 또는 React.lazy() 함수로 대응 가능하다.

Speed Insights

Vercel 호스팅 하는 사용자들에게만 해당되는 사항이니, Vercel 공식 문서를 참조한다.
Vercel 외 호스팅 사용자는 어자피 못 쓰기 때문에 마이그할 필요가 없는 부분이다.

마치며

예전에 React 18 나왔을 때, Remix는 여유로웠던 반면, Next.js 는 며칠간 큰 진통이 있었다.
이번 React 19는, Vercel의 관여가 많다 보니, 반대로 Remix가 바쁜 나날을 보낼 것 같다.

번외: Nest.js 에 React 서버 컴포넌트 쌉가능?

그렇다. 리액트 차원에서 서버 기능이 대폭 추가되어, Nest.js 같이 백엔드 위주의 프레임워크나 Express 같은 간단한 라이브러리에 서버 컴포넌트 탑재가 쌉가능해지는 시대가 열렸다. 어자피 용자들이 알아서 이식해줄 테니 큰 걱정은 없다고는 하지만,
Next.js 부럽지 않은(?) 풀스택 프레임워크 환경 쌉가능 예상한다.
물론 Next.js 가 프론트엔드 시장을 꽤 장악하고 있지만, 프레임워크는 프레임워크다. 마치 전자정부처럼 말이지.
나는 서버 컴포넌트가 많이 활성화 되었으면 좋겠다. Deno에도 들어가고 Nest.js 에도 들어갔으면 좋겠다.

프론트엔드 시장은 현재 많이 쏠려있기 때문에, 경쟁이 필요하다. 오픈소스의 많은 힘과 도움이 필요하다.
나는 현재 주 업무가 개발이 아니기 때문에 열정적인 참여는 어렵지만, 인사이트는 계속 낼 생각이다.

지금 Next.js 행보를 보니 React 19가 연말에 나올 거라는 예상을 했는데 이러다 빠르면 연 하반기 초에 나오는거 아닌가 싶다.

끗.