3년을 기다렸다

이창신 iasandcb@gmail.com, http://iasandcb.pe.kr 티맥스소프트 JEUS팀, 엔씨소프트 오픈마루 스튜디오를 거쳐 현재 인디 개발자로 활동하고 있다. 2009년 6월 9일

내가 티맥스소프트에서 제우스 6를 자바 EE 5 인증받도록 하는 작업을 했던 것이 2006년이었다. 그해 자바 EE 5가 정식 출시된 이후 자바 EE 6에 대한 청사진이 그려지기 시작했는데, 보통 2년이 걸렸던(J2EE 1.4에서 자바 EE 5는 2년 반이 걸렸다) 버전 업이 결국 3년을 넘기고 말았다.

아직 자바 EE 6가 스펙을 확정짓고 정식 출시되지는 않았지만, 지난 6월 첫째 주에 열린 자바원(JavaOne) 2009 컨퍼런스를 빛내기 위해 자바 EE 6 프리뷰가 나왔다. 이 프리뷰의 구성은 여기에서 자세히 볼 수 있는데, 아직 스펙 제정이 완료된 상태가 아니므로 작은 변화는 일어날 수도 있다. 자바 EE 6 SDK 프리뷰는 여기에서 받을 수 있는데, “더 작게, 더 간단하게, 더 가볍게(smaller, simpler, lighter)”라는 모토답게 풀 프로파일(Full Profile)과 웹 프로파일(Web Profile) 두 가지 선택지를 제공하고 있다.

그건 그렇고, 과연 3년 넘게 기다린 보람이 있을까? 여타 소프트웨어 발전이 빛의 속도로 빠르게 진행되는 가운데, 자바 플랫폼의 최대 격전지인 자바 EE의 차세대 기술은 어째서 더 늦어진 것일까? 이렇게 쏟아지는 질문에 대해 경량 컴포넌트 지향이라는 관점으로 접근해보려 한다.

서블릿 3.0

자바 EE 5는 SOA라는 대유행을 타고 XML 웹 서비스(SOAP/WSDL/UDDI)의 대폭 강화에 힘썼었다. 또한 하이버네이트(Hibernate) 같은 걸출한 ORM의 등장으로 EJB는 JPA에 ORM의 짐을 넘겨주는 대결단을 보여주기도 했다.

그런데, 웹 서비스나 EJB와 달리 웹 티어(web tier) 쪽은 근본적인 변혁, 특히 웹 티어의 가장 밑바탕이라 할 수 있는 서블릿 기술의 변화를 크게 가져오지 못했다. 결과적으로 자바 EE 5는 자바 EE 역사상 가장 덩치 큰 스택으로 자리잡았으며, 이는 저비용의 민첩한 서버 애플리케이션 개발과 점점 멀어지는 효과를 낳았다.

원래 서블릿도 자바 EE 5에서 3.0을 찍으려 했지만, 어찌 보면 그 동기가 강하지 않았는지도 모르겠다. 그 덕분에 자바 EE 6에서는 충분한 기간 동안 현재와 미래를 위해 필요한 기술들을 수용할 수 있지 않았나 싶다.

어노테이션 채용
어노테이션은 이미 자바 EE 5에서 개발 편의성(ease of development)이라는 구호와 함께 EJB와 웹 서비스의 곳곳에 적용되었다. 하지만 유독 서블릿 쪽은 적용되지 않았는데, 이번에 대폭 적용되면서 EJB와 웹 서비스가 배포 디스크립터 XML 파일에서 벗어난 것처럼 web.xml 없이 웹 애플리케이션 개발과 배포가 가능해졌다.

내가 이 신기능을 보고 바로 떠올린 것은 자바 웹 애플리케이션 개발 과정에서 처음으로 배우는 Hello World 예제를 얼마나 간단히 만들 수 있는가이다. 서블릿 2.x에서는 web.xml이 필수였기 때문에, Hello World를 출력하는 서블릿을 작성하는 것과는 별개로 배포 디스크립터를 도입해야 했었다. 따라서 처음 배우는 입장에서는 학습 곡선이 급격히 올라갈 수밖에 없었는데, 이제 그야말로 HelloServlet 서블릿 클래스만 작성하면 된다.

