리액트

리액트의 평가

리액트는 현재 세계에서 가장 많이 사용되는 웹 애플리케이션 UI 구축 라이브러리이다.


https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/ 출처

위의 평가에서 확인할 수 있듯이 현재 세계에서 가장 많이 사용되고 있는 라이브러리이다.

리액트의 특징

선언형 프로그래밍

내가 느낄 때 선언형 프로그래밍은 인터페이스 프로그래밍의 느낌이다. 기본적을 선언형 프로그래밍은 명령형 프로그래밍과 대치되는 개념인데, 명령형 프로그래밍은 구현의 내용이 모두 구구절절히 적혀있는 프로그래밍, 선언형은 방법보다는 결과에 초점을 맞춘 프로그래밍 방식이라는 점이라는 것이다.

예를 들어, reduce라는 js 함수를 보자. 우리가 sum 이라는 배열의 모든 합을 구하는 함수를 구할 때 reduce를 사용한다.

const sum = (array) => array.reduce((acc, val) => acc + val, 0);

우리는 reduce가 내부적으로 어떻게 배열을 돌고 합을 구해내는지 전혀 알지 못하지만, 결과가 어떻게 나올 것을 알고 있다. 이런 게 선언형 프로그래밍이다. 즉 초점 자체가 내부 구현보다는 그것을 사용하는 입장에 맞춰진 프로그래밍 개념이다.

const sum = (array) => {
 let result = 0;
  for(const element of array){
   result += element;
 }
  return result;
}

이게 명령형 프로그래밍이다. 내부적으로 어떤 원리로 해당 로직이 돌아가는지 알 수 있다. 하지만 프로그램이 복잡해지면 해질수록 사용자는 이 내부 로직을 알 필요가 없다. 그렇기 때문에 사용자는 선언형으로 프로그래밍을 할 수 있도록 만들고, 내부적으로 이 선언형에 대한 처리를 모두 대신 해주도록 만드는 것이다.

실제로 리액트는 사용자가 양식에 맞춰 컴포넌트만 만들어주고, 해당 메서드나 hook이 호출될 때 작동할 함수만 만들어준다면, 내부 상태 변화, 렌더링 등의 동작들을 모두 자동으로 해준다. 이런게 선언형 프로그래밍이다.

컴포넌트 시스템

리액트는 컴포넌트 시스템을 기반으로 동작한다. 이전에는 웹 프로그래밍을 할 때 컴포넌트로 작동시키는 것이 거의 불가능했다. 자바스크립트는 모듈을 지원하지 않았기 때문에, 모든 파일이 하나의 환경을 가질 수 밖에 없었다. 또한 마크업, css, js 로직을 한 곳에 묶어서 관리하는 것도 불가능했다.

이런 시스템은 유지보수와 재사용에 엄청나게 불리했고, 대규모 웹 애플리케이션을 관리하기란 쉬운 일이 아니었다. 모듈이 도입되면서 컴포넌트 기반 프로그래밍 이론이 나왔고 이것이 CDD 이다. 프로그램의 단위를 컴포넌트로 쪼개고, 이를 하나의 모듈로 관리하는 방법이다. 그리고 리액트는 한 걸음 더 나아가서 마크업, 스타일링, 로직을 하나의 모듈에서 관리할 수 있도록 만들어 유지보수성을 높혔다.

CDD

품질	독립적으로 컴포넌트를 분리하여 관련 상태를 정의하여 UI가 다양한 시나리오에서 작동하는 지 확인 가능합니다.
내구성	컴포넌트 수준에서 테스트하여 세부 사항까지 버그를 정확하게 찾아낼 수 있습니다. 테스트 보다 작업량이 적습니다.
속도	컴포넌트 라이브러리 또는 디자인 시스템의 컴포넌트를 재사용하여 UI를 보다 빠르게 조립할 수 있습니다.
효율성	UI를 개별 컴포넌트로 분해 한 다음 서로 다른 팀 구성원 간에 공유하여 개발 및 디자인을 병렬 처리합니다.

멀티 플랫폼 지원

리액트는 브라우저에서만 동작하지 않는다. react-native 라는 라이브러리를 이용해 모바일 환경에서도 동작할 수 있다. 또한 일렉트론이라는 데스크톱 환경을 이용해 데스크톱 어플리케이션도 개발할 수 있다.

