1장. jsp 및 servlet을 활용한 동적 웹 프로그래밍...
TRANSCRIPT
1. JSP 및 Servlet을 활용한 동적 웹 프로그래밍 소개
JSP(Java Server Page)는 동적 웹 페이지를 작성하기 위한 좋은
도구이다. 본 교재에서는 JSP를 이용하여 앞으로 HTML을
동적으로 생성하는 프로그래밍 코드를 작성할 것이다. JSP는
상대적으로 배우기 쉬우며, HTML과 스크립트 언어에 관한 약간의
경험만 있으면 누구나 바로 이 책과 함께 JSP를 배울 수 있다. 이
장에서 우리는 먼저 인터넷상에서 웹 서버의 동작방식을 알아보고,
그 이후에 정적인 웹 페이지와 동적인 웹 페이지의 차이에 대하여
알아본다. 다음에, 서버측 스크립팅 기술 및 클라이언트측 스크립팅
기술을 알아보고 JSP의 장점을 살펴보면서 1장을 마친다.
1.1 웹 동작방식
1.2 웹 프로그래밍과 동적 웹 페이지
1.3 스크립팅(Scripting) 기술
1.4 왜 JSP 인가?
1.1 웹 동작방식
WWW(월드 와이드 웹, 또는 웹) 은 인터넷상에 분산되어 존재하는 온갖 종류의 정보를 통일
된 방법으로 찾아볼 수 있게 하는 광역 정보 서비스 및 소프트웨어이며, 1989년 스위스 제네
바에 있는 유럽 원자핵 공동 연구소(CERN:European Council for Nuclear Research)의
Tim Berners-Lee1)가 제안하였다. 웹을 통하여 전달되는 정보는 웹 서버(Web Server) 내
에서 하이퍼텍스트(Hyper-text) 형태의 홈 페이지(Home Page)라는 단위로 보관 및 관리되
며, 링크(Link)라고 하는 기능에 의해 인터넷상에 지리적으로 분산되어 있는 세계 각지의 하
이퍼텍스트와 연결될 수 있다.
웹 서버에 어떠한 정보를 요청하는 곳은 대개 거리상으로 멀리 떨어져 있는 웹 클라이언트(원
격 컴퓨터)의 웹 브라우저이다. 웹 클라이언트(Web Client)에 해당하는 것은 일반 사용자의
브라우저(Browser)이다. 국내의 많은 사용자들은 일반적으로 Windows OS를 활용하면서
그 안에 내장되어 있는 인터넷 익스플로러(Internet Explorer)를 브라우저로 활용하지만 최근
파이어폭스(Firefox)2)라는 브라우저도 많이 활용되고 있다.
하이퍼텍스트 전송 프로토콜(HyperText Transfer Protocol, HTTP)은 웹 클라이언트와 웹
서버 사이에 대화하는 방법 및 데이터 정보를 웹 서버에서 웹 클라이언트로 전송하는 방법을
정의하는 표준 프로토콜이다. 브라우저상에서 사용자들은 http://로 시작되는 URL (Uniform
Resource Locator)를 입력함으로써 웹 서버의 데이터 정보를 획득하여 가져온다. 이 URL의
맨 앞에 붙어 있는 http://가 인터넷 프로토콜로서 HTTP를 사용하겠다는 의미이다.
[그림 1-1] 웹 클라이언트와 웹 서버간의 정보를 주고
받는 모습
[그림 1-1]에서 보이듯이 HTTP는 클라이언트가 서버로 연결을 설정하고, 데이터를 요청하
고, 서버가 그 요청에 응답하고, 마지막으로 연결을 닫는 등의 방법을 정의하는 무상태
(stateless) 프로토콜이다. 무상태 프로토콜이라는 것은 서버가 클라이언트의 요청에 응답한
이후에 클라이언트의 상태에 대하여 어떠한 것도 자체적으로 유지관리하지 않는다는 것을 의
미한다. 또한, HTTP는 그 하부에서 데이터의 이동을 위해 TCP/IP(Transmission Control
Protocol/Internet Protocol)를 사용한다.
1) http://www.w3.org/People/Berners-Lee/
2) http://www.mozilla.com/firefox/
HTTP에 기반한 웹 클라이언트와 웹 서버가 서로 간에 정보를 주고받는 작업은 다음과 같은
네 단계의 순서로서 행한다.
▣ 연결 설정하기
클라이언트는 디폴트로 서버의 포트 80번에 TCP 연결을 만든다.
▣ 요청하기
클라이언트는 서버에게 지정된 URL의 페이지를 요청하는 메시지를 보낸다. 이 요청을 헤더
정보라고 하며 그 형식은 일반적으로 다음과 같다.
G ET / in d e x .h tm l H T T P /1 .1
맨 앞의 GET은 웹 서버로의 행위를 정의하는 메소드(method)이며 /index.html은 서버에 있
는 파일에 대한 상대적 URL이다. GET 이외에도 다른 종류의 메소드가 있으며 이후 챕터에
서 더 알아보자. 헤더 마지막 부분의 HTTP/1.1은 클라이언트가 사용 중인 HTTP 프로토콜
버전이다. 위와 같은 메시지 뒤에는 반드시 빈 줄이 있어야 하며, 서버는 이와 같은 빈 줄을
보고 클라이언트의 요청이 모두 왔다는 것으로 인식한다.
위와 같은 GET 으로 시작되는 한 줄의 헤더 내용으로도 서버에 자신이 요청하는 내용을 전
달할 수 있지만 다음의 형식으로 다른 정보들을 위의 GET 헤더 정보 뒤 그리고 빈 줄 앞에
포함할 수 있다.
a c ce p t : im ag e /g if , im ag e /x -xb itm a p , im ag e / jp e g , im ag e /p jp e g ,.. .a c c e p t- la n g u ag e : k ou a -cp u : x 8 6u s e r-a g e n t : M o z illa /4 .0 (c o m p a t ib le ; M S IE 7 .0 ;.. . . . .. . .. . .(빈 줄 )
위의 예에서 accept는 어떤 종류의 데이터를 클라이언트가 다룰 수 있는 지를 서버에게 알려
주는 것이다. 위의 예에서는 클라이언트가 GIF과 JPEG 이미지 등을 다룰 수 있다고 서버에
게 알려주고 있다. 이러한 'image/gif' 형태를 MIME (Multipurpose Internet Mail
Extensions)3) 타입이라고 한다. MIME 타입은 원래 E-mail로 전송되는 데이터의 타입을
지정하기 위한 포맷이지만 HTTP에도 함께 사용 된지 오래되었다.
3) http://ko.wikipedia.org/wiki/MIME
accept-language는 클라이언트의 웹 브라우저가 한글버전으로 설치되었음을 알려주며
ua-cpu는 클라이언트 컴퓨터의 cpu 종류를 알려준다.
user-agent 정보는 어떤 브라우저가 사용 중인지를 서버에게 말해준다. 이 정보를 통해 서버
는 특정한 브라우저에 적합한 동작을 할 수 있고 또는 특정 브라우저에 적절한 데이터를 보낼
수 있다. 위의 예에서는 클라이언트가 인터넷 익스플로러 브라우저 7.0 버전 (MSIE 7.0)의 요
청임을 서버에게 알려주고 있다.
하지만 이러한 accept, accept-language, ua-cpu, user-agent 정보들은 어디까지나 선택사
항이며 반드시 있어야 하는 것은 아니다. 본인의 웹 브라우저에서는 어떠한 정보들이 웹 서버
로 전달되는 지 알아보기 위해서는 http://www.thinkonweb.com/jspbook/ch01/requestInf
o.jsp4) 를 접속하여 “헤더의 부가 정보” 부분을 보면 된다.
[그림 1-2] 웹 클라이언트가 서버에게 전달하는 정보들
▣ 응답하기
서버는 클라이언트에 응답을 보낸다. 응답은 응답코드가 담긴 헤더 정보로 시작하고 서버의
종류 및 보내는 내용의 MIME 타입 등의 부가 정보가 뒤따르고, 다음엔 빈 줄, 그 다음엔 요
청된 문서 또는 에러 메시지가 온다. 요청된 문서를 찾았다면 일반적인 응답은 다음과 같을
것이다.
4) requestInfo.jsp의 코드 내용은 8장의 request_result.jsp에서 다시 그 내용을 자세히 살펴 볼 것이다.
H T TP /1 .1 O K 2 0 0S e rv e r : A p a c h eM IM E -v e rs io n :1 .0C o n te n t- ty p e :te x t/h tm lC o n te n t- le n g th : 1 0 7(빈 줄 )< h tm l>< H EA D >< T it le>A S am p le H T M L f ile< /T it le >< /H EA D >< b o d y>T h e re s t o f th e d o c u m e n t g o e s h e re< /b o d y>< /h tm l>
첫 번째 줄은 서버가 사용하고 있는 프로토콜 (HTTP/1.1)을 나타내고, 바로 응답코드가 나온
다. “OK 200”은 요청이 성공적이었다는 자주 나오는 응답 코드이다. 다른 헤더 라인들은 서
버의 소프트웨어(Apache)와 사용중인 MIME의 버전 및 MIME의 내용 형식
(Content-type), 전송될 내용의 길이(헤더는 포함하지 않음) 등을 알려 준다. 그 다음의 오는
빈 줄은 헤더 정보들이 모두 끝나고 다음부터는 실제 전송되는 내용이 온다는 표시이다.
HTTP는 많은 응답코드를 지닌다. 그 중 100부터 199는 요청이 현재 처리된다는 정보를 알
리는 것이고, 200에서 299까지의 응답코드는 언제나 성공을 가리키고, 300에서 399까지는 리
다이렉션(redirection)을 가리킨다. 400에서 499까지는 클라이언트 쪽의 에러를 가리키는 코
드고, 500에서 599까지는 서버 쪽의 에러를 알리는 코드이다. 자세한 응답코드는
http://www.thinkonweb.com/tip/http_response_code.html 에 설명되어 있다.
▣ 연결 끊기
클라이언트나 서버 혹은 둘 다 연결을 닫는다.
이상 네 과정을 통하여 독립된 하나의 HTTP 정보 전달 과정이 완료된다. HTTP 프로토콜
을 무상태(stateless) 특성 때문에 이후 클라이언트가 다시 연결한다고 해도 서버는 이전의 연
결에 대한 어떤 기억이나 결과도 가지고 있지 않는다. 반면에 FTP와 같은 프로토콜은 연결이
닫히기 전에 많은 요청을 수행할 수 있다. 이와 같이 상태를 기억하지 않는 것은 HTTP의 약
점처럼 보이지만 서버의 부하를 최대로 줄일 수 있다는 강점이 있다.
간단하게 HTTP 프로토콜을 체험해 볼 수 있다. [시작]버튼의 [실행]을 클릭하여 "cmd"를 입
력한 후 엔터를 입력하자. 그러면 명령어를 텍스트 기반으로 입력할 수 있는 아래 모습의 창
이 뜬다. 이 곳에 곧바로 “telnet www.naver.com 80" 이라고 입력해 보자. 여기서 telent은
임의의 서버와 텍스트를 주고 받을 수 있는 프로그램이며 웹 서버가 80번 포트에서 동작하기
때문에 맨 마지막에 80번이라고 입력을 해 주었다.
[그림 1-3] 네이버 웹 서버 접속 모습
위와 같은 명령을 타이핑 한 후 엔터를 입력하면 곧바로 화면이 바뀌면서 아무것도 안보이고
커서만 하나가 깜박이게 된다. 이 때 “GET /index.html HTTP/1.0" 이라고 입력해 보자. 주
의할 것은 이 헤더 명령을 타이핑하더라도 화면에는 안 보인다는 것이다5). 타이핑을 한 후 엔
터를 두 번 입력6)하면 아래와 같이 네이버의 첫 화면에 해당하는 HTML 소스가 화면에 출력
되게 된다.
[그림 1-4] 네이버 첫 화면의 HTML 소스
지금까지 수행한 내용은 웹 브라우저에서 "http://www.naver.com"이라는 주소를 입력 한
후 엔터를 입력했을 때 브라우저에서 일어나는 일과 같다. 다만 브라우저는 전달받은 HTML
소스를 해석하여 폰트의 사이즈 및 색상을 조정하고 이미지 처리 등을 수행하는 점이 다르다.
5) 리눅스에서 수행하면 타이핑하는 내용이 나타난다.
6) 엔터를 두 번 입력하는 이유는 헤더 정보 이후 곧바로 빈 줄의 효과를 주기 위해서이다.
1.2 웹 프로그래밍과 동적 웹 페이지
1.2.1 정적 웹페이지의 한계
인터넷상에는 많은 정적 웹 페이지들이 산재해 있다. 정적 웹 페이지는 확장자가 .htm 이나
.html 들로 구성된 페이지이다. 이것들을 정적(static)이라고 하는 이유는 임의의 사용자가 이
페이지를 가져와서 브라우저상에 보기 전에 이미 그 페이지의 모든 내용이 정해져 있기 때문
이다. 이 페이지의 모습은 이것을 보는 사용자의 장소, 시간 및 환경에 관계없이 항상 동일하
다.
예를 들어 다음과 같은 welcome.html이라는 HTML 문서가 있다고 가정해보자.
0 10 20 30 40 50 60 70 80 91 01 11 21 31 41 51 6
< h tm l>< h e ad > < t it le > 내 홈 페 이 지 < /t it le > < /h e ad >< b o d y>< tab le b o rd e r= '0 '>< tr> < td > < h 1 > 내 홈 페 이 지 < /h 1> < / td >< /tr>< tr> < td > < h 4> 환 영 합 니 다 !< /h 4 > < h 5> 정 적 웹 페 이 지 입 니 다 .< /h 5 > < / td >< /tr>< / ta b le>< /b o d y>< /h tm l>
[예제 1.1 - Tomcat 설치 폴더\webapps\jspbook\ch01\welcome.html]
모든 사용자는 이 페이지를 볼 때마다 항상 다음 [그림 1-5]와 같은 내용을 보게 된다. 이 내
용은 사용자가 내용을 보기 전에 이미 정해져 있는 것이다.
[그림 1-5] 정적 웹 페이지 수행 모습
초창기 웹이 출현했을 때에는 이러한 정적 웹 페이지로도 그 의미 전달을 충분히 할 수 있었
다. 하지만 만약 HTML을 브라우저에 보여줄 때 오늘의 날짜와 현재 시각을 보여주고 싶다
고 하면 이것은 정적인 웹 페이지로 구현할 수 없다. 웹 브라우저의 사용자가 서버에 저장된
페이지를 요청하는 시각을 미리 알 수가 없기 때문이다. 정적인 웹 페이지로는 항상 동일한
날짜 및 시간만을 보여줄 수밖에 없다. 이밖에도 방명록, 게시판 및 블로그 등을 웹 페이지로
서 제작하려면 정적 웹 페이지로는 그 한계가 있을 수밖에 없고 동적 웹페이지가 필요하다.
1.2.2 동적 웹 페이지
우선 동적 (dynamic) 웹 페이지의 한 예를 보자.
0 10 20 30 40 50 60 70 80 91 01 11 21 31 41 51 61 7
< % @ p a g e co n te n tT yp e = " te x t/h tm l; c h a rse t= eu c -k r" % >< h tm l>< h e ad > < t it le > 내 홈 페 이 지 < /t it le > < /h e ad >< b o d y>< tab le b o rd e r= '0 '>< tr> < td > < h 1 > 내 홈 페 이 지 < /h 1> < / td >< /tr>< tr> < td > < % = “< h 4 > 환 영 합 니 다 !< /h 4 > ” % > < % o u t .p r in t ln ("< h 5 > 동 적 웹 페 이 지 입 니 다 .< /h 5 > " ) ; % > < / td >< /tr>< / ta b le>< /b o d y>< /h tm l>
[예제 1.2 - Tomcat 설치 폴더\webapps\jspbook\ch01\welcome.jsp]
몇 가지 새로운 코딩모습이 보이지만 이후에 학습하고 여기서는 표준 HTML 외에 다른 프로
그래밍 방식이 사용되고 있다는 내용 정도만 이해하자. [그림 1-6]은 위 동적 웹 페이지의 수
행 모습이다.
[그림 1-6] 동적 웹 페이지 수행 모습
동적 웹 페이지는 사용자가 페이지를 요청하는 시점에 그 페이지를 새롭게 구성하는 행위를
한다. 그러므로 동적 웹 페이지에는 HTML 소스를 만들어내는 코딩이 들어가게 된다. 본 책
에서 배우게 될 JSP가 HTML 페이지를 브라우저로 보내기 전에 프로그램을 통해 그 보내질
HTML 페이지를 새롭게 생성할 수 있게 하는 스크립팅 기술이다. JSP는 일종의 프로그래밍
언어라기보다는 기존의 Java 언어를 사용하여 일정한 형식에 따라 웹 페이지를 동적으로 구
성할 수 있는 새로운 도구이다.
[그림 1-7] 정적 웹 페이지와 동적 웹 페이지의 수행 방식 비교
[그림 1-7]와 같이 JSP와 같은 동적 웹 페이지를 처리하기 위해서는 웹서버 뒤에서 JSP 스크
립트 엔진을 포함하는 케이션 서버 (Application Server)가 반드시 있어야 한다. 이러한 케이
션 서버는 JSP 스크립트를 HTML으로 변환하는 기술 및 게시판의 글 목록 및 로그인 처리
와 같은 여러 가지 로직 (Logic) 처리를 수행한다. 이러한 로직을 효율적으로 처리하기 위해
서는 여러 가지 정보를 체계적으로 관리하는 데이터베이스 (Database)를 활용한다. [그림
1-7]에도 나와 있듯이 주목해야 하는 것은 사용자의 브라우저에서는 요청하는 문서가 정적인
HTML이나 동적인 JSP 모두 항상 순수 HTML 문서만을 받는 다는 것이다.
한편 동적 웹 페이지를 구성하는 다른 기술로서 클라이언트 측 스크립팅 기술이 있다. 이는
서버 측에서는 아무런 처리 없이 요청하는 파일을 그대로 브라우저로 주고 브라우저가 그 파
일 내에 있는 스크립트 언어를 해석하여 페이지 자체를 동적으로 만들어 주는 기술이다. 클라
이언트 측 스크립팅 기술로는 자바스크립트(JavaScript) 및 Dynamic HTML, 그리고 Flash
와 관련된 Actionscript 등이 있다.
1.2.3 전통적인 CGI 방식의 동적 웹 페이지 작성 기술
CGI (Common Gateway Interface)는 과거에 동적 웹 페이지를 개발하기 위하여 사용된 기
술이다. CGI 자체는 정식 프로그래밍 언어나 스크립트가 아니라 웹 서버와 서버에서 수행중
인 일반 프로세스 사이에 정보를 주고받는 규칙을 의미한다. 그래서, CGI는 주로 Perl, C,
C++ 등의 언어를 지원하면서 웹 서버를 통해서 요청을 받고 실행 결과를 다시 웹 서버를 거
쳐 클라이언트의 브라우저로 보낼 수 있는 기능을 지닌다. 그러나 지금은 CGI가 거의 사용되
지 않기 때문에 자세히 그 원리와 방법을 알 필요는 없다. 그러나, 최근의 동적 웹 페이지 작
성 기술의 원리를 올바르게 이해하는 차원에서 전통적인 CGI 방식의 동적 웹 페이지 작성 기
술을 간략하게 알아볼 필요가 있다.
전통적인 CGI 방식은 [그림 1-8]과 같이 웹 서버가 직접 Perl, C, C++로 만들어진 어플리케
이션 프로그램을 호출하여 개별 프로세스를 생성한다는 점이 중요하다7). 즉, 웹 서버는 웹 브
라우저가 요청한 CGI 실행을 직접 해당 프로그램을 호출하여 프로세스를 생성한 후 수행 결
과를 다시 웹 브라우저로 전송한다. 그림에서 요청 URL의 마지막에 cgi로 끝나고 있음을 유
의하자.
[그림 1-8] 전통적인 CGI 방식의 웹 요청 처리 방식
CGI 방식의 근본적인 문제점은 각각의 클라이언트 요청에 대하여 독립적인 별도의 프로세스
가 생성된다는 점에 있다. 프로세스가 많아진다는 것은 그 만큼 시스템에 많은 작업 부하를
주는 요인이 된다. 예를 들어, [그림 1-9]와 같이 거의 같은 시간에 5개의 웹 브라우저가 똑같
은 URL을 통하여 동일한 CGI 실행을 요청한다고 가정해 보자. 이러한 경우 웹 서버는 웹 브
라우저에서의 요청 개수만큼 동일한 시간에 같은 프로세스를 생성한다. 또한, 이러한 프로세
스는 서버의 메모리를 점유하기 때문에 요청이 더 많아질수록 메모리 요구량도 비례적으로 많
아짐을 의미한다.
[그림 1-9] 중복된 같은 요청에 대한 CGI의 대처 방법
다른 문제점은 C언어를 이용하여 CGI 프로그램을 작성한 경우 프로그램이 운영되는 OS
(Operating System)에 종속되어서 윈도우즈에서 개발된 CGI 프로그램을 리눅스나 유닉스에
7) 프로세스 (Process)는 실제 수행중인 프로그램 (Program)을 의미한다. 즉, 프로그램은 정적인 의미로서 하드디스크에 저
장되어 있는 명령어들의 집합이라고 보면 프로세스는 실제 메모리 자원을 할당받아서 CPU에 의하여 스케줄링되어 활성적
으로 수행이 되고 있는 개체라고 정의된다.
서 바로 사용할 수 없는 문제가 있다. 따라서 개발이 어렵고 유지보수가 힘들다.
1.2.4 어플리케이션 서버 방식의 동적 웹 페이지 작성 기술
어플리케이션 서버 방식은 CGI 방식과 다르게 웹 서버가 직접 관련 프로그램을 호출하기 보
다는 [그림 1-10]처럼 어플리케이션 서버를 통하여 간접적으로 관련 스크립트를 호출하여 수
행한다. 수행된 결과는 다시 웹 서버로 전달이 되며 다시 웹 서버는 이러한 결과를 웹 브라우
저로 전송한다. 오늘날의 다음이나 네이버 등 웹 어플리케이션 (Web Application)은 이와 같
은 어플리케이션 서버 방식으로 구축되어져 있다. 본 교재에서 활용하는 톰캣(Tomcat) 도구
가 바로 JSP 스크립트 엔진을 포함하는 어플리케이션 서버의 대표적인 소프트웨어이다.
[그림 1-10] 어플리케이션 서버 방식의 웹 요청 처리 방식
이러한 어플리케이션 서버 방식에서는 다수의 웹 브라우저가 같은 요청을 하더라도 어플리케
이션 서버는 관련된 스크립트에 대한 프로세스를 하나만 수행한다. [그림 1-11]과 같이 동시
에 5개의 동일한 요청을 한다고 해도 단지 하나의 프로세스에 해당하는 메모리만 사용하기 때
문에 CGI 방식에 비하여 CPU 점유도나 메모리 점유도에 있어서 상당히 효율적이다. 이러한
자원 활용면에서 효율성이 높다는 것은 더 많은 웹 브라우저의 요청을 처리할 수 있다는 것을
의미하며 이는 곧 안정적인 웹 서비스를 제공할 수 있는 기반이 된다.
[그림 1-11] 중복된 같은 요청에 대한 어플리케이션 서버 방식의 대처 방법
여기서 간과할 수 없는 것은 각 웹 요청에 대해서 어플리케이션 서버는 쓰레드 (Thread)로서
처리한다는 점이다8). 즉, 실제 프로그램 수행은 프로세스를 생성하여 메모리에 띄어 놓고 각
요청에 대한 쓰레드를 새로 생성하여 프로세스를 한 번씩 지나게 하여 원하는 응답을 얻어내
는 기법을 활용하고 있다.
8) 쓰레드는 LightWeight Process(LWP)라고 하며 CPU를 활용하는 작은 기본단위이다. 여러 개의 프로세스를 동시에 수행
시키는 것보다 여러 개의 쓰레드를 동시에 수행시키는 것이 CPU 활용 면이나 메모리 점유면에서 훨씬 효율적이고 그 처리
율이 높다.
1.3 스크립팅(Scripting) 기술
1.3.1 컴파일 코드 방식 vs. 스크립팅 코드 방식
동적 웹 페이지를 구현하는 방식은 크게 컴파일 코드 방식과 스크립팅 코드 방식으로 나눌 수
있다. 이 두 가지 방식의 차이점은 다음 [표 1-1]과 같다.
컴파일 코드 방식 스크립팅 코드 방식
종류CGI 관련 프로그램인 Perl, C, C++과 서블릿 프로그램
JSP, PHP, ASP
코드 형태컴파일된 기계어코드 (BinaryCode) 또는 바이트코드 (ByteCode)
컴파일되기 전 상태인 일반적인 스크립트 코드
컴파일방법
코드 구현 이후 컴파일과정을 직접수행해야 함
코드 구현 이후 컴파일과정은 웹 요청시 자동으로 수행됨
코드 변경 코드를 직접 다시 재컴파일해야 함스크립트 내에서 코드를 수정만 하면되며 재컴파일은 웹 요청 시 자동으로수행됨
컴파일 코드 방식과 스크립트 코드 방식의 가장 큰 차이점은 컴파일 코드 방식은 프로그래머
가 직접 코드를 컴파일해야 해야 하고 스크립트 코드 방식은 프로그래머는 소스 코딩만 하고
컴파일은 실제 웹 요청이 발생할 때 어플리케이션 서버가 자동으로 행한다는 점이다. 그러므
로, 개발과정에서 코딩을 어느 정도 수행한 후 웹 요청을 하여 실행 결과를 본 후 고쳐야 할
점을 발견하여 재코딩을 수행하게 되면 컴파일 코드 방식은 다시 또 컴파일을 해야 하는 번거
로움이 있다. 하지만 스크립트 코딩 방식은 단순히 소스 코드에서만 재코딩을 해주면 된다. 이
후 다시 웹 요청을 하게 되면 그 때 컴파일이 자동으로 다시 수행된다.
[그림 1-12] 컴파일 코드 방식과 스크립팅 코드 방식의 차이
1.3.2 서버 측 스크립팅 기술
▣ ASP
ASP(Active Server Page)는 마이크로소프트(Microsoft)사에서 1996년 7월 16일에 데날리
(Denali)라는 코드명으로 공식적으로 발표되었다. 이후 베타 버전은 1996년 11월에 발표되었
고, 1996년 12월 12일에 ASP 버전 1.0이 배포되었다. ASP는 베이직 (Visual Basic)과 유사
한 구문을 갖고 있는 VBScript를 이용해서 매우 쉽게 배우고 사용할 수 있다. 일반적으로 회
사에서 비쥬얼베이직에 익숙한 프로그래머는 어렵지 않게 찾을 수 있기 때문에 ASP 기반의
웹 사이트를 유지하는 것은 그리 어렵지 않다.
ASP의 가장 뛰어난 장점은 COM 객체를 이용하고 있다는 것이다. 즉, 비쥬얼베이직이나 비
쥬얼 C++에서 사용하던 강력한 COM 객체들을 ASP 페이지에서도 똑같이 사용할 수 있다.
또한, ASP 페이지에서 사용할 수 있는 COM 객체를 쉽게 만들어 낼 수 있다. 기존에 이미 개
발되어 있는 COM 객체를 활용함으로써, 개발자들은 필요한 프로그램을 코딩하는 시간을 대
폭 줄일 수 있다. 가령, 마이크로소프트의 IIS(Internet Information Server)와 ASP를 인스
톨 해 두었다면 기본적으로 제공되는 "ad rotator"같은 무척 유용한 COM 객체를 바로 활용
할 수 있다. "ad rotator"는 배너 광고를 무작위로 돌려가며 보여주는 기능을 지닌다. 즉,
ASP 개발자는 IIS를 인스톨하는 것만으로 딱 두 줄의 코딩을 한 ASP 페이지를 이용해서 여
러 배너를 무작위로 보여줄 수 있다.
최근 윈도우즈 개발환경이 닷넷 (.NET) 플랫폼으로 변화하면서 ASP도 ASP.NET이라는 이
름으로 바뀌어서 보다 강력한 기능을 제공하고 있다. 하지만, ASP를 사용하면 결국 마이크로
소프트에서 개발한 운영 체제 및 개발 환경에 종속이 될 수밖에 없다. 만약 중소기업에서 웹
사이트를 운영한다고 할 때 값비싼 마이크로소프트 계열 운영 체제 및 데이터베이스와 통합
개발 환경을 사용한다고 하면 그 비용이 만만치 않을 것이다.
▣ PHP
PHP(Professional Hypertext Preprocessor)는 윈도우즈 운영체제에서도 동작이 가능하지
만 Unix 및 Linux 운영체제에서 가장 빠르게 동작하는 웹 사이트를 구성할 수 있는 도구로서
인정받고 있다. 특히, PHP는 오픈소스 모델로 개발되는 언어이기 때문에 다양한 운영 체제와
웹 서버 환경에서 운영될 수 있도록 포팅이 잘 되어 있다.
PHP는 언어의 스타일이나 구문을 여러 언어로부터 차용해 와서 만들어진 언어라서 일반적인
프로그래밍 언어로 코딩을 하던 사람이라면 쉽게 PHP를 이용해서 웹 기반 어플리케이션을
만들 수 있다. 또한 PHP가 오픈소스 모델을 통해 발전해 가고 있다는 말은 PHP에 부가적으
로 다른 기능을 첨가하는 것이 컴파일 한 번으로 쉽게 가능하다. 이는 곧 ASP에 COM 객체
가 제공하는 기능과 비슷하지만 PHP 소스 코드에 필요로 하는 기능을 직접 첨가하는 것처럼
쉽지는 않다. 그래서, PHP는 소규모 개발자들에게 매우 쉽게 접근할 수 있는 도구가 된다.
PHP가 갖고 있는 가장 큰 매력은 가볍고 사용하기 쉽다는 것이다. 일반적으로 리눅스를 사용
하는 PC에 간단히 서버로서 환경을 세팅을 하게 되면 Apache 웹 서버에서 쉽게 PHP 코딩
환경이 마련된다. PHP는 Sybase, Oracle, Informix, Solid, Postgres, 심지어 MS-SQL까지
지원하는 풍부한 DB 지원 기능을 제공한다.
하지만, 일반적인 프로그래밍 언어가 가지고 있는 풍부한 기능이 부족한 편이다. 가령, 객체지
향 (Object-oriented) 프로그래밍 언어가 가지고 있는 캡슐화, 상속성, 재사용성, 모듈화 특성
이 PHP는 잘 구현되어 있지 않다. 그래서, 은행, 대학, 관공서 등의 웹 사이트와 같이 중대형
급 규모에서는 잘 사용되지 않는다.
▣ JSP
JSP(Java Server Page)는 썬 마이크로시스템즈(Sun Microsystems)에서 개발한 Java 언
어 기반의 웹 스크립트 언어이다. 원래 JSP가 나오기 전에 썬 마이크로시스템즈에서는 서블
릿(Servlet) 기술을 먼저 개발하여 동적 웹 페이지 코딩을 지원했다. 하지만 서블릿은 여전히
컴파일 코드 방식을 따라야 하기 때문에 웹 개발자 입장에서는 불편한 점이 많았다. 그래서
바로 연달아 JSP 기술을 개발하여 뛰어난 스크립팅 기반의 웹 프로그래밍을 지원하게 되었다.
무엇보다도 JSP의 장점은 Java라는 훌륭한 객체지향 언어의 여러 가지 기능을 지원받는 점이
다. 즉, 여러 가지 운영 체제 및 웹 서버로 포팅이 쉽고, 멀티쓰레딩(Multithreading), 광범위
한 클래스 라이브러리(Class libraries), 객체 지향적 코딩, 확실하고 풍부한 보안, 언어 자체
가 갖는 우아함 등의 장점을 JSP도 그대로 가지고 있다.
Java 언어가 C나 C++ 보다 다소 느리다는 평가가 있기 때문에 JSP도 ASP나 PHP보다 느
리게 동작한다고 생각할 수 있다. 하지만, JSP는 최초 요청시에 서블릿으로 컴파일 되고 서블
릿은 다시 메모리에 매우 컴팩트 (Compact) 하게 적재된다. 이후의 요청 시에는 이러한 일련
의 과정이 모두 생략되고 메모리에 적재된 서블릿 코드에서 바로 응답이 가능하다. 그래서, 그
성능 또한 매우 띄어나며 사용자가 증가해도 전체 처리 효율면에서도 좋은 평가를 받고 있다.
한편, JSP는 중대형 웹 사이트를 개발할 때 많이 활용되는 데 그 이유는 코드의 유지관리 보
수 측면에 많은 강점이 있기 때문이다. 본 교재 뒤에서 설명할 MVC (Model-View-Controll
er) 모델을 Java로 쉽게 구현이 가능하기 때문에 이 모델을 활용하여 대형 프로젝트를 수월하
게 관리하며 웹 프로그래밍을 할 수 있다. 게다가 Java 언어 자체가 가지고 있는 여러 클래스
라이브러리를 활용할 수 있다는 점은 많은 웹 프로그래머가 JSP를 선택하는 이유 중 하나이
다.
1.3.3 클라이언트 측 스크립팅 기술
서버 측 스크립팅 기술은 웹 서버 내에 코딩해 놓은 파일을 서버 측에서 동작하는 어플리케이
션 서버가 직접 처리하여 그 결과를 브라우저로 보내주는 기술인 반면에 클라이언트 측 스크
립팅 기술은 서버 측에서 아무런 처리 없이 요청하는 파일을 그대로 브라우저로 주고 브라우
저가 그 파일 내에 있는 스크립트 언어를 해석하여 페이지 자체를 동적으로 만들어 주는 기술
이다. 클라이언트 측 스크립트 언어로는 자바스크립트(JavaScript) 및 DHTML(Dynamic H
TML), 그리고 Flash 와 관련된 Actionscript 등이 있다.
자바스크립트는 객체 기반의 스크립트 프로그래밍 언어이다. 자바스크립트는 원래 넷스케이프
커뮤니케이션즈 회사의 브렌단 아이히(Brendan Eich)에 의해 처음에는 모카(Mocha)라는 이
름으로, 나중에는 라이브스크립트(LiveScript)라는 이름으로 개발되었으며, 최종적으로 자바
스크립트라는 이름으로 되었다. 자바스크립트가 Java와 그 문법이 유사한 점도 있지만 이는
사실 두 언어 모두 C 언어의 기본 구문을 바탕으로 했기 때문이고 자바와 자바스크립트는 직
접적인 관련성이 없다.
웹 페이지를 동적으로 만들어 주는 클라이언트 측 스크립트 언어로서 자바스크립트의 성공에
자극 받은 마이크로소프트는 JScript로 알려진 호환 언어를 개발하게 되었다. JScript는 1996
년 8월에 출시된 인터넷 익스플로러 브라우저 3.0부터 지원되기 시작했다. 그러므로 인터넷
익스플로러 브라우저의 자바스크립트 사용은 실제로 JScript의 사용을 의미하는 것이다. 그래
서, 자바스크립트가 인터넷 익스플로러나 파이어폭스에서 모두 지원된다고는 하지만 자바스크
립트는 브라우저 마다 지원하는 방식이 약간씩 차이가 있어서 실제 웹 사이트 개발 시에는 이
러한 브라우저 간의 차이점을 잘 고려하며 자바스크립트 코딩을 해야 한다.
한편, DHTML(Dynamic HTML; 동적 HTML)은 정적 마크업 언어인 HTML과 자바스크
립트 같은 클라이언트 측 스크립트 언어 그리고 스타일 정의 언어인 CSS(Cascading Style
Sheet)를 조합하여 동적 또는 대화형 웹 사이트를 제작하는 기법을 의미한다. DHTML은 예
를 들어 간편한 네비게이션을 위해 대화형 폼(form)을 제작하거나, 전자 학습에 사용되는 대
화형 실습장을 만드는데 이용될 수 있다.
본 교재에서는 이와 같은 클라이언트 측 스크립트 언어에 대해서는 특별하게 다루지 않는다.
다만 실습 예제에서 가끔 자바스크립트를 활용하여 적절한 기능을 추가할 수 있다. 그러한 예
제가 나오게 되면 자세한 설명과 함께 자바스크립트의 해당 기능을 설명할 예정이다. 본 교재
에서 다루지 않는다고 할지라도 최근 Web 2.0의 패러다임을 실현하기 위해서 클라이언트 측
스크립팅 기술의 중요성이 크게 부각되고 있기 때문에 적절한 학습이 요구된다. 특히 Ajax(A
synchronous JavaScript and XML)를 활용하여 사용자와의 상호작용을 좀 더 효율적이고
동적이게 만들어 주는 기술은 Web 2.0 시대의 필수 웹 기술로서 떠오르고 있다.
1.4 왜 JSP 인가?
JSP는 동적인 웹 컨텐츠를 생성하는 가장 좋은 기술로서 오랫동안 평이 나있다. 그렇다면 왜
JSP인가? 이러한 질문에 대해 우선 JSP는 강력한 언어인 Java를 기반으로 하기 때문이라고
답할 수 있다. Java는 “한번 작성한 프로그램은 어디에서나 실행이 가능하다. (Write once
run anywhere)”라는 모토를 지니고 있다. 이러한 특징이 바로 JSP에 바로 적용이 되어서 어
떠한 운영체제에서도 JSP는 활용이 가능하다. 이후 계속해서 JSP의 장점을 살펴보자.
1.4.1 Java의 강력한 컴퓨팅 플랫폼 기술 활용
Java는 1995년 Sun Microsystems에서 처음 개발된 이후 가장 빠른 시간 내에 가장 많은 프
로그래머를 확보한 언어이다. 그 이유는 Java는 현재 단순한 언어가 아닌 복합적으로 다양한
용도의 솔루션을 효율적으로 지원하는 플랫폼(platform)이기 때문이다. 여기서 플랫폼이란 소
프트웨어가 수행되는 일종의 멍석을 지칭하는 것으로서 자바는 작은 임베디드 하드웨어에 올
라가는 컴퓨팅 플랫폼을 마련해주기도 하고 기업형 서버나 슈퍼컴퓨터에 올라가는 고성능 컴
퓨팅 플랫폼을 지원하기도 한다. 컴퓨팅 플랫폼으로서의 Java는 위키피디아(wikipedia) 웹
사이트인 http://en.wikipedia.org/wiki/Java_Platform#Platform에 더 많은 설명이 나오며
[그림 1-13]은 상기 위키페디아 사이트에서 소개된 Java의 컴퓨팅 플랫폼 모습이다.
[그림 1-13] Java의 컴퓨팅 플랫폼
Java가 이와 같이 아주 강력한 컴퓨팅 플랫폼으로서 인식이 되고 있기 때문에 Java를 기반으
로 하는 JSP 역시 자바가 제공하는 모든 기술을 서버 측에서 동적인 웹페이지를 구축 하는데
활용할 수 있는 장점을 가지게 된다. 그래서 복잡한 업무지향형 (business oriented) 웹 어플
리케이션에서 다양한 고객 및 사용자의 요구를 효율적으로 반영하기 위해서는 JSP와 함께
Java가 기존에 지니고 있는 강력한 플랫폼 기술을 함께 적용해야 목적하는 바를 손쉽고도 효
과적으로 이룰 수 있다.
1.4.2 프리젠테이션 로직과 비즈니스 로직의 분리
브라우저 화면에서의 표현을 꾸미는 절차 및 기능을 프리젠테이션 로직(Presentation Logic)
이라고 하며 사용자의 요청에 대한 내부적인 처리 절차 및 기능을 비즈니스 로직(Business
Logic)이라고 한다. 예를 들어 쇼핑 사이트에서 각 물건 아이템들을 가로방향으로 배치할 것
인지 세로방향으로 배치할 것인지에 관한 결정은 프리젠테이션 로직과 관련된 것이며 사용자
가 어떤 물건을 구매할 때 신용카드 처리와 연관된 모든 절차는 비즈니스 로직과 관련되어 있
다. JSP는 이러한 프리젠테이션 로직과 비즈니스 로직을 효율적으로 분리하여 동적 웹 사이
트를 구축할 수 있는 훌륭한 스크립트이다. 특히 비즈니스 로직은 자바빈즈 (Javabeans) 컴
포넌트 모델을 통하여 구현할 수 있다.
이러한 프리젠테이션 로직과 비즈니스 로직을 분리하는 것이 왜 중요한가? 그 이유는 이 두
가지를 분리함으로써 웹페이지의 디자인이 변경되더라도 내부 비즈니스 로직을 처리하는
JSP 및 자바빈즈(Javabeans) 코드를 변경할 필요가 없기 때문이다. 반대로 결제 시스템 변경
과 같은 비즈니스 로직이 완전히 바뀌는 상황이라도 프리젠테이션 로직을 담당하는 코드에는
전혀 영향을 미치지 않기 때문이다.
프리젠테이션 로직과 비즈니스 로직의 분리와 관련하여 MVC (Model-View-Controller) 모
델을 통한 JSP (프리젠테이션 로직 View)-자바빈즈 (비즈니스로직, Model)-서블릿
(Controller)의 연계가 가능한데 이에 대해서는 12장에서 심도있게 다루도록 하겠다.
1.4.3 컴포넌트의 재사용
컴포넌트의 재사용은 위에서 설명한 프리젠테이션 로직과 비즈니스 로직의 분리에 의하여 발
생되는 부수적인 효과이다. 컴포넌트 (Component) 재사용이란 많은 JSP 페이지나 자바빈즈
에서 공통적으로 사용되는 컴포넌트를 만들어 이 컴포넌트를 계속해서 재사용을 한다는 의미
이다. 예를 들어 주소 검색 기능, 한글 처리 기능, 데이터베이스 연결 기능 등을 공통 컴포넌트
로 개발하여 동적 웹 사이트를 개발을 좀 더 편리하게 할 수 있다.
1.4.4 JSTL, EL, 커스텀 태그 등을 활용한 개발 용이성
JSP는 기본적인 스크립팅 언어 규칙외에도 HTML 태그처럼 사용이 가능한 JSTL (Java
Standard Tag Library)를 제공하고 있으며 이와 함께 융통성 있고 손쉽게 사용이 가능한
EL (Expression Language)를 정의하고 있다. 또한 개발자가 임의로 새롭게 태그를 만들어
사용하도록 하는 커스텀 태그 (Custom Tag) 기능을 지원한다. 이러한 기능들은 모두 개발을
용이하게 하고 동적 웹 사이트 개발시간을 대폭적으로 단축시켜주는 용도로 활용이 가능하다.
1.4.5 서버 자원의 효율적 관리
CGI 방식이 워낙 오래된 방식이라 이것과 JSP를 비교하는 것은 사실 큰 의미는 없지만 JSP
의 동작 원리와 관련하여 잠깐 이 사항도 다시 살펴보자. 기존의 CGI는 요청이 들어올 때 마
다 새로운 CGI 프로세스를 생성하고 이렇게 생성된 프로세스의 수행 결과를 브라우저로 넘겨
주고 다시 해당 프로세스는 종료가 된다. 이는 거의 동시에 들어오는 여러 사용자들의 요청에
대해 모두 새로운 프로세스가 생성되어야 함을 의미하는 것이다. 즉, CGI 방식은 서버 자원을
효율적으로 활용하지 못한다.
반면에 JSP는 최초 요청 시에 해당 페이지에 대해 컴파일을 통하여 서블릿이 구성되고 메모
리로 적재가 된다. 이후 요청들에 대해서는 새로운 컴파일 생성 및 메모리 적재 없이 이미 적
재되어 있는 서블릿에서 바로 응답을 해주기 때문에 서버의 자원을 효율적으로 활용하면서 동
시에 응답속도도 상당히 빠르다.
응답속도 면에서 Java가 다른 언어들에 비해서 다소 느리다는 평이 나있기는 하지만 이미 메
모리에 적재되어있는 상태에서 응답을 해주기 때문에 다른 언어에 비해 느리게 처리되는 편이
아니다. 사실, 웹 사이트의 응답 속도는 언어 자체의 영향 보다는 서버의 관리 기술 및 로직
처리의 적정성 및 효율성에 더 많은 의존도가 있다.
[Note: Java EE, Servlet, JSP는 어떤 관계에 있는가?]
JSP/Servlet 컨테이너 이외에 흔히 접하게 되는 용어로 웹 어플리케이션 서
버라는 것이 있다. 웹 어플리케이션 서버는 기업의 기간 정보 시스템과 웹 서
비스 사이에 위치하는 일종의 미들웨어로, 트렌젝션 관리를 비롯해 다른 시스
템간의 연동을 위한 솔루션을 제공해준다.
일반적으로 웹 어플리케이션 서버는 기본적으로 Java EE를 지원하는 서버
소프트웨어들을 일컫는다. 웹 어플리케이션 서버가 지원하는 Java EE는 기
본적으로 Servlet과 JSP를 실행할 수 있으며 EJB (Enterprise JavaBeans)
를 포함하는 거대한 솔루션으로 기업 정보 시스템 구축에 필요한 기능을 제공
한다.
이들 웹 어플리케이션 서버들은 단순한 Java EE 지원 이외에 시스템 장애
및 대규모 사용자 접속 등에서 성능을 보장하기 위한 클러스터링 및 결함포용
(Fault Tolerance), 트랜잭션, 보다 안정적이고 신속한 데이터베이스 처리를
위한 다양한 관리 기능을 제공한다.