brunch

You can make anything
by writing

C.S.Lewis

by 메튜 Jul 26. 2016

올 한해, ReactJS개발은 접다.

충동적인 프레임워크 변경에서 오는 후회,

3주정도의 시간이 지난 것 같다. 프로토타입 공정률 50%정도, 나름대로 아키텍처 설계를 잘 하고 이제는 레고블럭 맞추듯이 차곡차곡 만들어 나가면 되는 상황을 또 다시 기술의 '욕심' 때문에 무려 3주의 엄청난 시간을 보내고 이제서야 정신을 차려서 포기하고 다시금 원점으로 돌아간 것이다. 구체적으로 말하면 AngularJS 1로 되어있는 프론트엔드를 요즘 핫하다는 React.JS로 바꾸는 작업을 포기했다.


프론트엔드 개발에 대한 나의 역사(?)


사실 내 개발의 시작은, 그러니깐 96년 쯤에는 무척이나 프론트앤드 개발을 좋아라 했다. 웹을 구성하는데에 필요한 기능인 회원가입, BBS, 방명록 혹은 메인화면에 들어가는 '메모'기능 등은 당시 훌륭하게 공개되어 있단 SP보드, 제로보드 등의 제공으로 굳이 백엔드 개발을 해야 할 필요성을 느끼지 못했다. 나름대로 오픈소스(?)로 되어 있는 소스를 까보기도 하고, 대부분 PHP나 Perl로 개발되어 있는 소스야 캐내면 캐낼수록 재미있긴 했지만 직접적으로 웹 인터페이스와 연관이 되어 있던 프론트앤드 개발이 가장 매력적이었던 것 같다. 지금은 잘 사용하지 않는 VBScript나 Java Applet등을 쓰면서 나름대로 역동적인 기능을 구현하곤 했다. 마우스 roll-over라던가, 메인화면에서 움직이는 이미지 등을 구현했을 때에는 못지않는 희열을 느끼곤 했다.


그런 프론트엔드 개발중심에서 스무살 전후로 SI에 끼어들고 나서 백엔드 개발자로 전향하게 되었다. 시작은 자바 모델 1,2,MVC 등이었지만 닷넷이나 ASP, PHP등 여타 중소규모의 웹 SI업체가 그러하듯이 나 또한 닥치는대로 서버 API기능개발을 해오게 되었다. 그러면서 점차 프론트앤드 개발과는 멀어져 갔다. 아니, 솔직히 말해 프론트개발에 대해서는, OOP적인 사고방식과 컴퓨터 구조, 프로그래밍 언어론, 네트워크, 하물며 클라우드나 분산처리, 그리고 오픈소스까지 이런 다양한 기술집약적인 프레임워크 (예컨데 Spring Framework) 를 이해하는 시간도 그 나름대로 오래걸렸은 뿐더러 차곡차곡 쌓아가는 백엔드 기술에 비해 내가 전에 배웠던 프론트앤드 기술은 매력적이지 않다는 생각이 들었기 때문이다.


그런 착각이 지금의 나의 특히나 프론트 기술에 대한 집착을 낳은것은 아니었을까, 실무에서는 그저 jQuery를 이해하고, 가끔 실무에서 백업으로 나선게 전부, 그것도 아마 스프링이나 JSP, PHP등을 주로 쓰는 당시 국내 웹SI업계에서는 Velocity나 Tiles같은게 있으니 디자인실에서 전달받은 HTML을 템플릿 엔진에 맞춰서 코딩하고, $.ajax와 콜백 함수로 도배된, 그런 묘한 개발만 했을 뿐이다.  그때는 전혀, 프론트에 디자인 패턴이 있다는 사실도 몰랐고, 테스팅이라던가, Maven같은 의존성 관리/빌드툴이 있을줄은 몰랐다. IDE또한, 드림위버를 제외하면 jQuery의 함수 자동완성 기능을 제공하는 툴이 보이지 않았으니깐. 더군다나 당시의 프론트앤드 개발자들은 주로 신입이나 업무를 전환하신 분들이 하는 경향이 많았으니, 욕심 많은 개발 초년차였던 나에게 당연히 프론트엔드 개발은 그다지 매력적으로 느껴지지 않았던게 분명하다.


