@Component (r1)

@Component는 스프링 프레임워크에서 관리되는 빈을 나타내는 어노테이션이다. 이 어노테이션을 클래스에 부여하면, 해당 클래스는 스프링 컨테이너에 의해 빈으로 등록되고 관리되는 대상이 된다. 이는 스프링의 핵심 원리인 제어의 역전과 의존성 주입을 적용받기 위한 기본적인 선언 단계에 해당한다.

@Component는 스테레오타입 어노테이션이라는 계층에 속한다. 이는 단순히 빈 등록을 표시하는 것을 넘어, 애플리케이션 내에서 해당 클래스가 수행하는 일반적인 역할(컴포넌트)을 의미하는 마커 역할을 한다. 이 계층의 구체적인 구현체로는 비즈니스 로직을 담당하는 @Service, 데이터 접근 계층을 표시하는 @Repository, 웹 계층의 컨트롤러를 나타내는 @Controller 등이 있으며, 이들 어노테이션은 모두 내부적으로 @Component를 메타 어노테이션으로 포함하고 있어 동일하게 빈 등록의 기능을 상속받는다.

빈으로 등록되기 위해서는 @Component가 부여된 클래스를 스프링 컨테이너가 인식해야 한다. 이는 주로 @ComponentScan 어노테이션을 통해 이루어진다. @ComponentScan이 지정된 범위 내에서 @Component 어노테이션(또는 이를 메타 어노테이션으로 포함한 @Service, @Repository 등)이 붙은 클래스를 자동으로 탐색하여 빈 정의를 생성하고 IoC 컨테이너에 등록하는 과정을 수행한다.

따라서 @Component는 스프링 기반 애플리케이션에서 POJO를 스프링이 관리하는 객체로 변환시키는 가장 기본적이고 필수적인 메커니즘의 출발점이다. 이를 통해 개발자는 복잡한 XML 설정 없이도 간편하게 빈을 등록하고, 스프링의 다양한 서비스를 활용할 수 있는 기반을 마련하게 된다.

@Component 어노테이션의 핵심 역할은 클래스를 스프링 프레임워크의 관리 대상, 즉 빈으로 표시하는 것이다. 이 어노테이션이 부여된 클래스는 스프링 IoC 컨테이너에 의해 인스턴스가 생성되고, 그 생명주기가 관리되며, 필요한 곳에 의존성 주입될 수 있는 자격을 부여받는다. 이는 개발자가 객체의 생성과 관리를 직접 코딩하지 않고, 프레임워크에 위임함으로써 관심사의 분리를 실현하는 데 기여한다.

주요 목적은 애플리케이션의 핵심 구성 요소를 컴포넌트 스캔을 통해 자동으로 탐지하고 등록하는 프로세스를 가능하게 하는 것이다. @ComponentScan이 설정된 범위 내에서 이 어노테이션이 붙은 모든 클래스는 스프링 컨테이너에 의해 자동으로 빈으로 등록된다. 이를 통해 XML이나 자바 설정 클래스에 각 빈을 일일이 명시적으로 선언하는 수고를 덜고, 애플리케이션 구조의 변화에 더 유연하게 대응할 수 있다.

또한, @Component는 더 구체적인 역할을 나타내는 스테레오타입 어노테이션들의 메타 어노테이션으로 사용된다. 예를 들어, 비즈니스 로직을 담당하는 @Service, 데이터 접근 계층을 표시하는 @Repository, 웹 계층의 컨트롤러를 나타내는 @Controller 어노테이션들은 모두 내부에 @Component를 포함하고 있다. 이는 공통적인 빈 등록 기능을 재사용하면서도 각 계층에 맞는 의미론적 역할과 추가적인 기능(예: @Repository의 예외 변환)을 부여하는 계층 구조를 형성한다.

결국, @Component의 역할은 스프링 기반 애플리케이션에서 관리 객체를 선언하고, 자동 구성을 가능하게 하며, 계층 구조를 위한 기반을 제공하는 데 있다. 이는 설정보다 관례 원칙을 따르며 개발 생산성을 높이고, 깔끔한 아키텍처를 유지하는 데 기여한다.

@Component 어노테이션은 주로 스프링 프레임워크의 핵심 기능인 제어의 역전과 의존성 주입을 구현하는 데 사용된다. 이 어노테이션은 스프링 애플리케이션 컨텍스트가 관리하는 빈을 표시하는 가장 일반적인 방법으로, 자바 기반의 스프링 부트 애플리케이션에서 광범위하게 활용된다.

