[📰 위클리페이퍼 ] Spring Framework?

📌 Spring Framework

🧐 탄생 배경

2000년대 초반 자바 엔터프라이즈 애플리케이션 개발은 EJB(Enterprise JavaBeans) 중심
당시 EJB는 대규모 시스템을 만들기에는 기능이 많고 강력했지만, 실제 현업에서는 여러 심각한 문제들이 있었음
-> Spring은 “EJB 없이도 엔터프라이즈 애플리케이션을 만들 수 있다”는 철학에서 출발

1. IoC / DI (제어의 역전, 의존성 주입)

• 객체가 직접 의존 대상을 생성하지 않고, 외부(Spring 컨테이너) 에서 주입받도록 설계
• 결과: 결합도 감소, 구현체 교체 용이, 테스트 쉬워짐 (Mock 객체 사용 가능)

2. POJO 기반 개발

• 특정 프레임워크를 상속하거나 인터페이스를 구현하지 않아도 됨
• 순수 자바 객체(POJO)로 비즈니스 로직 작성 가능
• 프레임워크에 덜 종속적인 코드 작성 가능

3. AOP (관점 지향 프로그래밍)

• 트랜잭션, 로깅, 보안 같은 횡단 관심사를 분리
• 비즈니스 로직은 핵심 기능에만 집중 가능

4. 경량 컨테이너

• EJB 컨테이너에 비해 훨씬 가볍고 설정이 단순
• 필요한 기능만 선택적으로 사용 가능

---

📌 Framework vs 라이브러리

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

프레임워크와 라이브러리는 모두 개발을 돕는 도구이지만, 제어 흐름의 주체와 사용 방식에서 본질적인 차이가 있음

1️⃣ 제어 흐름의 주체

라이브러리

• 제어 흐름의 주체는 개발자
• 개발자가 필요한 시점에 라이브러리의 기능을 직접 호출
• 프로그램의 전체 흐름은 개발자가 설계하고 관리

프레임워크

• 제어 흐름의 주체는 프레임워크
• 개발자는 프레임워크가 정한 규칙에 따라 코드를 작성
• 프레임워크가 필요할 때 개발자의 코드를 호출
  → 이를 제어의 역전(Inversion of Control, IoC) 이라고 함

2️⃣ 사용 방식의 차이

라이브러리의 사용 방식

• 필요한 기능만 선택적으로 사용
• 코드에 자유도가 높고 제약이 적음
• 전체 구조를 강제하지 않음

프레임워크의 사용 방식

• 정해진 구조와 생명주기(lifecycle)를 따름
• 애플리케이션의 뼈대를 제공
• 개발자는 “어디에 무엇을 구현할지”를 프레임워크 규칙에 맞춰 작성

🔍 예시를 통한 설명

일반 Java 라이브러리 예시

예를 들어, java.util.List 나 Collections 같은 Java 라이브러리를 사용하는 경우:
개발자가 직접 객체를 생성하고 필요한 메서드를 원하는 시점에 호출

List<String> list = new ArrayList<>();
Collections.sort(list);

→ 흐름은 개발자가 제어하며, 라이브러리는 단순히 기능을 제공할 뿐이다.

Spring Framework 예시

Spring Framework는 대표적인 프레임워크
객체 생성과 의존성 관리를 개발자가 아닌 Spring 컨테이너가 담당
개발자는 @Component, @Service, @Controller 등의 어노테이션을 사용해 역할만 정의

@Service
public class UserService {
}

실제 객체 생성 시점과 호출 흐름은 Spring이 관리
→ 개발자가 코드를 호출하는 것이 아니라, Spring이 개발자의 코드를 호출함