fender
9k
2017-09-14 06:51:29.0 작성 2017-09-14 09:13:54.0 수정됨
17
7255

자바EE의 역사 및 스프링과의 관계


다른 글타래에서 어느 분이 스프링(Spring Framework)과 자바EE(Java Enterprise Edition)의 관계에 대해 질문을 주셔서 답글을 쓰다가, 어쩌면 경력이 길지 않은 다른 개발자 분들도 잘 모르실 수 있는 내용인 것 같아서 따로 글을 올리게 되었습니다.

이상하게 우리나라에선 풀스택 자바EE 서버를 구매하면서도 언젠가부터 자바EE는 철저하게 외면하고 스프링으로만 개발하는 관행이 자리 잡아서 자바EE에 대해 잘 모르는 분들이 있을 것 같다는 생각이 듭니다.

스프링과 자바EE의 관계를 이해하기 위해서는 기업형 소프트웨어 시장에서 자바의 역사를 간략하게 이야기할 필요가 있을 것 같습니다.

지금은 잘 상상이 안가지만 원래 자바의 초점은 애플릿 같은 클라이언트 GUI를 만드는데 맞춰져 있었습니다. 그러다가 곧 서버 시장에서의 가능성에도 주목하게 되는데, 이유는 당시엔 기업용 서버 소프트웨어 개발이라는 것이 CC++을 사용해서 다양한 회사의 미들웨어(middleware) 제품들을 사용해서 개발하는 방식이었기 때문입니다.

이 경우 개발자들은 운영체제와 사용하는 미들웨어 제품에 종속될 수 밖에 없는데, 자바의 플랫폼 독립적 특성을 활용해서 미들웨어에 필요한 공통 API를 제공하면 그런 문제를 해결할 수 있다는 생각이었습니다.

그래서 서버 개발에 필요한 기능을 모아서 J2EE(당시엔 자바EE를 그렇게 불렀습니다)라는 표준을 만들고, 각 기업들을 해당 표준을 준수하는 미들웨어 제품을 판매하면 개발자들은 어느 제품을 사용하더라도 API를 새로 공부하거나 제품이나 운영체제에 따라 포팅을 하지 않아도 되도록 했습니다. 그 것이 흔히 'WAS'로 부르는 자바EE 어플리케이션 서버의 시작이었습니다.

그렇게 시작된 자바EE는 출발부터 많은 관심을 받았고, 기업들은 웹로직(WebLogic)이나 웹스피어(WebSphere) 등 자바EE와 호환되는 어플리케이션 서버 제품을 앞다투어 출시하게 되었습니다. 특히 웹 개발을 위해 자바EE 표준에 포함된 서블릿(Servlet)과 JSP는 당시 막 유행하던 PHPASP와 함께 CGI를 몰아내며 자바 언어가 인기를 얻는데 한 몫을 담당했습니다.

하지만 자바EE의 핵심은 EJB(Enterprise Java Beans)라는 기술이었는데, 서블릿이나 JSP가 웹 GUI를 만들기 위해 필요한 기술인 반면, EJB는 자바EE가 대체하는 미들웨어에서 구동되던 기업의 핵심 서비스를 만들기 위한 분산처리 및 트랜잭션, 보안 등을 지원하는 컴포넌트 모델을 제공하는 기술이기 때문입니다.

이러한 EJB는 개발자들의 주목을 받으며 널리 쓰이게 되었지만 시간이 지남에 따라 몇 가지 심각한 문제들로 인해 비판 받게 되었습니다. 당시 자바 표준에서 흔히 보던 문제이지만, 실무와 거리가 있는 아키텍트 들이 실용성보다는 API의 모양새나 플랫폼 독립성이라는 자바의 특성만을 강조한 설계를 하다보니 정작 실제 사용할 때 불편한 점이 너무 많았던 것입니다.

예를들어, EJBORM 기능을 제공하기도 했는데 2.x 버전이 나올 때까지 심지어 결과값을 정렬할 수 있는('order by') 표준적인 방법 조차 제공하지 않았습니다. 표준에서 정의하지 않은 이런 기능들은 모두 자바EE 서버를 판매하던 회사들이 각자 다른 방식으로 구현해서 제공할 수 밖에 없었고, 미들웨어 제품에 종속적인 기존 환경을 극복하기 위해 만든 자바EE를 사용하면 이제는 특정 자바EE 서버 제품에 종속되어 버리는 아이러니한 상황이 되어 버렸습니다.

