한빛출판네트워크

제 4부 - 엔터프라이즈 자바, 무주공산은 이제 끝났다?

저자: 이아스님

스타팅 멤버

한국만큼 CGI의 명이 짧았던 웹 기술 현장도 없었을 것입니다.(그리고 앞으로도 없을 것 같구요.) 이제는 웹 사이트 URL에서 cgi-bin이라는 정겨운 경로를 보기조차 진귀한 경험이 되어버렸습니다. 펄(perl)의 위세가 가장 약한 곳도 IT강국 대열중에서는 우리나라 아닐까요? 

가장 먼저 이러한 현상을 이끄는 데 공헌한 기술은 역시 ASP(Active Server Page)였습니다. 필자조차 처음 asp페이지를 봤을 때의 당혹감은 잊을 수 없군요. 

"이것이 바로 동적 페이지 생성 기술(dynamic page generation technology)이로구나...."

1990년대초에 친구의 지인이 스탠포드에서 연구한다던 동적 웹 컨텐츠 생성 기술-DB의 정보를 정적인 웹 페이지로 보여준다는 야심차면서도 불가능해보이던 시도-의 실제가 이미 1990년대중반부터 파급되기 시작했던 셈입니다. 

분명 프로그램이 안에 들어가있어보이는데, HTML 소스를 보면 보통의 HTML과 다르지 않고, URL을 보면 무슨무슨.asp로 되어있고, 아니 이 세상에 html로 끝나지 않는 HTML파일도 다 있구나... 

MS가 보여준 이런 신기에 가까운 마술은 빠르게 CGI의 틈새를 파고 들었습니다. (물론 새로운 스크립트 언어이기도 했지만) 펄조차도 짜기 힘들다고 아우성이었고, 다소 무거운 CGI의 프로세스 기반 운영도 괜시리 트집을 잡으며 ASP는 기존의 비주얼 베이직(VB)기반의 씩(thick) 클라이언트 진영을 빠르게 웹 기반의 씬(thin) 클라이언트 진영으로 흡수했습니다.

필자는 이러한 정황속에 등장한 JSP(Java ServerPage)를 보고 다소 실소(?)를 금치 않을 수 없었습니다.

"엑티브는 MS의 전매특허... 자바는 썬의 전매특허.... 서버 페이지는 똑같이 썼군..."

다소 어이없는 네이밍 센스만으로도 본인을 즐겁게 해주기 충분했지만, 내부 구조상 썬이 창안한 최고 흥행작중의 하나인 서블릿에 의존하고 있다는 점은 무척 착찹해보였습니다.

ASP에 비해 서블릿은 물론 페이지 생성쪽에서 아주 불편한 것이 사실이었습니다. 그래서 다양한 템플릿 기술이 그러한 서블릿의 약점을 보완하고자 등장했었고, 몇몇 대안 기술은 상당한 인지도를 가지게 되었지만, 주류로서는 다소 벤더 파워(vendor power)-기술 제작사의 입지가 미약했습니다.

이러던 차에 썬이 JSP를 서블릿 기반으로 고안했다는 점은 너무도 많은 것을 시사하는 통에 이루 다 지적할 수 없을 정도입니다. 그래도 대강 추려보면 다음과 같겠지요.

1. 이미 상당히 퍼져버련 서블릿을 져버리기에는 시기상 늦어버렸으니 어떻게든 서블릿 기술과 서블릿 컨테이너를 안고 가야했고,
2. 서블릿 API를 그대로 활용할 수 있으므로 자바 페이지 생성 기술의 주류로 자리잡기 쉬운 이점이 있었고,(당시 다른 템플릿들은 제각각의 API와 스크립트 언어 방식을 씀)
3. 사실상의 껍데기는 ASP와 아주 흡사하므로 기존 ASP세력까지 꼬실 수 있으면서도 자바의 강력한 확장성을 빌려올 수 있다

그런데, 이렇게만 내놓으면 "자바로 만든 ASP"라는 오명을 피할 수 없다고 판단했었는지, 그동안 GUI컴포넌트계의 찬밥 신세를 면치 못하던 자바빈즈를 교묘하게 끌어들여 

"JSP는 자바빈즈와 꼭 함께 써야한다!"

는 선전 전략으로 자료 캡슐화(data encapsulation)의 도구로 활용하기 시작했습니다.

