티스토리 뷰

Review

Angular 개발자의 React 사용기

그랩그랩 2017. 11. 17. 19:11

 no more react...


Before...


  이 글을 보시는 React를 사랑하는 모든 분들에게.


  애초에 이 글을 쓰게 된 계기가 React를 쓰면서 불편했던 걸 토로 하는 글이기 때문에 React를 좋아하시는 분들에게는 마음이 불편해질 수도 있을 글이라고 생각됩니다. 혹시라도 그렇다면 미리 사과 드리겠습니다. 


  또한, 웹을 이제 겨우 1년 조금 넘게 하고 있고, React는 1달 밖에 사용해보지 않았습니다. 그래서 React에 대해 오해를 하고 있을 수 있습니다. 제가 적은 React의 불편한 점 중에 React의 문제가 아닌 다른 문제 이거나, 이미 만들어진 React 기능이 있음에도 알지 못하여 사용 못한 각종 기능, 라이브러리들이 있다면, 댓글로 알려주면 바로 수정을 하겠습니다. 


  여러분의 댓글이 웹 뉴비, React 뉴비인 제가 성장할 수 있는 발판이 됩니다. 감사합니다.


1_태생적 특징


  Angular의 공식 문서인 angular.io에 들어가면 처음 보이는 문구는 'One framework. Mobile & Desktop.'이다. 그러면 React는 어떨까. React의 공식 문서인 reactjs.org에 들어가면 처음 보이는 문구는 'A Javascript library for building user interfaces'이다.


  여기서 주목할 단어는 framework와 library인데, 그 차이점은 나도 잘 모르기 때문에 구글에게 물어봤다.

출처 : https://www.quora.com/Whats-the-difference-between-a-library-and-a-framework


  라이브러리는 재사용 가능한 코드 조각인데 그 코드 조각은 개발자가 '호출해서' 사용된다. 고 설명하고 있으며, 프래임워크역시 코드 조각인데 프로젝트의 '아키텍쳐를 결정하고' 개발자는 그 구조에 맞춰 개발하는 것이라 설명하고 있다. 이 설명은 Angular와 React를 잘 설명한다고 생각한다.


  먼저 Angular는 당신의 프로젝트에 필요한 거의 모든 것을 가지고 있다고 생각하면 된다. 페이지를 이동시키는 Router Module, 폼을 관리하는 Form Module, 심지어 최근에는 Prograssive Web App을 개발하기 위한 Service Worker Module도 포함 되었다. 공식 문서의 문구 처럼 Angular 하나만 가지고 어떤 웹 서비스를 만들던지 왠만하면 추가적인 라이브러리는 설치하지 않아도 된다는 뜻이다.


  그에 반해 React는 공식 문서의 문구처럼 User Interface에 관련된 내용만 가지고 있다. React의 특징을 설명하는 글들을 보게 되면 자주 보이는 말인 React는 MVC 패턴 중에 V인 View만 담당한다. 그렇기 때문에 Router, HTTP Request를 사용하려면 추가적인 라이브러리를 설치를 해야한다는 것이다. Router의 경우에는 react-router라는 '공식은 아니지만 공식 처럼 쓰이는' 라이브러리가 있기 때문에 고민 없이 설치하여 사용하지만, HTTP Request의 경우에는 request, axios, async await 등 그것을 할 수 있는 라이브러리들이 많이 있고, 어떤 것을 쓰라는 공식적인 가이드라인이 없기 때문에 어떤 것이 쓰기 편하고 좋을까 고민하게 된다.


  개인적으로 이 점이 React를 한 달 동안 사용하면서 가장 마음에 안들었는데, React에는 Angular의 Tour of Heroes 같은 튜토리얼이 없기 때문에 (이걸 가지고 튜토리얼이라고 하지 말자...)(React는 뷰만 관리하는 라이브러리리이기 때문에 튜토리얼이 저것만 있을 수 밖에 없긴하다.) Stackoverflow에 비슷한 오류를 검색을 하면 질문자는 나와 다른 라이브러리를 사용하고 있어서 답변을 봐도 내가 React를 구현하는 곳에서 잘못한 건지, 라이브러리를 사용한 곳에서 잘못한 건지 헷갈리게 되고, 검색 시간이 늘어나게 된다. 또한, 필요한 여러 라이브러리를 설치하여 쓰다보면, 각각의 공식문서를 띄워놓고 보게 되는데 앞에 말한 것 처럼 어느 라이브러리를 사용하면서 실수를 했는지 모르면 그 각각의 공식문서를 이리 둘러보고 저리 둘러보게 된다는 것이다. 특히 공식문서의 설명이 잘 되어 있지 않은 라이브러리를 쓰게 된다면 검색을 위한 인터넷 탭은 점점 늘어난다...


  이러한 이유 때문에 React를 단독으로 사용함에 있어서는 러닝 커브가 크지 않지만, 필요한 기능에 대한 라이브러리 선정이라던지, 오류에 대한 검색의 용이성, 각 라이브러리의 공식 문서의 완성도를 생각해보면 Angular의 러닝 커브와 React의 러닝 커브는 크게 다르지 않다고 생각한다. RPG 게임으로 예를 들자면 Angular는 어렵지만 익숙해질 수록 좋은 캐릭터라면 React는 쉽게 쓸 수 있지만 잘 하려면 어려운 캐릭터 인 것 같다.


  그리고 Angular에 대한 오해 중에 Angular가 내가 안쓰는 모듈까지도 전부 가지고 있어서 쓸데 없이 무겁고 느려지는 것이 아니냐 라고 생각할 수 있는데 Angular에서만 지원하는 AOT를 이용하게 되면 웹 앱의 로딩속도가 상당히 빨라지고, React와 마찬가지로 Tree Shaking을 통해 사용하지 않은 모듈을 전부 털어낸다. 또 Router에서 Lazy Loading을 쉽게 구현 할 수 있으며, Lazy Loaing을 적용한다면 더 빠른 로딩 속도를 기대할 수 있다. 따라서 Angular가 느리다는 것은 절대로 오해라고 생각한다. (벤치마크 링크)


