펄(Perl), ASP, PHP, JSP 비교 : Server Side Scripting Languages

웹 프로그래밍에서 많이 쓰이는 서버 사이드 스크립팅 언어 비교

webmonkey.com 글 번역입니다

2000-4-9

펄(Perl)이 최고다

웹 프로그래머가 원하는 것은 고객이 원하는 것을 최상으로 해낼 수 있는 툴입니다. 가급적 빠른 시간내에 필요한 작업을 완성하는 것입니다. 물론 안정적이어야 하고 적은 비용만으로 해내길 바랍니다. 또, 무엇인가 바꿔야 할 필요가 있을 때 쉽게 바꿀 수 있기를 원합니다. 왜냐하면 실제 코딩이 시작되기 전까지 어떤 프로젝트의 세부 요구사항들이 확실하게 알려지지 않는 경우가 많기 때문입니다. 그리고 고객은 빠른 속도로 발전해 나가고 있는 미래의 컴퓨팅 환경에 맞게 잘 업그레이드되는 것을 원합니다.

 

 

개발자로서 원하는 것은 이렇습니다. 개발자는 기술적 한계에 갖혀서 일하기는 싫습니다. 창조성을 마음껏 발휘하면서 솔루션을 만들고 싶고 다른 사람이 만들어 놓은 산더미 같은 요구사항에 허덕거리기를 원치 않습니다. 그래서 펄을 선택했습니다. 물론 mod_perl을 이용한 아파치 웹 서버와 함께. 하이엔드 오픈소스 조합입니다.

펄과 관련해서 몇가지 논란이 있었습니다. 결론은 펄이 최고라는 것으로 판명이 되었지만요.

 

우선 펄을 웹프로그래밍 언어로 쓰기에 적합한가라는 문제제기가 있었습니다. 분명히 다른 웹 프로그래밍 언어들 모두 각자 영역을 확보할 가치가 있습니다. 저는 PHP의 우수성에 대해서 충분히 공감하고 있으며, 왜 사람들이 PHP를 선택하는지 충분히 이해합니다. ColdFusion이 Window NT 머쉰에서 웹 프로그래밍을 하는 것 같은 악조건에서 최고의 대안이라는 사실 역시 부인하지 않습니다. 또한 VBScript와 ASP를 활용하면 이미 잘 알고 있는 비쥬얼 베이직 지식을 지렛대로 활용할 수 있다는 것도 사실입니다. 하지만 정말 본격적으로 웹 프로그래밍을 하려면 펄이 유일한 대안입니다.

 

펄은 파워풀하고 모든 기능이 완비되어 있는 고급 언어로 프로그래밍도 쉽습니다. 배우는 과정이 그렇게 까다롭지 않습니다 꼭 전문가만 펄을 사용하는 것이 아닙니다.

 

펄은 텍스트 프로세싱에 있어 (예를들어 http의 헤더를 만든다든지, html 작성을 자동화한다든지) 독보적 강점을 갖고 있습니다. 더욱 중요한 것은 바로 그 텍스트 프로세싱이야말로 웹 프로그래밍의 본질이란 점입니다.

 

펄을 써서 여러가지 프로그램을 만들고, 심지어 시스템 전체를 만들어 낼 수도 있습니다. 그것도 매우 빠르게. 펄은 웹 프로그래머 사이에서 광범위하게 쓰이고 있기 때문에 유용한 코드가 이미 준비되어 있습니다. 그냥 가져다 쓰기만 하면 됩니다.

 

웹 프로그래밍이 항상 웹만을 대상으로 한 것은 아니라는 사실도 잊어서는 안됩니다. 웹 시스템은 대단히 많은 백엔드 프로세스가 총체적으로 맞물려 있습니다. 펄의 CPAN에는 어떤 상황이 닥치더라도 해결해 낼 수 있는 다양한 모듈이 갖춰져 있습니다. 웹과 데이타베이스를 연동하려 할 때도 펄의 DBI module을 손쉽게 사용할 수 있습니다. 게다가 펄은 오픈소스입니다. 수많은 사람들이 테스트한 뒤에도 살아남은 것입니다.

 

