2013년 Facebook은 뉴스피드, 좋아요 버튼, 알림 카운터가 서로 연동되는 복잡한 UI를 jQuery로 유지하면서 심각한 문제를 겪었습니다. 상태 하나가 바뀌면 그 변경이 수십 곳의 DOM 조작 코드에 파급되었고, 어디서 버그가 생겼는지 추적하기가 점점 어려워졌습니다. React는 이 문제를 근본적으로 해결하기 위해 "UI를 상태의 함수로 정의한다"는 아이디어에서 출발했습니다.
명령형(Imperative) 방식은 화면을 어떻게 바꿀지 절차를 직접 기술합니다.
// Imperative: 절차를 직접 기술
const btn = document.getElementById('btn');
btn.textContent = isLoggedIn ? 'Logout' : 'Login';
btn.style.color = isLoggedIn ? 'red' : 'blue';
선언형(Declarative) 방식은 화면이 어떤 상태여야 하는지를 기술하고, 실제 DOM 조작은 라이브러리에 위임합니다.
// Declarative: 결과 상태를 기술
function Button({ isLoggedIn }) {
return (
<button style={{ color: isLoggedIn ? 'red' : 'blue' }}>
{isLoggedIn ? 'Logout' : 'Login'}
</button>
);
}
선언형 방식에서는 상태가 바뀌면 React가 이전 UI와 새 UI를 비교하여 최소한의 DOM만 갱신합니다. 개발자는 절차가 아닌 목표 상태만 관리하면 되므로 버그 추적이 훨씬 쉬워집니다.
React는 UI를 컴포넌트라는 독립적인 단위로 분리합니다. 각 컴포넌트는 자신의 UI와 상태를 캡슐화하며, 조합(Composition)을 통해 복잡한 화면을 구성합니다.
┌─────────────────────────────┐
│ App │
│ ┌──────────┐ ┌──────────┐ │
│ │ Header │ │ Feed │ │
│ └──────────┘ │ ┌──────┐ │ │
│ │ │ Card │ │ │
│ │ └──────┘ │ │
│ └──────────┘ │
└─────────────────────────────┘
컴포넌트를 독립 단위로 만들면 재사용, 테스트, 유지보수가 각각 독립적으로 가능합니다.
React는 프레임워크가 아니라 UI 라이브러리입니다. 라우팅, 상태 관리, 데이터 페칭 등은 React가 직접 제공하지 않으며, 각 프로젝트가 필요에 따라 선택합니다. 이는 특정 방식을 강제하지 않는다는 장점이지만, 초기 설계 결정이 많다는 단점이기도 합니다.
UI 라이브러리: 화면 렌더링에만 집중하고, 나머지 아키텍처 결정은 사용자에게 위임하는 도구.
Angular나 Vue가 "프레임워크로서 전체 구조를 제시"하는 반면, React는 "뷰 레이어만 담당하고 나머지는 생태계에 맡긴다"는 철학을 유지합니다.
React는 "Learn Once, Write Anywhere" 철학을 지향합니다. React DOM은 브라우저 환경을 담당하고, React Native는 동일한 컴포넌트 모델로 iOS·Android 네이티브 앱을 만듭니다. React의 핵심 개념(컴포넌트, 상태, 렌더링)을 한 번 익히면 다양한 플랫폼에 적용할 수 있습니다.
이 철학이 가능한 이유는 React 코어가 렌더러(renderer)와 분리되어 있기 때문입니다. React 코어는 컴포넌트 트리를 계산하고, 실제 출력(DOM, 네이티브 뷰 등)은 플랫폼별 렌더러가 담당합니다.
React의 핵심 철학은 세 가지로 요약됩니다.
이 철학을 이해하면 React의 API 설계와 제약이 왜 그렇게 되어 있는지 자연스럽게 납득이 됩니다.