01. Spring Framework가 탄생 배경 및 문제점
1. EJB(Enterise JavaBeans)
EJB란 예전 Java EE 환경에서 사용된 기술로, 기업 환경의 대규모 애플리케이션을 구축하기 위해 만들어진 자바의 서버측 컴포넌트 모델이다. 즉, EJB는 복잡한 기능은 컨테이너가 맡고, 개발자는 비지니스 로직에 집중할 수 있도록 하는 구조를 뜻한다.
| EJB가 제공한 기능 | 예시 | |
| 트랜잭션 관리 | 여러 DB 작업을 하나로 묶는 기능을 자동으로 처리 | 계좌 이체 시 둘 다 성공해야 함 |
| 분산 객체 기술 | 여러 서버에 흩어진 객체들을 연결 | 분산 시스템에서 다른 서버와 통신 |
| 보안 및 상태 관리 | 사용자 인증이나 세션 관리 | 권한 없는 사용자는 접근 불가 |
2. EJB의 문제점
기존의 EJB는 복잡한 기능을 제공하는 대신 개발자가 종속적으로 복잡한 코드를 작성해야 했다. 하지만 이는 기술이 비지니스 로직을 압도하는 주객전도 현상을 초래하였으며, 이러한 배경에서 탄생한 것이 단순하고 유연한 경량 프레임워크인 Spring Framework이다.
| EJB의 문제점 | |
| 기술 종속성 및 낮은 이식성 | 특정 WAS(WebLogic, WebSphere 등)에 강하게 결합되어, 다른 환경에서 재사용 및 이식 어려움 |
| 객체 지향 설계 원칙 위반 | 컨테이너 주도 개발, 직접 의존 객체 생성 등으로 OOP 설계 원칙 훼손 |
| 복잡한 구조 | 단순한 로직에도 여러 파일(Home, Remote, Bean 클래스 등)을 만들어야 했음 >> EJB의 인터페이스를 상속받거나 구현함으로써, 강한 종속 발생 |
| 무거운 설정 | XML(eXtensible Markup Language) 기반 설정이 많고 복잡하여 실수와 유지보수 비용이 높았음 |
| 느린 배포로 인한 생산성 저하 | 설정 파일이 하나만 변경되어도, 전체 애플리케이션 단위(EAR)를 다시 패키징하여 배포해야 했음 |
| 테스트 어려움 | EJB 컨테이너 환경에서만 실행 가능하여 단위 테스트가 불가능하거나 제한적이었음 |
3. Spring이 제시한 새로운 방향
이러한 Spring Framework는 복잡성을 제거하면서 기능성을 유지하는 균형을 제공한다. 즉, Spring은 단순한 기술 스택이 아니라 실제 문제를 해결하기 위한 도구를 뜻한다.
| Spring 제시한 방향 | |
| POJO 기반 개발 | 특정 프레임워크나 컨테이너에 의존하지 않는 순수한 자바 객체인 POJO를 사용 >> 단위 테스트 가능 |
| IoC (Inversion of Control) |
개발자 대신 컨테이너가 객체의 생성과 의존성 주입을 담당 >> 낮은 결합도 (Loose Coupling) |
| AOP (Aspect-Oriented Programming) |
공통 관심사를 비지니스 로직과 분리 |
| 경량 컨테이너 | 전체 WAS 없이도 실행 가능한 구조 |
02. 프레임워크 vs 라이브러리
| Java 라이브러리 | Spring Framework | |
| 사용 방식 | new 키워드를 통해 객체를 생성하고 메서드를 호출 | 스프링 컨테이너가 객체(Bean) 생성 및 관리 >> 해당 객체가 필요한 곳에 자동 주입 |
| 제어 흐름 주체 | 개발자 >> 제어의 순전 |
프레임워크 >> 제어의 역전 (Inversion of Control, IoC) |
| 비유 예시 | 필요할 때 꺼내 쓰고 다시 넣어두는 연장 | 집의 구조 자체는 고정되어있는 모델 하우스 |
'[Codeit] > Spring 백엔드 10기 위클리페이퍼' 카테고리의 다른 글
| [06] AOP와 MVC (0) | 2026.02.26 |
|---|---|
| [05] 웹 서버와 WAS, 그리고 Bean 등록 (0) | 2026.02.12 |
| [03] HashSet, 그리고 O(n)과 O(logn) (0) | 2026.01.27 |
| [02] SRP와 OCP, 그리고 map과 flatMap (0) | 2026.01.18 |
| [01] Git | merge vs rebase, 그리고 fetch vs full (0) | 2026.01.05 |