[React] React 다시보기1_페이스북은 왜 리액트를 만들었을까

들어가며

리액트로 프로젝트 3개를 했지만, 리액트가 어떻게 동작하는 지 설명하라고 물어보면 말문이 막히는 경험을 했다. 수능 만점자들이 흔히 하는 "교과서만 보고 공부했어요"라는 대답에서 힌트를 얻어, 리액트 공식문서를 다시 살펴보기로 했다. 리액트 공식문서를 살펴보며, 그간 익힌 내용들을 접목시켜 리액트가 무엇이고 어떻게 작동하는지에 대해 설명을 해보고자 한다.

리액트가 무엇인가요?

리액트는 페이스북이 만든 JavaScript기반의 라이브러리이다. 페이스북은 “지속해서 데이터가 변화하는 대규모 애플리케이션을 구축하기” 위하여 React를 만들었다고 밝혔다.

리액트 공식문서는 리액트를 다음과 같이 설명하고 있다.

React는 사용자 인터페이스를 구축하기 위한(for building composable UI) 선언적이고 효율적이며 유연한 JavaScript 라이브러리입니다. “컴포넌트”라고 불리는 작고 고립된 코드의 파편을 이용하여 복잡한 UI를 구성하도록 돕습니다.

리액트는 프레임워크가 아니라 JavaScript기반의 라이브러리다

• 리액트는 클라이언트(프론트엔드)에서 사용하는 라이브러리로, 프레임워크인 뷰나 앵귤러와 다르게 MVC(Model, View, Controller)모델 중에 View 만을 관리한다.

• 왜 View만을 관리하는 라이브러리를 만들었을까? 생각해보자. 리액트는 페이스북이 만든 라이브러리다. 페이스북은 거대한 서비스로, 유저들의 엄청난 데이터가 생성되고 삭제되고 수정되고 읽혀진다(C.R.U.D). 이러한 거대한 데이터들의 상태를 쉽게 관리하기 위해, 그리고 사용자가 서비스를 만나는 표면인 UI(유저 인터페이스)에 집중하기 위해 리액트를 만든 것이다. 즉, 사용자 경험을 향상시키기 위해 리액트를 만든 것이다.

• 페이스북은 PHP 언어를 사용하는데, PHP의 단점을 보안하기 위해 HHVM, Hack, XHP를 만들었다.

• 이를 통해 Back-end에서는 자체적으로 개선하여 개발 효율성을 높이고 있지만, Front-end의 한계를 극복하기 위한 대안이 필요했을 수 있다.(이 글의 추측에 따르면 그렇다)

리액트 이전에는 어땠을까

• 이전에는 컴포넌트들이 늘어날 때마다 개별적으로 뷰 로직을 짜야했다. 또한 뷰와 모델의 로직이 잘 분리되지 않고, 뒤섞이기 쉬웠다. 유지보수를 신경 쓰는 개발자들은 모델 데이터를 변경하는 로직과 뷰 로직을 분리해 Separation of Concern (관심사의 분리)를 하고자 했다.
• 이로 인해 Backbone.js이나 Angular.js와 같은 라이브러리들이 자연히 등장하게 되었다.
• 로직에 집중하기 위해서는 좀 더 많은 부분, 특히 뷰의 업데이트가 자동으로 이뤄져야 할 필요가 있다. React는 뷰 업데이트 과정을 단순화할 수 있게 도와준다.

리액트가 라이브러리라 생기는 장단점

• 리액트는 View 라이브러리이기 때문에 어떤 형태의 모델이 사용될 것인지에 대한 가정을 하지 않으므로, 시스템적인 구성을 강제하지 않는다. 한가지 일만 하기 때문에 단순하고, 여러 자바스크립트 프레임워크나 라이브러리와 함께 사용할 수 있다.
• 대신, 데이터 조작이나 라우터 같은 기능들은 상황에 맞게 부가적인 라이브러리를 사용해야 한다. 어떤 라이브러리를 쓸 지 선택하는 데 비용이 발생한다.
• React를 사용하기 위해서 기존 코드를 모두 바꿀 필요 없이 필요한 부분부터 부분적으로 조금씩 적용하는 것이 가능하다.root로 취급되는 DOM Element가 있으면 어디에서나 적용할 수 있다.

