여러분은 웹 애플리케이션 서버라는 용어를 언제 처음 들었봤나요? IT 학원 붐이 일던 2000년대 초반? 아니면 학교에서 프로그래밍을 공부하던 때로 거슬러 올라가야하나요?
웹 애플리케이션 서버를 잘 모르시거나 시초에 대한 흥미와 IT트렌드에 관심을 가진다면 이 글을 가볍게 읽어주시면 됩니다.
자바 웹 애플리케이션 서버의 역사를 살펴보자면 사실 자바라는 언어에서 시작하는 수고스러움을 겪어야 합니다.
본 글을 대하는 여러분은 대부분 자바를 주 언어로 이용하고 있을 것입니다. 하지만 예전에 제가 강의를 할 때 수강생분에게 물어보면 대부분 자바가 언제 어떻게 탄생했는지 알고 있는 분들이 거의 없습니다.
탄생의 역사는 지금으로부터 23년전인 1991년으로 거슬러 올라갑니다. GE(General Electric, 미국최대 가전회사)는 1991년 대화식 TV에 대한 개발을 썬 마이크로 시스템즈(이하 썬, 현재 오라클에 인수됨)에 요청했다. 이를 위해 썬은 그 개발을 제임스 고슬링(James Gosling ,자바의 아버지로 불림)을 비롯한 마이크 쉐리단(Mike Sheridan), 패트릭 노턴(Patrick Naughton)에게 맡겼고, 이들은 초기의 언어 이름을 오크(Oak, 떡갈나무)라 명명했고 이후 그린(Green) 프로젝트로 이름을 바꾸었습니다.
고슬링은 C/C++에 기반을 둔 가상 머신의 구현에 초점을 맞추었고, 이후 그린 프로젝트는 자바 커피에서 이름을 딴 자바라는 언어로 1995년에 1.0이 최초로 발표되었습니다. 들어봤을 수 있겠지만 여기서 중요한 단어는 가상 머신(Virtual Machine)이며, 이는 WORA(Write Once, Run Anywhere)라는 모토로 WO(Write Once)는 개발 키트(JDK)를 RA(Run Anywhere)는 가상 머신(JVM)을 가리킨다고 봐도 됩니다.
앞서 이야기한 것처럼 초기의 자바는 가전을 위한 목적으로 만들어졌습니다. 하지만 초기 버전에 애플릿(Applet)이 포함되면서 기존의 정적(static)인 페이지만 제공하던 웹을 애플릿이 동적으로 변화시켜 버렸습니다. 예를 들면 증권 시세 정보나 동적인 데이터들을 실시간으로 볼 수 있던 방법이 없었는데 애플릿을 통해 이러한 것들이 가능해지면서 넷스케이프와 더불어 1996년 폭발적인 성장을 하게 됩니다.
그러한 성장과 많은 개발자들이 자바에 관심을 갖게 되고 눈을 돌리게 되었습니다. 사실 이는 초기에 의도되었던 소형 기기가 아닌 3티어이상의 엔터프라이즈 환경에 어울리는 모양새였습니다. 이러한 차이점을 구분하기 위해 마케팅적인 목적으로 자바를 3가지로 분류하게 되었는데 그것이 바로 Java ME(Micro Edition), SE(Standard Edition), EE(Enterprise Edition)였습니다.
앞서 설명한 애플릿의 성장에 따라 썬은 차기 버전의 자바를 준비할 필요성이 있었습니다. 드디어 1998년 12월에 J2SE 1.2 버전을 내놓고 이를 java 2라 명명하고, 엔터프라이즈 환경, 모바일 환경에서 작동되는 서로 다른 환경으로 구성된 자바 버전을 내놓게 됩니다.
애플릿이 그 영역을 넓히고는 있었지만 클라이언트 측에 다운로드되어 실행된다는 점(속도적인 약점)을 극복하기 위한 노력은 내부적으로도 계속되었습니다. 그에 따라 Java2가 발표되기 전 JDK1.1에서 서블릿에 대한 논의를 실행에 옮긴 2.0버전을 내놓고 1998년 11월에 RequestDispatcher, ServletContext를 포함시킨 최초의 공식 명세서(specification)을 내놓게 됩니다. 이러한 기능들은 기존의 CGI(Common Gateway Interface)가 가지던 성능적인 약점, 메모리 문제, 단일 인스턴스로 인한 병목 등을 해결하며 더욱 승승장구하게 되었습니다.
NOTE. 서블릿(Servlet)은 비공식적으로 서버 측 애플릿에서 이름의 유래를 찾을 수 있다. 애플릿은 클라이언트 측이며, 서블릿은 서버 측이다. 언어는 자바로 같지만 라이프사이클, 구성 방식, 특징 들은 완전히 다르다.
이 서블릿을 통한 동적 웹의 폭발적 성장은 기존의 메인 프레임 기반이던 기업 전반의 시스템 구조를 유닉스 기반의 오픈 환경으로 변화시키는데 많은 기여를 하게 됩니다. 이에 따라 메인 프레임 일색이던 시스템들이 2000년대 초반 차세대 프로젝트라는 이름으로 엔터프라이즈(기업) 영역에서 그 쓰임이 넓어지는 계기가 되었습니다.
NOTE. 사실 웹의 폭발적 성장의 주요인을 꼽는다면 초창기1위를 수년간 놓지 않았던 ‘Sex’ 라는 단어였다. 현재는 ‘Porno’ – 찌라시 기사들 참조
서블릿이 각광을 받던 즈음 각 기업들이 비용이 싸진 개방형 시스템(유닉스 기반)을 도입하게 되면서 각 업무 시스템들은 기존의 중앙 집중형이 아닌 분산된 시스템 구조로의 변화를 일으키게 됩니다. 즉 인사, 마케팅, 영업, 생산, 자재 시스템 등이 각 사업부별로 분산되어 구축되고 관리되기 시작한 것입니다.[1]
각 사업부서에 도입되는 패키지 애플리케이션(CRM, SCM, ERP 등등)들은 서로 각기 다른 언어를 사용하여 분산된 시스템에 구축되었습니다. 이러한 구조적 현상은 시스템적인 측면에서 데이터 중복, 연계의 어려움 등이 발생을 초래했고, 경영적인 관점에서는 실시간 형태의 데이터를 즉시 제공하지 못함으로 인해 업무 지연 등의 문제가 발생을 하게 되었습니다.
이제는 분리된 시스템을 어떻게 하면 쉽게 연계하고, 적시성을 확보할 수 있느냐로 화두가 옮겨가게 된 것입니다. 그러한 문제를 해결하기 위해 1991년에 OMG에 의해 CORBA(Common Object Request Broker Architecture) 1.0 명세서가 발표되었고 서로 다른 언어의 통신을 위한 인터페이스 언어(IDL, Interface Definition Language)를 고안해냈습니다.
<그림> ORB 아키텍처
위의 CORBA는 자바에게도 영향을 미치게 되었으며, 자바 언어끼리만의 통신인 RMI(Remote Method Invocation) 또한 그러한 영향을 많이 받았습니다. 이후 RMI의 기능에 리소스 관리, 라이프사이클, 트랜잭션, 보안 관리 등의 기능을 연계하여 개발자들의 수고들 덜어주겠다는 EJB(Enterprise Java Beans)가 등장하게 됩니다.
NOTE. EJB는 단순히 Java EE의 한 부분으로써 다른Java EE 서비스(네이밍, 트랜잭션, 보안, 서블릿 등)와 연계하여 사용한다.
이 EJB는 분산 구조의 비즈니스 컴포넌트를 만들 수 있는 특징을 이용하여 서블릿와 연계함으로써 비즈니스 애플리케이션을 만들 수 있는 방법으로 각광받기 시작하였고, 2000년대 초반의 대부분의 국내 금융 차세대 프로젝트에 이 기술을 이용하여 시스템을 구축하였습니다.
뒷담화 EJB는 분산 환경 구조 시스템을 가진 기업들이 도입을 시작하면서 주류로 자리 잡을 것처럼 보였지만 개발자들이 쉬운 접근을 막는 너무나 많은 예외처리, 동일 가상 머신 임에도 원격호출을 시도하는 RMI구조, 복잡한 설정의 퍼시스턴스, 트랜잭션 개념 등이 발목을 잡기 시작하였습니다.
특히나 퍼시스턴스는 이후 개발자들이 EJB 접근과 하이버네이트와 같은 강력한 OR맵핑 프레임워크에 거부감을 갖게 한 주범이나 다름없다고 봅니다. (사실 디자인 패턴도 한 몫 했다고 생각한다) 결국 개발자의 부담을 덜어주기 위해 만들어진 명세서가 되려 개발자들의 발목을 잡고 있는 셈이 되었던 것입니다.
그 때문에 EJB를 개발할 수 있던 고가의 개발자 구인, 개발 툴 도입 등이 프로젝트비용을 상승시켰으며, 성능 병목(원격 호출, 마샬링 등)을 해결하기 위한 추가적인 시스템 도입 등이 필요했습니다. 그러한 문제점들을 개선하려는 노력이 EJB2.0(Local 인터페이스 도입), EJB3.0(POJO방식의 OR Mapping개선)에도 지속되었지만 현재의 대부분의 프로젝트에서 사용되지 않고 있습니다.
결국 어려운 것을 사용함으로 인한 학습비용, 프로젝트 지연보다는 단순함을 생산성으로 연결시키는 것이 훨씬 더 바람직한 상황이 되었습니다. 하지만 반대 급부로 개발자는 더 이상 내부의 라이프사이클, 아키텍처 등에 대한 공부를 함으로써 내공을 쌓은 실력자가 되기보다는 AA(Application Architect) 들이 만들어놓은 공통 프레임워크에 업무만 더해가는 단순 노동자로 전락하는 현상을 만들게 되었습니다.
좀 더 자세한 내용이 궁금하다면 로드 존슨이 2004년에 내놓은 “Expert One-on-One J2EE Development without EJB(ISBN 10: 0764558315)”을 읽어보길 바랍니다.
앞선 단원에서는 웹 애플리케이션 서버라는 용어는 하나도 나오지 않았습니다. 왜냐하면 웹 애플리케이션 서버 자체가 앞서 설명한 자바의 시작과 중흥을 모두 아우르고 있기 때문입니다.
이제부터 앞선 내용과 결합한 웹 애플리케이션 서버에 대해 알아보도록 하겠습니다.
여러분들이 어디선가 들어보거나 익숙한 이름일 것이다. 애플리케이션 서버의 시초는 웹로직으로 거슬러 올라갑니다. 웹로직은 1995년 자바의 탄생과 동시에 만들어진 회사입니다. 초기의 솔루션은 순수 자바 기반의 분산 컴퓨팅 솔루션을 공급하던 업체였습니다.
웹로직는 초기에 CORBA, 오라클 데이터베이스, MSSQL 서버, dbKona/Sybase 등에 접근을 쉽게 제공하는 솔루션 회사였습니다. 또한 애플릿에서 데이터베이스 연결을 허용하는 ‘Three-tier’ 서버[2]도 개발하였습니다.
이후 1997년 11월 최초의 자바 애플리케이션 서버 Tangah를 개발하여 기업들에게 공급하였고, Tangah는 자바가 점차 확산하고 있는 시점에 웹로직 Tangah는 혁신 제품이었습니다. 이후 HTTP Servlet을 고성능으로 지원하였고, EJB, JNDI, SSL, 파일 전송, CORBA Client까지를 모두 지원하였습니다.
<그림. 초기 웹로직 디렉토리 구조>
웹로직사는 이후 1998년에 BEA Systems에 인수 합병되었고, 기존의 Tangah 애플리케이션 서버는 BEA 웹로직 서버로 이름을 변경하여 4.0부터는 BEA사의 제품으로 팔리게 되었습니다. BEA는 TP(Transaction Performance) 모니터 제품인 턱시도(Tuxedo)와 웹로직으로 전체 애플리케이션 서버 시장의 왕좌로 군림하게 됩니다.
BEA 웹로직은 이후 2008년 오라클에 인수되어 현재는 오라클 웹로직이라는 제품명으로 바뀌어 기업들에 공급되고 있습니다.
웹로직 Tangah가 개발된 지 1년만에 BEA로 인수되고, BEA는 1998년부터 2000년대 초반까지 웹 애플리케이션 서버 시장을 거의 독점하다시피 하였습니다. 이를 가만히 두고 볼 경쟁자는 없었을 것입이다. IBM이 도전장을 내밀었으나 웹스피어의 최초 버전이 1998년에 나온데다가 최초 버전은 서블릿 하나만 지원하고 있었고, 그나마 사용할 수 있는 버전이 3.5 버전이었기 때문에 안정화되기까지는 시간이 걸렸습니다. 이 때문에 BEA의 WAS 시장에서의 독주는 수년간 지속되었습니다.
이후 IBM은 기존의 하드웨어 업체에서 소프트웨어 업체로 변신을 거듭하면서 웹스피어 제품은 하드웨어 공급과 함께 빠르게 시작을 확대해 나가고, 웹로직의 대항마로 떠오르게 되었다. 오라클 또한 시장에 진입하기 위해 JServ를 포함시켰지만 이미 시장은 양분화된 상태로 지속이 되었습니다.
그 즈음 국내에서는 티맥스소프트가 웹 애플리케이션 서버인 제우스(Jeus)를 내놓고 공공시장을 기반으로 점차 그 영역을 확대해 나가기 시작했습니다. 언제나 그렇듯 시장에 경쟁자가 발생하게 되면 기업들은 서비스와 가격을 이용한 우위를 갖기 위해 노력하기 마련입니다. 이러한 분위기는 WAS 시장의 전반적인 가격 하락과 유지 보수 요율의 하락을 가져왔습니다. 소위 출혈 경쟁이 시작된 것입니다.
이후 2008년 WAS 시장에서 그리 두각을 나타내지 못하던 오라클이 BEA를 2008년 인수하면서 국내 자바 웹 애플리케이션 서버 시장은 IBM, 오라클, 티맥스의 3강 체제로 굳혀지게 되었지만 현재는 티맥스가 1위 체제를 유지하고 있습니다.
1999년, 프랑스의 엔지니어였던 마크 플러리(Marc Fleur)y는 JBoss 라는 이름의 작은 오픈 소스 프로젝트를 시작했습니다. 그 프로젝트는 J2EE 명세서의 Enterprise Java Bean (EJB) 부분에 대한 구현을 제공하기 위한 것이었는데, 이 프로젝트가 점차 유명해짐에 따라 커뮤니티의 개발자들은 프로젝트 관련 문서, 컨설팅 서비스, 교육 서비스를 판매하기 시작했습니다.
2001년 플러리와 동료들은 JBoss Group, LLC 라는 법인을 설립하고, 2002년부터는 개발자 지원을 제공하기 시작했습니다. 이 일이 진행되는 동시에 그들은 JBoss AS 3를 개발하였는데, 모든 Java EE스펙을 갖춘JBoss의 최초 버전이었습니다. 이는 IBM의 웹 스피어나 당시 BEA의 웹로직과 같은 다른 독점 애플리케이션 서버와 경쟁할 수 있는 수준의 것이었습니다.
NOTE. 프로젝트의 이름은 원래 EJBoss (Enterprise Java Bean Open Source Software)였습니다. 하지만, Sun이 자신들이 보유중인, EJB를 상표권으로 등록하였기 때문에, 프로젝트 명에서 E(Enterprise) 글자가 빠져 JBoss 라는 이름이 되었습니다.
JBoss Group LLC 는 2004년에 JBoss, Inc 로 사명을 변경하고, JBoss AS 4를 출시하면서 기업들을 위한 제품 지원 서비스를 제공하기 시작하였습니다. JBoss AS 4는 매우 유명한 애플리케이션 서버로 성장하였고, 여전히 업계에서 널리 사용되고 있습니다. JBoss Cache, Hibernate, jBPM, JBoss Rules 같은 JBoss AS 내에서 동작하는 많은 컴포넌트들이 JBoss AS 외부에서 독립적으로 동작할 수 있습니다.
하지만 국내에서는 오픈 소스라는 이유로 고객들이 가진 오해 – 보안에 약하다. 성능이 떨어진다 –를 극복하지 못하고 저조한 판매율을 보여오다 2011년 하반기부터 많은 국내 레퍼런스가 생기기 시작하였고, 현재는 공공기관의 표준 WAS로 사용되기에 이르렀습니다.
웹 애플리케이션 서버가 2000년대 도입되는 시기에 국내 기업들은 안정성, 성능 등을 확인하기 위해 BMT(Benchmark Test)를 수없이 수행했습니다. 외국의 경우 BMT 수행에 필요한 인건비, 라이선스, 장비 등은 고객사에서 부담하는 것이 원칙이었지만, 국내의 경우 이러한 부담을 고스란히 솔루션 업체들이 떠안고 제품으로 선정되기 위해 무상 지원을 하였습니다.
2005년 이후에는 웹 애플리케이션 서버가 인정받고 점차 안정화되었다는 인식에 따라 그 횟수가 현저하게 줄어들었습니다. 왜냐하면 서버 플랫폼 자체가 JVM이라는 화이트 박스에서 돌아가고 서버들의 처리 방식 또한 대동소이하기 때문에 사실 성능 BMT를 진행하더라도 많아 봐야 10%안팎의 성능 차이를 보일 뿐이었습니다. 그 성능 차이는 어떤 엔지니어가 BMT에 투입되느냐에 따라 다시 뒤집힐 수 있는 것들이었습니다. 웹 애플리케이션 서버 업계 엔지니어들 사이에서는 성능테스트인 BMT를 어떤 업체의 엔지니어가 더 잘하냐를 뽑는 엔지니어 테스트라고 우스개 소리로 이야기하곤 했습니다.
뒷담화 (2000년 초반 EAI 관련 BMT에 있었던 상황)
외국의 경우 BMT를 진행하게 되면 각 사의 엔지니어 수배 및 하드웨어 렌탈 등의 기타 부수적인 비용을 진행하는 회사에게 일임하고 비용을 지불하는 것이 의무화되어 있습니다. 하지만 국내의 경우 소위 말하는 횡포의 수준까지 도달을 하고 있는 데 필자가 하고 있던 BMT의 예를 들어보고 비용을 한 번 계산해 보도록 하지요.
S/W 비용(D/C 없이)
—————————————————————————
EAI Engine License : CPU당 1억 초반의 가격Load Runner : Socket 1000 user 한달 비용 대략 2억Oracle Enterprise DB : CPU 1억.
H/W비용
—————————————————————————
HP rx8620 32way 2대
HP rx8640 16way 1대
HP superdome 16way 2대
HP superdome 32way 2대 : DB용
인건비
—————————————————————————
Oracle 엔지니어 1명 1개월 : 대략 3000만원
HP 엔지니어 3명 * 2개월 : 1억 5천만원
S/W 개발 엔지니어 2명 * 2개월: 4000만원
EAI 엔지니어 1명 2개월 : 6000만원 위의 비용을 뽑아보면 인건비만 3억 가까이 됩니다. 고객에게 비용 부담에 대한 이야기를 꺼내면 대부분의 고객들은 이렇게 이야기합니다.”우리 회사랑 장사 그만하고 싶어요?”
지금까지 웹 애플리케이션 서버의 역사와 시장 상황에 대해서 살펴보았습니다. 현재의 상황을 이야기하기 위해 지금부터는 웹 애플리케이션 서버 위에 비즈니스 컴포넌트를 확장시킨 포탈, EAI, SOA에 대해 간략하게 살펴보도록 하겠습니다.
웹 애플리케이션 서버 시장이 폭발적으로 성장을 한 후 언제부턴가 그 성장폭이 줄어들게 되었습니다. 그 이유는 대부분의 기업들이 웹 애플리케이션 서버를 도입했기 때문이며, 이후 도입된 S/W 자산을 업그레이드만 시키면 됐기 때문입니다. 이에 벤더들은 다른 형태의 솔루션을 모색해야만 할 필요성이 있었을 것이란 추측(?)입니다.
바코드 시스템은 1932년에 고객의 자동 구매를 위한 프로젝트로 시작이 됐습니다. 하지만 실제 최초 설치된 것은 1960년대였고 활성화되기 시작한 것이 1980년대부터였습니다.
ERP(Enterprise Resource Planning)은 1960년초에 IMC(Inventory Management Control)이라는 재고 관리를 위한 시스템 개념으로부터 시작되어 1970년대 MRP(Manufacturing Resource Planning), CIM(Computer Integrated Manufacturing)으로 발전하면서 1990년대에 ERP 붐을 일으켰습니다.
CRM(Customer Relationship Management)는 전단지와 같은 카탈로그 마케팅(catalog marketing)으로 1950년대에 처음 시작이 되었고, SCM(Supply Chain Management)은 MRP II(1970년대)와 같이 시작해서 1990년대에 와서야 비로소 정착하게 되었습니다.
BPM(Business Process Management)의 경우는 1970년대 제록스의 OA(Office Automation) 개념으로 시작되었으니 딱 30년째 되던 2000년대에 어느 정도 성숙 단계로 접어들고 있습니다.(현재는 많이 사용안함)
위의 경우를 살펴보았을 때 우리가 현재 사용하고 있는 IT개념들이 정착되는데 걸리는 시간이 평균 30년임을 예상하고 다음의 개념들을 살펴보도록 하시죠.
EAI는 1990년대 메이저 ERP 사용 기업들이 시스템을 업그레이드 하면서 레거시 시스템과의 연계 요구로 처음 생겨나게 되었습니다. 이 때 TIBCO, Vitria, WebMethod, iWay 등의 전통 EAI 업체가 생겨나게 되었는데, 이 업체들의 특징을 살펴보면, 레거시 시스템과 연계하는 어댑터를 통해 기업 고객은 개발 생산성, 성능에 집중하도록 함으로써 고가의 어댑터를 공급하기 시작하였습니다.
이에 애플리케이션 서버 벤더들이 눈을 돌린 것이 하부의 레거시 시스템(Legacy, Proprietary) 이었습니다. 웹 애플리케이션 서버가 레드오션으로 전락함으로써 블루오션인 영역에 눈을 돌린 것입니다.
<그림> 스파게티 형태의 기업 내부 인프라스트럭처
이에 웹 애플리케이션 서버 벤더들은 기존의 애플리케이션 서버 위에 기존의 시스템들을 연결할 수 있는 레거시 어댑터를 탑재하여 하부의 시스템들을 연결할 수 있는 기능을 선보였습니다. 이러한 것들이 자바 표준에도 영향을 미쳐 RAR(Resource Archive) 형태의 어댑터 라이브러리를 통해 기존의 자원에 연결할 수 있는 명세서가 제정되었습니다.
레거시 시스템 연계를 편리하게 한다는 논리를 통해 기업고객들을 설득하였고, 2000 초반에 금융권을 중심으로 많은 EAI 프로젝트가 생겨났습니다. 당시 EAI를 도입하는 고객 측에서 고려했었던 사항은 다음과 같은 것들이었습니다.
정보 전략 파트:
l EAI를 도입했을 경우 나타나게 되는 전체 운영시스템에서의 이점은 무엇인가?
l EAI를 적용했을 경우 향후 ROI는 어떻게 되는 것인가?
l EAI 프로젝트를 진행하는 데 필요한 발생예산은 얼마인가?(기간, 유지보수 등)
l EAI 완료 후 향후 발생되는 프로젝트에 끼치는 영향은 무엇인가?
시스템 운영 파트:
l Control Tower에 대한 관심
l Timer에 의한 장애 발생시 대처를 어떻게 할 것인가?
l 전체 시스템을 모니터링할 수 있는 방법이 있는가?
l EAI 환경 구성 및 변경, 디플로이를 쉽게 할 수 있는가?
인프라 개발 파트:
l 개발시 데이터 정합성 보장을 어떻게 할 것인가?
l 각 시스템별 프로토콜을 처리하기 위한 효과적인 방안은 무엇인가?
l EAI를 도입함으로 인한 표준 거래 전문에 대한 변환을 어떤 방식으로 할 것인가?
l 거래를 잃어버렸을 경우 어떤 방식으로 처리해야 하는가?
l 2PC를 적용하여야 할 시스템은 무엇인가?
EAI는 단일 부서의 프로젝트의 사항이 아니었습니다. 이는 시스템과 연계되는 모든 부서의 공통된 작업이었고, 부서 간의 마찰도 빚을 수 있는 상황이었습니다. 게다가 EAI를 개발할 수 있는 도구들 또한 벤더에 종속될 수 있는 상황이었고, 개발을 위한 교육비용이 상당하였습니다.
<그림> 전형적인 EAI 아키텍처
생각해보세요. 위와 같은 그림을 통해 EAI를 구축한다고 했을 때 개발자들 중에 Tuxedo, EJB, Socket, SAP 등과 연계 애플리케이션 구축을 경험했던 개발자가 몇이나 있을까요? 이로 인해 EAI 개발자의 몸값은 현재의 클라우드 환경의 개발자처럼 상승하였고, 이는 고스란히 프로젝트 비용으로 연결되는 결과를 초래하였습니다.
보고서(Trotta, Gian(2003-12-15). “Dancing Around EAI ‘Bear Traps'”. http://www.ebizq.net/topics/int_sbp/features/3463.html. Retrieved on 2006-06-27)에 의하면 전세계의 70%의 EAI 프로젝트는 실패했다고 보고했다. 문제는 다음과 같았다고 기술합니다.
– 지속적인 기업환경 변화에 시스템이 따라주지 못함
– 대상 시스템에 대한 전문가 부재
– 각 사용자 부서와 협업, 의사 소통이 제대로 이루어지지 않아 인터페이스 도출 어려움
– 기술, 문화, 정치적인 이유로 부서의 시스템을 다른 사업부에 보여주기 원치 않음
– 많은 부서 참여로 인한 요구 사항 중첩 및 해결책 모호로 인하여 최종 시스템 구조가 명확하지 않음
EAI 프로젝트의 가장 큰 폐해 요소로 기업들은 해당 패키지 애플리케이션 벤더 및 EAI 벤더에게 종속(lock-in) 되었다고 보고되었습니다.
벤더 종속은 고객이 벤더, 제품, 서비스에 의존한 나머지 신규 시스템 도입시 다른 제품을 고려하지 못하고, 다시 묶임으로써 추가적인 비용이 발생하여 시장에 빠르게 진입하지 못하는 현상을 일컫습니다. 예를 들어 가장 대표적인 케이스의 생활 벤더 종속은 DSLR 카메라가 아닐까 싶습니다. 타사의 성능이 좋은 렌즈를 구입하고 싶을 때, 해당 렌즈만을 구입하는 것이 아니라 카메라 바디를 바꾸어야 하는 전환 비용(switch-cost)가 발생을 하게 되는 경우입니다.
국내의 EAI 프로젝트를 보더라도 실제 공공, 제조는 거의 제로에 가깝다고 말할 수 있고 그나마 통신, 금융이 복잡한 시스템들로 인하여 도입을 한 경우가 상당수 있습니다. 문제는 도입됨과 동시에 앞서 언급한 상황이 발생할 수 있다는 것입니다.
너무 부정적인 면으로 흐르기 때문에 EAI 이야기는 여기서 끊도록 하겠습니다. 중요한 것은 EAI가 하부의 복잡한 레거시 시스템에 대한 단일 접점을 제공함으로써 메시지 표준화, 프로토콜 표준화 등을 통해 시스템 재사용성을 높일 수 있다는 것입니다. 단 그것이 명확한 기준으로 잘 개발되었을 때라는 전제가 있습니다.
그러면 하부(레거시) 시스템 연계에 대한 재사용성을 높일 수 있다고 했는데 웹 애플리케이션 페이지의 재사용성은 높일 수 없을까? 벤더들은 포탈에 그 답이 있다고 이야기합니다.
자바에서 이야기하는 포탈을 한 문장으로 요약하자면, 포틀릿이라는 컴포넌트를 개인화시킨 웹 사이트라고 지칭할 수 있습니다. 포틀릿 명세서(JSR-168, JSR-286)를 잠깐 살펴보면 포틀릿은 서블릿과 같은 형태의 웹 컴포넌트이지만, 포탈 웹페이지에 삽입되어 실행될 수 있는 속성들을 가지고 있습다. 서로 다른 사용자 및 인스턴스 포탈 데이터 별 파라미터에 따라, 동일한 포틀릿에 대한 다수의 인스턴스들은 동일한 포탈 페이지에 같이 놓일 수 있습니다.
말이 필요없습니다. 백문이불여일견(百聞不如一見)이라 했습니다. 지금(2013년 11월)은 서비스를 종료했지만 기존에 구글의 iGoogle이라는 포탈서비스가 존재했었습니다.
구글의 페이지가 사실 자바 포틀릿은 아니지만 자바의 포틀릿과도 연동이 되며, 포틀릿의 개념을 체험해 볼 수 있는 좋은 도구였습니다. 포틀릿 컴포넌트의 재사용성에 대해서는 위 그림의 왼쪽 위편에 보이는 가젯을 눌러보면 알 수 있습니다. 구글에서 이야기하는 가젯이 자바에서는 재사용 가능한 포틀릿으로 인식될 수 있습니다. 가젯을 눌러보면 수만 개의 가젯이 검색되고 원하는 가젯을 추가하면 igoogle에 추가되는 것을 볼 수 있었습니다.
가젯은 포탈 내부에서 이동이 가능하며, 배치를 원하는 형태로 바꿀 수 있었습니다. 즉 개인화(Personalization)의 강점을 최대한 살려놓은 것입니다. 개인화는 포탈의 대표적인 특징으로 대변될 수 있습니다.
이러한 개념을 벤더들은 포탈이라는 웹 애플리케이션 서버 위의 포틀릿 컨테이너를 만들어 실행하고 있습니다. 기업 고객들은 다양한 사용자 군을 가지고 있습니다. 가령 기업이 제조회사라고 하면 영업, 생산, 마케팅, CxO(CEO, CFO, CIO 등을 일컫는 말) 영역이 있다고 했을 때 그들이 사용한 시스템을 별도로 만든다는 것은 비용이 상당히 들어가는 작업이며, 각 애플리케이션들이 공통의 데이터(로그인, 권한, 생산실적, 판매실적, 영업망 등)를 다루게 될 확률이 높아집니다.
기업 내 공통 웹 화면에 해당하는 것을 미리 포틀릿 컴포넌트를 만들고, 그것을 프로젝트에서 가져다 사용하면 어떨까요? 미리 구성되어 있으니, 연결하는 속성만 알고 있다면 각 사용자를 위한 개인형 포탈이 쉽게 개발될 수 있을 것입니다. 이에 따라 포탈 제품들이 나오게 되었고, 이 또한 EAI와 같이 많은 기업들이 도입을 하기 시작했습니다. 영업포탈, 사용자 포탈, 부서 포탈, 마케팅 포탈 등은 포틀릿 재사용을 통해 사이트가 구축되었습니다.
사실 초기에는 개인화를 하기 위해 각 개개인이 설정한 정보를 LDAP 등에 저장하여 사용하는데, 로그인시 권한, 페이지 구성 등에 대한 내용이 너무도 복잡한데다, 그것을 웹 세션 등에 저장함으로 인해 과도한 메모리 소비, 성능 문제를 야기함으로써 많은 시행착오를 겪게 되었습니다.
그럼에도 불구하고 포탈의 개념은 많은 장점들을 가지고 있었으며, 여기서는 설명하지 않는 BPM, 위에서 설명한 EAI 등과 연계되었을 경우 논리적인 관점에서 가장 이상적인 아키텍처를 표현하게 됩니다. EAI와 함께 포탈을 도입하는 고객들은 모든 레이어가 재사용이라는 주제 아래에서 프로젝트의 신속성을 통한 Time To Market이라는 기업의 궁극적인 목표를 달성해 줄 것처럼 보였기 때문이었습니다.
얼마나 시장에 발 빠르게 대응하느냐의 문제, 즉 Time to Market은 기업 생존의 기본 요소였고 지금도 그렇습니다. 기업들이 비즈니스를 하는 목적은 이익일 것이고 그러기 위해 얼마 전까지만 해도 양질의 제품을 얼마나 많이 제공하느냐가 가장 중요한 문제였습니다. 하지만 최근 시장이 너무도 빠르게 변화함에 따라 시장에 얼마나 발 빠르게 대응하느냐가 기업의 수익에 있어서 가장 큰 변수로 작용하고 있습니다. 다른 경쟁 기업에 비해 새로운 아이디어를 제품으로 더 빨리 내놓기 위해서는 IT 환경의 다이내믹한 지원이 절대적으로 필요해지고 있는 것입니다. 이를 벤더들이 가만히 보고 있지 않았을 것입니다. SOA의 탄생은 여기서 시작합니다.
기업의 변화를 가로막는 3대 요인은 다음과 같습니다.
l 복잡성(Complexity) : 다양한 사람, 프로세스, 부서
l 경직성(Inflexibility) : “현 상태에 문제없으면 굳이 바꿀 필요 없다”
l 취약성(Brittleness) : 복잡성과 경직성으로 인한 이상의 발생 위험성
1996년 가트너 보고서에는 이런 말이 실립니다..
“잘 정의된 인터페이스를 가진 재사용이 가능한 일련의 컴포넌트들로 구축되는 기술 구조 방식을 SOA(Service Oriented Architecture)라 한다”
벤더에게 딱 맞는 말이 아닐까 합니다. 비즈니스적인 용어이지만 무엇인지 그것을 이용해 새로운 무언가를 만들기 위한 좋은 단어임에는 틀림없어 보입니다. 일련의 컴포넌트, 위에서 이야기한 포틀릿과 어댑터를 통한 애플리케이션입니다.
이제 컴포넌트를 서비스로 바꾸어 생각해보죠. 서비스라는 용어를 다시 IT가 아닌 비즈니스로 생각해봅시다. 현재까지 기업에서 IT적인 요소가 필요할 경우, 컨설팅을 통해 프로젝트를 계획하고 여러 단계를 거쳐 프로젝트 수행으로 지원했던 반면 향후에는 서비스(Service)라는 단위로 IT로의 접근 및 활용해야 한다고 주장했습니다.
또한 새로운 상품에 대한 기획 안이나 아이디어들이 IT 환경에서 즉시 활용되기 위해서는 업무적으로 바로 활용할 수 있는 서비스 단위로 구성된 각 조각들을 마치 어린이용 블럭을 조립하듯 설계와 시뮬레이션이 되어야 한다고 말합니다. 이것은 SOA를 선전하는 벤더들이 시장에서 BPM과 같은 제품들을 SOA 영역에 포함시키는 이유이기도 했습니다.
SOA는 아키텍처이지 기술이 아닙니다. SOA를 구현하는 기술들은 ESB, 포틀릿, 리포지토리, 웹 서비스, 어댑터 등의 다양한 기술들이 존재합니다. SOA에서 가장 중요한 서비스는 업무적인 단위이고, 하나의 업무를 수행하기 위해서는 여러 시스템에 걸쳐 정보를 조회하거나 트랜잭션을 발생시켜야 하는 경우가 많습니다. 이를 구현하기 위한 앞서 언급한 다양한 기술들을 사용해야 하지만, 그러한 방식 모두가 모든 기업 환경에서 사용하기에 적당하다고는 할 수 없습니다.
SOA가 가트너에 의해 언급된 지 어느덧 20여년이 넘는 시간이 흘렀습니다. 국내 시장의 경우에는 SOA가 소개되는 과정에서 관련 벤더들의 몫이 컸습니다. 벤더들은 자사의 제품을 소개하는 과정에서 SOA를 대대적으로 홍보하기 시작했고, 실제로 수많은 개발자들이 그런 벤더들의 세미나나 제품 소개를 통해 SOA를 처음 접하고 알게 되었습니다. 이런 이유로 개발자의 입장에서는 SOA의 개념과 실체가 다소 왜곡된 형태로 전달될 수밖에 없었습니다.
SOA가 서비스가 유기적으로 잘 동작하려면 다음의 특성들을 가지고 있어야 했습니다.
● 프로세스 통합의 구조
프로세스를 가진 각각의 노드들이 업무적인 단위의 서비스로 표출되고 그것을 업무 관련 담당자가 설계에 참여할 수 있어야 합니다. IT로 전환될 때 설정치에 따라 시뮬레이션되고 결과 예측이 가능해야 합니다. 벤더에서는 BPM 제품을 통해 프로세스를 지원하고 있습니다.
● 시스템 통합의 구조
기존 EAI 시스템에서 담당했던 것과 유사한 기능의 구조를 제공해야 합니다. 업무적인 단위인 서비스는 여러 시스템과 관련될 가능성이 높습니다. 그러므로 해당 시스템의 최적화된 프로토콜 방식이나 웹 서비스와 같은 좀 더 표준화된 방식의 지원이 모두 가능해야 합니다. 보통 SOA 제품군에서는 ESB(Enterprise Service Bus)를 통해 이를 지원하고 있습니다.
● 데이터 통합의 구조
시스템의 통합은 보통 애플리케이션(application)간의 인터페이스를 뜻하는 경우가 많으며 여러 시스템에 흩어진 여러 가지 형태(DB, File, LDAP 등)의 데이터들을 하나의 관점에서 바라볼 수 있게 하는 구조가 필요합니다. 더 나아가서는 하나의 관점에서 바라보는 것과 더불어 여러 가지 프로그램 언어나 인터페이스 방식으로 해당 데이터에 대한 조회나 트랜잭션을 할 수 있는 방안을 제공하는 것도 필요합니다. 벤더들은 EII(Enterprise Information Integration) 제품을 통해 이를 지원하고 있습니다.
하지만 SOA의 문제는 무엇일까요? 아이러니하게도 EAI에서 발전된 양상이니 만큼 EAI가 가졌던 한계성을 극복하지 못한 것으로 필자는 보고 있습니다. 컴포넌트가 업무 단위의 서비스로 올라오긴 했지만 여전히 업무에 연관된 이들이 너무 많은 관계로 이를 조직적인 차원의 통제(Governance)가 이루어지지 않으면 성공하기란 하늘의 별따기 수준이었습니다.
<그림> SOA 프로젝트의 핵심은 통제(Governance)였다.
전사적인 차원의 접근이 필요한 SOA 프로젝트가 부서간의 경쟁이 이루어지는 기업 조직에서 자신들의 업무를 타 부서에 공개하고 공통의 서비스를 찾아낸다는 게 쉽지 않은 일이었습니다. 2005년도 전후에 기고된 문서들을 읽어보면 그 때는 장밋빛 전망을 상당수 내놓았었습니다. 우리는 현실에 살고 있지 이상(理想) 속에서 살지 않습니다. 성공 사례(Best Practice)가 없다는 이야기는 이상이 현실이 되지 못했다는 이야기일 수도 있습니다.
대략 IT트렌드는 여기서 접겠습니다. 이후 무수히 나타난 개념들은 결국 현재의 종착역인 클라우드로 모이고 있습니다. 웹 애플리케이션 서버 관점에서 위의 정도를 알아두면 좋기 때문에 기술한 것입니다.
IBM, Oracle, SAP 등의 SOA제품을 가진 벤더 공통점은 무엇일까요? 그것은 앞서 나열한 개념을 구현한 제품들이 웹 애플리케이션 서버 위에서 만들어진 비즈니스 서비스 컴포넌트를 위한 컨테이너(포틀릿, BPM, ESB등)일 뿐이었다는 것입니다.
근래에 들어 이러한 서비스 개념에 대한 부분은 상당 부분 사라졌으며, 웹 애플리케이션 서버의 기본 항목을 이용한 스프링 프레임워크와 같은 도구를 사용하여 개발하여 가장 가벼운 형태의 개발이 다시 주를 이루고 있습니다.
전자정부 프레임워크 또한 표준 기반의 자바를 활용하여 벤더에 종속적이지 않은 코드를 만들어낼 수 있도록 고안되어 상당수 정부 기관의 프로젝트에서 사용중에 있습니다. 이로 인해 기존의 표준 WAS로 제정되었던 제우스, 웹로직과 같은 라이선스 비용이 비싸고, 유지보수 비용에 상당한 투자가 들어가는 부분을 오픈소스 SW기반의 WAS로 전환하고자 하는 움직임이 계속되고 있습니다.
기존 상용 WAS를 오픈소스SW 기반의 WAS로 전환했을 때 얻는 이점을 상당히 많으며, 이는 WAS 뿐만 아닌 다른 소프트웨어의 경우도 마찬가지로 볼 수 있다.
[표] 상용 소프트웨어와 오픈소스 소프트웨어의 비교
| 구분 | 상용 소프트웨어 | 오픈소스 소프트웨어 |
| 비용분석 | – 적용비용이 적음 – 유지비용 및 시스템 개선비용이 높음(윈도우계열) – 소수의 관리자에 대한 관리비용 높음 – 라이선스 수수료에 대한 비용발생 | – 적용비용이 낮음(무료)- 유지비용이 낮고 기능확장에 대한 추가비용이 들지 않음 – 다수의 공개된 사용자에 의한 관리로 관리자에 대한 관리비용이 낮음. – 서비스에 대한 비용발생 |
| 성능분석 | – 규모가 큰 시스템 환경에서 비교적 높은 성능 – 고가의 장비로 인한 고성능 – 전체적으로 공개SW와 비슷한 성능 | – 규모가 작은 시스템환경에서 높은 성능 – 높은 안정성 및 비용효율이 높음 |
| 보안성 | – 폐쇄적인 운영으로 인한 공개되지 않은 시스템 취약점 보유 – 최근에 다수의 취약점 발견으로 많은 보안 위협에 노출 – 프로토콜 호환이 어려워 인증체계가 취약함 | – 개발 시부터 공개되어 이미 많은 취약점이 해결된 안전화 상태 – 공개키 기반의 인증 메커니즘 구현을 위한 통합패키지존재(적용이 용이) – 다양한 암호화 알고리즘 및 키 관리에 대한 기능 제공 |
| 경제성 | – TCO 높음 – 구입비, 유지비가 높음 | – TCO낮음 – 라이센스 비용없음 |
| 기술성 | – 재 사용성 없음 | – 재 사용성 높음 – 유지보수, 업그레이드 용이 – 독점폐해방지 |
| 저작권 | – 일반 라이선스 – 독과점에 의한 가격결정우려 | – GPL라이선스, BSD라이선스 등 |
| 확장성 | – 서버의 가용성 측면에서 클러스터링 비효율성 – 소프트웨어간의 호환성이 보장되나 높은 적용비용과 제한된 시스템 운영환경 | – 효율적인 클러스터링 구현가능 – 소프트웨어간의 호환성이 조금 떨어지나 적용비용이 거의 들지 않고 낮은 수준에서의 기능추가 가능 |
| 경쟁력 | – 소프트웨어선진국에 유리 | – 공동개발상식에 따른 효과우수 |
현재 웹 애플리케이션 서버 시장에서 공개 SW가 가지는 영향력은 상당합니다. 2012년 ZeroTurnAround사에서 진행한 개발 관련 서버 시장 조사의 웹 애플리케이션 서버 영역에 대한 결과는 아래와 같이 나타나고 있습니다.(2014년도 비슷함)
| 서버 이름 | 시장 점유율 |
| GlassFish | 11% |
| WebSphere | 10% |
| WebLogic | 14% |
| JBoss | 28% |
| Jetty | 27% |
| Tomcat | 59% |
현재 전세계의 애플리케이션 서버 시장 자체가 오픈소스SW 형태로 전환되고 있으며, 상용 SW 벤더로부터의 이탈이 점차 빨라질 것으로 예상하고 있습니다.
자바 웹 애플리케이션 서버에서 시작한 다양한 컴포넌트들이 다시 순수 기능으로 회귀하고 있는 상태입니다. “Simple is the best”를 알고 있다면 그것을 어떻게 효과적으로 사용하고 상호 운용성을 높일 수 있는지가 현재 IT 시스템을 만드는데 있어 화두입니다.
다음 번 글에서는 요즘 사용되고 있는 아키텍처링 기법 등에 대해 설명하고자 합니다.
긴 글 읽어주셔서 감사합니다.
[1]. 사실 이는 ERP 초창기인1960년대부터 시스템 분산이 시작되었다.
[2] 현재 웹로직의 t3 프로토콜은 three-tier server란 이름에서 변형되었다.
