React · Node · Next.js 관계 정리 : ‘파일로 여는 웹’에서 ‘프로젝트를 실행하는 웹’으로

HTML/CSS/JS로 “파일을 열어보는 웹”은 이해가 됐는데, Node/React/Next로 넘어오면서 라우팅·빌드·배포 같은 단어가 한꺼번에 등장해 혼란이 생겼다. 이번 글의 목표는 “정의 암기”가 아니라 “관계 정리”다. Next.js를 중심에 두고, React/Node가 각각 무엇을 담당하는지(런타임/라이브러리/프레임워크), 어디에서 실행되는지(브라우저 안/밖), 그리고 그 결과로 렌더링 방식(SSR/CSR/SSG)과 SEO가 왜 연결되는지를 하나의 흐름으로 묶어본다.

---

1. 분류를 다시 잡기: 프레임워크 / 라이브러리 / 런타임

1-1. Next.jsㅡReact 기반 프레임워크

• React 기반의 웹 애플리케이션 프레임워크
• React로 만든 UI를 "프로덕션용 웹 애플리케이션" 형태로 운영하기 위해
  필요한 기능(라우팅, 렌더링 전략, 번들링, 최적화, 빌드/배포 등)을 묶어서 제공하는 프레임워크
• 보통 Node.js위에서 동작

1-2. ReactㅡUI를 만드는 라이브러리

• 화면(UI)를 만드는 라이브러리
• UI를 컴포넌트 단위로 쪼개서, 상태 변화에 따라 화면을 선언적으로 다시 그리게 해주는 프론트엔드 라이브러리
• '라이브러리'인 이유: 라우팅/데이터패칭/빌드 규칙 등을 강제하지 않고, 필요한 것들을 조합해서 
• 내가 호출해서 쓰는 도구 (주도권이 나에게 있음)

1-3. Node.jsㅡJS 런타임(실행 환경)

• 브라우저 밖에서 자바스크립트를 실행할 수 있게 해주는 자바스크립트 런타임 환경
• JS로 서버(웹 API), 배치 작업, CLI 도구, 실시간 서비스 등을 만들 수 있게 해준다.

더 간단하게:

• React는 화면.
• Node는 서버에서 JS를 돌리는 엔진.
• Next는 화면(React)를 서비스로 만드는 틀.

결론:
Node(실행기) 위에서 Next(틀)가 돌아가고, Next 안에서 React(UI)가 쓰인다.

---

2. 브라우저 안 vs 브라우저 밖

그럼 여기서 말하는 "브라우저 밖"이 뭔데? 그럼 브라우저의 "안"과 "밖"이 따로 있는가 에 대해.

2-1. 브라우저 안

• 브라우저 안에서 실행되는 JS
• 실행 주체: 웹 브라우저(Chrome, Safari 등)
• 목적: 웹페이지 UI 그리기/조작하기

즉, 브라우저 안 JS는 화면(HTML/CSS)과 사용자 상호작용을 다루기 위한 환경이다.

2-2. 브라우저 밖

• 내 PC 터미널/서버에서 실행되는 JS
• 실행 주체: Node.js 런타임
• 목적: 서버/파일/네트워크/프로세스 같은 운영체제 자원을 다루기

즉, 브라우저 밖 JS는 OS 위에서 백엔드/도구/자동화를 만들기 위한 환경이다.

 

2-3. React / Next.js / Node.js로 연결해서 보면

• React: 보통 “브라우저 안”에서 돌아가며 UI를 만든다.
• Next.js: “브라우저 안” + “브라우저 밖”을 동시에 쓴다.
  • 페이지를 서버에서 만들어 내려주면(SSR/SSG) 그 부분은 브라우저 밖(Node 환경)에서 실행될 수 있음
  • 이후 사용자 인터랙션은 브라우저 안에서 실행(하이드레이션/클라이언트 코드)
• Node.js: 원칙적으로 “브라우저 밖” 런타임이다.

---

3. Next.js의 렌더링 방식과 SEO

3-1. 렌더링 방식

화면(HTML)을 누가, 언제 만들어 주느냐
누가? 브라우저 vs 서버
언제? 요청 때마다 vs 미리

