스프링(Spring Framework)과 자바EE(Java Enterprise Edition)의 관계 및 역사

최근 스프링(Spring Framework)과 자바EE(Java Enterprise Edition)의 관계에 대한 질문을 받았는데, 많은 개발자들이 이에 대해 잘 모르실 수 있을 것 같아 글로 정리합니다. 특히 한국에서는 자바EE가 철저히 외면당하고 스프링만 사용하는 관행이 자리잡고 있어, 자바EE에 대해 잘 모르는 분들이 많을 수 있습니다.

스프링과 자바EE의 관계를 이해하기 위해, 기업형 소프트웨어 시장에서 자바의 역사를 간략하게 살펴보겠습니다.

자바의 시작과 자바EE의 등장
자바는 원래 애플릿 같은 클라이언트 GUI를 만들기 위해 시작되었습니다. 그러나 곧 서버 시장에서 가능성을 인식하게 되었습니다. 당시 기업용 서버 소프트웨어 개발은 C나 C++을 사용해 다양한 회사의 미들웨어 제품을 활용하여 개발했는데, 이는 운영체제와 미들웨어 제품에 종속될 수밖에 없는 구조였습니다. 자바의 플랫폼 독립적 특성을 활용해 미들웨어에 필요한 공통 API를 제공하면 이러한 문제를 해결할 수 있다는 생각에서 자바EE(Java Enterprise Edition)가 탄생하게 되었습니다.

자바EE는 서버 개발에 필요한 기능들을 모아 표준화하였고, 각 기업들이 이 표준을 준수하는 미들웨어 제품을 판매하면 개발자들은 어느 제품을 사용하더라도 같은 API를 사용하여 개발할 수 있게 되었습니다. 이것이 흔히 'WAS(Web Application Server)'로 부르는 자바EE 애플리케이션 서버의 시작이었습니다.

자바EE의 성장과 한계
자바EE는 초기부터 많은 관심을 받았고, 기업들은 웹로직(WebLogic)이나 웹스피어(WebSphere) 같은 자바EE와 호환되는 애플리케이션 서버 제품을 출시했습니다. 특히 웹 개발을 위한 서블릿(Servlet)과 JSP(JavaServer Pages)는 PHP나 ASP와 함께 CGI를 몰아내며 자바의 인기를 높였습니다.

그러나 자바EE의 핵심 기술인 EJB(Enterprise Java Beans)는 여러 문제점으로 인해 비판을 받게 되었습니다. 실무와 거리가 있는 아키텍트들이 설계한 EJB는 실제 사용하기에는 불편한 점이 많았습니다. 예를 들어, EJB는 ORM(Object-Relational Mapping) 기능을 제공했지만, 2.x 버전까지는 'order by'와 같은 기본적인 기능조차 제공하지 않았습니다. 이런 기능들은 자바EE 서버를 판매하던 회사들이 각자 다른 방식으로 구현하여 제공할 수밖에 없었고, 이는 자바EE의 취지와는 다르게 특정 자바EE 서버 제품에 종속되는 문제를 발생시켰습니다.

또한, 자바EE 서버에 산출물을 배포하기 위해서는 많은 양의 XML 설정을 작성해야 했습니다. 이로 인해 자바는 'XML 지옥'이라는 비판을 받기도 했습니다. 이러한 문제점들을 개선하기 위해 스프링 프레임워크가 등장하게 되었습니다.

스프링 프레임워크의 등장
스프링 프레임워크는 자바EE의 문제점을 개선하고자 개발되었습니다. 특히, 고가의 풀스택 자바EE 서버가 아닌 탐캣(Tomcat)과 같은 일반 서블릿 컨테이너에서도 구동될 수 있다는 점이 큰 강점이었습니다. 탐캣은 원래 서블릿 기술의 참조 구현으로 시작되었으나, 점차 성능과 안정성이 개선되어 실무에서도 사용 가능한 수준으로 발전했습니다.