2_실 사용


  필자는 C++을 처음 배우던 1학년 때에도 코드가 길어져서 스크롤을 하루종일 해야하는 코드는 상당히 싫어했다. 단일 클래스(함수) 단일 책임에 대한 개념을 잘 모르던 때에도 왠만하면 작게, 짧게 코딩하는 것을 좋아했다. 그런 성격 탓인지 Angular를 쓰면서 마음에 들었던 것은 HTML, CSS, Typescript가 서로 다른 파일로 나눠졌고, 왠만해선 페이지 구조는 HTML, 스타일은 CSS, 로직은 Typescript에 서로 담기는 것이 너무나 마음에 들었다. 


  그런 상태에서 React를 처음 만났을 때 render()를 보는 순간 한숨만 나왔다. Javascript 코드와 HTML이 한 곳에 있을 뿐더러 서로 뒤섞여 있었다. 그리고 컴포넌트를 나눴음에도 불구하고 CSS는 왜 다른 컴포넌트에도 영향이 가는지 이해를 할 수 없었다. 이걸 가지고 웹 앱을 만들었을 때 유지보수가 용이할까? 에 대한 의구심이 만드는 내내 커져갔다.


  또, Form의 입력을 처리하는 과정에서 React는 Angular에 비해 이해가 안되는 과정을 거쳐야 한다.


  위의 코드는 각각 React와 Angular를 가지고 Login을 하는 Component를 만든 것이다. 둘다 form element와 input element를 가지고 Login Form을 구성하였다. Angular는 Reactive Form Module을 이용해 폼을 관리하는 Form Group을 만들었다. 이렇게 했을 때 이용자가 input element에 입력한 값이 단방향 바인딩으로 FormControlName으로 설정한 곳에 실시간으로 들어간다. 하지만 React가 View를 담당하는 라이브러리임에도 불구하고 폼 모듈이 따로 없어 단방향 바인딩 조차 onChange를 이용해서 함수를 직접 만들어 써야 한다는 점에서 상당히 실망했다.


  물론 Angular도 check input의 경우나 입력된 값을 처리해야하는 과정이 필요하면 onChange를 이용하지만,(심지어 onChange를 사용하지 않아도 Form control에 속한 함수 중에 입력값을 Observable stream으로 만들어주는 valueChanges 함수를 이용할 수도 있다.) React는 기본 text input의 경우에도 번거로운 일을 해야한다는 것에 많이 실망했다. React만 이용했을 때 상태 관리가 쉽지 않다는 것은 React를 사용하는 분들이라면 알 것이라 생각하는데 빈번한 값 변경이 일어날 수 있는 Form에서 조차 개발자에게 짐을 떠넘기는 듯한 느낌이었다.


  React를 쓰면서 state와 props를 관리하는 것이 정말 어려웠다. React에서 props는 Child component 입장에서 값을 바꿀 수 없기 때문에, Child component에서 Parent component로 상태를 전달 하려면 Parent component에서 자신의 state를 변경하는 함수를 만들고 함수를 props로 Child에 전달하고 값 변경시에 그 함수를 이용해 Parent에 넘겨주는 방식으로 상태를 변경해야한다.


  이 때, Angular에서 비교할 수 있는 것은 @Input, @Output, Service인데, 여기서 @Input은 props와 같은 역할을 한다고 보면되고, @Output은 Child component에서 Parent component로 상태를 전달할 수 있게 해주는 Decoration이다. 그리고 Service는 멀리 떨어져있는 컴포넌트와 직접 상태를 공유하고 싶을때 사용할 수 있다. 


  자식에서 부모로 상태를 전파하는 과정은 React와 Angular가 각각 함수를 부모에서 내려서 자식이 값을 담아주느냐, 자식이 상태 변경이 일어나면 변경된 상태를 부모에게 올려주느냐 차이이므로 넘어갈 수 있지만, 여러 컴포넌트에서 공통으로 필요한 상태라던지, 멀리 떨어진 컴포넌트와 상태를 공유에 해야한다던지 한다면, React를 이용할 때는 점점 난감해지면서, Redux와 Mobx를 기웃기웃 거리게 된다.


  물론, Angular에서도 Redux나 Mobx 같은 상태 관리 라이브러리인 ngrx가 있다. 하지만, 나는 Angular를 사용하는 지난 1년동안 한번도 그런 것을 써야 할 것 같다라는 생각을 가져본 적이 없다. (Angular 커뮤니티에서 Angular와 Redux를 쓰시는 분이 정말 편하다! 라는 말이 있어서 써 볼까? 라는 생각은 해본 적 있다.) 하지만, React를 사용하는 지난 1달 중에 HTTP Request를 받아오기 시작한 1주가 조금 지난 시점에 Angular에서는 느끼지 못했던 상태 관리에 대한 어려움이 나타나기 시작하면서, Mobx를 고려 하였고, 그 주에 Mobx를 도입하였다.


  이것은 내가 React의 상태 전파에 대해 이해를 잘 하지 못한 상황 때문에 왔을 수도 있다고 생각한다. 하지만 React를 사용하는 사람 중에 Redux나 Mobx를 사용하는 사람은 꽤 있지만, Angular를 이용하면서 Redux나 여타 상태 관리 라이브러리를 이용한다는 사람은 별로 본 적이없다는 것을 봐도 느껴지지 않는가?


