3편: React는 props를 통한 단방향 통신을 한다

React를 배우면 꼭 듣게 되는 말이 있다.

“React는 단방향 데이터 흐름(one-way data flow)을 가진다.”

이 말은 단순히 “부모 → 자식으로만 데이터가 간다”는 구조적 특징이 아니다.
이건 React가 복잡성을 통제하기 위해 세운 철학적 규칙이며,
“예측 가능한 UI”를 보장하는 가장 근본적인 원리다.

React 공식 문서(react.dev)
“Data flows down in React. A parent passes data to its child via props.”

Facebook Engineering Blog (2014)
“We wanted a single, predictable direction of data flow.”

즉, 이 규칙은 누군가의 취향이 아니라,
React의 선언적 철학을 완성시키는 필연적 구조다.

📖 참고

• react.dev — Passing Data Deeply with Context
• Facebook Engineering Blog (2014)

---

🤔 “단방향”이 왜 필요한가?

그런데 이 말을 처음 들으면 의문이 생긴다.

“굳이 왜 한쪽 방향으로만 흘러야 하지?”
“양방향으로 하면 더 편하지 않나?”

실제로 Vue나 Angular는 v-model처럼 양방향 바인딩(two-way binding) 을 지원한다.
입력 값이 바뀌면 즉시 상태가 바뀌고, 상태가 바뀌면 다시 입력이 바뀐다.
겉보기엔 훨씬 자연스럽고 편하다.

하지만 React는 정반대의 길을 택했다.
React는 왜 이렇게 “답답한 길” 을 고집했을까?

그 이유는 복잡한 UI 상태가 서로 얽힐 때,
‘누가 무엇을 바꿨는가’를 추적하기 어려워지기 때문이다.

📖 참고

• react.dev — Thinking in React

---

📺 방송국과 TV의 관계로 생각해보자

React의 데이터 흐름은 ‘방송국과 TV’ 관계에 가깝다.

• 방송국(Parent)은 신호를 보낸다.
• TV(Child)는 그 신호를 수신해 화면(UI)을 보여준다.
• TV는 방송 내용을 바꿀 수 없다.
  다만 리모컨을 통해 의견(이벤트)을 방송국으로 전달할 뿐이다.
  

이게 바로 React의 통신 구조다.
데이터는 부모 → 자식으로만 흐르고,
자식은 오직 이벤트로 부모에게 요청할 수 있다.

즉, React의 단방향 통신은

“데이터는 한 방향으로만 흐른다. 예측 가능성을 위해.”
“모든 변화의 근원은 부모(State)에게 있다”는 철학적 약속이다.

그리고 이 약속 덕분에 React는 예측 가능한 UI를 만들 수 있다.

📖 참고

• react.dev — Describing the UI
• react.dev — Updating Objects in State

---

💻 코드로 비교하기

❌ 양방향 바인딩 (명령형)

<!-- Vue 예시 -->
<template>
  <input v-model="name" />
  <p>{{ name }}</p>
</template>

<script>
export default {
  data() {
    return { name: '' };
  },
};
</script>

• input의 변화가 즉시 name을 수정하고,
  name의 변화가 다시 input을 수정한다.
• 데이터와 UI가 서로 얽혀 있다.
• 편리하지만, 상태 변경의 출처를 추적하기 어렵다.

---

✅ 단방향 흐름 (React 선언적)

function Parent() {
  const [name, setName] = useState('');

  return (
    <>
      <Child value={name} onChange={setName} />
      <p>{name}</p>
    </>
  );
}

function Child({ value, onChange }) {
  return <input value={value} onChange={(e) => onChange(e.target.value)} />;
}

• Parent는 상태의 단일 출처(single source of truth)
• Child는 오직 “표현(render)”만 담당
• 이벤트만 상위로 전달되고, 데이터의 진실은 항상 부모에 있다

[ Parent State ]
     ↓ props
   [ Child View ]
     ↑ event
     (상태 요청)

📖 참고

• react.dev — Passing Props to a Component
• react.dev — Keeping Components Pure

---

🧩 React가 이 구조를 고집한 이유

React의 창시자 Jordan Walke는 2013년 발표에서 이렇게 말했다.

“We realized the DOM was a poor source of truth.
We needed a single direction of data flow.”
— Jordan Walke, React Conf 2013

당시 Facebook Ads 팀은 양방향 데이터 갱신 지옥을 겪고 있었다.
수백 개의 UI 조각이 서로 상태를 참조하고 변경하면서

“한쪽을 고치면 다른 쪽이 깨지는” 연쇄 문제가 발생한 것이다.

