1 웹 애플리케이션 서버

여러분은  웹 애플리케이션 서버라는 용어를 언제 처음 들었봤나요 ? IT 학원 붐이 일던 2000 년대 초반 ? 아니면 학교에서 프로그래밍을 공부하던 때로 거슬러 올라가야하나요 ?

웹 애플리케이션 서버를 잘 모르시거나 시초에 대한 흥미와 IT트렌드에 관심을 가진다면 이 글을 가볍게 읽어주시면 됩니다.

자바 웹 애플리케이션 서버의 역사를 살펴보자면 사실 자바라는 언어에서 시작하는 수고스러움을 겪어야 합니다 .

1.1 자바의 시작을 제대로 알고 있는가 ?

본 글을 대하는 여러분은 대부분 자바를 주 언어로 이용하고 있을 것입니다 . 하지만 예전에 제가 강의를 할 때 수강생분에게 물어보면 대부분 자바가 언제 어떻게 탄생했는지 알고 있는 분들이 거의 없습니다 .

1.1.1 자바의 시작

탄생의 역사는 지금으로부터 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) 을 가리킨다고 봐도 됩니다 .

1.1.2 자바의 폭발적 성장

앞서 이야기한 것처럼 초기의 자바는 가전을 위한 목적으로 만들어졌습니다 . 하지만 초기 버전에 애플릿 (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.1.3 엔터프라이즈 영역의 확대

서블릿이 각광을 받던 즈음 각 기업들이 비용이 싸진 개방형 시스템 ( 유닉스 기반 ) 을 도입하게 되면서 각 업무 시스템들은 기존의 중앙 집중형이 아닌 분산된 시스템 구조로의 변화를 일으키게 됩니다 . 즉 인사 , 마케팅 , 영업 , 생산 , 자재 시스템 등이 각 사업부별로 분산되어 구축되고 관리되기 시작한 것입니다 . [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)” 을 읽어보길 바랍니다 .

1.2 웹 애플리케이션 서버

앞선 단원에서는 웹 애플리케이션 서버라는 용어는 하나도 나오지 않았습니다 . 왜냐하면 웹 애플리케이션 서버 자체가 앞서 설명한 자바의 시작과 중흥을 모두 아우르고 있기 때문입니다 .

이제부터 앞선 내용과 결합한 웹 애플리케이션 서버에 대해 알아보도록 하겠습니다.

1.2.1 애플리케이션 서버의 시초 : WebLogic Inc.

여러분들이 어디선가 들어보거나 익숙한 이름일 것이다 . 애플리케이션 서버의 시초는 웹로직으로 거슬러 올라갑니다 . 웹로직은 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 년 오라클에 인수되어 현재는 오라클 웹로직이라는 제품명으로 바뀌어 기업들에 공급되고 있습니다 .

1.2.2 블루오션에서 레드오션으로

웹로직 Tangah 가 개발된 지 1 년만에 BEA 로 인수되고 , BEA 1998 년부터 2000 년대 초반까지 웹 애플리케이션 서버 시장을 거의 독점하다시피 하였습니다 . 이를 가만히 두고 볼 경쟁자는 없었을 것입이다 . IBM 이 도전장을 내밀었으나 웹스피어의 최초 버전이 1998 년에 나온데다가 최초 버전은 서블릿 하나만 지원하고 있었고 , 그나마 사용할 수 있는 버전이 3.5 버전이었기 때문에 안정화되기까지는 시간이 걸렸습니다 . 이 때문에 BEA WAS 시장에서의 독주는 수년간 지속되었습니다 .

이후 IBM 은 기존의 하드웨어 업체에서 소프트웨어 업체로 변신을 거듭하면서 웹스피어 제품은 하드웨어 공급과 함께 빠르게 시작을 확대해 나가고 , 웹로직의 대항마로 떠오르게 되었다 . 오라클 또한 시장에 진입하기 위해 JServ 를 포함시켰지만 이미 시장은 양분화된 상태로 지속이 되었습니다 .

그 즈음 국내에서는 티맥스소프트가 웹 애플리케이션 서버인 제우스 (Jeus) 를 내놓고 공공시장을 기반으로 점차 그 영역을 확대해 나가기 시작했습니다 . 언제나 그렇듯 시장에 경쟁자가 발생하게 되면 기업들은 서비스와 가격을 이용한 우위를 갖기 위해 노력하기 마련입니다 . 이러한 분위기는 WAS 시장의 전반적인 가격 하락과 유지 보수 요율의 하락을 가져왔습니다 . 소위 출혈 경쟁이 시작된 것입니다 .

이후 2008 WAS 시장에서 그리 두각을 나타내지 못하던 오라클이 BEA 2008 년 인수하면서 국내 자바 웹 애플리케이션 서버 시장은 IBM, 오라클 , 티맥스의 3 강 체제로 굳혀지게 되었지만 현재는 티맥스가 1위 체제를 유지하고 있습니다 .

1.2.3 JBoss 웹 애플리케이션 서버

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로 사용되기에 이르렀습니다 .

1.2.4 WAS BMT 가 아직도 성행하는가 ?

웹 애플리케이션 서버가 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 에 대해 간략하게 살펴보도록 하겠습니다.

1.3 EAI, Portal 그리고 SOA

웹 애플리케이션 서버 시장이 폭발적으로 성장을 한 후 언제부턴가 그 성장폭이 줄어들게 되었습니다 . 그 이유는 대부분의 기업들이 웹 애플리케이션 서버를 도입했기 때문이며 , 이후 도입된 S/W 자산을 업그레이드만 시키면 됐기 때문입니다 . 이에 벤더들은 다른 형태의 솔루션을 모색해야만 할 필요성이 있었을 것이란 추측(?)입니다 .

1.3.1 개념을 IT 화시키는 데 걸리는 평균 시간 30년

바코드 시스템은 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 년임을 예상하고 다음의 개념들을 살펴보도록 하시죠 .

1.3.2 EAI(Enterprise Application Integration)

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 가 하부의 복잡한 레거시 시스템에 대한 단일 접점을 제공함으로써 메시지 표준화 , 프로토콜 표준화 등을 통해 시스템 재사용성을 높일 수 있다는 것입니다 . 단 그것이 명확한 기준으로 잘 개발되었을 때라는 전제가 있습니다 .

그러면 하부 ( 레거시 ) 시스템 연계에 대한 재사용성을 높일 수 있다고 했는데 웹 애플리케이션 페이지의 재사용성은 높일 수 없을까 ? 벤더들은 포탈에 그 답이 있다고 이야기합니다 .

1.3.3 Portal

자바에서 이야기하는 포탈을 한 문장으로 요약하자면 , 포틀릿이라는 컴포넌트를 개인화시킨 웹 사이트라고 지칭할 수 있습니다 . 포틀릿 명세서 (JSR-168, JSR-286) 를 잠깐 살펴보면 포틀릿은 서블릿과 같은 형태의 웹 컴포넌트이지만 , 포탈 웹페이지에 삽입되어 실행될 수 있는 속성들을 가지고 있습다 . 서로 다른 사용자 및 인스턴스 포탈 데이터 별 파라미터에 따라 , 동일한 포틀릿에 대한 다수의 인스턴스들은 동일한 포탈 페이지에 같이 놓일 수 있습니다 .

말이 필요없습니다 . 백문이불여일견 ( 百聞不如一見 ) 이라 했습니다 . 지금(2013년 11월)은 서비스를 종료했지만 기존에 구글의 iGoogle이라는 포탈서비스가 존재했었습니다.

http://www.google.com/ig


구글의 페이지가 사실 자바 포틀릿은 아니지만 자바의 포틀릿과도 연동이 되며 , 포틀릿의 개념을 체험해 볼 수 있는 좋은 도구였습니다 . 포틀릿 컴포넌트의 재사용성에 대해서는 위 그림의 왼쪽 위편에 보이는 가젯을 눌러보면 알 수 있습니다 . 구글에서 이야기하는 가젯이 자바에서는 재사용 가능한 포틀릿으로 인식될 수 있습니다 . 가젯을 눌러보면 수만 개의 가젯이 검색되고 원하는 가젯을 추가하면 igoogle 에 추가되는 것을 볼 수 있었습니다 .




가젯은 포탈 내부에서 이동이 가능하며 , 배치를 원하는 형태로 바꿀 수 있었습니다 . 즉 개인화 (Personalization) 의 강점을 최대한 살려놓은 것입니다 . 개인화는 포탈의 대표적인 특징으로 대변될 수 있습니다 .

이러한 개념을 벤더들은 포탈이라는 웹 애플리케이션 서버 위의 포틀릿 컨테이너를 만들어 실행하고 있습니다 . 기업 고객들은 다양한 사용자 군을 가지고 있습니다 . 가령 기업이 제조회사라고 하면 영업 , 생산 , 마케팅 , CxO(CEO, CFO, CIO 등을 일컫는 말 ) 영역이 있다고 했을 때 그들이 사용한 시스템을 별도로 만든다는 것은 비용이 상당히 들어가는 작업이며 , 각 애플리케이션들이 공통의 데이터 ( 로그인 , 권한 , 생산실적 , 판매실적 , 영업망 등 ) 를 다루게 될 확률이 높아집니다 .

기업 내 공통 웹 화면에 해당하는 것을 미리 포틀릿 컴포넌트를 만들고 , 그것을 프로젝트에서 가져다 사용하면 어떨까요 ? 미리 구성되어 있으니 , 연결하는 속성만 알고 있다면 각 사용자를 위한 개인형 포탈이 쉽게 개발될 수 있을 것입니다 . 이에 따라 포탈 제품들이 나오게 되었고 , 이 또한 EAI 와 같이 많은 기업들이 도입을 하기 시작했습니다 . 영업포탈 , 사용자 포탈 , 부서 포탈 , 마케팅 포탈 등은 포틀릿 재사용을 통해 사이트가 구축되었습니다 .

사실 초기에는 개인화를 하기 위해 각 개개인이 설정한 정보를 LDAP 등에 저장하여 사용하는데 , 로그인시 권한 , 페이지 구성 등에 대한 내용이 너무도 복잡한데다 , 그것을 웹 세션 등에 저장함으로 인해 과도한 메모리 소비 , 성능 문제를 야기함으로써 많은 시행착오를 겪게 되었습니다 .

그럼에도 불구하고 포탈의 개념은 많은 장점들을 가지고 있었으며 , 여기서는 설명하지 않는 BPM, 위에서 설명한 EAI 등과 연계되었을 경우 논리적인 관점에서 가장 이상적인 아키텍처를 표현하게 됩니다 . EAI 와 함께 포탈을 도입하는 고객들은 모든 레이어가 재사용이라는 주제 아래에서 프로젝트의 신속성을 통한 Time To Market 이라는 기업의 궁극적인 목표를 달성해 줄 것처럼 보였기 때문이었습니다 .

얼마나 시장에 발 빠르게 대응하느냐의 문제 , Time to Market 은 기업 생존의 기본 요소였고 지금도 그렇습니다 . 기업들이 비즈니스를 하는 목적은 이익일 것이고 그러기 위해 얼마 전까지만 해도 양질의 제품을 얼마나 많이 제공하느냐가 가장 중요한 문제였습니다 . 하지만 최근 시장이 너무도 빠르게 변화함에 따라 시장에 얼마나 발 빠르게 대응하느냐가 기업의 수익에 있어서 가장 큰 변수로 작용하고 있습니다 . 다른 경쟁기업에 비해 새로운 아이디어를 제품으로 더 빨리 내놓기 위해서는 IT 환경의 다이내믹한 지원이 절대적으로 필요해지고 있는 것입니다 . 이를 벤더들이 가만히 보고 있지 않았을 것입니다 . SOA 의 탄생은 여기서 시작합니다 .

1.3.4 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 ) 일 뿐이었다는 것입니다 .

