크로키의 스택 - Mithril

크로키닷컴(지그재그)이 Backbone → Angular → Mithril 로 클라이언트 프레임워크를 옮겨 온 5년치 이력을 정리한 글이다. 각 단계에서 무엇이 불편해 갈아탔는지를 밝히고, 마지막에 프레임워크 선택 기준을 한 줄씩 남긴다.

핵심 포인트

2012년 두 번째 제품을 모바일 웹 앱으로 시작하며 서버 렌더링 대신 클라이언트 렌더링을 택했다. 서버 비용이 준다는 판단이었다(돌아보면 사용자가 적어 차이는 없었다).
그때 고른 것이 Backbone(0.9.2)이었고, Angular 도 있었지만 접하는 범위에서는 Backbone 이 대세였다.
SPA 의 단점은 무시할 만했다. 로그인이 필요한 사이트라 SEO 가 의미 없었고, 파일 크기로 인한 로딩 속도도 한정된 사용자에게는 이슈가 아니었다.
Backbone 관리 사이트가 커지며 소스 관리에 한계(파일을 단순 concat 으로 합치던 상태)를 느껴 2014년 Angular(1.2)로 옮겼다.
Angular 를 떠난 이유는 흔히 말하는 속도가 아니라 복잡도였다. 라이브러리 내부 코드를 종종 살펴보는 저자에게 "쓸데없이 복잡" 하게 느껴졌다.

상세 정리

배경: 크로키는 모바일 앱이 기본이라 일반 사용자용 웹 서비스는 없었지만, 내부 직원과 한정된 외부 사용자를 위한 웹 애플리케이션은 꾸준히 만들어 왔다.
2012년 초 첫 iOS 앱은 Vanilla JS 와 UIWebView 로 시작했고 1주일 만에 CoffeeScript 로 바꿨다가, 2주 만에 한계를 느껴 네이티브로 전환했다.
두 번째 제품도 웹 앱에서 Apache Cordova(PhoneGap)를 잠시 시도한 뒤 네이티브로 갔지만, 그때까지 만든 JS 클라이언트는 간이 관리 사이트에서 계속 쓰였다.
SPA 에 대한 관점이 정리된 시점을 2013년 세 번째 제품으로 꼽는다. 서버가 모바일 앱용 API 위주로 개발돼 있어 SPA 가 같은 API 를 그대로 쓸 수 있다는 점이 장점이었다.
Angular 전환은 요구사항이 크게 달라진 덕에 과감히 처음부터 재작성할 수 있었다. Yeoman 으로 프로젝트를 만들고 Grunt 를 빌드 툴로 썼다.
Mithril 은 Hacker News 댓글에서 알게 됐고, 속도보다 크기가 작다는 점이 마음에 들었다.
2015년 초 지그재그 내부 관리 사이트를 Mithril 로 시작해 이후 모든 웹 애플리케이션에 쓰고 있으며, 글 작성 시점(2017년 4월)에 1.0 으로 올라가며 구조도 안정화됐다.
빌드 툴은 Grunt → 다음 도구 → webpack 순으로 옮겼고, 언어는 CoffeeScript 가 주력이지만 TypeScript 전환을 시작했다.
선택 기준 ①: Angular 는 Spring 처럼 틀이 갖춰져 있어, 잘 모르는 사람이 일정 품질 이상의 제품을 만들고 싶을 때.
선택 기준 ②: React 는 좋은 구조를 원하고 빠르게 바뀌는 트렌드를 따라갈 자신이 있을 때.
선택 기준 ③: Vue 는 React 와 비슷하되 조금 더 안정된 것을 원할 때.
선택 기준 ④: Mithril 은 복잡한 기능이 필요 없고 가급적 Vanilla JS 에 가깝게 쓰고 싶을 때.