@Component는 스프링의 스테레오타입 어노테이션 계층 구조에서 최상위에 위치한다. 이는 @Service, @Repository, @Controller와 같은 다른 스테레오타입 어노테이션들이 내부적으로 @Component를 포함하고 있어, 궁극적으로 모두 동일한 방식으로 스프링 컨테이너에 의해 빈으로 등록됨을 의미한다. 따라서 @Component는 스프링 IoC 컨테이너가 관리해야 하는 모든 일반적인 POJO 클래스에 적용할 수 있는 범용 마커 역할을 한다.

주요 사용 프레임워크는 스프링 프레임워크와 이를 기반으로 한 스프링 부트이다. 스프링 부트는 자동 구성 기능을 통해 @ComponentScan을 기본적으로 활성화하여, 애플리케이션의 기본 패키지 및 하위 패키지에서 @Component가 붙은 클래스를 자동으로 탐색하고 빈 정의를 생성한다. 이로 인해 개발자는 XML이나 자바 설정 파일에 빈을 일일이 선언하지 않아도 되어 생산성이 크게 향상된다.

이 어노테이션의 사용은 순수 스프링 프레임워크 프로젝트뿐만 아니라 스프링 시큐리티, 스프링 배치, 스프링 클라우드 등 스프링 생태계의 다른 모듈을 사용하는 프로젝트에서도 동일한 원리로 적용된다. 또한, 자바 EE나 일반 자바 SE 환경에서 스프링을 도입할 때도 @Component는 애플리케이션 컴포넌트를 정의하는 표준 수단이 된다.

@Component 어노테이션의 가장 큰 장점 중 하나는 재사용성을 극대화할 수 있다는 점이다. 이 어노테이션을 적용한 클래스는 스프링 프레임워크의 IoC 컨테이너에 의해 빈으로 등록되어 관리된다. 이는 특정 비즈니스 로직이나 유틸리티 기능을 담당하는 컴포넌트를 한 번 정의해두면, 애플리케이션 내의 여러 다른 클래스나 모듈에서 반복적으로 인스턴스를 생성하지 않고도 동일한 객체를 주입받아 사용할 수 있게 함을 의미한다. 결과적으로 코드 중복을 줄이고 일관된 동작을 보장한다.

이러한 재사용성은 의존성 주입 메커니즘과 결합되어 더욱 효과를 발휘한다. 개발자는 새로운 객체를 필요로 하는 곳에서 매번 new 키워드로 인스턴스를 생성할 필요 없이, @Autowired 어노테이션 등을 통해 컨테이너가 관리하는 빈을 쉽게 주입받을 수 있다. 이는 객체 지향 프로그래밍의 원칙 중 하나인 관심사의 분리를 실현하며, 컴포넌트 간의 결합도를 낮춘다. 따라서 특정 컴포넌트의 내부 구현이 변경되더라도, 이를 사용하는 다른 부분의 코드를 크게 수정하지 않아도 된다.

또한, @Component는 @Service, @Repository, @Controller와 같은 더 구체적인 스테레오타입 어노테이션의 기반이 된다. 이들은 모두 @Component를 메타 어노테이션으로 포함하므로, 기본적인 재사용성과 빈 관리의 혜택을 공유한다. 예를 들어, 데이터 접근 계층의 컴포넌트에 @Repository를 사용하면, 해당 클래스는 자동으로 스프링의 데이터 접근 예외 변환 등의 추가적인 혜택을 받으면서도, 다른 서비스 계층에서 재사용 가능한 빈으로 활용될 수 있다.

이처럼 @Component를 통한 재사용성 향상은 개발 생산성을 높이고, 애플리케이션의 유지보수성과 테스트 용이성을 개선하는 데 기여한다. 잘 설계된 컴포넌트는 하나의 애플리케이션을 넘어 다른 프로젝트에서도 모듈 형태로 재사용될 가능성을 열어준다.

@Component 어노테이션이 부여된 클래스는 스프링 프레임워크의 핵심 원칙 중 하나인 의존성 주입(Dependency Injection, DI)의 대상이 된다. 스프링 컨테이너(또는 IoC 컨테이너)는 @Component로 표시된 클래스의 인스턴스를 생성하고 관리하며, 이 빈(Bean)들이 필요로 하는 다른 의존성(Dependency)을 자동으로 연결해 준다.