또한 당시까지는 '의미있는 기본값(sensible defaults)'이나 '설정보다 관행(convention over configuration)' 같은 사상이 널리 쓰이기 이전이었기 때문에, 자바EE 서버에 산출물을 배포하기 위해선 상당한 분량의 XML 설정을 작성해야 했습니다. 아직까지도 외국에서 자바에 대해 흔히 'XML 지옥'이라고 비판하는 이유는 이 시절의 기억이 남아있기 때문입니다. 당시에는, 제 기억에 EJB 하나를 배포하려면 이런 저런 XML을 서너 개 쯤 작성해야 했던 것 같습니다.

스프링 프레임워크는 이러한 문제점을 개선하기 위해 처음 개발되었고, 특히 고가의 풀스택(full stack) 자바EE 서버가 아닌 탐캣(Tomcat)과 같은 일반 서블릿 컨테이너에서도 구동 된다는 것이 큰 강점으로 작용했습니다.

원래 탐캣은 자바EE 표준의 일부인 서블릿 기술의 참조 구현(reference implementation)으로 출발했습니다. 즉, 원래의 용도는 실제 서비스에 사용하기 보다는 서블릿이나 JSP라는 기술이 이런 것이라는 것을 보여 주기 위한 용도로 쓰였는데, 점차 성능이나 안정성이 개선되면서 이 시점에는 이미 실무에서 사용해도 문제없는 수준으로 발전하게 된 것입니다.

다시 말하면, 이는 스프링을 통해 비싼 자바EE 서버를 구매하지 않아도 EJB보다 훨씬 간편한 방식으로 EJB가 제공하던 선언적 트랜잭션 및 보안 처리, 분산 환경 지원 등 주요 기능을 모두 사용할 수 있게 되었음을 뜻하며, 무엇보다 이제는 더 이상 각 자바EE 서버 제품에 특화된 설정을 따로 공부하거나 서버 제품을 바꿀 때마다 포팅 작업이 필요없이 스프링만 이용하면 탐캣이든 레진(Resin)이든 기존의 풀스택 자바EE 서버이든 관계없이 간단하게 배포가 가능하다는 뜻이었습니다.

이러한 이유로 스프링은 곧바로 개발자들 사이에 빠르게 확산되게 되었고, 특히 국내에선 EJB의 부족한 기능과 개념에 대한 오해 등이 맞물려서 심각한 실패를 경험하는 경우가 잦았는데, 이 때의 트라우마로 인해 스프링이 인기를 얻자 EJB는 완전히 사장되어 버리고 스프링 일색의 개발 관행이 자리잡게 됩니다.

하지만 해외에선 여전히 자바EE 역시 명맥을 유지할 수 있었는데, 이는 데이터베이스 중심적인 개발 관행이 강하고 자바로는 주로 웹 UI를 만드는데 주력했던 국내와는 달리, 해외에선 본래의 목적대로 자바EE 기반으로 기업의 핵심 인프라를 구축한 사례도 많았기 때문에 그런 크고 복잡한 시스템을 쉽게 스프링으로 이행할 수 없었던 이유도 있습니다.

그렇지만 무엇보다 스프링이 인기를 얻은 이후 자바EE 역시 스프링 같은 오픈소스 성공 사례를 적극적으로 받아들여 대폭적인 개선을 했던 점도 크게 영향을 주었습니다. 예를들어 EJB는 3.0 버전 이후에선 기존에 비판 받던 부분을 대거 개선하고 완전히 다른 모습으로 등장했는데, 특히 가장 큰 비판을 받던 ORM 관련 기능에서는, 당시 유행하던 오픈소스 프로젝트인 하이버네이트(Hibernate)의 개념을 대폭 받아들여 JPA(Java Persistence API)라는 개별적 표준 기술로 재탄생하게 되었습니다.

