상태(State)로 UI를 설계하는 사고방식

 

 

 

React는 화면을 그리는 기술이 아니다. 화면을 설명하는 함수다.

— 상태(State)로 UI를 설계하는 사고방식

이 글은 React 문법을 설명하지 않는다.
대신 “왜 React가 이렇게 생겼는가”부터 짚는다.
그래야 이후에 훅이든, 상태관리든, 성능이슈든 전부 같은 축에서 이해된다.

---

1️⃣ React의 출발점은 HTML도, JavaScript도 아니다

React의 출발 질문은 이거다.

“화면은 언제, 왜 바뀌는가?”

전통적인 웹에서는  jQuery나 순수 JavaScript로 DOM을 직접 조작

• DOM을 직접 찾고
• 이벤트가 발생하면
• 그 자리에서 화면을 수정했다

기존 웹 개발에서는하는 방식이 주류였습니다.
하지만 애플리케이션 규모가 커질수록 들이 심각해졌습니다.

React는 이런 문제를 해결하기 위해 등장한 기술로, 하게 해줍니다. 이로 인해 유지보수성과 확장성이 크게 향상되었습니다.

 

이 방식은 화면이 커질수록 사이드 이펙트가 폭증한다.

( DOM 조작의 복잡도, 데이터와 UI의 불일치 문제)
어디서 DOM을 바꿨는지 추적이 안 된다.

React는 이 질문을 이렇게 바꿨다.

“상태가 바뀌면, 화면은 자동으로 다시 계산되면 되지 않을까?”
( UI를 상태 기반으로 선언적으로 표현하는 방식으로 전환)

여기서 React의 모든 설계가 시작된다.

---

2️⃣ React의 핵심 공식 (이 한 줄로 끝난다)

// React 컴포넌트: 상태 입력받아 UI설명서 반환하는 함수
function Counter({ count }) {
  return <div>{count}</div>;
}

UI = f(state) // 외부 입력은 없는 상태 (아키텍처 철학)
UI 설명 = f(props, state) // 외부에서 받은 입력과 상태의 조합으로 설명(실무표준)
UI = f(type, props, children) // 실제 구현 인터페이스 React내부

• UI는 함수의 결과물
• 입력값은 state
• state가 바뀌면 UI는 다시 계산된다

React 컴포넌트는 정확히 이 역할이다.

“현재 상태(state)를 입력으로 받아
UI 설명서(UI tree)를 반환하는 함수”

 

JSX문법 : 문법설탕 , 태그처럼 보이지만 UI를 선언적으로, 직관적으로, HTML을 흉내낸 문법

function Hello() {
  return <h1>Hello</h1>;
}

// javascript 아님. 실제 변환 
function Hello() {
  return React.createElement(
    "h1",
    null,
    "Hello"
  );
} 
//type = "h1", props = null, children = ["Hello"]
<h1 className="title">Hello</h1>
React.createElement(
  "h1",
  { className: "title" },
  "Hello"
);

2)
return (
  <div>
    <h1>{title}</h1>
    <p>{desc}</p>
  </div>
);

return React.createElement(
  "div",
  null,
  React.createElement("h1", null, title),
  React.createElement("p", null, desc)
);
// 아래 소스보다 위 태그처럼 보이는게 훨씬 읽기 쉬움

<h1>Hello</h1>
// 위 문법은 아래 객체임 . 컴포넌트가 반환하는건 태그가 아닌 객체트리
{
  type: "h1",
  props: { children: "Hello" }
}

이 사고방식 하나로

• DOM 직접 조작 ❌ 아직 DOM ❌ 실행 결과 : Virtual DOM 트리
• 화면 동기화 코드 ❌ 아직 화면 ❌
• “여기 바꾸면 저기 깨짐” ❌

을 전부 제거한다.

“그럼 이 return은 언제 실행돼?”

아주 중요하다.

컴포넌트 함수는 언제 실행될까?

• 처음 마운트될 때
• state가 바뀔 때
• props가 바뀔 때
• 부모가 다시 렌더링될 때

---

3️⃣ 컴포넌트는 ‘화면 조각’이 아니다

많이들 컴포넌트를 이렇게 오해한다.

“컴포넌트 = 재사용 가능한 UI 블록”

반만 맞다.

React에서 컴포넌트는 정확히 말하면
👉 상태를 입력받아 UI를 반환하는 순수 함수에 가깝다