1.3.5 웹 애플리케이션 서버 순수 기능으로의 회귀

근래에 들어 이러한 서비스 개념에 대한 부분은 상당 부분 사라졌으며 , 웹 애플리케이션 서버의 기본 항목을 이용한 스프링 프레임워크와 같은 도구를 사용하여 개발하여 가장 가벼운 형태의 개발이 다시 주를 이루고 있습니다 .

전자정부 프레임워크 또한 표준 기반의 자바를 활용하여 벤더에 종속적이지 않은 코드를 만들어낼 수 있도록 고안되어 상당수 정부 기관의 프로젝트에서 사용중에 있습니다 . 이로 인해 기존의 표준 WAS 로 제정되었던 제우스 , 웹로직과 같은 라이선스 비용이 비싸고 , 유지보수 비용에 상당한 투자가 들어가는 부분을 오픈소스 SW 기반의 WAS 로 전환하고자 하는 움직임이 계속되고 있습니다 .

기존 상용 WAS 를 오픈소스 SW 기반의 WAS 로 전환했을 때 얻는 이점을 상당히 많으며 , 이는 WAS 뿐만 아닌 다른 소프트웨어의 경우도 마찬가지로 볼 수 있다 .

[ ] 상용 소프트웨어와 오픈소스 소프트웨어의 비교

