[React] 2. 리액트 등장 배경

Aug 18, 2025

Contents

1. 초창기 웹 구조와 한계 2. 서버 확장(스케일 업/스케일 아웃)과 한계 3. AJAX의 등장 4. HTTP 통신과 F5 5. AJAX와 비동기 통신 (CPU, HDD, RAM 비유)6. AJAX의 한계 7. React 엔진의 아이디어 8. 상태 관리와 불변성 9. Pub/Sub 10. SEO(Search Engine Optimization) 문제 11. SPA 구조 (동작 방식)12. Next.js의 등장 12. 미래 전망

1. 초창기 웹 구조와 한계

웹은 기본적으로 브라우저가 서버에 요청을 보내면, 서버가 HTML을 완성해서 돌려줌.

즉, 컨텐츠 타입이 text/html이고 서버에서 DB 데이터를 합쳐 완성된 HTML을 응답하는 구조였음.

문제점은 다음과 같았음:

서버가 HTML, CSS, JS, 이미지까지 모두 돌려줘야 해서 응답 용량이 매우 커짐.

데이터(JSON)만 주면 몇 백 바이트면 끝날 일을, HTML 전체를 주면 수십~수백 배 트래픽이 발생함.

따라서 같은 성능의 서버라도 처리할 수 있는 사용자가 훨씬 적었음.

페이스북처럼 사용자 수가 폭발적으로 많은 서비스에서는 서버비가 감당이 안 됨.

또한 DB 조회도 매번 발생해 서버 부하가 심해졌음.

2. 서버 확장(스케일 업/스케일 아웃)과 한계

단기적 해결책은 스케일 업(더 좋은 서버), 스케일 아웃(여러 대 서버 분산) 이었음.

하지만 장기적으로는 돈이 계속 들어가는 구조였음.

스타트업은 차라리 서버 늘리는 게 나았지만,

페이스북처럼 대규모 서비스는 장기적으로 소프트웨어적 해결이 필요했음.

3. AJAX의 등장

이 상황에서 나온 해법이 AJAX였음.

원래는 서버가 HTML을 만들 때 DB 데이터를 합쳐서 완성된 HTML을 돌려줬음. (= 서버사이드 렌더링)

AJAX는 이 과정을 바꿈:

처음 요청 때는 정적 HTML(껍데기) 만 받음.

브라우저에서 자바스크립트 코드가 추가로 AJAX 요청을 보냄.

서버는 JSON 같은 순수 데이터만 돌려줌.

브라우저의 JS가 DOM을 찾아 데이터를 끼워 넣음.

즉, AJAX의 핵심은 전체 리로드가 아니라 필요한 부분만 갱신(부분 리로드) 하는 것이었음.

4. HTTP 통신과 F5

HTTP 통신은 본질적으로 **F5(전체 새로고침)**였음.

즉, 요청이 발생하면 서버는 다시 HTML 전체를 돌려주고 브라우저는 페이지 전체를 다시 그림.

그래서 버튼 하나만 눌러도 페이지 전체를 새로고침하는 방식이었음.

반면 AJAX는 이와 달랐음:

전체를 새로고침(F5)하는 것이 아니라 일부분만 비동기로 갱신할 수 있었음.

이 차이가 AJAX의 진짜 장점이었음.

5. AJAX와 비동기 통신 (CPU, HDD, RAM 비유)

자바스크립트는 싱글 스레드 언어라서 통신 요청을 보내면 그 결과를 기다리느라 멈춰버렸음.

예시:

서버에 요청을 보냈는데 응답까지 2초가 걸린다고 하자.

이때 CPU는 직접 통신을 처리하지 않고, HDD나 RAM 같은 장치가 응답할 때까지 대기 상태가 됨.

그래서 사용자가 다른 버튼을 눌러도 반응이 없고, 브라우저가 다운된 것처럼 느껴졌음.

→ 이 문제를 해결한 것이 AJAX의 비동기 처리였음.

요청을 보내고 CPU는 기다리지 않고 자기 할 일을 계속함.

응답이 돌아오면 이벤트 루프가 이를 처리함.

따라서 AJAX의 진짜 핵심은 JSON 기반 부분 리로드였고,

비동기는 그것을 가능하게 하는 보조 개념이었음.

6. AJAX의 한계

하지만 AJAX가 만능은 아니었음.

처음엔 HTML+JSON 두 번 요청해야 해서 비효율적이었음.

부분 리로드가 가능해지면서 서버 부하는 줄었지만, 문제가 남았음.

문제: 프론트엔드 개발자의 부담이 폭증.

DOM을 직접 찾아 데이터를 넣는 코드를 계속 작성해야 했음.

화면에 바꿔야 할 부분이 많아질수록 코드가 복잡해졌음.

결국 프론트엔드 개발자가 힘들어지게 됨.

7. React 엔진의 아이디어

페이스북은 이 문제를 해결하기 위해 엔진을 만들었음.

원래는 개발자가 DOM을 직접 찾아 수정했지만,

이제는 상태(state) 와 DOM을 매핑해두고,

개발자가 상태만 바꾸면 엔진이 알아서 DOM을 갱신하도록 했음.

즉, “상태 기반 렌더링” 개념이 나옴.

개발자는 단순히


state.fruit = "apple"

이렇게만 하면, React 엔진이 알아서 DOM에서 해당 부분을 찾아 업데이트했음.

이것이 바로 React 엔진이었음.

8. 상태 관리와 불변성

