그 동안 몰랐던 서버 사이드 자바스크립트 이야기, Part 1: 다시 보는 자바스크립트의 역사

김영후 zerohoo.kim@gmail.com 웹 개발 기술과 매킨토시에 관심이 많은 스물여섯 살 개발자다. 능력과 시간을 전부 창조하는 작업에만 쓸 수 없을까 궁리 중이며 현재 병역 특례 업체에서 플렉스를 주로 다루고 있다. 난이도 : 중급 2008년 9월 16일

연재순서
1회(2008년9월): 다시 보는 자바스크립트의 역사

[오픈 developerWorks]는 여러분이 직접 필자로 참가하는 코너입니다.

우리는 자바스크립트 언어를 웹 브라우저에서만이 아니라 다양한 환경과 다양한 목적으로 사용할 수 있다. 서버 사이드 자바스크립트 기술을 이용하면 웹 프로그래밍부터(클라이언트에서의 웹 프로그래밍이 아닌 URL을 해석하고, GET과 POST를 처리하고, DB와 연동하는 서버 사이드의 웹을 말한다.) 간단한 유틸리티 프로그램이나 주기적으로 정보를 수집하는 멀티 스레드 프로그래밍도 가능하다.

서버 사이드 자바스크립트 기술을 이용하기 전에 한 가지 근본적인 질문이 필요하다. 왜 이러한 일반적인 목적으로도 자바스크립트를 써야 하는가? 자바스크립트의 첫 번째 비극은 그것이 적어도 웹 브라우저 안에선 대체 불가능하다는 것이다. 많은 프로그래머들이 원하든 원치 않든 적어도 한번 이상은 자바스크립트를 경험하게 되고, 웹 브라우저 안에선 '파이썬이 좋나요, 루비가 좋나요'와 같은 선택권이 존재하지 않는다. 이러한 유일성은 자바스크립트를 탐탁치 않은 마음으로 받아들이게 되는 원인 중 하나다.

그런데 이 언어가 사실 정말로 강력하다면? 웹을 벗어나 여러 언어를 선택할 수 있는 상황에서도 굳이 사용하고 싶을 정도의 가치가 있는 언어라면 어떻게 할 것인가? 사실 어떠한 목적으로 특정한 언어를 선택하는 데에는 별다른 이유가 없다. 누군가 특정 언어를 사용하도록 시키지 않았다면 그 언어를 정말로 좋아하기 때문이다. 그리고 자바스크립트는 비록 결함이 많더라도 우리가 충분히 좋아할 수 있을 만한 언어다.

그렇기 때문에 이 글의 본래 목적인 리노(Rhino)와 헬마(Helma) 같은 서버 사이드 자바스크립트 기술을 본격적으로 소개하기 전에 자바스크립트의 역사를 살펴보는 일이 필요할 것 같다. 이 역사를 통해 왜 자바스크립트가 많은 개발자들에게 '장난감 언어'라는 오해를 사고 있는지, 언어 창조자의 본래 목적과 설계 시 실수들 그리고 여전히 남아있는 좋은 개념은 무엇인지, 어떠한 점들을 우리가 좋아하고 이 언어를 사용하도록 강제 받지 않더라도 즐겁게 사용할 수 있는지 알아보자.

위로

자바스크립트의 역사

컴퓨터 세계에서 소프트웨어 산업과 프로그래밍 언어의 역사를 살펴보면 '첨단 산업'과 '전문가'라는 낱말들이 얼마나 무색하게 들리는지 알게 된다. 사람들은 끊임 없이 실수를 저지르며 그 실수에서 생기는 우연한 요소들이 수혜자와 희생자를 결정한다. 좋고 뛰어난 것을 만들어 놓고도 그것을 이해하지 못하는 사람들이 '더 안 좋은 작업들'을 계속 반복하기도 하며 작은 문제를 해결하기 위한 기술들이 거시적으로 더 큰 문제가 되는 일도 자주 생긴다. 넷스케이프에서 시작된 자바스크립트의 역사는 그 자체로 이러한 우연과 오해, 무지의 역사이며 컴퓨터 산업의 우스꽝스러움을 잘 보여주는 이야기이기도하다. 우리는 여전히 과거의 뛰어난 창조물들을 잘 이해하지 못하고 있다.

