JavaScript 의 과거, 현재, 미래

이 글은 2013년 05월에 월간 Microsoftware  제 이름으로 기고한 글을 바탕으로 작성된 글입니다.

ECMAScript와 JavaScript

JavaScript 만큼 세상에서 오해받고, 천대받았던 언어가 갑자기 트렌드의 주류로 떠오른 (번역), 대박 인생역전 언어가 또 있을까?

이번 포스트에서는 일단 JavaScript의 표준안인 ECMAScript 에 대해 알아보고, 그 태생이 어떻게 진행되어 갔는지를 한번 써 보려고 한다.

ECMASCRIPT Cloud - by John Resig
ECMASCRIPT Cloud – by John Resig ## Released under the GPL v2

ECMAScript???

이쪽 분야에 큰 관심이 없는 사람은 ECMAScript 라는 생소한 단어를 보고 어리둥절할지 모르겠다.

ECMAScript는 JavaScript의 기초를 이루는 스크립트 언어로서, Ecma International 기구에 의하여 ECMA-262 specification 에 정의한 규격을 따른다. JavaScript는 ECMAScript를 포함하는 관계이며 ECMAScript에 여러 부가적인 요소를 덧붙인 것이 JavaScript 이다.

ECMAScript 를 기반으로 하는 언어는 JavaScript 만 있는 것은 아니고, 예전 MicroSoft 사의 JScript 나 Adobe의 Action Script 등이 있다.

역사

JavaScript는 넷스케이프에 탑재하기 위해 개발된 언어였다.

사실 시작은 엉뚱한 면이 있다. 그 당시 브랜든 아이크(BrendanEich) 는 넷스케이프에게

“10일 안에 브라우저에서 스킴(함수형 프로그래밍 언어의 일종) 이 동작하게 하겠다”

라는 조건으로 입사한뒤 언어 개발에 착수했다.

하지만 그 당시 인기 언어였던 Java 에 편승하고자 스킴 언어를 사용하려는 계획은 버리고 개발을 시작하게 되었고, 1995년 9월 역사적인 날에 넷스케이프 네비게이터 2.0에 라이브스크립트(Live Script) 라는 이름으로 탑재되어 세상에 모습을 드러내었다.

그 뒤 버전인 2.0B3에서 Sun Microsystems(현 오라클에 인수)의 동의를 얻어 이름을 JavaScript 로 변경하였다.

마이크로소프트도 이런 시류에 편승하여 Internet Explorer 3.0에 JScript가 개발되어 탑재되었는데, 이는 넷스케이프의 JavaScript의 복사본이라 할만큼 동일하였고, 상표 문제를 회피하기 위한 이름만 다른 언어였다.

이에 자극받았는지는  잘 모르겠지만, 브랜든 아이크와 넷스케이프는 JavaScript를 산업 표준화를 위해 Ecma International 에 받아들여져 ECMAScrpt 표준이 만들어졌다.

JavaScript에게는  역사적인 순간이다.
그 이후 ECMAScript 표준을 따르는 JavaScript 표준이 제안되기 시작했고 1999년 12월에 이르러서는 현재의 JavaScript의 모습을 갖춘 ECMA-262 3판의 규격을 따르는 버전이 제안되었으며 현재 이 구현(JavaScript 1.5)이 제일 널리 쓰이고 있다.

ECMA International 에서는 지속적으로 언어 규격을 변화시키고 발전시키려 노력했고 그 결과로 4번째 판을 제안하게 되었지만 많은 반대에 부딪혀 흐지부지되고 만다.

4판의 규격에는 JavaScript의 본질인 프로토타입의 특성, 간결한 표현식과는 많이 다른 이질적인 느낌의 클래스 타입 프로그래밍의 특성을 다수 도입하는 내용이었다. (클래스 객체지향, 다중 메서드 지원, 연산자 오버로딩, 타입 애노테이션, Strict Mode 등등. 이중 일부는 EcmaScript 5판에 채택되어 있다.)

이 큰 변화에 대한 반발은 거셌다.

이 변화 내용에 대해서 더글라스 크락포드 등의 유명한 JavaScript 관련 프로그래머들은 강하게 반발했으며 ECMAScript 4에 제동을 걸기 시작했다.

Douglas_Crockford
더글라스 크락포드

초보자, 웹개발자, 언어과학자가 아닌 언어 비평가들은 언어를 바꾸는 시도를 하지 말아달라
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014061.html

특히 더글라스는 위와 같은 돌직구 발언을 날리기도 하는 등, 분위기는 뜨거워졌고, 거의 성명전(Outsider님 블로그 참고) 수준의 논쟁(Channy 님 블로그 참고), 이 지나간뒤 협회에서는 둘의 주장을 전부 받아들여 발전해나가기로 결정하였다.

2011년 6월, ECMAScript 5판이 발표되어 있으며, EcmaScript Harmony 라는 이름으로 현재 6판이 작업중이다.

발전

CommonJS, AMD 등의 모듈화

