NextJS를 전제로 다시 배우는 React

“컴포넌트 중심”에서 “실행 위치 중심” 사고로

이 글은 React를 처음 배우는 사람을 위한 설명이 아니다.
React를 알고 있지만, NextJS(App Router)를 쓰면서 기존 사고방식이 계속 어긋나는 개발자를 위한 정리다.

핵심 메시지는 하나다.

NextJS에서의 React는
“무엇을 렌더링하느냐”보다 “어디서 실행되느냐”가 먼저다.

---

1. 컴포넌트 분리 기준의 변화

기존 React 사고 vs NextJS 사고

구분	기존 React 사고	NextJS 사고
분리 기준	UI 역할	실행 위치
기본값	클라이언트 컴포넌트	서버 컴포넌트
상태 기준	거의 모든 컴포넌트	필요한 경우만
데이터 접근	클라이언트에서 fetch	서버에서 직접 접근

---

❌ 기존 React 사고

• 컴포넌트 = UI 단위
• 재사용을 위해 최대한 쪼갠다
• 상태와 로직을 컴포넌트에 자연스럽게 둔다

이 사고는 SPA에서는 합리적이었다.

---

✅ NextJS 사고

• 컴포넌트 = 실행 컨텍스트 단위
• 서버에서 끝낼 수 있으면 서버에서 끝낸다
• 클라이언트 컴포넌트는 “최후의 수단”

👉 질문이 바뀐다.

“이 컴포넌트가 UI를 가지는가?” ❌
“이 컴포넌트가 브라우저에서 실행될 이유가 있는가?” ⭕

---

2. 상태 관리의 역할 재정의

“상태는 기본값이 아니다”

❌ 기존 React SPA 패턴

• 데이터 = 상태
• 서버 데이터도 상태로 관리
• 전역 상태 관리 도입이 빠름

문제:

• 불필요한 hydration
• 상태 동기화 비용 증가
• 서버 캐싱과 충돌

---

✅ NextJS에서의 상태

상태는 오직 다음 경우에만 필요하다.

• 사용자 입력
• UI 토글
• 클라이언트 전용 인터랙션

서버에서 가져온 데이터는:

• 상태 ❌
• 렌더링 결과 ⭕

👉 서버 컴포넌트에서는
“상태 없는 React”가 기본 형태다.

---

3. useEffect의 재해석

“필수 훅”에서 “회피 대상”으로

❌ 기존 React 사고

• 데이터 페칭 = useEffect
• 컴포넌트 마운트 시 실행
• 거의 모든 비동기 로직에 사용

---

✅ NextJS 사고

서버 컴포넌트에서는 useEffect가 없다.

필요한 경우는 극히 제한적이다.

useEffect가 필요한 경우

• 브라우저 API 사용
• DOM 직접 접근
• 클라이언트 이벤트 후 처리

useEffect가 필요 없는 경우

• 데이터 페칭
• 초기 렌더링 로직
• 인증 정보 확인

👉 useEffect는
“서버에서 못 하는 일의 증거”에 가깝다.

---

4. SPA 사고방식이 NextJS에서 실패하는 지점

실패 패턴 1: 모든 페이지를 클라이언트 컴포넌트로 시작

• 'use client' 남발
• 서버 렌더링 이점 상실
• JS 번들 폭증

---

실패 패턴 2: 서버 데이터를 상태로 관리

• 서버 캐시 무력화
• 불필요한 리렌더링
• 데이터 일관성 문제

---

실패 패턴 3: 페이지 단위 사고 고수

• 레이아웃 중복
• 데이터 페칭 위치 혼란
• 라우팅과 UI 분리 실패

---

핵심 정리: 사고 전환 체크리스트

• 이 컴포넌트는 서버에서 끝낼 수 있는가?
• 상태가 정말 필요한가, 그냥 결과값이면 안 되는가?
• useEffect를 쓰는 이유가 “습관”은 아닌가?
• 이 로직은 UI 문제인가, 데이터 문제인가?

---

결론: NextJS는 React를 버리는 게 아니라, 완성시킨다

• React는 여전히 컴포넌트 기반 UI 라이브러리다
• NextJS는 그 컴포넌트들을
  서버와 클라이언트에 올바르게 배치하는 규칙을 제공한다

NextJS에서 React를 잘 쓴다는 것은
더 많은 코드를 작성하는 것이 아니라,
더 많은 코드를 “작성하지 않는 것”이다.

---

• 참고: Next.js 15 & React - 완벽 가이드