누구든지 하는 리액트 1편: 리액트는 무엇인가


이 튜토리얼은 10편으로 이뤄진 시리즈입니다. 이전 / 다음 편을 확인하시려면 목차를 확인하세요.

프론트엔드 라이브러리 / 프레임워크

리액트는 정말 인기있는 프론트엔드 라이브러리입니다. 그런데 일단, 리액트에 대해서 알아보기전에, 이 프론트엔드 라이브러리란게 정확히 뭔지, 그리고 왜 필요한건지에 대해서 알아봅시다.

일단, 여러분이 웹사이트를 만들기 위해선, 사실 프론트엔드 라이브러리의 도움 없이도 만들어낼 수 있습니다. 그리고 단순히 정적 페이지를 만드는거라면 자바스크립트 없이도, 그냥 HTML 과 CSS 를 사용해서 만들면 되죠.

거기에 자바스크립트를 더해주면, 유저의 행동흐름에 따라서 동적으로 화면을 보여줄 수 있게 되겠죠.

그런데 요즘의 웹은요, 단순히 웹 페이지 가 아니라, 웹 애플리케이션이에요. 브라우저 상으로도 정말 자연스러운 흐름으로 매우 많은것들을 할 수가 있죠. 자, 그런데 어떠한 유저인터페이스를 동적으로 나타내기위해서는 정말 수많은 상태를 관리해줘야합니다.

예를 들어서 다음과 같은 HTML 코드가 있다고 가정해봅시다.

  <div>
    <h1>Counter</h1>
    <h2 id="number">0</h2>
    <button id="increase">+</button>
  </div>

우리가, 버튼을 눌러서 저 숫자 0 값을 바꿔주려면 각 DOM 엘리먼트에 대한 레퍼런스를 찾고, 해당 DOM 에 접근하여 원하는 작업을 해줘야하죠.

var number = 0;
var elNumber = document.getElementById('number');
var btnIncrease = document.getElementById('increase');

btnIncrease.onclick = function() {
  number++;
  elNumber.innerText = number;
}

만약에 jQuery 를 사용하게 된다면, document.getElementById 대신에 $('#number') 이런식으로 사용해서 DOM 을 가져오게 되겠죠.

여러분의 프로젝트가 사용자와의 인터랙션이 별로 없다면, 사실상 프론트엔드 라이브러리는 필요하지 않습니다. 그냥 직접 구현하는 것도 나쁘지 않아요. 하지만! 프로젝트가 규모가 커지고, 정말 다양한 유저 인터페이스와 인터랙션을 제공하게 된다면, 그 많은 DOM 요소들을 직접 관리하고 코드 정리하는건 진짜 진짜 갈수록 힘든 일 일것입니다.

물론, 제대로된 컨벤션을 가지고, 여러 규칙을 세워서 진행을 한다면 불가능한 일은 아닙니다만, 여전히 번거로운 것은 사실입니다.

웹 개발을 하게 될 때, 귀찮은 DOM 관리와 상태값 업데이트 관리를 최소화하고, 오직 기능 개발, 그리고 사용자 인터페이스를 구현하는 것에 집중 할 수 있도록 하기위해서 정말 여러 라이브러리들 혹은 프레임워크들이 만들어졌습니다.

대표적으로 Angular, Ember, Backbone, Vue, React 등이 있죠.

라이브러리 / 프레임워크의 선택

2017년 기준으로 이 프론트엔드 동네에서 3 대장으로는 React, Angular, Vue 가 있습니다. 무엇을 선택해야 할까요? 결국 이 세 라이브러리는, 똑같은 문제를 다른 방식으로 해결 할 뿐입니다. 이 중에서 하나를 고르라고 하는건, 정말 답이 없는 문제입니다. 이런 말 들어보셨죠? “장인은 도구를 탓하지 않는다.” 훌륭한 개발자, 훌륭한 팀이라면 이 셋중에서 뭘 선택하던지 훌륭한 프로젝트를 만들어 낼 수 있을 것 입니다.

이 셋 중에서 가장 좋은 도구를 고르는것은, 불가능한 것이지만, 여러분이 가장 좋아하는 도구를 고르는것은, 가능합니다. 되도록이면, 각 라이브러리/프레임워크를 기초수준이더라 하더라도, 한번쯤 사용해보세요. 각 도구들의 철학과 추구하고자 하는 방향이 서로 다르다는 것을 알게 될 것입니다. 그리고 나서, 맘에드는걸 사용하시면 됩니다.

제가 느낀 각 도구들에 대한 생각과 특징을 요약해보자면 다음과 같습니다.

Angular

