Jimmy Breck-McKye

Twitter:@jbreckmckye

Jimmy Breck-McKye는 프론트엔드 개발자입니다.

Breck-McKye가 자신의 블로그에 쓴 글로 2014년 12월 첫째 주  JavaScript Weekly에 올라온 The State of JavaScript in 2015를 번역한 글입니다.

 
 
—–
요즘 JavaScript 세계는 춘추전국시대 같다. 감당할 수 없는 속도로 새로운 프레임워크와 기술이 쏟아지고 사라진다. 나는 사람들이 이 상황을 새로운 방법으로 헤쳐나갈 것으로 본다. 내 예상에 앞으로 개발자들은 Angular.js, Ember 같은 단일 프레임워크가 아닌 입맛대로 조합할 수 있는 작은 라이브러리를 사용해서 변화가 가져올 위험을 줄이고 서로 다른 문제를 개별적으로 해결하는 방향으로 나갈 것이다.
많은 사견이 들어가 있는 글이지만 끝까지 읽어보길 바란다.
 
 

춘추전국시대

2014년을 마무리하는 이 시점에 JavaScript 개발자로서 확신을 가지고 특정 라이브러리나 기술을 지지하기 어렵다. 심지어 최근의 사건을 보면 강력한 단일 페이지 애플리케이션 (SPA, Single Page Application) 프레임워크인 Angular의 상황조차도 불안정하다.
이유는 이렇다.
평소 <ng-community>에 별 관심이 없는 사람이라도 10월에 열린 ‘2014 ng-europe’ 콘퍼런스는 봤을 것이다. 이 자리에서 Angular 개발팀은 Angular 2.0 업데이트 로드맵을 발표했다. 이 콘퍼런스에서 많은 논란이 있었는데 그 중 하나가 NG2.0의 하위 호환성 문제다. NG2.0은 기존 Angular로 작성한 코드와 호환되지 않는다. 그리고 실제로 새로운 아키텍처에 따라서 기존에 있던 몇가지 주요 개념을 보류 할 예정이다.
그렇다. Angular 개발자는 이제 완전 새로운 프레임워크를 배워야 한다.
당연히 많은 개발자들이 화를 내고 있다. 이것이 옳든, 틀리든 Angular를 이용해서 애플리케이션을 만들어 오면서 2년 동안 열심히 쌓아온 온 지식, 사례, 코드가 이제 본인의 의사와 상관없이 사라질 위기에 처했으니까. 설상가상으로 이 변경은 12개월 후에나 있을 예정이다. 반대론자들의 말마따나 지금 시작하는 새 프로젝트는 2015년 후반에 Angular 2.0이 나오면 죽으라는건가.
 

저는 솔직히 Angular 팀이 이렇게 정떨어는 Angular 2.0을 발표할 줄 몰랐습니다. 오프라인 우선 기능이나 멋진 걸 추가하기 위해 구형 브라우저 지원을 접는다는 이야기만 좋았네요.
엉망이에요. 문법은 개판인 것 같고, 1.3과 2.0의 차이는 수년 동안 업무로 해 온 프로젝트에서 손을 떼라는 건가요? 저보고 사장님한테 “이제 엄청난 걸 만들 수 있습니다. 그런데 코드를 18개월 후에 어떻게 다시 작성할지 계획을 세워야 합니다.” 이렇게 말하라는 건가요 지금?
Angular 2.0 발표에 대한 Reddit R/프로그래밍 보드에 달린 jbarkett의 댓글

 
위 글에 달린 댓글을 보면 Angular와 Google을 향한 분노가 가득하다. 그 중 일부는 타당한 비난일테고, 일부는 아닐 것이다. 가장 많은 찬성(upvoted)을 받은 댓글은 Angular가 아니라 JavaScript 환경 전체를 이야기한다.
 

