ECMAScript 4 논쟁이 거세게 일고 있습니다. ECMAScript는 우리가 흔히 JavaScript 혹은 JScript 언어의 표준안이죠. 넷스케이프가 표준화 기구인 ECMA에 자사의 자바스크립트 표준안을 넣은 이후 업계에서 안정적인 표준의 위치에 있습니다. ECMAScript는 99년 Version 3가 나온 이후로 약간의 기능 추가만 있다가 이번에 대대적으로 손보고 있는 중입니다.
[ECMAScript 관련 기술 지도 via John Resig]
그간의 경과 과정을 보자면 2005년에 10월에 자바스크립트 발명자이자 모질라의 CTO인 Brendan Eich가 처음 작업을 제안해서 진행 하였습니다. 한참 있다가 뒤늦은 2006년 6월 JSON을 만든 야후!의 Doug Crockford가 Microsoft가 지원하지 않으면 어쩔거냐는 우려를 표명합니다. 이에 7월모임에서 Microsoft도 IE 7 이후 버전에서 ES4를 지원할 거라고 말합니다. 그러다, 변경하는 표준안의 양이 엄청 커지자 2007년 3월에 Doug과 MS의 Petrap은 이에 대한 걱정을 시작 합니다. 그러면서 2007년 4월에 ES3를 약간 보완한 ES3.1을 전격 제출 합니다.
Doug는 Ajax Experience conference에서 ES4 작업 과정이 두 개로 나눠졌다고 말하면서 Adobe와 Microsoft과 ES4에 대한 표준 진행에 대한 제휴를 했다는 뉘양스를 풍깁니다. 이후에 격렬한 논쟁이 시작되었는데, ECMAScript 3 and beyond, ECMAScript Edition 4: Brendan Speaks Out, What I think about ES4., Open Letter to Chris Wilson 등 성명전 양상으로 치닫고 있습니다.
[ECMAScript 4 Major Features via John Resig]
Doug은 ES4가 자바스크립트가 아닌 완전히 다른 언어인데다 보안 이슈에도 안전하지 않다고 밝혔습니다. 실제로 ES4는 자바 스크립트를 전통적인 객체 지향 언어로 바꾸려는 시도를 하고 있지만, 논쟁에 초점이 되고 있는 class 기능의 경우 과거 prototype 형식으로 짜던 방식도 가능한 호환성을 유지하게 됩니다. (Brendan은 MS측에서 하위 호환성을 유지할 수 없어 기존 자바 스크립트 애플리케이션이 실행되지 않을 수 있다는 유언비어를 중단할 것을 요구했습니다.)
하지만 하위 호환성을 유지한다고 하지만 어디서 어떻게 문제가 터질지 모르는 것이죠. 지금도 이미 전통적 함수 기반 코딩 방식과 prototype 기반 방식이 혼재되어서 헷갈리는데 거기에 class 방식 까지 나오게 된다면 자바 스크립트를 copy & paste 방식으로 익히던 것은 사실상 불가능해 지겠죠. 이런 기술 개발 방식의 단점도 있지만 장점도 있다는 사실을 인정해야 합니다.
물론 ECMAScript가 JavaScript만을 위한 것은 아닙니다. ActionScript도 있고 리치 인터넷 애플리케이션을 위한 기반 인터프리터가 필요한 시점에서 더 많은 전통 개발자들 끌여들이기 위해서는 ES에 대한 이미지 개선이 절박하긴 합니다. Ruby나 Python 같은 런타임이 ES 기술 프레임웍안에 들어오게 하고 싶은 모질라나 어도비 입장에서 MS의 제동은 황당하기도 할 것 같습니다.
어찌됐던 이 진통은 겪고 나가야 하는 과정이고 과거와는 달리 공개 표준에 대한 인식이 높은 만큼 어떻게든 발전적인 방향으로 나갈 것입니다. Brendan도 이를 염두해 두어서 인지 아예 ECMAScript 관련 위키, 메일링리스트, 모임 결과 등 모든 기록을 별도 그룹 홈페이지에 모조리 공개해 놓고 있습니다. WHATWG의 HTML5 논의 역시 마찬가지고 이는 W3C에도 적잖이 영향을 주고 있죠. 표준의 진행 과정에서 무엇보다 중요한 건 투명성 이니까요.
더 읽어 볼 글
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)
개인적인 의견으로는 Brendan의 관점에 동감합니다. Open letter to Chris Wilson의 중후반에 언급한 내용에 보다시피 ES4가 경쟁적인 위협이 되기 때문에 ES3.1을 뚱딴지 같이 내어놓은게 아니냐는 이야기가 있는데 MS가 전략적으로 밀고 있는 기반이 어디인지를 유심히 살펴보면 근거가 있는 이야기입니다.[http://wiki.ecmascript.org/doku.php?id=discussion:browser_profile]에서의 Pratap(Petrap이 아닙니다.. ㅜㅜ)과의 갑론을박의 마지막 메세지를 보시면 아시겠지만 ES3.1이나 하위 호환성을 위해(?) 좀 더 단순함을 유지하는 ES4의 궤변은, WPF, WPF/E(현재의 SilverLight), Flash, Apollo 모두 Pratap의 주장과 달리 ES4의 기능을 충실히(?) 지원하고 있다는데서 무너집니다. 결국 실제 관점을 두어야 할 부분은 이런 경쟁 구도의 싸움이 아니라 Brendan의 이야기처럼 언어로써의 재기능을 찾아가는 것과 현재 안고 있는 문제를 풀어나는 것에 있지 않나 생각됩니다.
[…] 하는 등, 분위기는 뜨거워졌고, 거의 성명전(Outsider님 블로그 참고) 수준의 논쟁(Channy 님 블로그 참고), 이 지나간뒤 협회에서는 둘의 주장을 전부 […]