그래서 React는
“상태의 진실은 오직 한 곳에, 데이터는 한 방향으로만 흐른다” 는 원칙을 세웠다.
이 철학이 바로 Virtual DOM 과
UI = f(state) 라는 개념의 토대가 되었다.

📖 참고

• Jordan Walke — React Conf 2013
• Facebook Engineering Blog (2014)
• react.dev — Referencing Values with Refs (UI 업데이트 방식 섹션)

---

🧠 원리 모델: Action / Data / Calculation

React의 단방향 통신은 아래 세 단계로 정리된다.

구분	설명	React 대응
Action	사용자의 입력, 상호작용	onClick, onChange
Data	상태(State)로 저장된 진실	useState, useReducer
Calculation	상태를 기반으로 계산된 결과	JSX (UI = f(state))

즉, UI는 계산 결과이며, 상태는 원인이다.
React는 UI를 명령하지 않고, 상태를 선언한다.

// Action: 사용자의 클릭
// Data: count 상태
// Calculation: count에 따른 UI
function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      {count}번 클릭됨
    </button>
  );
}

➡️ 데이터 흐름이 단방향이므로,
UI는 항상 상태에 의해 예측 가능하게 계산된다.

📖 참고

• react.dev — Thinking in React
• react.dev — Managing State

---

🧩 실무에서의 가치

React의 단방향 통신은 단순한 기술 규칙이 아니라,
팀 협업과 유지보수성의 철학적 기반이다.

1. 🧩 예측 가능성 (Predictability)

   • 데이터는 “위에서 아래로” 만 흘러간다.
   • 따라서 “이 값이 왜 이렇게 됐지?”라는 의문이 생기면,
     항상 부모 → 조상으로 거슬러 올라가면 답을 찾을 수 있다.

2. 🪄 디버깅 용이성 (Debuggability)

   • 상태 변경은 오직 하나의 방향과 함수로만 일어난다.
   • Redux, Zustand, Recoil 등 모든 상태 관리 도구가
     이 철학을 그대로 계승하고 있다.

3. 🔁 재사용성과 확장성

   • 자식 컴포넌트는 오직 props로만 통신하므로, 외부 의존성이 없고 독립적 재사용이 가능하다.

   • 물론, 이 철학을 엄격히 고수하면 최상위 상태를 아주 깊은 자식에게 전달할 때 props를 계속 넘겨줘야 하는 Prop Drilling 현상이 발생한다.

   • React는 이 문제조차 단방향 철학을 유지하면서 해결하기 위해, 데이터를 필요한 곳으로 '순간이동' 시켜주는 Context API 같은 확장 기능을 제공한다. (전역 상태 관리 라이브러리들도 이 철학을 따른다.)
     

4. 🤝 협업 효율성

   • “상태는 부모가 관리하고, 자식은 표현한다”는 규칙이 팀 전체의 일관된 통신 패턴을 만든다.
   • 신입 개발자도 “데이터는 위에서 온다”는 하나의 원칙만 익히면 된다.
     

📖 참고

• react.dev — Sharing State Between Components
• react.dev — Passing Data Deeply with Context

---

🧩 명령형과 선언적의 통합 관점

2편에서 다뤘던 “선언적” 개념과 연결하면 이렇게 요약할 수 있다:

관점	명령형 (Imperative)	선언적 (Declarative)
데이터 흐름	상호(양방향)	단방향 (Top → Down)
역할 분리	상태와 UI 뒤섞임	상태는 부모, UI는 자식
복잡성 증가 시	예측 어려움	흐름이 일정, 추적 용이
사고 모델	“어떻게 바꿀까”	“무엇이 되어야 할까”

React의 단방향 통신은 곧 선언적 철학의 연장선이다.
“UI를 명령하지 않는다”는 선언적 사고는
“데이터를 한 방향으로만 흐르게 한다”는 구조로 완성된다.

📖 참고

• react.dev — Describing the UI
• react.dev — Keeping Components Pure

---

🚀 결론 — “단방향 통신은 철학이다”

React의 단방향 통신은 단순한 기술적 제약이 아니다.

그것은

“변화는 통제되어야 한다”,
“상태의 진실은 하나여야 한다”
는 React의 철학적 선언이다.

양방향 바인딩은 편리하지만,
시간이 지날수록 시스템은 예측 불가능한 혼란을 만든다.
React는 그 반대의 길을 택했다

명시적이고, 추적 가능하며, 계산 가능한 데이터 흐름.

이 단방향 통신 구조 덕분에,
React는 지금까지도 “예측 가능한 UI의 표준” 으로 자리 잡았다.

📖 참고

• react.dev — Thinking in React
• Jordan Walke — React Conf 2013
• Facebook Engineering Blog (2014)