JavaScript는 모듈화를 언어 자체에서 지원하지 않는다. 모듈화란 쉽게 말해 기능별로 프로그램을 나누어 기능별로 개발하고 조립해가는 방식인데, Java 같은 경우 클래스와 패키지로 지원하고 있다.

JavaScript는 모듈화에 필요한 여러 요소들이 존재하지 않기에 별도의 표준이 필요했고 그 결과 탄생된 표준 이 CommonJS,AMD이다. 이들의 목표는 JavaScript의 표준 라이브러리를 만드는 것이 목표이다.

Node.JS, Rhino

JavaScript가 자주 사용되는 곳이 클라이언트 사이드이지만 본래 JavaScript는 클라이언트에 국한된 언어가 아니다.

Node.JS 는 크롬 브라우저에서 쓰이는 V8 엔진 을 사용한 서버사이드 JavaScript 런타임으로, JavaScript를 말그대로 서버환경에서 동작시키며 프로그래밍 할 수 있다. V8 엔진의 고성능답게 현재 주목을 받고 있는 기술이다.

Rhino 는 JavaScript 인터프리터를 자바로 구현한 것으로 Java 6.0에 기본 스크립팅 엔진으로 탑재되어 있다. 이를 사용하여 자바가 돌아가는 환경이라면 어디서든 JavaScript를 조작하고 실행시켜 볼 수 있다.

CoffeeScript, TypeScript, Dart

JavaScript는 분명 언어상의 한계가 극명하다. 때로는 잘못된 설계도 보이며 그 중에는 아주 치명적인 것도 존재한다. 대표적으로 보면 전역 변수의 접근이 쉬우며 모호한 타입 비교 연산, 객체지향의 구현이 까다로운 점, 모듈화를 고려하지 않은 언어 설계 등 이다.

그러한 상황을 아예 언어적으로 벗어나고자 하는 움직임도 있는데 CoffeeScript TypeScript는 그 예들중 하나이다.

CoffeeScript는 JavaScript의 언어적인 불편함과 표현력을 루비와 파이선의 친근한 문법으로 소스코드를 작성하고 별도의 컴파일 과정을 거쳐 안정된 JavaScript를 만들어 낸다.

TypeScript는 MS에서 내놓은 JavaScript 컴파일러로서 CoffeeScript가 파이썬과 흡사한 문법이라면 이쪽은 Java와 거의 흡사한 문법이다.

위 둘과는 전혀 다른 방법으로 접근한 방식도 있는데 구글에서 발표한 Dart 이다. Dart는 언어를 컴파일하여 결과물을 JavaScript로 얻는 방식이 아니며, 별도의 VM으로 구동된다.

VM의 지원만 된다면 굉장한 속도로 사용할 수 있지만 VM의 지원이 현재는 크로미움 계열의 브라우저에서만 VM이 구동되므로 사용이 어렵다는게 아쉽다. VM을 지원하지 않는 플랫폼에도 대응하기 위하여 별도의 JavaScript 컴파일러를 제공하여 Dart 코드를 변환시킬 수 있지만 결과 코드의 효율은 그리 좋지 않은 편이다.

문법 자체는 위 TypeScript와 흡사하며 Node.JS 처럼 서버사이드 환경에서도 구동할 수 있는 것은 위 두개의 언어 컴파일러에 대비되는 확실한 장점이다

관련 트윗 중에 이 셋을 비교하면서 남긴 코멘트가 인상깊다

“자바스크립트를 C라고 하면 CoffeeScript는 파이선, TypeScript 는 C++, Dart는 자바…인가요?”

결론

JavaScript는 현재 많은 변화와 주목을 받고 있다. github (Git을 사용하는 프로젝트 호스팅 서비스. 루비 온 레일스로 작성되어 있다. 현재 거의 모든 오픈소스를 여기에서 검색할 수 있으며 전세계적으로 제일 인기있는 Git 기반 서비스이다.) 의 오픈소스의 대부분을 JavaScript 가 점령하고 있으며, 인터넷에서는 많은 스터디 그룹이 생기고 그곳에서는 시간이 다르게 다양한 의견이 오가고 있다.

관련 프로젝트나 프레임워크, 라이브러리 개발도 오픈소스 개발자 뿐 아니라 MS, Google, Adobe 등의 대기업에서도 앞다투어 참여하고 있으며 서로 자신들이 제안한 표준이 W3C에 채택되기에 노력을 아끼지 않고 있다. 스크립트는 더이상 브라우저 안에서만 동작하는 개구리가 아닌, 서버사이드 뿐 아니라 다양한 플랫폼에서 활용되고 인정받고 있다.

이는 다른 관점에서 생각해보면 JavaScript를 잘 다룬다는 것은 키워드를 서치엔진에 검색한 뒤 Copy & Paste를 잘하는 것이 아닌 보다 전문적인 지식이 필요해졌다는 것을 의미하며 언어적인 면에서 많은 부분을 공부해야 할 필요성이 있다는 것을 말해주고 있다.

역사에 대해 흥미가 생기신 분은 이 포스팅도 한번 참고해 보길 바란다.

JavaScript.next에 대해서

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중