그 전에도 수시로 논의가 오갔지만 5월 초에 JSConf.us 2011이후로 JavaScript.next()에 대한 논의가 해외 프론트앤드 개발자 사이에서 엄청나게 활발해 졌습니다. 여기서 JS.next()라는 것은 차세대 자바스크립트를 의미합니다. 이 논의의 발단은 JSConf에서 Brendan Eich의 발표가 그 시작점이었던것 같습니다. 물론 대부분의 논의는 JavaScript가 어떤 언어가 되어야 하고 어떤 문법을 추가해야 하는가에 대한 구체적인 논의이지만 이 순간이 JavaScript가 크게 변화는 시작점에 포함되어 있다는 판단하에 앞으로의 상황추이를 좀 쉽게 보기 위해서 현재의 상황을 좀 이해하고 넘어가야 할 것 같아서 관련 정보들을 찾아보았습니다.




JavaScript의 역사
JS.next에 대해서 이야기 하기전에 자바스크립트의 역사를 좀 집고 넘어가야할 필요가 있을 듯 합니다. JavaScript는 Netscape에서 Brendan Eich(Mozilla의 공동설립자로 현재는 CTO로 있습니다.)가 90년대 초에 웹페이지를 다이나믹하게 하기 위해서 만들었으며 처음에는 Mocha라고 불렀으며 그 뒤에는 LiveScript라고 명명되었습니다. 이후 Netscape Navigator에 자바기술을 넣기 위해서 Sun Microsystem와 함께 하면서 1995년에 JavaScript라는 이름으로 최종 확정됩니다.

Netscape가 JavaScript를 Ecma International에 제출하게 되고 1996년 11월에 ECMA-262를 위한 스펙을 제정하는 작업에 들어갔으며 1997년 7월에 첫번째 에디션이 받아들여졌습니다. 1996년 Netscape 3.0에서 1.1이 적용된 뒤 1997년 Netscape 4.0에서 1.2가 릴리즈되었습니다. 이때 Microsoft는 1996년에 Internet Explorer 3.0를 발표하면서 JavaScript에 기반을 두었지만 트레이드마크를 피하기 위해서 JScript라고 이름을 지어서 같이 발표했습니다. JScript는 JavaScript의 방언정도이고 이후로 ECMAScript가 표준화 되면서 JavaScript도 ECMAScript의 Netscape 방언이 되었으며 그 외방언으로는 ActionScript가 있습니다.

이후 Netscape와 Internet Explorer의 브라우저 전쟁이 나면서 지금에서는 이상하게 들리겠지만 Microsoft는 당시에 JavaScript가 인기를 얻을 수 있도록 하기 위해서 JScript를 JavaScript와 최대로 호환성을 이룰수 있도록 노력하였습니다. 이 브라우저 전쟁의 중심에는 DOM 개발이 있었고 DOM Level 0은 Netscape에서 개발했으며 그 유용성이 좀 의심스럽기는 하지만 현대적 브라우저가 모두 지원하고 있는데 Microsoft도 이를 카피해서 Internet Explorer 3에 적용했습니다. document.images[0]같이 사용하는 것인 DOM Level 0입니다

W3C는 1994년에 설립되었고 ECMAScript를 통해서 JavaScript의 표준화를 돕고 있었으며 1998년 DOM Level 1을 위한 recommendation이 발표되고 2000년에 DOM Level 2가 발표되어 지금의 getElementById()와 이벤트 모델을 가지게 되었습니다. 하지만 이는 너무 늦은 시기였습니다. Microsoft가 브라우저 전쟁에서 이긴 후에 비호환성 정책을 취하게 되고 IE6이 지배적인 브라우저가 되면서 웹의 혁신은 끝이 나게 됩니다. 이는 웹 2.0의 시대가 올 때 까지 계속 됩니다.

또한 SpiderMonkey는 Netscape에서 Brendan Eich가 C로 구현한 JavaScript의 첫번째 인터프리터였으며 지금도 파이어폭스와 Adobe의 제품들에서 사용되고 있습니다. 1999년 말에 ECMA-262 Edition 3가 발표되면서 정규표현식과 try/catch를 통한 예외처리등이 추가되었고 현재의 대부분의 브라우저는 이 Edition 3를 지원하고 있습니다.



