HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🐣
프론트엔드 데브코스 4기 교육생/
💡
나유리팀/
🤔
NextJS를 사용하는 이유
🤔

NextJS를 사용하는 이유

🤔
NextJS를 사용하는 이유는 무엇일까?
원석의 생각정리

4가지 동작원리

Server Side Rendering(SSR), Server Static Generation(SSG), Incremental Server Rendering(ISR), Client Side Rendering(CSR)
 
사용성 개선을 위해 Server Side Rendering을 하는 것이 좋을 것이라 확신

NextJS의 장점과 단점

장점
단점
페이지 접속시 초기 렌더링 속도가 빠르다(SSR) 즉 SSR과 SSG를 지원하여 페이지를 서버에서 렌더링하고 성능을 향상시킬 수 있습니다. 이로써 SEO 최적화와 초기 로딩 속도 향상에 도움이 된다.
React에 익숙하지 않다면 학습 곡선이 높을 수 있다.
자동으로 페이지와 컴포넌트를 코드로 분할하여 필요한 부분만 불러와 불필요한 데이터 전송을 최소화합니다. 이는 초기 로딩 속도를 빠르게 만든다.
SSR 및 SSG를 구현하려면 추가적인 코드 작성과 구성이 필요하고 따라서 프로젝트의 복잡성이 증가하 수 있다.
API 라우팅: 내장된 API 라우팅을 통해 서버리스 함수를 만들고 관리할 수 있습니다.
SSR은 서버 측에서 페이지를 렌더링하기 때문에 서버 리소스를 추가로 필요로 할 수 있다.
lighthouse의 점수가 많이 증가할 수 있다
간단한 정적 웹사이트나 SPA(Single Page Application)에는 Next.js의 기능이 필요하지 않을 수 있다.
ㅤ
ㅤ
 

우리의 질문!

  1. 현업에서 Next.js 를 많이 사용하는 추세인지 궁금합니다
      • 현업에서 Nextjs 많이 쓴다. 아직 page 라우터를 쓰는 것으로 예상한다.
  1. 신입 이력서에 Next.js 사용경험이 있는 것이 취업에 도움이 많이 되는지 궁금합니다.
  1. 1. Next.js 를 사용해야 한다면, 저희는 Next.js 의 어떤 부분에 집중하여 공부하고 사용하는 것이 좋을지 멘토님의 의견이 궁금합니다. (2-3 묶어서 답)
      • Nextjs 사용 경험이 있다는 것은 취업에 도움이 되는 건 아니다. 다만 NextJS을 쓰면서 1deps 깊게 생각해보고 이것을 표현할 줄 아는 것, 새로운 기술을 빠르게 공부하고 적용할 수 있다는 것을 어필하면 도움이 된다. 단순히 써봤다는 것은 도움이 되지 않는다.
      • page 라우터와 새로 나온 app 라우터가 있는데 어느 것을 사용해도 좋다.
        • page: 계속 존재해왔고, 레퍼런스가 많다. 그래서 학습 비용을 줄일 수도 있다. 추천한다.(언젠가 legacy가 된다.)
        • app: 현재 react18이 나아가고자 하는 방향과 일치하다. 실제 react 개발자가 vercel로 자리를 옮겨 nextjs를 개발하고 있다. next를 공부하면서 react18에 대해 깊게 다룰 수 있다. react에 대한 개념이 없다면 더 좋을수도 있다. react는 lib, next는 프레임워크이므로 프레임워크를 쓴다는 것은 약속인데 lib는 어떻게 쓸지 변형이 아주 가능하기 때문이다. app 라우터를 쓰면서 server component SSG SSR 등의 개념들을 익혔다면 공부할만한 가치가 충분히 있다. 추천한다. 다만 래퍼런스가 많이 없어서 학습 비용이 많이 들 수 있다. 하지만 성공적으로 학습을 한다면 4배 이상 성장할 수 있다.
4. 멘토님께서는 React 와 Next 둘 중 어떤 것을 사용하기를 추천하시는지 궁금합니다!
  • next를 쓰든 react를 쓰든 둘 다 좋다. 위에서 말했던 것처럼 학습을 목적으로 (어차피 react18과 나아가는 방향이 같으니깐) next를 쓰면 나쁘지 않을 것 같다.

참고 자료