간단히 설명하면, greeting이라는 디렉터리를 만든 후 그 밑으로 WEB-INF 디렉터리를 만들고, 또 그 밑으로 classes 디렉터리를 만든다(유닉스 셸에서는 mkdir -p WEB-INF/classes에 해당한다). 그리고 greeting 디렉터리에 HelloServlet.java 소스 파일을 아래와 같이 작성한다.

package ias; 

import java.io.*; 
import javax.servlet.annotation.*; 
import javax.servlet.http.*; 
import javax.servlet.*; 

@WebServlet("/hello") 
public class HelloServlet extends HttpServlet { 
  public void doGet (HttpServletRequest req, 
                     HttpServletResponse res) 
    throws ServletException, IOException 
  { 
    PrintWriter out = res.getWriter(); 

    out.println("Hello World!"); 
    out.close(); 
  } 
}

greeting 디렉터리에서 아래와 같이 HelloServlet.java를 컴파일한다(이 경우 자바 EE 6 SDK를 ~/Apps/javaee6-preview에 설치한 것이다).

javac -cp ~/Apps/javaee6-preview/glassfish/modules/javax.servlet.jar -d WEB-INF/classes HelloServlet.java 

이렇게 하면 애플리케이션이 완성된다(믿기지 않겠지만 더 이상의 작업은 필요없다).

asadmin start-domain으로 서버를 띄운 다음 asadmin deploy ~/Workspace/greeting으로 디렉터리를 배포하고 http://localhost:8080/greeting/hello를 브라우저로 열어보면 Hello World!가 가볍게 찍힌다.

전에 web.xml로 했던 서블릿 매핑과 URL 지정 등은 @WebServlet 어노테이션 한방으로 깔끔하게 처리됨을 볼 수 있다.

web-fragment.xml 컴포넌트
서블릿을 기반으로 한 웹 애플리케이션 모델에서 MVC 패턴의 완결된 컴포넌트는 기존 애플리케이션에 쉽게 넣어 쓰기가 어려웠다. 가장 근본적인 문제는 역시 web.xml과 관련된 것인데, 컴포넌트가 동작상 자신만의 web.xml을 가진 경우 애플리케이션의 web.xml과 어떤 식으로든 합쳐져야 하는데, 수동으로(즉 개발자의 직접 편집을 통한 병합) 하는 데에도 한계가 있고, 플러그 앤 플레이와 핫 스왓이 보편화된 오늘날의 컴포넌트 모델과도 맞지 않는 것이 사실이다.

서블릿 3.0에서는 이 문제를 web-fragment.xml이라는 새로운 개념의 도입으로 해결한다. 예를 들어 댓글 컴포넌트를 comment.jar로 배포하는 경우 그 파일 안에 META-INF 디렉터리 밑으로 web-fragment.xml을 두어 웹 애플리케이션의 WEB-INF/lib에 넣으면 자동으로 WEB-INF/web.xml과 함께 배포 디스크립터로 작동하는 것이다.

EJB 3.1

앞서 소개했던 자바 EE 6의 프로파일 개념은 원래 무거운 자바 EE 기술 전체를 특정 분야에 맞게 묶어 가볍게 하려는 시도에서 비롯되었다. 그래서 일단 자바 EE 6 기술을 전부 아우르는 풀 프로파일이 있고, 웹 애플리케이션 개발에 집중하는 웹 프로파일을 정했다.

그런데, ORM을 포함한 비즈니스 로직의 컴포넌트화를 맡은 EJB가 웹 프로파일에 들어갈 것인지에 대해 격론이 벌어졌다. JPA만 넣자는 의견도 있었고, 심지어 JPA도 빼서 웹 프로파일을 더 가볍게 하자는 극단적인 이야기도 있었다.

수년에 걸친 논의 끝에 EJB의 경량(Lite) 버전이 웹 프로파일에 들어가는 것으로 결론이 났는데, 앞서 web-fragment.xml과 더불어 EJB 3.1 경량 버전이 웹 프로파일에 들어감으로써 MVC 모델의 컴포넌트가 더욱 현실화되었다.

