Angular5 -> React + next.js 로 프로젝트 갈아 엎은 썰 (Angular vs React 개인적 비교)

회사에서 fanzeel.com 을 리뉴얼 작업을 하였는데, 

개발 결과물의 표면적인 부분은 '[개발후기] FANZEEL.COM 리뉴얼' 이 글에 남겨 두었으며, 

이 글은 Angular 에서 React 로 변경하면서, 기술적인 측면에서 느낀점과, 두 라이브러리(프레임웍)을 개인적인 취향으로 비교하며 기록하고자 한다.

기존 환경(변경 전).

기존 fanzeel.com 환경은 프론트는 Angular5, 백엔드와 API 서버는 PHP 로 만들어져 있었다.

변경하게 된 동기.

사실, 다 만들어서 잘 돌아가고 있는 서비스를 갈아 엎는다는게 쉬운 결정은 아님에도 불구하고, 프로젝트를 갈아엎기로 결정한 몇가지 이유가 있는데, 가장 중요한 이유는 'SEO 문제' 였다.

-  Fanzeel.com 특성상, 페이지를 페이스북이나 카톡으로 공유할 때, '미리보기'가 완벽하게 지원되길 원하셨는데, Angular 같은 SPA 방식과는 SEO 와 상극이다.

- 그래서 어쩔 수 없이, PHP에서 라우팅을 처리해주면서, 메타데이터를 변경해 주고, 실제 내용은 Angular 가 로드 되도록 변경했다. 이 작업에 대한 내용은  Angular4, SEO 와 페이스북 공유 크롤링 봇을 위한 몸부림 이 글에 상세히 적어두었다. 이렇게 Meta 데이터를 동적으로 응답해 주므로, '페북' '카톡' 미리보기 는 해결을 했으나, 막상 주된 내용은 HTML 에는 없고, Client단의 Javascript 가 실행되야만 내용이 '표시' 되기 때문에, SEO 에 결단코 좋을리가 없다.

- 상황이 이렇다보니, 내가 만든 프로젝트가 "끔찍한 혼종" 과같이 보여 자괴감이 들었다. 처음 야심차게 코딩한 Angular 에서 제공하는 라우터, RouteReuseStrategy 상태관리 등, 쓸모없게 되어버릴 뿐더러, Angular 가 제공하는 그 수 많은 좋은 기능들이 그저 거추장스럽고 무거워 보일 뿐이였다.

그래서 이번 리뉴얼에서 디자인을 완전히 변경하면서, 데이터의 구조도 변경되어야 했기 때문에, 어차피 거의 대부분 코딩을 다시 해야 하는 판에, 프로젝트 자체를 변경하기로 결심하였다. 

REACT 로 결정.

- React 자체가 PHP 에서도 SSR을 지원하는 점.

- View 라이브러리 이기 때문에, 불필요한 기능들 없이 가벼운 점 때문에 우리 프로젝트와 가장 어울린다고 판단했다.

- Angular Universial 도 생각을 해보았지만, 백엔드 변경에 대한 부담 + Angular Universial 에 대한 문서나 참조할만한 아티클들이 React 에 비해 굉장히 적어서 탈락.

첫번째 시도 - 뷰만 React로 변경, 백엔드/API 서버 = PHP로 유지하자.

  개인적인 욕심으로는 이참에 Node.js 로 가고 싶었으나, 시간도 없는데, 경험도 없는 Node.js 로 백엔드까지 변경하기엔 무리라고 생각했다. 그래서 라우팅을 비롯한 백엔드 / API 서버는 PHP 를 조금만 수정해서 쓰기로 하고, View 만 React 로 다시 만들자고 결론을 내었다.

  그렇게 결론을 내고, 작업을 시작했는데... 테스트 환경을 만들기가 정말 HELL 이였다!!!!!!  

  처음의 계획은 아래와 같다.

- PHP에서 라우팅을 받아서, 필요한 데이터를 가공해 React 컴포넌트 props 에 데이터를 전달해 준다.

- React 의 컴포넌트를 서버사이드 렌더링을 거쳐서 HTML 문서로 응답을 내보내 준다.

  그런데 막상 리액트에서 뷰를 만드는 작업을 하려하니, PHP에서 이미 "데이터를 'props'에 전달받았다." 라는 가정하에 코딩을 해야 하는 상황이 온것이다. 서버와 React 단이 완벽하게 분리되어있기 때문에, 원활한 테스트를 할 수 가 없는 것이다! 물론, 데이터를 json 형태로 임시로 박아놓고서, 뷰를 개발하는 방법이 있지만, 정말... 개발자로서 스스로 자괴감을 느낄만한 아이디어인것 같다. 이 테스트환경을 꾸미기 위해 또다른 연결고리를 억지로 만들 방법이... 생각나지도 않고, 생각하기도 싫었다.

