김세곤 <sehkone@bawi.org>
1999년 12월 19일
프로그래밍을 공부하고 싶은 사람이나 프로젝트를 목전에 두고 있는 개발자 모두가 고민하고 있는 것은 과연 어떤 개발 방법이 가장 적합할 것인가 하는 문제이다. 큰 범주로는 어떤 OS를 택할 것인가하는 것에서부터 작게는 어떤 에디터를 사용할 것인가에 이르기까지 고민거리는 널려있다. 문제는 개발 방향 선정 과정에서의 고민으로 그치는 것이 아니다. 우여곡절끝에 한번 개발 방향이 잡혀서 상당 기간 동안 관련 자료를 수집, 학습하고 개발을 진행시키게 되면 다른 가능성을 고려해 보기란 쉽지 않다. 리눅스에 대한 이해가 없는 직장 상사때문에 윈도우즈에서 개발을 착수해 놓고나서 중간에 리눅스로 전환한다는 것은 상상하기 어려운 일이다. 오랫동안 C/C++을 공부하여 CGI 기법을 득도했다고 해도 보다 진보된 방법들로 여겨지는 Server-side Script 방식을 새로이 공부하여 사용하기란 만만치 않은 일이다. 따라서, 개발 과정에서의 후회를 최소화하기 위해서라도, 더 나아가서는 향후 프로젝트에도 유용하게 써먹을 수 있도록 하기 위해서, 초기 개발 방향 선정에 보다 혜안을 갖고 신중을 기해야 한다.
그러나, 어떤 개발 방향이 현재의 요건과 향후의 비전을 동시에 만족시켜줄 수 있는지를 찾아내는 것도 쉽지 않다. 진보적인 방법으로 보이는 것들은 진행 상태가 베타 정도인 경우가 많고 심지어는 스펙만 있고 관련 툴을 찾기 어려울 때도 있다. 그렇다고, 막상 손에 익은 개발 방법은 뭔가 향후 비전이 없어 보이고, 벤치마크 테스트에서 새로운 개념에 비해 못 미치기도 한다. 여기저기 관련 사이트를 뒤져가면서 비교적 그럴싸한 개발 방법 몇 가지를 압축해 놓고 나서도, 조언을 해 주는 개발자마다 딱히 어떤 개발 방법이 최선이라는 답을 내 주지 못 한다. 그도 그럴 것이, 이런 저런 방법을 모두 학습하고 실제에서 다 적용시켜 본 개발자는 거의 없기 때문이다. 인터넷에 널려 있는 벤치마크 테스트 자료도 내가 알고 싶은 것만 꼭 빠져있기 일쑤고, 어쩌다 나와 있는 정말 궁금한 정보는 테스트 자료마다 다르다. 설상가상으로 좀 좋은 툴이다 싶은 것은 열심히 다운로드 받으려고 보면 트라이얼 버전이고, 상업적으로는 절대 이용하지 말란다.
현재까지의 경험들과 산더미같은 관련 자료를 바탕으로하여 기도하는 심정으로 개발 방향을 잡았다고 하자. 그것으로 해결되는가? 문제는 이제부터 시작이라고 보면 된다. 돈 싸 들고 문제를 해결하려고 하면 간단하겠지만, 오픈 소스 진영의 개발자들의 자존심으로 상업용을 쓸 수 있겠는가. 자존심은 둘째로 쳐도 돈이 없는데 어쩌겠는가. 다행히도 절망에서 건져주는 것은 어딘가에 숨어있는 자유로이 배포가능한 소프트웨어! 중요 기능을 비교적 다 갖추고 있는 그래도 쓸만한 툴이 숨어 있기 마련이다. 그러나, 반가움도 잠깐, 설치해서 운영해 보려고 하면 어딘지 찜찜하다. 개발자야 열심히 노력해서 만들었겠지만, 그 양반이 언제까지 업그레이드 해 줄지 의문이 생기기도 하고, 어딘가에 심각한 버그 있을지 알 길 없음이다. 다시 여기 저기 뒤져보다 보면 내가 찾아낸 소프트웨어가 비교적 안정적으로 여러 사람의 지지를 받고 있는 것이 확인된다. 그렇다면 역시 이것을 찾아낸 나의 혜안에 놀라게 되며 설치를 시도해 보게 된다. 이제 본격적인 문제가 발생한다. 전세계의 많은 사람들이 좋다고 지지를 보낸 소프트웨어가 왜 나의 컴퓨터에서는 설치가 안 되는 문제가 발생한단 말인가. 싼 맛에 조립한 나의 펜티엄은 역시 비지떡이었단 말인가. 나랑 설치를 같이 시작한 다른 개발자가 7000만원짜리 컴팩 서버에서 잘 돌리고 있는 모양을 보면 열이 받기까지 한다. 이틀을 고민하고 머리를 쥐어 뜯고 나니 어느 순간 꿈쩍도 않던 소프트웨어가 돌아가고 문제는 디렉토리에 쓰기 퍼미션을 안 열어 놓았기 때문이라는 사실을 깨닫게 된다. 겨우 퍼미션 따위로 이틀을! 그러나, 기쁨도 잠시, 설치만 하면 무엇하겠는가. 개발하려고 모니터 앞에 앉으면 손에 쥐게 되는 자료라고는 README나 API를 줄줄이 설명해 놓은 정도이다. 튜토리얼을 열심히 읽어도 겨우 입문 정도지 본격적인 개발에 도움이 크게 되기 어렵다. 결정적으로 그 놈의 문서들은 죄다 영어로 씌여 있는 통에 해독하는데만 해도 한숨 나온다.
이 모든 어려운 과정을 헤치고 개발에 착수해서 프로젝트가 완수될 무렵, 개발자의 가슴을 찧는 것은 더욱 진보적인 방법이 수없이 생겨나고 내가 열심히 쌓은 기술이 오래가지 못 할지도 모른다는 불안감이다.
초기에는 HTML만으로도 놀라운 인터넷의 세계라고 여길 수 있었다. 그러나, 곧 정적인 문서에 식상하게 되고 뭔가 방문자와 호흡할 수 있는 동적인 사이트를 만들 필요성이 생겨나기 시작했다. 사실 지금은 전세계의 모든 사이트가 정적인 HTML문서만으로 움직이지 않는다. 끊임없이 데이터베이스와 연동하여 방문자에게 맞는 맞춤 정보를 제공하고 있다.
초기 HTML의 정적인 자료를 동적으로 움직이게 하기 위해서 등장한 방법이 CGI(Common Gateway Interface)이다. 초기 한동안은 많은 개발자에게 쉽게 전달되지 않아서 특별하고 대단한 기법쯤으로 여겨지기도 했는데, 그 메카니즘은 매우 간단하다. 별도로 만들어 놓은 프로그램에 HTML의 GET이나 POST의 방법을 통해 클라이언트의 데이터를 환경 변수로 전달하고 프로그램의 표준 출력 결과를 그대로 클라이언트에 되돌려 주는 형식이다. CGI는 특별한 라이브러리나 개발 툴을 지칭하는 것이 아니고 웹 서버와 별도로 만들어 놓은 프로그램 간의 데이터 교환 방식을 일컫는 것으로서 어떤 프로그래밍 언어로도 구현이 가능하다. 초기에는 C, C++, Perl, Visual Basic(물론 윈도그에서만) 등이 주류를 이루었다.
데이터베이스와 연동하기 위해서는 개별 데이터베이스가 제공하는 해당 언어의 라이브러리를 이용하는 방식을 취하였다. 예를 들어 postgreSQL을 웹과 연동시키기 위해서는 postgreSQL이 제공하는 C라이브러리를 이용한다든지 하는 식이었다.
구동 메카니즘의 취약성을 차치하고서라도 CGI 방법에서 표준 출력으로 HTML문서 양식을 만들어야 한다는 것이 개발자에게 가장 번잡스러운 문제로 등장하였다. 예를 들어, C로 CGI 프로그램을 만들었다고 하자. 간단한 HTML문서를 출력하기 위해서도 다음과 같은 C코드를 써야 했다.
...
printf("<HTML><HEAD><TITLE>CGI결과물</TITLE></HEAD>");
printf("\n<BODY>");
printf("\n난 \"멋진 넘\"이야");
...
HTML 문서 양식이 한눈에 들어오는가? 절대 그럴 수 없다. 겨우 한 줄의 HTML 코드를 쓰려고 해도 표준 출력 함수를 불러야
하고, 줄 넘김을 위해서 \n을 남발해야 하며, 큰 따옴표를 쓰려고 하면 앞에 \(backslash)를 붙여주어야만 한다. 매번 printf
함수가 호출되는 것도 달갑지 않다. HTML 문서의 한계상 문서 체계를 코드만으로 이해하는 것이 쉬운 일은 아니지만, C 코드와 섞여 있으니
어디가 어딘지 도통 감이 서지 않는다.
천신만고 끝에, 절대 직관적으로 눈에 들어오지 않는 HTML 코드에서 헤매다가 간신히 프로그램을 작성하고, 작성한 CGI 프로그램을 웹에서 동작하게 하려면 컴파일러로 컴파일을 우선 해야 한다. 그리고, 브라우저를 띄운다. 테스트를 했더니, "멋진 놈"이라고 나와야 할 것이 "멋진 넘"으로 오타가 나고 있다. 단 한 글자를 수정하기 위해 해야 할 일은 작성한 C 프로그램 코드의 "멋진 넘" 부분을 열심히 찾아서 한 글자 고치고 다시 컴파일을 하고 브라우저의 다시 읽기 버튼을 누르는 것이다. 상상해보자. 조금 긴 문서, 테이블이 복잡하게 들어간 문서를 고치려고 하면 과연 쉬울까? 그래도 디자인과 CGI를 함께 한다면 작성자 스스로 디자인을 고쳐갈 수 있으니 꺼이꺼이 수정할 수 있다고 치자. 그러나, 디자이너가 별도로 있고 개발자가 이를 CGI로 변환하는 작업만을 한다면? 디자이너가 C 코드를 봐가면서 고칠리 만무다. 예를 들어, 홈페이지의 대대적인 개선 작업의 일환으로 게시판의 디자인이 확 바뀌었다고 하자. 디자이너는 바뀐 게시판의 샘플 디자인을 CGI 작업자에게 던져 준다. 프로그래머는 이를 COPY-PASTE로 C 에디터로 가져 와서 열심히 표준 출력 함수로 우겨 넣어야 한다. 예전에 작업했던 것은 다 필요 없이 새 부대에 담아야 한다. 이제, 웹 개발자는 노가다 인력으로 전락하고 만다.
CGI의 결정적인 한계는 성능에 있다. 간략한 페이지를 CGI를 통해 보여 주려고 해도 웹 서버는 별도의 프로그램을 실행시켜야 한다. 프로그램 실행이 뭐 대수냐고? OS가 프로그램을 실행하는 단계를 잠깐 생각해 보자. 각각의 프로그램은 실행되면서 하나의 프로세스가 되는데, 개별 프로세스를 제어하기 위해 OS는 PCB(Process Control Block)를 사용한다. PCB에는 각 프로세스의 상태, 프로그램 카운터, CPU 레지스터, 스케줄링 정보, 메모리 정보, I/O 정보 등등등이 저장되고 이 PCB는 메모리에 저장된다. 더불어, 코드 내용이 메모리에 적재되는데, 프로그램 코드를 모두 메모리에 저장하는 것은 무리이므로 필요한 부분만을 찾아서 메모리에 싣는다. 프로세스가 하나만 도는 것이 아니므로 CPU는 현재 진행 중인 프로세스를 적절하게 스케줄링하여 동시에 수행되고 있는 효과를 내도록 한다. 위에서 언급한 프로그램이 실행되면서 OS가 처리해야 하는 일련의 일과 동시에 여러 작업을 수행하기 위해 프로세스를 전환하는 과정 등은 OS의 관점에서 보면 매우 Heavy한 일이다. 뿐만아니라, CGI는 클라이언트의 요청이 같은 URL, 즉 같은 CGI 프로그램을 실행시키는 것이라고 해도, 각각의 요청을 모두 개별 프로세스로 처리한다. 1000명이 카운터 CGI를 요청했다고 하면 1000개의 프로세스가 생긴다는 말이다. 몇 줄의 HTML 문서 결과를 보여 주기 위해 위에서 언급한 일들을 매번 수행한다는 것은 어딘지 효율적이지 못하다.
프로그램 코드 속에 HTML 문서를 우겨 넣는 방식은 디자인과 개발을 별도의 작업으로 분리시키지 못 하고 유지, 보수에 많은 시간을 들게 하는 등의 단점이 있었다. 이를 개선하는 방법들이 등장하기 시작했는데, 뭔고하니, HTML 문서 안에 우아하게 프로그램 코드를 넣는 방식이다. 대표적인 것이 ASP(물론 윈도그에서만), PHP 등이다. 이 중 근래에 사용의 편리성으로 인해 주목받고 있는 방법이 PHP이다.
PHP를 생각해 보자. PHP는 C 코드와 비슷해 보이지만 절대 C가 아닌 새로운 언어 스펙을 사용하고 있다. 기존 언어처럼 복잡하지 않고, 사용하기 간편하다. 뿐만아니라, 온갖 종류의 데이터베이스를 제어할 수 있는 함수도 제공되고 있으며, 기타 웹 개발에 필요하다 싶은 함수들은 잔뜩 들어가 있다. 그러나 PHP 한계는 여기에 있다. 모든 필요한 것은 PHP가 해결을 해 주어야 한다. PHP가 제공하지 않는 방법으로는 해결책을 찾을 수 없다는 말이다. PHP는 기존 언어를 사용하는 것이 아닌 새로운 언어이므로, 기존의 수많은 라이브러리, 소프트웨어와 연동시킬 수 없는 한계가 있다. 더욱이, PHP는 웹 서버에 모듈로 포함되어 있어서, 이런 온갖 기능이 웹 서버에 상당한 부하를 주게 된다. 구동 방식을 생각해 보자. 웹 서버에 PHP 문서가 요구되면 웹 서버는 PHP 모듈로 그 제어권을 넘긴다. PHP 모듈은 PHP 문서를 문법적으로 해독하면서 관련 함수들을 구동하여 결과물을 브라우저에 보내게 된다. 언어를 문법적으로 해독하는 과정은 아무리 간단한 문법의 언어라고 해도 일정 수준의 시간이 필요하다. 함수가 많아지고 기능이 복잡해질 수록 요구되는 시간은 늘어난다. 뿐만아니라, 한번 실행한 문서의 해독 정보를 저장하는 것이 아니라 매번 그 문서가 요구될 때마다, 같은 작업을 수행해야 한다. PHP 모듈은 웹 서버에 들어가는 다른 모듈에 비해 매우 큰 규모로 웹 서버 수행에 부담을 가중시킨다. 이런 이유로 성능 향상을 위해 구문을 최소화하느라 객체지향 등의 최신 언어 기법을 구사할 수 없다. 때문에, C++이나 Java처럼 한번 사용한 소스 코드를 재사용하기 어렵다.
자바는 Sun이 개발한 객체지향 언어로서 플랫폼에 구애 받지 않는 장점때문에 급속히 확산되고 있다. 최신 프로그램 언어 개념인 객체지향, 멀티쓰레드, Garbage Collection, Exception Handling 등을 복합시킨 언어로서 기반이 매우 훌륭하다. 그동안 등장했던 Lisp, C, C++ 등 모든 언어의 장점을 절묘하게 복합시켰으며 C에서 사용해온 포인터와 동적 메모리 관리 등을 아예 없애 개발자의 부담을 덜어주었다. 자바 코드는 어느 OS에서도 JVM(Java Virtual Machine)만 있다면 단 한 줄의 코드 수정 없이 똑같이 가동시킬 수 있다. 자바 소스를 자바 컴파일러로 컴파일 하면 Bytescode가 생성이 되고, 이 Bytescode는 어떤 OS의 JVM에서도 동등하게 실행된다. 그러나, 초기엔 자바의 개념적 우월성에도 불구하고 JVM의 수행 속도가 매우 느려 실제 개발 현장에서 채택하기에는 무리였다. 그러나, 하드웨어 사양의 발전과 JVM의 성능 향상으로 초기의 느리다는 지적은 점차 사라지고 있다.
초기에 자바는 애플릿 작성에 많이 이용되었다. 애플릿은 HTML 코드안에 포함되는 독립적 프로그램으로 브라우저가 이를 받아서 수행한다. 넷스케이프와 익스플로러 모두 브라우저 안에 자바를 수행할 수 있는 JVM을 내장하고 있으므로 OS와 독립적으로 동등하게 실행시킬 수 있다. 애플릿은 서버측에서 동적으로 생성되는 것이 아니라 클라이언트(브라우저)에게 보내져 클라이언트 환경에서 수행된다. 자바 Bytescode는 소스를 자바 컴파일러로 컴파일한 결과물로서 HTML 문서에 비해 크기가 매우 크며 웹 서버에서 브라우저로 전송되기까지가 많은 시간이 걸린다. 일단 전송된 애플릿은 브라우저가 수행시키므로 그 속도는 클라이언트의 시스템 환경과 브라우저가 내장하고 있는 JVM의 성능에 따라 좌우된다. 28.8K 정도의 모뎀 환경이라면 그럴듯한 애플릿을 다운 받아서 수행하는데는 많은 인내심이 필요하게 된다. 그러나, 점차 인터넷 통신 환경이 좋아지고 있으며 가정집을 제외한 대부분의 사무실과 학교 등에서는 전용 회선이 깔려 있고, 넉넉한 환경의 전용선이라면 애플릿을 구동하는데 무리가 없다. 근래에는 가정에서도 초고속 통신 환경을 싼 값에 구축할 수 있으므로 점차적으로 인터넷 환경에서 애플릿의 전송은 부담이 되지 않을 것이다. JVM도 기술적으로 많이 향상되었고, Sun뿐 아니라, IBM과 같은 매머드급 회사들이 뛰어들어 개발하고 있어 초기 지적받았던 JVM의 구동 속도는 점차 문제가 되지 않는 상황이다.
오늘날의 많은 개발은 웹과의 연동을 염두에 두고 있다. 자바 진영도 예외는 아니어서, 근래의 발전 방향은 인터넷에 초점이 맞추어져 있다. 지금까지 등장한 웹 개발 방법들은 페이지 생산에 비해 보수가 매우 어렵다는 점과, 동시 접속자가 많아지면 성능이 저하된다는 점, 기존에 산재해 있는 많은 개발 방법들과 연계가 번거롭다는 점 등이라고 말하였다. 이를 개선하려는 노력이 반영되어 자바 진영에서는 이러한 단점을 극복해 줄 수 있는 방법을 제시하고 있다. 뿐만 아니라, 대규모 프로젝트에서 적합한 훌륭한 아키텍쳐를 제공하고 있다.
보통 웹 개발이라면 단순히 방문자에게 효과적인 화면을 제공하는 것 쯤으로 생각하기 쉬운데, 내부적으로는 끊임없이 데이터베이스와 연동하기도 하고 각종 미들웨어를 사용하여 효율을 증대하기도 한다. 이 중에서 웹은 클라이언트와의 접점이며 인터페이스이다. 자바에서는 웹 인터페이스로서 서블릿과 자바 서버 페이지의 두 가지 방법을 제공한다.
우선 서블릿에 대해서 간략히 소개하겠다. 서블릿은 일종의 CGI이다. 그러나, 그 구동 방식은 여러가지 점에서 다른데 가장 큰 장점은 클라이언트가 요청하는 서블릿이 개별적인 프로세스로 실행되는 것이 아니고 서블릿을 제어하는 모듈 내에서 실행된다는 것이다. 아파치와 JServ를 사용했다고 하면 쉽게 ps를 통해 java 프로세스가 하나만 돌고 있는 것을 확인할 수 있다. 이것은 클라이언트들이 같은 서블릿을 요청하면 이 서블릿이 메모리에 개별적으로 올라오는 것이 아니라 하나만 메모리에 적재된다는 뜻이고 이는 엄청난 퍼포먼스 향상을 가져온다. 뿐만 아니라, 모든 실행되는 서블릿은 이를 제어하는 모듈의 통제하에 놓이게 되므로 서블릿끼리의 자유로운 통신이 가능하고 쓰레드를 사용한다면 멀티쓰레드 프로그래밍이 가능해진다. 일반적인 CGI의 큰 단점 중에 하나인 보안 문제도 서블릿을 사용하면 걱정할 필요가 없다.
또 하나의 장점은 서블릿이 자바를 사용하기 때문에 자바가 제공하는 수많은 기능을 제한없이 사용할 수 있다는 것이다. 예를 들면 자바가 제공하는 2D, 3D 그래픽 툴을 이용해서 동적인 이미지를 생산할 수 있고, 자바가 제공하는 메일 클래스들을 이용하면 효과적으로 메일 전송 및 관리를 할 수 있다.
또, 자바를 기반 언어로 사용하기 때문에 자연스럽게 얻어지는 장점이 있는데 이것은 코드의 손쉬운 재사용, 플랫폼 독립성, JDBC 사용 등이다. 코드의 재사용은 객체지향언어의 중요한 개념으로 잘 만들어 놓은 구조의 클래스라면 어느 코드에서도 쉽게 사용할 수 있고 계승 등을 이용하여 기능을 추가할 수 있다. 플랫폼 독립성도 역시 자바의 중요한 장점인데 만일 서블릿으로 웹을 구축하였다면 어떤 OS, 어떤 기계라도 그 플랫폼이 자바를 지원하기만 하면 한 줄의 코드 바꿈없이 개발해 놓은 코드를 그대로 이식할 수 있다. 자바는 리눅스, 유닉스를 비롯하여 심지어 윈도그에서도 무리없이 돌아가며, 서블릿 환경도 어떤 플랫폼이라도 쉽게 구축할 수 있다. JDBC를 사용하면 어떤 데이터베이스와도 똑같은 인터페이스로 연동할 수 있으므로, 데이터베이스를 다른 기종으로 교체한다고 해도 서블릿 소스 코드를 거의 수정할 필요가 없다.
서블릿 코드를 잠깐 소개하겠다.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class CMemberTest extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html; charset=EUC_KR");
PrintWriter out = response.getWriter();
out.println("<HTML><HEAD><TITLE>세션 테스트</TITLE></HEAD></HTML>");
out.println("<BODY>");
Cookie[] cookies = request.getCookies();
boolean pass = false;
String email = "";
for (int i = 0; i < cookies.length; i++) {
Cookie thisCookie = cookies[i];
out.println(thisCookie.getName() + ":" + thisCookie.getValue());
if (thisCookie.getName().equals("pass") &&
thisCookie.getValue().equals("yes")) pass = true;
if (thisCookie.getName().equals("email"))
email = new String(thisCookie.getValue().getBytes(), "EUC_KR");
}
try {
if (pass) {
out.println("인증 통과된 아이디임" + " : " + email);
} else {
out.println("인증 통과되지 않았음");
}
} catch (NullPointerException e) {
out.println("인증 과정을 거치지 않았음");
}
out.println("</BODY></HTML>");
}
}
위의 예에서는 쿠키를 이용하여 인증 여부를 확인시켜 주는 간단한 방법을 보여준다. 쿠키를 이용하는 인증은 보안 측면에서는 빈약하여
WebDox가 제공하는 아파치에 추가 되는 postgreSQL 인증 모듈을 쓰는 방법이 훌륭하지만, 우선 위의 방식은 쿠키 사용예를 보여주며
보안이 크게 필요하지 않는 수준이라면 사용할 수 있다.
서블릿은 CGI와는 비교할 수 없는 수준의 좋은 아키텍처를 갖고 있고 다양한 장점들이 있다. 그러나 역시 자바 코드 속에 HTML 코드를 넣어야 한다는 단점이 있는데, 이를 극복한 것이 JSP(Java Server Page)이다. JSP는 HTML문서 안에 자바 코드를 넣는 형식으로 PHP, ASP와 같이 Server-side script 방식이다. 그러나, JSP는 소스 수정 시 자동적으로 서블릿으로 전환되어 구동되며 이점에서 완전히 서블릿과 동등하다. JSP의 코드를 잠시 살펴보자.
<%@ page import="java.sql.*" contentType="text/html; charset=EUC_KR" %>
<%
String userId = request.getParameter("userid");
Connection db;
ResultSet rs;
Statement stmt;
try {
Class.forName("postgresql.Driver");
} catch (java.lang.ClassNotFoundException e) {
System.err.println(e.getMessage());
}
%>
<HTML>
<HEAD><TITLE>JSP Sample page</TITLE></HEAD>
<BODY>
<TABLE>
<TR>
<%
try {
db = DriverManager.getConnection("jdbc:postgresql:dbname", "dbowner", "password");
stmt = db.createStatement("SELECT name FROM member WHERE userid = " + userId);
rs = stmt.executeQuery();
while (rs.next()) {
%>
<tr>
<td><%= rs.getString("name") %><td>
</tr>
<%
}
%>
</TABLE>
</BODY>
</HTML>
<%
} catch (SQLException e) {
%>
<%= e.getMessage() %>
<%
}
%>
HTML 문서 안에 자바 코드가 들어가는 모습과 JDBC를 이용하여 postgreSQL과 연동되는 모습을 볼 수 있다. <%
%> 태그 안에는 자바 코드를 아무런 제한 없이 써 넣으면 되고, <%= %> 태그 안의 자바 코드 결과는 화면에 그 결과가
보여지게 된다. Post나 Get으로 전달받는 값들은 request.getParameter() 함수를 이용하면 쉽게 제어할 수 있다.
많은 개발자들이 가장 궁금해 하는 것이 역시 여러 개발 방법들 중 어떤 것이 더 나은가 하는 점일 것이다. 지금까지 여러가지 방법들의 장단점을 언급했는데 정리해 보기로 하자. 비교 대상은 일반 CGI, Server-side scripts(PHP, ASP), Servlet+JSP 등이다.
ASP는 스크립트로 씌여 졌지만 일단 컴파일 되면 CGI로 바뀌므로 CGI가 갖고 있는 여러가지 문제점을 그대로 지니게 된다. 따라서, ASP와 CGI가 성능면에서 가장 취약하다. PHP의 경우는 대체적으로 매우 뛰어난 속도를 보여 준다. Servlet과 JSP는 JVM에 그 성능이 의존적이다. 현재는 ASP나 CGI보다는 빠르지만 PHP보다는 약간 느리다는 평을 얻고 있다. 그러나, 여러 미들웨어를 사용하거나 DB와의 많은 트랜잭션이 있는 경우는 PHP에 앞선다고 보고되고 있으며, JVM의 성능 향상에 따라 꾸준한 성능 향상을 기대할 수 있다.
단연, Servlet+JSP 방식이 우월하다. 자바가 제공하는 모든 기능을 자유롭게 사용할 수 있으며 코드의 재사용 등에서 탁월하다. JDBC를 사용하여 모든 데이터베이스와 똑같은 인터페이스로 데이터 교환이 가능한 점에서도 Servlet+JSP 방식이 뛰어난 확장성을 갖고 있다.
ASP나 PHP는 간단한 문법이므로 초보자도 쉽게 사용할 수 있다. 그러나 Servlet과 JSP는 자바를 알아야 한다는 전제 때문에 쉽게 다가서기 어려운 면이 있다. 하지만, 개발자는 간단한 웹 인터페이스만을 작업하는 것이 아니기 때문에 제대로 한 언어를 알아두면 어느 때고 약이 된다. 간단한 작업을 위해서라면 자바를 전부 익혀야 하는 부담없이 손쉽게 작업할 수 있기도 하다.
향후 웹 개발에서 자바를 이용한 솔루션은 큰 몫을 차지할 것이며, 큰 프로젝트일수록 그 사용 비중은 높아질 것이다. webdox는 웹 개발에 있어서의 자바의 비전을 인식하여 지속적으로 자바를 이용한 웹 개발 방법에 대한 자세한 글을 게재할 예정이다.