Spring Framework의 배경과 프레임워크와 라이브러리의 차이점

1. Spring Framework의 탄생 배경과 해결하고자 했던 문제점

배경

1990년대 ~ 2000년대 초반 자바 표준 모델로서 EJB(Enterprise Java Bean) 기술이 서버 개발의 표준이었다.

J2EE는 기업용 서비스 개발에 필요한 다양한 표준 기술 (EJB, JSP, Servlet, JDBC 등)을 제공했다.

하지만 EJB는 단순한 비즈니스 로직 하나를 작성하려고 해도 EJB 컴포넌트를 등록, 복잡한 인터페이스와 XML 설정을 해야하기 때문에 단순한 로직이어도 많은 코드 및 설정 부담을 안고 개발해야 했다.

따라서 개발 생산성과 개발자 경험이 크게 떨어졌고 EJB 컴포넌트는 항상 J2EE서버 위에서만 실행할 수 있었기 때문에 테스트가 어렵고, 개발 속도도 매우 느렸다.

이때 마틴 파울러는 그의 동료들과 컨퍼런스 준비하다 탄생한 POJO(Plain Old Java Object)라는 용어는 순수하고 오래된 자바 오브젝트를 지향한다는 의미로 이는 그때 당시 사용되던 EJB를 겨냥한 것으로 자바가 특정 프레임워크에 종속되는 패턴을 극복, 순수한 본래 형태로 돌아가야 한다는 일종의 개혁적인 메시지를 가지고 있었다.

그리고 이 POJO는 개발자들 사이에서 큰 공감을 얻고 확산되어 이는 추후 스프링이라는 이름의 프레임워크의 뼈대로 작용했다.

해결하고자 한 목표들

1. 경량화
   복잡한 EJB 없이 POJO로 개발할 수 있게 했다

2. 제어반전
   객체 생성과 의존성 주입을 프레임워크가 대신 관리해 코드의 결합도를 낮췄다

3. 관심사의 분리
   로깅, 보안, 트랙재션과 같은 공통 기능을 비즈니스 로직과 분리해 모듈화했다

4. 테스트 용이성
   무거운 서버에 올리지 않고, 단위 테스트가 가능했다

5. 생산성 향상
   XML 설정을 줄이고 점진적 어노테이션 기발 개발으로 쉽게 개발이 가능했다

6. 유연성 확보
   전체를 강제하지 않고 필요한 기능만 선택해서 쓸 수 있는 모듈성을 제공했다

프레임워크와 라이브러리의 차이점

1. 제어흐름의 주체
   프레임워크 - 프레임워크가 제어
   라이브러리 - 개발자가 제어

2. 사용방식
   프레임워크 - 개발자가 프레임워크 규칙을 따르며 필요 코드 작성
   라이브러리 - 개발자가 필요한 기능을 직접 호출

3. 개발자 역할
   프레임워크 - 프레임워크가 개발자 코드를 호출
   라이브러리 - 개발자가 라이브러리를 호출

4. 제어 흐름 예시
   프레임워크 - 객체 생성, 초기화, 실행 순서 등을 프레임워크가 관리
   라이브러리 - 원하는 기능을 직접 불러 사용

• 예시
  프레임워크
  스프링 컨테이너가 전체 흐름을 관리
  객체(Bean) 생성 -> 의존성 주입 -> 라이프사이클 관리 -> 호출

  라이브러리
  개발자가 필요한 기능을 직접 호출