NextJS가 꼭 필요한 것은 아닙

Translated for your language. Read the original.

AI-assisted draft.

Next.js가 꼭 필요한 것은 아닙니다

React 앱을 구축할 때 Next.js는 가장 먼저 떠오르는 선택지입니다. 훌륭한 프레임워크임에 틀림없습니다. 하지만 '기본값'이라고 해서 반드시 '필수'인 것은 아닙니다.

잘못된 프로젝트에 Next.js를 사용한 결과, 개발 속도가 저하되고 팀 내 마찰이 발생했습니다. 저희는 대시보드와 차트가 포함된 데이터 중심의 제품을 만들었습니다. 거의 모든 화면은 로그인 후에만 볼 수 있었습니다.

이런 유형의 앱에서는 서버 사이드 렌더링(SSR)이 가치를 더해주기는커녕 비용만 증가시켰습니다.

적절한 도구는 무엇을 만드느냐에 따라 달라집니다.

콘텐츠 중심 프로젝트: • 마케팅 사이트 • 블로그 • 스토어프론트 • 문서(Docs) • 여기에는 Next.js를 사용하세요. SEO가 중요하고 콘텐츠가 정적이기 때문입니다.

애플리케이션 중심 프로젝트: • 내부 도구 • 대시보드 • 관리자 패널 • SaaS 콘솔 • 여기에는 Vite 기반의 SPA를 사용하세요. 이러한 앱은 인증 뒤에 존재하며 API에 의존합니다.

저희는 Next.js에서 Vite SPA로 전환했습니다. 그 이유는 다음과 같습니다.

더 쉬운 디버깅 서버 에러는 컴포넌트와 명확하게 매핑되지 않습니다. 반면 클라이언트 측 에러는 브라우저에서 명확한 스택 트레이스(stack trace)와 함께 발생하므로 버그 수정이 빠릅니다.
더 나은 테스트 다른 서버 컴포넌트를 렌더링하는 서버 컴포넌트를 유닛 테스트하기란 쉽지 않습니다. 저희는 테스트 가능성을 유지하기 위해 설계 단계에서 많은 고민을 해야 했고, 이는 실수였습니다.
더 단순한 인증 SSR은 매 요청마다 서버에서 토큰을 검증해야 합니다. 이는 공격 표면(attack surface)을 넓히고 쿠키 로직을 복잡하게 만듭니다. 클라이언트 중심 앱은 API라는 한 곳에서 인증을 처리합니다.
더 낮은 인프라 비용 SSR은 모든 요청에 대해 항상 켜져 있는 서버가 필요합니다. 반면 정적 프론트엔드는 CDN을 통해 파일 형태로 배포됩니다. 운영하고 보안을 유지해야 할 서비스가 하나 줄어드는 셈입니다.
더 적은 복잡성 Next.js는 서버와 클라이언트의 분리를 강제합니다. 프론트엔드 엔지니어가 미들웨어(middleware)나 캐싱(caching) 같은 서버 측 이슈까지 관리해야 했고, 이는 개발 속도를 늦췄습니다.

저희는 단계적으로 마이그레이션을 진행했습니다. SEO가 중요한 공개 페이지에는 Next.js를 유지했고, 그 외의 모든 것은 Vite SPA로 옮겼습니다.

트레이드오프(trade-offs)는 미미했습니다: • SEO: 로그인 뒤에 있는 대시보드는 SEO가 필요하지 않습니다. • 초기 로딩: 데이터 중심의 앱은 프레임워크가 아니라 보통 데이터베이스 때문에 느려집니다.

SEO와 소셜 프리뷰가 중요하다면 Next.js를 사용하세요. 앱이 인터랙티브하고 데이터 중심이며 로그인 후에 사용된다면 Vite SPA를 사용하세요.

무조건적인 기본값 사용을 멈추세요. 자신이 실제로 무엇을 만들고 있는지 스스로에게 물어보십시오.