스프링을 통해 비싼 자바EE 서버 없이도 EJB보다 간편하게 선언적 트랜잭션, 보안 처리, 분산 환경 지원 등 주요 기능을 사용할 수 있게 되었습니다. 이는 개발자들 사이에서 빠르게 확산되었고, 국내에서는 특히 EJB의 부족한 기능과 개념에 대한 오해 등이 맞물려 스프링이 대세가 되었습니다.

자바EE의 변화와 현재
해외에서는 여전히 자바EE가 명맥을 유지했습니다. 이는 자바EE 기반으로 기업의 핵심 인프라를 구축한 사례가 많아 쉽게 스프링으로 이행할 수 없었기 때문입니다. 자바EE는 스프링 같은 오픈소스 성공 사례를 받아들여 대폭적인 개선을 하였습니다. 예를 들어, EJB 3.0에서는 하이버네이트(Hibernate)의 개념을 받아들여 JPA(Java Persistence API)라는 표준 기술로 재탄생했습니다.

JSF(JavaServer Faces)와 같은 자바EE의 다른 기술들도 개선되었습니다. 자바EE와 스프링의 간극을 좁히기 위한 노력은 계속되었습니다. 자바EE는 POJO 중심의 설계, 설정보다 관행을 중시하는 접근 방법, 의존성 주입 등을 도입했습니다. 이로 인해 자바EE와 스프링은 서로 상호 보완적으로 발전했습니다.

자바EE와 스프링의 상호 관계
스프링과 자바EE는 상호 보완적인 관계를 유지해왔습니다. 예를 들어, 스프링이 도입한 의존성 주입 개념은 자바EE에 반영되어 @Inject 어노테이션이 등장하게 되었습니다. 스프링은 자바EE 표준을 지원하기 위해 @Autowired와 @Inject를 모두 사용할 수 있게 되었습니다.

국내에서는 스프링이 대세가 되어 자바EE 기반 프로젝트가 거의 사라졌지만, 자바EE는 여전히 기업형 시스템 구축을 위한 기술 표준으로 발전하고 있습니다. 현재는 스프링을 사용하지 않아도 자바EE 서버에서 의존성 주입, 스케줄러, 배치 작업, 트랜잭션 자동화, ORM 등 다양한 기능을 사용할 수 있습니다.

자바EE의 미래
기술 환경의 변화로 인해 자바EE의 미래는 밝지 않습니다. 마이크로 서비스 아키텍처와 도커(Docker) 같은 기술이 대세가 되면서, 자바EE와 같은 거대한 공통 플랫폼 대신 작은 단위 시스템을 느슨하게 연결하는 방식이 인기를 얻고 있습니다. 스프링 부트(Spring Boot)는 이러한 변화에 맞춰 서블릿 컨테이너를 내장한 형태로 배포할 수 있게 하여, 풀스택 자바EE 서버의 수요를 더욱 줄였습니다.

오라클(Oracle)이 자바EE를 이클립스 재단(Eclipse Foundation)에 이관한 결정은, 자바EE가 더 이상 오라클에게는 수익성이 없다는 판단에서 비롯된 것입니다. 자바EE는 앞으로도 계속 발전하겠지만, 이전처럼 모든 스펙을 포함하는 풀스택 컨테이너가 아닌, REST 서비스 개발에 필요한 서블릿이나 JSON 관련 표준 등 널리 쓰이는 기술을 느슨하게 포함하는 개념으로 존속할 가능성이 큽니다.

자바EE가 오픈소스로 개발되면서 좀 더 빠르게 발전할 수 있는 계기가 되길 바랍니다.

스프링과 자바EE는 역사적으로 많은 변화를 겪어왔고, 현재도 상호 보완적인 관계를 유지하고 있습니다. 자바EE는 오라클의 손을 떠나 오픈소스로 개발되며 새로운 변화를 맞이하고 있습니다. 기술 환경의 변화와 함께 자바EE와 스프링의 역할도 변화하고 있지만, 두 기술은 여전히 기업형 소프트웨어 개발에 중요한 위치를 차지하고 있습니다.