펄은 여러분에게 무한한 자유와 편안함을 줍니다. 관련 회사가 어느날 갑자기 기술지원을 없애버리는 일은 결코 일어날 수 없기 때문입니다. 펄이 웹 프로그래밍에 적절히 사용될 수 있다면 계속 발전해 갈 것이고 펄 사용자들에 의한 공개적 지원 네트웍이 더욱 커져갈 것입니다. 그래서 더욱 많은 사람들이 펄을 선택하게 되면 이는 다시 더 많은 사람들에 의한 기술지원을 만들어 내고 더 많은 사람들이 펄을 선택하게 됩니다. 상당히 괜챦은 사이클 아닙니까?

 

만약 펄이 웹 언어 전쟁에서 승리하고 아파치가 웹 서버 경쟁에서 활발하게 활동한다면 다른 것들은 무너질 것입니다. 그렇게 될 수밖에 없습니다. 왜냐하면, 아파치야말로 웹 마스터들을 위한, 웹 마스터들에 의해 만들어진 웹 서버이기 때문입니다. 웹 마스터 자신 이상으로 웹 마스터가 무엇을 원하는 지 더 잘 알 수 없습니다. 아파치는 깔끔하게 완성되어 있고 제대로 동작하고, 풍부한 기능으로 가득 차 있고 설정도 최고 수준으로 할 수 있으며 강력한 확장성을 갖고 있습니다. 다른 사람이 뭐라 하든 웹 서버 선택에 있어 방금 말한 것 이상의 것을 요구할 수는 없습니다. 그리고 아파치 역시 펄처럼 오픈소스 체제로 개발되어 가고 있습니다. 펄에서 얘기한 오픈 소스의 장점이 고스란히 아파치에도 적용됩니다.

 

아파치가 확장성이 좋다는 말은 사실 그 이상의 의미를 담고 있습니다. 아파치는 이미 웹 마스터 구미에 딱 맞게 확장되어 있습니다. 특히 펄과 함께 운용하기 좋게 확장되어 있습니다. mod_perl 아파치 모듈을 찾아서 Core Apache Server와 함께 컴파일하면 즉시 펄로 웹프로그래밍 하는 속도를 2000 퍼센트 정도 빠르게 만들 수 있습니다. 또한 아파치의 내부 기능도 펄 코드에서 쉽게 호출해서 사용할 수 있습니다. 그리고 mod_perl은 다른 하이엔드 웹 사이트 제작 기술과 긴밀한 관계를 맺고 있습니다. 웹 템플릿 시스템인 HTML::Embperl이나 HTML::Mason 같은 것이 대표적 예입니다. 앞의 것은 웹 페이지 제작에 embedded-code 방식을 끌어들인것이고, 두 번째 것은 template, component 방식을 도입한 것입니다. 어떤 방식으로 웹 페이지를 코딩하든 아파치와 mod_perl을 이용하면 최고로 만들어 낼 수 있습니다.

ASP가 최고다

PHP를 쓸까, ASP를 쓸까, 또는 ColdFusion이나 기타 비슷한 것을 택할까에 있어 가장 먼저 고려해야 할 점은 여러분의 웹 사이트를 지금 어떤 사람이 운영하고 있으며 앞으로 누가 운영해 갈 것인가입니다. 물론 PHP가 제일 멋있어 보일 것입니다. 최근 가장 유행하는 것이 오픈 소스와 리눅스이니까요. 하지만 웹 사이트를 만드는 사람들이 유닉스나 펄, 또는 C 언어에 익숙하지 않다면 PHP는 결코 최선이 아닙니다. 심지어 유닉스 전문가를 한 명 데리고 있다 하더라도 그 사람이 언제까지나 당신과 함께 일을 할 것이라는 보장은 없습니다. 그 유닉스 전문가가 그만두면 누가 싸이트를 유지합니까?

 

ASP(Active Server Page)는 비쥬얼베이직과 유사한 구문을 갖고 있는 VBScript를 이용해서 매우 쉽게 배우고 쓸 수 있습니다. 대개의 경우 회사에서 비쥬얼베이직에 익숙한 사람은 어렵지 않게 찾을 수 있기 때문에 ASP 기반의 웹싸이트를 유지하는 것은 PHP에 비해 훨씬 더 용이합니다. 만약 ASP와 관계 없는 경력을 갖고 있는 사람을 고용한다 해도 큰 문제가 안 됩니다. 자바스크립트와 거의 유사한 jscript, 펄, 심지어 Python을 써서 ASP 페이지를 코딩할 수도 있기 때문입니다.

 

