React가 컴포넌트로 프론트엔드 아키텍처를 재구성한 방법

React가 도착했을 때 무엇이 바뀌었나

React는 단순히 새로운 라이브러리를 소개한 것이 아니라, 팀들이 “프론트엔드 아키텍처”라 부르는 것의 의미를 바꿨습니다. 실무적으로 프론트엔드 아키텍처는 UI 코드베이스를 대규모로 이해가능하게 유지하는 일련의 결정입니다: UI를 어떻게 나누는지, 데이터가 어떻게 흐르는지, 상태는 어디에 저장되는지, 사이드 이펙트(데이터 패칭 등)를 어떻게 처리하는지, 그리고 결과를 어떻게 테스트 가능하고 팀 전체에 일관되게 유지하는지 같은 것들입니다.

한 문장으로 정리한 컴포넌트 사고

컴포넌트 사고는 UI의 각 조각을 렌더링을 소유하고 다른 단위들과 조합해 전체 페이지를 구성할 수 있는 작고 재사용 가능한 단위로 다루는 것입니다.

React가 촉진한 변화들

React가 널리 퍼지기 전에는 많은 프로젝트가 페이지와 DOM 조작 중심으로 조직되어 있었습니다: “이 요소를 찾아 텍스트를 바꿔라, 이 클래스를 토글해라” 같은 식이었죠. React는 팀들을 다른 기본값으로 밀어넣었습니다:

• 상태 중심 UI: 상태를 업데이트하면 UI가 그 결과로 갱신됩니다.
• 연결보다는 컴포지션: 서로 관련 없는 파일을 이어붙이는 대신 컴포넌트를 중첩하고 결합해서 화면을 구성합니다.
• 재사용을 1순위 목표로: 공유되는 UI 패턴은 복사된 마크업이 아니라 컴포넌트가 됩니다.

이 아이디어들은 일상의 작업을 바꿨습니다. 코드 리뷰는 "이 상태는 어디에 있어야 하나?"를 묻기 시작했고, 디자이너와 엔지니어는 공통의 컴포넌트 어휘로 정렬할 수 있게 되었으며 팀은 전체 페이지를 다시 작성하지 않고도 UI 빌딩 블록 라이브러리를 성장시킬 수 있었습니다.

React를 넘는 변화

팀이 나중에 다른 프레임워크로 옮기더라도 React가 만든 습관들은 남습니다: 컴포넌트 기반 아키텍처, 선언적 렌더링, 예측 가능한 데이터 흐름, 그리고 일회성 페이지 코드보다 재사용 가능한 디자인 시스템 컴포넌트를 선호하는 태도 등입니다. React는 이러한 패턴을 자연스럽게 만들었고, 그 영향은 넓은 프론트엔드 생태계에 퍼졌습니다.

React 이전: 페이지 중심 UI와 DOM-우선 코드

React 이전에는 많은 팀이 페이지 중심으로 인터페이스를 구축했습니다. 서버에서 렌더링되는 템플릿(PHP, Rails, Django, JSP 등)이 HTML을 생성하고, 그 위에 jQuery로 상호작용을 추가하는 방식이 일반적이었습니다.

전형적인 스택: 템플릿 + jQuery + 플러그인

페이지를 렌더링한 뒤 스크립트로 활성화(activate)했습니다: 날짜 선택기, 모달 플러그인, 폼 검증기, 캐러셀 등—각각 자신의 마크업 기대치와 이벤트 훅을 가졌습니다.

코드는 종종 DOM 노드를 찾아 핸들러를 붙이고 DOM을 변경하는 식이었고, 아무것도 망가지지 않기를 바라는 식이었습니다. UI가 커지면 진실의 원천(source of truth)은 조용히 DOM 자체가 되곤 했습니다.

동작이 계층에 걸쳐 흩어짐

UI 동작은 한 곳에 모여있지 않았습니다. 보통 다음으로 나뉘었습니다:

• 서버 뷰(조건부 렌더링, 부분 템플릿, 기능 플래그)
• HTML(data-* 속성, 인라인 핸들러, 숨겨진 필드)
• JavaScript(jQuery 셀렉터, 전역 상태, 플러그인 초기화)

예를 들어 결제 요약 위젯 하나가 서버에서 부분적으로 만들어지고, AJAX로 업데이트되고, 플러그인으로 일부를 제어하는 식으로 나뉠 수 있었습니다.

흔한 고통 포인트

이 접근법은 작은 개선에는 잘 작동했지만 반복적인 문제를 낳았습니다:

• UI 중복: 같은 “컴포넌트”가 여러 템플릿과 페이지에서 다시 구현됨
• 상태 불일치: 로딩 스피너, 비활성화된 버튼, 오류 메시지 등이 동기화되지 않음
• 취약한 DOM 코드: 사소한 마크업 변경으로 셀렉터와 이벤트 연결이 깨짐

초창기 MV* 프레임워크

Backbone, AngularJS, Ember 같은 프레임워크는 모델·뷰·라우팅으로 구조를 가져오려 했습니다—대부분 큰 개선이었지만, 많은 팀은 여전히 패턴을 섞어 쓰며 반복 가능한 단위로 UI를 구성할 더 단순한 방법에 대한 틈을 남겼습니다.

