왜 React 인가 — 선언형 UI · Virtual DOM · 단방향 데이터 흐름

학습 개요

탄생 배경

쉬운 설명

복잡한 개념을 실생활 비유로 설명합니다.

“엑셀 스프레드시트”

A1 셀에 값을 넣으면 A1 을 참조하는 모든 셀이 자동으로 갱신됩니다. "어느 셀을 어떻게 다시 그려라" 라고 명령하지 않아도 됩니다. React 도 마찬가지입니다 — `setState` 가 A1 의 값을 바꾸는 행위, Virtual DOM diff 가 어떤 셀을 다시 칠해야 하는지 계산하는 엔진입니다.

핵심 개념

실생활 비유

명령형은 "프라이팬에 기름 두르고, 가스 켜고, 계란 깨서 풀고, 뒤집고…" 라고 매 단계를 지시하는 레시피입니다. 선언형은 "오믈렛 한 접시" 라고 주문하면 주방이 알아서 만드는 식당입니다.

기술적 의미

명령형 코드(jQuery) 는 DOM 의 "현재 상태" 를 매번 읽고 다음 상태로 옮기는 절차를 작성합니다. 선언형 코드(React) 는 "지금 state 가 X 라면 UI 는 Y 다" 라는 매핑만 적고, 어떤 DOM 노드를 추가/수정/삭제할지는 React 가 결정합니다.

같은 토글 UI — 두 패러다임으로

명령형 (jQuery 스타일)

DOM 을 직접 조회/수정
현재 상태를 DOM 에서 다시 읽어와야 함
같은 데이터를 쓰는 다른 UI 가 있다면 거기도 직접 갱신
관련 코드가 클릭 핸들러, 초기화, 갱신 함수에 흩어짐

1const btn = document.getElementById('btn');
2const menu = document.getElementById('menu');
3btn.addEventListener('click', () => {
4  const isOpen = menu.style.display !== 'none';
5  menu.style.display = isOpen ? 'none' : 'block';
6  btn.textContent = isOpen ? '열기' : '닫기';
7  // 같은 상태를 표시하는 다른 영역이 있다면 여기서도 갱신해야 함
8});

선언형 (React)

state 라는 단일 진실원
현재 상태에서 UI 를 도출(UI = f(state))
같은 state 를 쓰는 모든 UI 가 자동으로 일관됨
동일 입력 → 동일 출력 (예측 가능성)

1function Menu() {
2  const [isOpen, setIsOpen] = useState(false);
3  return (
4    <>
5      <button onClick={() => setIsOpen(o => !o)}>
6        {isOpen ? '닫기' : '열기'}
7      </button>
8      {isOpen && <nav>...</nav>}
9    </>
10  );
11}

핵심 공식 — UI = f(state)

같은 state 와 같은 props 가 들어가면 항상 같은 UI 가 나와야 합니다. 이 순수성(purity) 이 깨지면 React 의 모든 최적화(memoization, concurrent rendering, Strict Mode 의 이중 실행) 가 함께 무너집니다.

실무 적용

어떤 상황에서 사용하는가

회사 대시보드를 jQuery 로 운영 중. 한 화면에 같은 사용자 정보가 7 군데 표시되는데, 어떤 동작에서는 일부만 갱신되고 어떤 동작에서는 화면 새로고침이 필요해 버그 리포트가 끊이지 않는다.

어떻게 적용하는가

(1) 사용자 정보를 단일 React 상태(또는 Zustand/Tanstack Query) 로 끌어올린다. (2) 7 군데 표시 영역을 모두 같은 state 를 구독하는 컴포넌트로 바꾼다. (3) 갱신은 한 곳의 `setState` 만. (4) 표시되는 모양만 컴포넌트별로 다르게 — UI = f(state) 가 자동으로 일관성을 보장.

흔한 실수와 안티패턴

state 가 여러 컴포넌트에 분산되어 또다시 동기화 코드가 생기는 것 — Single Source of Truth 위반.
props drilling 을 피하려 Context 를 남용해 모든 자식이 매번 리렌더되는 것 — Context 분리가 필요.
컴포넌트가 props 가 아닌 외부 변수에 의존해 "같은 props 인데 다른 UI" 가 나오는 것 — 순수성 위반.
Virtual DOM 을 믿고 무한 리렌더를 방치 — 측정 후 `React.memo`/`useMemo` 로 좁은 범위에 한정해 적용.

흔한 오해

오해

"Virtual DOM 은 항상 실제 DOM 조작보다 빠르다."

교정

아니다. Virtual DOM 은 일관된 추상화를 위한 비용 있는 메커니즘이고, 단순한 업데이트는 직접 DOM 조작이 더 빠르다.

