스프링 빈(Bean) 등록 방식 정리

 

스프링에서 가장 중요한 개념 중 하나는 빈(Bean)이다.
빈은 단순한 자바 객체가 아니라, 스프링 컨테이너가 생성하고 관리하는 객체를 의미한다.

즉, 객체는 그냥 new로 만든 것이고,
빈은 스프링이 대신 만들어서 관리하는 객체다.

 

빈은 어떻게 등록하는가

스프링에서 빈을 등록하는 방법은 하나가 아니다.
대표적으로 다음 3가지 방식이 있다.

1. 컴포넌트 스캔 (자동 등록)
2. @Bean을 이용한 수동 등록
3. XML <bean> 등록

중요한 포인트는 이것이다.

모든 빈을 하나의 방식으로 통일하는 것이 아니라,
상황에 따라 적절한 방식을 선택해서 사용한다.

 

 

 

컴포넌트 스캔 (자동 등록)

가장 많이 사용하는 방식이다.

@Service
public class TodoService {
}

@Repository
public class TodoRepository {
}

@Controller
public class TodoController {
}

 

이처럼 클래스에

• @Component
• @Service
• @Repository
• @Controller

같은 어노테이션을 붙이면,
스프링이 시작될 때 해당 클래스를 자동으로 찾아서 빈으로 등록한다.

이 과정을 컴포넌트 스캔이라고 한다.

특징

• 개발자가 직접 빈을 등록하지 않아도 된다
• 클래스에 역할이 명확하게 드러난다
• 프로젝트 규모가 커져도 관리가 편하다

언제 사용하는가

컴포넌트 스캔은 내가 직접 만든 클래스에 사용한다.

예:

• 서비스 클래스
• 리포지토리 클래스
• 컨트롤러 클래스
• 비즈니스 로직 클래스

이유는 간단하다.
내 코드이기 때문에 어노테이션을 직접 붙일 수 있기 때문이다.

 

 

@Bean으로 수동 등록

이번에는 자동이 아니라 직접 빈을 등록하는 방식이다.

@Configuration
public class AppConfig {

    @Bean
    public ModelMapper modelMapper() {
        return new ModelMapper();
  	}
}

 

이 코드는 다음 의미다.

"이 객체는 내가 직접 생성하니까, 스프링이 빈으로 등록해라"

 

즉 @Bean은
메서드가 반환하는 객체를 빈으로 등록하는 방식이다.

특징

• 객체 생성 과정을 개발자가 직접 제어한다
• 세부 설정을 넣을 수 있다
• 외부 라이브러리 객체 등록에 유리하다

언제 사용하는가

1. 외부 라이브러리 객체

ModelMapper, ObjectMapper, PasswordEncoder

 

이런 클래스는 내가 만든 것이 아니다.
따라서 @Service 같은 어노테이션을 붙일 수 없다.

2. 생성 과정이 복잡한 객체

@Bean
public ObjectMapper objectMapper() {
    ObjectMapper om = new ObjectMapper();
    om.findAndRegisterModules();
    return om;
}

 

이처럼 단순 new가 아니라
추가 설정이 필요한 경우 @Bean이 적합하다.

3. 생성 방식을 명확히 제어하고 싶은 경우

객체 생성 로직을 코드로 명확하게 드러내고 싶을 때 사용한다.

 

 

XML <bean> 등록

전통적인 방식이다.

<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource" />

 

XML 파일에 직접 빈을 등록하는 방식이다.

특징

• 어노테이션이나 자바 코드가 아닌 XML로 설정한다
• 예전 스프링 프로젝트에서 많이 사용했다
• 현재는 레거시 프로젝트에서 주로 볼 수 있다

언제 사용하는가

• 기존 프로젝트가 XML 기반일 때
• MyBatis, DataSource 같은 설정이 XML에 있을 때
• 레거시 코드 유지가 필요한 경우

 

 

왜 세 가지 방식을 섞어서 사용하는가

핵심은 이것이다.

각 방식이 잘 맞는 대상이 다르기 때문이다.

 

 

자동 스캔이 적합한 경우

@Service
public class TodoService

• 내가 만든 클래스
• 역할이 명확함
• 특별한 생성 로직 없음

@Bean이 적합한 경우

@Bean
public ModelMapper modelMapper()

• 외부 라이브러리 객체
• 생성 과정에 설정이 필요함

XML이 적합한 경우

<bean id="dataSource" ... />

• 기존 프로젝트 설정
• DB, MyBatis 같은 인프라 구성

 

 

모든 빈을 @Bean으로 등록하면 안 되나?

가능하다. 하지만 비효율적이다.

예:

@Bean
public TodoService todoService() {
	return new TodoService();
}

이런 식으로 모든 클래스를 등록할 수도 있다.

하지만 문제는 다음과 같다.

 

참고로 @Bean은 해당 메소드의 실행 결과로 반환된 객체를 스프링의 빈(Bean)으로 등록시키는 역할을 한다.

 

문제점

1. 코드가 너무 많아진다

클래스가 많아질수록 설정 코드가 폭발적으로 증가한다.

2. 가독성이 떨어진다

클래스만 봐서는 역할이 드러나지 않는다.

3. 대부분의 방식과 다르다

실무에서는 대부분 자동 스캔을 기본으로 사용한다.

 

정리

실무에서는 보통 다음 기준으로 나눈다.

 

컴포넌트 스캔

• Controller
• Service
• Repository

→ 비즈니스 로직 클래스

@Bean

• ModelMapper
• ObjectMapper
• PasswordEncoder

→ 외부 라이브러리 + 설정 객체

XML

• DataSource
• SqlSessionFactory

→ 레거시 / 인프라 설정

 

 

최종 결론

스프링에서는 모든 빈을 하나의 방식으로 등록하지 않는다.

• 자동 등록이 가능한 것은 컴포넌트 스캔을 사용한다
• 직접 설정이 필요한 것은 @Bean을 사용한다
• 기존 설정은 XML을 유지한다

즉 중요한 것은 방식이 아니라,
객체의 성격에 맞는 등록 방법을 선택하는 것이다.

 

 

 

정리

스프링 빈 등록은 하나로 통일하는 것이 아니라,

자동 스캔, @Bean, XML을 상황에 맞게 나누어 사용하는 구조이다.