ASP의 가장 뛰어난 장점은 COM 객체를 이용하고 있다는 것입니다. ASP의 다른 모든 부분과 마찬가지로 COM 객체를 이용하는 것은 믿을 수 없을 만큼 쉽습니다. 이것은 곧 두 가지 큰 장점으로 이어집니다. 첫째, 비쥬얼베이직이나 비쥬얼 C++에서 사용하던 강력한 COM 객체를 ASP 페이지에서도 똑같이 쓸 수 있습니다. 둘째, 언제든지 여러분의 ASP 페이지에서 쓸 COM 객체를 만들어 낼 수 있습니다.

 

기존에 개발되어 있는 COM 객체를 활용함으로써, 개발자들은 필요한 프로그램을 코딩하는 시간을 대폭 줄일 수 있습니다. 예를 들어, 마이크로소프트의 IIS(Internet Information Server)와 ASP를 인스톨 해 두었다면 "ad rotator"같은 무척 유용한 COM 객체를 바로 활용할 수 있습니다. "ad rotator"는 이름에서 대충 짐작 했겠지만, 배너 광고를 무작위로 돌려가며 보여줍니다. ASP 개발자는 IIS를 인스톨하는 것만으로 딱 두 줄의 코딩을 한 ASP 페이지를 이용해서 여러 배너를 무작위로 보여줄 수 있습니다. 똑같은 것을 PHP로 한 번 해보세요.

 

COM 객체의 강점은 마이크로소프트의 ActiveX Data Object(ADO)를 써보면 확실하게 느낄 수 있습니다. ADO는 데이타 억세스에 사용되는 강력한 COM 객체를 모아둔 것으로 비쥬얼베이직이나 비쥬얼 C++ 프로그램 또는 ASP 페이지에 즉시 사용할 수 있습니다. SQL 7.0 데이타베이스에서 엑셀까지, 어떤 형태의 데이타든 한 번에 연결할 수 있습니다. 그 뿐이 아닙니다. ADO는 거의 모든 것을 데이타 저장소로 활용합니다. 표준적인 ODBC 호환 데이타베이스는 말할 필요도 없고 delimited된 텍스트 파일, xml 파일 모두 데이타 저장소로 쓸 수 있습니다. 심지어 운영체제의 파일시스템도 데이타 저장소입니다.

 

필요한 COM 객체를 적접 만들 수 있다는 것도 중요합니다. 사실 마이크로소프트는 특정 비즈니스 관련 문제에 적합한 COM 객체를 직접 만들 것을 권장하고 있기도 합니다. 그리고 유용한 COM 객체를 개발해 줄 프로그래머를 찾는 일도 전혀 어렵지 않습니다. 왜냐하면 아까 얘기한대로 COM 객체는 비쥬얼베이직, 비쥬얼 C++, 또는 자바, 이 모든 것을 이용해서 개발될 수 있기 때문입니다.

 

멋진 ASP 페이지를 만드는 것은 매우 쉽습니다. 이 점에 대해 반론을 펼 사람은 많이 없을 것입니다. 굳이 얘기를 하는 사람들은 마이크로소프트의 웹써버인 IIS의 안정성과 보안성에 조금 문제가 있지 않느냐는 지적을 합니다. 하지만 저 개인적으로는 IIS나 ASP의 안정성 문제를 별로 겪어 본 적이 없습니다. 정 의심이 간다면, HotBot이나, Buy.com, Dell 등, 매우 많은 방문객을 처리하는 사이트를 보세요. 그 사이트들은 모두 ASP를 사용하고 있습니다.

 

IIS와 ASP가 확장성이 좋다는 것도 확실합니다. 하지만 도저히 마이크로소프트의 IIS는 못쓰겠다면, 그래도 ASP는 쓸 수 있습니다. ChiliSoft나 Halcyon 소프트웨어의 iASP같은 것들을 쓰면 IIS가 아닌 웹써버에서도 ASP를 쓸 수 있습니다.

 