1995년 4월 브랜든 에이크(Brendan Eich)는 웹 브라우저에 내장되는 스킴(Scheme) 언어를 만들기 위해 넷스케이프에 입사한다. 당시 넷스케이프에선 웹 브라우저에 내장되는 언어의 필요성을 인식하고 있었으나 그 내막엔 미묘한 이견이 있었다. 이제 막 오크(Oak)에서 이름을 바꾼 자바(Java)가 본격적인 '인터넷 언어'로 브랜딩을 하고 있었고 넷스케이프에선 이 언어를 브라우저에 내장하기 위해 썬 사와 협상을 벌이는 중이었다(실제로 1995년 10월에 나온 넷스케이프 2.01B 버전은 자바를 탑재했다). 자바가 브라우저를 위한 인터넷 언어로 탑재되는 것이 가시화하자 넷스케이프 내부에서는 '브라우저에 또 하나의 언어가 필요한가'라는 논쟁이 자연스럽게 벌어졌다.

넷스케이프에선 두 종류의 언어가 필요하다는 결론을 내렸다. 하나는 진지하고 전문적인 프로그래머들을 위한 복잡한 언어, 즉 자바이고, 다른 하나는 아마추어나 디자이너를 위한 '스크립트' 언어였다. HTML 안에 포함되어 동작하며 쉽고 가벼운 언어가 필요하다는 후자의 생각은 마크 앤드리슨, 빌 조이와 같은 IT 업계 거장들도 동의하는 사실이었고 이는 에이크가 만들 언어가 복잡한 괄호들로 가득 찬 신비로운 스킴이 아니라 '자바나 C 같이 보이는' 그리고 '쉬워 보이는' 언어여야 한다는 사실을 의미했다.

자바스크립트의 이러한 태생적 요구와 상황은 매우 독특한 것이다. 프로그래밍 언어는 대부분 아마추어나 디자이너를 위해 만들어지지 않았고 그러한 사실을 스스로 홍보하는 일도 드물다(어도비에서 액션스크립트(ActionScript)가 진정한 프로그래머를 위한 진짜 언어라는 사실을 얼마나 강조하는가). 또한 이 언어가 다른 언어처럼 '보여야' 한다는 어리석은 제약이 존재했고 언어의 창시자는 고대의 마법과 같은 기술 - 스킴 - 을 구현하겠다는 희망을 품고 있었다. 이렇게 복잡한 서로 다른 동기와 목적은 어느 언어와도 다른 자바스크립트의 여러 특징을 만드는 바탕이 된다.

에이크는 요구대로 스킴이 아닌 '자바처럼 보이는' 스크립트 언어를 만든다. 하지만 그는 열흘 만에 기본 객체(built-in)들이 포함된 인터프리터를 만들면서도 자신의 본래 목적인 스킴의 함수형 언어적인 특성들을 최대한 모방해 자바스크립트를 높은 수준의 함수형 언어로 만들었다. 실제로 자바스크립트는 함수형 스타일의 좋은 교과서라 할 수 있는 SICP의 여러 예제를 거의 스킴과 같은 수준으로 따라할 수 있다. 단지 C 언어처럼 보일 뿐이며, 스킴과 다르게 꼬리 재귀(tail recursion)를 지원하지 않는다.

에이크는 자바스크립트를 객체지향 언어로 설계하는 데 있어 스킴이나 자바가 아닌 또 다른 언어를 모방하는데 그것은 1986년 소개된 셀프(Self)다. 자바스크립트는 셀프의 가장 큰 특징인 '클래스란 개념이 존재하지 않는' 프로토타입 기반 객체지향을 가져 왔으며 이는 함수형 스타일과 함께 자바스크립트의 높은 유연성을 말해주는 특징이 되지만 동시에 자바와 같은 클래스 기반 객체지향에 익숙해진 개발자들에 의해 '클래스도 없는 장난감 언어'로 오해를 받는 원인이 된다.

스킴의 함수적 스타일과 셀프의 객체지향적 특징은 자바스크립트의 핵심적인 두 '개념'이 되지만 동시에 '자바 같이' 그리고 '쉬워 보여야 하는' 제약은 언어의 외형적인 특징에 큰 영향을 끼친다. 자바스크립트의 외형은 명백하게 자바와 같은 C 언어 계열로 설계되었으며 동시에 함수형 언어의 원천 기술들과 프로토타입 기반 객체지향에 대한 이해가 전혀 없이도 쓸 만한 프로그램을 만들 수 있게 하였다. 이는 언어의 요구에 부합하는 합당한 일이었지만 심각한 개발자들이 자바스크립트를 '장난감 언어'로 인식하는 원인이 된다. 실제로 자바와 비슷해 보이는 특징은 자바스크립트가 뭔가 새로운 것을 배울 만한 언어라기보단 '내가 아는 언어의 유치한 수준'이라고 생각하도록 만들게 되었으며 함수형 스타일을 잘 살려 만든 수준 높은 코드들도 자바스크립트에선 약간 너저분(verbose)해 보이는 면이 있다.

