By Kesus Kim

이 글의 원본은 여기에서 보실 수 있습니다.

주의: 글이 꽤 깁니다. 근데 정말 저는 읽으면서 10000번 공감…

혹시 더 나은 번역을 제안해주신다면 감사하게 수용하겠습니다.

수정: 오타 및 실수를 지적해주셔서 감사합니다. 말씀하신 대로 업데이트 할게요. HackerNews 와 Reddit에 가시면 상세한 토론을 보실 수 있습니다.

다음 글은 Circle CI의 “It’s the future” 라는 글로부터 영감을 받아 작성하였습니다. 해당 글은 다음 링크에서 확인하실 수 있습니다. 다음의 글은 단지 의견이므로, 다른 어떤 자바스크립트 프레임웤과 같이 너무 심각하게 받아들이면 안됩니다. 이 글을 작성하는 동안 어떠한 자바스크립트 프레임웤도 생성되지는 않겠지요.

이봐, 내가 새로운 웹 프로젝트를 얻었어. 근데 솔직히 말하면 최근 몇 년간 웹에서 코딩을 안했는데, 듣자하니 그쪽 세계가 뭔가 좀 바뀌었다면서? 네가 요 근처의 최신 웹 개발자 맞지?

- 정확한 명칭은 ‘프론트 엔드 엔지니어’야. 하지만 뭐, 맞아, 내가 바로 그 사람이지. 내가 2016년에 웹을 한다구. 시각화, 음악 플레이어, 축구를 하는 비행 드론 등등, 말만 해봐. 지금 막 ‘JSConf’와 ‘ReactConf’ 에서 돌아왔어, 그래서 내가 바로 웹 어플리케이션을 만드는 최신의 기술들을 알고 있지.

오 멋지다! 내가 사용자의 최근 활동 정보를 받아서 보여주는 웹페이지를 만들어야 하거든, 그래서 그냥 REST 엔드포인트에서 데이터를 받아온 다음에 검색 가능한 테이블 형태로 보여주고, 서버에서 변화가 있으면 업데이트 하는 형태로 하려고 해. 내 생각에는 jQuery를 이용해서 데이터를 가져와서 보여주면 될 것 같은데?

- 오 세상에나, 안되 안되. 요즘은 아무도 jQuery를 사용하지 않아. 넌 React를 배워야 해. 지금은 2016년이잖아.

아, 그래. React가 뭔데?

- React는 Facebook의 어떤 사람들(guys)이 만든 짱짱멋진 라이브러리야. React를 사용하면 어떠한 뷰라도 쉽게 바꿀 수 있기 때문에, 너의 어플리케이션을 쉽게 제어할 수도 있고, 성능도 보장해주지.

오 꽤 괜찮게 들린다. 그럼 내가 React를 사용해서 서버로부터 데이터를 보여줄 수 있는거야?

- 응, 하지만 먼저 너의 웹페이지에 라이브러리 형태로 React와 React DOM을 추가해주어야 해.

잠깐만, 왜 2개의 라이브러리를??

- React는 실질적인 React 자체의 라이브러리이고, React DOM은 DOM을 제어하기 위한 녀석이야. JSX를 이용해서 DOM을 기술하면(describe) 되.

JSX? JSX는 뭐야?

- JSX는 자바스크립트 문법의 확장인데, XML과 꽤나 유사하게 생겼어. DOM을 기술하기 위한 또 다른 방법이야. 그냥 JSX를 더 좋은 HTML이라고 생각해.

HTML이 뭐가 문제가 있어?

- 지금은 2016년이야. 아무도 직접적으로 HTML을 코딩하지 않는다고.

그래, 어찌됐든 좋아. 그래서 내가 아까 말한 두 라이브러리를 추가하면 React를 사용할 수 있어?

- 꼭 그렇지는 않아. Babel 이라는 녀석을 추가해주어야 하거든. 그럼 이제 React를 사용할 수 있어.

바벨은 뭐야? 또 다른 라이브러리야?

