Title:
차세대 웹 프론트엔드 기술에 대한 고민
|
edited by
Youngrok Pak
at
5 years, 6 months ago.
<p>최근 수년 간 웹 프론트엔드 개발은 webpack을 중심으로 언어는 es6, 프레임워크는 react와 angular, vuejs가 이끌어왔다. angular가 선도한 이 프레임워크들은 이전까지 어떤 다른 UI 프레임워크에서도 경험하지 못했던 높은 생산성을 보여주었으나, webpack의 빌드와 es6 언어의 발전 방향은 정말 싫었다. 그래서, 그동안 나는 변화를 거부하고 여전히 전통적인 웹에 es5로 vue.js 프레임워크만 얹어서 써왔다. 그렇다고 트렌드를 무시할 수는 없는지라 몇몇 개인 프로젝트는 완전히 webpack을 풀로 채용해서 써보기도 했는데, 종합적인 생산성은 장단점이 어우러지면서 큰 차이가 없는 느낌이다.</p>
<p>일단 내가 중요한 프로젝트에서 사용하는 기술 스택은 대충 이렇다.</p>
<ol>
<li>django-rest-framework으로 서버 API를 짠다.</li>
<li>서버 사이드 템플릿은 mako를 사용하고, 메인페이지는 django의 view로 띄운다.</li>
<li>vue component는 `.vue` 확장자를 붙이기는 하지만 진짜 single file component가 아니라, 단순히 템플릿과 코드를 이어서 같이 두기만 하고 id로 연결해서 `x-template`으로 사용한다. 종종 여러 개의 component를 한 `.vue` 파일에 선언하기도 한다.</li>
<li>이 component들은 mako의 include로 html에 같이 렌더링한다.</li>
<li>vuex는 쓰지 않고 그냥 globals 같은 변수에 공통 데이터를 저장하고 모든 vue component에 그 globals를 data로 넣도록 mixin한다.</li>
<li>3rd party 라이브러리는 yarn으로 인스톨하고 script 태그로 넣어서 사용한다. </li>
</ol>
<p>이 방식에 비해 webpack을 중심으로 하는 요즘 트렌드는 몇 가지 장단점이 있다. </p>
<ul>
<li>source map으로 템플릿 내부 코드의 오류를 추적하기가 쉽다. 내 방식은 js 코드에서 오류가 날 때는 문제 없지만 템플릿에서 오류가 날 경우 찾기가 매우 어렵다.</li>
<li>라이브러리를 가져다 쓰는 노동은 비슷하다. import 구문, components 선언 등의 중복이 많아서 생각보다 간편하지 않았다.</li>
<li>css, image를 쓰는 건 내 방식이 훨씬 편했다. 이걸 뭐하러 loader로 빌드를 하는 미친 짓을 하는 건지.</li>
<li>webpack을 쓰면 es6 문법을 자유롭게 쓸 수 있다. 내 방식에선 IE를 포기하면 es6를 쓸 수 있지만, 그것도 완전 최신 문법은 쓰지 못한다.</li>
<li>Hot Module Replacement는 생각보다 편하지 않았다. 뭔가 원하는 데이터로 렌더링이 되지 않아서 그냥 리프레시를 해야 할 때가 많았고, 내 방식에서도 리프레시는 충분히 빨랐다.</li>
<li>webpack을 쓸 때는 서버 사이드와 연계하기 위해 CORS 등의 설정을 해야 하고, 개발할 때도 서버를 두 개 띄워야 하는 번거로움이 있었다.</li>
</ul>
<p>이렇게 장단점이 어우러져서 서로 플러스 마이너스를 주고 받은 끝에 나온 생산성은 거의 비슷한 것으로 보인다. es6의 문법에 기대를 많이 걸었으나, 여전히 파이썬과 넘사벽의 차이가 있었다. 가끔 es6가 과연 자바보다는 나은가 하는 의문이 들기도 한다.</p>
<p>여튼, 지금 내 방식이 그럭저럭 할만하긴 하지만, 분명 단점이 존재하고, 그렇다고 webpack과 es6 조합으로 이동하고 싶지는 않다. 뭔가 더 나은 차세대 기술을 찾을 필요가 있는 상황이다.</p>
<p>현 시점에서 가장 유력한 차세대는 TypeScript다. es6가 기대 이하라고 보는 사람은 나 말고도 많은지, es6가 매우 빠른 속도로 발전하고 있음에도 불구하고 다양한 js 트랜스파일 언어들이 쏟아져 나오고 있고, 그 중에 TypeScript가 대세가 되어가고 있다. angular 2가 먼저 이동했고, vue도 따라가려고 하고 있다. es6에 비해 좀더 안정된 문법을 갖고 있기 때문에 지금보다 근소하게 나아질 것으로 보인다. 만약 내가 다른 팀과 깊이 협업해야 하는 프로젝트를 한다면 webpack(또는 parcel)과 TypeScript, Vue.js(또는 Angular 2)를 선택할 것 같다.</p>
<p>그러나, TypeScript는 자바스크립트의 superset을 지향하기 때문인지 es6의 나쁜 것들(대표적으로 import/export)도 그대로 가져왔다. 그리고, 생각보다 진보적인 문법은 거의 없다. 그냥 class를 쓰는 좀더 안정적인 방법 정도? 7~8년 전에 유행하던(?) coffeescript보다 낫다고 느껴지지 않는다. es6보다 아주 약간 좋다 정도?</p>
<p>내 프로젝트를 할 때는 좀더 내 마음대로 기술 선택을 하기 때문에 이 정도로는 만족하기 어려웠다. 그래서, 대안을 찾기 시작했다. 먼저 시도해본 것은 Transcrypt다. 파이썬을 자바스크립트로 트랜스파일해주는 것이다. 어차피 webpack으로 트랜스파일을 해서 쓴다면 굳이 es6나 TypeScript의 범주에 갇힐 필요가 없지 않은가? 내가 가장 좋아하는 언어인 파이썬으로 웹 프론트엔드를 개발할 수 있다면 그보다 더 좋은 일은 없을 것 같았다. 그래서, 여러 가지 시도를 해보았는데, 일단 1차 시도는 실패했다. 꽤 복잡한 문제를 풀기 위해 파이썬의 좀 특수한 문법들을 썼는데, 그런 것들이 꼬이면서 컴파일에 실패하는 일이 일어났다. 일상적인 UI 작업에는 별 문제가 없을 것 같지만, 이 실패로 마음이 좀 흔들렸다. 가장 어려운 작업을 해야 할 때 파이썬 문법 중에 일부만 써야 한다면 굳이 옮겨갈 가치가 있나? 그래도 가치가 있을 것 같긴 하지만, 다른 시도도 좀더 해보고 싶었다.</p>
<p>그 다음으로 살펴보기 시작한 것은 함수형 언어들이다. 사실 우리 회사의 메인 프로젝트가 워낙 복잡한 계산들을 다루다보니 함수형 언어를 쓰면 도움이 될까 하는 생각을 해본 적이 있었는데, 그보다 웹 프론트에서 먼저 실험을 해보게 될 것 같다. 함수형 언어를 선택하려는 이유는 vue, angular와 같은 프레임워크와 비슷한 관점으로 UI를 만들 수 있을 것 같다는 점(직접 호환이 되지 않더라도), 내가 토이 프로젝트 외에는 해보지 않았던 패러다임을 실무에서 써보고 싶다는 욕구, 두 가지다. 내 시야에 잡힌 건 Elm, ReasonML, PureScript, fable 등이다. 아직 함수형 언어에 대해 잘 모르기 때문에 이것들을 꼼꼼히 뜯어보고 평가하기보다는 그냥 아무 거나 하나를 잡아서 해보려고 한다.</p>
<p>일단은 토이 프로젝트를 좀 해볼 생각이다. 이번 주나 다음 주 중에 한 번 <a href="http://wiki.c2.com/?WriteSmallButUsefulProgramsEveryDay">WriteSmallButUsefulProgramsEveryDay</a>를 해볼 생각이다. </p>
<p>결론도 없는데 이렇게 글로 정리해두는 이유는, 지금 방식으로 하다가 뭔가 문법적 한계 때문에 빡칠 때마다 새로운 기술을 조금씩 찾아보는데, 그게 좀 시간 낭비다보니 계속 쳇바퀴 돌지 말고 그냥 하루 작정하고 써보는 대신 일상 업무에서는 딴짓거리 안하려는 것.</p>
<p>
WikiNamu
영록이 홈페이지