여기에 스몰토크라는 GUI지향 개발 언어의 애플리케이션 설계 구조인 MVC(Model-View-Controller)개념까지 끌어들여 빈즈-JSP-서블릿의 삼위일체 시스템을 자바 웹 애플리케이션이라고 명명한 데에까지 이르면 실소는 멈추고 얼굴에는 심각한 표정만 남게 되지요.

참으로 기묘한 우연인지는 몰라도, 엔터프라이즈 자바라고 일컫는 기술 분야의 첨병 역할을 담당하고 있는 자바 웹 애플리케이션 구조의 ASP와의 차별점이 모두 GUI에서 유래하고 있습니다. 서버측 기술이라고 하면 보통 눈에 안보이는 것으로 생각하는데, 눈에 보이지 않는 기술에 눈에 보이는 기술을 도입한다... 위험천만한 계산이었을까요?

끊임없이 재기되고 있는 자바 웹 애플리케이션의 성능과 구조 논쟁은 이제 J2EE 디자인 패턴의 공식화와 함께 다소 진정된 듯 보이지만, ASP와의 차별성을 주기 위한 "차별성을 위한 차별성"은 이제 역으로 닷넷(.NET)이 따라하게 되었으니 참으로 아이러니하다고나 할까요?

90%, 아니 99%?

미국의 J2EE현장에서의 EJB미사용율이라고 생각하기에는 믿겨지지 않는 90%라는 수치는, 어쩌면 표본수를 늘리면 99%까지도 올라갈지 모르는 통계의 일면입니다. 

심지어 MVC모델를 채택하지 않고 작성되는 사이트도 허다합니다. 어떤 경우에는 빈즈가 빠지고, 또 어떤 경우에는 서블릿이 빠지고, 심지어는 ASP와 아무런 차이가 없는 "JSP홀로" 사이트도 있습니다. 구조상의 이점이 전혀 없이 속도만 깍아먹는(특히 윈도우즈NT에서) 웹 애플리케이션이라면 상당히 눈치밥을 먹고 살고 있겠지요.

왜들 그렇게 EJB며 패턴이며 모델에 목을 매는가? 과연 목을 매는 만큼 실용성이 있고, 실제로 적용들은 하고 있는가? 이러한 화두는 썬의 객체 지향 자바와 분산 객체 EJB의 보급 정책에 묻혀 제대로 논의되기를 꺼려하고 있는 분위기입니다.

최근 자바 웹 프로그래머의 3대 학습 대상은

XML
EJB
디자인 패턴

으로 요약할 수 있는데, 흥미로운 것은 이 기술들이 모두 당장 실무에 필요해서라기 보다는 엔지니어로서의 경쟁력 강화를 위한 "명분적" 과목이라는 암암리의 현실입니다. 더군다나 당장 일자리조차 구하기 힘든 초보 개발자의 경우에는 더 다급할 수밖에 없죠. 

그러나, 지극히 현실적이며 실용적인 미국의 "90%"라는 수치를 약간 다른 관점으로 주목해볼 필요가 있습니다. J2EE 플랫폼 기반으로 사이트를 만든다고 해도, 분산 객체가 필요한 경우는 그리 "흔치" 않다는 것입니다. 그리고도 그런 분산 객체는 아무나 설계하고 만들 수 없다는 것도 솔직히 인정해야겠죠. 결코 초보를 얕보고 고수를 찬양하자는 뜻이 아닙니다. 개발자에도 능력의 수준이 있고 발전의 단계가 있습니다. 

제가 나름대로 생각하는 우리나라 교육에서 가장 치명적인 정책은 "필요하지도 않은 것을 가르쳐준다"입니다. 그렇다면 아주 까놓고 얘기해서 미국이 "필요한 것만 가르치는" 것일까요? 그렇다면 늘 딱 필요한 만큼만 알게 되니까 전혀 진보는 바랄 수 없겠죠. 최근 애플의 CEO 스티브 잡스가 다음과 같은 말을 했습니다.

"시장이 없다고 불평하는 것은 기업가가 아닙니다. 시장을 창출하는 것이 기업가의 임무입니다."