blog.kmong.com
https://blog.kmong.com/크몽-프론트엔드팀에서-next-js를-사용하는-이유-5474e10bc72b
위 자료를 함께 읽어보면 좋을 것 같아요!!
혜진의 생각정리
우리는 왜 Next 를 써야할까?
  • React: JavaScript 라이브러리
  • Next: React 프레임워크 -> 즉, Next 를 쓴다고 React 를 사용하지 못하는 것은 아님!

Next 를 사용하는 이유

나의 결론: 리액트에서 지원하지 않는 랜더링 기술을 사용하여 성능을 최적화하기 위해

1. CSR 과 SSR

사실 CSR 도 웹 페이지의 성능을 향상시키기 위해 고안된 기술 원래 옛날 웹은 사실 전부 다 SSR 이었음...!
SSR 이란?  - 서버에서 javascript 파일을 html 로 랜더링하고, 그걸 클라이언트(브라우저)로 전달  - 브라우저는 모든 javascript 가 로드될 때까지 기다릴 필요 없이 html 을 보여줌  - 따라서 초기 페이지의 First Contentful Paint 또는 Largest Contentful Paint 속도가 빠르다  - 하지만 다른 페이지 이동할때마다 또 서버를 호출해야해서, 서버의 부하가 커지고, 인터넷 대역폭이 많이 소모됨
CSR 이란?  - 서버에서 javascript 파일을 클라이언트로 보내면, 브라우저에서 그걸 html 로 랜더링함  - 브라우저는 javascript 파일을 해석하는 동안 빈 html 페이지를 보여줌  - 하지만 한 번 컨텐츠가 로드되면, 재호출이 없으므로 백엔드 호출 최소화할 수 있음  - 그리고 페이지 이동할 때마다 새로 컨텐츠를 로드하지 않아도 돼서 네이티브 앱과 같은 성능
https://d2.naver.com/helloworld/7804182
 
리액트에서 SSR
  • 리액트는 CSR 철학을 토대로 만들어진 라이브러리
  • 리액트는 공식적으로는 SSR 지원은 안되고, 직접 구현해야 함
  • SSR 과 살짝 다른 개념이지만, React Server Component 를 만들고 있긴 함(아직 출시 안함)
넥스트에서 SSR
  • 사실 넥스트도 리액트와 동일하게 SPA으로 동작함
  • 하지만 빈 html 이 아닌, server side 에서 rendering 된 html 을 가지고 SPA 로 동작한다는 차이
  • 내부적으로는 SPA 이기 때문에 전역상태관리 또한 가능한 것 (찐 SSR 은 전역상태관리 불가능함)

2. SSG

SSG 란?
  • 프로젝트 빌드 시, pre-render page 를 만들어 static 페이지로 가지고 있는 것
  • 클라이언트가 페이지를 요청하면 미리 만들어둔 페이지를 로드하여 보여주므로 응답이 빠름
  • 배포 되고나면 사전 렌더링한 페이지는 변경 되지 않기 때문에, 자주 바뀌지 않는 페이지에만 사용
 

Next 를 사용했을 때의 단점

프레임워크라서 생기는 어쩔 수 없는 한계

Next 를 사용해도 구현 방식은 전부 CSR 로 구현할 수도 있고, Next 에서 제공하는 기능을 사용하지 않고 React 를 사용하는 것과 똑같이 구현해도 됨.
하지만, 프레임워크를 사용한다는 것은 프레임워크에서 강요하는 규칙을 따를 필요가 있다는 것.
  • 어떤 부분은 구현이 너무 숨겨져 있어 우리가 제대로 커스텀하기 어려운 부분이 생길 수도 있음
  • 하지만 평범한 요구사항 수준에서는 아마 그런일은 발생하지 않을 것
  • Next 에서 제공하는 편리한 기능들을 사용하여 개발 시간을 단축시키는 것의 이점이 더 크다
 
리액트에서 SSR, SSG 같은 기술들을 사용하려면, 사실 Next 말고도 Gatsby 같은 다른 프레임워크가 있긴함. 하지만 SSR을 지원하는 리액트 프레임워크 분야에서는 Next 가 압도적인 선호도를 가지고 있으므로 사용자 층이 많고 추후 지원가능성이 더 높은 Next 를 사용하는 것이 좋다고 생각.
 
