자바스크맆트
개요
자바스크맆트(JavaScript). 중간의 S가 대문자임에 유의.
프로그래밍 언어. 특수한 목적이 아닌 이상 모든 웹 브라우저에 인터프리터가 내장되어 있다. 오늘날 HTML, CSS와 함께 웹을 구성하는 요소의 하나다. HTML이 웹 페이지의 기본 구조를 담당하고, CSS가 디자인을 담당한다면 자바스크맆트는 클라이언트 단에서 웹 페이지가 동작하는 것을 담당한다[* 이 때문에 동적인 홈페이지가 필요없다면 자바스크맆트는 안 써도 된다. 그러나 2013년 현재 웬만한 홈페이지에는 동적인 요소가 들어가므로 거의 필수적으로 쓰이는 것이 현실.].
썬 마이크로시스템즈에서 개발한 자바와는 별 관계가 없는 언어이다. 이름이 비슷하다고 같은 언어가 아니다. 사람들이 흔히 헷갈리는 부분 중 하나. 실질적인 구동 방식도 자바 가상 머신을 이용해서 돌리는 자바와, 브라우저 내에 스크립트 엔진이 존재하는 자바스크립트는 완전히 다르다. 더불어 둘의 거의 유일한 유사점인 객체지향 조차 자바는 클래스, 자바스크립트는 프로토타입을 쓰는 객체지향으로 전혀 다르다. ~~햄이랑 햄스터가 다르고 인도가 인도네시아랑 다르듯이~~
처음에 지금은 없어진 넷스케이프사에서 내비게이터 웹 브라우저에 자바에 대한 지원을 넣을 때쯤, 라이브스크립트(LiveScript)라는 스크립트 언어를 브라우저에 포함시켰다. 그리고 자바와 구문이 유사하기도 하고 해서 이름을 자바스크립트(JavaScript)로 명명했다 는 표면상의 이유고 그 속은 자바의 유명세를 타서 묻어가려고 의도적으로 만든것이다.
자바스크립트의 초기 역사는 말 그대로 네스케이프의 삽질기다. 자바스크립트는 본래 네스케이프 서버에서 애플리케이션을 제작하기 위한 고수준 추상화 언어로 설계되었다. 그러나 자바스크립트는 당시 기준에서 무리한 추상화[* 1990년대 중반에 발표된 언어가 요즘 새롭게 나오는 언어들 보다도 더 한 추상화를 자랑한다]를 시도했기 때문에 성능 문제가 많았다. 게다가 마케팅좀 해보자고 붙인 이름인 자바스크립트가 자바의 열화판이라는 느낌이라서 당시 개발자들 사이에서 이름으로 무시당했다[* 그때는 자바를 할 줄 알면 자바스크립트를 몰라도 깔 수 있었다. 이름으로...]. 여기에 더해서 그나마 클라이언트용 자바스크립트 엔진에 있던 시스템 자원 접근용 API[* 과거에는 브라우저의 자바스크립트 엔진이 파일시스템 같은 자원에 접근할 수 있었다.]들이 보안사고의 원인이 되면서 삭제되는 과정에서, 별다른 보완 방법을 제시하지 못해 진정한 웹 전용 반쪽 언어로 찌그러지게 되었다. 그 후 네스케이프는 착실하게 망해갔고, 주요 API인 DOM은 마이크로소프트와 네스케이프의 자존심 싸움 속에서 조각나 버렸다[* 이때 생겨난 것이 지금도 남아있는 크로스 브라우징 문제다. 혹자는 이 상황을 두고 고자 API가 정신분열을 일으킨 것이라 평하기도 한다(...)]. 그러던 것이 마이크로소프트에서 1999년에 처음으로 XMLHttpRequest 기능을 제공하기 시작했고, 모질라에서 이것을 흉내내어 비슷하게 구현하면서 2002년에는 브라우저 자바스크립트에서 쓸 수 있도록 API에 노출시켰다. 이후 이것이 인기를 끌어 사실상 표준처럼 되고 AJAX 개발도 가능해지면서, 인터넷 신세계가 열리고 말그대로 대박이 났다.[* 물론 네스케이프는... 모질라 얘기가 나온 것에서 알 수 있겠지만 이미 망해서 구원받을 수 없는 상태].
오늘날 자바스크립트의 주된 용도는 동적 웹 페이지 제작이다. 즉, 홈페이지상의 구성 요소를 제어하기 위한 용도로 사용한다. 자바스크립트가 워낙에 유용했기 때문에 마이크로소프트는 인터넷 익스플로러 3.0에서부터 JScript라는 자바스크립트 비스무리-한 구현을 추가하였다. 이 때문에 인터넷 익스플로러에서만 동작하는 자바스크립트(정확히는 JScript) 코드가 나타나는 등 중구난방이 될 뻔했는데...
현재는 ECMAScript라는 표준안이 나와있다. 따라서 JScript든 자바스크립트든 모두 저 표준 규격을 따르기 때문에 별 불편함 없이 프로그래밍할 수 있는 상태. 참고로 저 ECMAScript는 어도비 플래시의 액션스크립트 문법으로도 사용되고 있다.
크로스 사이트 스크립팅(XSS)같은 해킹 기법에 필수불가결(...)하기 때문인지 대부분의 게시판 및 사용자 입력을 받아들이는 필드에는 스크립트 태그의 사용을 제한하는 경우가 많다.
홈페이지의 내용을 부분적으로 바꿔주는 wiki:"ajax#s-1" AJAX기법이 자바스크립트를 기반으로 작동한다.
자바스크립트는 멀티-패러다임 언어로 명령형, 함수형, 객체지향형 언어다. 간혹 클래스가 없어서 객체지향이 아니라고 생각하는 사람들도 있으나[* 요즘은 별로 없으나 옛날에는 꽤 많았다.] 프로토타입 객체지향으로 방식이 달라서 그렇지 객체지향 언어다. 또한 명령형 언어라 덜 그래보이지만 기본 바탕으로 함수형 언어의 패러다임을 따른다. 그래서 Continuation Passing Style 같은 함수형 언어 스타일로 프로그램을 짜면 아주 잘 돌아간다[* 물론 CPS자체는 함수형 언어가 아닌 다른 언어들에도 적용가능하다. 하지만 함수형 언어가 아닌 경우 CPS를 쓸 필요는 별로...]. 그리고 함수형 언어답게 프로그램 시작부터 끝까지 익명함수(람다함수)만 이용해서 코딩할 수도 있다.
자바스크립트는 동적 타이핑, 약타입 언어고, 간단한 문법에 코딩 방법이 비교적 유연하기 때문에 초기 진입장벽이 거의 없어서 쉽다고 이야기 되지만, 깊이 들어가보면 매우 특이한 --변태적-- 언어다. 예를 들어 자바스크립트에서는 Function이 거의 전지전능한다[* 함수가 일급 객체인 것으로 자바스크립트 뿐만 아니라 거의 모든 함수형 언어들의 일반적 특징이다. 근데 함수형 언어 자체가 비주류여서 일반적 관점으로 볼 때 충분히 특이하긴 하다.] 내부에 아무거나 다 때려 넣을 수 있는데, Douglas Crockford의 설명에 의하면 일반 객체지향언어의 Class, Constructor, Method 모두 Function으로 구현된다. 게다가 명령형 언어라서 짧은 동작들의 경우 절차적 프로그래밍을 해도 잘 돌아가는 것 처럼 보이지만 사실 객체지향 + 함수형 언어라는게 함정이어서 긴 코드를 짜보면 의외로 골치아프다[* 물론 절차적 프로그래밍에 익숙한 사람 기준에서다.]. 예를 들어 웹브라우저나 node.js 서버에서도 자바스크립트의 비동기 프로그램 작성시에는 스레드를 분기하여 작업을 분산 처리하거나 코루틴으로 작업을 대기 시키는 대신 컨티뉴에이션(+타이머)만 이용해 비동기 프로그램을 구현한다. 즉 싱글스레드 위에 시분할만 존재하고 무조건 1 프로세스 1 스레드로 작동한다. 스레드 분기와 코루틴 같은 추상화된 비동기 처리 자원에 익숙한 프로그래머들이라면 이러한 방식으로 인하여 꽤 고생할 수 있다. 반대로 자바스크립트 커뮤니티에서는 싱글스레드와 컨티뉴에이션의 단순하고 투명한 작동 모델이 오히려 프로그램을 더 좋게 만든다는 의견도 있다.
자바스크립트는 웹에서의 광범위한 사용처에 비해서 진지하게 매달리는 개발자가 적은편이다. 여기에는 여러가지 이유가 있지만 근본적으로 주 용도가 클라이언트측에서 작동하는 언어기 때문에 개발하면 무조건 오픈소스가 되어버린다는 점이[* 브라우저로 소스를 전송해줘야 작동하므로 자바스크립트로 만든 프로그램은 이용자가 항상 소스를 볼 수 있다.] 문제로 작용하고 있다. 즉 내가 a라는 기능의 자바스크립트 프로그램이 필요하다면 그 기능이 돌아가고 있는 사이트에서 소스를 받아다 적당히 고치면 구현할 수 있다는 것. 그래서 자바스크립트는 퍼다 쓰는 것이 이득이고, 새로운 것을 만들면 손해라는 인식이 퍼졌던 것이다. 하지만 요즘은 자바스크립트가 다시 주목받고 있다. 그 이유는 우선 복잡한 자바스크립트를 이용한 대규모 웹 서비스들이 돈을 잘 벌고 있다는 것, 또한 CommonJS와 같은 유용한 API 라이브러리를 이용하여 자바스크립트로 훌륭한 프로그램을 개발할 수 있게 되었다는 점 등이 있다.
최근에는 아예 자바스크립트에서 많이 쓰이는 여러가지 기능들을 포함해 넣어놓은 라이브러리도 여러 종 배포되고 있다. Prototype이나 jQuery는 꽤 유명한 자바스크립트 라이브러리. 이 라이브러리를 잘 익혀두면 직접 짜는 것보다 꽤 간단하게 기능을 불러 쓸 수 있다.
DOM<ref>Document Object Model</ref>과 JavaScript
오늘날 자바스크립트 프로그래밍이 가장 널리 쓰이는 분야는 클라이언트용 인터페이스 프로그램이다. 이 때 자바스크립트는 웹브라우저에서 제공되는 DOM을 API로 사용하게 된다. 문제는 이 DOM이 심히 후진 물건이라는 것. 이벤트의 경우 브라우저마다 구현이 다르게 되고 있는 경우가 많고, 실질적으로 자바스크립트용 API로 쓰이는 경우가 대부분인 주제에 자바스크립트의 주요 문법 중 일부와 충돌하는 위엄을 자랑한다. 또 기능 설명을 보고 나면, 상식적으로 HTML페이지 속 특정 엘레먼트를 찾아서 지정하는 기능이 강력 할 것 같지만, 실재로는 매우 부실하다.
다만 이러한 단점들은 오늘날 상당히 개선되었다. 문제는 워낙 개선폭이 컸던 탓에 IE8과 같은 구형 브라우저와 최근의 브라우저들 사이에 채울 수 없는 성능/기능상의 격차가 벌어졌다는 것. 아래 나온 jQuery도 최신 버전에서는 IE8 이하는 지원을 포기한 상태로 시작하고 있다.
이러한 DOM의 병맛에서 나온 것들이 위의 JQuery 같은 라이브러리다. DOM의 구조와 구현을 조금이라도 상식적으로 바꾸어보려고 발버둥 친 결과물인 것.
CommonJS
비록 자바스크립트가 이용가능한 자원이 한정적이고 자바의 짝퉁 같은 이름이기는 해도 순수하게 프로그래밍 언어로서는 상당히 우수한 설계를 자랑[* 물론 사람이 만든 것이라 설계 결함도 많이있다.]한다. 자바스크립트의 일급객체는 함수를 포함[* 이러면 함수가 인자로 함수를 전달받을 수 있어서 프로그래밍이 대단히 편리해진다.]하며, 우수한 텍스트 표기법(JSON)[* JavaScript Object Notation, 즉 자바스크립트 객체 표기법으로 지금은 다른 언어들에도 도입되어 있다.]을 가졌으며, 람다를 쓸 수 있고, 구조적으로 비동기 프로그래밍에 유리하다. 하지만 동시에 성능 문제를 해결하기 아주 어려운 설계이기도 했다.
그러던 것이 구글이 브라우저에 V8엔진을 쓰면서 성능문제를 상당히 개선하였다. 이 자바스크립트 엔진은 인터프리터 방식이 아닌 JIT컴파일을 해서 엄청난 성능을 낸 것이다. 이 후 마이크로소프트,애플,모질라,오페라라는 업계에서 한가닥 하는 집단들이 경쟁적으로 고성능 자바스크립트 엔진을 개발하게되었다. 지구 수비대급 개발력에 떠밀려 성능문제가 해결된 자바스크립트는 과거에 상상도 못할 정도로 속도가 빨라져서 지금은 자바스크립트 3D게임엔진도 개발되고 있다. 이러한 발전 속에서 과거 이루지 못한 자바스크립트의 범용 프로그래밍 진출을 도모하는 새로운 표준이 CommonJS다. 핵심은 간단해서 자바스크립트에 파이썬과 유사한 모듈을 도입하도록 표준을 정하는 것이다. 이 CommonJS를 이용한 모듈식 확장을 하면 자바스크립트 프로그램을 쉽게 구조화 할 수 있게 된다.
CommonJS의 현재 사양은 모듈 1.0 이다. 이 표준을 이용한 가장 유명한 플래폼은 Node.JS로 자바스크립트를 이용한 서버다. 이 서버는 꽤 인기를 끌고 있는데, 웹의 프론트엔드와 백엔드를 동일 언어로 프로그래밍 함으로서 얻는 이득이 상당하고, 순수한 서버로서의 성능이 꽤 좋은편이기 때문이다.
기타
해외에서는 자바스크립트를 결과물로 내보내는 컴파일러가 많이 등장하고 있다. 이와 함께 고성능을 요구하는 프로그램을 작동시키기 위해 가비지 컬렉터와 산술 연산을 지금보다 효율적으로 수행하기 위한 서브셋 개발이 진행중이다. LLJS(Low-Level JavaScript)와 asm.js가 대표적이다. 이러한 서브셋과 컴파일러는 C++ 같은 언어로 작성된 프로그램을 자바스크립트로 컴파일 해서 돌릴 수 있게 한다. 또한 JSIL은 CIL과 .net 가상기계를 다시 자바스크립트로 컴파일 하는 프로젝트다.
함께 보기
참고할만한 곳
참조
<references/>