들어가는 말

지금까지 진행해온 프로젝트는 대부분 Next.js를 기반으로 만들어졌다. 하지만 부끄럽게도, 내가 만든 페이지들에 대한 빌드 결과물이 실제로 어떤 모습으로 나오는지는 깊게 들여다본 적이 없었다. 보통은 개발을 마치고 빌드만 수행한 뒤 인프라팀에 전달하거나, 이미 마련된 배포 파이프라인에 맞춰 올려두는 식이었다. 그 결과물들이 어떤 구조로 구성되고, 어떤 방식으로 실행되는지는 자연스럽게 관심을 덜 기울이게 되었다.

이번 글에서는 그동안 무심코 지나쳤던 이 부분을 집중적으로 살펴보려 한다. Next.js 프로젝트를 빌드했을 때 실제로 어떤 결과물이 나오고, 그 구성은 어떤 의미를 가지는지, 또 라우팅과 렌더링 종류에 따라 어떻게 달라지는지 정리해보면서, NextJS 프레임워크의 동작 원리에 대한 이해를 해보고자 한다.

.next 내부 구조

.next/cache/

빌드 캐시(재빌드 속도를 빠르게 하기 위한 중간 산출물)을 지닌 폴더이다. 로컬 개발 및 빌드 최적화를 위한 폴더로, 보통 배포에는 필요 없음.

.next/diagnostics/

Next.js 빌드 및 런타임에 대한 분석용 정보가 들어간다. 일반적으로는 내부 디버깅이나 분석 용도로 쓰이고, 앱 실행에는 직접 필요하지 않다.

.next/server/

서버 실행에 필요한 결과물이 들어가는 폴더로 서버측 실행 스크립트 코드, 서버 전용 API 라우트 등이 들어간다. next start를 실행하면 이 폴더 내부의 파일들을 불러와서 Node.js 서버를 띄운다.

이 글에서 주로 살펴볼 Initial HTML, Server Bundle JS 을 포함한다.

.next/static/

브라우저로 직접 내려가는 정적 자산을 모아둔 폴더이다. .next/server/가 서버에서 실행될 코드들의 모음이라면, .next/static/은 클라이언트에서 실행될 코드들의 모음이다. 페이지 번들(JS), 공통 청크(JS), CSS, 폰트 및 이미지 최적화 산출물 등을 포함한다.

이 글에서 주로 살펴볼 Client Bundle JS 을 포함한다.

.next/types/

컴파일 및 빌드 시점에 타입 기반 검증을 제공하기 위한 파일을 지닌 폴더이다. 라우트/파라미터/Next.js 규약(getStaticProps, getServerSideProps 등)에 대한 타입 검증을 통해 컴파일 및 빌드 시점에 오류를 잡아낸다.