React로 사고하기 & 트리로서 UI 이해하기
이번 글에서는 React의 기본 철학 중 하나인 React로 사고하기와 트리로서 UI 이해하기에 대해 다뤄보고자 한다.
UI를 어떻게 분해하고 데이터를 어떻게 흐르게 하며, 컴포넌트를 어떻게 구성해야 하는지를 단계적으로 보자.
1. React로 사고하기 - UI를 컴포넌트로 분해하는 사고법
React로 사고한다는 것은 단순히 useState, useEffect 같은 API를 아는 것이 아니라, UI를 컴포넌트 단위로 재구성하고 설계하는 습관을 의미한다.
1단계 : UI를 컴포넌트 계층으로 나누기
React 공식 문서에서는, UI를 먼저 정적인 버전으로 그려보고 이를 시각적으로 컴포넌트 단위로 나누는 것이 첫 단계라고 설명한다.
이때 중요한 기준은 다음과 같다.
- 한 개념이나 책임(Responsibility)을 가진 요소
- 재사용 가능성이 있는 요소
- 데이터 또는 상태를 독립적으로 받을 수 있는 요소
예시로 상품 리스트를 출력하는 UI를 보자.
<ProductList>
<ProductItem name="React 책" price={24000} />
<ProductItem name="Vue 책" price={21000} />
</ProductList>
여기서 ProductItem은 반복되는 단위 컴포넌트이며, ProductList는 반복을 관리하는 래퍼 컴포넌트가 된다.
2단계 : 데이터 흐름 설계
React의 가장 큰 철학 중 하나는 **단방향 데이터 흐름(one-way data flow)**이다. 상태(state)는 최상위 컴포넌트에서 관리하고, 필요에 따라 props로 하위 컴포넌트에 전달한다. 데이터 흐름 설계를 통한 장점은 다음과 같다.
- 예측 가능한 상태 흐름
- 디버깅이 쉬움
- 테스트 용이성
만약 형제 컴포넌트 간의 상태 공유가 필요하다면, 공통 부모 컴포넌트로 상태를 끌어올리는 **상태 끌어올리기(lifting state up)**가 필요하다.
2. 트리로서 UI 이해하기 - 구조를 시각화하기
React 앱은 결국 DOM의 구조처럼, 컴포넌트 트리로 구성되어 있다. 이 구조를 명확하게 이해하는 것이 유지보수와 확장에 중요하다.
UI = 트리
브라우저의 DOM이 트리 형태인 것처럼, React의 가상 DOM 역시 트리로 구성된다. 각 컴포넌트는 노드이며, 자식 컴포넌트를 가지는 부모 노드가 될 수 있다.
<App>
├── <Header />
├── <Main>
│ ├── <Sidebar />
│ └── <Content>
│ ├── <Post />
│ └── <Comments />
└── <Footer />
이 구조를 기반으로 다음과 같이 생각해볼 수 있다.
- 상태는 어느 컴포넌트에서 관리되어야 할지 판단
- 하위 컴포넌트로 props 전달 경로 예측
- React DevTools에서 디버깅 시 구조를 쉽게 파악
리렌더링 최적화와 트리 구조
트리 구조를 이해하면, 불필요한 리렌더링을 줄이기 위한 최적화 포인트도 명확해진다.
React.memo로 특정 서브트리의 리렌더링 방지- 상태를 너무 깊은 하위 컴포넌트에 전달하지 않도록 트리 설계
- 컴포넌트의 위치에 따라 리렌더 영향 범위를 예측 가능
3. 실전 적용 팁
설계 전에 트리를 그려보자
디자인 시안을 받고 바로 코드로 구현에 들어가기보다는, 다음처럼 트리 구조로 설계해보자.
DashboardPage
├── Sidebar (Navigation)
├── MainArea
│ ├── SummaryCards
│ ├── ChartSection
│ └── TableView
└── NotificationBar
이렇게 계층을 나눈 뒤, 어느 컴포넌트에 상태가 필요한지, 어떤 데이터를 내려줘야 하는지 판단하면 구현의 난이도가 줄어든다.
상태는 꼭 필요한 곳에만
모든 컴포넌트에 상태를 넣지 말자. 상태가 많을수록 컴포넌트는 복잡해지고, 리렌더링 비용도 커진다. 따라서 상태는 공유 범위가 좁을수록 좋다.
마무리
React를 단순히 코드만으로 이해하기보다 “구조와 흐름”을 디자인하는 관점으로 접근해 보자. 더 나은 설계와 협업을 위해서!