React 톺아보기 1편 - React는 왜 필요할까?

2025년 04월 24일

개발React

전문가를 위한 리액트 Fluent React 책과 각종 공식 문서를 참고하여 React 톺아보기 시리즈를 작성해보고자 합니다. 사실 프론트엔드 개발자라면 React를 사용해보지 않은 사람은 없을 것이라 생각합니다. 그러나 React에 대해 깊게 생각해본 적은 없는 것 같아 이 참에 정리해보려고 합니다. 늘 고쳐야지 하면서 결심하지만 개발자임에도 개념과 지식이 머릿속에 없으면 선뜻 활용하는 것을 어려워하는 성격이라 제대로 공부해보고자 합니다.

React의 필요성

React 이전에도 사실 웹 페이지는 있었고 많은 기술들이 있었습니다. 그러나 이전에는 정적 페이지(Static Page)가 많았고, 직접 사용자가 특정 작업을 하거나 입력을 할 때는 새로운 페이지를 불러오는 경우가 많았습니다. 그러나 최근 웹의 엄청난 발전으로 웹 안에서 사용자가 할 수 있는 것들이 무궁무진해졌습니다. 이러한 점에서 기존 방식은 속도와 성능 측면에서 분명한 한계를 가져왔습니다.

새 페이지가 렌더링되고 로딩될 때 까지 시간이 오래 걸렸고 보안적인 측면에서도 HTMLJavaScript를 모두 소독해야만 했습니다. (*책에서 사용자 입력 등의 데이터에서 문제가 될 만한 부분을 제거하는 작업을 소독이라고 일컫고 있습니다.)

이제는 앱에 가까워진 웹과 사용자의 눈높이를 충족시켜야하는 상황이 왔습니다. 화면 전환 없이 페이지가 바뀌고, 사용자 상호작용에 실시간으로 반응하며, 수많은 데이터를 다뤄야 하는 점입니다. 이와 더불어 사용자는 위와 같은 과정에서 오래 기다리는 것을 원하지 않는다는 점입니다.

따라서 위와 같은 문제를 해결하기 위해 React가 등장하게 되었습니다.

React 이전의 세계

1. HTML + JavaScript + JQuery

예전에는 HTML로 구조를 만들고, JQuery 같은 라이브러리로 직접 DOM 요소를 조작하는 방식이 많았습니다. 초기에는 나쁘지 않았으나, 규모가 커지면서 관리와 특히 추적에 있어서 굉장히 어려움을 겪게 됩니다.

2. MVC 프레임워크의 등장

Backbone.js, AngularJS 등의 프레임워크가 등장하면서 구조화된 개발이 가능해졌지만, 양방향 바인딩과 복잡한 상태 관리로 인해 다른 새로운 문제를 겪기도 했습니다. 복잡한 문법과 타입 안정성 부재 등 자바스크립트의 단점을 보오나하기 어려웠고 이것은 유지보수에 있어 심각한 단점으로 여겨졌습니다.

양방향 바인딩이란?

양방향 바인딩이란 뷰(화면)와 모델(데이터)이 서로 영향을 주고 받을 수 있으며, 둘 중 하나가 바뀌면 나머지 하나에도 자동으로 반영이 되는 방식을 말합니다. 흔히 양방향 호스라고 생각하면 이해하기 쉽습니다.

React의 등장

React는 위에서 나온 것들의 문제점들을 보완하고 더욱 발전시키며 등장하게 되었습니다. 특히 가장 핵심은 컴포넌트 기반의 개발과 가상 DOM입니다.

컴포넌트 기반 구조

사용자 인터페이스를 작성할 때 재사용 가능한 컴포넌트를 조합하는 방식입니다. 테스트와 유지보수도 간편하고 디자이너와 협업하기도 좋습니다. 특히 Angular가 지시자를 사용했다면, React는 JSX와 같이 훌씬 더 간단한 컴포넌트 모델을 도입하여 개발 경험을 향상 시켰습니다.

가상 DOM