학생들이 필요로 하게 만들어서 가르치는 것입니다. 임무(mission)와 역할(role)을 주어서 수행하고(operate) 성취하도록(achieve) 합니다. 왜 필요한지까지 꼬치꼬치 잔소리하지 않습니다. 너무도 당연하게 이미 그런 임무와 역할을 맡고 있는 사람이 있을 터이고, 스스로 맡아서 해나가다보면 시나브로 깨닫게 장을 마련해주면 됩니다. 

처음 자바 개발자로 나섰다고 XML, EJB, 디자인 패턴에 관심을 가지지 말라는 소리가 아니고, 당장 현재의 자신의 위치에 걸맞는 지식과 경험의 체계를 쌓는 데에 주력하는 것이 장기적인 안목뿐만 아니라 단기적으로도 효험있습니다. 

자바 웹 개발자 단계별 실질 학습 항목(순전히 필자 마음대로 잡은 것임)

초보(대략 경력 2년 미만)  - J2SE 심화(특히 I/O와 네트워킹, 쓰레드, 콜렉션), TCP/IP, 플랫폼(운영체계/하드웨어)

중급(대략 경력 2~4년) - RMI, RFC, XML, MVC

고급(대략 경력 4~6년) - EJB, RUP, UML

설계자(대략 경력 6년 초과) - 디자인 패턴, XP

따라서 자바 웹 개발이 본격화된 시점을 아무리 빨라도 국내에서 1998년으로 잡으면, 아직 설계자급이 나오기에는 무리가 있는 상황인 것입니다. 적어도 2003년, J2SE 1.5가 나오는 시점와 얼추 일치하며 국내 자바 웹기반 시스템의 설계자급 인력이 "안정적"으로 배출된다는 계산이 나오지요. (안정적이라는 말에 주목해주세요. 물론 개인차에 따라 빠르게 성장하시는 분도 계시고 대기만성인 분도 계시기 때문입니다.)

질보다 양? 

새천년을 맞이한 포탈 건설 붐으로 자바는 엔터프라이즈 시장을 빠르게 점령하기 시작했습니다. 특히 최고의 원군 오라클을 얻은 썬은 거칠 것이 없이 같은 우군인 IBM의 질투까지 사가면서 서버와 자바 장사를 멋지게 일구어내었습니다. 그러나, 마치 실제 건설업과 비슷하게도 지나친 하도급과 무리한 단가 설정은 부실 공사를 낳아 이제 정부에서까지 나서서 사이트 품질을 논하기에 이르렀죠.

공기(工期)라는 말이 있습니다. "공사 기간"을 줄인 용어이죠. 무슨 수를 써도 공기를 어겨서는 안되는 것이 공사일이니까, 날림으로 짓든 그랜드 오픈 다음날 무너지든 상관할 바 없겠죠? (뜨끔하신가요? ^^)

애플리케이션 최고의 덕목은 질이다. 따라서 품질을 포기한다면 아무런 의미도 소용도 없다. 

이런 말은 누구든 술자리에서는 할 수 있습니다. 그러나 현실은 바다건너 미국조차도 마찬가지인가봅니다. 공기때문에 제대로 만들 수 없었다는 불만은 미국 자바 개발자들도 토로하는 바더군요.

왜 이토록 공기에 집착하는가? 당연하게도 인간은 시간상 유한한 존재이기 때문입니다. 더우기 인터넷 비즈니스는 시간 싸움이라는 선입관까지 자리잡혀 있으니까요. 빨리 하는 게 나쁘다면 이 바닥에서는 바보죠. 가장 좋은 케이스라면 빨리도 하고 품질도 만땅인 것이겠지만, 이 세상은 수퍼맨만 사는 동네가 아닙니다.

절대 어거지로 "불합리적인 공기"에 "합리적인 품질"을 내라고 해서는 곤란하죠. 트레이드오프(trade-off)라는 말이 유행해오고 있습니다. 허허실실이지요. 줄 건 주고 받을 건 받고, 이점을 취하면 해점도 감수해야죠. "최선"은 정신을 표현하는 말이지 물질을 표현하는 말이 아닙니다. 최고까지는 아니더라도, 믿고 돌아다닐 수 있는 사이트 건설에 필요한 것은 최선을 다하는 개발자의 마음뿐만 아니라 그런 개발자에게 "너는 왜 수퍼맨이 아니냐"고 묻지 않는 고객(사이트 발주자)와 관리자(사실상 동료)의 합리적인 사고가 아닐까요? 

