넉스트 (Nuxt.js)

넉스트(Nuxt.js)는 뷰(Vue.js) 위에 서버 사이드 렌더링(Server Side Rendering), 파일 기반 라우팅, 데이터 페칭, 배포까지 아우르는 규칙과 도구를 얹은 풀스택 웹 프레임워크다. 뷰가 화면을 그리는 라이브러리 계층이라면, 넉스트는 그 위에서 애플리케이션 전체의 구조와 렌더링 전략을 책임진다. 리액트(React) 생태계의 넥스트(Next.js)와 같은 위치에 있는 프레임워크로, 현재는 뷰 3와 비트(Vite) 기반의 넉스트 3 세대가 표준이다.

왜 넉스트를 쓰는가

뷰만으로 SPA(Single Page Application)를 만들면 두 가지 부담이 생긴다. 첫째, 빈 HTML에 자바스크립트(JavaScript)로 화면을 그리는 구조라 첫 화면이 늦게 뜨고 검색 엔진 최적화(SEO, Search Engine Optimization)에 불리하다. 둘째, 라우터 설정, 상태 관리, 코드 분할, 빌드 구성 같은 기반 결정을 팀이 매번 직접 해야 한다. 넉스트는 이 두 문제를 관례(Convention)로 해결한다. 서버에서 완성된 HTML을 먼저 내려보내는 SSR을 기본 제공해 첫 화면과 SEO 문제를 풀고, 디렉터리 구조라는 규칙으로 반복되는 설정을 없앤다. pages 디렉터리에 파일을 만들면 그 경로가 곧 라우트가 되고, components 디렉터리의 컴포넌트는 임포트(Import) 없이 자동 인식되며, 미들웨어와 플러그인, 레이아웃도 정해진 폴더에 두면 동작한다. 설정보다 관례(Convention over Configuration)라는 철학이 프레임워크 전반에 흐른다.

렌더링 모드와 데이터 페칭

넉스트의 핵심 가치는 렌더링 전략을 선택할 수 있다는 데 있다. 기본값인 유니버설(Universal) 모드에서는 첫 요청을 서버가 렌더링해 완성된 HTML을 주고, 브라우저에서 하이드레이션(Hydration)을 거친 뒤에는 SPA처럼 동작한다. 빌드 시점에 페이지를 미리 생성하는 정적 생성(SSG, Static Site Generation), 클라이언트 렌더링 전용 모드도 지원하며, 넉스트 3부터는 라우트 규칙(Route Rules)으로 경로별 렌더링 방식과 캐시 정책을 다르게 지정하는 하이브리드 렌더링이 가능하다. 예를 들어 마케팅 페이지는 정적으로, 상품 페이지는 SSR로, 관리자 페이지는 클라이언트 렌더링으로 한 프로젝트 안에서 섞을 수 있다. 데이터 페칭은 useFetch와 useAsyncData 컴포저블(Composable)이 담당하는데, 서버 렌더링 중에 가져온 데이터를 HTML에 실어 보내 클라이언트가 같은 요청을 반복하지 않게 하는 상태 전달까지 처리해 준다. SSR 환경에서는 같은 코드가 서버와 브라우저 양쪽에서 실행되므로, window 같은 브라우저 전용 객체 접근을 클라이언트 시점으로 미루는 구분이 필요하다는 점은 개발자가 익혀야 할 부분이다.