의존성 주입은 주로 생성자, 세터(Setter) 메서드, 또는 필드에 @Autowired 어노테이션을 사용하여 구현한다. 예를 들어, 한 @Component 빈이 데이터베이스 접근을 위해 다른 @Repository 빈을 필요로 할 때, 컨테이너는 해당 의존성을 찾아 자동으로 주입한다. 이 방식은 클래스가 직접 의존 객체를 생성하거나 찾지 않아도 되게 하여 결합도(Coupling)를 낮추고 테스트 용이성(Testability)을 높인다.

@Component를 기반으로 한 의존성 주입의 가장 큰 장점은 설정의 자동화이다. 개발자는 XML이나 자바 설정 클래스(@Configuration)에서 각 빈과 그 의존 관계를 일일이 선언하지 않아도 된다. 대신 컴포넌트 스캔(@ComponentScan)이 지정된 패키지 내의 @Component 어노테이션을 발견하고, 의존성 주입을 위한 와이어링(Wiring)을 컨테이너가 담당하게 된다. 이는 대규모 애플리케이션의 개발과 유지보수 효율성을 크게 향상시킨다.

@Component 어노테이션이 지정된 클래스는 스프링 프레임워크의 핵심인 IoC 컨테이너에 의해 빈으로 등록된다. 이 컨테이너는 빈의 생성부터 소멸까지 전 과정을 관리하는데, 이를 빈 생명주기라고 한다. 컨테이너는 빈을 초기화할 때 의존성 주입을 완료하고, 필요에 따라 지정된 초기화 메서드를 호출한다. 반대로, 컨테이너가 종료될 때는 빈을 정리하기 위해 지정된 소멸 메서드를 호출한다.

개발자는 빈의 생명주기 특정 시점에 실행되어야 하는 로직을 직접 제어할 수 있다. 가장 일반적인 방법은 초기화 콜백과 소멸 콜백 메서드에 @PostConstruct와 @PreDestroy 어노테이션을 각각 부여하는 것이다. 이 어노테이션들은 자바 EE 표준에 속하며, 스프링이 이를 지원한다. @PostConstruct가 붙은 메서드는 빈의 의존성 주입이 모두 완료된 직후에, @PreDestroy가 붙은 메서드는 컨테이너가 종료되어 빈이 제거되기 직전에 자동으로 실행된다.

또 다른 방법으로는 스프링의 InitializingBean과 DisposableBean 인터페이스를 구현하는 것이다. 각 인터페이스의 afterPropertiesSet() 메서드와 destroy() 메서드를 구현하면, 전자와 후자는 각각 초기화와 소멸 시점에 컨테이너에 의해 호출된다. 그러나 이 방식은 스프링 전용 인터페이스에 코드가 결합된다는 단점이 있다.

이러한 생명주기 관리 메커니즘을 통해, 데이터베이스 연결 풀 초기화, 캐시 데이터 로딩, 사용 중인 자원의 정리 작업 등을 안정적으로 수행할 수 있다. 이는 @Component로 선언된 빈이 단순한 객체가 아닌, 컨테이너에 의해 철저히 관리되는 구성 요소임을 보여준다.

@Component 어노테이션을 사용하여 빈을 선언하는 방법은 매우 직관적이다. 기본적으로 스프링 프레임워크가 관리할 컴포넌트 클래스의 선언부 위에 @Component 어노테이션을 추가하기만 하면 된다. 이는 해당 클래스가 스프링 IoC 컨테이너에 의해 인스턴스화되고 의존성 주입의 대상이 될 수 있음을 표시한다.

보다 명시적인 빈 이름을 부여하려면 @Component 어노테이션의 value 속성을 사용할 수 있다. 예를 들어, @Component("myService")와 같이 지정하면, 스프링 컨테이너는 해당 빈을 고유한 이름으로 등록한다. 속성을 생략할 경우, 스프링은 클래스 이름의 첫 글자를 소문자로 변환한 값을 기본 빈 이름으로 사용한다.

@Component는 메타 어노테이션으로, 더 구체적인 역할을 나타내는 @Service, @Repository, @Controller 등의 스테레오타입 어노테이션의 기반이 된다. 따라서 실제 개발에서는 비즈니스 로직 계층에는 @Service를, 데이터 접근 계층에는 @Repository를, 프레젠테이션 계층에는 @Controller를 주로 사용하는 것이 일반적이다. 이러한 어노테이션들은 모두 내부적으로 @Component를 포함하고 있어 동일하게 컴포넌트 스캔의 대상이 된다.