왜 중요

diff 자체에도 시간/메모리가 든다. React 의 진짜 이점은 *예측 가능한 선언형 모델 + 합리적 성능* 의 균형.

오해

"React 는 프레임워크다."

교정

React 자체는 UI 라이브러리. 라우팅·상태관리·데이터 패칭은 별도 선택이 필요.

왜 중요

Next.js · Remix · Tanstack Router 같은 프레임워크가 그 위에 올라가는 구조. "React 만 쓴다" 와 "Next 를 쓴다" 는 의사결정이 다름.

오해

"단방향 흐름이라 폼이 불편하다."

교정

제어 컴포넌트(Controlled) / 비제어(Uncontrolled) 둘 다 가능하고, React Hook Form 처럼 비제어 기반 라이브러리가 성능과 DX 를 모두 잡는다.

왜 중요

단방향은 "양방향 바인딩이 안 된다" 가 아니라 "변경 의도를 부모가 알 수 있게 통과시킨다" 는 규칙일 뿐.

면접 질문

중급토스카카오네이버당근

답변 방향 힌트

"풀려고 한 문제 → 푼 방식 → 그 방식이 만든 정신 모델" 순서로.

반드시 언급할 키워드

jQuery: 명령형 DOM 조작 → 상태/UI 동기화 코드 폭발
React: 선언형, UI = f(state) 로 한 곳에서 진실 관리
Virtual DOM 은 선언형을 실용적으로 만들기 위한 절충
단방향 데이터 흐름 → 디버깅·테스트 용이
컴포넌트 합성으로 재사용 단위가 함수가 됨

7년차 수준 모범 답변

jQuery 시대에는 같은 데이터가 화면 여러 곳에 표시될 때, 각 위치의 DOM 을 어느 시점에 어떻게 바꿀지를 개발자가 모두 추적해야 했습니다. 기능이 늘수록 상태와 DOM 동기화 코드가 폭증하고, 한 곳을 바꾸면 다른 곳이 깨지는 회귀가 일상이었죠. React 는 "현재 state 가 X 라면 UI 는 Y" 라는 함수형 매핑만 적게 하고, 어떤 DOM 노드를 만들고 지울지는 라이브러리가 결정하게 했습니다. 이를 실용적으로 만들기 위해 Virtual DOM 으로 변경 부분만 실제 DOM 에 패치하고, 데이터는 부모→자식 단방향으로만 흐르게 하여 추적 가능성을 높였습니다. 결과적으로 코드의 의미가 "절차" 에서 "선언" 으로 바뀌었고, 같은 입력은 같은 출력을 보장하는 순수성이 테스트·메모이제이션·동시성 렌더링 같은 후속 기능들의 토대가 되었습니다. 단순한 페이지에는 jQuery 가 여전히 빠르고 가볍지만, 여러 화면이 같은 상태를 공유하는 앱 규모로 가면 React 의 정신 모델이 이기는 게임이 됩니다.

예상 꼬리 질문

Virtual DOM 이 항상 더 빠르다고 말하기 어려운 이유는?
단방향 데이터 흐름의 단점이나 한계는 무엇인가요?

자기 점검

"UI = f(state)" 공식이 의미하는 것을 한 문장으로 설명하라.

기대 키워드

선언형state같은 입력같은 UI순수성

자주 하는 오해

단순히 "상태가 바뀌면 화면이 바뀐다" 로 끝내면 부족하다. "같은 state/props 에서는 항상 같은 UI 가 나와야 한다" 는 *결정성/순수성* 까지 들어가야 React 의 모든 최적화가 왜 가능한지 설명할 수 있다.

Virtual DOM 의 Render Phase 와 Commit Phase 가 다른 이유는?

기대 키워드

순수중단 가능동기DOM 패치effect

자주 하는 오해

두 단계를 나눈 것은 "성능" 이 아니라 "Concurrent 렌더링 안전성" 이 본질이다. Render 가 순수해야 React 가 중간에 폐기/재시도할 수 있다.

단방향 데이터 흐름이 디버깅을 쉽게 만드는 메커니즘을 설명하라.

기대 키워드

props downevents upSingle Source of Truth추적

자주 하는 오해

"코드가 적게 든다" 가 아니라 "값이 어디서 왔는지 항상 한 방향으로 거슬러 올라갈 수 있다" 가 핵심.

학습 개요

탄생 배경

쉬운 설명

핵심 개념

같은 토글 UI — 두 패러다임으로

실무 적용

흔한 오해

면접 질문

자기 점검

학습 자료