그래서 나는 Flex를 좋아라했다. 언제였는지 가물가물 하지만, Ajax의 발전과 함께 RIA (Rich Internet Application) 의 인기가 하늘을 찌르듯 하였다. 나는 플래시를 잘 몰라서 액션스크립트는 몰랐지만, Flex는 묘하게 응용한 자바의 그것과 MXML 사이에서 나는 왠지모르는 백엔드 스러움과 패턴을 느꼈다. 거기에는 모델도 있었고, 컨트롤러도 만들 수 있었다. 그러면서 백엔드와 서비스가 통신하더라. 그것이 신기했고, 언젠가는 순수 HTML/JS역시도 프레임워크의 도움으로 MVC정도는 지원하게 될 것으로 생각했다.


변화하는 프론트엔드를 다시금 보다.

2013년 말, 나는 HTML5와 관련된 책을 집필하며 자바스크립트를 기초부터 다시 공부하며 이 세상을 다시 보게 되었다. 당시 백엔드를 Play!와 스칼라로 갈아타려고, 예제로 제공되던 소스의 뷰단을 보던 순간, 아주 깜짝 놀랐다. 제공되는 프론트앤드의 Backbone.js으로 구성된 그것의 MVP (Model-View-Presentation) 구조가 너무나도 환상적이었던 것이다. 당시 나의 주된 관심사는 백엔드의 함수와 모델 그대로 프론트에서 함수형으로 쓸 수 있는 것이었는데, 일단 스칼라 라이브러리의 도움으로 이 또한 제공됨은 물론, 별다른 노력 없이 모델까지도 통일화된다. 어쩜 이런일이 가능한 것일까, 아니 내가 잠시 못본 사이에 이리도 발전할 수 있었단 말인가.


이 놀라움도 잠시, 유학을 준비하던 2014-15년에 걸쳐 AngularJS가 급속도로 파고올라왔다. 그러면서 Directive, Factory, 그리고 MV*패턴도 약 1.5년간 개발을 하며 많이 익히게 되었고, 익숙하게 되었다. 그런데 작년부터 React.JS가 엄청나게 파고 올라오더니, 지금은 페이스북에서도 사용하는 등 버전이 낮은데도 꽤나 실무에서 많이 사용을 하더라. 거기다 앵귤러까지 TypeScript등과 함께 2버전을 지원하게 되다니 말이다.


사실 올해 초까지만 해도 그냥 하나의 트랜드이겠지 하며 넘겼는데, 점점 주변에서도 쓰는 사람이 늘어나고 특히나 Flux패턴의 그것이라던가, GraphQL이나 Relay같은것도 '들리는' 자체로는 매력적으로 느껴졌다. 그뿐이랴, 앵귤러2 의 개발 커뮤니티에 비해 React.JS는 너무나도 활발하더라. 그리고 왠만한 프레임워크는 이미 플러그인으로 많이들 제공되고, NPM이 Bower보다 빠르다는(?) 벤치마킹도 보니 나도모르게 혹 해서는 3주동안 포팅을 시도하고, 오늘 장렬하게 '올해는 포기' 를 선언했다. (참고로 3년 전에는 이와 비슷하게 '올해는 스칼라 개발은 포기'를 선언한 적이 있다.)


React.JS를 배우며 느낀점


1) 확실히 빠르다.