선언된 @Component 클래스가 실제로 스프링 애플리케이션 컨텍스트에 등록되려면, 해당 클래스가 위치한 패키지 또는 그 상위 패키지가 @ComponentScan 어노테이션의 스캔 범위에 포함되어야 한다. 자바 기반 설정에서는 @Configuration 클래스에 @ComponentScan을 추가하여 탐색 경로를 지정한다.

@Component 어노테이션이 부여된 클래스가 스프링 프레임워크의 IoC 컨테이너에 빈으로 등록되기 위해서는 해당 클래스를 컨테이너가 인식할 수 있어야 한다. 이를 위해 주로 사용되는 방법은 컴포넌트 스캔이다. @ComponentScan 어노테이션을 사용하면 스프링은 지정된 기본 패키지 및 그 하위 패키지를 탐색하여 @Component 또는 이를 메타 어노테이션으로 포함한 @Service, @Repository, @Controller 등이 붙은 클래스를 자동으로 찾아내고, 이를 스프링 빈으로 등록한다.

컴포넌트 스캔은 자바 설정 클래스에 @ComponentScan 어노테이션을 선언하거나, XML 설정 파일에서 <context:component-scan> 요소를 사용하여 활성화할 수 있다. 스캔 범위를 제한하기 위해 특정 패키지 경로를 명시적으로 지정하거나, includeFilter 및 excludeFilter 속성을 활용하여 특정 어노테이션 유형이나 클래스를 포함하거나 제외시킬 수도 있다. 이 과정에서 스프링은 리플렉션을 통해 클래스의 메타데이터를 읽어 빈 정의를 생성한다.

자동으로 스캔되어 등록된 빈의 기본 이름은 클래스 이름의 첫 글자를 소문자로 바꾼 형태이다. 예를 들어, UserService 클래스는 userService라는 이름의 빈으로 등록된다. @Component 어노테이션의 value 속성에 값을 직접 지정하면, 이 값이 빈의 고유한 이름으로 사용된다.

@Component로 선언된 빈의 의존성 설정은 주로 생성자 주입, 필드 주입, 세터 주입 방식을 통해 이루어진다. 스프링 프레임워크의 핵심 원칙인 제어의 역전과 의존성 주입을 실현하는 구체적인 방법이다. 생성자 주입은 의존 객체를 final로 선언할 수 있어 불변성을 보장하고, 순환 의존성을 사전에 발견할 수 있어 권장되는 방식이다. 필드 주입은 코드가 간결하지만 테스트의 어려움 등 단점이 있어 최근에는 지양되는 경향이 있다.

의존성을 주입받을 대상에는 @Autowired 어노테이션을 사용한다. 스프링 4.3 버전 이후로는 빈에 생성자가 하나만 있고, 그 생성자의 매개변수가 모두 스프링 컨테이너에 등록된 빈이라면 @Autowired 어노테이션을 생략할 수 있다. 또한 @Qualifier 어노테이션을 함께 사용하면 동일한 타입의 빈이 여러 개 있을 때 특정 빈의 이름을 지정하여 주입받을 수 있다. @Resource나 @Inject 같은 자바 표준 또는 다른 어노테이션을 사용할 수도 있지만, 스프링 생태계에서는 @Autowired가 가장 일반적이다.

@Component가 아닌 @Configuration 클래스 내에서 @Bean 메서드를 사용해 빈을 정의할 때는, 메서드 파라미터를 통해 다른 빈을 자연스럽게 주입받아 설정할 수 있다. 이는 XML 설정 파일에서 <constructor-arg>나 <property> 태그를 사용하는 방식과 유사한 결과를 가져오지만, 자바 기반의 설정 방식이다. 최신 스프링 부트 애플리케이션에서는 이러한 자바 설정 방식이 표준으로 자리 잡았다.

의존성 설정의 궁극적인 목표는 클래스 간의 결합도를 낮추고, 유닛 테스트를 용이하게 하며, 애플리케이션의 유연성과 확장성을 높이는 데 있다. @Component로 등록된 빈들은 스프링 IoC 컨테이너에 의해 그 생명주기와 의존 관계가 관리되며, 이는 견고한 애플리케이션 아키텍처를 구축하는 데 기여한다.

@Component 어노테이션을 사용하는 주요 장점은 스프링 프레임워크의 핵심 원칙인 제어의 역전과 의존성 주입을 효과적으로 실현하여 개발 생산성과 애플리케이션 품질을 높이는 데 있다.