- 아, 바벨은 아무 버전의 자바스크립트를 사용하던 상관없이, 특정 버전의 자바스크립트를 타겟으로 트랜스파일해주는 ‘트랜스파일러’ 야. 반드시 Babel을 사용해야 ReactJS를 사용할 수 있는건 아니지만, 사용하지 않으면, ES5의 자바스크립트를 사용할 수밖에 없지. 우리 좀 현실적이 되자, 지금은 2016년이잖아? 다른 멋진 애들이 하듯이 너도 이제 ES2016+ 를 이용해서 코딩해야해.

ES5? ES2016+? 뭔 말인지 모르겠어. 그게 뭐야?

- ES5는 ECMAScript 5를 의미해. 거의 모든 최신의 브라우저에 구현이 된 자바스크립트의 표준 버전이야.

ECMAScript?

- 응, 너도 알다시피, 자바스크립트의 스크립트 표준은 자바스크립트가 초창기 1995년에 실린 이후인 1999년도에 세워졌거든. 1995년 당시에는 자바스크립트가 ‘라이브 스크립트(LiveScript)’ 라 불렸고, Netscape Navigator 에서만 동작했지. 그때는 굉장히 난잡했어. 하지만 감사하게도 요즈음에는 모든 것이 명확해져서, 지금 우리는 자바스크립트의, 대략, 7번째 개정판(edition)을 가지고 있다구.

7번째 개정, 와우. 그리고 그게 ES5와 ES2016+ 이야?

- 각각 5번째, 7번째 개정이야.

잠깐만, 6번째에겐 무슨 일이 생겼어?

- ES6 말하는거지? 맞아, 내 말은 각각의 개정판이 이전 개정판의 확장 버전(superset)이기 때문에, 만약 ES2016+을 쓴다면 이전 버전들의 기능까지도 사용하고 있다고 볼 수 있어.

그래… 그럼 왜 ES6 대신에 ES2016+ 을 쓰는거야?

- 글쎄, ES6을 쓸 수도 있지만, async나 await 처럼 정말 멋진 기능들을 사용하려면 ES2016+ 을 써야하지. 그렇지 않으면 비동기 호출을 처리하기 위해 ES6의 제너레이터와 코루틴 기능 이상으로 사용할 수가 없어.

지금 뭐라는지 하나도 모르겠다. 이름들도 생소하고 혼란스럽네. 봐봐, 난 그냥 서버로부터 데이터를 가져오려고 하는 것 뿐이야. 예전에는 그냥 CDN에서 jQuery를 라이브러리로 포함시켜서 Ajax 를 이용해서 데이터를 가져올 수 있었어. 왜 그냥 그렇게 하면 안돼?

- 지금은 2016년이잖아. 아무도 더 이상 jQuery를 쓰지 않는다고. 결국 스파게티 코드(역자 주: 난잡한 코드) 뭉덩이로 끝나버릴꺼야. 모두가 다 아는 사실이잖아.

그래… 그래서, 내가 데이터를 서버로부터 가져와서 HTML의 테이블 형태로 보여주기 위해서 대신 사용할 수 있는게 아까 이야기 한 3가지의 라이브러리라는 말이지?

- 음 그게 말이야, 3개의 라이브러리를 포함시키기는 하지만 모듈 관리자(module manager)를 이용해서 3개의 라이브러리를 하나로 합쳐서(bundle them up) 하나의 파일만 로딩되게 할 수 있어.

알겠어. 그럼 모듈 관리자 뭐야?

- 그 정의는 상황에 따라 다른데, 웹에서는 보통 AMD나 CommonJS 모듈을 지원하는 것을 의미해.

그으으으래… 그래서 AMD와 CommonJS라는건…?

- 정의일 뿐이지. 여러 자바스크립트 라이브러리들과 클래스들이 어떻게 서로 동작하는지를 기술하는 여러 방법들이 있어. exports와 requires 알지? AMD나 CommonJS API를 사용해서 여러 개의 자바스크립트 파일을 정의할 수 있고, Browserify 같은 것을 이용해서 번들링을 하는거야.

흠, 이제 좀 말이 되는 것 같네… Browserify는 뭐야?

- Browserify는 CommonJS 형태로 정의된 의존성 파일(dependencies) 들을 브라우저 내에서 사용할 수 있도록 번들링을 할 수 있게 해주는 도구야. 이 녀석은 대개 모든 사람들이 그들의 의존성 파일들을 npm 저장소(npm registry)에 배포하기 때문에 개발되었지.

