[Basic-4] 스프링 컨테이너의 생성과 빈 관리 메커니즘

 지금까지는 개발자가 직접 AppConfig 객체를 생성하고 의존관계를 주입하였다. 이제부터는 스프링 프레임워크의 핵심인 스프링 컨테이너에 이 역할을 맡기는 방법을 알아본다.

---

1. 스프링 컨테이너로의 전환

순수 자바 기반의 AppConfig를 스프링 기반으로 변경하기 위해서는 두 가지 어노테이션이 필요하다.

• @Configuration: 해당 클래스를 설정을 구성하는 정보로 사용하겠다는 선언이다.
• @Bean: 메서드를 호출하여 반환된 객체를 스프링 컨테이너에 등록하라는 지시어이다.

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

 이제 MemberApp 등 실행부에서는 AppConfig를 직접 생성하는 대신, 스프링 컨테이너인 ApplicationContext를 통해 객체를 조회하여 사용한다.

// 스프링 컨테이너 생성
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

// 컨테이너를 통해 빈(Bean) 조회
MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

---

2. 스프링 컨테이너의 생성 과정

 new AnnotationConfigApplicationContext(AppConfig.class)를 호출하면 내부적으로 다음과 같은 과정을 거쳐 컨테이너가 완성된다.

2.1. 스프링 컨테이너 생성

 구성 정보(AppConfig.class)를 인자로 받아 스프링 컨테이너를 생성한다. 컨테이너 내부에는 '빈 이름'과 '빈 객체'를 저장할 수 있는 공간이 마련된다.

2.2. 스프링 빈 등록

컨테이너는 구성 정보 클래스에 정의된 @Bean 붙은 메서드를 모두 호출하여 반환된 객체를 빈 이름과 함께 등록한다.

• 빈 이름: 기본적으로 메서드 이름을 사용한다. (예: memberService)
• 주의: 빈 이름은 항상 중복되지 않도록 고유하게 유지해야 한다.

2.3. 스프링 빈 의존관계 설정

 스프링 컨테이너는 설정 정보를 참고하여 등록된 빈들 사이의 의존관계를 주입(DI)한다. 단순히 자바 코드를 실행하는 것처럼 보이지만, 이후에 다룰 '싱글톤 보장'을 위한 특별한 처리가 내부적으로 일어난다.

---

3. 컨테이너 내부의 빈 조회 전략

스프링 컨테이너에서 빈을 찾는 가장 기본적인 방법은 ac.getBean() 메서드를 사용하는 것이다.

• 이름으로 조회: ac.getBean("이름", 타입)
• 타입으로 조회: ac.getBean(타입)
• 구체 타입으로 조회: 인터페이스가 아닌 구현 클래스 타입으로도 조회가 가능하지만, 이는 변경 유연성이 떨어지므로 지양해야 한다.

 만약 조회 대상 빈이 없으면 NoSuchBeanDefinitionException 예외가 발생한다. 또한, 동일한 타입의 빈이 둘 이상일 경우 이름을 명시하지 않으면 NoUniqueBeanDefinitionException이 발생하므로 주의가 필요하다.

---

4. BeanFactory와 ApplicationContext

흔히 스프링 컨테이너라고 부르는 것은 사실 두 가지 계층으로 나뉜다.

• BeanFactory: 스프링 컨테이너의 최상위 인터페이스로, 빈을 관리하고 조회하는 핵심 기능을 담당한다.
• ApplicationContext: BeanFactory의 기능을 상속받으면서, 국제화(메시지 소스), 환경변수 처리, 애플리케이션 이벤트, 리소스 조회 등 부가 기능을 추가로 제공한다.

 실무에서는 BeanFactory를 직접 사용하는 경우는 거의 없으며, 모든 부가 기능이 포함된 ApplicationContext를 스프링 컨테이너로 사용한다.

---

5. 설정 형식의 추상화: BeanDefinition

 스프링은 자바 코드뿐만 아니라 XML, Groovy 등 다양한 형식의 설정 정보를 지원한다. 이것이 가능한 이유는 BeanDefinition이라는 추상화 덕분이다.

 

 스프링 컨테이너는 설정 정보가 자바 코드인지 XML인지 알 필요가 없다. 각 설정 파일을 읽어서 BeanDefinition이라는 메타 정보를 만들어 컨테이너에 넘겨주기만 하면 된다. 이를 통해 스프링은 특정 설정 형식에 종속되지 않는 유연한 구조를 가지게 된 것이다.

---

결론: 컨테이너 사용의 이유

 스프링 컨테이너를 사용하면 객체의 생성과 관리를 자동화할 수 있을 뿐만 아니라, 엔터프라이즈 환경에 필수적인 '싱글톤 유지', '생명주기 관리' 등의 강력한 혜택을 누릴 수 있다.