지난 1995년 넷스케이프(Netscape)가 자사의 브라우저 임베디드형 스크립트(Script) 언어의 새로운 브랜드를 찾고 있을 때 업체는 썬마이크로시스템즈로부터 '자바'(Java)에서 변형된 이름에 대한 라이선스를 취득했다. 이렇게 자바스크립트(JavaScript)라는 이름이 생겨나면서 (자바스크립트와 자바의 가까운 관계로 인해) 오해가 생기게 됐고 일부 개발자들은 여전히 혼란스러워하고 있다. 이제 이런 식의 브랜드명 공유 사례는 다시는 나타나지 않을 것이다. 썬을 인수한 오라클 경영진 역시 마찬가지다.
시간이 지나면서 브라우저 내 자바 사용은 시들해졌고 구글이 안드로이드로 클라이언트용 자바를 구제하지 않았다면 모바일 기기에서 조차도 그 자리를 잃었을 것이다. 자바미(JavaME)는 기술적인 대참사, 부정한 마케팅, 미심쩍은 가치 제안 등 문제투성이였다. 거기에 또 무엇이 있을까. 한편 호환성 문제를 일으키려는 마이크로소프트(MS)의 엄청난 노력에도 불구하고 자바스크립트는 애플리케이션 개발자들과 플랫폼 개발자들이 선호하는 크로스 플랫폼 언어가 되었다.
자바스크립트, 서버를 점령하다
본래 클라이언트사이드(client-side, 서버가 아닌 클라이언트에서 실행되는) 언어인 자바스크립트는 서버 부문으로 빠르게 진격해 나갔다. MS는 1996년 액티브 서버 페이지스(Active Server Pages)를 통해 자사의 J스크립트 아류를 제시했다. 약 10년 전, 필자는 XML 개발 단계에 따라 코쿤(Cocoom)이라는 이름의 아파치(Apache) 프로젝트를 수행했었다. 해당 프로젝트의 책임자이자 필자의 멘토였던 스테파노 마조치는 자바스크립트를 일종의 제어 언어로 코쿤에 포함시키려 시도했다. 필자는 그가 제정신이 아니라고 생각했지만 결국 XML 기반의 동적 웹 사이트를 개발하는 것보다 더 좋은 아이디어였던 것으로 드러났다.
그렇게 탄생한 리노(Rhino)는 자바 가상머신을 위한 최초의 내장형 스크립트 언어였다. 본래 넷스케이프가 포기한 브라우저를 자바로 재개발하기 위한 것이었지만 대부분 서버사이드 용도로 사용되었다. 이런 추세는 클라우드 전반에 걸쳐 애플리케이션 개발언어로 Node.js가 적용되는 오늘날까지 이어지고 있다.
모바일부터 데이터베이스까지 자바스크립트 '전성시대'
자바스크립트는 오랫동안 거대한 골칫거리로 조롱을 당했다. 이런 이미지는 대부분 호환성이 떨어지는 형편없는 브라우저 때문에 발생한 것이다. 그렇다. 문제는 MS다. 인터넷 익스플로러(IE)는 여전히 엉망진창이다. 그럼에도 불구하고 MS에 감사하고 싶다. 왜냐하면 IE의 문제들 때문에 '상당수의' 현대적인 웹 사이트가 자바스크립트 기반의 AJAX로 개발될 수 있었기 때문이다.
자바스크립트 라이브러리인 '제이쿼리'(JQuery)는 플래시, 클라이언트사이드 자바는 물론 브라우저에 임베드디하려는 대부분의 기술들을 집어삼키는 괴물이 됐다. 앱셀러레이터(Appcelerator), 폰갭(PhoneGap), 그리고 이와 유사한 프레임워크들도 자바스크립트 프로그래밍의 한 요소가 되는 크로스 플랫폼 모바일 개발을 지원한다. 오직 망상에 사로잡힌 애플의 추종자들 만이 80년대에나 유행했던 오브젝트-C(Objective-C)를 부여잡고 화려했던 시절을 추억하고 있다.
어도비는 ECMA스크립트(ECMAScript)라고 불리는 표준화된 자바스트립트 버전을 기반으로 액션스크립트(ActionScript)를 내놓았다. 자바스크립트 없이도 괜찮은 개발 툴을 만들 수 있게 된 것이다. 그러나 안타깝게도 어도비는 이 ECMA스크립트를 불운한 개발툴 '플렉스(Flex)', 이상한 플랫폼 '플래시'와 통합해 버렸다. 문자 그대로 자바스크립트의 표기법인 JSON(JavaScript Object Notation)은 개발 언어 독립적인 데이터 형식으로서 데이터 전송용 XML을 대체하고 있다. 심지어 SOAP/웹서비스 업체들은 JSON을 더 지원하는 경향이 있다. 브라우저는 물론 다른 클라이언트에서도 화면을 보여주는 것이 더 빠르고 쉽기 때문이다. 게다가 SOAP의 헤더(Header)를 읽고 싶어하는 사람이나 있을까.
한편 NoSQL의 대히트로 오라클 주식에 대한 투자가치가 떨어졌고 동시에 문서 데이터베이스가 성장했다. 몽고DB(MongoDB)와 코치베이스 2.0(Couchbase 2.0) 등 대부분의 문서 데이터베이스는 주요 데이터베이스 포맷으로 무엇을 사용할까. 당연히 JSON이다!
부전승의 주인공은 누구?
결국 이 모든 것을 종합해 보면 우리는 웹 또는 모바일 애플리케이션을 개발할 때 자바스크립트 이외에 다른 언어가 전혀 필요없다. 자바스크립트에서 제이쿼리 라이브러리(물론, HTML 마크업를 사용해)를 이용해 클라이언트를 개발하고 JSON으로 서버와 주고 받고 몽고DB 문서 데이터베이스에서 데이터를 JSON으로 저장하고 쿼리 처리할 수 있으며 이 모든 것을 클라우드를 통해 서비스할 수 있다. 경영 입장에서 보면 이것은 자바, 루비, 닷넷 개발자들보다 저렴한 일련의 개발자를 채용해 활용할 수 있다는 의미이다.
이런 접근 방식에 허점은 없을까. 물론 있다. 자바스크립트 기반의 프레임워크인 Node.js가 대표적이다. Node.js는 아직 다듬어지지 않았다. 이것은 프로세스당 단일 쓰레드(Thread)즉 단일 프로세서 코어를 사용하고 별도로 복수의 프로세스를 할당할 수 있는 옵션을 지원한다. 그러나 수직으로 확장되지 않기 때문에 더 큰 장비를 구입해도 성능이 크게 향상되지 않을 수 있는 한계가 있다. (단, 더 많은 인스턴스를 간단하게 추가 할당할 수 있는 클라우드 환경에서는 이런 문제가 중요하지 않을 수 있다)
결국 자바스크립트는 만능이 아니다. 상황에 따라 무엇이 적절한 지 스스로 판단해야 한다. 필자는 관리자로서 제이쿼리, Node.js를 다룰 수 있고 몽고DB에서 가벼운 데이터베이스 작업을 처리할 수 있는 개발자를 선호한다. 그러나 개발자 입장에서는 IE에 대한 안 좋은 기억 때문에 자바스크립트를 이용한 개발을 꺼리는 것도 사실이다. 특히 프로젝트 리더로서 많은 자바스크립트 개발자들뿐만 아니라 귀중한 데이터베이스를 위해서라도 꺼려지는 것도 사실이다.
필자는 현재 어도비가 포기한 플랙스 플랫폼용 액션스크립트에 충분한 시간을 투자하면서 그 효용성을 확인하고 있다. 문서 데이터베이스에서 자바스크립트로 개발한 경험이 큰 도움이 되고 있다. 하지만 자바스크립트와 같은 골치덩어리를 프런트 엔드(Front End)부터 채택해 이를 중간계층까지 사용하는 것이 가능할까. 필자는 여전히 고민중이다. editor@idg.co.kr
Read more: http://www.itworld.co.kr/news/78199#csidx772b0cfdad63310b119fa301b604e98 
Copyright © LinkBack