[React][개발기] 1. React! 근데 React를 왜 써?

깃허브 주소 ▼

GitHub - NOGUEN/dilemma_cafe_web

 

 

개요

---

 

웹을 시작하게 된 이유

 기존에 모바일로 개발하던 서비스에 배포 문제가 발생하면서 다 완성을 해도 배포에 시간이 걸리게 됐다. 그래서 그 동안에 배포가 빠르고 모바일 웹, 혹은 데스크톱 웹에서도 쉽게 접근할 수 있게 웹으로 배포하고자 했다. 요즘 세대는 모바일로 접근이 빠르지만, 나를 비롯해 나보다 나이가 조금 있는 윗세대는 아직은 컴퓨터로의 접근이 조금 더 편한것 같았다. 모두가 즐길 수 있는 컨텐츠인데 특정 연령층만 접근이 빠른 것은 서비스의 목적과 맞지 않으므로 웹으로 배포하는 것을 결정했다. ▼

디자인부터 프론트 백 모두 혼자 하는 개인 프로젝트

 

 

Flutter로는 안되는거야?

 

"모바일은 Flutter로 개발했는데, 그걸로 Web까지 배포하면 되잖아?"

 

 확실히 Flutter로 웹도 배포할 수 있다. 하지만 이전에 Flutter로 웹을 배포를 해봤을 때, 그 해결되지 않은 특유의 버벅임이 너무나도 거슬려서 별도로 개발을 해야겠다는 생각이 들었다. 추가로 Flutter에서 웹 대응 버전을 내기 위해 반응형 UI도 구성을 해야하는데, 이를 구성하는 시간이나 웹으로 새로 만드는 시간이 큰 차이가 나지 않을 것으로 생각이 되어 Flutter로 웹까지 배포하는 것은 포기했다.

 

그렇게 찾다가 본게... React

 제일 먼저 생각난 웹 라이브러리는 React였다. (나중에 알게 된 거지만 React는 엄밀히 말하면 프레임워크가 아니라 라이브러리라고 한다.) 가장 유명하고 가장 많이 사용되는 라이브러리였기에 나도 모르게 React부터 찾게 됐다.

 

 그런데 찾던 도중 의문이 하나 들었다. 왜 가장 많이 사용하는걸까? 이 근본적인 사용 동기조차 모르고 개발이 들어가면 안되겠다고 생각이 들어서 왜 React가 나왔고, 왜 React가 좋고, 어떤 상황에서 주로 사용하는지를 알아보기로 했다.

 

 

React가 왜 인기가 많을까?

---

React의 등장 이유

 웹 개발이 복잡해짐에 따라 HTML, CSS, JS 만으로는 한계가 왔으며, 이를 해결하기 위해 DOM 조작을 쉽게 해주는 jQuery 라이브러리가 주로 사용이 됐다.

 

DOM(Document Object Model)?
DOM은 Document Object Model, 문서 객체 모델의 약어로 웹 페이지 문서를 트리 구조의 노드로 표현한다. JS를 사용하여 이러한 노드를 조작할 수 있다. DOM은 웹 페이지의 요소에 동적으로 접근하고 수정하는 데 사용되며, 웹 어플리케이션의 동적인 기능을 구현하는데 중요한 역할을 한다.

 

 그러나 웹 페이지의 규모는 시간이 흐를수록 커져만 가고, DOM을 직접 조작하는데에도 한계를 느껴버려서 대규모 프로젝트에서 효율적으로 코드를 관리하고, 컴포넌트 기반 UI 개발을 지원하는 프론트엔드 프로임워크와 라이브러리가 등장했다. 대표적으로 3가지가 나왔는데,  그 3가지가 바로 Angular, React, Vue다.

 

 리액트는 페이스북에서 사용하다가 2013년에 오픈소스로 공개했는데, 이후 다양한 회사에서 사용을 하면서 셋 중에서 가장 큰 인기를 끌고 있다.

 

 

리액트의 인기 비결(장점)

그럼 왜 리액트가 인기가 많아진 것일까? 거기에는 여러가지 이유가 있는데, 대표적으로 아래의 이유들이 있다.

 