리액트의 발전 과정과 학습

리액트는 리액트 단독으로만 보면 UI 를 렌더링하는 라이브러리이다. 즉, 리액트 하나로 단독적으로 작동할 수가 없다는 것이다. 페이스북에서 만든 수많은 리액트와 관련된 라이브러리가 함께 작동하면서 이 리액트 생태계를 구성한다.

즉, 이 말은 리액트를 배우면서 관련된 라이브러리를 엄청나게 배워야 한다는 뜻이다.

위의 그림에서 나와있듯이, 가장 기본적으로 가상 DOM의 개념에 대해 알아야 한다. 가상 DOM 은 리액트를 특별하게 만들어주는 요인 중에 하나이다. 이 가상 DOM 에서 JSX 라는 문법이 파생되고, 이 JSX 와 상태가 합쳐져서 컴포넌트라는 개념이 완성된다. 내가 정의하는 리액트는 상태 기반 컴포넌트 렌더링 라이브러리이다.

렌더링은 JSX 와 virtual DOM 을 통해서 구현한다면 상태는? 이 상태를 관리하기 위해 클래스 컴포넌트에서는 생명주기 메서드가 구현되었다. 각 컴포넌트의 상태 변화에 따라 해당 컴포넌트의 생명 주기가 변경되고 이 메서드가 호출되면서 등록된 로직이 실행되는 것이다.

클래스 컴포넌트의 문제

이 클래스 컴포넌트는 문제가 있었다.

1. this 바인딩 문제

this 바인딩은 자바스크립트에서 고질적인 문제를 가지고 있다. 함수 호출 방식에 따라 바인딩이 다르게 일어나는 것이다. 즉, 사용자가 해당 this 에 대해 계속 신경을 써주어야 되는 것이다. 그리고 클래스 컴포넌트는 이 this가 남발된다.

2. 로직의 절단 및 중복

생명주기 메서드를 사용하다보면 componentWillMount 와 componentWillUnMount 의 로직이 연결되어야 하는 경우가 있다. 어떤 이벤트를 컴포넌트가 만들어질 때 붙이고, 제거될 때 삭제되어야 되는 경우, 하나의 로직으로 연결되는 게 자연스럽다. 하지만 이 내용이 메서드가 분리되면서 부자연스럽게 변하는 경우가 있다.
또한 componentWillMount 와 componentShouldUpdate 의 경우 같은 로직을 사용하는 경우가 많다. 첫 렌더링이나, 리렌더링이나 항상 같은 로직을 작동시켜야 하는 경우 중복 코드를 작성해야 하는 문제가 있다.

함수 컴포넌트의 출현

이런 클래스 컴포넌트의 문제를 해결하기 위해 함수 컴포넌트가 등장했다. 함수 컴포넌트는 기본적으로 클래스 컴포넌트의 렌더 메서드를 따로 분리해서 컴포넌트로 만든것이다. 즉, 상태가 없다. (상태를 가질 수 없다.) 리액트 팀은 이런 문제를 hooks를 통해 멋지게 해결했다.

컴포넌트가 각자 가지고 있던 상태를 외부에 저장하고, 함수 컴포넌트는 렌더링만 담당해 외부의 저장해둔 자신의 상태를 가지고 와 사용할 수 있게 만든 것이다.

훅에 대해서는 나중에 자세히 다루겠다. 또한 리액트가 상태 기반으로 동작하는 만큼 이 상태를 다루는 라이브러리들이 많다. 이에 대해서도 차차 정리할 예정.

결론

왜 리액트를 사용할까? 라는 질문은 왜 (뷰나 앵귤러가 아닌) 리액트를 사용할까? 라는 질문으로 바꾸는게 맞다고 생각한다. 리액트만 놓고 보면 사용할 이유가 명백하다. 하지만 뷰나 앵귤러 모두 훌륭한 프레임워크이고, 충분한 장단점을 가지고 있다. 그렇기 때문에 이 비교를 통해 이유를 찾아야 한다.

React vs Vue

1. 코드 형태