동환의 생각정리

React의 한계

  1. TV(Time To View), 즉 FCP(First Contentful paint)가 오래 걸린다
  1. js에 의해 페이지가 그려지므로 js가 필수적이다. 만약 사용자가 js를 비활성화한다면 첫번째 페이지조차 볼 수 없다
  1. SEO(검색엔진 최적화)가 힘들다
  1. 보안에 취약하다 - Client에서 모든 것을 렌더링하기 위해 코드를 받아야하는데 API key, 서버 주소 등이 노출된다
  1. CDN에 html이 캐시되지 않는다

Next.js의 장점

  1. 여러 렌더링 방법을 혼합해서 사용 가능 (SSG, ISR, SSG, CSR)
  1. 자동으로 코드 스플리팅과 서버 렌더링 지원 - FCP 감소
  1. 데이터 패칭 설정 가능
      2. 주체: 서버 or 클라이언트
      패치 주기: 한번 or 주기적 패칭
  1. nested layout - outlet을 사용할 때보다 간편하게 layout.js 사용가능
  1. html streaming - 원래는 모든 데이터를 서버로부터 받아야 화면을 그리는데 Suspense를 이용해서 데이터를 chunk로 나눠서 받아 화면의 일부분부터 그릴 수 있다
  1. turbopack - 새로운 번들러로 dev모드에서 웹팩보다 700배 vite보다 10배 빠름, 아직 alpha라 실제 프로덕션에서는 사용해도 되는지는 모르겠음
  1. SSG, ISR을 사용하면 CDN에 화면 캐싱 가능
  1. 미들웨어, 서버리스 함수 사용으로 보안이 좋아진다

Next의 단점

  • 러닝 커브가 있다
  • 프로젝트가 복잡해질 수 있다
  • legacy 라이브러리와 충돌 발생할 수 있음

우리가 사용할 때는?

  • 러닝 커브가 있기 때문에 개발 생산성을 고려해야 하는 것외의 큰 단점은 찾지 못했습니다. 매우큰 단점이긴 합니다.
  • 흔히 말하는 서버에 과부하가 생길 수 있다는 단점은 Next.js의 단점이 아니라 SSR의 단점입니다.
  • 프로젝트를 하면서 SSG, ISR, SSR, CSR에 대해 고민해보는 경험을 가지면 어떨까 합니다.
 
참고 : https://www.reason-to-code.com/blog/why-we-couldn't-feel-the-difference-of-nextjs/
 
현지의 생각정리
장점
  • 검색엔진최적화
  • 다양한 종류 렌더링 패턴을 제공
    • SSR
      • 장점: HTML을 렌더링하는데 시간을 쏟을 필요가 없다.
      • 단점: CSR은 보여지는 시간(Time To View)과 인터랙션이 이루어지는 시간(Time To Interaction)이 동일하지만, Server Side Rendering은 보여지는 시간과 인터랙션이 이루어지는 시간 사이에 공백이 생기게 된다.
      출처: https://www.reason-to-code.com/blog/why-we-couldn't-feel-the-difference-of-nextjs/
  • 코드분할 : 내가 원하는 페이지에서 원하는 자바스크립트와 라이브러리를 렌더링 하는것
      • 모든 번들이 하나로 묶이지 않고, 각각 나뉘어 좀 더 효율적으로 자바스크립트 로딩 시간을 개선할 수 있다.
 
단점
  • 학습 곡선
  • SSR의 단점으로 서버가 느리면 웹사이트가 기하급수적으로 느려진다. 서버부하가 CSR에 비해 많은편이다.
  • WebSocket, WebRTC 같은 기능을 이용해야한다면 직접 Nodejs + express 서버를 하나 만드는게 더 낫다..?
    • 출처: https://codingapple.com/unit/nextjs-0-ot/
결론
넥스트는 성능 최적화와 다양한 렌더링 패턴을 제공해주는것이 큰 장점인것 같습니다. 어떤 웹사이트를 구상하는지에 따라서 넥스트를 사용하는것을 도입하는게 좋을 것 같다는 생각이 들었습니다.
학습적인 측면에서는 다양한 렌더링 패턴을 제공하니깐 렌더링 패턴에 대해서 고민을 해보는 기회가 생길것 같다는 생각이 들었습니다.