1. 진입 난이도

React는 View Layer만을 담당하는 간단하고 가벼운 라이브러리다. Angular와 Vue와 같은 프레임워크가 아니라 React는 라이브러리에 속한다.

 

프레임워크와 라이브러리의 차이
프레임워크와 라이브러리의 핵심적인 차이는 프레임워크는 개발에 필요한 전체적인 구조와 규칙을 제공한다는 것이고, 라이브러리는 전체 구조나 규칙을 제공하지 않아 개발자가 원하는대로 도입할 수 있다는 것이다.

 

따라서 JS를 다룰 줄 알고 기초만 잘 익힌다면, 쉽게 React를 이용하여 개발을 시작할 수 있다.

 

2. 부분 적용이 가능

 필요한 부분에만 적용할 수 도 있다. React는 프레임워크가 아니라 라이브러리이며, 프레임 워크들에 비해 가볍고 제약 조건이 걸려있지 않아서 다른 프레임워크 혹은 라이브러리와 혼용이 가능하다. 그렇기에 기존의 코드를 변경하지 않고도 진행중인 프로젝트에 쉽게 React를 도입할 수 있다.

 

3. 재사용이 가능한 컴포넌트

 재사용은 모든 개발자들이 추구하는 것이다. 같은 코드를 반복해서 적기 보다, 하나의 코드를 만들고 이를 재사용하여 프로젝트를 구성할 수 있기를 바란다. React는 이 재사용을 컴포넌트라는 개념을 통해 보다 쉽게 가능하게 해줬다. 복잡한 UI도 작은 단위로 나누어 개발을 하면 전보다 쉽게 구현해낼 수 있게 되는 것이다. 이를 통해 보다 직관적으로 개발하는 것이 가능해진다.

 

 Angular나 Vue에서도 가능한 항목이지만, React에서는 JSX를 통해 이를 보다 쉽게 가능하게 해준다. Angular에서는 @Component 를 사용하고, Vue에서는 SFC, Single File Component를 사용한다. 사용면에서만 보면 이 둘 보다는 JSX가 훨씬 쉽게 다가온다.

 