사실 JPA는 단순하게 하이버네이트의 개념만 차용한 것이 아니라 아예 하이버네이트 개발을 주도했던 개발자가 직접 스펙 개발에 참여하면서 결과적으로 JPA라는 공통 표준을 따르는 다양한 제공자(provider)가 존재할 수 있고, 하이버네이트는 그 중 대표적인 구현체로서 관계가 정립되게 된 것입니다.

이러한 오픈소스와의 협력을 통해 자바EE를 개선하려는 노력은 다른 분야에서도 이어졌는데, 대표적으로 국내에선 자바EE의 인기가 떨어지면서 함께 외면 받았지만 해외에선 자바 웹 개발의 표준 기술로 쓰이던 JSF(Java Server Faces)의 사례를 들 수 있습니다.

이러한 추세는 스프링의 경우도 예외가 아니어서, 자바EE와 스프링의 간극을 좁히기 위한 노력은 꾸준히 이어져 왔습니다. 자바EE 진영은 EJB를 개선하면서 POJO 중심의 설계나 설정보다 관행을 중시하는 접근 방법을 적극 도입했고, 의존성 주입과 같은 스프링의 핵심 기능들을 표준 스펙으로 제공하게 되었습니다.

스프링과 관련해서 종종 @Autowired@Inject의 차이점을 궁금해하시는 분들이 있는데, 이는 바로 이러한 자바EE와 스프링의 특수한 관계가 반영된 사례입니다. 즉, 스프링이 자바EE를 개선하기 위해 어노테이션을 통한 의존성 주입이라는 개념을 고안하면서 @Autowired라는 기능을 추가했는데, 이후 자바EE가 이를 받아들여 표준으로 @Inject라는 개념을 만들고, 다시 스프링이 자바EE 표준을 지원하는 과정에서 양쪽을 다 사용할 수 있게 된 결과입니다.

국내에선 스프링이 대세가 되는 바람에 자바EE 기반 프로젝트가 거의 자취를 감추다 시피 했지만, 이와 같이 자바EE는 기업형 시스템 구축을 위한 자바의 기술 표준으로 꾸준히 발전하고 있습니다. 사실 기능적으로 보면 지금은 스프링을 사용하지 않아도 자바EE 서버에서 개발한다면 의존성 주입이나 스케줄러, 배치 작업, 트랜잭션 자동화, ORM 등 서버 개발에 필요한 거의 모든 기술을 편리하게 사용할 수 있습니다.

하지만 탐캣 같은 서블릿 컨테이너 기반 개발이 인기를 얻는 통에 풀스택 상용 자바EE 서버 시장의 수요가 줄어들었고, 무엇보다 기술 환경의 변화로 인해 더 이상 자바EE와 같은 거대한 공통 플랫폼 위에 모든 것을 쌓아 올리기 보단 도커(Docker)나 마이크로 서비스 아키텍쳐를 통해 작은 단위 시스템을 느슨하게 연결하는 방식의 개발이 점차 대세가 됨에 따라 자바EE의 미래가 밝지만은 않아 보입니다.

특히 스프링 부트(Spring Boot)의 출현으로 이제는 서블릿 컨테이너 조차 서비스에 내장한 형태의 배포 방식이 주목을 받는 것을 보면, 풀스택 자바EE 서버에 대한 수요는 더욱 축소될 것으로 예상됩니다.

그렇게 본다면 자바EE를 이클립스 재단(Eclipse Foundation)에 이관한다는 이 번 오라클(Oracle)의 결정은 자바EE가 다시 부흥하는 계기라기 보다는 오픈오피스(OpenOffice)나 허드슨(Hudson) 등의 사례처럼 유행하는 기술을 집어 삼키고 더 이상 돈이 되지 않는다고 판단하면 선심쓰듯 뱉어내는 또 다른 사례라고 보는 것이 더 적합하지 않나 싶은 생각이 듭니다.

아마도 자바EE는 이전 처럼 포함하는 모든 스펙을 제공하는 풀스택 컨테이너로서가 아닌, JSF 등 리거시화된 일부 스펙을 제외하고 REST 서비스 개발에 필요한 서블릿이나 JSON 관련 일부 표준 등 여전히 널리 쓰이는 기술을 느슨하게 포함하는 개념으로만 존속하게 될 가능성이 높아 보입니다.

