3) Spring 컨테이너, Bean

1. "Spring 컨테이너"란?

“Spring 컨테이너는 커피숍의 바리스타와 같다”

     

      1) 커피숍에선 손님이 주문하면, 바리스타가 재료를 조합해서 커피를 만들어 줌

      2) 바리스타는 커피를 만들기 위해서 커피 원두, 우유, 시럽 등 필요한 재료들을 잘 보관, 관리함

      3) 바리스타가 모든 걸 직접 만들고, 관리하니 손님은 그냥 주문만 하면 됨

      4) 즉, Spring 컨테이너는 객체(Bean)를 생성하고, 관리하며, 필요할 때 꺼내주는 "바리스타" 같은 존재

2. Bean 이란?

Bean은 커피숍에서 만드는 ‘커피’ 한 잔'

 

      1) Bean은 "Spring 컨테이너"가 관리하는 "객체"

      2) 직접 new 해서 만드는 게 아니라, Spring이 대신 만들어서 관리해 줌

      3) 필요한 곳에서 바로 가져다 쓸 수 있도록 미리 만들어 두거나, 요청 시 만들어줌

          (싱글톤, 프로토타입 등 범위가 있음)

//Bean 등록하기(Component)

import org.springframework.stereotype.Component

@Component
class CoffeeMaker {
    fun brew(): String = "coffee"
}


//Service에 Bean 주입받기 
import org.springframework.stereotype.Service
import com.example.coffee.CoffeeMaker

@Service
class CoffeeShop(private val coffeeMaker: CoffeeMaker) {
    fun serveCoffee() = coffeeMaker.brew()
}

 

3. 왜 Bean을 Spring 컨테이너가 관리할까?

      1) 객체 생성과 의존성 주입을 직접 하려면 코드가 복잡하고, 결합도가 높아짐

      2) Spring이 대신 관리하면 → 객체를 재활용, 라이프사이클 관리, 의존성 자동 주입(DI) 가능

           → 개발 효율 극대화

      3) 즉, ‘내가 커피숍 주인이라면 손님 주문이 들어오면 일일이 만드는 대신,

          미리 커피를 준비해 놓거나 필요한 재료를 다 준비해두는 것’

 

4. 왜 Spring Bean으로 등록하고 DI(의존성 주입)를 써야 할까?

      1) 결합도(Dependency) 감소와 유연성 증가

           - 직접 new로 객체를 만들면, 코드가 구체적 클래스에 강하게 의존하게 됨
              → 나중에 클래스 변경, 테스트, 유지보수가 어려워짐

           - DI를 사용하면 구현체가 바뀌어도 주입받는 쪽 코드는 변경 없이 그대로 사용 가능

           - 즉, “느슨한 결합(loose coupling)” 덕분에 유지보수, 확장성이 좋아짐

 

커피숍에서 원두를 바꾸고 싶을 때, 코드를 직접 수정하지 않고 Bean 설정만 바꾸면 끝

 

 

 

       2) 객체 관리의 책임 분리 (IoC: 제어의 역전)

           - 전통적 개발은 개발자가 객체 생성과 관리 책임을 전부 짊어짐

           - Spring은 컨테이너가 ‘객체 생성과 라이프사이클’을 관리해줌

             → 개발자는 ‘비즈니스 로직’에만 집중 가능

           - 덕분에 코드가 깔끔해지고 재사용성이 높아짐

 

       3) 테스트 용이성 (Mocking, 단위 테스트 편리)\

           - 직접 new 하면, 테스트할 때 실제 클래스가 강제로 사용돼서 대체하기 어려움

           - DI를 쓰면 테스트 시 Mock 객체나 가짜 구현체를 쉽게 주입할 수 있음

             → 테스트가 쉬워짐

           - 테스트 코드와 프로덕션 코드가 명확히 분리되고, 자동화가 가능

 

       4) 싱글톤 및 스코프 관리 용이

           - Spring 컨테이너는 기본적으로 Bean을 싱글톤으로 관리해서 메모리를 효율적으로 쓸 수 있음

           - 필요에 따라 요청마다 새 객체 생성(프로토타입), 세션별 객체 관리 등도 가능

           - 직접 new하면 이런 라이프사이클 관리가 힘듦

 

       5) 구성 변경, 확장에 유리

           - 설정 파일(XML, 어노테이션, 프로퍼티 등으로) Bean 구성만 바꾸면,

             애플리케이션 동작 방식을 쉽게 바꿀 수 있음

           - 직접 new하면 코드 내부를 수정해야 해서 번거로움

 

5. 결론

직접 new하는 건 ?

: 요리사가 모든 재료를 직접 사서 바로바로 요리하는 것.

 

Spring Bean + DI는?
: 주방 매니저가 재료 준비하고, 레시피에 맞게 재료를 셰프에게 미리 갖다 주는 것.

요리사는 요리하는 데만 집중하고, 매니저는 재료 준비·관리 담당.

따라서 전체 주방 운영이 더 효율적이고 체계적임.

val result = "직접 new로 객체를 만들면 개발자가 모든 걸 관리해야 해서
변경, 테스트, 확장이 어렵고 코드가 복잡해집니다.

Spring 컨테이너가 Bean을 관리하면, 객체 생성과 의존성을 컨테이너가 책임져서 
개발자는 비즈니스 로직에만 집중할 수 있습니다.

이게 바로 IoC(제어의 역전)와 DI(의존성 주입)의 핵심 가치입니다."