JavaScript 적응기 01 - Vue.js

최근 새 팀에 합류했다.

합류한 팀에서 풀 스택 개발 추구하고 있었고, 그 과정에서 웹 프론트엔드 개발에 vue.js를 사용하고 있었다.

Vue.js

자연스레 자바 스크립트를 사용해야 했는데, 2009~2012년경 윈도우 배치 스크립트 짜기 괴로워, Jscript (윈도우 내장 자바 스크립트 엔진을 이용한 스크립팅)을 했던 뒤로 오랜만에 실무에 사용하게 됐다.

종종 Node.js를 이용한 REST API 서버를 가볍게 써오긴 했으나, 나의 경우엔 업무 외적인 습작에 써왔고, 백엔드 서버로써 사용한 거라 굉장히 다르다고 할 수 있다.

주로 백엔드 내지는 서버 개발자 포지션에 있었으나, 클라이언트 개발에 관심도 많고 종종 해왔던지라 거부감이 없다는 점은 매우 다행이지 않나 싶다. 팀의 방향성과 나의 가치관에 충돌이 있을 땐 스트레스 요소가 될 수 있는데, 나는 아주 좋은 기회라고 생각이 들었고, 재미도 있었다.


대략 한달 간 가량 진행한 Vue.js의 감흥은 생각보다 쉽다 였다. 웹 프론트엔드 문외한이나 다름없었지만, 동료들이 작성한 코드를 보고 구조적인 이해나, 인프런 vue.js 강좌와 동일한 강사분이 써두신 입문서를 보고 금새 무언가를 만들 수 있을 만큼 직관적이고, 동작하는 무언가를 만드는 시간이 적게 소요됐다.

즉 학습도, 실습도 빠른 시간내에 가능했다는 의미다.

가장 도움이 된 것은 vue.js의 컴포넌트 라이프 사이클 이해하기 였는데, 유니티때와 마찬가지로 컴포넌트간 상호 작용이 크게 중요한 만큼, 이 그림은 계속 참고하면서 코딩하게 되는 유용한 자료 였다.

Vue.js Lifecycle

참고: https://medium.com/witinweb/vue-js-%EB%9D%BC%EC%9D%B4%ED%94%84%EC%82%AC%EC%9D%B4%ED%81%B4-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-7780cdd97dd4


반면 힘들었던 점은 역시나 언어의 태생적인 단점이었다. 나는 강타입 언어를 선호하는데, java script 자체는 typeless 언어라서, 이에 대한 아쉬움이 있었다.

Vue.js에서도 TypeScript를 지원 Vue.js TypeScript 지원 하고 있으나, 현재 팀에선 사용하고 있지 않은 상태였고, 리액트에 비해 상대적으로 미약하다고 한다. 이 부분은 아무래도 좀 이해도가 높아진 후에야 명확히 말할 수 있을 것 같다.

Vue.js 자체의 규칙은 간결하고 직관적이라 쉬운편이라고 할 수 있는 반면, 내가 HTML5, css, bootstrap등에 대한 이해도나 경험이 부족해서 이 부분에 대해서 막히는 부분이 많았다.

html을 직접 작성해야 하고, vue와 결합도가 높게 동작하고 연관하여 분석, 작성 해야 하다 보니 부족한 이해도가 아쉬웠다.

그런 부분을 감안했을 때에도 생각보다 허들이 낮은 편에 속했고, 프레임워크 자체에 대한 룰이나 제약이 단순하고, 해결 방법도 제시되어 있어 큰 어려움이 없이 작업 할 수 있었다.

Vue.js에서 주장하는 쉽고 빠른 간결한 프레임워크라는 주장을 신뢰할 수 있는 경험이었다고 할 수 있겠다.


애초에 Web Frontend라 할 수 있는 작업도 처음이지만, SPA로 작업한 것도 처음이고, 컴포넌트 단위로 코딩한 것도 처음이지만, 게임 UI랑 비교 했을 때에 아주 색다른 개념들은 크진 않았다.

컴포넌트간 통신 및 계층에 따른 의미나 제약을 집중해서 살펴보면서 작업을 진행했다.

컴포넌트 간의 순환 참조, 생성 순서 문제, 상호 통신, 순환 참조 문제 등 다양한 이슈가 얽혀 있었다. 선행 조건들이 늘어 날 수록 컴포넌트 간의 관계도 복잡해지고, 결합도가 높아지는 걸 느낄 수 있었는데, 이에 대한 몇가지 우회 방법들이나 팁이 존재하더라.

또 다른 측면의 걱정은 느리지 않을까?

처음 맞닥뜨린 vue.js는 각 컴포넌트를 감시하게 동작 할 것 같다는 생각이 강하게 들었었다.

앵귤러의 특징이면서도 단점으로 여겨지는 양방향 바인딩도 존재하고, v-bind나 v-if 등의 키워드로써 걸어놓은 트리거들이 동작하는 것들이 많고, 쉽게 사용할 수 있게 직관성을 강조하다보니 그만큼 느리지 않을까 하는 우려가 있었다. (물론 내부적으로 최대한 폴링보다는 이벤트 드리븐으로 잘 짰겠지만, 미지의 영역인 프론트 엔드 프레임워크에 대한 막연한 의구심 같은 거라고 할 수 있겠다.)

아주 의외인 것은 리액트보다 빠르다는 점이었다. 측정한 곳이 vue.js 공식 페이지다보니 수치나 정말 복잡하게 사용하는 상황에서 마저 우위에 있을지를 100% 믿기엔 어렵겠지만 말이다.

막연한 의구심을 해소하기 위해 이런 저런 글들과, 지인들에게 자문을 구했는데, 결론은 프론트엔드 프레임워크 대부분이 사용성과의 밸런스를 맞추기 위한 코스트를 감안하고 구현되어 있고, 돔을 직접 다루는 번거로움과 어지간히 잘 관리하지 못하면 돔을 찾고 수정하는 과정에 오버헤드가 걸리곤 하는데, 이를 프레임워크가 관리하면서 적정 수치 이상으로 유지해주기에 신경 쓸 거리가 적다고 봐야 한다는 것이었다.

이런 고민들이나 의구심들 대다수가 게임 UI 에서도 공통되게 고민되는 것 들이고, 비슷하게 접근하고 나면 납득 할 수 있는 것들이 많았다.

다만 현재까지의 생각과 감상이 든 과정 모두 내가 적응기로써 짧은 기간 학습+적응을 목표로 작업한 admin web에 한정된 이야기였고, 브라우저 호환성 및 메모리 이슈, 훨씬 더 복잡한 UI간 상호 작용을 요구하는 작업에선 훨씬 더 많은 감상이 있지 않을까 싶다.

Comments

comments powered by Disqus