3_맺음말


  정리하자면, React는 태생부터 View를 다루기 위해 나온 라이브러리였고, 다른 것들은 생각지 않기로 했기 때문에 Router같은 하나의 웹 앱을 만들기 위해 필요한 모듈들이 거의 포함되지 않았다. 그럼에도 사람들은 React를 사용해 웹 앱을 만들기로 했기 때문에 React Router 등을 만들어 사용하였고, 사용하는 라이브러리가 사람마다 다르다 보니 사람마다 다른 React 생태계를 가지게 되었다. 이것이 `활발한` React 생태계의 뒷모습이라고 생각한다.


  또한, state와 props를 이용한 상태 관리가 쉽지 않았기 때문에 Dump component, Smart component를 거쳐 Flux => Redux, Mobx 등 상태 관리 라이브러리 등이 나오기 시작했으며, 다양한 React의 라이브러리들 때문에 러닝 커브가 시작은 미약하지만, 끝은 창대해져버리는 상황이 오게 되는 것이다.

  이에 반해 Angular는 태생부터 하나의 프레임워크로 모바일에서 데스크탑 앱까지 만들게 할 것이라는 목표를 가지고 나왔기 떄문에, 하나의 앱을 만들 수 있는 모든 모듈을 담고 있다. 처음부터 모든 것을 가지고 있다는 것 때문에 Angular의 생태계는 그다지 활발해 보이지 않는다.

  또한, 사람들의 생각에 `내가 쓰지 않을 요상하고 이상한 모듈도 내 프로젝트에 가지고 있기 때문에 이것을 이용해 웹 앱을 만들면 느릴꺼야`라고 생각하지만, AOT와 Tree Shaking을 통해 프로젝트 Building 과정에서 필요 없는 모듈은 떨어져 나가며, 몇번의 버전업을 하면서 최적화를 하여 벤치마크에서도 React에 밀리지 않는 수준까지 오게되었다.

  그럼에도 Angular는 러닝 커브가 빡센 편이며, 처음부터 Angular를 이용해 웹 앱을 만들 생각이라면 힘들 것이라고 생각한다. 하지만, 다른 웹 앱을 만들 수 있는 라이브러리, 프래임워크를 사용해봤다면, 당신이 생각하는 것보다 쉽게 사용할 수 있을 것이라 생각한다. 내가 React를 하면서 아, React를 하고 Angular를 했으면 옛날에 처음 Angular를 했을 때보다 더 쉽게 적응 했을 것같다 라는 생각을 했는데, 그 이유는 React 등을 사용해 컴포넌트, 라우터 등에 대한 이해를 한 뒤에 Angular를 사용한다면 Angular에서 컴포넌트나 라우터를 어떻게 만드는지만 알면 되기 때문이다.

  만약에 당신이 Typescript, Rxjs 등과 같이 처음 보는 것들에 두려움을 느낀다면, 당신이 하고 싶은 작은 Toy Project 혹은 Angular 공식 튜토리얼인 Tour of Heroes를 먼저 해보면 좋을 것같다.

  끝으로 앞에서도 말했지만, React를 사랑하는 분들이라면 이 글이 오류 투성이고 React에 대해 오해를 가득 가지고 있는 글이라고 생각할 것이다. 그렇다면 댓글로 알려주길 부디, 제발, 부탁한다. 나도 둘다 잘하고 싶다...


'Review' 카테고리의 다른 글

프론트엔드 개발자의 React 사용기  (0) 2018.04.24
Adieu! 2017. Bonjour! 2018,  (0) 2018.01.01
웹 뉴비의 Angular 1년 -하-  (0) 2017.10.26
웹 뉴비의 Angular 1년 -중-  (0) 2017.10.26
웹 뉴비의 Angular 1년 -상-  (0) 2017.10.26
댓글
Total
Today
Yesterday
공지사항
최근에 올라온 글
최근에 달린 댓글