[Java의 역사 #2] 웹과 함께 발전한 Java
안녕하세요 (전)프포자 @stunstunstun 입니다. 지난 포스팅에 이어 한국에서 가장 많이 사용하는 프로그래밍 언어라고해도 과언이 아닌 Java의 역사에 대한 이야기를 이어나아갑니다.
웹의 발전과 애플릿의 쇠퇴
애플릿은 자바로 작성한 프로그램을 미리 업로드 하고 브라우저 상에서 애플릿 태그로 불러온다. 애플릿 태그가 실행되면 브라우저에서는 프로그램을 다운로드 한 다음 실행한다. 방식으로 보자면 액티브X, 어도비 플래시 및 AIR, 실버라이트와 크게 다를 것은 없지만, 특징은 운영체제 상에서 직접 실행되는 것이 아니라 자바답게 자바 가상 머신에서 실행된다. 따라서 애플릿을 실행하려면 자바 가상머신을 운영체제에 미리 깔아야 한다.
액티브X보다는 이미지가 좋은 편이지만, 애플릿 역시 시간이 지날수록 만만치 않게 엄청난 보안 구멍이 있었다. 일반적인 액티브X와는 달리 운영체제와 통합된게 아니라 자바 가상머신에서 돌아가므로 조금 나을 수도 있지만, 초기에는 별 제한 없이 로컬 파일을 액세스 할 수 있었으므로 보안이 뚫린 적도 꽤 많았다. 후에 지속적으로 보안 패치를 했지만 취약점 없는 프로그램이란건 사실상 존재하지 않기에 꾸준히 뚫리고, 막는 창과 방패의 전쟁이 지속됐다. 거기다가 자바 가상 머신을 통해서 실행되며 실행 속도가 비교적 느리다.
그 와중에 터진 브라우저에서의 자바 플러그인의 보안 취약성으로 인한 일련의 사고 및 이에 대한 오라클의 뒤늦은 대응은 개발자 뿐 아니라 기업의 IT 인프라의 아키텍쳐를 결정하는 데 영향을 줄 수 있는 경영자를 포함한 일반인들에게 까지 자바에 대한 부정적인 인식을 퍼뜨리는 치명적인 결과를 가져오게 된다.
인터넷의 실행 환경인 웹브라우저가 점점 발전하고 거기다 HTML5, Javascript가 발전하면서 더이상 추가적인 설치가 필요하고 번거로운 애플릿, 플래시같은 웹 플러그인은 그 장점을 점점 잃어갔다.
모질라 재단에서 2015년 10월 파이어폭스에서 NPAPI 플러그인 지원을 중단하겠다는 발표를 했고, 곧 이어 오라클에서는 2016년 1월 Java 9 부터 애플릿을 위한 자바 플러그인 지원을 중단하겠다고 발표했다. 따라서 자바 애플릿은 Java 9 이후 역사속으로 사라질 예정이며, 이후 자바 애플릿이 했던 역할은 유사한 기술인 Java Web Start 가 대신하게 된다.
HTML5에서는 폐지되었으며 대신 embed 태그를 쓴다.
사실 이건 웹 플러그인들의 공통점이다. 널리 쓰이는 플래시랑 AIR, 실버라이트도 보안 문제가 많았다.
Java EE
Java는 이렇게 애플릿이 쇠퇴하였지만 여전히 서버측 애플리케이션을 개발하기 위한 중심적인 역할을 하고 있다. J2EE는 자바를 이용한 서버측 개발을 위한 플랫폼이다. Java EE 플랫폼은 PC에서 동작하는 표준 플랫폼인 Java SE에 부가하여, 웹 애플리케이션 서버에서 동작하는 장애복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다. 이전에는 J2EE라 불리었으나 버전 5.0 이후로 Java EE로 개칭되었다.
이러한 Java EE 스펙에 따라 제품으로 구현한 것을 웹 애플리케이션 서버 또는 WAS라 불린다. 현재는 Java EE의 복잡도로 인해 스프링과 같은 프레임워크를 통해 웹 애플리케이션 서버를 개발하는 추세이다.
스프링 프레임워크
스프링은 로드 존슨(Rod Johnson)이 2002년에 출판한 저서 Expert One-on-One J2EE Design and Development에서 선보인 소스 코드를 시작으로 점점 발전하게 되었다. 2003년 6월에 최초로 아파치 라이선스 2.0으로 공개되었다.
동적 웹을 개발하기 위한 어플리케이션 프레임워크로 JVM 환경에서 작동하며 아파치 라이선스 2.0를 따르고 있다. 전자정부 표준 프레임워크의 기반 기술이며 한국정보화진흥원에서 공공기관의 웹 서비스 제공시 권장하고 있다.
스프링 프레임워크(Spring Framework)의 특징은 아래와 같다
POJO(Plain Old Java Object) 방식 : POJO는 Java EE 등 무거운 프레임워크들을 사용하면서 해당 프레임워크에 종속되어 있는 무거운 객체들을 만드는 것에 반발하며 나타난 용어다. J2EE Framework에 비해 특정 인터페이스를 구현하거나 상속받을 필요가 없어 기존 라이브러리를 지원하기에 용이하고 객체가 가볍다.
관점 지향 프로그래밍(Aspect Oriented Programming, AOP) : 로깅, 트랜잭션, 보안 등 여러 모듈에서 공통적으로 사용하는 기능을 분리하여 관리할 수 있다. AspectJ를 포함하여 사용할 수 있고, 스프링에서 지원하는 실행에 조합하는 방식도 지원한다.
의존성 주입(Dependency Injection, DI) : 프로그래밍에서 구성요소간의 의존 관계가 소스코드 내부가 아닌 외부의 설정파일을 통해 정의되는 방식이다. 코드 재사용을 높여 소스코드를 다양한 곳에 사용할 수 있으며 모듈간의 결합도도 낮출 수 있다. 계층, 서비스 간에 의존성이 존재하는 경우 스프링 프레임워크가 서로 연결시켜준다.
제어 반전(Inversion of Control, IoC) : 전통적인 프로그래밍에서는 개발자가 작성한 프로그램이 외부 라이브러리의 코드를 호출해서 이용했다. 제어 반전은 이와 반대로 외부 라이브러리 코드가 개발자의 코드를 호출하게 된다. 즉, 제어권이 프레임워크에게 있어 필요에 따라 스프링 프레임워크가 사용자의 코드를 호출한다.
MVC 패턴(Model-View-Controller pattern, MVC) : 웹 프로그래밍 개발에서 필수적인 디자인 패턴인 MVC 패턴을 사용한다. DispatcherServlet이 Controller를 담당하며 요청에 따라
@(Annotation)으로 선언되어 있는 각 서비스로 분산시켜준다.트랜잭션 관리 : 추상화된 트랜잭션을 XML 설정파일 등을 이용해 관리할 수 있다.
생명주기 : 스프링 프레임워크는 자바 객체의 생성, 소멸을 직접 관리하며 필요한 객체만 사용할 수 있다.
다양한 서비스 : myBatis와 같은 데이터베이스 처리 라이브러리나 tiles 같은 유용한 인터페이스를 제공한다.
웹 애플리케이션 서버
웹 애플리케이션 서버(Web Application Server, WAS)는 인터넷 상에서 HTTP를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는 미들웨어이다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이 된다. 한국에서는 일반적으로 WAS로 통칭하고 있으며 공공기관에서는 웹 응용 서버로 사용되고, 영어권에서는 Application Server 로 불린다.
다음 포스팅에서는 안드로이드의 출현과 함께 성장하게 된 Java 이야기를 이어나아 갑니다!