다들 보고 있는 것처럼 이제 유행을 따라서 웹을 개발하기는 힘들어요. 내가 이런 유행을 따르지 않았다는 게 다행이네요. 이런 웃기는 상황을 강요받는다면 출구를 찾아다니면서 비명을 지르거나 미쳐버릴 겁니다. 이건 단편화보다 세제곱 정도는 힘든 상황이에요.
MV머시기 하는 프레임워크가 몇 개나 되는지 세지도 못 하겠어요. “Foo, Bar, Baz를 사용한 프레임워크”라고 떠드는 걸 본 적이 있습니다. 봤더니 Foo는 3%가 사용하는 한 번도 들어본 적 없는 이벤트 라이브러리더군요. Bar는 2% 정도가 사용하는 템플릿 라이브러리고. 역시 한 번도 들어본 적 없을 겁니다. Baz는 1%가 사용하는 데이터 바인딩 라이브러리고요. 얘네들을 조합한 게 쓸모 있을까요? 뭐, 만든 사람이 5분 뒤에 라이브러리를 새로 바꾸기 전까지는 쓸모 있을지도 모르겠네요.
이해 못 하겠어요. 사람들이 왜 이런 프레임워크를 좋아하는지 모르겠어요. 이런 걸로 작성한 코드를 봤는데, 그냥 막 믿을 수 없을 정도로 끔찍해요. 30초마다 바뀌는 걸 제대로 이해할 사람이 있을 리가 없죠.
 
Reddit의 같은 글에 달린 othermike의 댓글

 
Othermike가 이야기하는 것처럼 나는 지금 이 상황이 싫다. 정말 열라 더럽게 많은 JavaScript 프레임워크가 열라 더럽게 빨리 바뀐다.
2년 전, JavaScript는 르네상스를 맞이하여 불타고 있었다. 브라우저(익스플로러 말고)가 더 현대화, 더 표준화 되고 Node.js가 등장해서 프론트엔드 빌드 도구의 동력이 되면서 불타는 JavaScript에 기름을 부었다.
모든 새로운 기술은 진보했다. 12개월 전까지만 해도 현대 웹을 지배하는 기술은 Backbone.js(Marionette를 사용하는 경우겠지), Grunt 태스크 러너, Require.js, Handlebars 기반의 템플릿 엔진이었다.
그런데 6개월이 채 지나기도 전에 다른 기술이 등장해서 이 녀석들을 모두 대체해버렸다. 블로그에 자주 보이는 내용에 따르면 요즘은 Angular, Gulp, Browerify가 대세다. 물론, 이 녀석들도 의심스럽기는 마찬가지.
 
 

이걸 어떻게 따라가?

솔직히 새로운 기술을 따라가기 버겁다.
noname123 – HackerNews

 
혁신은 아주 좋지만, 이런 식의 빠른 변화는 지나친 것 같다. 기술이 지속성을 보장받지 못하는 상황에서 개발자는 새로운 프레임워크와 기술을 학습하는 데 많은 시간을 선투자 할 수 없다.
프로그래머는 프로그램을 만들고 싶어한다. 뭔가를 만들고 싶어하고, 만든 것의 주인이 되고 싶어한다. 그런데 배우는 데 시간을 다 써버리면 이걸 언제 할까? 낯선 기술을 가지고 어둠 속에서 허우적대는 데 장인 정신은 개뿔.
예전에는 기업의 후원이나 대규모 조직 지원은 등불과 같았다. 우리는 구글, 어도비, 마이크로소프트가 만든 프레임워크를 보면서 이 기업들이 오래도록 잘 관리해 줄 거라고 믿었다. 하지만 플렉스(Flex)와 실버라이트(Silverlight)의 위기를 볼 때 이제는 다 지나간 이야기다.
나는 지금 단지 사용 중인 도구가 사라질까봐 걱정하는 게 아니다.
막 등장하는 새로운, 겉으로 볼 때 좀 더 좋아보이는 기술이라고 해서 넋놓고 긍정적으로 바라보는 태도는 잘못된 것일 수도 있다는 이야기를 하고 싶다.
지금은 시니어 개발자가  Grunt, Backbone, Require를 쓰는 게 당연하지만, 과연 6개월 후에도 그들이 이 기술을 사용하는 게 당연할까?
 
 

희망은 있다.

그래서 상황은 어렵다. 하지만 우리는 영리하고, 개발자는 재주가 많다. 그리고 앞으로도 새로운 애플리케이션을 만들고 싶기에 우리는 포기할 수 없다. 그럼 무얼 해야할까?
여기 세 가지 하고 싶은 이야기가 있다.
 

1. 새로운 기술을 건강하게 비판해라.