React는 UI 렌더링을 담당하는 부분과, 로직을 담당하는 부분을 모두 js 로 만들어야 한다. jsx 를 통해 만들어지는 결과물은 자바스크립트 객체이고 이 부분을 자바스크립트로 이해해야 한다. 반면 vue 는 컴포넌트 내에서 html, css, js 부분을 나누어서 구현하도록 정해두었다. 그렇기 때문에 vue 가 react 보다 가독성과 컴포넌트 응집도 측면에서 우수하다고 할 수 있다. react도 css in js 방식을 통해 마크업, 스타일, 로직을 모두 한 컴포넌트에서 구성할 수 있지만, vue 는 프레임워크 자체적으로 이런 기능을 제공하므로 조금 더 우수하다고 생각한다.

2. 유연성(학습곡선)

나는 개인적으로 유연성이 높다라는 말은 학습곡선(러닝커브) 가 빡세다라는 말로 받아들인다(완전 동의어는 아니지만). 개발자가 자유롭게 기술을 선택해서 사용할 수 있다는 말은, 그 기술에 대해 정확하게 이해해서 가져다 사용할 수 있어야 한다는 뜻이다. 초심자들에게 이런 자유도는 혼란을 야기할 수 있는 부분이라 생각한다.
리액트는 라이브러리이다. 이 말은 기본적인 js 위에서 다양한 라이브러리를 결합해서 리액트를 사용하게 된다는 이야기이다. 반면 vue 는 프레임워크로서 코드 스타일을 고정하고 있다. 그리고 다양한 상태관리 툴, 라우팅 기능들을 제공함으로써 사용해야 하는 기술을 정해두고 있다. 고수가 될 수록 이런 강제성은 불편함으로 작용할 수 있다.

3. 타입스크립트

리액트는 타입스크립트에 최적화되어있다. 나는 개인적으로 타입스크립트를 배우는 것이 좋고, 사용할 수록 좋다고 생각한다. 동적 타입은 처음에는 쉽게 언어에 접근할 수 있게 해주지만, 대규모 서비스를 개발할 경우 타입 지옥에 빠질 수 있다. 리액트는 타입스크립트로 개발하는 것에 최적화 되어 있어, 타입스크립트를 사용한다면, 최고의 선택지가 될 수 있다.

4. 함수형 프로그래밍

가장 큰 차이가 아닐까 싶다. 뷰는 아직 객체 컴포넌트를 통해 구현을 하고 있다. 이건 취향 차이긴 한데, 난 함수 컴포넌트를 더 선호한다. 가독성이 높고, 상태 로직이 더 눈에 잘 보인다고 생각한다.

5. 협업

한국에는 한국에만 유일하게 존재하는 직업인 퍼블리셔가 있다. 일반적으로 퍼블리셔는 html, css 만 다루는 직업이라고 정해져 있고, 이는 자바스크립트만 사용하는 리액트는 국내에서 협업에 불리할 수 있다는 것이다. 특히 뷰의 경우에는 html, css, js 로직을 분리시킬 수 있어, 협업에 이점이 있을 수 있다.

React vs Angular

1. 러닝커브

앵귤러는 러닝커브가 가파르기로 유명하다. 개인적으로 앵귤러는 처음 시작하는 사람이라면 별로 추천하고 싶지않다. 어느정도 프론트엔드에서 공부를 해본 사람이 더 많은 걸 배우고 싶어서 공부하기 시작하는 게 좋다고 생각한다.

2. DOM

리액트는 가상 DOM 을 이용해서 변화를 감지하고 실제 DOM 으로 그려낸다. 반면 앵귤러는 실제 DOM 에서 변화된 부분을 감지하고 이를 DOM에 반영한다.

3. 데이터 바인딩

리액트는 단방향 데이터 바인딩이 가능하지만, 앵귤러는 양방향 데이터 바인딩을 지원한다. 이게 어떤 이점이 있는지는 모르겠지만, 그렇다고 한다.
(난 혼란만 늘지 않을까 싶은데...) 공부해봐야 겠다.

테스팅

테스트에 대한 부분도 고민해보면 좋다고 생각한다. 내가 테스트에 약하기 때문에, 이 부분은 나중에 정리하면 좋을 것 같다.