[React] 리액트를 사용하는 이유에 대해 살펴보자.

저자 velog 블로그, 리액트를 사용하는 이유를 옮긴 글입니다.

프론트앤드 공부를 시작하게 되고, 리액트를 사용하게 되었습니다. 왜 사용하게 됐는지에 대한 질문을 받는다면 '매우 인기 있는 라이브러리', '많은 기업에서 요구하는 스펙'이라는 솔직한 답변은 프론트앤드에서 겪고 있는 고충을 해결하기 위해 만든 리액트를 사용할 자격이 불충분하다고 생각하게 되었습니다.

그래서, 이번 글에서는 리액트는 어떤 문제를 해결하고자 나왔고, 리액트의 철학과 추구하는 방향, 그리고 많은 개발자분들이 느끼고 있는 리액트의 공통적인 장점과 특징을 간접적으로 정리해보고자 합니다.

🧐 프론트앤드 라이브러리와 프레임워크의 등장 배경

프론트앤드 라이브러리가 등장하게 된 이유는 동적인 웹 페이지를 보다 효율적으로 유지 보수하고 관리할 수 있도록 하기 위함입니다. 여기서 정적, 동적인 웹 페이지가 무엇인지 궁금해집니다.

정적인 페이지는 웹 서버에 이미 저장되어 있는 HTML 문서를 클라이언트에게 전달하여 받은 페이지입니다. 기업을 소개하는 페이지라면, 단순히 기업 정보를 전달하기 위한 목적이기 때문에 유저의 인터랙션은 중요하지 않은 요소로 볼 수 있습니다. 이런 경우엔 단순히 HTML과 CSS의 구성만으로도 충분히 멋진 웹 페이지를 만들 수 있습니다.

반면, 동적인 페이지는 유저의 행동 흐름에 따라 웹페이지의 구성을 달리해주어야 하는 페이지를 말합니다. 즉, 유저의 요청 정보를 처리한 후 제작된 HTML 문서를 클라이언트가 전달받게 됩니다.

동적인 페이지가 주를 이루는 요즘, 웹 페이지라기 보다, 웹 애플리케이션이라는 용어가 더 어울릴 정도로 유저 인터랙션을 처리하기 위한 상태 변화가 상당히 많아졌습니다. 이를 자연스러운 유저 인터페이스로 만들어주기 위해서 프론트앤드 라이브러리 / 프레임워크가 등장하게 된 것입니다.

🙋 그래서, 프론트앤드 라이브러리 / 프레임워크는 무엇을 도와주는데?

웹 애플리케이션이라 불릴 만큼, 프로젝트 규모가 커지고, 다양한 유저 인터랙션이 전달된다면 그만큼 DOM 요소들 또한 변화가 이루어져야 한다는 것과 같습니다. DOM 요소들이 변화한다는 것은 랜더 트리 재생성, 요소의 스타일 계산, 레이아웃 구성, 패인팅 하는 과정을 거쳐야 한다는 것과 같습니다. 결국, 유저 인터랙션이 전달되는 만큼, 이와 같은 과정이 반복되어야 한다는 것이죠. (DOM 변화에 의해 발생되는 브라우저의 동작원리는 이 글을 참고하시면 좋습니다.)

하지만, 이러한 과정이 반복되면 될수록 브라우저가 많은 연산을 해야 한다는 것이고, 이는 전체적인 프로세스의 비효율성을 야기합니다. 또한, 많은 DOM 요소의 변화를 개발자가 직접 관리하는 것은 적지 않은 짐으로 다가오게 될 것입니다.

결국, 프론트앤드 라이브러리 / 프레임워크는 DOM 관리와 상태 변화 관리를 최소화하고, 개발자는 오직 기능 개발, 사용자 인터페이스에 보다 더 집중할 수 있도록 도와주는 것이며 이러한 목적을 가지고 다양한 해결 방식, 추구 방향을 가지고 각각의 프론트앤트 라이브러리 / 프레임워크가 탄생하게 되었습니다.

🤨 그럼, 왜 리액트야?

각각의 프론트앤트 라이브러리 / 프레임워크들은 추구하는 방향과 특징들이 다릅니다. (이 글에서는 리액트를 중심으로 다루기 때문에 타 프론트앤트 라이브러리 / 프레임워크들의 특징은 이 글로 대체하겠습니다.)

그렇다면, 우리가 사용할 리액트의 특징은 무엇이 있을까요?

🛠 Component 단위 작성

컴포넌트는 UI를 구성하는 개별적인 뷰 단위로서, UI를 개발을 레고라고 한다면, 컴포넌트는 블록 역할을 하게 됩니다. 이러한 블록을 조립해 하나의 완성품을 만드는 것과 같습니다. 이러한 특징은 하나의 컴포넌트를 여러 부분에서 사용할 수 있게 해줍니다. 가령, 웹 애플리케이션의 여러 곳에 버튼이 필요하다면, 공통된 하나의 버튼 컴포넌트를 생성하고 그 컴포넌트를 필요한 곳에 가져다 사용하면 되죠.

이러한 특징은 생산성과 유지 보수를 용이하게 합니다. 하나의 요소의 변화가 다른 요소들의 변화에 영향을 미치는 복잡한 로직을 업데이트하는 까다로운 작업에 경우, 컴포넌트의 재사용 기능으로서 보완할 수 있게 됩니다.