가장 큰 장점은 설정의 간소화이다. XML과 같은 외부 설정 파일에 일일이 빈을 정의하지 않아도, 클래스에 간단히 @Component를 추가하는 것만으로 스프링 IoC 컨테이너에 자동으로 등록된다. 이는 @ComponentScan과 결합되어 자동 구성을 가능하게 하여, 프로젝트 규모가 커질수록 반복적인 설정 작업을 크게 줄여준다. 또한, 의존성 주입이 어노테이션 기반(@Autowired)으로 명시적으로 이루어지기 때문에, 코드 가독성이 향상되고 객체 간의 의존 관계를 코드 상에서 직관적으로 파악할 수 있다.

두 번째로 중요한 장점은 관심사의 분리와 테스트 용이성이다. @Component로 등록된 빈은 그 생성과 의존성 해결을 스프링 컨테이너가 전담하므로, 비즈니스 로직에 집중할 수 있다. 이는 단일 책임 원칙을 지키는 데 도움이 된다. 또한, 컨테이너가 의존성을 주입해주기 때문에, 단위 테스트 시 목 객체나 스텁을 쉽게 주입하여 해당 컴포넌트를 격리된 상태에서 테스트하기 용이하다.

마지막으로, @Component는 스테레오타입 어노테이션의 기반이 되어 계층별 역할을 명시하는 데 기여한다. @Service, @Repository, @Controller 등은 모두 내부에 @Component를 포함하는 메타 어노테이션이다. 이를 통해 개발자는 클래스가 서비스 계층, 데이터 접근 계층, 표현 계층 중 어디에 속하는지 코드만 보고도 명확히 구분할 수 있으며, 스프링이 각 계층에 맞는 추가 기능(예: @Repository의 예외 변환)을 제공할 수 있는 토대를 마련한다.

@Component 어노테이션의 사용은 명확한 장점에도 불구하고 몇 가지 주의할 점을 동반한다. 가장 큰 단점은 과도한 사용으로 인한 의존성 관계의 복잡성이 증가할 수 있다는 점이다. 많은 클래스에 @Component를 적용하면 스프링 프레임워크의 IoC 컨테이너가 관리하는 빈의 수가 늘어나고, 이들 간의 관계가 복잡해져 전체 애플리케이션 구조를 파악하기 어려워질 수 있다. 이는 특히 대규모 프로젝트에서 유지보수의 어려움으로 이어질 수 있다.

또 다른 단점은 명시성의 부재이다. @Component는 가장 일반적인 스테레오타입 어노테이션으로, 해당 클래스가 애플리케이션에서 어떤 구체적인 역할(서비스 계층, 데이터 접근 계층, 표현 계층)을 수행하는지 직관적으로 알기 어렵다. 반면 @Service, @Repository, @Controller와 같은 하위 어노테이션을 사용하면 코드를 읽는 개발자에게 계층적 역할에 대한 추가적인 정보를 제공할 수 있어 가독성과 유지보수성에 도움이 된다.

마지막으로, @Component를 통한 자동 스캔은 편리하지만, 때로는 예상치 못한 부작용을 초래할 수 있다. 클래스패스 스캔 범위가 넓을 경우 원치 않는 클래스가 빈으로 등록되거나, 동일한 타입의 빈이 여러 개 생성되어 의존성 주입 시 충돌이 발생할 수 있다. 이러한 상황에서는 @ComponentScan의 필터 설정을 세밀하게 조정하거나, 특정 빈에 대해서는 명시적인 자바 설정 방식(@Bean 어노테이션 사용)을 통해 등록하는 것이 더 나은 선택이 될 수 있다.

@Bean은 스프링 프레임워크에서 빈을 정의하는 데 사용되는 메서드 레벨 어노테이션이다. @Component가 클래스 자체를 빈으로 등록하는 반면, @Bean은 주로 자바 설정 클래스(@Configuration이 붙은 클래스) 내의 메서드에 적용되어, 해당 메서드가 반환하는 객체를 스프링 IoC 컨테이너에 빈으로 등록하도록 지시한다. 이는 개발자가 인스턴스화 과정을 직접 제어해야 하는 서드파티 라이브러리의 클래스나 반환 타입을 인터페이스로 지정해야 하는 경우 등에 유용하게 사용된다.

@Bean 어노테이션을 사용하면 빈의 이름, 초기화 및 소멸 메서드, 싱글톤 범위 여부 등 다양한 속성을 세밀하게 설정할 수 있다. 메서드의 이름이 기본적인 빈의 이름이 되며, name 속성을 통해 별도의 이름을 부여할 수도 있다. 이렇게 정의된 빈은 의존성 주입의 대상이 되어 애플리케이션 전반에서 재사용될 수 있다.