멋진 Github의 새 프로젝트를 제품에 적용할 때는 조심해라. 그 기술의 많은 버그를 수정해서 사람들이 보편적으로 사용하고, 의심의 여지없이 성숙했다 싶을 때까지 기다려라. 피할 수 없는 공포스러운 이야기(모든 기술은 공포 가득한 이야기를 가지고 있다)와 X, Y를 사용한 제품에 대한 이야기가 참호에서 들려올 때까지 기다려라.
 

2. 기업의 후원을 너무 신뢰하지 마라.

Google이 자신들의 생태계에 의존하고 있는 개발자가 깔고 서 있는 양탄자를 걷어치워버리는 일은 이게 처음이 아니다. 구글의 Web API를 이용하는 사람에게 가서 물어봐라. 기업은 항상 비이성적으로 자해를 한다. 기업의 관심과 당신의 관심이 항상 같을 수 없다.
 

3. 단일 프레임워크보다 전용 라이브러리를 추천한다.

프레임워크 선택은 장기적인 관점에서 생각해야 할 큰 계약이다. 일단 프레임워크를 선택하면, 프레임워크의 다양한 내부 동작과 낯선 행동을 학습해야 한다. 또한 선택한 프레임워크를 잘 이해할 수 있을 때까지 비효율의 시간을 겪어야 한다. 선택한 프레임워크를 써보니 애초 생각했던 것과 달라서 다른 프레임워크로 바꿔야한다면, 많은 것을 잃을 수도 있다. 하지만 프레임워크가 아닌 라이브러리를 사용한다면 프론트엔드 스택의 한 부분만 교체하고 나머지는 그대로 유지할 수 있다.
 
사람들은 이미 3번을 향해 움직이고 있다.
 
 

Libraries > frameworks?

Angular 논쟁의 여파로 Reddit에 JavaScript 개발자가 옮겨갈 만한 다른 기술을 묻는 글이 올라왔다.
목록을 뽑아보면 이렇다.

• React.js with Flux (a view-only library and an eventing module)
• Ember.js (a full MVC framework)
• Knockout.js (view-only library)
• Backbone.js (full MVC framework)
• Meteor (full isomorphic framework)
• Mithril (full MVC framework)
• ‘No framework; just lots of libraries’
• Vue.js (view-only library)
• Breeze.js (model-only library)
• Ractive (view-only library)

이 중에 많은 녀석들이 프레임워크가 아니라 라이브러리라는 게 재밌다. 주로 DOM에 데이터를 바인딩한다.
 
어떤 사람이 프레임워크 대신 한가지를 잘하는 모듈화 컴포넌트를 추천하면서 이런 글을 남겼다.
 

최선의 대답은 이겁니다.
완벽한 프레임워크는 있을 수 없다. npm을 이용해서 가장 적절한 기능을 가져다가 원하는대로 조합해라.
이런 작은 컴포넌트의 문서를 보면 대부분 정말 쉬워요. 사용하는 데 아무 문제 없고, 프레임워크 처럼 작성자가 버그를 수정해서 다음 번에 릴리즈 할 때까지 기다리지 않아도 됩니다. 이슈만 올리면, 만든 사람이 이슈를 해결하고 코드를 push하죠. 그러면 펑~하고 npm으로 코드가 올라가서 모든 사람이 사용할 수 있습니다. 다른 컴포넌트를 사용하는 데 전혀 방해를 받지 않습니다.
템플릿 언어나 에러 처리를 좋아하지 않는다면 전체 프로젝트를 재고하지 않아도 됩니다. 그냥 컴포넌트를 핫 스왑(hot-swap)하고 하던 일 다시 하는거죠.
 
Reddit에 있는 “Reddit Now That AngularJS Has Gone Down a Bit of a Weird Route, What Are Some Good Alternatives?“에 달린 krazyjaykee의 댓글.

 
 