npm 저장소?

- npm 저장소는 똑똑한 사람들이 그들의 코드와 의존성 파일들을 모듈의 형태로 저장해놓는 굉장히 큰 공인 코드 저장소(repository)야.

CDN처럼?

- 좀 달라. npm은 마치 모든 사람들이 라이브러리를 배포하고 다운로드 할 수 있는, 중앙집중된 데이터베이스 같은 녀석이야. 그래서 개발을 위해서 로컬 네트워크 환경에서도 사용할 수 있고, 이후에 원하면 CDN으로 업로드도 할 수 있지.

아, Bower처럼 말이구나!

- 맞아, 하지만 지금은 2016년이잖아. 아무도 더이상 Bower를 쓰지 않아.

아 그래… 알겠어. 그래서 npm으로부터 라이브러리를 다운로드 받아야 된다는 말이지?

- 응, 그래서 예를 들면, 만약 React를 사용하고 싶다면, React 모듈을 다운로드 받은 후에 코드 내로 들여오면 되. 거의 모든 유명한 자바스크립트 라이브러리에 대해서 그런 식으로 사용할 수 있어.

Angular처럼 말이구나!

- Angular는 너무 2015년꺼지만, 그래 맞아. Angular도 그런 식으로 사용하지, VueJS나 RxJS, 그 외에 멋진 2016년 라이브러리들과 마찬가지로 말이야. 이런 것들을 더 알아볼래?

우리 그냥 React나 하자. 이미 너무 많은 것들을 배웠어. 그래서 만약 내가 React를 사용해야 된다면 이 ’npm’ 이라는 곳에서부터 가져온 다음에 이 ‘Browserify’ 같은 것들을 사용하면 된다는 말이지?

- 맞아

단지 의존성 파일들을 다운로드 받아서 합치는 데에 너무나도 복잡한 것처럼 보인다.

- 사실 그래, 그래서 Grunt나 Gulp, Broccoli와 같이 Browserify 실행을 자동화 시켜줄 수 있는 태스크 관리자 (task manager, or task runner, task에 대한 적절한 단어를 모르겠네요)가 필요하지. 젠장, 심지어 Mimosa 라는 녀석도 있어.

Grunt? Gulp? Broccoli? Mimosa? 뭔 소리를 하는거야?

- 태스트 관리자들이야. 하지만 요즘엔 더이상 멋진 것들이 아니지. 그건 2015년에나 쓰던 것들이지. 그리고는 Makefiles도 쓰다가, 지금은 Webpack을 쓰고 있지.

Makefiles? 그건 C나 C++ 프로젝트에서 사용하던 것들로 알고 있는데.

- 맞아, 확실히 웹의 세계에서 우리들은 모든 것을 복잡하게 만드는 것을 좋아했다가 다시 기본으로 돌아갔었어. 우리는 그런 행동을 매년 해왔지. 조금만 기다려봐, 이제 1-2년 안에 웹에서 어셈블리어도 할 수 있게 될거야.

(한숨) 너 좀전에 Webpack 이라는걸 언급했었잖아?

- 그건 태스크 관리자이기도 하면서, 브라우저를 위한 또 다른 모듈 매니저야. 더 나은 버전의 Browserify 이라 생각하면 되.

아 그래, 왜 더 나은데?

- 음, 더 낫다고 할 수는 없겠다. 그냥 단지 의존성 파일들이 어떻게 결합되어야 할 지에 대한 개념의 차이일 뿐이거든. Webpack은 우리에게 다른 모듈 매니저를 사용할 수 있도록 해주고, 또한 CommonJS 뿐 아니라 AMD, 네이티브 ES6 등의 모듈들도 사용할 수 있게 해주지.

CommonJS와 ES6, 이 모든 것들이 굉-장히 헷갈린다.

- 모두가 그래. 하지만 이제 더이상 SystemJS에 대해 걱정 안해도 된다구.

하나님 맙소사, 또 다른 명사-js 라니. 그래, SystemJS가 뭐야?

- 음, Browserify나 Webpack 버전 1과는 다르게 SystemJS는 동적 모듈 로더야. 동적 모듈 로더는 하나의 큰 파일로 번들링 과정을 갖는 대신, 여러 개의 파일에 존재하는 여러 개의 모듈을 결합할 수 있어.

