[나만무] Next.js를 선택하게 된 이유

Next.js를 선택하게 된 이유

저는 이번 한 주동안 배워볼 프레임워크로 Next.js를 선택하게 되었는데요. 이전에 배웠던 Java의 Spring이나, React를 다시금 볼 수도 있었지만, 한편으로는 그동안 쌓아 온 기본기를 바탕으로 새로운 기술들을 배워보고 싶은 마음이 컸습니다. 그리고 주니어 개발자의 경우 백엔드와 프론트엔드를 나누는 것이 무의미하고, 오히려 독이 될 수 있다는 말에 깊이 공감하기도 했습니다.

 

그러던 중에 백과 프론트가 나눠져 있지 않은 풀스택 웹 프레임워크인 Next.js가 있다고 해서 관심을 가지게 되었는데요. 기술적인 유연성을 갖추고 싶은 마음과 백/프론트 둘 다 할 줄 아는 사람이 되고 싶은 마음이 합쳐져서 이번에 Next.js를 배워보기로 마음먹었습니다. 이에 따라 Next.js의 장점은 무엇인지, 왜 선택해야 하는지에 대해서 정리해 보려고 합니다.

 

 

Next.js의 장점

풀스택 프레임워크

Next.js는 React 기반의 웹 프레임워크로, 프론트와 백을 하나의 프로젝트 안에서 통합적으로 개발할 수 있는 풀스택 프레임워크인데요. 프론트 단에서는 React를 주축으로 한 UI 구성과 다양한 렌더링 전략을 자유롭게 선택할 수 있습니다.

 

또한 백 단에서는 API Routes 기능을 통해 서버를 별도로 구성하지 않아도 각 요청을 처리할 수 있는 엔드포인트를 파일 단위로 정의할 수 있지요. 이는 마치 서버리스 함수처럼 동작하여 간단한 백엔드 기능 구현을 매우 간편하게 만들어 줍니다.

 

다양한 렌더링 방식 지원

기본적인 React 라이브러리는 CSR(Client Side Rendering, 클라이언트에서 JS로 처리해 HTML을 완성하는 방식)만 지원합니다. 이는 곧 React 자체는 렌더링 방식에 대한 내장된 전략이 없고, 브라우저에서 동작하는 Client Side Library일 뿐이라는 건데요.

 

반면 Next.js는 React 코드를 기반으로 서버에서 미리 HTML을 만든 다음 클라이언트에 보내는 방식인 SSR(Server Side Rendering)을 추가로 구현해 놓음으로써 활용할 수 있습니다. 이를 통해 기존 CSR의 단점인 구글 검색 노출 불리, 페이지 로딩속도 저하 등의 문제를 해결할 수 있지요. 그리고 심지어 SSR만 쓸 수도 있는 것도 아닙니다. 초기 로딩 속도가 중요한 페이지는 SSR로, 자주 변경되지 않는 페이지는 SSG로 구성하는 식의 유연한 설계가 가능해, 성능과 SEO 모두를 만족시키는 구조를 만들 수 있습니다.

 

즉 Next.js의 진짜 강점은 React로 만든 웹 애플리케이션에 대해 페이지 단위로 유연하게 렌더링 전략을 다르게 가져갈 수 있다는 점입니다. 현재는 무조건 CSR이 좋다, 무조건 SSR이 좋다가 아닌 Mix Rendering, 즉 다양한 렌더링 방식이 목적에 따라 혼용되고 있는 시대인데요. 이러한 흐름에 있어 렌더링 전략의 그라데이션을 지원하는 유연한 프레임워크인 Next.js는 지금 시대의 웹 트렌드(Mix Rendering)에 완벽하게 들어맞는다고 할 수 있습니다.

 

높은 생산성과 개발자 경험