🛠 JSX

JSX(Javascript + xml)는 자바스크립트에 대한 확장 구문으로서, 리액트에서 element(요소)를 제공해 줍니다. 장점은 매우 다양합니다. 단순히 개발자가 마크업 코드에 익숙하다면, 그것만으로도 JSX를 통해 컴포넌트를 구성하는 데 쉽게 적응할 수 있다는 장점이 있습니다.

아래 코드에서 return () 에 감싸져 있는 HTML 문법과 매우 유사한 코드가 바로 JSX입니다.

import React from "react";
import logo from "./logo.svg";
import "./App.css";

const App = () => {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <h1 className="App-title">Welcome to React</h1>
      </header>
      <p className="App-intro">
        To get started, edit <code>src/App.js</code> and save to reload.
      </p>
    </div>
  );
};

export default App;

위와 같은 코드는 creata-react-app을 통해 리액트 프로젝트를 생성할 때 포함되어 있는 Babel이 아래와 같은 코드로 변환하여 컴파일 해줍니다.

"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.default = void 0;

var _react = _interopRequireDefault(require("react"));

var _logo = _interopRequireDefault(require("./logo.svg"));

require("./App.css");

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

const App = () => {
  return /*#__PURE__*/_react.default.createElement("div", {
    className: "App"
  }, /*#__PURE__*/_react.default.createElement("header", {
    className: "App-header"
  }, /*#__PURE__*/_react.default.createElement("img", {
    src: _logo.default,
    className: "App-logo",
    alt: "logo"
  }), /*#__PURE__*/_react.default.createElement("h1", {
    className: "App-title"
  }, "Welcome to React")), /*#__PURE__*/_react.default.createElement("p", {
    className: "App-intro"
  }, "To get started, edit ", /*#__PURE__*/_react.default.createElement("code", null, "src/App.js"), " and save to reload."));
};

var _default = App;
exports.default = _default;

덕분에 우리는 익숙한 HTML문법과 유사한 JSX를 통해 컴포넌트를 생성할 수 있게 됩니다.

🛠 Virtual DOM

Virtual DOM을 설명하기 전에, 이 동영상을 먼저 보고 오시는 것을 추천드립니다.

유저의 인터랙션에 의해 상태 변화가 일어나면 브라우저 작동 원리에 의해 랜더링 과정을 반복하게 됩니다. Vitual DOM은 이러한 과정에 의해 발생하는 비효율성을 최소화하기 위해 탄생하게 되었습니다.

Virtual DOM의 개념이 기존에 아예 없던 것은 아닙니다. 또한, Virtual DOM 개념을 적용한 유일한 프론트앤드 라이브러리 / 프레임워크는 아닙니다. 하지만, 리액트는 성공적으로 Virtual DOM 개념을 적용한 선발 주자라고 할 수 있습니다.

⚙ Virtual DOM의 작동 원리

유저 인터랙션에 의해 View에 변화가 발생하여 10개의 노드를 수정해 주어야 한다면, 10번의 레이아웃 재계산, 10번의 리랜더링이 필요하다는 것입니다.

Virtual DOM은 변화가 발생하면, 실제 DOM에 적용되기 전에 Virtual DOM에 우선 적용을 시켜봅니다. 실제 DOM에 바로 적용하나, Virtual DOM에 적용하나 같은 연산 비용이 필요할 거라 생각하실 수 있지만, Vitual DOM은 랜더링 과정이 필요 없기 때문에 연산 비용이 실제 DOM보다 적습니다.

Virtual DOM에서 이러한 연산이 끝나고 나면, 최종적인 변화를 실제 DOM에 전달해줍니다. 즉, 10번의 작업을 하나로 묶어 딱 한 번 전달해 줍니다. 물론, 레이아웃 계산과 리랜더링하는 과정의 규모는 커지겠지만, 횟수를 줄이는 것으로 충분히 연산 비용을 적게 만들어 줍니다. 또한, Virtual DOM은 어떤 게 바뀌었는지, 어떤 게 바뀌지 않았는지 자동으로 파악하여 필요한 DOM 트리만 업데이트할 수 있게 해줍니다.

👨‍💻 마무리

리액트가 등장하게 된 배경과 다양한 프론트앤트 라이브러리 / 프레임워크 중에서 리액트만의 장점과 특징을 정리해보았습니다. 물론, 위에서 언급하지 않은 장점들이 많겠지만, 손꼽히는 장점 3가지를 정리했습니다.

위의 글을 읽다 보면, 리액트는 엄청 빠르겠구나! 생각할 수 있습니다. 하지만, 리액트는 유지 보수에 보다 집중되어 있지만, 충분히 빠른 프론트앤드 라이브러리라는 것을 기억하셔 합니다.

리액트를 사용하는 더 많은 카테고리를 알고 싶다면, 이 글을 추천드리며 글을 마치겠습니다. 감사합니다.

📝 참고자료

https://velopert.com/3612

https://velopert.com/3236

https://d2.naver.com/helloworld/59361

https://medium.com/@SilentHackz/top-10-reasons-why-you-should-learn-react-right-now-f7b0add7ec0d

1day 1commit