그래서 결국, API 서버만 그대로 둔 채, 서버까지 Node 로 완전히 갈아 엎기로 결심하게 되었다.

React+Next.js 와 만남.

Next는 정말, 내가 생각했던 SSR 과 CSR 의 좋은점만 아주 딱 조합하여 제공해주는, 매우 아름다운 솔루션이였다. 이에 관련한 내용은 '18.06.11. React - Next.JS 로 SSR 환경 꾸미기.' 에 기록해 두었다. 

- Next 에서 제공하는 튜토리얼이 매우 좋아서, Next 가 어떻게 동작하는지 금방 파악할 수 있었다.

- pretty url 을 사용하기 위해서는 Node - Express 도 함께 조합해서 사용해야 했는데, 그것 역시 next 의 튜토리얼에 상세히 나와서 어렵지 않았다.

- 그 외에도, scss, mobx, redux, 뭐 등등등등 생각할 수 있는 많은 라이브러리들의 조합을 직접 example 프로젝트로 제공하고 있어서 너무너무 좋았다. https://github.com/zeit/next.js/tree/master/examples 여기에서 확인해 볼 수 있다.

- Next.js 의 이런 세심한 배려 때문에, 내가 비록 Node 를 처음하는데도 불구하고, 정말 금방 프로젝트를 구조를 잡고 시작할 수 있었다.

- 또 next 를 만든 zeit 에서 만든 'now' 라는 서비스를 사용해 보았는데. 실서버 테스트를하기에 너무 좋았다.

React 와 Angular 의 비교 (지극히 개인적인 의견)

1. TypeScript

 

  Angular 는 TypeScript 가 기본이다. 처음 Angular를 할 때, TypeScript 로 되어있어서 너무 좋았다. 그러나, 프로젝트를 오래 하다보면, javascript 라이브러리를 쓰는경우들도 많이 생기고, 또 자잘한 모델들은 귀찮아서 그냥 any타입으로 처리해 버리는 경우들이 생기게 된다. 그러다보면 TypeScript 의 의미가 조금 퇴색하는 느낌이 든다. 물론, 약간의 노력을 더 해준다면 TypeScript 스타일의 개발기조를 지킬 수 있을것이지만, 하다보면 그게 거추장스럽게 느껴지는 때가 종종 있다.

  그래서 React 는 그냥 javascript 로 시작했다. (React+Next 에 TypeScript 를 지원하는 example이 있지만) TypeScript 는 Javascript 의 단점을 보완한 훌륭한 대안이고, TypeScript로 했을 때의 장점을 매우 잘 느끼고 있음에도 불구하고. 그래도 그냥 최종 결론은 그냥 Javascript 로 결정하게 된다. 나도 내가 왜 이런 묘한 감정을 가지는지 정확한 이유는 모르겠는다. TypeScript 는 멋진데, 그냥 Javascript 가 막 편하게 쓰기 좋은 느낌이랄까.

2. 양방향 Binding 과 rxJs 

  

  React 와 Angular 를 비교할때 가장 많이 의견이 갈리는 부분이 이게 아닐까 싶다. 2-way binding 을 칭송하는 사람들도 있고, 극혐하는 사람들도 있더라. 두개 모두 특징과  장/단점이 명확하기 때문에, 그야말로 우열을 가릴 수 없는, 지극히 개인취향 문제인것 같다. 

  비슷한 프로젝트를 Angular 와 React 두개 모두로 만들어 본 결과, Angular 에서도 1-way 방식으로 쓸 때도 있더라. Angular 에서는 모두들 습관처럼 [(모델)] 이런식으로 양방향으로 쓰는것으로 보이는데, 프로젝트를 하다보면 [모델] 또는 (모델) 이런식으로 단방향으로 하는게, 논리적으로 더 맞는 특수한 상황도 더러 생긴다. 요컨데, 1-way 방식이 더 편하게 느껴질 때도 더러 있다는 얘기다.

 * [(모델)] 의 의미는 Angular 를 사용해보면 알게되므로 자세한 설명은 생략하겠다.

  그렇다면 React 는 완벽한 단방향을 지향함으로써 잇점을 모두 챙기고 있을까? 꼭 그렇지도 않은것 같다. 예를 들어 <input> 이나 <textarea>를 활용하는 부분을 보자. 거의 대부분의 예제들이 <input value={this.state.text} onChange={onChangeText} /> 이렇게 해놓고 한글자 한글자 입력할 때마다 this.setState 를 호출해주는 방식의 예제를 보여준다. 물론 가장 React 다운 방식인데, 이렇게 할거면 실제로 양방향 바인딩을 하는것과 다른것이 무엇인지 의문이 들며, 오히려 양방향 보다 안좋은 결과가 나올 때도 있다. 그 이유는 setState가 비동기적으로 처리되기 때문인데, 이와 관련된 내용은 https://brunch.co.kr/@hee072794/108  에 있으니, (이 내용에 전적으로 동의하지는 않지만) 참고해보자. 그 고충과 고민을 엿볼 수 있다.

  그렇다고 기본적으로 단방향을 지향하면서 setState 를 활용하는게 양방향에 비해 열등하다는 얘기는 아니다. 위에 쓴 부분은 <input>을 활용할 때의 예로써, 프로젝트 전체 중 매우 일부분일 뿐이고, 나는 기본적으로 단방향을 지향하면서, 프로그래머가 여러 작업들을 직접 제어한 후에, setState 로 일괄적으로 처리하는 방식은, 좋은 아이디어라고 생각하며, 내 취향에도 맞다.

  둘다 장/단점이 명확하다. 그래서 내 결론은... 기본적으로는 리액트의 단방향 개발기조를 따르면서, 특수한 경우에 mobx 를 활용해서 양방향 모델을 사용한다.