큰 아이디어: 상태의 함수로서의 UI

React의 가장 중요한 전환은 간단히 말하면 강력합니다: UI는 상태의 함수다. DOM을 "진실의 원천"으로 취급하고 수동으로 동기화하는 대신, 데이터를 진실의 원천으로 두고 UI를 그 결과로 취급합니다.

일상 앱에서 ‘상태’가 의미하는 것

상태는 화면이 의존하는 현재 데이터입니다: 메뉴가 열려 있는지, 폼에 입력된 텍스트, 리스트의 항목들, 선택된 필터 등입니다.

상태가 바뀌면 페이지를 뒤져 여러 DOM 노드를 업데이트할 필요가 없습니다. 상태를 업데이트하면 UI가 그에 맞춰 다시 렌더됩니다.

왜 수동 DOM 작업이 줄어드는가

전통적 DOM-우선 코드는 보통 흩어진 업데이트 로직을 만들었습니다:

• 체크박스 변경 → 라벨 업데이트
• 항목 추가 → 리스트와 빈 상태 메시지 업데이트
• 폼 제출 → 버튼 비활성화, 스피너 표시, 오류 처리

React 모델에서는 이런 업데이트들이 렌더 출력의 조건이 됩니다. 화면은 주어진 상태에서 무엇이 보여져야 하는지에 대한 읽기 쉬운 설명이 됩니다.

작은 예시

function ShoppingList() {
  const [items, setItems] = useState([]);
  const [text, setText] = useState("");

  const add = () => setItems([...items, text.trim()]).then(() => setText(""));

  return (
    <section>
      <form onSubmit={(e) => { e.preventDefault(); add(); }}>
        <input value={text} onChange={(e) => setText(e.target.value)} />
        <button disabled={!text.trim()}>Add</button>
      </form>

      {items.length === 0 ? <p>No items yet.</p> : (
        <ul>{items.map((x, i) => <li key={i}>{x}</li>)}</ul>
      )}
    </section>
  );
}

빈 메시지, 버튼의 disabled 상태, 리스트 내용이 모두 items와 text에서 파생된다는 점을 주목하세요. 이것이 아키텍처적 이득입니다: 데이터 구조와 UI 구조가 정렬되어 화면을 이해하고 테스트하며 확장하기 쉬워집니다.

컴포넌트: 새로운 빌딩 블록

React는 “컴포넌트”를 기본 UI 작업 단위로 만들었습니다: 명확한 인터페이스 뒤에 마크업, 동작, 스타일링 훅을 묶은 작고 재사용 가능한 조각입니다.

HTML 템플릿, 이벤트 리스너, CSS 셀렉터를 관련 없는 파일에 흩어놓는 대신, 컴포넌트는 이동하는 부분들을 가깝게 유지합니다. 모든 것을 한 파일에 넣어야 한다는 의미는 아니지만, 코드는 사용자가 보고 상호작용하는 것을 중심으로 조직됩니다.

컴포넌트가 실제로 의미하는 것

실무적 관점에서 컴포넌트는 보통 다음을 포함합니다:

• 구조(무엇을 렌더링하는가)
• 상호작용(핸들러, 상태, 이펙트)
• 스타일링 훅(클래스 이름, 변형, 토큰)

중요한 전환은 “이 div를 업데이트하라”는 사고에서 “이 상태에서 버튼을 비활성화된 상태로 렌더하라”는 사고로 바뀐다는 점입니다.

캡슐화 = 유지보수 용이성과 명확한 소유권

컴포넌트가 적은 수의 props(입력)와 이벤트/콜백(출력)을 노출하면 내부를 바꿔도 앱의 다른 부분을 망가뜨리지 않고 개선할 수 있습니다. 팀은 특정 컴포넌트나 폴더(예: "checkout UI")를 소유하고 자신 있게 개선할 수 있습니다.

캡슐화는 우발적 결합을 줄입니다: 전역 셀렉터가 줄고, 크로스-파일 사이드 이펙트가 줄며, "왜 이 클릭 핸들러가 작동을 멈췄지?" 같은 놀람이 줄어듭니다.

컴포넌트는 제품 개념에 대응한다

컴포넌트가 주요 빌딩 블록이 되자 코드가 제품을 그대로 반영하기 시작했습니다:

• Button(primary/secondary, loading, icon)
• Modal(열기/닫기, 포커스 트랩, ESC 키)
• CheckoutForm(검증, 제출, 오류 상태)

이 매핑 덕분에 디자이너, PM, 엔지니어가 같은 "사물"에 대해 이야기하기 쉬워졌습니다.

파일 구조에 미친 영향

컴포넌트 사고는 많은 코드베이스를 기능 또는 도메인 기반 조직(/checkout/components/CheckoutForm 등)과 공유 UI 라이브러리(/ui/Button) 쪽으로 밀었습니다. 기능이 확장될 때 페이지 전용 폴더보다 이 구조가 더 잘 확장되며, 나중에 디자인 시스템을 도입할 기반을 마련합니다.