React 엔진은 상태를 기준으로 변경 여부를 판단했음.

이전 상태(previous state)와 새로운 상태(next state)를 비교(diffing).

바뀐 부분만 다시 그렸음.

따라서 상태는 불변성(immutability) 을 가져야 했음.

원본 데이터를 직접 수정하면 비교 불가능.

항상 새로운 객체를 만들어 “전(before)”과 “후(after)”를 비교해야 했음.

이 원리가 리액트의 성능과 편리함의 핵심이었음.

9. Pub/Sub

싸이 공연에서 수만 명이 형광봉을 들고 있고, 방송실에서 신호를 주면 특정 구역의 색만 바뀜.

React의 상태 관리도 이와 같음: pub/sub 구조로 동작함.

상태(state)가 “발행자(publisher)” 역할을 하고,
DOM 요소들이 “구독자(subscriber)”가 됨.

상태가 바뀌면, 해당 상태를 구독하고 있던 DOM만 자동으로 갱신됨.

덕분에 전체를 다시 그리지 않고, 필요한 부분만 바꿀 수 있었음.

10. SEO(Search Engine Optimization) 문제

React는 SPA(Single Page Application) 방식이라 최초 HTML에는 껍데기만 있음.

데이터는 JS 실행 후 AJAX로 불러오기 때문에, 구글 로봇이 수집할 때 빈 HTML만 보게 됨 → 검색엔진 최적화(SEO)에 불리함.

구글 로봇의 동작 방식

전 세계 웹 페이지를 수집하며 헤더의 메타 태그를 기반으로 사이트 성격을 분석함.

또한 링크 구조를 수집하여 PageRank를 매김:

다른 사이트에서 내 URL을 참조하면 내 랭크가 올라감.
CNN 같은 권위 있는 사이트가 링크를 걸면 랭크가 더 크게 상승함.

SPA 구조는 최초 HTML이 비어 있어 로봇이 볼 때 무의미한 페이지로 인식됨 → 순위 하락, 노출 불가 현상 발생.

11. SPA 구조 (동작 방식)

SPA는 보통 index.html 하나만 내려옴.

<body> 안에는 루트 노드(#root/#app) 가 있음.

그다음 동작:

UI는 JS 함수(컴포넌트) 가 HTML(JSX → 가상 DOM) 을 return 하면서 그려짐.

라우팅은 실제 <a> 태그(F5)로 이동하지 않고, History API 기반 클라이언트 라우터로 루트 노드 내부만 교체함.

즉, 부분 리로드의 범위를 화면 전체(body 태그)로 크게 잡아 교체하는 것.

→ 사용자 눈에는 “완전한 페이지 전환”처럼 보이지만, 실제론 한 문서 안에서 루트만 교체됨.

요약: 함수 → (가상)HTML 반환 → 루트에 덮어쓰기를 반복하는 구조.

장점: 전환이 빠르고 깜빡임 없음.

단점: 최초 진입은 HTML/CSS/JS 다운로드 + 데이터 요청의 2단계 통신이 필요해 상대적으로 느림, SEO에도 불리함.

12. Next.js의 등장

(1) Next.js 이전 흐름

브라우저 → 프론트엔드 서버 요청

프론트 서버가 정적 자산(HTML/CSS/JS) 을 내려줌 → 브라우저가 앱 쉘을 다운로드함.

브라우저 JS가 백엔드 서버로 데이터 요청(AJAX/Fetch).

백엔드 서버가 JSON 응답.

이후부터는 브라우저 JS ↔ 백엔드 서버(JSON) 만 주고받으며 루트 내부를 교체함.

→ 구조적으로 최초에 자산 다운로드 + 데이터 요청 2번 통신이 필요해 초기 로딩이 느림.

→ SEO에도 불리함(초기 HTML에 콘텐츠 없음).

(2) Next.js 이후 흐름

브라우저 → 프론트엔드 서버(Next.js) 요청.

Next 서버가 즉시 백엔드 서버로 데이터 요청 → JSON 수신.

받은 JSON으로 프론트 서버 사이드 렌더링(SSR) 수행:

기존 CSR과 다름: 브라우저가 아닌 서버에서 렌더.

기존 백엔드 SSR(템플릿 엔진)과도 다름: Next는 리액트 컴포넌트 트리를 서버에서 실행해 완성 HTML을 만들어냄.

Next 서버가 완성된 HTML(메타 포함) 을 브라우저에 돌려줌.

사용자는 첫 화면부터 내용 있는 페이지를 보고,

구글 로봇도 완성된 HTML을 수집 가능 → SEO 강화.

브라우저는 HTML을 표시한 뒤 JS를 다운로드해 하이드레이션(hydration) 함.

하이드레이션: 기존 HTML에 이벤트와 상태를 붙여 상호작용 가능 상태로 만드는 과정.

이후부터는 SPA처럼 동작.

라우팅 시 F5 없이 루트 교체,

데이터는 JS ↔ 백엔드 JSON 통신,

필요 시 서버 컴포넌트/액션으로 부분 SSR도 가능.

12. 미래 전망

구글 로봇도 앞으로는 SPA 구조를 이해할 수 있도록 진화할 것.

따라서 현재 SEO 문제도 언젠가는 사라질 것임.

웹 브라우저 시대 자체가 언젠가 소멸하고, 음성·시각 기반 OS 시대로 넘어갈 것이라는 전망도 있었음.

하지만 시장과 생태계 때문에 리액트는 단기간에 사라지지 않을 것이고, 계속 발전할 것임.