React는 가상 DOM을 도입하여 직접적인 DOM 조작을 최소화 하여 성능 문제를 해결하려고 노력했습니다. 가상 DOM은 실제 DOM과 동일한 구조를 가지는 객체를 생성하여, 이 객체를 변경하여 DOM을 업데이트하는 방식입니다. 이는 실제 DOM을 직접 조작하는 것보다 훨씬 빠르고 효율적인 결과를 가져오므로 성능을 크게 개선할 수 있습니다.

DOM이란?

DOM이란 웹페이지를 자바스크립트로 다룰 수 있도록 만든 구조 입니다. 즉, HTML로 만들어진 웹페이지를 자바스크립트로 다룰 수 있게 하는 것입니다. 특히 나무 구조(트리)가 되어 각각의 DOM 노드가 존재하고 자바스크립트로 접근하거나 수정할 수 있는 것이 특징입니다. 이러한 DOM을 직접 조작하는 것은 느리고 복잡한 문제를 가져옵니다. 그래서 React는 가상 DOM을 도입하여 직접적인 DOM 조작을 최소화하려고 노력한 것입니다.

선언형 프로그래밍

React는 어떻게 보일 지를 명확하게 선언합니다. 우리가 보고자 하는 것을 코드로 표현하는 방법을 제공 후 실제로 어떻게 할 지는 React가 처리합니다. 이를 통해 사용자 인터페이스가 안전하고 예측 가능하며 효율적으로 생성되고 작동할 수 있도록 보장합니다.

단방향 데이터 흐름 & Flux 아키텍처

데이터가 한 방향으로만 흐르기 때문에 버그가 줄어들고, 애플리케이션의 상태를 더 쉽게 예측할 수 있습니다. 또한 React는 데이터의 불변성을 강제하기 때문에 UI 컴포넌트가 특정 시점의 특정 상태를 반영하도록 보장합니다. 상태가 변경되면 기존 상태를 직접 변경하는 대신 새로운 상태를 표현하는 새 객체를 반환하기 때문에 추적과 디버깅에 용이한 효과를 가져옵니다.

Flux 아키텍처

Flux는 클라이언트 측 웹 애플리케이션 구축을 위한 아키텍처 디자인 패턴입니다. 단방향 데이터 흐름을 강조하여 데이터 흐름을 더욱 예측 가능하게 만들어줍니다.

Flux는 사용자 입력을 기반으로 Action을 만들고 ActionDispatcher에 전달하여 Store(Model)의 데이터를 변경 한 뒤 View에 반영하는 단방향의 흐름으로 애플리케이션을 만드는 아키텍처입니다.

Flux 아키텍처

  • Action : 데이터를 변경하는 행위로서 Dispatcher 에게 전달하는 단순한 객체입니다. Dispatcher를 통해 여러 Store로 보내집니다.
  • Dispatcher : Flux 아키텍처의 중심입니다. Action을 받아서 애플리케이션에 등록된 Store로 보냅니다.
  • Store : 애플리케이션 상태와 로직을 포함합니다. 다수 객체의 상태를 관리하고 자신을 Dispatcher에 등록하고 Action을 처리하는 콜백도 제공합니다. 스토어 상태가 업데이트 되면 View에 변경된 사항을 알립니다.
  • View : 리액트 컴포넌트입니다. Store에서 변경 이벤트를 받으며, 의존하는 데이터가 변경되면 스스로 업데이트 합니다.

그래서 우리는 이러한 이유로 React를 씁니다.

  • 화면에 나타내고자 하는 바를 선언적으로 표현할 수 있음
  • 더 예측 가능하고, 안정적인 앱 개발
  • 대규모 애플리케이션에 적합한 구조화된 방식
  • 수많은 커뮤니티와 생태계 덕분에 빠른 학습 및 문제 해결

후기

꽤나 압축해서 썼는데 그럼에도 불구하고 쓰다보니 점점 늘어나게 됩니다..ㅎ 그래도 이렇게 역사와 핵심 가치에 대해 알아보면서 React를 잘 이해할 수 있는 출발점이 된 것 같습니다. 좀 더 친해져보기 위해 다음 시리즈도 열심히 작성해보겠습니다.