<table border="1" cellpadding="0" cellspacing="0" style="border-collapse:collapse;border:none;mso-border-left-alt:solid black .25pt; mso-border-bottom-alt:solid black .25pt;mso-border-right-alt:solid black .25pt; mso-table-overlap:never;mso-yfti-tbllook:1184" table"="">

구분

상용 소프트웨어

오픈소스 소프트웨어

비용분석

- 적용비용이 적음
-
유지비용 및 시스템 개선비용이 높음 ( 윈도우계열 )
-
소수의 관리자에 대한 관리비용 높음
-
라이선스 수수료에 대한 비용발생

- 적용비용이 낮음 ( 무료 )

- 유지비용이 낮고 기능확장에 대한 추가비용이 들지 않음
-
다수의 공개된 사용자에 의한 관리로 관리자에 대한 관리비용이 낮음 .
-
서비스에 대한 비용발생

성능분석

- 규모가 큰 시스템 환경에서 비교적 높은 성능
-
고가의 장비로 인한 고성능
-
전체적으로 공개 SW 와 비슷한 성능

- 규모가 작은 시스템환경에서 높은 성능
-
높은 안정성 및 비용효율이 높음

보안성

- 폐쇄적인 운영으로 인한 공개되지 않은 시스템 취약점 보유
-
최근에 다수의 취약점 발견으로 많은 보안 위협에 노출
-
프로토콜 호환이 어려워 인증체계가 취약함