이 생각에 공감한다. 하나의 목적과 작은 부분에 집중하는 라이브러리를 선택해서 조합하면, 어떤 라이브러리를 변경해야 할 때 전체 프론트엔드 스택의 일부만 바꿔치기 할 수 있다.
새로운 프로젝트를 할 때 라우팅 API 같이 오랫동안 변하지 않는 핵심 기능은 그대로 두고 중요 부분만 교체할 수 있다.
라이브러리를 사용하면 ‘모 아니면 도’ 같은 결정을 할 필요가 없다. Angular의 제어 역전(IOC, Inversion Of Control) 컨테이너는 좋아하지만 데이터 바인딩이 싫다면? 걱정없다. NPM에서 마음에 드는 녀석을 하나 고르면 그만이다.
기존 프로젝트(사장님의 밥줄)를 갈아엎지 않고도 점진적으로 새로운 기술을 적용할 수 있다. 이렇게 하면 기존의 좋은 관행을 유지하면서 라이브러리를 조심스럽게 감쌀 수 있다.
게다가 다른 문제를 해결하는 서로 다른 라이브러리가 있을 때, 각각의 라이브러리가 제공하는 해결책을 직접 비교할 수 있다. 프레임워크A의 X는 좋지만 Y는 별로이고, 프레임워크B는 Y가 환상적이지만 X가 불안하면 프레임워크를 선택하기가 어렵다. 하지만 같은 X를 제공하는 라이브러리 A와 B는 구분할 수 있는 수치를 가지고 직접 비교할 수 있다.
 
 

정리하자면

• 지나치게 빠른게 등장하고 사라지는 프론트엔드 JavaScript 기술은 문제가 있다.
• 이런 변화 속도에 사람들은 피로와 소외감을 느끼기 시작했다.
• 단일 프레임워크가 아닌 마이크로 라이브러리를 사용하면 이 문제를 해결할 수도 있다.

 
물론, 2015년에 실제로 일어날 일이고 많은 개발자가 바득바득 이를 가는 상황이지만 Angular가 계속 세상을 지배할 수도 있다. Angular의 인기는 그만한 이유가 있다. 그렇게 된다면 지난 2년간 격동의 시기를 겪으며 표준과 안정을 찾으려고 애써온 JavaScript 세계에서 Angular는 안정적인 지위를 가질 수 있다. 물론 또 다른 프레임워크가 나타나서 Angular의 자리를 차지할 수도 있다. 현재로서는 React, Flux, Browerify 조합이 유력해 보인다.
어떻든간에, 기술이 변해가는 속도를 늦출 수는 없다. 앞으로 어떻게 될 지 지켜보자. 관련해서 하고 싶은 이야기가 있다면 트위터로 오시길. (노트 : 인기가 많아서 블로그에 댓글 기능을 열었습니다. 아래에 댓글을 달아주세요!)
 
 
—–
 
원문은 여기까지입니다.
번역을 하다가 Angular에 대한 원문의 내용이 편향적이라는 의견을 남긴 댓글을 발견했습니다. 참고할만한 내용인 것 같아 함께 실었습니다.
 

마이크로 라이브러리 사용은 좋은 의견입니다. 그런데 이 글에 나와있는 “AngularJS 논란”은 한쪽으로 치우친 의견 같네요.
AnguarJS 팀은 1.x를 전담하는 팀이 이후에도 프로젝트를 계속 지원할 계획이라고 분명히 밝혔습니다. 새로운 Angular가 나온다고 겁 먹고 다른 프레임워크로 갈아타야 할 이유가 없는거죠. Angular 1.x로 만든 애플리케이션은 문제없이 계속 돌아갈거고, 새로운 기능도 추가할 수 있습니다. 필요할 때 커뮤니티에서 도움도 받을 수 있을 거구요. 기존 Angular를 2.x로 변경해야 한다면 마이그레이션 할 수 있는 길을 만들어주겠죠.
제가 볼 때 Angular 2.x는 완전히 다른, 별개의 프레임워크입니다. 그냥 같은 사람이 만들었고, 이름만 같을 뿐이죠. 쉽게 다른 이름을 붙이기 어려웠을 거에요. 다들 “얼? Angular팀이 새로운 프레임워크를 만들었네?” 하면서 흥분했겠죠.
Angular를 처음 설계했을 때에 비해 웹은 아주 많이 변했습니다. ES6, 웹 컴포넌트, Object.observer 등 많은 것이 나왔어요. Angular 팀은 이 기술을 사용해서 프레임워크를 만들고 싶었겠죠. 처음 Angular를 만들 때 사용한 기술은 6년 전에 나온 것들이니까요.
이게 전부에요. 겁 먹지 마세요. 지금까지 Angular를 잘 사용해왔으면 그냥 계속 사용하면 됩니다. 2.x가 나와도 말이죠.