Angular의 방식 ▼

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <h1>Hello, Angular!</h1>
    <p>This is an example of Angular component.</p>
  `,
  styles: []
})
export class AppComponent { }

 

Vue의 방식 ▼

<template>
  <div>
    <h1>Hello, Vue!</h1>
    <p>This is an example of Vue component.</p>
  </div>
</template>

<script>
export default {
  name: 'App',
};
</script>

 

React 방식 ▼

import React from 'react';

const App = () => {
  return (
    <div>
      <h1>Hello, react!</h1>
      <p>This is an example of React component.</p>
    </div>
  );
};

export default App;

 

 

4. 가상 DOM 사용을 통한 높은 퍼포먼스와 쉬운 유지보수

 이전의 HTML, JS로 개발된 웹에서는 HTML 구조가 바뀌면 전체를 다시 렌더링하곤 했다. 처리해야할 이벤트나 변수가 다양해지면 코드는 배로 복잡해졌다. 기존 JS는 DOM 접근을 통해서 값을 얻고 변경하는 방식을 많이 사용했기 때문이다.

 

 결국에는 DOM이 통째로 새로 생성되거나 비교 후에 변경이 이루어지는 것이 문제였는데, React는 이를 가상, Virtual DOM을 사용하여 해결했다. 실제 DOM에 접근하여 조작하는 것이 아니라 이를 추상화한 JS 객체를 구성하여 DOM을 조작한다. DOM의 상태를 메모리에 저장해놓고 변경 전과 변경 후의 상태를 비교한 뒤, 최소한의 내용만 반영하여 성능 향상을 이끌어낸다. DOM의 상태를 메모리 위에 계속 올려두고, DOM에 변경이 있을 경우 해당 변경 사항만 반영하게 된다.

 

 가상 DOM을 통해 재사용이 필요한 기능을 언제든지 필요한 곳에서 호출하여 반복적인 코드 작성 없이 사용할 수 있도록 해준다.

 

5. React Native

 React를 하면 같은 문법, 완벽히 같다고는 못하겠지만, 거의 동일한 문법으로 앱 개발도 가능해진다. HTML과 CSS가 조금 다른 걸 빼면 전체적인 구성은 거의 동일하기에 처음부터 배우는 수고를 하지 않고 앱 개발도 할 수 있다.

 

6. 커뮤니티

 오래된 만큼 그 정보도 많고 공유하는 커뮤니티도 많다. Flutter를 처음 배울 때는 정보가 많지가 않고, 대부분 영어로 되어있어서 학습을 할 때에 번역을 하는 시간이 필요했다. 그에 비해 React는 강의 수 부터 시작해서 다루는 정보 글이 엄청나게 많고 활발하게 소통하는 커뮤니티들도 다수 존재하여 정보를 얻는데에 조금 더 용이하다.

 

좀 더 자세한 이유들은 아래의 글에 잘 나와있다. ▼

리액트(React)를 왜 사용해야 할까? - 리액트가 강력한 이유

 

그렇다면 단점으로는 어떤 것들이?

 이렇게만 보면 React는 무조건 좋은거고 안쓰면 바보인 기술이기에 어떤 단점이 있는지도 알아봤다. 만병통치약 같은 기술은 없기에 늘 유의해야한다는 생각이다.

 

1. 스타일링이 어려움

 Flutter를 하다가 React의 UI 구성에 대해 봤을 때, React쪽이 좀 더 어렵고, 정형화된 무언가가 없다는 생각이 확 들었다. 약간 당연하기도 한 이유인데, 우선 Flutter는 선언형 UI에 구글에서 공식적으로 가이드라인을 만들어준 프레임워크인 반면 React는 크게 정해진 것이 없는 라이브러리이기 때문이다.

 

 그래도 정형화된 무언가가 있지 않을까? 하고 공부를 시작하기 전 스타일링을 도와주는 라이브러리나 다른 사람들은 어떤 형식으로 스타일링을 하는지 찾아봤는데, 그 종류가 너무 많았다. 공통 css를 사용하기, style 블록을 사용하기, styled-component 사용하기, module css 사용하기, tailwindcss 사용하기 등등... 수많은 방법으로 스타일링이 가능했다.

 

 방법이 많다는것이 나쁘다는 것은 아니지만, 입문자의 경우 어떤 것을 도입해야 좋을지 판단하기 어려웠다. (필자는 styled-component와 scss를 같이 사용해보려고 하는데 프로젝트에 정말 알맞는지는 아직 모르겠다.) 리액트가 의도한 단점이라고는 하지만 디자이너나 퍼블리셔의 입장에서는 상당히 곤란한 문제다.

 

2. Hook

 React Hook은 간단하게 이야기하면 함수형 컴포넌트들이 useEffect와 useState등의 기능을 통해 클래스형 컴포넌트들의 기능을 사용할 수 있게 해주는 것이다. 하지만 많은 개발자들이 Hook의 설계는 잘못되었다고 말하며 상태관리를 해치는 주범이라고 한다.

 

아래의 글에서 그 이유가 잘 나와있다. ▼

[React] 리액트 훅이 실패한 설계인 이유 네가지

 

3. 규모가 커지면 실행속도가 느려짐

 React 자체가 상당히 무거운 환경인데 앞의 단점들로 인해 이것저것 라이브러리들을 붙이고 스타일링을 붙이면 더 무거워진다. 렌더링을 자주하는 환경에서 이득을 보기위해 무거움에도 사용을 하는 것인데, 그것이 아니면 다른 환경이 더 좋을 수도 있다. (다행히 필자가 개발하는 서비스는 렌더링이 꽤 잦을 것으로 예상이 되기에 그나마 다행인거 같다.)

 

4. View 만을 지원

 React는 View만을 지원하기에 데이터 모델링과 같은 기능이 필요한 경우 직접 구현하거나 별도의 라이브러리의 힘을 빌려야한다. 이는 3번 단점과도 계속 이어지는 단점이 되기도 하고, 직접 구현하는데에서의 시간이나 개발자가 이를 위해 별도로 소모하는 자원이 많아진다.

 

 

React를 프로젝트에 사용하는 진짜 이유들

---

 앞에서는 React의 장점에 대해서 알아보았다. 그런데 장점이 많다고 꼭 사용해야할까? 전혀 아니다. 해당 라이브러리에 장점이 수두룩 빽빽하게 있다고 하면 어느 하나는 내가 만들고자 하는 프로젝트에 얻어 걸려서 좋긴 하겠지만, 그 모든 장점들이 내가 만들고자 하는 프로젝트에 맞지 않을수도 있다. 그렇기에 우리가 하고자 하는 프로젝트에 React가 맞는지를 알고 들어가야한다.

 

 그렇다면 React는 어떤 프로젝트에 적용을 할까? 그리고 React를 사용하는 또 다른 이유가 무엇일까? 필자는 이 두 가지 질문의 답을 알기 위해 커뮤니티를 검색했고, 나온 해답은 아래와 같았다.

 

1. Single Page Application을 만들기에 최적화돼있다.

 React는 Single Page Application(줄여서 SPA)을 만드는 라이브러리다. 첫 로딩 이후 빠르고 자연스러운 전환이 가능해져서 사용자 경험이 좋다. 이는 첫 로딩 시에 서버에서 대부분의 데이터를 받아오기 때문인데, 프론트 단에서는 서버와 데이터를 받은 이후 로컬 캐싱으로 데이터를 보관한다. 데이터를 받고난 이후엔 독립적으로 동작하기 때문에 서버와 연결이 끊겨도 동작한다. 백엔드와 독립적으로 동작하기에 프론트엔드 개발이 백엔드에 영향을 주지않고 진행될 수 있다.

 

Multi Page Application(MPA)
 SPA와 반대되는 개념인 MPA는 전통적인 웹에서 사용되던 방식이다. 처음에 전부 받아오는 SPA와는 다르게 새로운 페이지 요청 마다 페이지를 받아오는 MPA방식은 Wikipedia, Amazon, BBC News 등등의 서비스에서 사용되고 있다. 해당 사이트들은 전통적인 웹이라서 MPA를 사용하는 것도 있겠지만, 보다 나은 SEO 최적화가 필요해서 MPA 방식을 고집하고 있기도 하다.

 

 이런 특징으로 인해 사용자 경험을 개선하고 싶은 서비스에서 주로 SPA를 사용한다. 하지만 SPA에도 단점이 있어서 아래의 두 가지 요소가 치명적으로 다가오는 서비스라면 도입을 꺼려야한다.

• 빠른 초기 로딩
• 검색 엔진 최적화

 React는 첫 로딩 후 로컬 캐싱으로 실행 도중에는 굉장히 빠르고 부드럽게 돌아가는 모습을 보이지만, 이를 뒷받침하기 위해서는 첫 로딩이 필요하다. 하지만 프로젝트 크기 자체가 크기에 첫 로딩이 오래 걸릴 수 있다. 요즘은 전반적인 하드웨어 성능이 다 상향평준화 되어있어서 큰 문제가 되지 않지만, 구형 기기나 네트워크 품질이 좋지 않은 상황도 커버하고 싶다면 좋은 선택지는 아니다.

 

 검색 엔진 최적화도 마찬가지다. React는 Ajax로 데이터를 교환하는 방식을 이용하여 SPA를 구현하는데, 검색 엔진 최적화에 좋지 못한 방식이다. 검색 엔진 크롤러는 초기 HTML을 크롤링하는데, Ajax로 데이터를 교환하는 방식이면 초기 HTML에 중요한 정보가 빠진채로 검색 엔진 크롤러가 크롤링하게 된다. 이는 Server Side Rendering(SSR)로 해결이 가능하다. SSR이 검색 엔진 최적화를 쉽게 만들어주는 이유는 이름 그대로 서버에서 HTML을 렌더링을 해서 주기 때문이다. 서버에서 중요한 정보가 들어간 HTML을 미리 렌더링 하고 클라이언트에 제공을 해주면 검색 엔진 크롤러가 데이터 누락 없이 크롤링이 가능해지기에 SSR을 도입하여 이를 해결할 수 있다. 허나 해결은 가능하지만 개발자에게 추가 작업을 요구하기 때문에 전통적인 방법(MPA)을 고수하는게 좋을 수도 있다.

 

 허나 위의 두 가지는 요즘 크게 문제가 되는 부분이 아니기 때문에 이에 대해 크게 생각하지 않아도 서비스를 만들 수 있다. 위의 두가지가 모두 치명적인 프로젝트는 전체 프로젝트에서 극소수이기에 크게 고민하지 않고 도입해도 문제가 되지 않는다. 또한 위의 두가지를 고려해서 React를 사용하지 않으려고 해도 SPA를 통해 줄 수 있는 사용자 경험적인 부분을 무시할 수 없기에 React를 도입할 수 밖에 없어 보인다.

 

2. React가 가장 오래됐고 정보가 많다. 그리고 너도나도 다 사용한다.

 이는 기술적인 이유보다는 사회적인 문제로 보이는데, 주변에서 React를 공부하는/사용하는 이유가 대체로 많이 사용해서다. 한국을 욕하고자 하는 것은 아니나 유행에 상당히 민감한 나라인 만큼 개발에서도 메인 스트림을 따르는 것이 많아 보이기도 한다. 메인 스트림을 따르는게 잘못된 것도 아니고 장점도 많다. 커뮤니티가 많고 얻을 수 있는 정보가 상당히 많아져서 메인 스트림을 따르는 것은 이상한게 아니다. 허나 앞에서도 이야기 했듯이 이를 왜 적용해야하는지를 모르고 적용하는 경우도 꽤 많이 보인다.

 

 간혹 어느 그룹에서는 React를 사용하지 않으면 바보 취급하거나 React를 찬양하기도 한다. 프로젝트를 위해서가 아니라 다들 하니까 하는 기조도 꽤 보인다. 필자는 안그랬냐 하면, 필자도 마찬가지다. 굉장히 좁은 시야를 갖고 있었고, 그로 인해 사용할 줄 아는 개발 스택이 굉장히 적었다. 어쨌거나 다들 다 사용해서 사용하는 경우가 꽤 보이나, 이는 좋은 건 아닌 것 같다.

 

3. 대부분의 기업이 React와 비슷한 프레임워크/라이브러리의 숙련도를 요구로 함.

 이는 보다 현실적인 이유로 먹고 살기 위해서다. 먹고 살기 위해서 하는게 나쁘다는 걸 말하려는게 아니다. 노동은 숭고한 것이다. 하지만 그 숭고한 노동 속에서도 왜 이걸 사용할까 하는 것은 중요하다고 생각한다.

 

 먹고 살기 위해서 React를 선택하는건 당연한 선택이다. 대부분의 회사가 React와 비슷한 프레임워크/라이브러리의 숙련도를 요구로 하기 때문이다. 이는 앞의 2번 이유와도 연계되어있다. 다들 많이 사용하고, 이를 통해 빠르고 효율적인 개발을 하며, 보다 나은 사용자 경험을 보여주고 있으니 회사 입장에서는 선택하지 않을 이유가 없다. 회사가 이렇게 하기로 결정했다면 당연히 이를 할 줄 아는 사람을 뽑게 되고 취업을 위해서라면 당연하게도 해당 스킬을 가지고 있어야 한다. 필자는 아닌것 처럼 말했지만 필자도 해당되는 이야기다.

 

---

 

그래서 주위 사람들은 대부분 이런 이유로 React를 사용/공부한다. 물론 진짜 React가, 개발이 재미있고 스스로에게 챌린지를 주려고 하는 사람도 있으나 큰 이유로는 위의 3가지인 것 같다.

 

 

마치며

---

 React 공부를 시작하기 전에 왜 좋고, 왜 사용하는지를 알아보았다. 무언가를 배울 때 이 두 가지가 선행되어야한다고 생각이 되어 개론에 상당히 시간을 투자했다. 이제부터 웹 개발을 하며 웹 개발기를 시작해보겠다...!