왜 React SPA만으로는 부족한가 — NextJS가 프레임워크가 된 이유
React SPA의 성능·SEO 한계와 CSR/SSR/SSG 비교, NextJS가 프레임워크가 되는 이유를 정리
문제 제기: React는 UI 라이브러리이지, 애플리케이션 프레임워크가 아니다
React는 UI를 선언적으로 구성하는 데 최적화된 라이브러리다.
그러나 React SPA 구조는 다음과 같은 전제를 깔고 있다.
- 모든 렌더링은 브라우저에서 시작된다
- 서버는 정적 파일 제공자 혹은 API 서버 역할만 수행한다
- 초기 HTML은 거의 비어 있고, JS 실행 이후 화면이 완성된다
이 전제는 작은 앱에서는 문제가 되지 않는다.
하지만 프로덕션 규모로 커질수록 구조적 한계가 드러난다.
1. React SPA 구조의 본질적 한계
1) 초기 로딩 문제 (Time to First Content)
React SPA의 기본 흐름은 다음과 같다.
- 빈 HTML 수신
- JS 번들 다운로드
- React 실행
- 데이터 요청
- 화면 렌더링
즉, 사용자가 “의미 있는 화면”을 보기 전까지의 단계가 길다.
- 네트워크가 느릴수록 체감 성능 급락
- 모바일 환경에서 치명적
- Core Web Vitals 점수 악화
2) SEO의 구조적 불리함
검색 엔진은 HTML을 우선적으로 해석한다.
- SPA 초기 HTML: 콘텐츠 없음
- 실제 콘텐츠: JS 실행 이후 생성
결과:
- 크롤링 지연
- 메타데이터 관리 난이도 상승
- 콘텐츠 신뢰도 저하
“요즘 검색 엔진은 JS를 실행한다”는 말은 부분적으로만 맞다.
- 실행 비용은 여전히 크고
- 모든 봇이 동일하게 처리하지 않는다
3) 운영 관점의 문제
React SPA는 다음을 직접 결정해야 한다.
- 라우팅 방식
- 코드 스플리팅 전략
- 데이터 페칭 타이밍
- 캐싱 전략
- SEO 처리 방식
즉, 애플리케이션 아키텍처의 대부분을 직접 설계해야 한다.
2. 서버 렌더링이 필요한 이유 (CSR → SSR/SSG로의 전환)
핵심 질문
“왜 굳이 서버에서 렌더링해야 하는가?”
답
초기 HTML에 ‘의미 있는 콘텐츠’를 포함시키기 위해서다.
CSR (Client Side Rendering)
- 문제: 빈 화면 → JS 실행 → 렌더링
- 장점: 단순, 인터랙션 강함
- 단점: 초기 UX, SEO 취약
SSR (Server Side Rendering)
- 해결: 서버에서 HTML 생성 후 전달
- 장점:
- 빠른 첫 화면
- SEO 유리
- 단점:
- 요청마다 서버 부하
- 캐싱 전략 필요
SSG (Static Site Generation)
- 해결: 빌드 시 HTML 생성
- 장점:
- 가장 빠른 응답
- 서버 부하 없음
- 단점:
- 실시간 데이터에 부적합
핵심 정리
| 방식 | 해결하는 문제 | 대가 |
|---|---|---|
| CSR | 단순성 | 초기 UX, SEO |
| SSR | 초기 UX | 서버 비용 |
| SSG | 성능 | 데이터 유연성 |
👉 문제는 “어떤 방식을 언제 쓰느냐”다.
3. NextJS가 제공하는 핵심 추상화
NextJS는 단순히 “SSR을 지원하는 도구”가 아니다.
React 앱에 필요한 결정들을 프레임워크 차원에서 대신 내려준다.
1) 렌더링 전략의 추상화
NextJS 15 기준:
- 기본값: 서버 렌더링
- 선택지:
- 정적 생성
- 서버 렌더링
- 스트리밍
- 캐시 기반 재검증
개발자는 더 이상
“이 페이지를 어떻게 렌더링할까?”를 처음부터 고민하지 않는다.
2) 파일 기반 라우팅
- 라우트 = 파일 구조
- 코드와 URL 구조가 강하게 연결됨
- 유지보수 비용 감소
이는 개발 생산성 문제를 해결한다.
3) 서버와 클라이언트 경계의 명시화
NextJS는 다음 질문에 답을 강제한다.
- 이 코드는 서버에서 실행되는가?
- 브라우저에서 실행되는가?
- 상태가 필요한가?
이로 인해:
- 불필요한 클라이언트 JS 감소
- 성능 예측 가능성 증가
4) 풀스택 통합
- 서버 액션
- API 라우트
- 인증
- 파일 업로드
- 캐싱
모두 하나의 프로젝트, 하나의 사고 체계 안에서 해결된다.
4. 언제 NextJS는 과한 선택인가
NextJS는 만능이 아니다.
다음 경우에는 React 단독이 더 합리적이다.
1) 완전한 내부용 도구
- SEO 불필요
- 초기 로딩 중요도 낮음
- 빠른 프로토타이핑 목적
2) 극도로 단순한 SPA
- 페이지 수 적음
- 서버 로직 없음
- 배포·운영 단순성 우선
3) 백엔드와 완전히 분리된 구조가 필요한 경우
- 조직 구조상 FE/BE 완전 분리
- BFF 계층을 두기 어려운 상황
👉 핵심은 “문제 크기 대비 복잡도”다.
결론: NextJS는 React의 대체제가 아니라, 완성체다
- React는 UI 구성 도구
- NextJS는 애플리케이션을 운영 가능한 형태로 만드는 프레임워크
React SPA의 한계를 체감하는 순간, NextJS는 “선택지”가 아니라 자연스러운 다음 단계가 된다.