이상적인 예로 댓글 컴포넌트를 가정해보자. 내가 마이크로블로그 애플리케이션을 만들었는데, 댓글 기능을 추가하고 싶다. 댓글 기능을 넣는다 함은 다음과 같다.

• 화면(View): 블로그 포스트에 댓글이 따라 보인다.
• DB(Model): 댓글이 DB로 관리된다.
• 흐름(Control): 댓글 기능과 관련된 워크플로(workflow)가 조절된다.

이전에는 이런 컴포넌트를 comment.jar라는 EJB 모듈로 만들어도, 다른 웹 애플리케이션과 함께 쓰려면 EAR라는 엔터프라이즈 애플리케이션으로 애플리케이션 단위의 상승을 피할 수 없었다. 하지만 EJB 3.1 라이트에서는 웹 애플리케이션 안에 EJB 모듈 jar 파일을 둘 수 있게 했다(그냥 WEB-INF/classes 밑에 있어도 된다). 더불어 기존 EJB 모듈은 화면과 관련된 영역을 다룰 수 없었는데, 이렇게 웹 애플리케이션 안에 들어올 수 있게 됨에 따라 JSF 등을 이용하여 화면까지 처리할 수 있게 된 셈이다.

JAX-RS

서블릿 3.0과 EJB 3.1을 통해 자바 웹 애플리케이션은 컴포넌트화에 큰 진보를 이루었다. 한편, 인터페이스라는 측면에서 자바 EE 5에서 주력으로 밀었던 JAX-WS는 REST의 득세와 함께 JAX-RS에 자리를 내주는 형국이다.

두 기술은 비슷한 이름만큼이나 웹 인터페이스(또는 웹 API, 국내에서는 오픈 API로 더 잘 알려진 개념)라는 목표를 갖고 태어났지만, SOAP/WSDL/UDDI라는 무거운 XML 기반 대신 REST 철학의 JSON 기반에 대한 호응이 높아짐에 따라 희비가 엇갈리고 있다.

위의 그림은 자바 EE 6이후의 자바 웹 애플리케이션에서 활약할 독립 컴포넌트의 구도를 보여준다. 기존 컴포넌트가 각자의 영역(비즈니스 로직, GUI, API)만을 담당했다면, 이제 비즈니스 로직의 웹을 향한 노출(exposure)을 인간이 시각적(visual)으로 접근할 수 있는 GUI와 인간과 기계 모두 데이터(data)적으로 접근할 수 있는 API 방식으로 모두 제공한다. 아직 이런 컴포넌트에 대한 정식 명칭은 없지만, 쉽게 자바 웹 컴포넌트라고 부를 만하다.

클라우드 컴퓨팅과의 상생

자바 웹 컴포넌트는 웹 애플리케이션 개발에 있어 코드 재사용성의 수준을 높혀 줄 것이다. 그렇다면 이런 웹 컴포넌트로 구성된 웹 애플리케이션의 실행 가능성은 역으로 부속 컴포넌트에 의존하게 된다.

애플리케이션 운영 환경으로서의 클라우드 컴퓨팅은 이런 관점에서 매우 의미있다. 아마존 웹 서비스의 EC2나 구글 앱 엔진은 컴퓨팅 자원을 마치 전기 쓰듯이 편하게 끌어다 쓰게 해줌으로써 클라우드 컴퓨팅의 현실적인 장을 열었다. EC2의 경우 자원 관리를 마음껏 할 수 있으므로, 자바 EE 6 관련 이미지가 잘 제공된다면 웹 컴포넌트의 사용 환경으로 아주 좋을 것이다. 반면, 구글 앱 엔진은 자바 환경을 제공한 지 얼마 되지 않았고 제약이 아직 많은 편이어서(서버 환경도 서블릿 2.4 수준이다) 앞으로 많은 향상을 필요로 한다.

3년을 기다려 나온 자바 EE 6, 그리고 그 기술을 쉽고 가볍게 쓰기 위한 환경이 마련될 앞으로 3년이 무척이나 기대된다.

mar.gar.in

naver

eolin

del.icio.us

위로

[지난 developerWorks Column 보기]