2026년 4월 6일
왜 React는 함수형 컴포넌트를 중심으로 흘러갔을까
단지 코드가 간결해서 선택된 것일까
React를 배울 때 자주 접하는 설명이 있습니다.
요즘은 함수형 컴포넌트와 Hooks를 쓰는 게 기본입니다. 클래스형 컴포넌트는 예전 방식이에요.
왜 React는 클래스형 컴포넌트에서 함수형 컴포넌트 중심으로 전환되었을까요?
보통 다음과 같은 이유가 꼽힙니다.
- 코드가 더 간결함
- this 바인딩을 신경 쓰지 않아도 됨
- Hooks로 로직을 재사용하기 쉬움
이런 문법적 편리함 외에도, React 팀이 함수형 컴포넌트로 방향을 튼 데에는 렌더링 엔진과 상태 관리 구조상의 실질적인 이유가 있었습니다.
상태에 따라 다시 그려지는 UI의 특성
백엔드 시스템에서는 객체지향 모델이 자연스러운 경우가 많습니다. 데이터베이스 커넥션 풀, 캐시 매니저, 주문 도메인 엔티티처럼 내부 상태를 메모리에 오래 유지해야 하는 대상이 많기 때문입니다.
반면 프론트엔드 UI는 상태 변화에 반응하는 성격이 강합니다.
- 사용자가 버튼을 클릭하면 상태가 바뀝니다.
- 서버에서 새 데이터가 오면 상태가 바뀝니다.
- 상태가 바뀔 때마다 화면을 새로 계산해 보여주어야 합니다.
React의 기본 아이디어: UI = f(state)
UI는 상태(state)를 받아 화면 결과를 반환하는 계산식에 가깝습니다.따라서 상태가 바뀔 때마다 가볍게 다시 호출할 수 있는 함수 형태가 React의 렌더링 방식과 자연스럽게 맞아떨어집니다.
클래스형과 함수형의 상태 저장 구조 비교
이 둘의 차이는 상태를 어디에 보관하는지 비교해보면 분명해집니다.
- 클래스형 컴포넌트:
this.state와 메서드가 하나의 인스턴스 객체 안에 묶여 있습니다. - 함수형 컴포넌트: 상태는 함수 안에 있지 않고 React 런타임(Fiber 노드)이 따로 보관합니다. 함수는 렌더링 시점에 상태를 읽어 UI를 계산하고 반환하는 역할을 합니다.
Fast Refresh(핫 리로딩)의 작동 방식
상태와 로직이 분리된 구조의 효과는 개발 중 Fast Refresh(코드 수정 시 즉시 반영)를 사용할 때 체감할 수 있습니다.
개발 중 컴포넌트의 버튼 색상이나 텍스트를 수정했을 때 원하는 동작은 단순합니다.
입력해 둔 폼 데이터나 모달 상태는 유지하면서, 방금 수정한 UI 코드만 화면에 바로 반영되길 원합니다.
함수형 컴포넌트는 상태를 React 런타임이 독립적으로 들고 있기 때문에, 기존 상태를 보존한 채 수정한 새 함수를 같은 자리에서 다시 실행하면 됩니다.
정리하며
클래스 문법 자체가 문제였다기보다는, 상태 변화에 따라 화면을 반복해서 다시 그리는 React의 렌더링 모델에는 함수와 훅의 조합이 구조적으로 더 다루기 쉬웠습니다.
- 상태 보존(Fiber)과 UI 계산(함수)을 분리하면서
- 동시성 렌더링, Fast Refresh, 커스텀 훅 등의 기능을 훨씬 수월하게 구현할 수 있었습니다.
단순히 코드를 짧게 쓰는 것을 넘어, 렌더링 엔진과 개발 환경 전반의 효율을 높이기 위한 구조적인 선택이었습니다.