넷스케이프와 썬의 깊은 관계는 자바스크립트가 자바의 언어적 특성을 외형 이상으로 많이 모방하도록 하였다. 근본 개념부터 큰 차이를 보이는 자바에 대한 베끼기는 결과적으로 대부분 자바스크립트의 결함이 된다. 자바스크립트는 자바와 같이 언어의 원시(primitive) 타입을 객체 타입과 분리했으며(실제로 두 언어 모두 '모두는 아니지만 대부분은 객체인' 언어다) 식(expression)과 절(statement)이 구분되어 있다. 이는 명백하게 좋지 않은 선택이다. Y2K 버그가 있던 자바의 Date 객체를 포팅하면서 버그도 같이 가져 왔으며 이 버그는 마이크로소프트가 구현한 JScript에도 그대로 포함되었다.

'자바 같이 보여야' 하는 제약은 언어 구현뿐 아니라 코딩 스타일에도 많은 영향을 주었는데 실제로 넷스케이프에서 소개한 자바스크립트 객체지향 코드는 대부분 생성자를 만들어 클래스 기반 언어 같이 객체를 생성하는 방법이었다. 이는 전통적인 객체지향 코드처럼 보이지만 프로토타입적 특징에서 보면 상당히 어색한 스타일이며 생성자를 new 키워드를 이용하여 호출하지 않을 경우 치명적인 버그가 생길 수 있는 스타일이다(그렇기 때문에 생성자 역할을 하는 함수를 대문자로 쓰는 규범(convention)에 의지했다). 이러한 스타일은 지금도 상당히 많은 자바스크립트 소스나 예제에서 찾아 볼 수 있다.

자바로부터 가져온 결함 외에도 전역 변수에 대한 의존, 블록 범위(block scope)를 가지지 못한 점, 실수(floating point) 계산 오류 등 자바스크립트는 명백한 설계 오류나 구현상의 실수를 가지고 있다. 하지만 한 가지 장점은 이 오류들이 비교적 명백하다는 점이다. 자바스크립트의 결함들이 명백해지고 잘 알려지면서 이를 피할 수 있는 여러 기법이나 스타일이 유행했으며 대부분의 자바스크립트 라이브러리는 이러한 결함을 보완하는 역할을 수행한다. 언어의 장단점이 섞여 흐릿하고 논쟁 소지가 많은 언어보다 단점이 분명하다는 것은 그만큼 대처하기가 쉽다는 의미이기도 하다.

현재 야후의 자바스크립트 아키텍트이자 유명한 자바스크립트 전문가 더글라스 크록포드는 2000년에 '자바스크립트: 세상에서 가장 오해가 많은 프로그래밍 언어'란 글을 발표하면서 자바스크립트를 C 언어 형상을 한 리스프로 부르며 언어에 대한 여러 오해를 정리했다. 웹 브라우저만을 위한 언어라는 고정적인 역할, 너무 많은 버전, 설계 오류, 버그가 많고 잘못된 구현들, 안 좋은 책들, 불충분한 표준, 언어에 대한 이해 없이 뛰어든 초보 개발자들, 프로토타입 객체 지향에 대한 몰이해 등이었다.

실제로 초창기 자바스크립트 언어 엔진 구현과 호환성 문제는 굉장히 심각한 것이었다. 마이크로소프트는 웹 브라우저 시장에 뛰어들면서 넷스케이프에 대한 역 공학(reverse engineering)을 통해 자바스크립트 엔진을 만들어 냈으며 저작권 문제를 피하기 위해 JScript란 이름을 붙인다. 즉 둘은 같은 언어의 다른 구현이다. 이때부터 자바스크립트는 두 브라우저 간 전쟁의 주 도구가 되어 상호 간 협의 없는 잦은 기능 추가와 필연적으로 찾아오는 버그 때문에 끔찍한 비호환성 문제가 야기된다. 결국 마이크로소프트의 승리로 끝난 웹 브라우저 전쟁은 호환성 문제를 유발했지만 동시에 비교적 견고하고 성능이 우수한 자바스크립트 엔진을 남기게 되었다. 이러한 유산은 웹 브라우저가 뒤이어 찾아올 웹 2.0 시대의 기반 플랫폼 역할을 수행하는 결과로 이어진다. 더글라스 크록포드의 글은 Ajax를 통해 자바스크립트의 가치가 새롭게 조명받기 전의 선구자적이자 뛰어난 통찰력이 담긴 것이었으나 수 년에 걸친 오해를 불식시키진 못하였다.

이후의 역사는 많은 개발자들이 목격한 그대로다. 마이크로소프트의 오피스팀에 의해 알게 모르게 인터넷 익스플로러에 추가된 XMLHttpRequest란 객체를 아주 적절한 용도로 이용한 구글과 몇몇 선도 업체에 의해 Ajax란 기술이 탄생했고 자바스크립트는 새로운 기회와 명성을 얻었다. 웹의 지배는 서버 사이드에서 실행되는 언어에 대한 제약을 사실상 제거해 버렸고 개발자들은 루비나 파이썬, 펄 같은 자신들이 좋아하는 스크립트 언어를 웹 개발에 이용할 수 있었다. 자바스크립트에 대한 재평가는 이러한 개발자들의 변화에 기여된 측면이 크다. 개발자들은 이제 클로저와 일차-함수(first-class function)의 의미와 유용성을 깨달았고 자신들이 사랑하는 언어에 못지 않게 자바스크립트가 이러한 것들을 잘 지원한다는 사실을 알게 되었다. 기존 주류 언어와 주류화되어 가는 스크립트 언어에서도 찾아 볼 수 없었던 객체 리터럴이나 프로토타입을 이용한 편의성과 확장성은 지금도 전파중이다. 지금 자바스크립트는 자바스크립트2라는 새로운 변화를 앞두고 있다.

위로

자바스크립트의 간결성

자바스크립트의 강력한 언어적 특징과 기능을 기사 하나로 전부 소개하기는 힘들다. 그것들을 배우고 익히는 것은 독자들의 몫일 것이다. 좋은 참고가 될 만한 책으로는 최근에 출판된 더글라스 크록포드의 『자바스크립트: 좋은 면(Javascript: The Good Parts)』을 추천한다. 이 책은 언어의 모든 면을 설명하려고 노력하지 않고 계속 배우고 익혀 써야 할 좋은 부분에 대한 설명을 담았다. 자바스크립트엔 다양한 강점이 있지만 이것들은 대부분 간결성(succinctness)이라는 성과를 내기 위한 것으로 볼 수 있다.

리스프 언어와 컴퓨터 세계에 대한 통찰력 있는 글로 유명한 폴 그레이엄(Paul Graham)은 프로그래밍 언어의 강력함을 나타낼 수 있는 가장 큰 특징으로 언어의 간결성을 꼽았다(참고 1: Revenge of the Nerds, 2: Succinctness is Power) 여기서 간결성이란 복잡한 식(expression)을 얼마나 간결하게 표현할 수 있느냐를 의미한다. 폴 그레이엄은 이를 테스트하기 위해 간단한 예로 '누산 기능이 있는 함수를 만드는 함수'를 들었다. 폴 그레이엄이 가장 간결하다고 말하는 리스프는 다음과 같다.

이 함수의 자바스크립트 버전은 다음과 같다(이 예는 폴 그레이엄이 직접 만든 것이다).

리스프와 크게 다르지 않은 이 코드는 자바스크립트의 간결성과 결함을 잘 보여준다. 모두 함수 안에서 새로운 함수를 만들어 결과로 돌려주는 간결한 코드를 쉽게 작성할 수 있다. 또한 렉시컬 클로저를 지원하므로 새로운 함수에선 선언될 당시의 함수 밖 변수 값을 보존하여 누산 값으로 이용할 수 있다. 하지만 C 언어의 중괄호는 함수형 스타일에서는 약간 너저분해 보이며 리스프의 lamdba와 같이 익명 함수(anonymous function)에 대한 단축 용어를 제공하지 않아 몇 글자가 더 길다. 그리고 자바스크립트는 식과 절이 분리되어 있어 값을 돌려 준다는 return 키워드가 필요하다. 하지만 의미적으로 두 코드는 거의 같다고 볼 수 있을 정도로 뛰어난 리스프의 함수형 스타일을 그대로 모방할 수 있다. 자바스크립트는 파이썬이나 루비 못지 않게, 어떠한 면에선 조금 더, 간결한 언어다.

자바스크립트는 분명 여러 가지 명백한 결함이 있다. 하지만 자바스크립트의 뛰어난 확장성은 언어 자체에 대한 패치 없이도 이러한 결함을 보정할 수 있을 정도로 충분히 강력하다. Prototype이나 jQuery 같은 자바스크립트 라이브러리의 면면을 살펴보면 이것들이 언어를 어떻게 보완하며 확장하는지 볼 수 있다. Prototype은 클래스와 상속을 라이브러리에서 제공하고 Object 객체에 복제(clone) 함수를 구현하여 모든 자바스크립트 객체에 복제 기능을 추가했다. Prototype의 Try.these 메서드는 다수의 함수 호출에서 제대로 동작하는 것이 있을 때 그 결과를 돌려주는 기능을 수행한다. 이 메서드는 다음과 같이 XMLHttpRequest 객체를 얻어오는 데 사용될 수 있다(참고: Try.these는 수행되는 함수에서 제대로 동작하는 것이 있을 때를 의미하지, '참'인 것을 의미하지 않는다. 즉 단축 평가(short-circuit)를 이용한 조건문으로 단순하게 치환하기 어렵다).

Try.these를 사용하지 않으면 현재 브라우저의 종류를 알아내고 다수의 조건문이 필요로 할 것이다. 이 Try.these의 구현은 다음과 같다.

이 Try.these는 하나의 객체와 객체의 프로퍼티 함수를 통해 구현되지만 마치 자바스크립트 언어의 일부인 것 처럼 사용된다. 사실 많은 자바스크립트 개발자들이 'jQuery 대 Prototype' 같은 라이브러리 논쟁에 깊게 뛰어드는 것도 이 때문이다. 이러한 라이브러리에서 제공하는 상당수의 기능은 언어를 확장하고 수정해 언어 자체를 변화시키거나 언어의 스타일을 규정할 수 있는 것이다.

위로

가장 널리 퍼진 리스프

파이썬이나 루비 같이 동적 언어를 선호하는 개발자 커뮤니티에서 활동하다 보면 '이 언어가 얼마나 좋은데 왜 안 퍼지는지, 왜 안 쓰는지 모르겠어요'와 같은 하소연(?)을 종종 볼 수 있다. 하지만 우리는 10년 동안 리스프의 강력함에 버금가는 언어를 매일 실행하는 프로그램인 웹 브라우저 내에서 가지고 사용하고 있었다. 단지 그 가치를 최근에 와서야 알아가고 있을 뿐이다. 그렇기 때문에 자바스크립트의 확장은 조금 다른 방향으로 진행될 필요가 있다. 우리가 이미 알고 있고 모든 사람의 컴퓨터에 내장된 이 언어가 얼마나 유용한지, 얼마나 잘 쓸 수 있는지를 보여주어야 하는 것이다. jQuery 개발자 존 레식(John Resig)이 Processing.js를 만든 것도 이 때문일 것이다. 웹 브라우저에 내장된 이 언어를 높은 수준의 시각화에도 사용할 수 있음을 보여주는 것이다.

앞으로 서버 사이드 자바스크립트 기술을 살펴보려는 것도 같은 이유다. 웹 브라우저 내에서 매일 동작하는 이 언어의 좋은 점을 잘 다루고 나쁜 점을 잘 파악해 피할 수 있다면 브라우저 밖에서도 이 언어를 사용하는 것이 즐거울 것이다. 원하기만 한다면 다양한 목적으로 이 언어를 사용할 수 있다. 웹 브라우저 밖에서 자바스크립트 언어를 수행하는 기술 중 대표적으로 리노(Rhino)가 있다. JVM 위에서 구현된 견고하고 빠르며 충분한 사용성이 있는 자바스크립트 구현이다. 다음 회에선 이 리노에 대해 자세히 알아보자

mar.gar.in

naver

eolin

del.icio.us

이제 전문가의 글을 단순히 ‘보는 것’에서, 직접 여러분이 developerWorks의 필자가 될 수 있습니다. IBM developerWorks를 통해 공유하고 싶은 지식이 있으신 분들은 원고 기획안을 접수해주세요. 채택되신 분께는 소정의 원고료를 드립니다.

필자 지원하기

[지난 Open dW 보기]