• CSR (Client-Side Rendering): 브라우저에서 JS로 렌더링(일반 SPA 느낌)
  • 브라우저에서 JS가 실행되며 화면이 만들어짐
  • 장점: 앱 같은 UX, 인터랙션 쉬움
  • 단점: 초기 로딩/SEO(검색 노출) 불리할 수 있음
  • 손님이 직접 조립
• SSR (Server-Side Rendering): 요청마다 서버에서 HTML 생성 → 초기 로딩/SEO 유리
  • 요청 시마다 서버에서 HTML을 만들어 내려줌
  • 장점: 초기 표시 빠름, SEO 유리
  • 단점: 서버 부하/캐싱 전략이 중요
  • 주문 들어올 때마다 가게가 즉석 조리
• SSG (Static Site Generation): 빌드 시 미리 HTML 생성 → 속도/캐시 유리
  • 빌드 시 HTML을 미리 생성해두고 CDN처럼 서빙
  • 장점: 매우 빠르고 저렴
  • 단점: 데이터가 자주 바뀌면 업데이트 전략 필요
  • 미리 만들어서 진열
• ISR (Incremental Static Regeneration): 정적 페이지를 일정 주기로/조건에 따라 재생성
  • “SSG + 주기적/조건부 재생성”
  • 장점: 정적의 성능 + 최신성 절충
  • 진열해두는데, 가끔 새 걸로 교체

 

3-2. SEO란,

• SEO(Search Engine Optimization): 검색 엔진 최적화
• 검색엔진이 내 페이지를 잘 이해하고, 검색 결과에서 더 잘 노출되도록 웹사이트를 정리·개선하는 작업
• 즉, 검색엔진이 내 페이지를 읽기 쉽게 만들고, 좋은 페이지라고 판단하게 만드는 것
• 검색엔진의 과정
  • 크롤링(Crawling): 링크를 따라다니며 페이지를 “수집”
  • 인덱싱(Indexing): 페이지 내용을 “이해하고 DB에 저장”
  • 랭킹(Ranking): 검색어에 대해 “어떤 페이지를 위에 보여줄지” 결정
• SEO는 이 3단계가 잘 되도록 도와주는 작업이다.

 

3-3. SEO 관점에서 CSR vs SSR

• CSR(브라우저가 JS로 화면 만듦)
  • 초기 HTML이 비어있거나 내용이 적고, JS 실행 후에야 내용이 채워진다.
    → 검색엔진 입장에서 “내용 파악이 어려운 상황”이 생길 수 있어 SEO가 불리할 가능성 존재
• SSR/SSG(서버가 HTML을 만들어서 바로 줌)
  • 처음부터 내용이 들어있는 HTML이 내려온다.
    → 검색엔진이 읽기 쉬워서 SEO에 유리한 경우가 다수

---

4. Next.js 라우팅 방식: App vs Pages

4-1. 라우팅이란?

• URL(주소)이 바뀌면 어떤 화면(페이지)을 보여줄지 연결하는 규칙
• Next.js는 이 라우팅을 만드는 방식이 2가지 있음: pages 방식 / app 방식

 

4-2. Pages Router (기존 방식)

• pages/ 폴더의 “파일”이 곧 URL이 되는 방식
• 핵심 규칙: pages/파일이름.js → /파일이름
• 예시
  • pages/index.js → /
  • pages/about.js → /about
  • pages/projects/index.js → /projects
  • pages/projects/[id].js → /projects/123
• 장점
  • 구조가 단순해서 초반 진입이 쉬움
  • 예전 강의/자료에 많이 나옴
• 단점(초보가 느끼는 지점)
  • 프로젝트가 커질수록 레이아웃/구조를 깔끔하게 나누는 게 번거로울 수 있음

 

4-3. App Router (최근 방식)

• app/ 폴더의 “폴더 경로 + page.js”가 곧 URL이 되는 방식
• 핵심 규칙: app/경로/page.js → /경로
• 예시
  • app/page.js → /
  • app/about/page.js → /about
  • app/projects/page.js → /projects
  • app/projects/[id]/page.js → /projects/123
• 장점
  • “앱 구조”처럼 폴더 단위로 정리하기 쉬움(레이아웃 등 구조화에 유리)
  • 최신 Next 문서/흐름에 가까움
• 단점(초보가 느끼는 지점)
  • Pages 방식만 보던 사람은 폴더 구조가 낯설 수 있음