UI 를 구현하게 되면서, 앵귤러만의 문법같은 것들이 다양하게 존재합니다. 특정 기능을 구현 할 때, 편리하게 대신 해주는 것들이 많습니다. 라우터, HTTP 클라이언트 등 웹 프로젝트에서 필요한 대부분의 도구들이 프레임워크 안에 내장되어 있습니다. 앵귤러1의 경우 만들어진지 꽤 오래 됐고, 기업에서 많이 사용이 돼서, 유지보수하고 있는 프로젝트가 많아서 사용률이 높은 편입니다. 앵귤러2의 경우 매우 성숙하긴 하지만, 인지도 측면에선 아직 성장하는 단계이며, 주로 타입스크립트랑 함께 사용됩니다.

React

“컴포넌트” 라는 개념에 집중이 되어있는 라이브러리입니다. 컴포넌트는 우리가 추후 더 자세히 배워보겠지만, 미리 간단히 설명하자면, 데이터를 넣으면 우리가 지정한 유저 인터페이스를 조립해서 보여줍니다. 페이스북 개발자들이 라이브러리의 성능과 개발자 경험을 개선하기 위해 많은 연구를 합니다. 리액트를 한번 해본 개발자들은 대부분 맘에 들어합니다. 생태계가 엄청 넓고, 사용하는 곳도 많습니다. HTTP 클라이언트, 라우터, 심화적 상태 관리 등의 기능들은 내장되어있지 않습니다. 따로 공식 라이브러리가 있는 것도 아니여서, 개발자가 원하는 스택을 맘대로 골라서 사용 할 수 있습니다 (혹은 직접 라이브러리를 만들어서 쓸 수도 있겠죠.)

Vue

입문자가 사용하기에, 정말 쉽습니다. 대부분 Webpack 같은 모듈 번들러를 사용하여 프로젝트를 구성해야하는 앵귤러와 리액트와 달리, 단순히 CDN 에 있는 파일을 로딩 하는 형태로 스크립트를 불러와서 사용하기도 편합니다. HTML 을 템플릿처럼 그대로 사용 할 수도 있어서 마크업을 만들어주는 디자이너/퍼블리셔가 있는 경우 작업 흐름이 매우 매끄럽습니다. 공식 라우터, 상태관리 라이브러리가 존재합니다.

소개

리액트의 매뉴얼을 보면 다음과 같은 내용이 있습니다.

We built React to solve one problem: building large applications with data that changes over time.
번역: 우리는 지속해서 데이터가 변화하는 대규모 애플리케이션을 구축하기 위해 React를 만들었습니다

리액트를 사용하는게 여기서 유일한 해답이냐? 그건 아닙니다. 그저 여러가지 솔루션 중 하나인 것 이죠.

페이스북은 왜 리액트를 만들게 됐을까?

페이스북이 리액트를 만들기 전에도, 이미 Angular, Backbone, Knockout.js, Ember 등의 수많은 프레임워크들이 존재했습니다. 그리고 해당 프레임워크들은 데이터단을 담당하는 모델(Model), 사용자의 화면에서 보여지게 되는 뷰(View), 그리고 사용자가 발생시키는 이벤트를 처리해주는 컨트롤러 (Controller) 로 이뤄진 MVC 패턴, 그리고 MVC 에서부터 파생된 MVVM(View Model), MVW(Whatever) 등의 패턴들로 이뤄져있죠.

여기서 공통점은 바로 모델입니다. 방금 언급했던 프레임워크들의 모델은, 대부분 어떻게 작동하냐면, 양방향 바인딩을 통하여 모델에 있는 값이 변하면, 뷰에서도 이를 변화시켜줍니다. 여기서 핵심적인 부분은 변화시켜준다는 부분입니다. 일단 첫 화면을 보여주고, 변화에 따라 필요한곳을 바꿔주는거죠.

**”변화(Mutation)”**라는것은 상당히 복잡한 작업입니다. 특정 이벤트가 발생했을때, 모델에 변화를 일으키고, 변화를 일으킴에 따라 어떤 DOM 을 가져와서 어떠한 방식으로 뷰를 업데이트 해줄 지 로직을 정해줘야 하는데요, 페이스북에서는 리액트를 만들기전에 이러한 발상을 했습니다:

그냥 Mutation 을 하지 말자. 그 대신에, 데이터가 바뀌면 그냥 뷰를 날려버리고 새로 만들어버리면 어떨까?

그렇게 하면 진짜 간단하겠죠? 그런데 브라우저가 무슨 게임 엔진도 아니고, DOM 기반으로 작동하는 이 페이지는 그때 그때 새로 뷰를 만들어버리라고 하면 성능적으로 엄청난 문제가 있을 것입니다.

그래서 사용하는게 바로, Virtual DOM 입니다.

