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)를 고안해냈습니다.
이 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)”을 읽어보길 바랍니다. |
'IT' 카테고리의 다른 글
| WEB Application (0) | 2023.11.05 |
|---|