(jsx문법: JavaScript 안에 HTML을 작성하는 독특한 문법 지원)

function UserName({ user }) {
  return <span>{user.name}</span>;
}

• 외부 상태를 직접 건드리지 않고
• 같은 입력이면 항상 같은 결과를 낸다

그래서 테스트가 쉽고, 추론이 가능하다.

---

4️⃣ Virtual DOM은 목적이 아니라 결과다

리액트는 SPA(Single Page Application) 개발에 매우 적합하며,

가상 DOM(Virtual DOM) 기반으로 효율적인 화면 갱신을 제공...

Virtual DOM을 React의 핵심으로 오해하는 경우가 많다.
하지만 이건 부수 효과에 가깝다.

React의 진짜 목적은 이거다.

“상태 변경 → UI 재계산을 안전하게”

그 과정에서

• 이전 UI 트리
• 새로운 UI 트리

를 비교해야 했고,
그걸 효율적으로 하다 보니 Virtual DOM이 나온 것이다.

(실제 DOM 변경을 최소화하여 성능 향상)

즉,

• Virtual DOM ❌ 목적
• Virtual DOM ⭕ 해결책 중 하나

---

5️⃣ 왜 React는 ‘불편하게’ 보일까

초반에 React를 쓰면 이런 생각이 든다.

• 왜 setState를 써야 하지?
• 왜 바로 값을 바꾸면 안 되지?
• 왜 이렇게 간접적이야?

이건 React가 개발자를 못 믿어서가 아니다.
미래의 나를 믿지 않아서다.

코드가 커질수록

• 누가 언제 상태를 바꿨는지
• 그게 어떤 화면 영향을 주는지

통제하지 못하면, 프로젝트는 반드시 무너진다.

React는 그 붕괴 지점을 구조적으로 막는다.

---

 

 

React의 주요 구성 요소

1. 컴포넌트 (Component)

• 함수형 컴포넌트 중심 (과거에는 클래스형도 사용)
• props와 state로 상태 관리

2. 상태 관리 (State)

• useState, useReducer 훅 사용
• 전역 상태 관리는 Redux, Recoil, Zustand 등 활용

3. 이벤트 처리

• JSX 문법으로 DOM 이벤트 처리 (ex. onClick={handleClick})

4. 라우팅 처리

• React Router로 SPA 환경에서 다중 페이지 구성 가능

---

React의 장점과 단점

장점	단점
컴포넌트 재사용으로 생산성 향상	초기 설정이 복잡할 수 있음
가상 DOM으로 효율적인 렌더링	상태 관리 복잡도 증가 가능
풍부한 커뮤니티와 생태계	JSX 문법에 대한 거부감 있을 수 있음
빠른 학습 속도	렌더링 최적화가 필요한 경우 직접 제어 필요

 

---

실무에서 React를 사용하는 이유

• 디자인 시스템과 UI 재사용성이 중요한 프로젝트
• SPA 구조의 대시보드, 관리자 페이지 개발
• React Native와 함께 모바일 앱 개발로 확장 가능
• 방대한 자료와 커뮤니티, 기업 채택률이 높은 기술

---

6️⃣ 이 카테고리에서 다룰 이야기들

이 글은 입구다.
이후 글들은 전부 이 질문으로 수렴한다.

• 상태는 어디까지 내려가야 하는가
• 언제 상태를 쪼개고, 언제 합쳐야 하는가
• useEffect는 왜 위험한가
• 렌더링은 언제 발생하고, 언제 멈춰야 하는가
• 전역 상태는 왜 쉽게 지옥이 되는가

 

• 함수형 컴포넌트와 훅(Hooks) 이해(useState/useEffect)
• 상태 관리 패턴 (useState → Redux → Zustand 비교)
• 커스텀 훅(Custom Hook) 작성 실전
• React Router로 라우팅 구성하기
• 컴포넌트 스타일링 방식 (CSS-in-JS, Tailwind 등)
• 성능 최적화와 React.memo, useCallback 활용

React 문법이 아니라
React 사고방식을 계속 파고들 예정이다.

---

마무리

React는 “화면 기술”이 아니다.
변화하는 상태를 다루는 철학이다.

이걸 이해하면

• 문법이 바뀌어도 흔들리지 않고
• 라이브러리가 바뀌어도 본질은 남는다

다음 글에서는
👉 “렌더링은 정확히 언제 발생하는가”
를 아주 집요하게 해부해볼 예정이다.