당연하게도 Top-down의 DOM트리에서 한번 더 휴리스틱으로 O(N^3) 에서 O(N)까지 줄였으니, 왠만한 라이브러리 하며 dirty-checking하며 죄다 바꾸는 앵귤러에 비하면 훨씬 빠른것은 당연하다. 나는 이점에 사실 솔깃했었지만 사실 내 서비스는 컴포넌트라 해봤자 5개 정도밖에 되지 않고 (Authentication, Dashboard, Service1, Service2, Service 3) 나름대로(?) 최적화 해둔 백엔드와 Ajax에서 최대한의 그 무한 콜백에 빠지는 행위를 막고자 한 노력 덕분에 아직까지는 큰 성능의 이득을 보지 못했다. 아니, 사실 아직 프로토타입도 안나왔으니 빠른 자체에 대한 '의미'가 없다. 사용자 반응보다 지금 당장 서비스의 유/무를 확인하는게 급선무인데, 왜 100ms라도 줄이고자 의미없는 행동을 하고있다는 말인가.


2) 컴포넌트로 이루어진 웹 (아름다운 모듈화)

React.js Conf 2015에서 Jason Bonta가 보여주던 Ads Manager의 그 속도, 특히나 대용량의 데이터 등 보이는 모든것이 컴포넌트라는 사실이 충격이었다. 정말 어쩜 이리도 완벽한 모듈화가 될 수 있을까, 리엑트가 보통 MVC의 V를 이루는 라이브러리라고 한다. 그래서 View의 최적화에 신경쓰다 보니 위와 같이 DOM 트리의 최적화를 위해 웹페이지의 컴포넌트화에 신경을 많이 썼다. 실제로 리엑트를 쓰다보면 아무리 템플릿 엔진을 쓴다 해도 이렇게나 깔끔해 질 수가 없다. 게다가 Presentation/Container Component로의 그 구분 은 평소에도 내가 무척이나 퍼포먼스를 위해 신경쓰던 부분이기도 하다. 하지만 조금 더 자세히 생각해보면 난 솔직히 아무리 JSX라고 해도 JS에 HTML이 들어가는 자체를 쉽게 받아들이기가 힘들다. MVC구조에 너무 익숙해버린것일까.. Babel을 쓴다면 컴파일 한번을 걸쳐 나오는 JS코드도 사실 조금 어지럽다고 생각하고, Redux등을 사용하면 (real-world 예제 참조) 무려 action/components/containers/reducers/middleware/store 로 나뉘는 부분도 내게는 너무나도 복잡하다.


3) 엄청난 러닝커브(Learning Curve)

단순히 리엑트를 View에만 사용한다면 모를까, 일단 실제 제품에 사용하기 위해서는 아무래도 기존에 사용하던 익숙한 라이브러리를 연동시켜야 한다. 일단 이 부분에서 크나큰 모험이 시작된다. 나의 경우는 Grunt/Angular/Bower-> Yeoman 의 아주 심플한 구조를 가지고 있음에도 Bower와 Grunt의 연동에 큰 시간이 걸렸다. 이유인 즉, 일단 React.JS를 잘 사용하려면 Webpack을 연동하는게 좋고, 여기서 웹팩 공부하며 각종 file extension에 대한 Loader의 설치부터 배워야 하고, 모듈과 플러그인 개념도 이해하고.. bower보다는 NPM을 주로쓰는게 좋다니 bower컴포넌트 다 옮기고, 보통 튜토리얼이 서버사이드도 node.js로 작성하며 server.js로 연동하게 되어있으니, 예전에 쓰던 Grunt에서 browserify쓰던거 watcher로 하려다가 만족스러운 Grunt boilerplate가 없어서 Gulp 예제를 겨우겨우 구입해다가(..) 사용하기 시작했다.


여기까지는 좋은데 Babel 들어가면 ES2015문법 또 공부하고, JSX배우고, React가 State개념이 위주이니 State/Props도 배우고, 이렇게 열심히 컴포넌트 모듈화 해놓고는 이제 데이터 다뤄야 하니 Redux배워야 하므로 열심히 공식 메뉴얼을 읽어본다. Flux패턴 익히고, 액션/리듀서/스토어 배우고, 정적 데이터는 힘드니 동적 리듀서 배우고, 1.5부터인가 Mixin의 ValueLink도 depreciated되었으니, Mixin이 또 Harmful 하다니 subscribe도 배우고.. 기존에 header/nav/footer/content 모듈화 된거 다시 컴포넌트 화 하고, presentation/container 로 나누고, login에서 authentication처리 다시하고, 이렇게 하며 react-router배우고, redux-router와의 차이점도 배운다.