- 개발 시부터 공개되어 이미 많은 취약점이 해결된 안전화 상태
-
공개키 기반의 인증 메커니즘 구현을 위한 통합패키지존재 ( 적용이 용이 )
-
다양한 암호화 알고리즘 및 키 관리에 대한 기능 제공

경제성

- TCO 높음
-
구입비 , 유지비가 높음

- TCO 낮음
-
라이센스 비용없음

기술성

- 재 사용성 없음

- 재 사용성 높음
-
유지보수 , 업그레이드 용이
-
독점폐해방지

저작권

- 일반 라이선스
-
독과점에 의한 가격결정우려

- GPL 라이선스 , BSD 라이선스 등

확장성

- 서버의 가용성 측면에서 클러스터링 비효율성
-
소프트웨어간의 호환성이 보장되나 높은 적용비용과 제한된 시스템 운영환경

- 효율적인 클러스터링 구현가능
-
소프트웨어간의 호환성이 조금 떨어지나 적용비용이 거의 들지 않고 낮은 수준에서의 기능추가 가능

경쟁력

- 소프트웨어선진국에 유리

- 공동개발상식에 따른 효과우수

</table>

1.3.6 웹 애플리케이션 서버 시장 현황

현재 웹 애플리케이션 서버 시장에서 공개 SW 가 가지는 영향력은 상당합니다 . 2012 ZeroTurnAround 사에서 진행한 개발 관련 서버 시장 조사의 웹 애플리케이션 서버 영역에 대한 결과는 아래와 같이 나타나고 있습니다 .(2014년도 비슷함)





<table border="1" cellpadding="0" cellspacing="0" style="margin-left:26.4pt;border-collapse:collapse;border:none;mso-border-left-alt: solid black .25pt;mso-border-bottom-alt:solid black .25pt;mso-border-right-alt: solid black .25pt;mso-yfti-tbllook:1184" table"="">

서버 이름

시장 점유율

GlassFish

11%

WebSphere

10%

WebLogic

14%

JBoss

28%

Jetty

27%

Tomcat

59%

</table>

현재 전세계의 애플리케이션 서버 시장 자체가 오픈소스 SW 형태로 전환되고 있으며 , 상용 SW 벤더로부터의 이탈이 점차 빨라질 것으로 예상하고 있습니다 .


자바 웹 애플리케이션 서버에서 시작한 다양한 컴포넌트들이 다시 순수 기능으로 회귀하고 있는 상태입니다. "Simple is the best"를 알고 있다면 그것을 어떻게 효과적으로 사용하고 상호 운용성을 높일 수 있는지가 현재 IT 시스템을 만드는데 있어 화두입니다.


다음 번 글에서는 요즘 사용되고 있는 아키텍처링 기법 등에 대해 설명하고자 합니다.


긴 글 읽어주셔서 감사합니다.

- 오픈소스컨설팅 최지웅 -



[1] . 사실 이는 ERP 초창기인 1960 년대부터 시스템 분산이 시작되었다 .

[2] 현재 웹로직의 t3 프로토콜은 three-tier server 이름에서 변형되었다 .


ienvyou's profile image

ienvyou

2014-11-15

Read more posts by this author