리액트가 MVC 패턴을 사용하지 않은 이유

• 페이스북은 MVC모델은 확장이 어렵고, 거대한 시스템에 어울리지 않는다고 결론을 내렸다.
• MVC 모델은 새로운 기능 추가 시 시스템의 복잡도가 기하급수적으로 증가하여, 개발자는 코드를 쓸 때 기존 기능에 대한 영향을 주지 않을지에 대한 불안감을 가지게 된다.
• MVC 패턴은 데이터의 변경 사항을 신속하게 전파하기가 어렵다. 모델(Model)과 뷰(View)의 수가 커지고 데이터의 흐름이 양방향으로 이루어질 수록, 전파해야 할 대상도 함께 늘어나기 복잡도는 더욱 증가하고 디버깅 및 코드를 이해하기 어려워진다. 때문에 MVC는 작은 앱에 어울린다는 것이다. (리액트는 단방향 바인딩을 한다.)
• 실제로 배달의 민족에서도 MVC 패턴을 써서 해오다, 서비스가 커지니까 기존 MVC 패턴으로는 해결이 안돼서 Webflux라는 것을 도입했다고 한다.

참고자료

• 배민의 선택이 더 궁금하다면, 이 영상을 참고하면 좋다.
• MVC패턴이 왜 생겨났는지 알고 싶다면 이 자료를 참고하면 좋다.
• 리액트의 Flux 패턴에 대해 더 알고 싶다면 이 자료와 영상또는 Flux로의 카툰 안내서를 참고하면 좋다.

MVC 패턴에 대해 더 알아보자

• MVC 패턴은 매우 효율적인 방식이지만. 규모가 커지면 '컨트롤러 (정보를 만들어내는 방식 (필터링 / 알고리즘))' 부분이 계속 커져서 속도가 느려지는 단점이 있다.
• MVC 패턴은 대부분 Blocking I/O (인풋, 아웃풋) 방식을 사용하기 때문이다. Blocking I/O 방식은 자신의 일이 끝날때까지 대기하다가 모든 일이 끝나면 그제서야 다음 일을 받는 방식이다.

리액트는 컴포넌트를 사용한다

우리는 컴포넌트를 사용하여 React에게 화면에 표현하고 싶은 것이 무엇인지 알려줍니다. 데이터가 변경될 때 React는 컴포넌트를 효율적으로 업데이트하고 다시 렌더링합니다.

• 리액트를 사용하면 컴포넌트라는 재사용가능한 UI 블럭조각을 통해 복잡한 앱을 효율적으로 만들 수 있다.
• 컴포넌트는 재활용 가능한 UI 구성 단위이다. 캡슐화를 컴포넌트별로 시켜주기 때문에, UI가 재활용 가능한 것이 큰 장점이며 유지보수 측면에서 뛰어나고 페이지의 구성을 한눈에 파악할 수 있다.

리액트는 단방향 데이터 흐름을 가지고 있다

• React는 Reactive 한 단방향의 데이터 흐름을 가지고 있다. Reactive하다는 것은 상태(state)가 바뀌면 상태에 의존하는 뷰도 함께 업데이트된다는 것이며, 단방향 데이터 흐름이라는 것은 한 방향으로 데이터가 흐른다는 것이다. 데이터는 상위 컴포넌트(Parent)에서 하위 컴포넌트(Children)로 흐르게 되어 있는데, 이 데이터는 React에서 prop이라고 지칭되며, JSX에서는 HTML의 attribute처럼 작성된다.

• 데이터 바인딩에 대해서 더 궁금하다면, 이전 글을 참고하면 좋다.

참고자료

• https://blog.gaerae.com/2016/04/hello-react.html
• https://jaeholee.org/react-guide-for-hipsters/