이제 어느정도 모듈화도 했고, 라우팅도 했으니 (여기까지 2주 소요) 실제로 서비스를 옮겨와본다. 기본적인 로그인/로그아웃만 먼저 구현하기로 하고, REST API야 다 구현되 있으니 열심히 시도해본다. 잘 되지 않으니 Authentication 예제 와 real-world 예제 로 열심히 비교해다가 만들어본다. 그러다 보니 드디어 dispatch에서 광채가 나기 시작한다 (3일전)... 이참에 CSRF토큰 방식도 JWT를 적용해본다. 쿠키에 저장하던 정보들도 localStorage에 저장해본다. 잘 된다.. 18일정도 지나니 로그인까지는 성공했다.


4) 모든 웹서비스는 State로 이뤄진다.

State, 말로만 들으면 정말로 웹에 컴포넌트처럼 딱 들어맞는 상황이다. 데이터가 모든 State마다 다르므로, 이에 따른 스테이트만 가지고 변경된 데이터만 해당 State에서 취한다는 것, 하지만 모든 것이 순조롭지는 않다. State마다의 데이터를 가지고 있으므로 이를 어떻게 유지하고, 변화시킬 것인지에 대한 설계가 필요하다. 즉, 기존의 MVC와는 별개의 설계가 필요하다. 데이터에 직접 접근이 힘들므로 리듀서를 열심히 사용해서 스테이트를 변경해야한다. 하지만 나는 여기서, 정말 여기서 일차적으로 포기했다.



배움은 어떠한 유형이든 간에 무언가에 대한 희생을 감수해야 한다. 특히나 시간이 넉넉치 않은 경우에는 더욱 더 그런 것 같다. 이번에 내가 느낀것은, 시스템 안정화 됬다고, 괜시리 주위에서 좋다는 소리에 무분별하게 프레임워크 바꾸지 말자는 것. 리엑트가 뭐 Native도 지원하고 빠르고.. 모든 기능이 완성되고, 잉여 시간이 남거나 정말로 시스템 퍼포먼스를 올려야 할 때, 그때 시작해도 늦지 않는다. 나 스스로가 풀스택으로 일하니, 정말 진심으로 러닝커브에 대한 감수를 스스로 할 수 있는지도 되물어 봐야한다. 프론트가 진척이 안되니 백엔드나 다른 부분이 진행이 될 리가 없다. 


마지막으로, 한번 더 기술의 엄청나게 빠른 변화를 직감했고, 혼자서 공부한다는 자체가 가끔은 무리가 수반된다는 것도 알게 되었다. 정말로 리엑트는, 나중에 서비스를 다 만들고, 나 외에 다른 프론트 개발자가 함께 한다면 그때 가서 함께 리펙토링 해도 늦지 않는다는 사실을 말이다. 괜시리 건방지게(?) 백엔드 개발자가 프론트 영역에 대고 최신기술 접목시킨다고 하고는 정말로 큰코 다친 것 같다. 한달이나 넘게 남던 데드라인이 채 일주일도 안남고, 개발 진척도는 원점이니, 이토록이나 대외적으로 아무것도 하지 않은 허탈함이 어디 있을까.


한번 더 '실험'과 '실무'는 별개라는 사실을 속 깊히 느끼며, 나는 다시금 한달 전의 코드로 돌아간다. 그렇다고 끝은 아니다. 언젠가는, 리펙토링을 하며 한번쯤 다시 돌아봤을 때, 그때는 또 모르겠다. ReactJS+AngularJS로 갈지도... :) 


글쓴이 메튜장 | matthew@urhy.me | http://www.matthewlab.com

작가의 이전글 빠른 개발 vs 미래대비 개발
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari