자바 프로그래밍에서 서버측 자바 애플리케이션(독립형 서블릿에서J2EE 전영역에 이르기까지)의 등장은 최근 가장 흥미로운 추세 중 하나임이 분명하다. 자바 언어는 원래 작은 내장형 장치를 위해서 고안되었고, 초기에는 애플릿의 형태로 클라이언트 측 웹 컨텐츠를 개발하는 데 주로 쓰였다. 안타깝게도, 지난 몇 년 전만 해도1 ) 서버 측 개발 플랫폼으로서 자바의 가능성은 아무도 오늘날 정도까지는 내다보지 못했다.
하지만 현재 자바는 서버측 개발에 적합한 이상적인 언어로서 그 자리를 공고히 하고 있으니 조금 아이러니하기는 하다.
특히 비지니스 측면에서 서버 시장을 누비고 다닐 자바의 잠재력(자바는 본질적 으로 큰 규모의 클라이언트/서버 애플리케이션에 적합하다)에 대한 인식은 실로 눈부 시게 변하고 있다. 자바의‘플랫폼간 호환’이라는 타고난 특성은 유닉스나 윈도우와 같은(그리고 최근 MacOS X까지) 다양한 운영체제에서 수행되는 이기종 서버를 운영 하는 기업이나 기관의 입장에서는 특히 유용하다. 자바의 현대적이고, 객체 지향적 이며, 메모리 보호를 철저히 하는 설계는 개발자로 하여금 개발의 사이클을 단축하 고, 신뢰도를 향상시키도록 하였다. 아울러, 네트워킹과 엔터프라이즈API를 내장하
1
소개
•서블릿지원요소
•서블릿의특성
1) 역자주: 1판에는 최근이라고 되어있지만, 이제는 아니다.
여 레거시 데이터(legacy data)에 접근을 제공함으로써 구식 클라이언트/서버 시스 템들의 전이1 )(transition)를 불필요하게 하였다.
자바 서블릿은 서버측 자바 개발의 주요 컴포넌트 중 하나이다. 서블릿은 작고 플러그-인이 가능한 형태로 서버에 추가되면서 서버의 기능성에 일대 혁신을 가져 다 준다. 또한, 자바를 사용할 수 있는 어떠한 종류의 서버(웹 서버, 메일 서버, 응용 서버 혹은 커스텀 서버)에 대해서도 지금까지 예상치 못했던 수준의 이식성, 효율성 및 편의성을 제공하여 서버를 확장하고 사용자화할 수 있도록 해준다. 그러나, 이러 한 서블릿에 대해 좀더 상세히 알아보기에 앞서, 몇 가지 심대한 관점을 먼저 살펴보 도록 하자2 ).
웹 애플리케이션 역사
서블릿은 자바를 사용할 수 있는 서버의 기능을 확장하기 위해 사용할 수 있다는 것이 일종의 대원칙이지만, 오늘날 서블릿은 대부분이CGI 스크립트를 대체할 강력 하고 효과적인 대안으로서 웹 서버를 확장하기 위해 사용된다. 웹 페이지의 동적인 컨텐츠를 생성하거나 혹은 웹 서버의 기능을 확장하기 위해 서블릿을 사용한다는 것 은, 사실상‘웹 애플리케이션(Web Application)’을 만들고 있다는 뜻이 된다. 웹 페 이지는 단순히 정적인 컨텐츠를 표시하고 사용자가 그러한 컨텐츠를 통해서 탐색하 는 것이지만, 웹 애플리케이션은 좀더 대화적 경험(Interactive Experience)을 제공한 다. 웹 애플리케이션은 문서 아카이브에서 키워드 탐색만큼이나 단순할 수도 있고, 전자 상점의 전면(s t o r e f r o n t)과도 같이 복잡할 수도 있다. 웹 애플리케이션은 인터넷 과 회사의 인트라넷 혹은 엑스트라넷에서 그 사용 폭이 점차 넓어지고 있으며, 이들 환경에서 생산성을 향상시키고 기업의 규모에 상관없이 기업의 사업방식을 바꿀 잠 재력이 있다.
서블릿의 원대함을 체감하려면 우선 잠깐 뒤로 물러서서 웹 애플리케이션을 생 성하기 위해 사용하는 몇 가지 다른 방법의 실체를 살펴보는 것이 필수적이다. 이들 의 실체가 파악되는 순간, 서블릿의 강점이 자연스레 드러나기 때문이다.
1) 역자주: 변경이라고쉽게생각해도 되지만, 전이(轉移)란 말이 정확하기는 하다.
2) 역자주: 어려워 할 것없다. 역사는 어디서도 필요한 것이다. 심지어 자바같은기술분야에서도.
C G I
일반적으로 CGI라고 불리는데, 동적 컨텐츠를 생성하기 위한 실질적인 기술의 제 1세대였다. CGI를 이용해서 웹 서버는 임의의 요청을 외부 프로그램에 전달할 수 있는 반면, 외부 프로그램의 수행결과는 정적인 파일의 형태로 클라이언트에 전 송된다. CGI의 도래는 웹 페이지에 모든 종류의 새로운 기능을 구현할 수 있는 가능 성을 열어둠으로써, CGI는 수많은 웹사이트에서 구현되는 사실상 업계 표준적인 기 술이 되었다.
CGI 프로그램이 동적인 웹 페이지를 생성할 수 있는 능력이 그 본래 의도(정보 서버와 외부 애플리케이션간의 대화를 위한 표준적인 메소드의 정의)의 부수적인 효과 라는 것은 흥미로운 일이다. CGI의 원론적인 정의는 왜 CGI가 최악의 라이프사이클 을 갖는지에 대한 이유를 극명하게 밝혀준다. 서버가CGI 프로그램의 접속을 위한 요청을 받으면, 서버는CGI 프로그램의 수행을 위해서 새로운 프로세스를 생성해야 하고, 응답의 생성을 위해서 필요한 모든 정보들을 환경 변수들과 표준 입력을 통해 서 외부 프로그램에 전송해야 한다. 매 요청마다 프로세스를 생성하는 것은 시간과 막대한 서버의 리소스를 요구함으로써, 서버가 동시에 다룰 수 있는 요청의 갯수를 제한하게 한다. [그림1-1]은 CGI의 라이프사이클을 보이고 있다.
비록 CGI 프로그램이 대부분의 프로그래밍 언어로 작성될 수 있지만, 이 중에서 펄(Perl) 프로그래밍 언어가 가장 많이 사용되고 있다. 펄이 갖는 우수한 텍스트 처 리 능력은 CGI 인터페이스의 상세한 부분들을 관리하는 데 많은 도움을 제공한다.
[그림1-1] CGI 라이프사이클
CGI 1에 대한 요청 CGI 1에 대한 자식 프로세스
CGI 1에 대한 자식 프로세스 CGI 2에 대한 자식 프로세스 기반 웹 서버
메인 프로세스
CGI 2에 대한 요청 CGI 1에 대한 요청
펄로써 CGI 스크립트를 작성하는 것은 플랫폼 독립적인 모습을 제공하나, 이 또한 각각의 요청에 대해서 독립적인 펄 해석기의 동작을 요구함으로써, 그렇지 않아도 CGI 자체가 상당한 부담으로 작용하는 가운데 심지어 더 많은 시간과 여분의 자원 을 펄이 필요로 하게 된다.
CGI에서 종종 간과하는 또 다른 문제는 CGI 프로그램이 일단 수행을 시작하게 되면, 독립적인 프로세스로 동작함으로써 웹 서버와 대화적으로 동작하거나 서버의 능력을 이용할 수 없다는 점이다. 예를 들어, CGI 스크립트는 서버의 로그 파일에 출력할 수 없다. 더 자세한 정보는 샤인셔 군다바람의『CGI Programming on the
World Wide Web』(오라일리, 1996)을 보라.
F a s t C G I
이렇게 CGI의 문제점이 점차 불거져 나오자 오픈 마켓(Open Market)이라는 회 사가 표준적인 CGI의 대안으로 FastCGI를 개발하였다. 여러 가지 점에서 FastCGI 는 CGI와 동일하게 동작한다. 주요 차이점은 [그림 1-2]에서 알 수 있듯이 FastCGI 는 각각의 FastCGI 프로그램에 대해서 하나의 지속적인 프로세스를 생성함으로써, 각각의 요청에 대해서 새로운 프로세스를 생성할 필요를 제거해 준다.
FastCGI가 올바른 방향으로 가고 있지만, 이 또한 프로세스가 많이 생성되는 문 제(최소한 각각의 FastCGI 프로그램에 대해서 하나의 프로세스가 생성된다)가 여전히 있다. 만일 FastCGI 프로그램이 동시에 다수의 요청을 처리해야 한다면, 요청당 하
[그림 1-2] FastCGI 라이프사이클 CGI 1에 대한 요청
기반 웹 서버
메인 프로세스
CGI 1에 대한 유일 자식 프로세스
CGI 2에 대한 유일 자식 프로세스 CGI 1에 대한 요청
CGI 2에 대한 요청
나의 프로세스에 대응하는 프로세스의 풀이 필요하다. 각각의 프로세스가 하나의 펄 해석기를 구동시킨다고 생각하면, 이 방법은 생각했던 것만큼 크게 확장할 수 없다 (비록 FastCGI는 다중 서버에 대해 자신의 프로세스를 분산시킬수 있다는 점에서 호평 을 받긴 했지만). FastCGI가 갖는 또 다른 문제점은 서버와 좀더 가까이 상호 작용을 하는 데 FastCGI 프로그램이 아무런 도움이 되지 못한다는 점이다. 마지막으로 주목 할 점은 FastCGI 프로그램은 단지 처음 작성된 언어의 형태로만 이식이 가능하다는 것도 제약아닌 제약이다. FastCGI에 대한 상세한 정보는 http://www.fastcgi. com/
을 참조하기 바란다.
m o d _ p e r l
아파치 웹 서버를 사용한다면, CGI 성능을 향상시키기 위한 다른 옵션으로 m o d _ p e r l을 사용할 수 있다. m o d _ p e r l은 아파치 웹 서버의 실행파일인h t t p d에 펄 해 석기의 복사본을 내장시킨 모듈로서, 아파치 웹 서버 안에서 펄의 기능을 완전히 사용 할 수 있도록 해준다. 작성한CGI 스크립트는서버에 의해 미리 컴파일되고 포크(새로 운 프로세스를 생성하는 작업)없이 실행되므로, 더 빠르고 효과적으로 수행된다.
m o d _ p e r l에 대한 좀더상세한 정보는h t t p : / / p e r l . a p a c h e . o rg /를 참조하기바란다.
기타 솔루션
CGI/Perl은 동적 웹 컨텐츠를 생성하는 데 비교적 플랫폼 독립적인 장점을 제공 하고 있다. 웹 애플리케이션을 생성하기 위한 ASP(Active Server Pages)나 서버측 자 바스크립트(JavaScript)와 같은 잘 알려진 기술은 특정 웹 서버에서만 동작하는 전매 특허격 솔루션이다.
서버 확장 A P I
여러 회사들이 자신의 웹 서버를 위한 독점적인 서버 확장(server extension) API 를 내놓고 있다. 예를 들어, 넷스케이프사는NSAPI(현재 WAI가 되었다)라는 내부 API를 제공하고 있으며, 마이크로소프트사는ISAPI를 제공한다. 이러한 API 중에 하나를 사용해서 서버의 기본 기능들을 확장하거나 변경하는 서버 확장 프로그램을 작성할 수 있다. 이는 일단 외부 CGI 프로그램에 미루어 놓는 작업을 서버가 다룰수
있도록 한다. [그림1-3]은 웹 서버의 메인 프로세스 안에 존재하는 서버 확장을 보 여주고 있다.
서버 고유의 A P I가 링크된 C나 C++ 코드를 사용하므로 서버 확장은 매우 빠르게 수행되며 서버의 리소스를 완전히 사용할 수 있게 된다. 그러나, 서버 확장은 결코 완전한 솔루션은 아니다. 개발과 유지가 어렵다는 점 이외에, 중대한 보안과 신뢰성 에 대한 위험에 노출되어 있다: 서버 확장의 오동작은 서버 전체를 마비시킬 수도 있 다. 그리고, 고유의 서버 확장은 서버 확장의 작성을 위해 사용된 서버 A P I에 당연히 절대적으로 의존하게 되며, 경우에 따라서는 특정 운영 체제에 의존하게 된다.
서버측 자바스크립트
i P l a n e t / N e t s c a p e 역시 서버측 자바스크립트, 혹은 줄여서 S S J S(Server Side JavaScript)라고 불리는 서버측 스크립트를 위한 기술이 있다. ASP와 마찬가지로, SSJS는 동적 웹 페이지를 생성하기 위해 코드의 스니핏(snippets)이 HTML 페이지 안에 내장되는 것을 허용한다. ASP와 다른 점이라고는 SSJS가 스크립팅을 위한 언 어로 자바스크립트를 사용한다는 점이다. SSJS를 사용할 경우, 웹 페이지는 성능 향 상을 위해 전처리(p r e c o m p i l e d)된다. 서버측 자바 스크립트 상세 정보는 h t t p : / / developer.netscape.com/tech/javascript/ssjs/ssjs.html을 참조하기 바란다.
[그림 1-3] 서버 확장라이프사이클
서버 확장 1 서버 확장 1에 대한 요청
서버 확장 2에 대한 요청 서버 확장 1에 대한 요청
메인 프로세스 서버 확장 API를 사용한 웹 서버
서버 확장 2
A S P
마이크로소프트사는 일반적으로ASP(Active Server Pages)라 불리는 동적 웹 컨 텐츠를 생성하는 기술을 개발하였다. 웹 서버의 HTML 페이지는ASP를 이용해서 내 장된 코드(일반적으로VBScript 혹은 JScript)의 스니핏을 포함할 수 있다. 이들 코드 는 클라이언트로 페이지가 전송되기에 앞서, 웹 서버에서 읽히고 수행된다. ASP는 COM 컴포넌트에 많은 부분을 맡기고 동적 컨텐츠의 소소한 부분을 맡도록 최적화 하여 있다.
A S P는 마이크로소프트 인터넷 인포메이션 서버 3 . 0이나 그 이상 버전에서 지원되 며, h t t p : / / w w w . m i c ro s o f t . c o m / i i s에서 구할 수 있다. 다른 웹 서버를 지원하는A S P로 는 C h i l i!S o f t사의 상용제품이 있다. 이 소프트웨어는h t t p : / / w w w . c h i l i s o f t . c o m에서 이용할 수 있다. 하지만 이건 알아두자. 비윈도우 운영체체에서A S P를 돌린다는 것은 바로 윈도우COM 라이브러리 없이 고도의 작업을 수행하게 되는 셈이고 따라서 무리 가 올 수밖에 없다는 것을. ASP 프로그래밍에 대한 상세한 정보는 h t t p : / / w w w . m i c ro s o f t . c o m / w o r k s h o p / s e r v e r / d e f a u l t . a s p와 h t t p : / / w w w . a c t i v e s e r v e r p a g e s . c o m / 을참조하기바란다.
J S P
JSP는 썬이 고안하고 표준화하고 있는 대(對)ASP 자바 기반 기술이다. JSP는 ASP와 문법상 아주 흡사한데, 다른 거라고는 스크립트 언어가 당연히도 자바라는 것이다(썬이 다른 걸 쓸 리가 없지 않은가?). ASP와는 달리, JSP는 모든 플랫폼에 두 루 걸쳐 수많은 공급업체가 구현하는 공개 표준이다(MS가 기술을 공개하고 다른 회 사가 장사하도록 할 리가 없지 않은가?). JSP는 서블릿과 뗄래야 뗄 수가 없는 사이인 데, 왜냐면JSP 한 쪽은 JSP 실행과정 중에 서블릿으로 변환되기 때문이다(이것이 기 본적으로 ASP와 다른 점이기도 하다). JSP는 이 책을 통해 더 자세히 살펴볼 것이다.
자세한 정보는 http://java.sun.com/products/jsp에 가보자.
자바 서블릿
이제 사전 지식이 구비되었으니 자바 서블릿으로 들어가 보자. 앞서 언급하였듯 이, 서블릿은 포괄적(generic) 서버 확장(서버의 기능을 확장하기 위해서 동적으로 적 재될 수 있는 자바 클래스)이다. 서블릿은 일반적으로 웹 서버와 함께 사용하며, CGI 스크립트를 대체할 수도 있다. 웹 서버의 자바 가상머신 안에서 동작된다는 점을 제 외하고는 고유의 서버 확장과 유사하다. 따라서, 안전하고 이식성이 높다. 서블릿은 서버의 도메인 안에서 단독으로 동작한다. 애플릿과는 달리, 웹 브라우저는 자바를 지원할 필요가 없다.
독립적인 프로그램이나 요청을 처리하기 위해 다중 프로세스가 필요한 CGI나 FastCGI와는 달리, 서블릿은 웹 서버 프로세스 안에서 독립적인 스레드가 모든 작업 을 처리한다. 이는 서블릿이 효율적이며 확장성이 높다는 것을 의미한다. 서블릿이 웹 서버 안에서 수행함으로써 서버와 매우 긴밀히 동작하기 때문에, CGI 스크립트 에서는 가능하지 못했던 일들을 수행할 수 있다.
서블릿의 또 다른 장점은 이식성이 높다는 점이다. 운영체제나 웹 서버에 독립적 으로 사용할 수 있다. 간단히 살펴본 것과 같이, 주요 웹 서버 대부분이 서블릿을 지 원한다. 서블릿이 웹 애플리케이션 개발을 위한 최적의 플랫폼을 제공할 것으로 확 신하며, 이러한 점은 이 장의 후반부에서 좀더 상세히 언급하고자 한다.
[그림 1-4] 서블릿 라이프사이클 서블릿 1에 대한 요청
서블릿 기반 웹 서버 메인 프로세스
JVM 서블릿 1 스레드
스레드
스레드 서블릿 2 서블릿 1에 대한 요청
서블릿 2에 대한 요청
서블릿 지원 요소
자바 자체와 마찬가지로, 서블릿도 이식성을 갖도록 설계되었다. 서블릿은 자바 를 지원하는 모든 플랫폼에서 지원되며, 모든 주요 웹 서버에서 동작한다.1 )썬의 자 바 소프트웨어부(전에는 자바소프트라고 알려진)에서 정의한 것과 같이, 자바 서블릿 은 자바에 대한 하나의 선택 패키지(Optional Package, 전에는 표준적인 확장이라고 했다)이다. 이는 서블릿이 공식적으로 썬사에 의해서 지원되며, 자바 언어의 일부분 이라는 것을 의미하지만 코아 자바 API의 일부분은 아니다. 대신 서블릿은 J2EE의 일부분으로 인식된다.
서블릿의 개발을 편리하게 하기 위해서 썬은 아파치와 공동으로 웹 엔진에 구애 받지 않고 서블릿을 지원하는 기본적인 일련의 클래스 집합을 공개하였다.
javax.servlet과 javax.servlet.http 패키지가 서블릿 API를 구성하는데, 최신버전은 http://java.sun.com/products/servlet/download.html에서 구할 수 있다.2 )이런 표 준적이며 공식적인 서블릿 API 클래스는 대개의 웹 서버가 지원하기 때문에(자체 구 현도 할 수 있긴 하지만) 꼭 위의 URL에서 다운받을 필요는 없다.
이 서블릿 API 클래스 세트는 작성된 서블릿을 컴파일하기 위해서 필요하기 때 문에 자신의 시스템에 설치되어 있는 한, 출처는 아무 상관이 없다. 서블릿 클래스 이외에 자신이 작성한 서블릿을 테스트하고 적절하게 사용하기 위해 서블릿 실행기 (전문적으로는 서블릿 컨테이너, 혹은 옛날부터 종종 서블릿 엔진이라고 불리는)가 필 요하다. 서블릿 컨테이너의 선택은 사용하고 있는 웹 서버에 부분적으로 의존한다.
세 가지 종류의 서블릿 엔진(독립형, 부가형, 내장형)이 있다.
1) 여러 웹 서버 공급업체가 자신의 서버측 자바 구현을 갖고 있으며, 이들 중 일부가‘서블릿’이라는 이름 으로 사용된다. 이들은 일반적으로 썬( S u n )사에서 정의한 자바 서블릿과는 호환되지 않는다. 이들 공급 업체 대부분은 자신의 자바 지원을 표준적인 서블릿으로 변환할 수 있도록 해주며, 아울러 동시에 표준 적인서블릿을 지원한다.
2) J S D K의 컨텐트가 JDK 1.2의 일부로 번들될 계획이 있었다. 그러나, 후에 J S D K에 대한 적절한 개정과 수 정을좀더 쉽게 하기 위해서블릿클래스를 J D K와 별도로 분리하여 유지하도록결정되었다.
독립형 서블릿 컨테이너
독립형 엔진은 서블릿을 자체적으로 지원하는 서버로서, 스스로 어떠한 작업도 해낼 수 있다는 장점이 있다. 그러나 최신의 서블릿 기술을 사용하려면 웹 서버 자체 가 새로 발표되어야 한다는 단점도 있다. 또한 대체로 서버 공급업체는 오직 자신들 이 제공한 JVM만을 지원한다는 편협한 사고방식도 문제이다. 이런 점에 주의하며 웹 서버 내부의 독립형 엔진들을 살펴보자.
• 아파치의 톰캣 서버는 서블릿 컨테이너가 서블릿을 어떻게 지원해야만 하는 가에 대한 공식 표준이다. 100% 순수 자바로 만들어졌으며, 공개 소스 라이 센스 정책하에 무료로 사용할 수 있다. 톰캣 자체의 모든 소스는 공개되어 있고 누구라도 톰캣 개발에 참여할 수 있다. 또한 독립형으로도 활약할 수 있고, 아파치나 기타 다른 서버에 서블릿 지원을 추가하는 식으로도 쓸 수 있다. 심지어는 임베디드 컨테이너(embedded container)로도 가능할 정도 다. 톰캣과 더불어 아파치는 javax.servlet.*와 javax.servlet.http.* 패키지의 표준 구현 개발도 담당하고 있다. 이 글을 쓰고 있는 시점에서‘서블릿’이라 함은 오직 공개 소스로 관리되는 javax.servlet.*와 javax.servlet.http.* 공식 패키지를 일컬어 지칭한다.1 )http://jakarta.apache.org를 참조하기 바란다.
• I P l a n e t(넷스케이프) 웹 서버 Enterprise Edition(버전 4 . 0과 그 이후)은 아마 도 가장 인기있는 자체 서블릿 지원 기능 내장형 웹 서버가 아닐까 싶다. 어 떤(분명히‘어떤’이다) 벤치마크에서는 가장 빠른 서블릿 구현체라는 평가를 받기도 하지만, 상기해야할 점은, 안타깝게도버전 3 . 5 1과 3 . 6은 초기 서블릿 API 1.0만을 지원하며, 많은 버그가 있어 서블릿 기능은 사실상 쓰레기나 다 름없다. 그래도Nescape 3.x 서버와 함께 서블릿을 사용하려면, 부가형 서블 릿 엔진을 사용하는 것이 바람직하다. h t t p : / / w w w . i p l a n e t . c o m을 참조하기 바란다.
• 오라일리사의WebSite Professional(버전 2.1과 이후 버전)은 iPanet 웹 서버 엔터프라이즈 에디션과 비슷한 기능으로 저가에 제공되고 있다.
1) j a v a x . s e r v l e t과 j a v a x . s e r v l e t . h t t p의 표준 공개 소스 구현의 존재는 수많은 버그 수정을(예를 들어, 제이슨 은 H t t p S e r v l e t을 수정하여 조건부 G E T의 동작을 향상하는 데 기여했다) 도왔고, 비호환성에 대한 우려 를 불식시켰다. 이런 좋은 선례가 앞으로도 더 많은 공식 자바 패키지의 공개 소스화를 고무하는 데 일 익을 맡기를 바란다.
• Zeus Web Server는 혹자가 지구상 가장 빠른 웹 서버라고 여기기도 한다.
기능도 많고 서블릿 지원도 당연히 포함한다. http://www.zeus.co.uk를 참 조하기 바란다.
• Caucho의 Resin은 성능에 무척 자신감을 보이는 공개 소스 컨테이너이다.
독립형 부가형 어느쪽으로도 쓸 수 있다. http://www.caucho.com을 참조 하기 바란다.
• Gefion Software의 LiteWebServer는 겨우 100kb가 넘는 귀여운 서블릿 컨 터이너로서, 데모를 번들한다든가하는 적은 용량이 필요한 곳에 쓰이기 좋 다. http://www.gefionsoftware.com/LiteWebServer를 참조하기 바란다.
• W3 컨소시엄의Jigsaw Server는 무료로 얻을 수 있으며, 자바로만 작성되어 있다. http://www.w3.org/jigsaw를 참조하기 바란다.
• 그리고 마지막으로 서블릿 세계의 태초에 썬의‘자바 웹 서버’가 있었다. 이 서버는 서블릿을 구현한 유사 최초의 서버였고, 서블릿API 2.0을 비공식적이 지만 사실상의 표준 참조를 구현하는 역할을 해왔다. 참고로 자바 웹 서버는
‘자바’라는 이름답게 자바로만 작성되어 있었다(기능들을 향상시키기 위한 두 개의 네이티브 코드 라이브러리는 제외. 역시 옥에 티?). 썬은 이 서버의 개발을 때려치웠고, 지금은썬-넷스케이프 연합전선의 일완으로i P l a n e t / N e t s c a p e 제 품에 몰두하고 있다.
자바 웹 서버의 추억
JWS와는 참으로 기구한 인연을 맺었다. 내가 서블릿을 처음 시작한 것은 1998년 12월 겨 울. 후배 한 명이 그렇게 해보라고 노래를 불러서(아마 전산실에서 놀고 있는 내가 안타깝 게 보였나보다) 마지못해 시작한 것이 오늘날 이지경에 이르렀다(고맙다, 후배야!).
자, 그래서 서블릿이라는 걸 해보려고 하는데, 도대체 뭔지 전혀 모르겠더라. 그나마 서점에 서 정말 반가운 책을 샀는데, 이름도 웃기는『서블릿 20일 완성』이었다(하지만 나는 서블릿 을 아직도 완성하지 못하고 있다. 이 책이 잘못된 걸까, 아니면 내가 잘못된 걸까?).
아마 우리나라 초창기 서블릿 개발자들의 필수품이 되다시피한 이 빨간 커버의 비서는 정말 이지 나를 거의 몰아지경의 상태로 끌고 갔다. 왜? 그건 그 책을 본 사람이면 다 안다.
역자도 말좀 합시다 ─ 5
첫째, 나같은 초보자(당시)가 보면 무슨 소린지 하나도 모를 고상한 설명들.
둘째, 죽어도 안 들어먹는 설정과 실행방법들.
셋째, 툭하면 컴파일이 안 되고 실행도 보장 못하는 예제들.
넷째, 다른 건 다 용서해도 이것만은 용서하지 못한다. 왜 “(큰따옴표) 표시를 out.println()에 써서 (결국 \”로 다 바꿔져 있다) 그렇지 않아도 복잡한 머리를 핑핑 돌게 만드냔 말야~~~ (나중에야 알았지만 HTML에서는 큰따옴표는 작은따옴표(‘)로 써도 된 다는 사실. 이 말을 들었을 당시 아주 바보가 된 기분이었다).
하지만 이렇게 욕을 할 만큼 좋은 책이기도 했다. 그리고 다른 대안도 없었다. 그래도 겨우 겨우 실행하게 된‘Hello World’를 브라우저에서 보는 순간 그 감회는 이루 헤아릴 수조 차 없을 것이다.
하지만 그것은 비극의 서곡에 불가했다. JDBC부터 시작해서 파일 업로드까지, 도대체 되 는 게 하나도 없었으니... 게다가 도와주는 이도 하나 없고. 전산실 인간들은 소 닭보듯 나 를 주시했다. “저인간 왜 저러고 사는지 몰라...”
이렇게 뭐가 안풀리다 보면 인간은 대체로 두 가지 행동양식을 취한다. 하나는 조용히 책을 덮고 길거리로 나가서 다신 안들어온다와 다른 하나는 심호흡을 한 번 하고는 책의 한글자 한글자를 향해 고함을 치는 것이다. “너 이제 나한테 죽었어~”
그러기를 두 달여쯤? 처음으로 서블릿으로 자료실을 만들었을 때의 감흥은“세상을 다 가 져라~”수준이었다. 그리고 무척 보람있었던 것은 그 자료실이 실제로 뜻깊게 쓰였다는 것 이다(놀랍지 않은가? 그 허접 덩어리를 써주다니. 그 자료실 이름는 더 놀랍게도 자이브 ( J i v e )였다) .
그사이에 나의 개발환경(이랄 것도 없었지만)에도 많은 변화가 일었다. 처음 책에서는 JSDK(이게 뭔가 하는 요새 사람이 있을 지도 모른다. 한마디로 톰캣 할아버지벌쯤 된다) 로 시작했지만, 이내“이것은 인간의 인내심에 대한 존엄성 침해다”라는 각성과 함께 다른 서블릿 엔진을 찾다가 JWS와 조우하게 된다. 마침 그즈음 이 책의 원서가 내 수중에 들어 왔다. 당시 이 책은 유난히 JWS와 친했기에 나도 선진 자바 왕국에 한번 들어가볼까나 하 고 발을 디뎠다가 아주 신세 망치게 된다.
JWS의 첫인상은 나름은 괜찮았다. 뭐 인스톨도 한번에 쫙 되고, NT에서는 서비스 모드로 도 뜬다. 좋아~ 바로 이거야~ 근데... 서블릿이 왜 이렇게 안 뜨는 거지? 이거 서블릿 엔 진 맞아?
문제는 바로 거기 그곳에 있었다. JSDK와 JWS는 개념 자체가 틀렸던 것이다. 그당시 조 금씩 기지개를 피던 서블릿 엔진의 제자백가시대는 그야말로‘아비규환’자체였다. 엔진마 다 서블릿을 돌리는 방식이 틀리니, 이게 자바가 맞는지조차 헷갈릴 정도였다. 그러니
애플리케이션 서버는 지속적인 성장세에 있으며, 엔터프라이즈 기반 애플리케이 션 개발을 위해 서버측 지원을 제공한다. 대부분 서블릿과 나머지 J2EE 스펙을 지원 하고 있다. 애플리케이션 서버에는 아래와 같은 것들이 있다.
• BEA 시스템의WebLogic 애플리케이션 서버는 업계 최초이자 가장 유명한 자 바 기반 애플리케이션 서버이다. h t t p : / / w w w . b e a s y s . c o m / p ro d u c t s / w e b l o g i c 참조.
• Orion 애플리케이션 서버는 하이엔드(high-end)이면서도 상대적으로 저가 인 순수 자바 기반 서버이다. http://www.orionserver.com 참조.
• Enhydra 애플리케이션 서버는 L u t r i s사가 제공하는 공개 소스 서버이다.
http://www.enhydra.org참조.
• Borland 애플리케이션 서버 4는 C O R B A에 역점을 두고 있는 서버이다.
http://www.borland.com/appserver참조.
자 이제 또 한번의 설정 전쟁이다, 하고 한 달간 또 실갱이를 벌였고, 결과는 나의 판정승.
JWS까지 거의 완전히 장악하고 나서부터 나의 서블릿 설정은 일사천리로 나갔다. 지금 생 각해보면 그때 그렇게 고생했던 것이 다 힘이 되고 자신감을 불어넣어주었던 것 같다. 그 이 후로 아무리 거지같은 설정문제가 내앞에 떡하니 버텨도 언제나 요리조리 살짝꿍떡해서 해 결했으니 말이다. 인간에게 고비는 성장의 발판인 것이다.
하지만 JWS는 그리 오래 버티지 못한 것으로 기억한다. 오히려 나하고는 잘 지내었는데...
내가 학교를 졸업하기 전까지 내 개인 웹 서버의 역할을 충실히 다하던 JWS는 내 머신이 전산실에 접수되면서 영원히 고정 IP번호를 잃는‘영구결번식’을 끝으로 가쁘게 몰아쉬던 하드 디스크 소리를 멈추었다(묵념).
JWS의 태생적인 한계였던 JVM 설정과 서블릿 스펙 고정은 후에 톰캣의 반면교사가 되어 지금의 우리에게 무한한 자유와 편리함을 유산으로 남겨주었으니, 살아있을 때 오욕을 당했 으나 죽어서 만민을 안락하게 한 축복이었던 것이다.
가끔 JWS가 다시 보고 싶어지기도 한다. 수많은 MP3를 받아내며 사랑과 우정을 함께 했 던 그 기억. 세월은 너무도 빨라 2년 전의 그 추억마저 잠들고 싶어한다.
JWS, 나는 너를 기억해~
• IBM의 Websphere 애플리케이션 서버는 일부 아파치 코드에 기반한 하이엔 드 서버이다. http://www-4.ibm.com/software/webservers 참조.
• AT G사의 Dynamo 애플리케이션 서버 3은 자바로 작성된 하이엔드 서버 중 하나다. h t t p : / / w w w . a t g . c o m / 참조.
• 오라클의 애플리케이션 서버는 Oracle 데이터베이스와 통합을 위해 설계된 서버이다. http://www.oracle.com/appserver 참조.
• IPlanet Application Server는 iPlanet 웹 서버 엔터프라이즈 에디션의 맏형 격인 J 2 E E규격 서버다. h t t p : / / w w w . i p l a n e t . c o m / p ro d u c t s / i n f r a s t r u c t u re / app_servers/nas참조.
• GemStone/J 애플리케이션 서버는 전에는 스몰토크 서버로 익히 알려졌던 회사의 자바 서버이다. http://www.gemstone.com/products/j 참조.
• Allaire(전에는 Live Software제품)의 Jrun 서버는 간단한 서블릿 컨테이너에 서 이제는 EJB, JTA, JMS같은 여러 J2EE 기술까지 제공하는 고급 컨테이너 로 탈바꿈하였다. http://www.allaire.com/products/jrun 참조.
• Silverstream 애플리케이션 서버는 처음은 서블릿에 초점을 맞췄지만 이제는 J2EE 규격을 완전히 보장하는 서버이다. http://www.silverstream.com 참 조.
부가형 서블릿 엔진
부가형 서블릿 엔진은 기존의 서버(원래 서블릿 기능을 염두에 두지 않고 설계되었 다든가, 성능이 좋지 않거나 구버전의 서블릿 구현을 제공하는)에 대한 플러그인과 같 은 기능으로 사용된다. 아파치, i P l a n e t의 F a s t Track 서버와 엔터프라이즈 서버, 마이 크로소프트사의I I S(Internet Information Server)와 P W S(Personal Web Server), 오라 일리사의 We b S i t e, 로터스 도미노의 Go 웹 서버, S t a r N i n e의 We b S TA R, 그리고 애 플사의 A p p l e S h a re IP 등을 포함해서 많은 웹 서버를 지원하는 부가형 서블릿 엔진 이 있다. 부가형 서블릿 엔진은 다음과 같다.
• 뉴 애틀란타사의ServletExec는 모든 유수한 운영체제와 웹 서버에 서블릿을 지원하도록 설계된 플러그인이다. 게다가 디버거도 꽁짜다. h t t p : / / w w w . servletexec.com/을 참조하기 바란다.
• Allaire(전에는 라이브 소프트웨어사)의 Jrun 또한 ServletExec와 마찬가지인 컨셉을 가지고 있다. 상당한 범용인 셈이다. h t t p : / / w w w . a l l a i re . c o m / products/jrun/을 참조하기 바란다.
• 자바-아파치 프로젝트의 JServ 모듈은 무료로 이용할 수 있는 서블릿 엔진 으로 널리 사용되고 있는 아파치 서버에 서블릿 지원을 부가한다. 하지만 안 타깝게도 이제는 단종되었고 톰캣이 플러그인 형식으로 대체하기에 이른다.
http://java.apache.org/를 참조하기 바란다.
• 전술한 아파치의 톰캣 서버는 아파치나 i P l a n e t / N e t s c a p e, I I S 등에 꼽아 (plugged) 사용할 수 있다.
내장형 서블릿 엔진
내장형 엔진은 일반적으로 다른 애플리케이션 안에 내장시킬 수 있는 경량 서블 릿 운영 플랫폼(lightweight servlet deployment platform)이다. 이 경우 엔진을 내장 한 애플리케이션이 진정한 서버가 된다. 내장형 서블릿 엔진은 다음과 같다.
• 아파치의 톰캣 서버는 보통 독립형이나 부가형으로 쓰지만, 필요하다면 다른 애플리케이션에 심어(embedded) 쓸 수도 있다. 톰캣은 공개 소스인 덕분에 다른 내장형 컨테이너의 개발은 거의 멈춰버렸다.
• Anders Kristensen의 Nexus 웹 서버는 서블릿 API의 대부분을 구현했으며, 자바 애플리케이션에 손쉽게 내장할 수 있고 무료로 사용할 수 있는 서블릿 실행 프로그램(r u n n e r)이다. h t t p : / / w w w - u k . h p l . h p . c o m / p e o p l e / a k / j a v a / nexus/를 참조하기 바란다.
추가 사항
더 나가기에 앞서서, 모든 서블릿 컨테이너가 동일하게 제작되지 않았다는 사실 을 지적하고자 한다. 따라서, 서블릿이 동작하게 될 서블릿 컨테이너를 선택하기에 앞서, 테스트를 해보거나 메일링 리스틀 체크해보기 바란다. 항상, 서블릿이톰캣 참 고 구현에서 동작하는 것과 동일하게 동작하는지를 검사해보기 바란다. 또한 어떤 개발 툴이 J2EE를 지원하며 속속들이 등장하고, 그 툴들을 통해 얼마나 신속하게 개 발 작업을 향상시킬 수 있는지 체크하는 것도 좋겠다. 서블릿을 이용하면, 가장 최소 의 공통 분모의 구현에 대해서 걱정할 필요가 없다. 따라서, 사용자가 원하는 기능을 가진 서블릿 엔진을 선택하는 것이 좋다.
최신판 서블릿 컨테이너의 완벽 리스트는 가격정보와 함께 h t t p : / / w w w . s e r v l e t s . c o m에서 알 수 있다.
서블릿의 특성
지금까지, 서블릿을다른 동적인 웹 컨텐츠 기술에 대한 대안으로 묘사하였다. 그 러나, 서블릿을 왜 사용해야 하는지는 실제적으로 설명하지 않았다. 서블릿을 웹 개 발을 위한 탁월한 항목으로 만드는 이유는 무엇일까? 필자는 서블릿이 다른 방법들 에 비해서 수많은 장점들(이식성, 파워, 효율성, 지속성, 안정성, 간결성(e l e g a n c e), 통 합성, 확장성, 효율성)을 제공하고 있다고 믿는다. 각각에 대해서 살펴보기로 하자.
이식성
서블릿은 자바로 작성하는 데다가 잘 짜여져서 폭넓은 지지를 받고 있는 A P I를 기반으로 하는 덕분에, 운영체제와 서버 구현에 상관없이 높은 이식성을 자랑한다.
사용자는 자바 웹 서버가 구동되는 윈도우 NT 머신에서 서블릿을 개발할 수 있으며, 추후에 별도의 노력 없이 아파치가 구동되는 고기능의 유닉스 서버에서 동일한 서블 릿을 사용할 수 있다. 서블릿을 이용해서, 진정한“write once, run everywhere”를 가능하게 할 수 있다.
두 가지 이유에서 서블릿의 이식은 흔히 애플릿에서 경험하는 장애물에 부딪치 지는 않는다. 첫째로, 서블릿의 이식은 가능한 모든 클라이언트 플랫폼에 대해서 테 스트해야 하는 애플릿과는 달리, 서블릿은 서블릿이 동작할 서버 머신에서만 동작하 면 된다. 만일, 서블릿을 판매하는 비즈니스를 하지 않는다면, 완전한 이식에 대해 걱정할 필요가 없다. 둘째로, 서블릿은 자바 언어의 상당한 오류를 발생시키면서도 비일관적으로 구현된 부분(AWT(Abstract Windowing Toolkit)는 스윙을 포함한 자바 그래픽 사용자 인터페이스의 기본을 형성한다)의 사용을 피해간다.
능력
서블릿은 코아(core) 자바 API의 완전한 능력(네트워킹과URL 접근, 다중스레드, 이미지 조작, 데이터 압축, 데이터베이스 접속, 국제화, 원거리 메소드 호출, CORBA 접 속, 그리고 객체 순차화, 기타)을 이용할 수 있다. 서블릿은 또한 J2EE 플랫폼을 그대 로 활용할 수 있는데, EJB, 분산 트랜젝션(JTS), 표준화한 메시징(JMS), 디렉토리 참 조(JNDI), 고급화한 데이터베이스 접근(JDBC 2.0) 등이 도움이 될 것이며 이런 표준 API의 리스트는 계속 늘어날 전망이고, 웹 애플리케이션 개발을 더 빨리, 더 쉽게 그 리고 더 믿음직스럽게 향상시킬 것으로 보인다.
또한 서블릿 작성자로서, 많은 서드파티(third-party) 제품의 자바 클래스나 자바 빈즈 컴포넌트를 선택을 할 수도 있다. 현재, 서블릿은 정규식 탐지, 데이터 차트화, 커스텀(custom) 데이터베이스 접근 그리고 고수준 네트워킹, XML 파싱, XSLT 변환 과 같은 일을 하기 위해 서드파티 코드를 사용할 수 있다.
서블릿들은 또한 클라이언트 서버 통신을 가능케 하는 데 매우 적합하다. 자바 기반의 애플릿과 자바 기반의 서블릿을 사용해서, 클라이언트와 서버간의 통신을 다 루기 위해 RMI와 객체 직렬화를 사용할 수 있다. 이는 클라이언트 에서의 사용자 정 의 코드를 동일하게 서버에서도 동작시킬 수 있다는 것을 의미한다. 동일한 목적을 위해 CGI를 이용한다는 것은 통신을 다루기 위해 자신의 프로토콜을 만들어야 하기 때문에 훨씬 복잡한 일이다.
효율성과 지속성
서블릿은 상당히 효과적이다. 일단 서블릿이 로딩되면, 일반적으로 단일 객체 인 스턴스로서 서버의 메모리에 남아있게 된다. 이후부터 서버는 요청을 다루기 위해 단순한 경량 메소드 호출로 서블릿을 호출하게 된다. CGI와는 달리, 인터프리터의 호출이나 프로세스의 생성이 없으므로 서블릿은 요청을 거의 즉각적으로 처리하기 시작한다. 다중 동시요청은 독립적인 스레드로 처리되므로, 서블릿은 상당한 확장성 을 갖는다.
일반적으로 서블릿은 지속적인 객체다. 서블릿이 단일 객체 인스턴스로서 서버 의 메모리 안에 남아있기 때문에 자동적으로 자신의 상태를 관리하고 데이터베이스 접근과 같은 외부 리소스에 접속 유지 등을 할 수 있게 된다.
안전성
서블릿은 다양한 수준에서 안전한 프로그래밍을 지원한다. 자바로 작성되었기 때문에 자바 언어의 강력한 자료형 안전성을 상속받게 된다. 게다가, 서블릿API는 자료형에 안전(type-safe)하도록 구현되었다. CGI 프로그램에서 서버의 포트번호와 같은 숫자 항목을 포함하여 대부분의 값들이 문자열로 취급되는 반면, 서블릿API에 서는 원래 값에 대응하는 유형으로 취급되므로 서버 포트 번호는 정수로 표시된다.
자바의 자동화한 가비지 컬렉션과 포인터의 부재는 댕글링 포인터(‘역자도 말좀 합 시다 - 6’참고), 비유효 포인터 참조, 그리고 메모리 누수와 같은 메모리 관리 문제 에서 서블릿이 안전하다는 것을 의미한다.
서블릿은 예외처리 메커니즘으로 인해 오류를 안전하게 다룬다. 만일, 서블릿이 0을 나누거나 다른 몇가지 비정규적인 연산을 수행하게 된다면, 서블릿은 예외를 발 생시켜 서버가 안전하게 처리할 수 있도록 한다. 만일, C++에 기반한 서버 확장이 동일한 오류를 발생한다면, 잠재적으로 서버를 망가뜨리게 될 것이다.
서버는 자바의 보안 관리자를 통해 서블릿에서 자신을 보호할 수 있다. 예를 들 어, 악의적이거나잘못 작성된 서블릿이 서버의 파일시스템에 손상을 주지 못하도록, 튼튼히 설계된 보안 정책을 갖는 엄격한 보안 관리자의 관리하에서 자신의 서블릿을 수행시킬 수 있게 함으로써, 서버는 자신의 서블릿을 수행시킬 수 있게 된다.
간결함
서블릿 코드의 간결함은 돋보이는 점이다. 서블릿 코드는 간결하고, 객체지향적 이며, 모듈화하여 있고, 놀랄 만큼 단순하다. 이러한 단순함이 있기에는 서블릿 API 자체의 공도 큰데, 이 API는 서블릿 개발을 위해 수많은 루틴들을 다루는 클래스와 메소드를 미리 포함하고 있기 때문이다. 심지어 쿠키 다루기와 세션 트랙킹과 같은 고급 연산이 보편적인 클래스로 추상화하여 있다. 하지만 몇몇 고수준의 보편적인
댕글링 포인터
댕글링(dangling)은 동사‘dangle’의 현재분사형으로 대롱대롱 매달려있다는 뜻이다. 하 지만 댕글링 포인터를 더 기술적으로 알기 위해 C 언어 불세출의 전문가인 후배‘주누주누’
와 대담을 가져보았다. 여기 대화전문을 전혀 여과없이 실었다(장소는 야후 메신저).
Ias_and_cb: 주누주누야질문이하나있는데, jwl33: 예.
ias_and_cb: 혹시C에서댕글링포인터(dangling pointer) ias_and_cb: 라는게뭐야?
jwl33: void *a = malloc(10);
jwl33: a = malloc(20);
jwl33: 이러면첫번째a가댕글링포인터가되죠.
ias_and_cb: 띵?
jwl33: 첫번째1 0바이트는결코찾을수없는주소가되잖아요.
jwl33: void *a = mallock(10);한후, jwl33: void *b = a;
jwl33: a = malloc(20); 이렇게하면괜찮구요.
jwl33: 첫번째경우 f r e e할수없게되죠.
jwl33: 이런식으로주소를읽어버리는걸dangling pointer 문제라고하는데요.
ias_and_cb: 그러니까a에새로운할당을하고까먹는거구나?
jwl33: 예.
ias_and_cb: 응. 알았어.
ias_and_cb: 고마워.
ias_and_cb: 역시주누주누는C 왕이야~
역자도 말좀 합시다 ─ 6
작업이 이 API의 범주를 벗어나 있기에 이 책에서는 com.oreilly.servlet 패키지를 제공하여 이 점을 보충하고 있다.
통합성
서블릿은 서버와 탄탄히 통합되어 있다. 이러한 통합은 서버가 CGI 프로그램으 로는 할 수 없는 방식으로 서버와 상호 협동을 가능케 한다. 예를 들어, 서블릿은 파 일 경로의 해석, 성능 기록(l o g g i n g), 인증 검사, MIME 타입 대응(m a p p i n g) 수행 등 을 위해 서버를 사용한다. 서버 고유의 확장은 이러한 일의 상당부분을 수행할 수 있 으나, 이러한 프로세스는 일반적으로 서블릿보다 복잡하고 오류가 발생하기 싶다.
확장성과 융통성
서블릿 API는 쉽게 확장할 수 있도록 설계되었다. 현재 이 API는 HTTP 서블릿 만을 위해 최적화한 클래스를 포함하고 있다. 그러나, 조만간 썬이나 서드파티가 다 른 유형의 서블릿을 확장하고 최적화할 수도 있을 것이다. 또한, HTTP 서블릿에 대 한 API의 지원 자체도 좀더 향상될 여지는 충분히 있다.
서블릿은 또한 컨텐츠 생성에 있어서도 아주 유연하다. 그냥 간단하게 out.println() 문장으로 할 수도 있고, 템플릿 엔진을 써 복잡한 페이지 뭉텅이도 엮 어낼 수 있다. HTML 페이지를 마치 자바의 객체 집합으로 처리해서 만들 수도 있 고, XML에서 HTML로 변환하는 방식도 가능하다. 심지어JSP같은 최신 기술도 밑 바닥을 까보면 서블릿이다. 앞으로 더 뭐가 튀어나올지 아무도 모르는 것이다.
발음 좀 해줘봐요~
겨우 1장밖에 안 되었지만 수많은 영어 고유명사들이 등장했다. 정말 벅차다. 다 영어 스펠 링을 썼지만, 도통 어떻게 소리내어 읽어야 할지 모를 것들도 꽤 많다(제이슨의 여자친구 이름만 해도 그렇다).
예를 들어 올레어(Allaire)같은 경우도, 나는 처음에는 알레어라고 했는데 어디선가 올레어 라고 본 것 같다(아마 올레어 한국지사 홈페이지). 그럼 그 전까지 알레어라고 했던 건 다 틀렸다는 거 아닌가? 창피하군. 지난 늦겨울 참여했던 프로젝트에서는 오라이언(Orion) 서 버를 썼는데, 이거 이름이 오리온 초코파이의 그 오리온 아닌가? 당연이 오리온라고 말했더 니, 먼저 그 서버를 쓰던 개발자가“오라이언”이라고 크게 발음하는 것 아닌가? 으이구, 또 창피해라. 오리온은 우리나라식 발음이고, 오라이언이 맞은 영어발음이었던 것이다(혀를 굴 릴 필요까지는 없다).
뭐 이러한 단어가 어디 한두 개랴. 심지어 현재 나와 함께 일하는 기획자 한 명은 지금도 끝 까지“쥐프(GIF: 이미지 파일 포맷)”을“기프”라고 발음한다. 한 열번쯤“기프”소리를 들 으면 정말 귀에 기브스 하는 것 같다. 이런 약어같은 경우에는 이 약어를 만든 단체에서 정 식 발음을 공표한다(그러니까 쥐프가 맞다. PNG의 경우는‘핑’이라고 읽는다). 내가 쥐프 가 맞다고 아무리 타일러줘도 소용이 없으니 언제 크게 쪽 당하기 전에는 못고칠 습관이다.
그런데, 아니 우리가 미국인도 아닌데 발음 좀 모르거나 틀리면 어떻습니까? 하면서 대드는 사람이 있을지도 모르겠다. 물론 신경 꺼도 된다. 어차피 우리는 그쪽과는 구강구조도 발성 구조도 틀리니까. 하지만 이것이 커뮤니케이션 문제로 비화되면 상황은 달라진다. 바벨탑은 괜히 무너진 것이 아니며, 답답하면 자기만 손해인 것이다. 평소에 이런 헷갈리는 고유명사 가 나오면 어떻게 발음하는지 확인해두자. 잘 아는 영미권 인사가 있으면 쪽팔리지만 한 번 물어보는 것도 나쁘지 않다. 영어 세미나나 강좌도 들어보자.
세계화, 거 정말 어렵다(‘영어공부 하지 마라’는 책을 보던 동료가 생각난다).
역자도 말좀 합시다 ─ 7
1장, 너 정말 많이 변했다!
1장을 다 번역하고 나니 정말 흥미로운 진단이 나왔다. 잠깐 소개할까 한다.
우선 처음 눈에 띄는 것은 JSP의 초등장. 원래 1판에서는 무슨 서버측 자바 스크립트라는 기상천외한 네이밍 센스의 기술이 등장하는데, 이름만 들어도‘아~’할 넷스케이프와 썬의 합작품이다. 왜 그렇게 이 인간들 하는 짓들은 이상한지, 결국 오래 못가고 지금은 흔적도 찾아보기 어렵다. 이 책을 처음 보셔서 궁금하신 분들은 서점 가서 1판을 한 번 구경해보기 바란다(강추는 아니다).
그리고 자바 서블릿을 소개하는 부분에서 1판의 후반부 상당량이 날라가버렸다. 이는 저자 제이슨(혹은 윌리엄 크로포드)의 예측성 발언이 문제가 되었기 때문이다. 사라진 부분의 내 용을 간략히 요약하면, 서블릿은 단순히 CGI의 대용이 아니다.“FTP 같은 비HTTP프로 토콜에서도 사용할 수 있다...”는 말이 나온다.
그러나 과연 누가 FTP에 서블릿을 쓸 것인가? 역자인 나도 가끔 상상은 해보았는데, 그게 그렇게 말처럼 쉬운 것이 아니다. 그것은 기본적으로 서블릿이 포괄적 서블릿( G e n e r i c Servlet)에서 많이 벗어나버렸기 때문이다. 원래 서버측 확장의 개념으로 시작한 서블릿은 점차 웹 서버와의 동거로 정착을 해갔고, 따라서 일반적인 서블릿은 그야말로‘일반적’이 될 수밖에 없었던 것이다.
또한, 원저자는 1판에서 확장 메일 서버의 가능성도 점쳤는데, 이는 서블릿 체이닝이나 필 터와 같은 개념의 절명으로 미래가 불투명해진 데다가, 자바 메일 API(Java Mail)와의 협 업이 예상처럼 그리 쉽지도, 편하지도, 강력하지도 않기 때문이다(이는 해본 사람이면 다 안다. 오죽했으면 오라일리에서도 다른 모든 자바 분야의 책이 있는데, 메일 관련만 책이 없 다).
가장 압권인 것은 이러한 미래의 예를 제시한 뒤에 달은 첨언이다. 1판의 발매당시 미국에 서나 역서가 나왔던 국내에서나 서블릿은 뭐가 어떻게 될지 아무도 모르는‘신천지’였다.
따라서 자바 개발자 자신들도 과연 기술에 매달려야 할 건지 말 건지에 대한 딜레마에 휩싸 일 정도로 애매모호한 상황이었던 셈이다. 고로 제이슨은 뭔가 메시아적인 메시지를 전달할 필요가 있었고, 그것도 아주 확실하게 내놓고 말하게 된다. 서블릿은 CGI의 훌륭한 대안이 며, 이 책도 그 점에 촛점을 맞추고 있다고. 즉, 단기적으로는 서블릿은 웹 서버와 HTTP 기반으로만 발전할 가능성이 농후하며, 일반적인 서블릿으로서 쓰임은 언제가 될 지 모르지 만, 아무튼 이 책에서는 일반론과 특화론(HTTP)을 적절히 구분해가며 언급하겠다고 천명 했었다.
하지만 이제 시간은 그 메시지에 대한 답을 이미 해버린 상태가 되어버려서, 위와 같은 황당 한 제언은 필요가 없게 되었던 것일까? 제이슨 본인도 약간 쑥스러웠던지 2판에서는 한마 디 언급도 없이 깨끗이 지워버렸다. 덕분에 나도 번역의 짐을 조금 덜었지만. 이런 것들이 역자가 엿보게되는 저자의 아픔이다.
역자도 말좀 합시다 ─ 8
서블릿의 지원요소 섹션에서도 말이 조금 바뀌었다. 전에는 썬이 API의 스펙만 규정하고 구현에서는 각 공급업체가 각개격파(그 중에는 썬 자신도 껴 있었지만)하는 식이었는데, 아 파치와 협력하면서부터 이 API 자체의 표준구현도 겸하고 있어 대부분의 공급업체 그 힘겹 고 짜증내는 API 구현의 노동에서 해방되는 기쁨을 누리게 되었다. 하지만 이것은 다른 한 편으로는 서블릿 라이브러리 자체를 썬에 의존하는 꼴이 되어 독점적 요소 발생의 가능성도 배제하기 어렵다. 그래서 그런지 기술력이 높은 회사들(IBM같은 고집불통들?)은 성능 향 상과 특화한 알고리즘을 바탕으로 자체 구현에도 인색하진 않다.
그 다음에 나오는 엔진이라는 말의 소멸과 컨테이너란 말의 발기도 눈에 띈다. 컨테이너는 우 리가 보통 그냥‘컨테이너‘라고 잘 쓰는 그런 말이다. 근데 이게 서블릿하고 무슨 상관이 있 는가?
초기 서블릿에‘엔진’이라는 말을 쓴 데에는 다 그만한 이유가 있다. 처음 서블릿이 나왔을 때는 독립형이라고는 하지만 사실상 HTML의 부속된 느낌을 지울 수 없었고, 따라서 부르 면“어서 옵서에”할 입장인 셈이었다. 따라서 뭔가 일의 개념이 배어 있었고 그래서‘엔진’
이라는 말이 붙었던 것이다.
그러던 것이 썬이 아파치에 서블릿에 관한 전권을 위임하면서부터 아파치 특유의 독특한 명 명감각이 발휘된 것이다. 이제 서블릿은 노동(labor)에서 활동(activity)의 존재로 패러다 임이 바뀌고 단순한 클래스에서 컴포넌트로 승화한다. 따라서 이들 서블릿 컴포넌트를 효율 적으로 관리할 매니저가 필요해졌고 그것을 컨테이너라는 다소 거친 단어로 매긴 것이다.
사실 매니저는 너무 권위적이고 저쪽 사람들이 썩 좋아하는 단어는 아니다. 오히려 컨테이 너란 말이 순박하고 친근하지 않은가?(지금도 고속도로를 달리는 산업의 역군, 컨테이너 트 럭들을 보라) 다행이 요새는 컨테이너란 말로 거의 통하는 분위기다(나는 개인적으로 이 말 을 좋아한다).
그리고 나서 왕창 변한 것이 바로 이 리스트들이다. 물론 약 2년간의 세월이 흘렀으니 그럴 만도 하지만, 솔직히‘이건 해도 너무한다’는 느낌이다. 그대로 남아 있는 것은 거의 없고, 가장 우울한 것은 JWS의 추락과 Jrun의 합병 소식.
우선 독립형과 J2EE, 부가형은 많이 추가된 반면에 내장형은 현저히 줄어버렸다 (본문에 그 이유가 나왔다). 이번 2판에서는 톰캣의 약진이 두드러지는데, 거의 제왕의 위치를 굳힌 것 같다.
이는 저자 제이슨의 농간도 약간 있다. 자신이 톰캣의 제작에 깊숙히 관여하는 코미터 (committer: 원래 톰캣은 누구나 개발에 참여할 수 있지만, 실제 소스코드의 변경 권한이 주어지는 것은 6개월간의 참여 성과에 따른 기존 코미터들의 투표(만장일치제다)로 선출된 코미터뿐이다. 코미터위에는 왕 코미터도 있다. 신기하면 톰캣 홈페이지를 가보도록. 제이 슨의 이름을 확인해볼 수 있다)이기 때문이다. 믿거나 또 믿거나. JWS의 총애도 땅에 떨어 지고, 대신 썬은 iPlanet으로 그나마 명맥을 이어가며 종가집 장맛을 유지하고 있고, 웹로 직은 당당히 J2EE 서버의 대표주자로 맹위를 떨치게 되었다(유일하게 위치도 안 바뀐 항
근데 위의 말을 무색하게 했던 에피소드가 있어 여기 소개하며 이 글을 마친다.
작년 한 해 국내에서 가장 서버 농사를 잘 지었던 곳은 어디일까? 바로 BEA다. 일설에 의 하면 BEA는 한국에 특별 조사반을 파견했었다고 한다. 국내 대표 딜러였던 IT plus(지금 은 웹로직을 취급하지 않는다)측에서는“왜 왔냐?”고 묻자 조사반은“지금 전 세계에서 웹 로직 서버가 가장 잘 팔리는 곳은 자바 종주국 미국도 아니고 바로 변방의 한국이다. 도대체 이렇게 오뉴월 미친년 치마자락 펄럭이듯 잘 팔리는 이유가 뭐냐?”며 반문했다는 것이다.
이것은 사실 2000년이 도래함에 따라 전 엔터프라이즈급 서버들이 이른바‘밀레니엄 리노 베이션’이라는 미명 아래 업그레이드를 단행했던 바에 크게 기인한다. 실제로 이때 썬도 엄 청나게 스펙을 팔아치웠다. 무슨 Y2K네 뭐네 하며 안갈아엎으면 큰 일 날 것처럼 떠들더니 만, 준비를 너무 잘 해서 그런지 몰라도 결국 원님덕에 나팔만 실컷 불었던 것이다.
하지만 새옹지마라, 그렇게 많이 팔린 웹로직이 이제 슬슬 그 마각을 드러내게 된다. 애플리 케이션 서버는 무슨 용가리 통뼈가 아니다. 애완동물과 마찬가지로 관심과 정성을 쏟아주지 않으면 바로 뻗어버린다(당해본 사람들은 안다). 그런데 우리의 마인드는 어떤가? 한번 팔 면 땡, 한번 개발하면 땡, 한번 장사하면 땡.
하지만, 그러다가는 업계에서 살아남지를 못하니, AS 비용도 변변히 못받고, 아주 난처한 지경에 처한 회사들이 곳곳에서 지르는 비명, 당신은 안들리시나요?