WAS라고라고라...

지난 2001 가을 자바원 컨퍼런스에서 한국의 한 벤쳐회사가 "우리는 어떻게 1년안에 J2EE인증을 받았는가"하는 아주 이색적인 주제로 발표를 했습니다. 최근 웹 애플리케이션 서버(Web Application Server)시장이 커지면서 엔터프라이즈 자바 기술의 표준으로 자리잡고 있는 J2EE를 제대로 지원한다는 것은 마케팅에 아주 큰 장점으로 발휘하고 있죠. 

처음에는 오라클이 DB도 먼저 내놓기전에 9i WAS로 기선을 제압하더니, IBM도 이에 뒤질새라 웹 스피어 스튜디오로 비주얼 에이지 포 자바와 드림 위버를 합쳐 명실공히 MVC모델 작성의 최상의 환경을 제공했고, 넷스케이프 서버를 은근슬쩍 사들인 썬은 아이플래닛으로 자바 종주국의 위력을 마음것 퍼붓더니, 시장의 터줏대감 BEA는 다들 웃기지 말라며 웹로직의 몸집을 빠르게 불리고 있습니다.

여기에 무료라는 충격까지 선사하며 시장 이미지 강화에 힘쓰고 있는 HP와 후발 주자들, 그리고 기존 중소업체까지 합치면 정말 어떤 WAS를 골라야할지 행복한 고민에 빠집니다.

예전과는 달리 요새 WAS는 J2EE(특히 1.3) 준수를 무척 자랑하고 있다는 마케팅 전략이 무척 이채롭습니다. 특히 IBM은 J2EE초창기에 라이센스 자체를 안하겠다고 버티며 썬을 비롯한 친J2EE진영의 목을 바짝바짝 마르게 했었는데, 이제는 다른 방식으로 썬의 독주에 제동을 걸 셈인지 J2EE자체에는 별 시비를 걸지 않고 있습니다. BEA나 오라클이야 썬덕분에 시장도 넓히고 돈도 번 회사들이기때문에 썬이 J2EE를 어떻게 구워삶건 상관할 바가 그렇게 크지는 않지요. 

자바가 성능상의 트레이드오프에도 불구하고 미래지향적인 유지보수성을 높이 평가받아 업계에서 활약하고 있음은 참으로 반가운 현상임에는 분명합니다만, 과연 그 유지보수성을 초월하여 다른 WAS간의 이식성까지 "J2EE 준수"라는 이름하에 신경써야하는지는 알송달송합니다. 특히나 오라클이나 IBM의 경우 DB 처리의 원활화, 가속화를 위해 비표준적인 자바 DB 제어 기술을 제공하고 있어, WAS를 결정하고 나서 공사에 들어가는 관행으로는 이러한 WAS-DB의존적 기술 채택이 사실상 불가피하고(성능상, 개발속도상), 그러다 보면 "웹 애플리케이션의 반은 DB"라는 말도 있듯이 자바는 J2EE를 준수해서 이식성이 높을지 몰라도 DB쪽은 전혀 이식성이 없는 애플리케이션이 탄생하는 셈입니다.

이런 상황은 DB제품군을 가지고 있지 않은 썬으로서는 무척 불안한 것이기에 EJB의 CMP, 즉 컨테이너가 관리하는 방향을 꾸준히 발전시키며 권장-표준화하고 있지만, 여러가지 실제적인 한계로 "CMP EJB는 WAS간 이식성을 높이는 데에는 좋다"는 명제만 남긴 채 아주 이상적인 학습용 모델로 남을지도 모르는 일이지요.