개발환경을 어떤 것을 택하느냐를 결정할 때는 다음 질문을 던져보세요. 누가 이 웹싸이트를 운영할 것인가? 기존의 싸이트에 변화를 줄 때 어떤 것이 신참도 쉽게 할 수 있게 하는가? 데이타베이스나 스프레드쉬트 또는 xml 파일에 손쉽게 접근할 수 있는 것은 어떤 것인가? 자체적인 COM 객체를 웹페이지에 손쉽게 접목할 수 있는가? 그런 질문에 대한 최고의 답변이 바로 ASP입니다.

PHP가 최고다

오픈소스(Open Source)에 관해 언급하지 않고 PHP를 얘기할 수는 없습니다. 오픈소스의 가장 핵심적인 철학 그 자체야 말로 오늘날 PHP의 인기를 몰고온 결정적 이유이기 때문입니다. 오픈소스에 관해서는 많은 글들이 있으므로 여기서는 그냥 한마디만 해두겠습니다. 인터넷, 그리고 전자상거래도 마찬가지로, 오픈 소스 모델이 없었다면 오늘날과 같이 발전할 수 없었습니다. 예를들어, NCSA와 CERN의 웹 서버, 아파치, Bind, SSLeay, 펄(Perl), 그리고 바로 리눅스. 이 모든 것이 다 오픈 소스 덕분에 나타났습니다.

 

 

그렇다면 왜 웹싸이트를 만들때 PHP를 써야 하는가. PHP가 갖고 있는 가장 큰 매력은 우선 가격입니다. PHP는 무료입니다. 많은 사람들에게 비용이 0이라는 점은 엄청난 강점이 됩니다. 낡은 PC가 하나 있다고 합시다. 거기에 리눅스나 FreeBSD를 인스톨합니다. 그리고 아파치 써버를 깔고, PHP, mySQL을 인스톨합니다. 기타 에디터도 인스톨한 다음 필요에 맞게 해킹합니다. 총비용? 셋팅하는 데 들이는 시간만 있으면 됩니다.

 

이것은 해커 정신을 자극합니다. 해커 정신이야말로 오늘날 인터넷을 만들어 낸 것 아닌가요? 무료로 똑같은 것 내지는 더 좋은 것을 얻을 수 있는 데 굳이 돈을 지출할 이유가 없습니다.

 

이런 전통적인 해커 정신은 PHP의 코딩스타일에도 적용됩니다. PHP는 언어의 스타일이나 구문을 여러 언어로부터 차용해 왔습니다. C 언어라든지, 자바, 펄과 유사합니다. 예전에 그 언어 중 하나 또는 이상을 이용해서 프로그래밍하던 사람이라면 쉽게 PHP를 이용해서 웹 기반 애플리케이션을 만들어 낼 수 있습니다.

 

또한 PHP가 오픈소스 모델을 통해 발전해 가고 있다는 말은 PHP에 부가적으로 다른 기능을 첨가하는 것이 컴파일 한 번으로 끝난다는 얘기와 똑같습니다. 물론 ASP에는 COM 객체가 있고, ColdFusion에는 커스텀 태그가 있습니다. 하지만 어떤 것도 PHP 소스 코드에 당신이 필요로 하는 기능을 직접 첨가하는 것만 못합니다.

 

혹자는 서버 사이드 스크립팅 언어는 결국 데이타베이스에 있는 정보를 화면상에 띄워주는 것에 불과한 것 아니냐는 얘기를 합니다. 크게 봐서 틀린 얘기는 아닙니다. 하지만 PHP는 단순히 데이타베이스 중심 언어가 아닙니다. 훨씬 더 엄청난 기능이 있습니다. 이를테면: 동적인 그래픽 생성(dynamic graphics generation), IMAP, SNMP, LDAP, XML . . . 이런 모든 것들이 PHP에 있습니다. 물론 펄도 이 모든 것이 가능합니다. 하지만 많은 사람들이 펄은 배우기가 훨씬 더 어렵고 또 일반적인 웹 애플리케이션에 사용하기에는 다소 과하다는 점을 지적하고 있습니다. 그리고 mod_perl은 이제 보편화 되고 있을 뿐입니다.

 

