

Spring이 등장하기 전에는 EJB(Enterprise JavaBeans)를 통해 엔터프라이즈 어플리케이션을 개발하였다. 그러나 EJB 기반 개발에는 여러 가지 한계가 있었다. (2번 내용 참고)
Rod Johnson은 이러한 EJB의 복잡성과 한계에 반발하여, 이를 대체할 수 있는 경량 프레임워크를 제시하였다.
그는 약 30,000라인의 예시 코드를 공개하였고, 이는 Spring Framework의 초기 버전이 되었다.
이 예시 코드에는 현재 Spring의 핵심 개념인 BeanFactory, ApplicationContext, POJO, IoC(제어의 역전), DI(의존성 주입) 등이 포함되었다.
💡 EJB(Enterprise JavaBeans)란?
대규모 엔터프라이즈 애플리케이션 개발을 단순화하기 위해 설계된 서버 측 구성 요소이다.
이는 비즈니스 객체들을 관리하는 컨테이너를 제공하여, 개발자가 객체 생명 주기를 관리할 필요 없이 비즈니스 로직에만 집중할 수 있도록 지원하였다.
1. XML기반의 복잡한 설정
EJB는 XML 기반의 복잡한 설정을 필요로 했고, 단순한 비즈니스 로직 구현에도 이러한 복잡한 설정이 요구되었다. 이는 개발 생산성을 크게 저하시켰고 유지보수 비용이 크게 증가하였다. Spring은 XML 기반 설정을 최소화하고, 자바 기반 설정과 어노테이션 기반 설정을 지원하여 설정을 간소화하였다.
2. 개발 생산성 저하
EJB는 높은 클래스 결합도를 가지며, 객체 간 의존성이 강하게 결합되어 확장성과 유지보수성을 떨어뜨렸다. Spring은 IoC와 DI 개념을 도입하여 객체 간 결합도를 낮추었다.
3. 테스트 제약 및 배포 속도 저하
EJB는 컨테이너 기반으로 동작했기 때문에, 단순한 기능 테스트를 위해서도 전체 애플리케이션 서버를 기동해야 했다.
이로 인해 개발과 테스트 주기가 길어져 개발 속도가 느려졌다.
Spring은 POJO(Plain Old Java Object) 기반 설계를 통하여 서버 기동 없이도 독립적인 단위 테스트가 가능하도록 했고, 이를 통해 빠른 개발과 테스트, 배포가 가능해졌다.
💡 POJO(Plain Old Java Object)란?
특정 프레임워크나 컨테이너에 의존하지 않는 순수한 Java 객체를 의미한다.
프레임워크: 개발을 효율적으로 할 수 있도록 다양한 기능과 구조를 제공하는 개발 환경을 의미한다. 이는 일종의 개발 '뼈대'를 제공하며, 개발자는 프레임워크 안에 코드를 작성하고 규칙을 따라야 한다.
라이브러리 : 자주 사용되는 로직이나 기능을 재사용하기 쉽게 모아둔 코드들의 집합을 의미한다.
라이브러리와 프레임워크의 가장 큰 차이점은 '누가 누구를 컨트롤 하는가' 에 있다.
라이브러리는 '내가 직접 코드를 결정하고 컨트롤하는 것'이고 프레임워크는 '누군가 정해준 규칙을 따라 내 코드가 실행되는 것'이다.
프레임워크의 제어 흐름
프레임워크는 어플리케이션의 제어 흐름을 스스로 관리 하며, 개발자가 작성한 코드를 필요할 때 호출한다. 개발자는 프레임워크의 구조와 규칙을 따라야 한다.
라이브러리의 제어 흐름
라이브러리는 개발자가 제어 흐름을 관리하고 필요한 시점에 라이브러리를 호출하여 사용한다.
프레임워크 예시
Spring Framework는 개발자가 비지니스 로직을 작성하면, 프레임워크가 객체 생성, 의존성 주입, 트랜잭션 처리 등의 제어 흐름을 관리한다.
라이브러리 예시
JQuery는 웹사이트에 동적인 기능을 추가할 수 있는 라이브러리로, 이는 개발자가 필요할 때 호출하는 형태로 사용할 수 있다.
💡 IOC(Inversion of Control)란?
객체의 제어권(생성, 생명주기 관리 등)을 개발자가 직접 관리하는 것이 아니라, 외부 시스템(컨테이너)에게 위임하는 것이다.
이는 주로 프레임워크에서 나타나는 특징이며, Spring Framework도 IOC개념을 기반으로 동작한다.