자바 웹 애플리케이션의 WAS독립성은 WAS가 J2EE 표준을 준수하고 개발자가 J2EE 기반으로 작성하면 완전 확보된다고 하지만, DB독립성은 글쎄요... 이것까지 확보하려면 웹 애플리케이션, 더 나아가 웹 서비스 개발의 패러다임이 많이 바뀌어야할 것입니다. 지금까지는 하나의 트랜잭션(업무 처리 과정)의 구현을 JSP부터 DB처리까지 한 명의 개발자가 책임지는 방식이었다고 하면, 앞으로는 (그것이 가능할까 모르겠지만) JSPer(제이에스피어-JSP짜시는 분), Servleter(서블릿터-서블릿 짜시는 분), Beanser(빈저-빈즈 짜시는 분), 여기에 DBA(DB assistant-DB관련 처리해주시는 분)까지 모두 각자의 분야에 전념하고 서로간에는 API(Application Programming Interface), 즉 일정한 설계를 바탕으로 꾸며진 약속으로 유기적으로 연결, 교류하는 방식으로 간다면 자바 웹 애플리케이션의 자바적 독립성(플랫폼 독립성)과 웹적 독립성(레거시 독립성)을 함께 구가할 가능성도 있습니다.

닷넷은 그럼 어떻게 되는 거죠?

최근 웹 서비스라는 개념이 대두되면서 이제는 웹 개발 플랫폼조차 독립하려는 경향이 두드러지고 있습니다. 물론 여기에는 XML과 소프(SOAP)라는 웹 공개 기술이 앞장서고 있구요. 처음에는 아파치에서 열심히 하는가 싶더니, 빠르게 썬과 MS가 도입하여 상품화하고 있습니다. 

사실상 XML과 소프는 HTML(Static Page)과 DSP(Dynamic Server Page)의 21세기적 상징에 지나지 않습니다. 시대가 이미 HTML과 ASP, JSP에 만족하기에는 무척 욕구가 다양해진 덕분이기도 하구요. 게다가 신물이 날 대로 난 MS와 반MS진영간의 반목으로 엉뚱한 개발자와 사이트만 골머리썩는 것도 짜증날만 하지요. 가장 진보적인 웹 기술 단체인 아파치가 가장 현실적인 문제에 접근하는 XML과 소프를 선도하고 있다는 사실은 그런 측면에서 무척 모순적이면서도 고무적이기까지 합니다.

여기에 그간 사이트 설계시 실제 공사 설계도와 같은 개념이 없었다는 점도 많이 지적되어 UML이 웹 서비스 설계도의 지위를 공고히 할 전망입니다. XML-소프-UML, 이 경지에까지 이르면 J2EE건 닷넷이건 그저 자제를 이태리제 대리석으로 할 지 러시아산 침엽수목으로 할지 결정하는 것과 별반 다르지 않겠지요. 

많은 사람들이 아주 저에게 까놓고 묻습니다. 

"이봐요, 당신이 뭘 좀 알고 보는 듯 한데, 앞으로 뭘해야 잘나갈 수 있을 거 같수?"

저는 되도록이면 위와 같은 질문을 하는 분에게는 하이브리드(hybrid)한 개발자쪽으로 나아가시길 권합니다. 앞날에 대해서 저토록(?) 고민하는 데에는 그만큼 욕심이 많고 그래서 불안도 많다는 뜻이겠지요. 그런 분에게 "자바만 해라!" 거나 "MS가 낫겠지요?"라고 해서 만족하실 리 만무하니까. 그렇다고 이것저것 다 하다보면 만물상이 되어서 전문가 소리는 못듣는건 아닌가하는 걱정도 하시는데, 만물상은 전문가아닙니까? (만물 전문가지요.)

하이브리드하다 함은 연장에 연연할 필요가 없다는 말입니다. 요새 많은 웹 개발자분들이 건설계의 설계 사무소에 해당하는 프로젝트 설계자(보통 영어로 아키텍트라고 부르는)를 지망하시는데, 그런 분들일수록 시야가 넓어야하고 썬이니 MS니 하는 편견따윈 집어치워야합니다. 수많은 명작을 낳고 있는 지브리 스튜디오의 수장 미야자키 하야오도 일개 애니메이터(동화 그리는 사람)부터 시작했지만 오늘날 독보적인 감독의 자리에 올라설 수 있었던 것은 작품을 만드는 처음(알파)와 끝(오메가)를 완전히 장악하고 있기 때문입니다. 장악하고 있다는 뜻은 알고있다는 뜻과 다릅니다. 그가 3D를 도입한다고 해서 3DMAX를 마우스로 찍어대지는 않겠지요. 지금 자바를 한다고 혹은 C#을 한다고 해서, 나중에 그런 언어가 힘을 잃고 사라지면 어쩌나 기우에 잠기실 필요는 없습니다. 가끔 미야자키 감독은 동화에 직접 참여하는 경우가 있다고 합니다. 그것은 일손이 달려서가 아니라, 감은 잃지 않기 위해서라고 보면 될까요? 설계자이자 지휘자이기도 한 아키텍트에게 중요한 것은 코드를 짜는 손이 아니라 코드를 짜는 손을 아는 눈입니다. 그리고 그 눈을 밝히기 위해서는 반드시 거쳐야하는 과정이 바로 코더(coder), 즉 코드를 짜는 일입니다. 개발자 10년, 아키텍트로서의 자신이 짜는 코드, 그 형상이 어떨지는 상상해봄직 하지요, 자바건 C#이건 아니면 2010년을 대표하는 신종 언어이건.

