IT/모바일
저자: 스티브 참피언(Steve Champeon), 역 전순재
자바 프로그래머가 아닌 사람들과 웹 디자이너들도 자바 애플릿(1995년 넷스케이프 네비게이터가 새로이 추가 지원)에 쉽게 접근해줄 필요성으로 탄생한 것이 바로 자바스크립트이다. 이것은 강력한 스크립팅 언어로 종종 "간단하다(simple)"라고 평가된다.
초기에는 보안 결함때문에 심각한 고초를 겪었고, 통합 개발 환경, 디버거, 의미있는 에러 메시지와 같은 강력한 개발 도구가 없었기 때문에 반신불수 상태였으며, 상황이 최초 디자이너들의 의도를 넘어서 확장되어 버렸고, 호환성 없는 브라우저 객체 모델의 유산에 걸터 앉아 있었기 때문에 자바스크립트는 수 년간 비평가들의 손에서 비난을 받으며 고생을 해 왔다. 비평가들은 다음과 같은 이유로 자바스크립트를 비난하였다. "자바스크립트는 자바와는 사뭇 다르고 펄과 많이 닮았으며 의도는 좋지만 무지한 웹 디자이너에 의해서 너무 자주 사용된다. 그리고 웹 디자이너들이 미래의 호환성에 대해서는 고려하지 않을 뿐만 아니라 지능적인 추상화나 코드의 재사용에 대해서도 생각하지 않고 억지로 자바스크립트를 끼워 넣으려 한다."
그렇지만 이러한 비난과는 달리 자바스크립트는 현재 웹에서 가장 인기있는 언어이다. 차세대 역동적인 클라이언트측 웹 애플리케이션을 위한 토대이며, 환상적인 잠재력과 능력을 가진 견고한 코어언어가 바로 자바스크립트이다. 도대체 왜 더 많은 프로그래머들이 자바스크립트를 도구상자에 꼭 있어야 할 도구로 여기게 되었는가? 이제 자바스크립트(nee LiveScript)의 역사를 간략하게 살펴 보고 자바스크립트의 기원과 향후 나아갈 방향에 대해 자세히 살펴 보도록 할 것이다.
초기의 웹의 세계로 돌아가보자
1995년 초로 되돌아 가자. 넷스케이프는 브렌단 아이히(Brendan Eich)를 MicroUnity Systems Engineering사로부터 고용하면서 그에게 새로운 언어를 디자인하고 구현하는 임무를 맡겼다. 네비게이터(Navigator)에 새로이 추가된 자바 지원을 자바 프로그래머가 아닌 사랍들도 쉽게 접근할 수 있게 해주라는 임무를 부여 받자, 아이히(Eich)는 결국 그 환경과 대상에 느슨한 형 정의(loosely-typed) 스크립트 언어가 적당하다고 결정하였다. 즉 수 많은 웹 디자이너와 개발자들은 바이트코드 컴파일러나 객체-지향 소프트웨어 디자인을 모르고서도 (폼, 프레임, 또는 이미지와 같은) 페이지 요소들을 다룰 수 있어야 했다.
그가 만들어 낸 언어는 그 역동적인 본성을 반영하여 "라이브스크립트(LiveScript)"라는 이름이 붙여졌으나 곧바로 (Navigator 2.0 베타 사이클이 끝나기 바로 전에) 자바스크립트로(JavaScript) 개명되었다. 그 개명때문에 시장에서 웹 다자이너들이 수 년간 고통스러워 했는데 그 이유는 메일링 리스트와 유스넷(Usenet)에서 그 두 용어를 끊임없이 혼동했기 때문이다. 넷스케이프와 썬은 1995년 12월 4일 공동으로 그 새로운 언어를 선언하면서, HTML과 Java 모두에 꼭 필요한 "단짝(complement)"이라고 불렀다.
자바스크립트는 즉시 자생의 길을 걸어나가기 시작했다. 자바 애플릿을 제어하기 보다는 문서 내용과 이미지를 조작하는데 더 흔하게 사용되었기 때문이다. 아마도 (활판인쇄가인 데이비드 시겔(David Siegel)과 그 동료들에 의해서 주도된) 그 시대의 조류를 반영하여 이전의 정적인 웹에 완전한 상호작용과 세밀한 사용자 인터페이스 그리고 활판 인쇄의 개념을 도입하려고 했을 것이다. 특히 초기 몇 년간 사용된 대다수의 스크립트가 사용자가-만든 마우스 이벤트에 대한 반응으로 그저 한 이미지를 다른 이미지로 바꾸는 것이었다는 점이 인상적이지 않을 수 없다.
자바스크립트가 진입 장벽이 낮은 프로그래그래밍 언어로 크게 성공하자 (컴파일러가 전혀 필요없기 때문에, 스크립트는 편집하는 수고조차도 필요없이 기존의 HTML 페이지에 복사할 수 있고 붙여 넣을 수 있어서 마치 브라우저에 단단하게 묶여 있는 듯이 보였다.) 많은 전문 프로그래머들이 자바스크립트를 장난감처럼 작성해 내었다. 초기에는 자바스크립트의 파워와 상대적으로 저-파워인 렌더링 엔진사이의 충돌 때문에 동적인 클라이언트측 트리 위젯(tree widgets) 등등과 같은 초기의 사용자 인터페이스(UI) 실험들이 화면에 피곤하게 어른거렸다.
언뜻 아무 기술이 없이도 사용할 수 있어 보이는 언어라고 해서 무시당하고, IDE와 신뢰성있는 플랫폼 독립적인 디버거도 없으며, 실제 브라우저에서 테스트될 때에만 페이지가 보여질 수 있고, 아주 널리 공개된 보안 결함들과 프로그래머가 아닌 사람들을 목표로 한 책들로 인해 많은 사람들은 초보자를 위한 "간단한" 언어로서 자바스크립트를 마구 작성하게 되엇다. 그리고 이러한 남발은 자바스크립트의 놀라운 잠재력을 가려버렸다.
잇따른 네비게이터(Navigator) 배포본에는 플러그인, 더욱 개선되고 더 엄격해진 보안 모델 등등과의 스크립트 주도형 상호작용에 대한 지원이 포함되었다. 넷스케이프 라이브와이어(LiveWire)는 데이터베이스 질의를 수행하고 다른 진보된 특징들을 수행할만한 서버측 언어로 자바스크립트를 도입하였다. 그렇지만 서버측 스크립팅은 ASP나 펄 또는 콜드 퓨전(Cold Fusion)만큼의 인기를 끌지는 못했으며 넷스케이프 서버 고객들을 제외하고는 거의 모든 사람들에게 무시되었다. 자바스크립트의 운명은 문서 저작자들이 클라이언트의 능력을 제어하고 확장하는데 있었다.
자바스크립트에 대한 마이크로소프트사의 대응
마이크로소프트는 자사의 VBScript 언어를 배포함으로써 자바스크립트에 부분적으로 대응하였다(VBScript는 그 자신을 임베디드 컴포넌트에 걸어 넣을(hooking into) 능력이 있었다. 초기에는 그러한 컴포넌트들이 처음으로 구현되었던 윈도우라는 플랫폼에 한정되어 있기는 했지만 말이다). 게다가 마이크로소프트는 1996년 7월 16일 "JScript"라고 부르는 일종의 자바스크립트를 배포한다. 인터넷 익스플로러 3.0은 캐스케이딩 스타일시트(Cascading Stylesheets)와 같이 W3C가 새롭게 비준한 표준을 지원한다는 관점에서 보면 놀라운 기술적 진보였을 테지만 그렇지 못하고 네비게이터(Navigator)의 자바스크립트(JavaScript)보다 한 발 늦게 수정되었다. 그리고 버전 3.02가 배포될 때까지는 한발 뒤쳐져 있었다.
많은 디자이너들은 그저 그들이 만든 스크립트를 네비게이터(Navigator)에 대해서만 점검하였고 명분이 없다는 이유로 인터넷 익스플로러는 무시하였다. 마치 초기의 CGI 프로그래머들이 사용자가 주관하는 환경 변수에 "Mozilla"를 점검하였고, 결과적으로 오늘날에도 여전히 준수하고 있는 우스꽝스러운 관례가 만들어졌듯이 말이다. 실제적으로 모든 주요 브라우저들은 제일 먼저 자신을 "Mozilla"로 선언하고, 두 번째로 "(compatible; BrowserName)"으로 선언하였다. 간단히 말해, 자바스크립트는 플랫폼 독립적이면서 표준 주도형 웹으로 가는 길목을 가로막는 또다른 장애물이 되어 버렸기 때문에 전적으로 좋은 평판을 얻지는 못했다.
ECMAScript: 표준화의 시도
인터넷 익스플로러 3이 도입되면서 document.images 배열이 지원되지 않았기 때문에 넷스케이프와 썬은 그 언어를 ECMA(European Computer Manufacturers Association)의 도움을 받아 표준화하였다. 그 결과 그 언어에는 ECMAScript라는 또다른 이름이 주어졌다. ECMAScript는 강력하고 보편적으로 지원되는 코어 기능과 비호환 객체 모델과의 기묘한 혼합물이 되었다. ECMA와 공동으로 1996년 11월에 표준화가 시작되어서 1997년 6월에 ECMA가 채택하였고 ISO는 1998년 4월에 채택하였다.
그 동안 ECMAScript가 표준화되면서 (그러나 안타깝게도 코어만 빼고는 거의 모든 것을 무시) 넷스케이프와 마이크로소프트는 각각 4.0 브라우저를 만들어 냈다. 그리고 각 브라우저는 완전히 독자적인 문서 객체 모델을 가졌으며 "Dynamic HTML"이 그 다음 골치거리가 되어 자바스크립트의 선의가 심한 열병을 앓았다.
기능의 분열(Fiefdoms)
크로스-브라우저 DHTML 애플리케이션을 필수적으로 지원하기 위해서는 수 많은 자질구레한 작업과 여러 구현이 필요하다. 어떤 사람들은 네비게이터가 익스플로러처럼 동작하도록 해주는 라이브러리를 제공하기도 했다. 반대로 어떤 사람들은 익스플로러가 네비게이터처럼 작동하도록 해주는 라이브러리를 제공하기도 했다. 프로그래머들이 비호환 코드를 일관성 있는 API로 싸 넣도록 도움을 줄 라이브러리를 모든 사람들이 제공했지만, 사람들은 최소한의 공통 분모조차도 거의 모든 어플리케이션에 대하여 너무 느렸다는 것을 곧 깨닫게 되었다. 그 결과 많은 사람들은 네비게이터 대신 윈도우 익스플로러를 더 많이 사용하게 되었고 웹은 더욱 분열되어 작은 영역으로 기능이 제한되어 버렸다.
브라우저 전쟁이 격렬하게 진행되는 동안, 마이크로소프트와 넷스케이프, 그리고 수십 개의 다른 회사들은 W3C와 협력하여 보편적인 DOM(Document Object Model)을 위한 작업토대를 (W3C DOM의 틀구성자(framers)들에 의해 "Level 0"으로 지칭되는) 최초의 브라우저 객체 모델과 하위 호환성을 유지하면서 쌓으려고 하였다. 과거의 연속선상에서 SGML-계승 플랫폼으로 유지하고자 하는 욕구 때문에 웹은 상대적으로 간단하고 강력한 XML의 지원을 받아 또다른 추상화 층을 도입하였으며, 결론적으로 몇 년 동안 비호환적인 구현 또는 부분적인 구현이라는 결과에 이르렀다.
오픈 소스 모질라(Mozilla) 프로젝트는 수년간을 소비하면서도 공개적으로 안정적인 배포나 광범위한 배포가 이루어지지 않았다. 반면에 마이크로소프트는 브라우저 시장의 점유율을 바짝 졸라 매었다. DHTML 프로그래머들은 크로스-브라우저 DHTML의 복잡성, 표준 지원에 대한 새삼스러운 강조, 플래시(Flash)와 같은 상호작용적 컨텐츠(content)를 제공하는 다른 도구들의 출현들 때문에 상당부분 움츠러들었다.
자바스크립트는 오늘 우리를 떠나 어디로 가는가?
2001년 자바스크립트가 상황-종속적 모듈에 의존하는 것은 한편으로는 강력한 힘의 원천이기도 하며 다른 한편으로 구현에 있어서는 치명적인 약점이기도 하다. 펄이나 자바 또는 다른 언어들과는 달리, 자바스크립트(JavaScript)의 능력은 개발자에 의해서 확대되거나 오버라이드될 수 없다. 대신에 개발자들은 전적으로 브라우저 벤더들의 결정에 의존한다. 자바스크립트는 아주 유연하게 많은 약점들을 극복할 수 있지만 기초적인 상황에-얽매인(context-enslaved) 객체 모델의 비호환성은 극복할 수 없다.
또한 소스를 감추는 능력을 갖추지 못한 것도 애플리케이션 개발의 장애가 되고 있다. 코드의 주인은 자신의 지적 재산권을 보호하기를 원하기 때문이다. 통합개발환경(IDE), 디버거, 그리고 다른 표준 개발 도구의 계속된 부재도 프로그래머들이 여전히 간과할 수 없는 문제들이다. 프로그래머들은 디버거가 없는 플랫폼에서 디버깅하는 것이 너무 어렵다는 그럴듯한 구실로 윈도우 전용 애플리케이션을 옹호한다. WYSIWYG 도구 벤더(vendors)들은 탁월한 크로스-브라우저 자바스크립트 라이브러리를 그들의 페이지 구축 도구 안으로 통합해 넣는데 성공했으며, 오직 구형 넷스케이프의 document.layers 객체 모델을 모질라가 포기한 것만 제외되었을 뿐이다.
그럼에도 불구하고 자바스크립트는 진화를 거듭해 (연관 배열(associative arrays), 느슨하게 형 정의되는 변수(loosely typed variables), 정규 표현식(regular expressions)이라는) 펄의 가장 뛰어난 특징들과, (산뜻하게 블록단위로-해석되는 구문, 객체 그리고 클래스, 고도로 진화된 date, math, 그리고 string 라이브러리라는) C/C++과 Java의 탁월한 특징들, 그리고 (광범위하게 이식된 어플리케이션 제어 환경이라는) TCL의 장점들을 최신의 브라우저(Mozilla, Netscape 6, IE6/Windows 그리고 IE5/Mac)에 구비된 W3C DOM에 놀라울 정도로 강력하게 결합하였다.
Blox, KnowNow, 기타 등등과 같은 회사들은 클라이언트측 자바스크립트를 사용하면서 동시에 지능적인 서버측 도구를 함께 사용하여 차세대 웹기반 애플리케이션을 생산하고 있다. 심지어 마이크로소프트조차도 C#을 떠들석하게 선전하는 것을 보면 자바스크립트의 파워를 인식한 듯이 보인다. MSDN 샘플 또는 한번쓰고-버릴 스크립트 또는 기타 등등… 아무거나 하나를 꺼내 보면 최소한 부분적으로라도 자바스크립트로 작성되어 있는 것을 볼 수 있다.
자바는 썬과 여러 세력 사이의 널리 공개된 내부 반목과 싸움의 틈바구니에서 고난을 겪어 왔다. VBScript는 마이크로소프트에 의해서 거의 포기된 상태이지만, 그렇다고 해서 컴파일러인 C#이 언제나-필요한 스크립트 언어의 임무를 채워줄 수는 없다. 자바스크립트(JavaScript)는 웹을 정복하였다. 이제 자바스크립트에 대해서 더 자세히 알아보는 것은 어떤가? 무엇을 알아야 하는가? 오랫동안 무시를 받아온 이 원숙한 초강력 언어에 어떻게 접근해야 하는가? 이러한 문제들에 접근해 볼 가치는 충분하다.
스티브 참피언(Steve Champeon)은 웹 전문 개발자, 작가, 편집자이다. NC, 랄레이(Raleigh)에 있는 웹 서비스 회사 hesketh.com의 CTO로 근무하고 있다.
자바 프로그래머가 아닌 사람들과 웹 디자이너들도 자바 애플릿(1995년 넷스케이프 네비게이터가 새로이 추가 지원)에 쉽게 접근해줄 필요성으로 탄생한 것이 바로 자바스크립트이다. 이것은 강력한 스크립팅 언어로 종종 "간단하다(simple)"라고 평가된다.
초기에는 보안 결함때문에 심각한 고초를 겪었고, 통합 개발 환경, 디버거, 의미있는 에러 메시지와 같은 강력한 개발 도구가 없었기 때문에 반신불수 상태였으며, 상황이 최초 디자이너들의 의도를 넘어서 확장되어 버렸고, 호환성 없는 브라우저 객체 모델의 유산에 걸터 앉아 있었기 때문에 자바스크립트는 수 년간 비평가들의 손에서 비난을 받으며 고생을 해 왔다. 비평가들은 다음과 같은 이유로 자바스크립트를 비난하였다. "자바스크립트는 자바와는 사뭇 다르고 펄과 많이 닮았으며 의도는 좋지만 무지한 웹 디자이너에 의해서 너무 자주 사용된다. 그리고 웹 디자이너들이 미래의 호환성에 대해서는 고려하지 않을 뿐만 아니라 지능적인 추상화나 코드의 재사용에 대해서도 생각하지 않고 억지로 자바스크립트를 끼워 넣으려 한다."
그렇지만 이러한 비난과는 달리 자바스크립트는 현재 웹에서 가장 인기있는 언어이다. 차세대 역동적인 클라이언트측 웹 애플리케이션을 위한 토대이며, 환상적인 잠재력과 능력을 가진 견고한 코어언어가 바로 자바스크립트이다. 도대체 왜 더 많은 프로그래머들이 자바스크립트를 도구상자에 꼭 있어야 할 도구로 여기게 되었는가? 이제 자바스크립트(nee LiveScript)의 역사를 간략하게 살펴 보고 자바스크립트의 기원과 향후 나아갈 방향에 대해 자세히 살펴 보도록 할 것이다.
초기의 웹의 세계로 돌아가보자
1995년 초로 되돌아 가자. 넷스케이프는 브렌단 아이히(Brendan Eich)를 MicroUnity Systems Engineering사로부터 고용하면서 그에게 새로운 언어를 디자인하고 구현하는 임무를 맡겼다. 네비게이터(Navigator)에 새로이 추가된 자바 지원을 자바 프로그래머가 아닌 사랍들도 쉽게 접근할 수 있게 해주라는 임무를 부여 받자, 아이히(Eich)는 결국 그 환경과 대상에 느슨한 형 정의(loosely-typed) 스크립트 언어가 적당하다고 결정하였다. 즉 수 많은 웹 디자이너와 개발자들은 바이트코드 컴파일러나 객체-지향 소프트웨어 디자인을 모르고서도 (폼, 프레임, 또는 이미지와 같은) 페이지 요소들을 다룰 수 있어야 했다.
그가 만들어 낸 언어는 그 역동적인 본성을 반영하여 "라이브스크립트(LiveScript)"라는 이름이 붙여졌으나 곧바로 (Navigator 2.0 베타 사이클이 끝나기 바로 전에) 자바스크립트로(JavaScript) 개명되었다. 그 개명때문에 시장에서 웹 다자이너들이 수 년간 고통스러워 했는데 그 이유는 메일링 리스트와 유스넷(Usenet)에서 그 두 용어를 끊임없이 혼동했기 때문이다. 넷스케이프와 썬은 1995년 12월 4일 공동으로 그 새로운 언어를 선언하면서, HTML과 Java 모두에 꼭 필요한 "단짝(complement)"이라고 불렀다.
자바스크립트는 즉시 자생의 길을 걸어나가기 시작했다. 자바 애플릿을 제어하기 보다는 문서 내용과 이미지를 조작하는데 더 흔하게 사용되었기 때문이다. 아마도 (활판인쇄가인 데이비드 시겔(David Siegel)과 그 동료들에 의해서 주도된) 그 시대의 조류를 반영하여 이전의 정적인 웹에 완전한 상호작용과 세밀한 사용자 인터페이스 그리고 활판 인쇄의 개념을 도입하려고 했을 것이다. 특히 초기 몇 년간 사용된 대다수의 스크립트가 사용자가-만든 마우스 이벤트에 대한 반응으로 그저 한 이미지를 다른 이미지로 바꾸는 것이었다는 점이 인상적이지 않을 수 없다.
자바스크립트가 진입 장벽이 낮은 프로그래그래밍 언어로 크게 성공하자 (컴파일러가 전혀 필요없기 때문에, 스크립트는 편집하는 수고조차도 필요없이 기존의 HTML 페이지에 복사할 수 있고 붙여 넣을 수 있어서 마치 브라우저에 단단하게 묶여 있는 듯이 보였다.) 많은 전문 프로그래머들이 자바스크립트를 장난감처럼 작성해 내었다. 초기에는 자바스크립트의 파워와 상대적으로 저-파워인 렌더링 엔진사이의 충돌 때문에 동적인 클라이언트측 트리 위젯(tree widgets) 등등과 같은 초기의 사용자 인터페이스(UI) 실험들이 화면에 피곤하게 어른거렸다.
언뜻 아무 기술이 없이도 사용할 수 있어 보이는 언어라고 해서 무시당하고, IDE와 신뢰성있는 플랫폼 독립적인 디버거도 없으며, 실제 브라우저에서 테스트될 때에만 페이지가 보여질 수 있고, 아주 널리 공개된 보안 결함들과 프로그래머가 아닌 사람들을 목표로 한 책들로 인해 많은 사람들은 초보자를 위한 "간단한" 언어로서 자바스크립트를 마구 작성하게 되엇다. 그리고 이러한 남발은 자바스크립트의 놀라운 잠재력을 가려버렸다.
잇따른 네비게이터(Navigator) 배포본에는 플러그인, 더욱 개선되고 더 엄격해진 보안 모델 등등과의 스크립트 주도형 상호작용에 대한 지원이 포함되었다. 넷스케이프 라이브와이어(LiveWire)는 데이터베이스 질의를 수행하고 다른 진보된 특징들을 수행할만한 서버측 언어로 자바스크립트를 도입하였다. 그렇지만 서버측 스크립팅은 ASP나 펄 또는 콜드 퓨전(Cold Fusion)만큼의 인기를 끌지는 못했으며 넷스케이프 서버 고객들을 제외하고는 거의 모든 사람들에게 무시되었다. 자바스크립트의 운명은 문서 저작자들이 클라이언트의 능력을 제어하고 확장하는데 있었다.
|
참고 도서 JavaScript: The Definitive Guide, 4th Edition |
자바스크립트에 대한 마이크로소프트사의 대응
마이크로소프트는 자사의 VBScript 언어를 배포함으로써 자바스크립트에 부분적으로 대응하였다(VBScript는 그 자신을 임베디드 컴포넌트에 걸어 넣을(hooking into) 능력이 있었다. 초기에는 그러한 컴포넌트들이 처음으로 구현되었던 윈도우라는 플랫폼에 한정되어 있기는 했지만 말이다). 게다가 마이크로소프트는 1996년 7월 16일 "JScript"라고 부르는 일종의 자바스크립트를 배포한다. 인터넷 익스플로러 3.0은 캐스케이딩 스타일시트(Cascading Stylesheets)와 같이 W3C가 새롭게 비준한 표준을 지원한다는 관점에서 보면 놀라운 기술적 진보였을 테지만 그렇지 못하고 네비게이터(Navigator)의 자바스크립트(JavaScript)보다 한 발 늦게 수정되었다. 그리고 버전 3.02가 배포될 때까지는 한발 뒤쳐져 있었다.
많은 디자이너들은 그저 그들이 만든 스크립트를 네비게이터(Navigator)에 대해서만 점검하였고 명분이 없다는 이유로 인터넷 익스플로러는 무시하였다. 마치 초기의 CGI 프로그래머들이 사용자가 주관하는 환경 변수에 "Mozilla"를 점검하였고, 결과적으로 오늘날에도 여전히 준수하고 있는 우스꽝스러운 관례가 만들어졌듯이 말이다. 실제적으로 모든 주요 브라우저들은 제일 먼저 자신을 "Mozilla"로 선언하고, 두 번째로 "(compatible; BrowserName)"으로 선언하였다. 간단히 말해, 자바스크립트는 플랫폼 독립적이면서 표준 주도형 웹으로 가는 길목을 가로막는 또다른 장애물이 되어 버렸기 때문에 전적으로 좋은 평판을 얻지는 못했다.
ECMAScript: 표준화의 시도
인터넷 익스플로러 3이 도입되면서 document.images 배열이 지원되지 않았기 때문에 넷스케이프와 썬은 그 언어를 ECMA(European Computer Manufacturers Association)의 도움을 받아 표준화하였다. 그 결과 그 언어에는 ECMAScript라는 또다른 이름이 주어졌다. ECMAScript는 강력하고 보편적으로 지원되는 코어 기능과 비호환 객체 모델과의 기묘한 혼합물이 되었다. ECMA와 공동으로 1996년 11월에 표준화가 시작되어서 1997년 6월에 ECMA가 채택하였고 ISO는 1998년 4월에 채택하였다.
그 동안 ECMAScript가 표준화되면서 (그러나 안타깝게도 코어만 빼고는 거의 모든 것을 무시) 넷스케이프와 마이크로소프트는 각각 4.0 브라우저를 만들어 냈다. 그리고 각 브라우저는 완전히 독자적인 문서 객체 모델을 가졌으며 "Dynamic HTML"이 그 다음 골치거리가 되어 자바스크립트의 선의가 심한 열병을 앓았다.
기능의 분열(Fiefdoms)
크로스-브라우저 DHTML 애플리케이션을 필수적으로 지원하기 위해서는 수 많은 자질구레한 작업과 여러 구현이 필요하다. 어떤 사람들은 네비게이터가 익스플로러처럼 동작하도록 해주는 라이브러리를 제공하기도 했다. 반대로 어떤 사람들은 익스플로러가 네비게이터처럼 작동하도록 해주는 라이브러리를 제공하기도 했다. 프로그래머들이 비호환 코드를 일관성 있는 API로 싸 넣도록 도움을 줄 라이브러리를 모든 사람들이 제공했지만, 사람들은 최소한의 공통 분모조차도 거의 모든 어플리케이션에 대하여 너무 느렸다는 것을 곧 깨닫게 되었다. 그 결과 많은 사람들은 네비게이터 대신 윈도우 익스플로러를 더 많이 사용하게 되었고 웹은 더욱 분열되어 작은 영역으로 기능이 제한되어 버렸다.
브라우저 전쟁이 격렬하게 진행되는 동안, 마이크로소프트와 넷스케이프, 그리고 수십 개의 다른 회사들은 W3C와 협력하여 보편적인 DOM(Document Object Model)을 위한 작업토대를 (W3C DOM의 틀구성자(framers)들에 의해 "Level 0"으로 지칭되는) 최초의 브라우저 객체 모델과 하위 호환성을 유지하면서 쌓으려고 하였다. 과거의 연속선상에서 SGML-계승 플랫폼으로 유지하고자 하는 욕구 때문에 웹은 상대적으로 간단하고 강력한 XML의 지원을 받아 또다른 추상화 층을 도입하였으며, 결론적으로 몇 년 동안 비호환적인 구현 또는 부분적인 구현이라는 결과에 이르렀다.
오픈 소스 모질라(Mozilla) 프로젝트는 수년간을 소비하면서도 공개적으로 안정적인 배포나 광범위한 배포가 이루어지지 않았다. 반면에 마이크로소프트는 브라우저 시장의 점유율을 바짝 졸라 매었다. DHTML 프로그래머들은 크로스-브라우저 DHTML의 복잡성, 표준 지원에 대한 새삼스러운 강조, 플래시(Flash)와 같은 상호작용적 컨텐츠(content)를 제공하는 다른 도구들의 출현들 때문에 상당부분 움츠러들었다.
자바스크립트는 오늘 우리를 떠나 어디로 가는가?
2001년 자바스크립트가 상황-종속적 모듈에 의존하는 것은 한편으로는 강력한 힘의 원천이기도 하며 다른 한편으로 구현에 있어서는 치명적인 약점이기도 하다. 펄이나 자바 또는 다른 언어들과는 달리, 자바스크립트(JavaScript)의 능력은 개발자에 의해서 확대되거나 오버라이드될 수 없다. 대신에 개발자들은 전적으로 브라우저 벤더들의 결정에 의존한다. 자바스크립트는 아주 유연하게 많은 약점들을 극복할 수 있지만 기초적인 상황에-얽매인(context-enslaved) 객체 모델의 비호환성은 극복할 수 없다.
또한 소스를 감추는 능력을 갖추지 못한 것도 애플리케이션 개발의 장애가 되고 있다. 코드의 주인은 자신의 지적 재산권을 보호하기를 원하기 때문이다. 통합개발환경(IDE), 디버거, 그리고 다른 표준 개발 도구의 계속된 부재도 프로그래머들이 여전히 간과할 수 없는 문제들이다. 프로그래머들은 디버거가 없는 플랫폼에서 디버깅하는 것이 너무 어렵다는 그럴듯한 구실로 윈도우 전용 애플리케이션을 옹호한다. WYSIWYG 도구 벤더(vendors)들은 탁월한 크로스-브라우저 자바스크립트 라이브러리를 그들의 페이지 구축 도구 안으로 통합해 넣는데 성공했으며, 오직 구형 넷스케이프의 document.layers 객체 모델을 모질라가 포기한 것만 제외되었을 뿐이다.
그럼에도 불구하고 자바스크립트는 진화를 거듭해 (연관 배열(associative arrays), 느슨하게 형 정의되는 변수(loosely typed variables), 정규 표현식(regular expressions)이라는) 펄의 가장 뛰어난 특징들과, (산뜻하게 블록단위로-해석되는 구문, 객체 그리고 클래스, 고도로 진화된 date, math, 그리고 string 라이브러리라는) C/C++과 Java의 탁월한 특징들, 그리고 (광범위하게 이식된 어플리케이션 제어 환경이라는) TCL의 장점들을 최신의 브라우저(Mozilla, Netscape 6, IE6/Windows 그리고 IE5/Mac)에 구비된 W3C DOM에 놀라울 정도로 강력하게 결합하였다.
Blox, KnowNow, 기타 등등과 같은 회사들은 클라이언트측 자바스크립트를 사용하면서 동시에 지능적인 서버측 도구를 함께 사용하여 차세대 웹기반 애플리케이션을 생산하고 있다. 심지어 마이크로소프트조차도 C#을 떠들석하게 선전하는 것을 보면 자바스크립트의 파워를 인식한 듯이 보인다. MSDN 샘플 또는 한번쓰고-버릴 스크립트 또는 기타 등등… 아무거나 하나를 꺼내 보면 최소한 부분적으로라도 자바스크립트로 작성되어 있는 것을 볼 수 있다.
자바는 썬과 여러 세력 사이의 널리 공개된 내부 반목과 싸움의 틈바구니에서 고난을 겪어 왔다. VBScript는 마이크로소프트에 의해서 거의 포기된 상태이지만, 그렇다고 해서 컴파일러인 C#이 언제나-필요한 스크립트 언어의 임무를 채워줄 수는 없다. 자바스크립트(JavaScript)는 웹을 정복하였다. 이제 자바스크립트에 대해서 더 자세히 알아보는 것은 어떤가? 무엇을 알아야 하는가? 오랫동안 무시를 받아온 이 원숙한 초강력 언어에 어떻게 접근해야 하는가? 이러한 문제들에 접근해 볼 가치는 충분하다.
스티브 참피언(Steve Champeon)은 웹 전문 개발자, 작가, 편집자이다. NC, 랄레이(Raleigh)에 있는 웹 서비스 회사 hesketh.com의 CTO로 근무하고 있다.
TAG :
이전 글 : CSS와 JavaScript로 테마만들기
다음 글 : 위키 파이썬 (Wiki Python)
최신 콘텐츠