3. JSX <-> HTML형식의 템플릿.

  Angular 에서 HTML 처럼생긴(?) 템플릿 기반으로 작업을 하다가, JSX를 처음 봤을 때, '페이스북이 요상한걸 만들어냈다' 라고 생각을 했다. 근래의 웹 개발은 HTML, CSS, Javascript 를 모두 분리해서 개발해야 제맛(?) 이건만, JSX는 html 도 아니고, javascript 가 뒤죽박죽인것 처럼보였기 때문이다. 

  그러나 한번, 'View 와 logic 의 완벽한 분리'라는 고정관념(?)을 약간 버려보자. 과연 현대의 웹에서 view와 logic 이 완벽하게 분리되는게 과연 효율적인걸까? 현대의 우리는 예전과 달리, 굉장히 역동적인 웹을 보고 있다. ajax는 기본이 되었고, 수려하고 멋진 웹페이지를 만들기 위해, 수없이 많은 인터랙션을 필요로 하게되어, 이 둘은 이제 뗄 수 없는 관계가 되버린듯 하다.

  여튼, 처음에는 JSX가 요상하게 보였으나, 지금은 오히려 더 편하다. 

4. Component 정의 / 사용

  Angular에서 모듈과 컴포넌트 관리는 정말 귀찮았다. 뭐 간단한 컴포넌트 하나 만드려면, 관련된 파일 만들고, 컴포넌트 정의하는데만 필수적으로 써줘야 하는 코드들 쓰고, 모듈에 등록해주고, 정말 귀찮았다. 그러다보니, 컴포넌트 단위를 잘게 쪼개서 재사용 하면서 쓰는 장점을 극대화하지 못하고, 컴포넌트 자체가 조금씩 비대해 지는 경향이 있었다. 

  그에 비해 React 는, 컴포넌트를 등록할 필요도 없고, functional 컴포넌트 (혹은 dumb 컴포넌트)가 있어서, 아주 가볍고 매우 작은단위의 컴포넌트를 만들어서 사용할 수 있었다. 매우 만족스럽다.

5. 생태계 

  개인적 취향으로써, 하나하나 따질때 Angular 의 특징을 선호하는게 많긴 하지만, 결국 React 를 선택하게 된 가장 큰 이유가 이것 아닐까 생각한다. Angular 는 이미 모든걸 다 잘 갖췄다. 그에비해 사실 React 는 딸랑 View 라이브러리 일 뿐이다. 그래서 오히려 React 의 생태계가 훨씬 커진게 아닐까 혼자 생각해본다. Angular 작업을 하다가, 막히는게 있어서 검색을 해보면, 몇몇 답안을 찾아낼 수 있다. React 작업을하다 궁금해서 검색을 하면, 오만가지 방법과 대안들, 라이브러리들이 나온다. 이런 생태계 때문에 나는 결국 React 를 선택하게 된것 같다.

6. 완성된 프로젝트의 주요 구성.

- React + Next.js

- express 

- mobx 

- material-ui, react-bootstrap 

- tinymce-react 

- axios 

- node-sass 

마치며...

  이미 운영중인 product 서비스 프로젝트를, 처음부터 갈아엎는다는건 정말 고민이 많은 결정이였다. 고민이 많이 되어, 예전에 생활코딩에 설문도 한적도 있었다. 그때 설문의 결론은 약 8:2 의 비율(?)로 "갈아엎어라" 가 우세했다. 그때는, 결과를 받아들고서도, '남의 일이라고 쉽게 바꾸라 하는구먼~' 하는 마음으로 거부하고 싶었다. 

  그러나 지금은 매우 만족스럽다. 완전히 바꾸길 잘했다. 최신의 기술들을 접목해서 개발하는 환경이 매우 쾌적해졌다. 지금은 비록 API 서버가 PHP 로 남아있지만, 이후의 모든 프로젝트는 Node 로 하려고 한다.