하지만 이 시점 이후로 ECMAScript의 개발인 이상한 짓을 하기 시작합니다. 임베디드 장비를 위한 컴팩트 버전도 발표하고 XML을 위한 ECMAScript로 E4X도 발표하게 됩니다. Edition 3출시 이후 ECMAScript 4에 대한 작업도 바로 시작되었는데 2003년에 중간보고서를 발표하면서 ActionScript, JScript.NET이 이 당시의 일부를 구현하고 있습니다. 2005년 ES4에 대한 작업이 다시 시작하며 2008년에 완료를 목표로 하고 있었지만 클래스기반의 객체지향, 다중메서드, 오퍼레이터 오버로딩, 타입 애노테이션, Strict 모드, 제너레이터등 작성해야할 피쳐리스트들이 2007년에도 2페이지가 넘었습니다.

이때 Douglas Crockford는 Ajax Experience 컨퍼런스에서 ES4 제안의 복잡성에 대해서 지적을 하기도 했으며 2007년 말 ES4가 완성될 수 없는 작업이라는 것이 명백해지기 시작했습니다. 그렇게 기대되던 ECMAScript 4와 JavaScript 2는 그렇게 그 생명을 다하게 됩니다. 이 과정에서 ECMAScript Edition 3의 마이너 패치를 위한 ECMAScript 3.1을 위한 워킹그룹도 진행이 되었으며 ECMAScript 4를 작업하는 워킹그룹과 별도로 진행이 되었지만 두 그룹의 분쟁은 어쩔 수 없는 것이었습니다. 

결국 협의 끝에 이 두그룹의 작업을 합치는 것으로 결정을 하게 되고 2008년 가을에 Brendan Eich는 Harmony 프로젝트를 발표하게 됩니다. 이 프로젝트는 파벌들을 다시 합시고 새로운 ECMAScript 표준을 계속 개발하는 작업을 돕기 위한 프로젝트입니다. 비록 ES4가 많은 부분에서 잘못되었지만 이미 많은 개발자들이 오픈소스 라이브러리를 ES4기반으로 만들었기 때문에 ES4를 완전히 버릴 수는 없었습니다.(물론 한때 열심히 전파되던 ES4의 특징들은 다 잊어버려도 됩니다.)

2009년에 "차후 ECMAScript 에디션에 대한 작업은 이전에 발표했던 ECMAScript Harmony 프로젝트의 일부로써 계속 됩니다.(Work on future ECMAScript editions continues as part of the previously announced ECMAScript Harmony project.)"라는 말과 함께 ECMA-262의 5번째 Edition이 승인되었습니다. ES5는 ES4처럼 급진적이고 혁신적이지 않았습니다. 배열메서드, Native JSON, String.trim, Date등이 추가되었으면 언어에 Function.prototype.bind, Updated object model, Strict mode, Constants, Getters/Setters등이 추가되었습니다.




Brendan Eich의 발표
이것이 현재까지의 상황이고 이 상황에 기반해서 Brendan Eich가 발표가 있었습니다. CoffeeScript를 만든 Jeremy Ashkenas와 Brendan이 JSConf에서 만나서 의기투합이 되어 Jeremy가 자신의 세션인 "CoffeeScript as a JS/next"에 첫 15분을 Brendan Eich를 위해서 양보해서 발표가 이루어지게 됩니다. Brendan의 발표자료는 Slideshare에 올려져 있고 자신의 블로그를 통해서 발표한 내용해 대해서 자세히 코멘트를 달았습니다.

Brendan의 얘기로는 JavaScript 개발자들이 미래를 두려워 하는 것처럼 보이게 된 것이 웹브라우더 벤더사들과 Ecma TC39(ECMAScript 3.1과 ECMAScript 4에 대한 커밋 책임을 가진 곳입니다.)가 그렇게 만들어 놨다는 것입니다. 그래서 JSConf를 통해서 JS 개발자들이 그들이 할 수 있는 가장 좋은 일을 할 수 있도록 독려하고자 했으며 그것은 모질라의 ES토론에 글을 쓰고 CoffeeScript를 사용하는 것과 같이 직접 행동하는 것입니다.

웹브라우져 경쟁이 뜨거워졌고 벤더사들은 개발자들이 팬이면서 지원자가 되기를 바랬지만 결과적으로 JS 해커들에게 커다란 힘을 안겨주었습니다. TC39의 멤버들이 커미터로써의 입장에서만 귀를 기울이면서 JS 커뮤니티보다는 업체들을 더 존중했기 때문에 이제 JS 개발자들이 목소리를 낼 수 있게 된 것은 아주 중요합니다.  물론 커뮤니티는 한 목소리를 낼 수 없지만 각 커뮤니티들은 자신들만의 방법으로 Prototype.js나 JQuery같은 결과물을 만들어냈습니다.



