React의 등장은 왜 필요했나

이 문서의 출발점

백엔드에서 일할 때는 보통 상태 변화가 “요청 단위”로 깔끔하게 구분됩니다.
프론트는 이 방식만으로는 충분하지 않았고, React는 거기서 생긴 공백을 메우기 위해 등장했습니다.

React 이전의 전형적인 프론트 개발은 대체로 다음을 반복합니다.

• DOM을 직접 찾고 조작한다.
• 특정 이벤트 후 언제 어떻게 다시 그려야 하는지를 사람이 직접 판단한다.
• 이전 렌더 결과와 새 렌더 결과의 중복 계산을 중복해서 수행한다.

즉, UI가 실제 상태 모델이 아니라 “수동 갱신 스크립트”로 운영되었습니다.

왜 React가 필요한가: 철학의 전환

React가 내놓은 핵심 전환은 기능의 화려함보다 운영의 안정성입니다.

1. 상태를 먼저 모델링한다

   • “무엇을 그릴지”보다 “현재 상태가 무엇인지”를 우선한다.
   • 상태 변화는 이벤트를 기록하듯 다루고, 화면은 상태의 파생물로 본다.

2. DOM을 직접 쓰지 않고 결과를 선언한다

   • 직접 조작의 반복을 줄이고, 결과를 기술하면 프레임워크가 반영 시점과 방식(렌더/커밋)을 정리한다.

3. 동기화의 책임을 분산한다

   • 화면 일치성의 책임이 컴포넌트 작성자 한 사람의 즉흥적 계산에서 벗어나 프레임워크가 제공하는 파이프라인으로 이동한다.

이 변화의 본질은 “빠른 코드”가 아니라 “헛도는 상태 갱신”을 줄이려는 시도였습니다.

백엔드 사고와의 연결

백엔드 개발자가 React를 이해할 때 가장 쉬운 전환점은 다음입니다.

• API 응답을 정답으로 두는 대신, 프론트에서는 상태가 계속해서 정합성 검증을 받는다는 점
• “요청 하나 → 즉시 응답 하나”가 아니라 “상태 변화 여러 번 → 최종 렌더링 결과 하나”로 수렴한다는 점
• 오래된 응답/이벤트가 최신 동작을 덮는 문제를 “예외 케이스”가 아니라 설계 원칙으로 처리해야 한다는 점

이 관점에서 React의 출현은 프론트엔드에서의 새로운 설계 언어를 만든 사건입니다.

React를 보면 UI를 상태와 데이터의 결과물로 보는 관점이 핵심입니다. 출처에서 강조하듯,

• 상태 기반 상호작용 컴포넌트: UI = f(state)
• 서버 데이터 기반 컴포넌트: UI = f(data)

실제로는 이 둘을 동시에 다루기 위해 UI = f(data, state)에 가까운 형태가 필요합니다.

이는 state만 놓고 설명하면 놓치는 구간(서버 데이터 전처리)과 data만 놓고 설명하면 놓치는 구간(클라이언트 즉시 반응)을 함께 품기 위한 표현입니다.

다음을 읽을 때 기억할 질문

• React의 변화는 문법 확장이 아니라 UI를 상태 기반으로 계산하는 설계 전환이라고 설명할 수 있는가?
• 상태 변화와 화면 반영 사이에 생기는 간극을 어디까지 프레임워크가 책임지고, 어디까지 팀이 모델링할지 명확히 구분했는가?

참고

• The Two Reacts

연결 포인트

다음 문서인 렌더링 계약에서는 React와 브라우저 사이의 시간 규칙을 더 구조적으로 봅니다.
그리고 웹/JavaScript 트랙에서 이 개념이 어떻게 이벤트·네트워크 타이밍과 맞물리는지도 이어서 확인합니다.