PHP는 Sybase, Oracle, Informix, Solid, Postgres, 심지어 MSSQL까지 지원하는 풍부한 DB 지원 기능을 갖고 있습니다. PHP는 또 소규모 개발자들에게 하나의 축복이나 다름 없습니다. PHP는 확실한 크로스 플랫폼인데다가 정말 쉽습니다. 다시 얘기하지만, PHP를 이용해서 (아마도 mysql도 같이 써서) NT/Windows 머쉰을 마치 대형 서버처럼 사용하며 훌륭한 개발을 할 수 있습니다. 무료로 말입니다. 물론 Win32 버전의 경우는 제대로 동작하지 않는것이 조금 있는 것도 사실입니다. 하지만 상당히 고급 수준의 것을 만들기 전까지는 별로 문제가 되지 않습니다. 그리고 고급 수준에 이르면 어떤 형태로든 유닉스를 고려하게 됩니다.

 

한마디 더 덧붙이자면, PHP는 거의 모든 유닉스에서 다 잘 동작합니다. 돈을 주고 사야하는 한두 개의 운영체제에 얽매일 필요가 없습니다.

 

그렇다면 PHP의 단점은 무엇일까요? 판매용 소프트웨어는 종종 그것이 돈을 받고 판다는 사실 그 자체 때문에 팔리는 경우가 있습니다. 많은 사람들이 무료는 뭔가 문제가 있을 것이라고 생각하기 때문입니다. 그래서 판매 용 제품을 판매 회사의 기술지원과 함께 구입해서 하나의 플랫폼으로 통일합니다. 그것은 정말 큰 손해입니다.

 

PHP가 세션 처리(session handling) 기능이 없다는 비판이 있습니다. 그것은 PHPLIB 라이브러리를 사용해서 이미 극복되었습니다. 세션 지원은 아직까지는 베타 버전이지만 PHP4 버전에 포함되었습니다. 가장 최근에 배포된 PHPLIB은 다른 세션 관리 패키지보다 훨신 더 강력한 기능과 확장성을 갖고 있습니다. 유사하게 ISAPI 지원 역시 없었지만 PHP4에 포함될 예정입니다. 한편, PHP는 다른 웹써버 API에 손쉽게 적용되는 generalized server API library가 있습니다.

왜 PHP를 쓰는지 한마디로 얘기해 달라고 한다면 무료이고, 쉽고, 유용하고, 확장성 좋고, 그야말로 최고이기 때문이라 얘기하고 싶습니다.

JSP가 최고다

뒤늦게 제 모습을 드러냈다고 해서 항상 나쁜 것은 아닙니다. 앞서 나온 것들이 겪은 고통을 미리 지켜볼 수 있다는 점에서 특히 그렇습니다. Java Server Pages(JSP)가 그런 것 중 하나입니다. 다른 스크립팅 언어의 커뮤니티가 자신들의 언어를 세세하게 다듬고 성숙한 형태로 만들어 가고 있는 동안 썬 마이크로시스템즈(Sun Microsystems)는 클라이언트-서버 상호작용의 기초를 이루는 부분을 개선하려면 어떤 부분을 개선해야 하는 지 연구하고 있었습니다. 썬은 자사에서 만든 언어인 자바를 활용해서 Servlet API를 개발합니다. 웹 서버의 성능을 막강하게 향상 시켜주고 또 새로운 기능들을 첨가시켜 주는 일군의 클래스(class)를 개발해냈던 것입니다.[1]

 

JSP는 html 페이지 내에 데이타베이스로부터 추출된 내용을 포함시켜주는, 즉 다이내믹한 html 페이지를 만들어 주는 스크립팅 환경을 써블렛(servlet)을 이용해서 구현합니다. 개념상으로는 ASP와 상당히 유사하지만 ASP가 갖지 못한 여러 가지 강점을 갖고 있습니다. ASP는 VBScript나 Jscript 같은 것을 이용하고 있는데 반해, JSP는 자바라는 훌륭한 언어의 파워를 활용하고 있습니다. 그러므로 JSP는 ASP나 기타 스크립팅 환경들이 상상할 수 없는 뛰어난 성능과 확장성을 갖고 있습니다.

 

서블렛이 일단 서버의 메모리 내로 읽힌 다음에는 대개 대단히 컴팩트한 자바 객체 형태로 메모리 내에 머뭅니다. 그러므로 서버가 사용자로부터 요청을 받은 다음 부가적으로 인터프리터가 개입해야 한다거나 변수들이 새롭게 instantiate될 필요가 없습니다. (최초 한 번만 instantiate되면 충분합니다.)

 