커뮤니티가 중요한 이유는 커뮤니티들은 JavaScript가 가진 가혹한 테스트에 직면해 있기 때문에 경쟁적이고 시간압받을 받으며 작업하는 커미터들보다 나은 장점을 가지고 있습니다. Andrew Dupont(prototype.js의 메인 커미터중 하나입니다.)이 JSConf에서 현재 어떻게 JavaScript 표준이 커뮤니티-프로젝트 라이브러리 방법을 통해서 시작되었는지를 얘기했다고 합니다. 이러한 사실상(de facto)의 표준은 러프(rough)하지만 진짜이고 JS가 그렇게 했습니다. 개발자들은 이길 때까지 사용자 테스트를 하고 이터레이션을 돌 것입니다. Harmony의 목표는 사실상의(de facto) 표준을 문서화 하는 것에 대해서 얘기하고 있습니다. 여기서 Harmony의 프로세스는 구현자들(implementors)이 어떻게 HTML5와 Web API 표준을 만드가를 돕는 것입니다.

TC39는 기존을 것을 사용해서 발전시킬수 있는 것(pave the cowpaths - 소의 통로를 포장한다.)대신에 새로 발명하는 것을 피해야 합니다. TC39는 발명을 더욱 더 하고자 하는 유혹에 빠졌습니다. 이 작업은 아마 완료되지 않을 것입니다.  TC39의 개발자들과 구현자들은 다른 것에서 좀더 배우고 어느정도 타협을 해야합니다.
Harmony의 목표는 좋지만 개발자들은 스스로 라이브러리 코드에서 무엇을 할수 있는지를 보여주거나 CoffeeScript같은 JS에 기반한 다른 언어 도달했습니다.


Harmony는 JavaScript가 더 나은 JavaScript가 되는 것을 도와주려고 하고 JS.next로써 표준화 될수 있도록 하기 위해서 입니다. 이것은 중요하고 큰 작업입니다. 이미 스펙으로써 하나의 오픈소스 언어(Single-open-source-as-spec)가 시작되었습니다.




JS.Next, ES.next
Brendan은 이 발표해서 현재 이슈되고 있는 가장 중요한 주제로 Tranpiler(Transcompiler)를 얘기했습니다. Tranpiler는 프로그리밍 언어의 소스코드를 다른 언어의 소스코드로 바꾸어주는 특수한 컴파일러를 의미하고 CoffeeScript가 그 중 하나인데 마침 이 JSConf에서 구글의  Allex Russel과 Peter Hallam은 Traceur을 발표했습니다. Traceur은 Hormony스러운 Tranpiler입니다.(Tracuer에 대한 더 자세한 내용은 Rhio.kim님의 자바스크립트. 그 다음 구글 Traceur에서 보실 수 있습니다.)

표준제정에 대한 관계가 복잡해서 완전히 다 파악할 수는 없었지만 분위기 상으로는 Brendan도 TC39나 ECMAScript 4와 무관하다고 할 수 없을텐데 JavaScript의 창시자가 직접 JavaScript의 표준은 커뮤니티가 주도해야 하며 지금보다 더욱 적극적으로 참여하라고 말한 것입니다. 현업 개발자들이 가장 좋은 안을 제시하고 만들어 내면 Harmony에서 그걸 표준문서화 해내겠다라는 의미정도로 받아들여집니다.그 때문에 엄청나게 많은 논의가 시작된 것입니다.

이 논의에는 프로토타입기반의 JavaScript에 OO의 특성이 어느정도 수준으로 들어와야 하냐부터 CoffeeScript나 Traceur같은 Tranpiler들이 JS.next이냐에 대한 다양한 논의부터 function이 너무 길어서 fn으로 하자는 중요도가 낮은 문제들까지 아주 다양합니다. 이 상황에서 JavaScript의 지존과도 같은 Douglas Crockford도 ES-discuss에서 현업개발자들이 아닌 언어 디자이너와 비평가들은 언어를 개선하기 위한 시도도 하지 말라라고 하면서 이 분위기를 더욱 고조시킵니다.

개인적으로는 어떻게 흘러갈지 모르기 때문에 뭔가 불투명한 것 같지만 이런 흐름의 미래는 아주 흥분되고 기대되는 일입니다. 최근 1,2년 사이에 JavaScript에 정말 많은 변화가 이루졌다고 생각하고 있는데 본격적인건 이제부터 시작인것 같습니다.



그런 면에서 Jeremy Ashkenas는 말은 아주 의미심장합니다.






[참고링크]
- Wikipedia
- History of JavaScript: Part 1
- History of JavaScript: Part 2
- History of JavaScript: Part 3
- History of JavaScript: Part 7
- ECMAScript Harmony