잠깐만, 여태까지 라이브러리들을 하나의 큰 파일로 만들어서 그걸 로딩하려고 한거 아니었어?

- 맞아, 근데 HTTP 2 가 다가오고 있어서 여러 개의 HTTP 요청들이 사실 더 낫거든.

잠깐, 그래서 그냥 React를 사용하기 위해서 번들링 하지 말고 3개의 원본 라이브러리들을 더하면 안되?

- 꼭 그렇지는 않지. 그냥 CDN을 이용해서 외부 스크립트에서 사용할 수 있기는 하지만, 여전히 Babel을 이용해야 한다구.

(한숨) 그리고 그건 나쁜 일이지?

- 맞아, 그렇게 되면 babel-core의 전체 부분을 웹페이지에 포함시켜야 할 텐데, 그건 배포하기에 그렇게 효율적이지 않거든. 배포를 하기 위해서는 미리 몇 가지 작업들을 해주어야 해. 그 작업들을 해줌으로써 사탄을 소환하는 의식을 마치 삶은 계란을 만드는 레시피처럼 보이게 할 수 있지 (역자 주: 무시무시하게 보이는 것을 굉장히 쉽고 가벼운 일처럼 만들수 있다는 말). 각각의 에셋 파일들을 압축시키고(minify, uglify), 그 파일에 CSS를 포함시키고, defer 스크립트들도 처리하고, 그 밖에도……

알았어 알았어. 그래서 CDN으로부터 직접 라이브러리를 가져오는게 아니라면 어떻게 하는건데?

- 난 아마 Webpack + SystemJS + Babel을 이용해서 TypeScript를 트랜스파일 할 것 같아.

TypeScript? 난 지금 자바스크립트 이야기 하고 있는 줄 알았는데!

- TypeScript 가 자바스크립트야. 좀 더 제대로 이야기하자면, 자바스크립트의 확장 버전(superset)이며, 더 정확하게는 자바스크립트 ES6 버전의 확대집합이야. 아까 이 6번째 개정판에 대해 이야기했던거 기억나지?

난 ES2016+ 이 이미 ES6의 확장 버전인줄 알고 있었는데! 왜 갑자기 이 TypeScript라는 것이 필요한거야??!

- 왜냐면 TypeScript는 자바스크립트에서 데이터 타입을 사용할 수 있도록 해주기 때문이야. 그래서 더욱 런타임 에러를 줄일 수 있지. 지금은 2016년이잖아, 이제 너의 자바스크립트 코드에 데이터 타입을 추가할 때라고.

TypeScript가 그걸 해주는거고 말이지?

- 마찬가지로 Flow도 그것을 해줘. JavaScript의 확장 버전인 TypeScript는 자바스크립트로 트랜스파일 되어야 하는 반면, Flow는 단지 데이터 타입만 확인하는 역할을 하지.

(한숨)… 그리고 Flow라는건?

- Flow는 Facebook의 어떤 사람들이 만든, 정적 데이터 타입 확인 도구(static type checker)야. 그들은 이 도구를 OCaml로 만들었어, 왜냐면 함수형 프로그래밍(functional programming)은 끝내주니까.

OCaml? 함수형 프로그래밍?

- 함수형 프로그래밍은 요즈음의 멋진 친구들이 하고 있는 거야. 알지, 지금은 2016년이라구. 함수형 프로그래밍, High order functions, Currying, Pure function 등등… (이 단어는 뭐라 번역해야 할지 모르겠네요, 더 어색해지는 느낌만 있는 듯…)

방금 무슨 말을 했는지 하.나.도. 못 알아듣겠어.

- 처음부터 이해하는 사람은 아무도 없지. 봐봐, 그냥 함수형 프로그래밍이 객체지향형 프로그래밍보다 낫기 때문에 우리가 2016년에 사용해야 한다는 것만 알면 되.

잠깐만, 내가 대학에서 객체지향형 프로그래밍을 배웠는데, 좋은거라고 생각했는데…?

