#0 스프링, 자바의 봄이 오기까지

해당 글은 김영한님의 인프런 강의를 공부하고 정리한 내용입니다.

# EJB 지옥

자바가 나온 2000년대, 그 당시 자바 진형에서는 EJB (Enterprise Java Beans) 프레임워크를 비즈니스 기술 스펙으로 제공하였습니다. EJB는 "대규모이고 구조가 복잡한 분산 객체 환경"을 쉽게 구현하기 위해서 등장했었고, 그 당시 EJB 안에 녹아든 객체지향을 설계하기 위한 이론들은 좋았습니다.

 

[ WebServer - EJB - DB ]의 3계층으로 나눠 비즈니스 로직과 UI를 나눌 수 있었습니다. 또한 비즈니스 객체를 관리하는 컨테이너를 만들어 필요할 때 마다 컨테이너로부터 객체를 받는 개념, 재사용성있는 컴포넌트 개발, 다른 곳에 떨어진 EJB 서버의 메모리에 있는 클래스를 참조할 수 있는등 대규모 분산 환경에서 객체지향 프로그래밍을 한다면 EJB가 정말 '매력적으로' 보였습니다. 

 

취지는 좋았으나, 서비스가 구현해야하는 비즈니스 로직보다 EJB 컨테이너를 사용하기위한 기본 코드들이 너무 많다는 큰 단점과 함께 아래와 같은 문제들도 있었습니다. 이는 개발자들을 정말 머리아프게 만들었죠.

• EJB로 만든 컴포넌트는 무겁습니다. 가벼운 객체로도 가능한 일을 굳이 EJB로 처리해야 합니다.
• 복잡한 컨테이너를 구현한 고가의 자바 WAS 서버가 필요했습니다. 패키징과 배포가 어려운건 덤.
• 벤더 사마다 EJB 컨테이너를 구현한 내용이 달랐습니다. 컨테이너의 설정과 변경이 상당히 어려웠습니다.
• 위의 3가지 문제때문에 프로젝트 자체가 특정 기술, 컨테이너에 종속적으로 만들어집니다. 재사용이 안됩니다.
• EJB 코드의 생산성, 유지보수는 최악이었고 EJB가 가진 개념은 순수한 자바코드로 충분히 대체 가능했습니다.

 

특히 DB 처리와 관련해서는, 이게 정말 기업에서 만든 기술이 맞나 싶을정도로 느리고 안되는 것이 많았다고 합니다. 그러니 실무 개발자들이 EJB 지옥에서 코딩할바에 내가 직접 순수한 자바코드로 새로 만들겠다. 라고 말하며 순수 자바를 이용한 개발용 방법론과 오픈소스가 나오기 시작합니다.

• 

---

# Java의 대처, EJB의 몰락

EJB는 너무나 구렸기에 버려지는건 당연한 수순이었다. 그래서 Java 진형에서 이대로가다간 Java가 망할 수도 있다는 생각에 EJB가 구린 것을 인정하고, Hibernate의 개발자를 데려와 해당 기술을 자바의 표준으로 만들기 시작하였다. 그리고 똑같은 내용을 이름을 바꿔 2006년에 정식출시한것이 Java Persistence API, 바로 JPA 이다.

2021.06.13 - [Backend/JDBC & JPA] - #1 JPA 개요

 

다른 한편으로는 2003년에 당시 엄청 유명했던 자바 엔터프라이즈 개발자들(유겐 휠로, 얀 카로프)이 롭 존슨을 영입하여 책의 주요 개념을 그대로 적용한 자바 오픈소스 프레임워크를 만들자고 제안하였는데, 이것이 바로 Spring Framework 의 시초였다. 그 당시 오픈소스 프레임워크는 상당히 혁신적였는데, 순수한 오픈 소스로 운영하다보니 관리가 어려웠고 아쉬운점이 많았기에 2009년에 VMware 회사가 스프링 프레임워크를 인수하여 관리하고 있다. (라이선스는 그대로 Apache License 2.0 오픈소스를 유지하였다.)

 

참고로 Spring이라는 이름은 얀 카로프가 EJB를 사용하던 자바 개발자들의 지옥같은 겨울을 끝낼, 새로운 봄(Spring)이라는 의미로 지었다고 한다. 현재(2021)에도 스프링의 핵심 코드를 유겐 휠러, 롭 존슨, 얀 카로프가 개발하고 있다.

2010년 이후 스프링이 어떻게 변화, 발전했는가는 나중에 다룰 예정이다.

 

참고로 스프링이 현업에 사용되기 시작한 때는 2006년인데, 그때 당시 자바 개발자들은 SSH라고 부르는 구성으로 웹 서버를 구성하였다. SSH란 스프링 코어(Spring) + 스트럿츠(Strutcs) + 하이버네이트 (Hibernate) 로 구성하였고 스프링이 제공하는 DI와 AOP 기능을 중심으로 다양한 라이브러리들을 조합하여 사용하였다.

 

그리고 새로운 프레임워크들이 나오며 스트럿츠의 사용률이 줄다가, 2013년에 공식 지원이 종료되었고 자연스럽게 스트럿츠 -> 스프링 MVC or 다른 프레임웤으로 넘어오게 된다. 참고로 전세계적으로 자바 개발에 스프링, JPA의 사용률은 높았지만 한국과 중국의 경우 거의 사용하지 않다싶이 했다고 한다. 신기술에 보수적인 입장도 있겠지만, 참고할 공식문서가 전부 영문이라 어려움도 많았다고한다. 한국에서 본격적으로 커뮤니티가 형성되고 기술을 받아들이기 시작한게 2015년 무렵이다. 

 

---

# Spring Framework 가 제공하는 핵심 기능

스프링이 가진 핵심 기능은, 웹 어플리케이션을 만들거나 DB를 편하게 접근해주기 위한 도구가 아니다. 이는 객체지향적으로 설계해서 얻는 이점일 뿐이고 스프링의 본질은 '순수한 Java로 좋은 객체지향을 설계하도록 도와주는 프레임워크' 이다. 스프링 프레임워크는 롭 존슨의 책에 있는 다음과 같은 개념들을 도입하여 객체지향적인 코드를 만들 수 있도록 도와주고있다. 

• 경량 컨테이너로서 자바 객체를 직접 관리
  - 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
  
  
• POJO(Plain Old Java Object) 방식의 프레임워크
  - 일반적인 J2EE 프레임워크 (EJB)에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없다. 즉 기존에 존재하는 라이브러리 등을 그대로 지원하기에 용이하고 객체가 가볍다.
  
  
• 제어 반전(또는 제어의 역전)(IoC: Inversion of Control)을 지원
  - 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.
  
  
• 의존성 주입(DI: Dependency Injection)을 지원
  - 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.
  
  
• 관점 지향 프로그래밍(AOP: Aspect-Oriented Programming)을 지원
  - 트랙잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적 기능의 경우 분리하여 관리할 수 있다.
  
  
• 확장성이 높음
  - 스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸 스프링에서 사용이 가능하다.
  - 수많은 라이브러리가 이미 스프링에서 지원되고 있고 라이브러리를 별도로 분리하기도 용이하다.
  
  
• 스프링의 기술들은 20여개의 모듈로 세분화 되어있고 다른 프레임워크들의 통합이 용이하게 만들어졌다.