Next.js 개발 경험기

Fastcampus Language 팀에서 Next.js 로 웹 애플리케이션을 만들며 느낀 장단점을 정리한 글이다. "SSR 과 SEO 빼면 쓸 이유가 없다" 는 시각을 겨냥해, 파일 시스템 라우팅·내장 기능·데이터 페칭 메서드의 차이를 실제 사용 경험으로 풀어낸다.

핵심 포인트

페이지 라우트 기반의 다소 강압적인 파일 시스템이 오히려 좋게 작용했다. 구조를 고민하는 데 들던 리소스가 줄고 파생되는 하위 구조가 명확해졌다.
부수 효과로 파일명이 곧 URL 이 되고 라우트별 자동 code splitting 이 붙는다.
환경 변수는 서버·클라이언트 노출 여부에 따라 나뉜다. `NEXT_PUBLIC_` 접두사가 붙으면 브라우저에 노출되고, 없으면 Node 환경에서만 보인다.
`.env.*` 형태로 값을 지정하면 jest·cypress 같은 테스트 환경도 자동으로 잡혀, axios mocking·action creator 테스트·e2e 테스트를 간편하게 할 수 있다.
dev 서버는 속도와 생산성, production 은 최적화와 효율성이라는 책임 분할 원칙이 뚜렷하다고 평가한다.

상세 정리

배경으로 Zeit → Vercel 리브랜딩과 시리즈 A 2,100만 달러 투자를 언급하며, 2018년 5버전에서 2020년 10버전까지 2~3개월 주기로 꾸준히 올라온 속도를 근거로 든다.
Vercel 의 철학을 생산성과 간편화로 읽고, React·Vue 와 Express·Koa 사이의 고민을 덜어 주는 Next·Nest 같은 프레임워크가 사람들을 움직였다고 본다.
`getInitialProps` 의 주의점: universal method 라 서버 사이드와 `next/router`(클라이언트) 양쪽에서 호출될 가능성이 있다. 공식 문서도 `getStaticProps`·`getServerSideProps` 를 권한다.
styled-components 를 서버 사이드에서 쓰는 예를 든다. `ServerStyleSheet` 인스턴스를 만들어 `collectStyles` 로 앱 전체 스타일을 수집하고 `getElement()` 로 스타일 태그를 만들어 `_document.js` 템플릿에 전달한다.
`_document.js` 의 용도는 애플리케이션의 `<html>`·`<body>` 태그를 보강하는 것이라고 정리한다.
`getStaticProps` 를 쓸 상황 넷: 매 요청마다 fetch 할 필요 없는 데이터, headless CMS 에서 오는 데이터, 유저와 무관하게 공개 캐시 가능한 데이터, SEO 때문에 미리 렌더링해야 하는 페이지. HTML 과 JSON 을 모두 생성해 둬 CDN 캐시가 쉽다.
`getServerSideProps` 는 서버에서만 실행되고 브라우저에서는 절대 실행되지 않는다. `next/link` 로 클라이언트 사이드 전환을 해도 `getInitialProps` 와 달리 무조건 서버에서 돈다. 당연히 page 에서만 쓸 수 있다.
컨텍스트 하위 키로 params·req(HTTP 요청 객체)·res(HTTP 응답 객체)·query(쿼리 문자열)를 정리한다.
TypeScript 컴파일 체크는 내장 지원되다가 속도 이슈로 제거된 것으로 알고 있다며 개인적으로 아쉬운 점으로 남긴다.
프레임워크의 단점으로 낮은 자율성과 높은 종속성을 꼽되, 공식 문서가 외부 라이브러리 적용 예시를 잘 보여 준 점을 좋게 본다.
자유도의 예: CSS-in-JS 만 9개 라이브러리를 지원하고 CSS·SASS 도 지원하며 LESS 는 내장 지원 예정이라, 취향에 따라 고르면 된다.
다만 지원하지 않는 라이브러리나 커스터마이징이 필요한 부분은 적용하기 매우 힘들었다고 한계를 명시한다.