- 오라클에 인수되기 전까지는 자바도 좋았었지. 그니까 내 말은, 객체지향형 프로그래밍은 그 당시에는 좋았어. 그리고 오늘날에도 수요가 있고. 하지만 요즈음 들어서 ‘상태를 변경하는 것’이 굉장히 고통스러운 일이라는 것을 모두가 깨닫고 있고, 그래서 이제 사람들은’변경 불가능한 객체’(immutable objects)와 함수형 프로그래밍을 더욱 사용하고 있지. 하스켈을 사용하던 사람들은 이 현상에 대해서 몇 년간 이야기 해왔지. 나는 Elm은 사용하기 싫었거든, 그런데 운 좋게도 이제 웹의 세계에서도 Ramda 같은 라이브러리가 있어서 순수하게 자바스크립트만으로도 함수형 프로그래밍을 할 수 있게 되었지.

너 지금 그냥 막 이름 지어내는거 아니지? 대체 Ramnda가 뭐야?

- 아니아니, Ramda. Lambda 처럼 말이야. 그거 있잖아, David Chambers의 라이브러리 말이야.

David 누구?

- David Chambers 말이야. 멋진 사람이지. Ramda 라이브러리의 공헌자 중 한 사람이야. 이 사람 말고도 함수형 프로그래밍에 대해 관심이 있으면 Erik Meijer라는 사람에 대해서도 찾아봐야해.

그리고 Erik Meijer는…?

- 마찬가지로 함수형 프로그래밍과 관련된 사람이지. 쩌는 사람이야. 그에게는 이상한 색깔의 셔츠를 입고(using this weird coloured shirt) 와서 애자일(역자 주: 프로그래밍 방법론 중 하나) 에 대해 비평을 하는 많은 프레젠테이션들이 있어. 그리고 이 사람들에 대해서도 찾아봐. Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osami, …

알았어. 거기서 그만 두는게 좋겠다. 이제 됐어. 내 생각에 이런 모든 것들이 단지 데이터를 가져와서 보여주는 데에는 너무 복잡하고 불필요한 것 같아. 이 사람들을 몰라도, 이런 모든 것들을 다 배우지 않아도 동적인 테이블 형태의 데이터를 만들 수 있을거라고 난 꽤나 확신해. 자 이제 다시 React로 돌아가자. React를 이용해서 어떻게 서버로부터 데이터를 가져올 수 있어?

- 음, 사실 React를 이용해서 데이터를 가져오지는 않아. 그냥 단지 React를 이용해서 데이터를 보여주는 것 뿐이지.

이런 젠장할. 그래서 데이터를 가져오기 위해서는 무엇을 사용하는데?

- Fetch 를 이용해서 서버로부터 데이터를 가져와.

잠깐만? Fetch를 이용해서 데이터를 가져온다고(to fetch the data)?? 누가 그렇게 비슷하게 이름을 지어놓은거야?

- 그러니까 말이야. Fetch는 서버로 XMLHttpRequest 을 수행하는 자바스크립트의 네이티브 구현 ‘이름’이야.

아, 그러니까 Ajax구나.

- Ajax는 그냥 XMLHttpRequests의 사용 예 중 하나일 뿐이지만, 뭐 맞아. Fetch를 사용하면 Ajax 기반의 요청을 Promise들을 이용해서 처리할 수 있고, 그럼으로써 콜백 헬(Callback hell)을 피할 수 있지.

콜백 헬?

- 응. 서버에 비동기 요청을 할때마다 응답을 기다려야 하잖아, 그리고 그 요청함수 내에 다른 응답 처리에 관한 함수를 추가해줘야 하고, 그것들이 반복되면 콜백 헬이라고 부르는거지.

아 그래. 그래서 이 Promise라는 것이 이 문제를 해결해준다는거지?

- 그렇지. 너의 콜백들을 Promise를 사용해서 조작함으로서, 더 이해하기도 쉽고 테스트하기도 쉬운 코드를 작성할 수 있어. 그럼으로써 동시에 여러 개의 요청을 수행하고 모든 요청이 로딩될 때까지 기다릴 수도 있지.

그리고 그것이 Fetch를 사용해서 할 수 있다는 말이지?

- 응. 하지만 너의 사용자가 최신의 브라우저를 사용해야만 해. 그렇지 않으면 Fetch의 polyfill (이것도 뭐라 번역하는게 좋을지 잘 모르겠네요.) 을 포함해주어야 해. 아니면 그냥 Requestsk Bluebird, Axios 등의 라이브러를 사용하던지.