즉, 서블렛은 대단히 효율적인 기술입니다. 서블렛은 마치 경계 상태에 있는 잠수함처럼 존재합니다. 항상 출동 준비를 하고 있는 상태입니다.

 

게다가 이런 효율성과 함께 서블렛은 서버에 매우 긴밀한 형태로 통합되어 있습니다. 따라서 일반적인 cgi보다 훨씬 더 복잡한 인터액션을 처리할 수 있습니다.

 

그런 점들이 JSP와 무슨 상관이 있을까요? 클라이언트 컴퓨터에서 최초로 JSP 페이지를 요청하면 서버는 자동으로 백그라운드에 있는 자바 서블렛(Java Servlet)을 빌드하고 컴파일해서 구동합니다. 자바 서블렛은 html 페이지를 만들어 내고 그 html 페이지는 클라이언트 컴퓨터의 웹 브라우져로 보내져서 사용자가 보게 됩니다. 중요한 점은, 일단 그렇게 된 다음부터는 JSP 페이지에 또 다시 접근하는 경우에도 다시 컴파일할 필요가 없다는 사실입니다. 그 즉시 데이타베이스에 질의해서 html 페이지를 만들어 내면 됩니다. 왜냐하면 서블렛은 이미 자바 바이트코드(bytecode) 형태로 웹 서버의 메모리에 떠있기 때문입니다. ASP를 사용한다면 클라이언트가 새로운 요청을 만들어 낼 때마다 코드를 새로 인터프리테이션해서 새롭게 html 페이지를 만들어 내야만 할 것 입니다. 이는 곧 속도 저하로 이어집니다.

 

또한 JSP는 자바 언어가 갖고 있는 모든 강점들을 클라이언트/서버 쪽에서 그대로 유지합니다. 포팅 가능성이라든지, 멀티쓰레딩(multithreading), 광범위한 클래스 라이브러리(class libraries), 객체 지향적인 코드, 확실하고 풍부한 보안, 언어 자체가 갖는 우아함, 그리고 확장 가능성 등 자바의 강점이 그대로 적용됩니다.

 

ColdFusion을 사용하는 사람들이 자신들의 제품을 Enterprise JavaBeans(EJB)와 연계시키려고 작업하는 것을 보세요. 그 사람들은 바깥 분위기가 어떤지 알기 때문에 그렇게 하는 것입니다. 인터넷 세계에서는 날이 갈수록 자바의 영향력이 강해져 가고 있습니다. 그들은 그 점을 받아들였습니다. 하지만 자바 이상으로 자바와 잘 어울리는 기술이 어디에 있겠습니까?

 

무엇보다 JSP를 우선적으로 고려해야할 가장 큰 이유는 아마도 개인적으로 투자한 것에 비해 수확이 매우 많기 때문일 것입니다. 무엇인가를 배우는 데 에너지를 쏟을 때 가급적 새로 배우는 것이 여러 모로 도움이 되기를 바라는 게 당연합니다. 해야할 일은 산더미처럼 많고, 연구 개발에 쏟는 시간은 참으로 귀중한 것으로 낭비되어서는 안 되기 때문입니다.

 

그런데 JSP를 배우면 투자한 시간 대비 매우 많은 것을 되돌려 받을 수 있습니다. JSP를 배우면 JSP라는 스크립팅 언어만 배우는 것이 아니고, 자바 언어를 배우는 것과 마찬가지이기 때문입니다. 자바가 무엇입니까? 다양한 상황에서 유효적절하게 활용할 수 있는 차세대 컴퓨터 언어의 대표주자 아닙니까?

 

JSP를 쓰기 위해서 자바에 능숙해져야 하는것은 아닙니다. 아니, 오히려 정반대입니다. JSP를 JavaBeans와 조합한다면 사실상 프로그래밍을 따로 해야 할 필요조차 없습니다. 자바스크립트를 조금 알고 있다면 지금 당장 JSP를 시작할 수 있습니다.

 