닷넷은 당연하게도 윈도우즈 플랫폼상의 최고 개발 환경임이 분명합니다. 따라서, 굳이 자바를 고집하며 거부할 필요가 없는 것입니다. 고객이 윈도우즈 레거시 시스템(MS SQL이라던가)을 가지고 있고, 앞으로도 MS-인텔이랑만 거래하겠다고 하고, 일반 사용자에게 철저히 다가가겠다는 확답만 받아내면 됩니다. 어차피 UML로 설계도 그리고 XML로 자료 처리하고 소프로 로직 처리하면 끝! 뒷단이라고 부르는 서버측 컴포넌트나 코드는 C#, C++, VB 뭘로 짜도 매한가지인 객체지향(object-oriented)-이벤트 운영(event-driven) 방식이니 코더로서의 경험에는 아무런 하자가 없습니다.

따라서 누가 우세할 것인가에 대해서는 호사가들의 술안주로는 짭짤할지 몰라도 일선 개발자들사이에서는 그렇게 절실한 이슈는 전에도 아니었고 지금도 아니고 앞으로도 아닐 것입니다. 개인적인 취향이나 애착은 물론 있을 수 있지만, 과유불급이라고, 사랑도 지나치면 질투와 증오를 낳고는 볼성사납게 끝나고 말지요.(왜 이런 경우에는 예외도 없는지...) 

우리에겐 부족한 것이 필요하다-시간 

기업 대상 시장에 있어서 신속성은 21세기에서도 가장 중요한 것으로 모두가 공감하고 이루려 할 것입니다. J2EE는 개발 기간을 늘리고자 만들어낸 거룩하고 고상한 기술이 아닙니다. 온고지신의 정신으로 품질과 공기, 두 마리 토끼를 함께 잡겠다는 아주 용감한 일보(一步)입니다. 그리고 고맙게도 그 생각은 닷넷에도 그대로 적용할 수 있습니다. 

"빠르다"와 "서두르다"는 무척 뉘앙스가 다릅니다. 마음같아서는 MS도 썬도 더 많은 기술자와 전문가를 동원하여 어서 더 엄청난 기술을 제공해주었으면 하는 욕심도 듭니다. 그러나 그들은 서두르기 보다는 빠르기를 원합니다. 표면적으로 보기에는 늘 무언가에 쫓기는 듯 싶어도, 자세히 들여다보면 주도면밀하고 기획하고 속도를 조절하는 모습이 숨겨져 있습니다. 기업은 늘 대계를 짭니다. 조직은 크고, 섯불리 바꿀 수 없는 것이 그럴 수 있는 것보다 더 많습니다. 그럼에도 불구하고 빠르게 움직이여 살아남는 현실은 너무도 가혹한 걸까요? 공룡 기업 IBM이 한순간의 판단실수로 자신이 키운 MS에게 완패한 후 컴퓨터 시장 자체에서의 패퇴를 거듭하다가, 최근 반도체, 소프트웨어, 서버, DB분야에서 부활하고 있는 드라마틱한 반전을 보고 있노라면, 주라기 공원의 명물 티-렉스들이 떠오릅니다. 전혀 공룡같지 않은 빠르기와 영리함을 보여주는 그들의 존재로부터 IBM은 무언가 배운 것일까요?

시간이 부족하다고 여기는 것은 인간뿐이 아닐까... 어쩌면 인간에게 필요한 것은 시간이 아니라 변화일지도 모르겠습니다. 시간의 흐름에 완벽히 적응하는 자연과 마찬가지로요.