세상에나 내가 얼마나 많은 라이브러리들을 알아야 하는거야? 몇 개나 있는데?

- 자바스크립트잖아. 같은 동작을 하는 것들에 대해서만 수천 개의 라이브러리는 있을 거야. 우리는 라이브러리들을 알고 있지. 사실, 우리는 최고의 라이브러리들을 가지고 있지. 우리의 라이브러리들은 거—대하고, 때로 우리는 Guy Fieri의 사진을 포함시키기도 하지.

방금 Guy Fieri라고 말한거야? 이 짓은 이제 끝내자. 이 Bluebird, Request, Axios 라이브러리들은 뭘 하는거야?

- 그 라이브러리들은 Promise를 반환하는 XMLHttpRequests를 수행하기 위한 라이브러리들이야.

jQuery의 Ajax 메서드도 요즘 들어서는 Promise를 반환하지 않던가?

- 2016년에는 더이상 J로 시작하는 단어는 사용하지 않아. 그냥 Fetch를 써. 그리고 polyfill을 포함시켜버리던지, Bluebird나 Request, Axios를 대신 사용해. 그리고 async 함수 안에 awiat을 이용해서 Promise들을 관리해. 그럼, 짜잔- 멋진 흐름을 갖게 되지.

지금이 네가 await에 관해 언급한지 세 번째인데, 아직도 뭔 소린지 모르겠다.

- Await은 비동기 호출을 동기식 함수처럼 코드를 작성할 수 있도록 해주어서 전체적인 코드의 가독성 등 프로그램에 더 나은 로직을 가질 수 있지. 진짜 엄청난거야, 그냥 Stage-3 Preset Babel을 사용하던지, syntax-async-functions 플러그인이나 transform-async-to-generator 플러그인을 사용하면 되.

이건 미친짓이야…

- 아냐, 정말 미친짓은 await을 사용하기 위해서 TypeScript 코드를 자바스크립트 ES6 코드로 컴파일 한 다음 Babel을 이용해서 ES5 코드로 트랜스파일해야 하는 짓이지.

ㅁ..!? 뭐? TypeScript에 포함이 안된거야?

- 다음 버전에는 포함이 되었는데, 1.7 버전까지는 await을 사용하려면 무조건 ES6으로 컴파일을 해야해서, 해당 ES6 코드를 Babel로 트랜스파일해서 ES5로 바꿔주어야 해. (역자 주: 지금은 2.0 버전이므로 괜찮습니다.)

이제 뭐라고 해야할 지도 모르겠다.

- 봐봐, 쉬운거야. 그냥 TypeScript로 코딩을 해. 모든 Fetch를 사용하는 모듈을 ES6 으로 컴파일하고, Babel을 이용해서 트랜스파일해서, SystemJS를 이용해서 로딩하는거지. Fetch가 없으면 그냥 polyfill을 포함시켜버리던지, Bluebird나 Request, Axios를 쓰고 await을 이용해서 Promise를 제어하면 되.

우리 서로 ‘쉽다’는 정의가 굉장히 다르구나. 그래서, 그런 의식을 하면 마침내 데이터를 가져온 후에 React를 이용해서 데이터를 보여줄 수 있는거지, 맞지?

- 혹시 너의 어플리케이션에 상태 변화가 있어?

어… 아마 없을 것 같아. 그냥 데이터를 보여주기만 하면 되.

- 오, 세상에 다행이다. 만약 그렇다면 Flux와 Flux의 구현체인 Flummox, Alt, Fluxible 등에 대해서 설명해야 하거든. 그럼에도 솔직히 Redux를 쓰는게 제일 낫지만 말이야.

이제 그 이름들 지긋지긋하다. 다시 한번 말하지만, 그냥 데이터를 보여주기만 하면 되.

- 아, 그냥 단지 데이터를 보여주기만 하는 거라면 React를 이용해서 할 필요가 없어. 그냥 적당한 템플릿 엔진(templating engine)만 있으면 되.

지금 나랑 장난해? 너한텐 지금 이 상황이 웃기지? 이게 네 연인을 대하는 방법이야?

