React 실무 가이드 · React는 무엇을 해결했나

이 파트에서 다루는 내용

DOM 직접 조작의 한계선언형 UI가상 DOM의 실제 의미SPA와 선택 기준

문제는 화면 그리기가 아니라 상태와 화면을 맞추는 일이었습니다

예전 방식에서는 데이터가 바뀔 때마다 어떤 요소를 어떻게 바꿀지 직접 지시했습니다. 값을 읽어 텍스트를 교체하고, 클래스를 붙였다 떼고, 목록에 요소를 추가하거나 지웠습니다.

기능이 적을 때는 문제가 없습니다. 그런데 상태가 늘고 화면이 복잡해지면 '지금 화면이 어떤 상태인지'를 코드만 보고 알 수 없게 됩니다. 어떤 순서로 이벤트가 발생했는지에 따라 결과가 달라지기 때문입니다.

React의 출발점은 이 지점입니다. 화면을 바꾸는 절차를 쓰는 대신, 상태가 이러이러할 때 화면은 이렇게 생겼다고 선언하고 나머지는 React가 맞추게 합니다.

명령형

이전 방식

무엇을 어떻게 바꿀지 단계별로 지시합니다. 요소를 찾아 값을 넣고 클래스를 조작합니다. 상태와 화면이 어긋나면 원인을 추적하기 어렵습니다.

선언형

React 방식

상태에 따른 결과 화면을 정의합니다. 상태가 바뀌면 React가 이전 결과와 비교해 필요한 부분만 실제 화면에 반영합니다.

핵심 문장

React에서 화면은 상태의 함수입니다. 같은 상태면 같은 화면이 나옵니다. 이 규칙 덕분에 화면이 이상할 때 DOM이 아니라 상태를 먼저 의심하면 됩니다.

가상 DOM은 '빠르다'는 뜻이 아닙니다

가상 DOM을 성능 최적화 기술로 설명하는 자료가 많지만 정확하지 않습니다. 손으로 최소한의 DOM만 골라 바꾸는 코드가 더 빠릅니다.

가상 DOM의 실제 가치는 예측 가능성입니다. 개발자가 매번 '무엇이 달라졌는지' 계산해 최소 변경을 찾는 대신, 전체 결과를 다시 만들어 내면 React가 차이를 계산해 적용합니다.

즉 성능을 얻는 기술이 아니라, 성능을 크게 잃지 않으면서 선언형으로 작성할 수 있게 해 주는 장치입니다.

동작 순서

개념

상태가 바뀌면 컴포넌트 함수를 다시 실행합니다
그 결과로 새 화면 구조를 만듭니다
이전 구조와 비교해 달라진 부분을 찾습니다
달라진 부분만 실제 DOM에 반영합니다

오해 주의

자주 하는 착각

가상 DOM이 있어서 무조건 빠른 것은 아닙니다
불필요한 재실행이 많으면 여전히 느려집니다
성능 문제는 대부분 렌더링 범위 설계에서 옵니다

컴포넌트는 화면을 나누는 단위입니다

React는 화면을 컴포넌트라는 조각으로 나눕니다. 각 컴포넌트는 자신에게 필요한 데이터를 받아 자기 부분만 그립니다.

나누는 기준은 파일 크기가 아니라 책임입니다. 한 컴포넌트가 여러 관심사를 갖게 되면 재사용도 테스트도 어려워집니다.

가장 단순한 컴포넌트jsx

// 컴포넌트는 데이터를 받아 화면을 반환하는 함수입니다
function OrderStatusBadge({ status }) {
  if (status === "PAID") {
    return <span className="badge mint">결제 완료</span>;
  }
  if (status === "CANCELED") {
    return <span className="badge red">취소됨</span>;
  }
  return <span className="badge">{status}</span>;
}

// 사용하는 쪽
function OrderRow({ order }) {
  return (
    <div className="order-row">
      <span>{order.id}</span>
      <OrderStatusBadge status={order.status} />
    </div>
  );
}

컴포넌트 이름은 반드시 대문자로 시작합니다. 소문자로 시작하면 React가 HTML 태그로 인식해 화면에 아무것도 나오지 않습니다.

React는 라이브러리이지 프레임워크가 아닙니다

React 자체는 화면을 그리는 일만 담당합니다. 라우팅, 서버 데이터 처리, 폼 관리, 빌드 설정은 별도 도구를 골라 조합해야 합니다.

이 점이 자유이기도 하고 부담이기도 합니다. 팀이 조합을 정하지 않으면 프로젝트마다 구성이 달라지고, 새로 합류한 사람이 매번 새로 익혀야 합니다.

React가 하는 일

범위

컴포넌트 렌더링
상태 변화 반영
이벤트 처리 연결

따로 정해야 하는 것

조합

빌드 도구 (Vite 등)
라우팅
서버 데이터 관리
전역 상태 관리
스타일링 방식
테스트 도구

프레임워크 선택지

참고

Next.js처럼 이 조합을 미리 정해 둔 프레임워크도 있습니다. 서버 렌더링이 필요하면 검토 대상이지만, 이 코스는 React 자체에 집중합니다.

언제 React를 쓰고 언제 쓰지 않을지

적합한 경우

판단

사용자 상호작용이 많은 화면
같은 UI 패턴이 여러 곳에 반복되는 서비스
상태에 따라 화면이 자주 바뀌는 대시보드나 관리 도구
장기간 기능이 늘어날 예정인 프로젝트

과할 수 있는 경우

판단

내용 위주의 정적 페이지
화면 몇 개짜리 단순 소개 사이트
기존 서버 렌더링 페이지에 작은 기능만 추가할 때

실무 관점

도구 선택은 화면 복잡도와 유지 기간으로 판단합니다. 상태가 거의 없는 페이지에 React를 얹으면 빌드 구성과 의존성 관리 비용만 늘어납니다. 반대로 상호작용이 많은 화면을 직접 DOM 조작으로 만들면 시간이 지날수록 손대기 어려워집니다.

버전

버전별 참고

본문은 React 19 기준입니다. 18과 달라지는 부분은 아래에 정리합니다.

이 코스는 React 19 기준으로 작성했습니다. 2026년 7월 현재 최신은 19.2 계열입니다.
React 18과 19는 컴포넌트 작성 방식이 크게 다르지 않습니다. 기초 개념은 두 버전 모두 동일하게 적용됩니다.
인터넷 자료에는 클래스 컴포넌트 기반 예제가 아직 많습니다. 지금 새로 작성하는 코드는 함수 컴포넌트와 훅을 사용합니다.

체크