@Component와 @Bean의 핵심적인 차이는 선언 방식에 있다. @Component(및 이를 메타 어노테이션으로 포함하는 @Service, @Repository 등)는 클래스 선언부에 직접 붙여 컴포넌트 스캔을 통해 자동으로 감지되는 반면, @Bean은 메서드를 통해 프로그래밍적으로 빈을 정의한다. 따라서 @Bean은 외부 라이브러리를 빈으로 등록하거나, 빈 생성 과정에 특별한 로직이 필요한 복잡한 경우에 선호되는 방식이다.

@Component는 스프링 프레임워크에서 정의된 대표적인 스테레오타입 어노테이션이다. 스테레오타입 어노테이션이란 특정 계층이나 역할을 표시하기 위해 사용되는 메타데이터 어노테이션을 말하며, 이 어노테이션이 부여된 클래스는 스프링 IoC 컨테이너에 의해 자동으로 빈(Spring)으로 등록되어 관리된다. @Component는 이러한 스테레오타입 어노테이션의 가장 기본이 되는 형태로, 컴포넌트 스캔의 대상이 된다.

보다 구체적인 역할을 나타내기 위해 @Component를 기반으로 한 파생 어노테이션들이 널리 사용된다. 대표적으로 비즈니스 로직을 담당하는 서비스 계층에는 @Service, 데이터 접근 계층에는 @Repository, 웹 애플리케이션의 MVC 패턴에서 컨트롤러 역할을 하는 클래스에는 @Controller 어노테이션을 사용한다. 이들 어노테이션은 내부적으로 @Component를 포함하고 있어, 모두 동일하게 컴포넌트 스캔의 대상이 되며 의존성 주입이 가능한 빈으로 등록된다.

이러한 파생 어노테이션들을 사용하는 주된 목적은 계층을 명시적으로 구분하여 코드의 가독성과 유지보수성을 높이기 위함이다. 예를 들어 @Repository 어노테이션은 데이터베이스 접근 중 발생할 수 있는 특정 예외를 스프링의 통일된 데이터 접근 예외로 변환해주는 부가 기능을 제공하기도 한다. 따라서 개발자는 클래스의 역할에 따라 적절한 스테레오타입 어노테이션을 선택하여 사용하는 것이 권장된다.

@Component 및 다른 스테레오타입 어노테이션의 탐지와 빈 등록은 주로 @ComponentScan 어노테이션에 의해 이루어진다. 이 설정을 통해 스프링은 지정된 패키지 경로를 재귀적으로 탐색하며 @Component가 부여된 클래스와 이를 메타 어노테이션으로 포함한 모든 클래스를 찾아내어 애플리케이션 컨텍스트에 자동으로 등록한다.

IoC 컨테이너는 제어의 역전 원칙을 구현하는 핵심 메커니즘으로, 애플리케이션을 구성하는 객체(빈)의 생성, 설정, 조립, 그리고 전반적인 생명주기를 관리하는 역할을 한다. 스프링 프레임워크의 핵심인 ApplicationContext가 대표적인 IoC 컨테이너의 구현체이다. 이 컨테이너는 개발자가 직접 객체를 new 키워드로 생성하고 의존성을 연결하는 대신, 설정 정보(어노테이션 또는 XML)를 바탕으로 객체를 생성하고 객체 간의 의존 관계를 자동으로 주입한다.

컨테이너가 관리하는 객체는 빈이라고 불리며, @Component 어노테이션은 클래스를 스프링 빈으로 등록하기 위한 가장 기본적인 표시자이다. 컨테이너는 @ComponentScan이 활성화된 범위 내에서 이 어노테이션이 붙은 모든 클래스를 찾아내어, 내부적으로 인스턴스를 생성하고 관리 풀에 보관한다. 이를 통해 개발자는 비즈니스 로직에 집중할 수 있고, 객체 간의 결합도를 낮춘 유연한 애플리케이션을 구성할 수 있다.

IoC 컨테이너의 주요 이점은 의존성 주입을 통한 느슨한 결합과 싱글톤 범위의 빈 관리에 있다. 컨테이너는 일반적으로 애플리케이션 전체에서 각 빈 타입당 하나의 인스턴스만을 생성하여 공유함으로써 자원을 효율적으로 사용한다. 또한, AOP와 같은 고급 기능을 쉽게 적용할 수 있는 토대를 제공하여, 로깅이나 트랜잭션 관리와 같은 횡단 관심사를 모듈화하는 데 기여한다.