도입 판단

React는 상태 변화가 화면 구조를 지배할 때 고른다

이름값으로 고르지 않고, 상태·반복 UI·DOM 갱신·데이터 흐름이 실제로 복잡한지부터 확인한다.

1

데이터가 바뀔 때 화면도 자주 바뀌는가?

버튼 상태, 필터, 입력값, 권한에 따라 UI가 계속 달라지면 선언적 모델이 유리하다.

상태 변화
2

반복되는 UI를 같은 규칙으로 묶을 수 있는가?

카드, 행, 입력 묶음이 반복되면 컴포넌트 경계가 유지보수 단위가 된다.

컴포넌트
3

여러 화면이 같은 상태를 읽고 바꾸는가?

부모에서 상태를 소유하고 자식에는 props와 이벤트를 내리는 흐름이 버그 추적을 쉽게 만든다.

단방향 흐름
4

정적 페이지나 단일 폼에 그치지는 않는가?

변화가 작고 재사용도 없다면 빌드 도구와 상태 계층이 오히려 비용이 될 수 있다.

되돌림 기준

React로 간다

  • 상태 변화가 화면 대부분을 바꾼다.
  • 같은 UI 규칙을 여러 화면에 재사용한다.
  • 변경 원인을 데이터 흐름으로 추적해야 한다.

부분 도입한다

  • 검색, 댓글, 필터처럼 일부 영역만 동적이다.
  • 기존 페이지 안에 작은 루트로 분리할 수 있다.
  • 전체 앱 전환보다 경계 설정이 먼저다.

단순 구현을 유지한다

  • 문서형 페이지처럼 DOM 변화가 거의 없다.
  • 상태가 한 폼 안에서 끝난다.
  • 컴포넌트 재사용보다 로딩 비용이 더 크다.

선언적 UI 최종 화면 상태를 선언하고 DOM 조작 절차는 숨긴다.

컴포넌트 화면 조각과 그 책임을 재사용 가능한 단위로 묶는다.

가상 DOM 변경 전후를 비교해 실제 DOM 반영 범위를 줄인다.

단방향 데이터 상태 소유자와 변경 경로를 고정해 추적성을 높인다.