이 경우 풀스택 자바EE 컨테이너 시장은 축소 되더라도 최소한 표준 자체는 여전히 자바에서 널리 쓰이는 기술들을 포함하고 있기 때문에, 자바EE가 오라클의 손을 떠나 오픈소스로 개발될 경우 전보다 좀 더 빠른 발전을 할 수 있는 계기가 되었으면 하는 바램입니다.

33
23
  • 댓글 17

  • 구구구구우
    1k
    2017-09-14 08:51:37.0

    예전에 책에서 읽었던 내용보다 더 자세하네요. 좋은 글 감사합니다. 궁금했던게 많이 해결되었습니다. 

    0
  • 말년개발
    1k
    2017-09-14 09:31:12.0

    읽다보니 Spring 처음 쓰던 그시절이 생각나네요 .

    감사합니다.

    고생하셨네요.

    0
  • byunji
    383
    2017-09-14 09:32:34.0
    감사합니다. 좋은 글 잘봤네요..ㅎㅎ
    0
  • 하비
    244
    2017-09-14 10:07:53.0

    평소에 궁금했었던 내용인데 이렇게 자세하게 나온 내용은 처음 보네요.

    좋은 글 감사합니다.

    0
  • timeflies
    14
    2017-09-14 10:23:37.0

    좋은 글 감사합니다.

    0
  • imkh
    1k
    2017-09-14 10:32:20.0

    좋은 내용 감사드립니다. ㅋㅋ

    잘봤습니다.

    0
  • 창천향로
    2k
    2017-09-14 11:23:08.0

    너무나 좋은글 감사합니다!

    잘봤습니다!

    0
  • theway99
    4
    2017-09-14 12:06:15.0

    정말 궁금했던 내용이었는데 잘 봤습니다.

    감사합니다.

    0
  • 쥐랲비
    13
    2017-09-14 17:24:45.0

    이런 스토리라인은 기술을 학습하는데 흥미와 이해도를 높여주는 것 같아요.

    좋은 글 감사합니다.

    0
  • 왜구랭
    79
    2017-09-14 17:47:26.0

    좋은 글 써주셔서 항상 감사합니다. 역시 믿고 보는 글이네요. 아직 잘 이해가 안 가는 부분이 많지만 두고두고 보겠습니다!

    0
  • coding8282
    947
    2017-09-15 00:25:19.0

    이런 지식은 어떤 쪽을 겅부해야 배울 수 있나요? 문법책에는 간략하게 자바의 역사 정도만 나오고 그렇다고 공식 홈에 가서 딱딱한 글 읽기는 힘들고, 보통 어떻게 학습해야 할까요? 면접에서 이런 배경 지식을 보여주면 좋은 점수를 받을 수 있을 것 같네요 ㅎ

    0
  • fender
    9k
    2017-09-15 00:35:53.0

    coding8282 // 딱히 공부를 해서 배운다기 보다는 그냥 제가 신입 시절 쯤의 이야기라 그냥 기억이 나서 적은 내용입니다 ㅎㅎ;;

    다른 분들도 저보다 경력이 적더라도 지금 현재 시점의 기술 동향에 관심을 갖는다면 아마 시간이 지나서 후배 개발자들에게 옛날 기억을 되살려서, 그 때는 스프링부트가 어땠다거나 리액트가 어땠다는 식의 이야기를 해주실 수 있을 것 같습니다.

    1
  • 더미
    6k
    2017-09-15 09:53:43.0

    딱딱한 글을 읽어야 이런 지식이 쌓아지죠..

    0
  • unigoon3
    251
    2017-09-15 15:46:30.0 작성 2017-09-15 15:46:52.0 수정됨
    EJB 최신기술이라고 올인성으로 연구시키던 그 시절 그 교수 지금은 무얼 하실까
    0
  • jayes
    41
    2017-09-17 14:12:55.0

    감사합니다. 잘읽었습니다ㅎㅎ

    0
  • 코드17
    38
    2017-09-18 09:25:45.0

    좋은글 정말 감사합니다! :)

    0
  • 요런
    24
    2017-10-20 11:12:11.0

    좋은글 감사합니다

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.