선언적 렌더링과 JSX가 정착시킨 이유

React의 렌더링 스타일은 흔히 선언적이라고 불립니다. 즉, 주어진 상황에서 UI가 어떻게 보여야 하는지를 선언하면 React가 브라우저를 그 상태로 맞추는 방법을 알아서 처리한다는 뜻입니다.

“결과를 설명하고 단계는 쓰지 말라”

옛 DOM-우선 접근법에서는 단계별 지시를 작성했습니다:

• 요소를 찾아라
• 새 노드를 만들어라
• 텍스트를 설정하라
• 추가하라
• 나중에 업데이트하거나 제거하라

선언적 렌더링에서는 대신 결과를 표현합니다:

사용자가 로그인되어 있으면 이름을 보여주고, 아니면 "Sign in" 버튼을 보여라.

이 전환은 "UI 장부 관리"의 양을 줄여줍니다. 어떤 요소가 존재하는지, 무엇을 업데이트해야 하는지 계속 추적할 필요가 없고, 앱이 가질 수 있는 상태에 집중할 수 있습니다.

JSX가 정착에 기여한 이유

JSX는 UI 구조를 그 구조를 제어하는 로직과 가까이 쓰기 편하게 했습니다. 템플릿 파일과 로직 파일을 분리해 이리저리 오갈 필요 없이 관련 조각을 함께 둘 수 있습니다: 마크업 같은 구조, 조건, 작은 포맷 결정, 이벤트 핸들러를 한곳에 두는 것이죠.

이 근접성(co-location)은 React의 컴포넌트 모델이 실용적으로 느껴진 큰 이유입니다. 컴포넌트는 단순한 HTML 덩어나 JavaScript 번들이 아니라 UI 동작의 단위입니다.

“HTML과 JS를 섞는 것 아닌가요?”

JSX가 HTML과 JavaScript를 섞는다는 우려가 있습니다만, JSX는 실제로 HTML이 아니라 JavaScript 호출을 생성하는 문법입니다. 더 중요한 점은 React가 기술을 섞는 것이 아니라 함께 변하는 것들을 묶는 것입니다. 예: "검증에 실패할 때만 오류 메시지를 보여라" 같은 규칙이 논리와 UI 구조가 밀접하게 연결된 상황에서 한 곳에 있는 것이 여러 파일에 흩어져 있는 것보다 명확할 수 있습니다.

선언적 렌더링은 JSX에만 국한되지 않는다

JSX가 React를 접근하기 쉽게 했지만, 근본 개념은 JSX를 넘어 확장됩니다. JSX 없이 React를 쓸 수도 있고, 다른 프레임워크들도 다른 템플릿 문법으로 선언적 렌더링을 사용합니다. 지속적인 영향은 사고방식입니다: UI를 상태의 함수로 취급하고 프레임워크에 화면 동기화의 세부를 맡기세요.

리콘실리에이션과 가상 DOM(그리고 신화 없이)

React 이전의 흔한 버그 원인은 단순했습니다: 데이터는 변경됐지만 UI는 변경되지 않았다. 개발자는 새 데이터를 가져온 뒤 적절한 DOM 노드를 찾아 텍스트를 업데이트하고, 클래스를 토글하고, 요소를 추가/제거하며 모든 것을 일관되게 유지하려 애썼습니다. 시간이 지나며 "업데이트 로직"이 실제 UI보다 더 복잡해지는 경우도 많았습니다.

React의 큰 작업 흐름 전환은 브라우저에 페이지를 어떻게 변경할지 지시하지 않는다는 점입니다. 주어진 상태에서 UI가 어떻게 보여야 하는지를 기술하면 React가 실제 DOM을 일치시키기 위한 최소 변경을 계산합니다.

리콘실리에이션의 실제 의미

리콘실리에이션은 React가 지난 렌더 출력과 이번 렌더 출력을 비교하고 실제 DOM에 가장 작은 변경 집합만 적용하는 과정입니다.

중요한 부분은 React가 "가상 DOM"을 성능의 마법으로 사용하는 것이 아니라 예측 가능한 모델을 제공한다는 점입니다:

• 렌더 로직을 마치 UI를 처음부터 다시 그리는 것처럼 작성합니다.
• React는 사용자에게 전체 재생성 비용을 지우지 않으면서 DOM을 증분적으로 업데이트합니다.

이 예측 가능성은 개발자 워크플로를 개선합니다: 수동 DOM 업데이트가 줄고, 비일관 상태가 줄며, UI 업데이트가 앱 전반에서 동일한 규칙을 따릅니다.

키(key): 실용적 요점

리스트 렌더링 시 React는 "이전 항목"과 "새 항목"을 매칭할 안정적인 방법이 필요합니다. 그게 key입니다.

{todos.map(todo => (
  <TodoItem key={todo.id} todo={todo} />
))}

ID 같은 안정적이고 고유한 키를 사용하세요. 항목이 재정렬되거나 삽입/삭제될 수 있다면 배열 인덱스는 피해야 합니다—아니면 React가 잘못된 컴포넌트 인스턴스를 재사용해 입력값이 엉키는 등 놀라운 동작이 발생할 수 있습니다.