- 난 단지 네가 뭘 사용할 수 있는지 설명하고 있던 것 뿐이었어.

그만, 그만해.

- 내 말은, 그냥 단지 템플릿 엔진을 쓰더라도 나는 TypeScript + SystemJS + Babel 조합을 사용할 거거든.

그냥 웹 페이지에 데이터를 보여주기만 하면 되. 뭔 대단한 필살기(역자 주: 원문에서는 Sub Zero’s original MK fatality라는, 모탈 컴뱃 게임의 Sub Zero 라는 캐릭터의 필살기를 언급하고 있음) 를 하려는 것이 아니란 말이야. 어서 빨리 템플릿 엔진이 뭔지, 어떻게 쓰는지, 어디서 얻는지만 얘기해줘.

- 많은 종류가 있지. 어떤 종류에 친숙해?

으으윽… 이름이 기억이 안난다. 꽤 오래 전이어서.

- jTemplates? jQote? PURE?

아… 아닌 것 같다. 다른건?

- Transparency? JSRender? MarkupJS? KnockoutJS? 그건 양방향 데이터 바인딩(two-way data binding)이 있지.

다른건…?

- PlatesJS? jQuery-tmpl? Handlebars? 아직도 몇몇 사람들은 사용하고 있는 것들이야.

아마도…? Handlebars와 비슷한 것들이 더 있어?

- Mustache나 underscore 같은 것들? 내 생각이기는 하지만, 요즘엔 심지어 lodash 같은것도 있잖아. 그런 것들은 마치 2014년도 꺼라고.

으음.. 아마도 좀 더 최신 것 같은데.

- Jade? DustJS?

아니..

- DotJS? EJS?

아니..

-Nunjucks? ECT?

아니..

- 흐음. 이젠 더이상 CoffeeScript의 문법을 좋아하지는 않지. Jade는?

아니, 이미 너 Jade 말했었어.

- 그니까 Pug 말이야. Jade. 그니까 Jade가 이제는 Pug거든.

(한숨) 아냐, 기억 못하겠어. 넌 어떤 템플릿 엔진을 쓰는데?

- 아마도 난 그냥 ES6의 네이티브 템플릿 문자열(template strings)을 사용할 것 같아.

그래… 아마 그건 ES6이 필요하겠구나?

- 정확해.

그리고, 어떤 브라우저냐에 따라서 난 Babel을 써야될 것이고 말이야.

- 정확해.

그리고, 전체 core 라이브러리를 포함하지 않으려면, 모듈을 npm으로부터 로딩해야 될 테고 말이야.

- 정확해.

그리고, Browserify나 Webpack, 아니면 SystemJS라 불리는 것이 필요하겠지.

- 정확해.

그리고, Webpack이 아니면, 이상적으로는 태스크 관리자에 의해 관리되어야 하겠지.

- 정확해.

하지만 함수형 프로그래밍과 데이터 타입을 추가해서 사용하기 위해서 먼저 타입스크립트를 컴파일하고 Flow 인지 뭔지를 추가해서 써야겠지.

- 정확해.

그리고 await 같은 것을 사용하기 위해서는 그 결과를 Babel한테 보내야겠지.

- 정확해.

그래서 마침내 Fetch, Promise 등등의 모든 마법들을 사용할 수 있는 거구만.

- 지원하지 않는 브라우저에 대해 polyfill을 제공하는 것을 잊지 마. Safari 브라우저는 아직도 Fetch를 지원하지 않거든.

그거 알아? 이제 우리 그만하자. 사실, 이제 난 끝났어. Web이랑 완전히 끝났어. 이 자바스크립트와는 완전히 인연을 끊을거야.

- 그것도 괜찮아. 몇년 내로 우리 모두는 Elm이나 WebAssembly를 이용해서 코딩하고 있을 거야.

난 그냥 백엔드나 해야겠어. 이렇게 많은 변화들과 버전들, 개정판, 컴파일러, 트랜스파일러… 감당할 수가 없다. 자바스크립트 커뮤니티가 만약 다른 사람들이 이 변화를 쫓아올 수 있다고 생각했다면, 그들은 미친거야.

- 그래, 너 한번 파이썬 커뮤니티에 가봐야겠다.

왜?

- 혹시 파이썬 3 들어봤어?