Virtual DOM 은 가상의 DOM 입니다. 변화가 일어나면, 실제로 브라우저의 DOM 에 새로운걸 넣는것이 아니라, 자바스크립트로 이뤄진 가상 DOM 에 한번 렌더링을 하고, 기존의 DOM 과 비교를 한 다음에 정말 변화가 필요한 곳에만 업데이트를 해주는 것이죠.

이 Virtual DOM 을 사용함으로서, 데이터가 바뀌었을 때 더 이상 어떻게 업데이트 할 지를 고려하는게 아니라, 그냥 일단 바뀐 데이터로 일단 그려놓고 비교를 한다음에, 바뀐 부분만 찾아서 바꿔주는거죠.

다음 동영상을 보시면 이해하기가 쉽습니다.

  • React and the Virtual DOM (https://www.youtube.com/watch?v=muc2ZF0QIO4)

Virtual DOM 은 DOM 변화를 최소화 시켜주는 역할을 하는데요, 이 횟수를 최소화 시키는것은 성능적으로 매우 중요한 이슈입니다. 자세한 내용은 리액트에 대해서 그 누구도 제대로 설명하기 어려운 것 – 왜 Virtual DOM 인가? 포스트에서 확인해보세요.

React 만 Virtual DOM 쓰나?

리액트는 Virtual DOM 을 성공적으로 사용한 선발주자입니다. 이 아이디어를 다른 많은 라이브러리에서도 택했습니다. Virtual DOM 을 사용하는 라이브러리는 꽤 많습니다.

리액트를 특별하게 만드는 점은?

그렇다면, 무엇이 리액트를 특별하게 만들까요? 이 부분은 여러가지 사항이 있겠지만, 제가 생각하는 주요 포인트는 다음 3가지입니다.

엄청난 생태계

리액트 생태계에서의 개발자들의 열정은 마치 2006년쯤 jQuery 가 나왔을 떄와 비슷합니다. 매우 뜨겁죠. 그 시절에는 웹 개발에서는 jQuery 를 사용하는게 너무나 당연했었죠. 그리고 이를 사용하는 수많은 플러그인이 나왔었습니다.

이것과 비슷하게, 리액트 라이브러리도 정말 많이 만들어집니다. jQuery, 혹은 일반 자바스크립트로 만들어진 라이브러리들도 리액트로 포팅되서 많이 작성되고있습니다. 뿐만 아니라, 그냥 단순히 특정 기능을 구현하기 위한 라이브러리 (예: 폼, 캐로절, 애니메이션, UI) 가 아니라, 프로젝트의 구조와 강하게 묶여있는 라우터, 상태 관리 라이브러리들도 매우 다양하죠.

사용하는곳이 많다

리액트를 사용하는 서비스는 여기에서 확인해볼 수 있습니다.

유명한 회사에서도 많이 사용되고 있죠 – Airbnb, BBC, Cloudflare, Codecademy, Coursera, Dailymotion, eBay, Twitch, Walmart, Yahoo…. 정말 수많은 곳에서 사용되고 있습니다.

하지만, 리액트의 사용률이 가장 높다고는 할 수 없습니다. 왜냐하면, 기존에 만들어진 프로젝트들중에서 이미 jQuery, Angular, Ember 등으로 만들어진 프로젝트들이 꽤 있기 때문이죠.

때문에, 새로 만들어지는 프로젝트, 혹은 리뉴얼되는 프로젝트에서 정말 많이 사용됩니다.

한국에도 이 리액트 부흥이 일어났습니다. 2015년만해도, 로켓펀치 에서 리액트를 검색했을 때 나타나는 채용 정보가 10개 내외였는데, 이제는 무려 180개가 넘습니다.

한번 사용해보면, 좋아하게 된다!

이것은 단순히 제 입장이 아니라, 통계적으로 그렇습니다.


한번 사용해본 사람들 리액트를 사용해본 14689 명에게 설문 조사를 했을 때 1020명을 제외한 나머지는 리액트를 다시 사용 할 의향이 있다고 합니다 (약 93%)

그리고 2017년에 가장 사랑을 많이 받은 라이브러리이기도 합니다.


리액트를 사용하게 됨으로써 앞으로 겪게 될 일들

리액트는 정말 자유도가 높은 라이브러리입니다. 예를들어서 라우터, 혹은 상태관리 같은 기능들이 리액트 자체에 내장되어있지도 않거니와, 공식적인 라이브러리도 없습니다. 하지만 써드파티 라이브러리가 존재하죠.

라우터쪽을 보자면, React-router, 그리고 Next.js, After.js 같은 라이브러리들이 있죠.

상태 관리 라이브러리만해도, Redux, MobX, fr(e)actal 같은 라이브러리들이 있습니다.

그리고 리액트 컴포넌트 스타일링을 할 때도 한가지 정해진 방식이 있는게 아니라 수많은 방식으로 할 수 있습니다.

이에 따른 장점은, 여러분들이 가장 맘에드는것을 사용하거나 심지어 직접 만들어서 사용 할 수도 있다는 점이고, 단점은 여러가지를 시도해볼 필요가 있고 선택장애(?) 가 일어날 수 있다는 점 입니다.

저는 이는 엄청 좋은 것이라고 합니다. 그리고 리액트 생태계 자체에도 정말 좋은 방식이라고 생각합니다. 리액트 라이브러리는 뷰 쪽만 관리하게 하고, 나머지 기능은 써드 파티 라이브러리가 담당하게 함으로서, 리액트는 리액트 라이브러리로서 더욱 성숙해질 수가 있는것이고 (페이스북 개발팀이 리액트 자체적인 기능에 더욱 많은 연구를 쏟을 수 있겠죠), 나머지 라이브러리들에서는 종류가 많다보니, 많은 개발자가 정말 다양한 시도를 하게 될 것이고, 덕분에 계속해서 성장합니다.

끝없는 공부

생태계가 계속해서 발전해나가기에 우리는 끊임없이 공부를 해야합니다. 근데 이건 사실상 뭘 배우던 마찬가지입니다 🙂 어느정도 숙달을 해놓고 나면, 계속해서 최신 동향을 따라가지 않더라도 큰 문제는 없겠지만, 더 좋은 것들을 누리지 못한다는 생각이 들게 되기 마련입니다. 그런 생각을 하면 공부를 하지 않을 수가 없죠.

앞으로 어떻게 공부할까?

구글링을 해가면서 자신을 학습해가시면 됩니다. 하지만, 정말 수많은 자료가 나올 것이고, 한국 자료는 (아직까지는) 그렇게 아주 많지는 않습니다. 제가 이번 튜토리얼 시리즈에서, 필요한 부분만 콕콕 찝어서 재밌고 쉽게 배울 수 있도록 가이드를 해드리겠습니다 😉 앞으로 이어지는 포스트를 쭉 읽어보세요.

Reference

  • Minwoo Kim

    좋은 글 감사합니다!!

  • 김영준

    좋은 글 감사합니다.

  • Yoon

    좋은글 감사합니다 ^^

  • ash

    좋은글 감사합니다.

  • JoonHo

    정말 유익한 글 잘 읽었습니다. 감사합니다. 🙂

  • 개굴이스냅백

    잘 읽었습니다! 감사합니다 : )

  • Myounghoon Lee

    React 공부 시작했습니다.
    잘 읽었습니다. 감사합니다:)

  • Yon

    감사합니다!

  • Yeji Park

    좋은 글 감사합니다!

  • AicBic

    Thanks!

  • 감귤

    공부 시작했습니다. 좋은 글 감사합니다.

  • Jin-Woo Jung

    좋은글 감사합니다.

  • jeon

    love you !!

  • Woojin Choi

    감사합니다^^

  • 최고

    너무 좋은글입니다. 감사합니다.

  • 윤병현

    버츄어돔에 대해 질문있는데요.. 제가 잘 이해한것이 맞는지 모르겠네요, 그니까 기존방식은 DOM에 변화를 주는 방식으로 화면을 업데이트 했는데.. 이 변화라는 작업이 생각보다 브라우저에서 복잡한 일을 하는거라.. 비용이 많이 들어, 페이스북에서는 브라우저가 변화를 주는것보다 그냥 아주 새로 그리자! 라고 생각을 했고 .. 그런데 여기서 새로 그린다! 라는것은 지금 보여주는 화면의 DOM을 처음부터 끝까지 새로 그리는 방식이어서(제가 강의를 토대로 추축한겁니다) 가상돔을 자바스크립트로 만들어 놓고 실제돔과 비교하여 변화가 필요한 부분만 DOM을 새로 그린다라는 것인가요?

    그니까 정리하면..만약 Virtual DOM이 없다면 뷰를 새로그린다는 작업은.. 모든 DOM을 처음부터 끝까지 새로 그리는 작업이 되는건가요?

  • HohO

    배워보려고 찾아보던 중 좋은 글이 있어서 다행입니다. 덕분에 공부 시작하게 됐습니다.

  • Carry Kim

    감사합니다. 잘 공부해보겠습니다.

  • Indo Yoon

    웹개발에는 문외한입니다. 스태틱 사이트 공부하다가 여기까지 왔네요

  • Jae yun

    페이스북은 진짜 대단해요..