물론 모든 언어가 각기 나름대로의 강점이 있습니다. JSP 역시 이미 상당한 사용자 층을 확보하고 있고, JSP가 가져다 주는 자바 향기의 유혹에 넘어가지 않기란 대단히 힘들 것이라고 생각합니다.

 

[1] 역자주

원래는 자바로 개발된 프로그램은 두 가지 형태로 존재 했습니다. 하나는 웹 브라우져내에서 실행되는 애플릿(Applet)이고, 다른 하나는 보통의 애플리케이션처럼 더블 클릭으로 실행될 수 있는 애플리케이션(Application)입니다. 전자는 웹 브라우져내에 포함된 JVM(Java Virtual Machine; 자바 가상 머신)상에서 실행되고, 후자는 운영체제 내에 설치된 JVM(Java Runtime을 인스톨하면 설치되는)상에서 동작합니다. 이 외에도 애플릿은 다음과 같은 특징이 있습니다. 대부분 보안을 위해 갖추어진 특징입니다.

 

 1. 로컬 파일시스템에 접근하지 못한다.

 2. 네트웍상의 다른 시스템에 접근하지 못한다.

 3. 새로운 프로그램을 시작하지 못한다.

 

애플릿이 만약 로컬 파일 시스템에 접근할 수 있다면 악의적인 애플릿으로 사용자 하드 디스크를 들여다 볼 수 있습니다. 또는 뭔가를 심어둘 수도 있습니다. 네트웍상의 다른 시스템도 마찬가지입니다. 그래서 보안을 목적으로 위와 같은 제한점을 두었습니다. 그런데 이런 특징들이 오히려 기업체 컴퓨팅에서의 자바의 활용을 제한하게 됩니다. 대부분의 사내 네트웍이 인터넷을 도입해서 이를 기반으로 하고 있는데, 사용자 유져 인터페이스 등의 프런트 엔드(front end)를 애플릿으로 만들려다 보면 너무 크기가 커지고, 이는 네트웍을 통해서 실행되어야 하는 애플릿 실행 속도를 현저하게 떨어뜨립니다. 또한 애플릿이 다른 시스템에 접근하지 못 하게 하려면 애플릿이 있는 웹 서버에 DBMS도 함께 존재해야 합니다. 이것은 서버의 큰 로드로 이어집니다. 이런 단점 때문에 나온 것이 서블렛(Servlet)입니다.

서블렛은 JVM을 클라이언트 쪽에 두지 않고 웹 서버에 둡니다. 애플릿처럼 클라이언트 쪽 웹브라우져로 건너가서 실행될 필요없이 웹 서버에서 바로 실행, 그 결과만 보내면 되므로 네트웍 상에서 훨씬 원할하게 사용할 수 있습니다. 그리고 서버에서 실행되는 것이므로 보안에 대해 큰 걱정을 하지 않아도 됩니다. 얼마든지 로드가 많이 걸리는 작업을 분산할 수 있습니다. 이러한 써블렛이 동작하는 방식은 크게 3단계로 이뤄집니다. 클라이언트가 서버에 어떤 것을 요청하면,

 

 1. 클라이언트의 요청을 추출: 예를 들면 사용자가 폼에 입력한 값들.

 2. 이를 바탕으로 여러 가지 연산을 수행하거나 DB와 연동.

 3. 그 결과를 out.println("") 형태로 출력해서 클라이언트에 보냄.

 

클라이언트 쪽에서 요청 --> 서버 쪽에서 적절한 처리(DB 연동...) --> 사용자에 맞게 변형된 내용으로 보내줍니다. 즉, 다이내믹 컨텐트(dynamic content)를 만들어 줍니다. 그런데, 위와 같은 방식으로 작업을 하면 3단계째인 out.println() 단계가 지나치게 복잡해집니다. 디스플레이와 관계되는 지저분한 html 테그들을 일일이 저런 형식으로 써가며 작업하기는 곤란하기 때문입니다.

그래서 ASP나 PHP 방식처럼과문서내에 자바 코드를 실행시킬 부분을 집어넣는 방식을 택합니다. html 안에 다이내믹하게 바뀔 부분만 <% 자바코드 %> 형태로 끼워 넣습니다. 다른 언어와 비슷한, 서버 측 스크립팅 방식인데 써버에 있는 JVM을 활용한 Java 기반이라는 것이 다릅니다.