Next.js는 개발자가 빠르게 구조를 잡고 기능을 구현할 수 있도록 다양한 개발 편의 기능을 제공하는데요. 먼저, 파일 기반 라우팅은 pages/ 또는 app/ 폴더에 파일만 생성하면 자동으로 URL 경로가 설정되어 별도의 라우터 설정이 필요 없고, 각 페이지는 자동으로 코드가 분할되어 사용자가 해당 페이지를 방문할 때 피룡한 코드만 불러오게 되어 성능 또한 개선됩니다.

 

또한 변경 사항을 저장하면 즉시 브라우저에 반영되는 HMR(Hot Module Replacement)은 개발 흐름을 방해하지 않고 즉각적인 피드백을 가능하게 합니다. 뿐만 아니라 App Router를 사용할 경우에는 페이지, 레이아웃, 로딩 상태, 에러 UI를 폴더 구조만으로 자연스럽게 분리해 구성할 수 있어, 대규모 애플리케이션에서도 유지보수가 쉬운 구조를 갖출 수 있습니다.

 

마지막으로 기본 템플릿에는 TypeScript(JavaScript에 정적 타입을 추가한 언어), ESLint(코드 스타일 및 문법 오류 자동 분석 도구), Prettier(자동 코드 포매터) 등의 도구가 설정된 상태로 포함되어 있어 코드 스타일 통일, 정적 분석, 타입 안정성까지 자연스럽게 확보할 수 있고, 실무에 바로 적용 가능한 프로젝트 환경이 자동으로 구축됩니다.

 

클라우드와의 높은 통합성

Next.js는 Vercel과의 궁합이 뛰어난데요. git 푸시만으로도 자동 배포, preview 환경 생성, 이미지 최적화, Edge Function 실행 등 다양한 기능이 지원됩니다. 이를 통해 CI/CD 파이프라인 구축에 드는 부담을 줄이고, 협업 중인 팀원들도 언제든지 배포 상태를 확인하고 피드백을 줄 수 있는 환경을 제공합니다. 꼭 Vercel이 아니더라도 AWS, Netify, Cloudflare 등 다양한 플랫폼에서도 유연하게 배포가 가능합니다.

 

 

Next.js의 단점

1. 폴더 기반 라우팅 특성 상 예약 파일이 많아, 프로젝트가 커질수록 구조가 복잡해질 수 있음
   • App Router 도입 이후 예약 파일이 늘어나게 됨
   • 대규모 프로젝트에서는 폴더 관리와 구조 파악이 번거로울 수 있음
2. 아직 실험적인 React 기능들이 포함되어 있어 안정성과 사용성이 떨어질 때가 있음
   • App Router는 React Server Components, Suspense, Streaming 같은 실험적 기능에 기반함
   • 타입 안정성, 디버깅 편의성, 일부 라이브러리 호환성 측면에서 미완성된 부분이 있음
3. 클라이언트 컴포넌트와 서버 컴포넌트를 명시적으로 구분해야 하고, 그에 따라 파일이 많아지고 관리가 번거로울 수 있음
   • App Router에서는 기본적으로 모든 컴포넌트가 서버 컴포넌트로 간주되므로, 클라이언트 컴포넌트의 경우 별도 명시가 필요
   • 이로 인해 폴더 내 컴포넌트 수가 많아지고, 컴포넌트 분리가 과도해지는 느낌을 줄 수 있음
4. 웹소켓이나 WebRTC 같은 실시간 양방향 통신 기능은 Next.js만으로는 구현하기 어려움
   • 요청-응답 기반 렌더링 최적화 프레임워크인 Next.js는 HTML 렌더링과 정적 자원 제공에 최적화되어 있음
5. 프레임워크 자체가 SSR과 정적 렌더링 중심이라, 일반적인 백엔드 기능에는 한계가 있음
   • DB 커넥션 관리, 인증 세션, 복잡한 비즈니스 로직 처리 등을 포함한 전통적인 서버 프레임워크(Nest.js 등)보다는 제한적인 기능만 제공