왜 스프링은 객체를 직접 만들지 않게 했을까

스프링을 처음 배우면 대부분 가장 먼저 보는 코드가 있다.

UserService service = new UserService();

자바에서는 원래 이런 방식으로 객체를 직접 만든다. 필요한 시점에 new를 호출하고, 생성한 객체를 사용하면 끝이다. 작은 프로그램에서는 이 방식이 단순하고 직관적이다.

그런데 프로젝트 규모가 커지기 시작하면 상황이 달라진다.

예를 들어 UserService가 있다고 해보자. 이 서비스는 UserRepository를 사용한다. 그런데 UserRepository는 DB 연결 객체를 필요로 한다. 또 서비스 내부에서는 PasswordEncoder도 필요하고, MailSender도 필요하다. 결국 객체 하나를 만들기 위해 연관된 객체들을 계속 생성해야 한다.

UserRepository userRepository = new UserRepository(dataSource);

asswordEncoder passwordEncoder = new PasswordEncoder();

MailSender mailSender = new MailSender();

UserService userService =  new UserService(
				 		userRepository,
				 		passwordEncoder,
				 		mailSender
				 	);

처음에는 괜찮아 보이지만 서비스 수십 개, 리포지토리 수십 개가 생기기 시작하면 객체 생성 코드가 애플리케이션 전체에 퍼진다.

어떤 객체가 어디서 생성되는지 추적하기 어려워진다. 객체 생성 방식이 바뀌면 관련 코드를 전부 수정해야 한다.
테스트할 때 가짜 객체(Mock)로 교체하기도 불편하다. 싱글톤처럼 하나만 유지해야 하는 객체도 개발자가 직접 관리해야 한다.

스프링은 이 문제를 해결하려고 나왔다해도 과언이아니다.

“객체 생성과 연결을 개발자가 직접 하지 말고, 스프링이 대신 관리하자.”

그래서 스프링은 애플리케이션 시작 시점에 필요한 객체들을 생성해서 컨테이너 안에 보관한다. 그리고 객체가 필요할 때 자동으로 연결해준다.

이렇게 스프링이 관리하는 객체를 Bean이라고 부른다. 여기서 중요한 건 Bean이 단순한 객체가 아니라는 점이다. 빈으로 등록되는 순간 스프링은 다음 같은 작업들을 같이 관리할 수 있다.

- 객체 생성 시점 관리
- 의존성 자동 연결(DI)
- 싱글톤 관리
- 생명주기 관리
- AOP 적용
- 프록시 생성
- 트랜잭션 연결

즉, 스프링에서 “빈 등록”은 단순 등록이 아니다. 애플리케이션 운영 흐름 안으로 객체를 편입시키는 작업에 가깝다.
그런데 여기서 새로운 문제가 생긴다.

“그럼 객체를 어떻게 빈으로 등록할 건데?”

이 질문에 대한 대표적인 두 가지 방식이 바로 @ComponentScan과 @Bean이다.

둘 다 결과적으로는 객체를 스프링 빈으로 등록한다. 하지만 접근 방식이 완전히 다르다.

@ComponentScan은 스프링이 클래스를 자동으로 찾아 등록하는 방식이다.

반면 @Bean은 개발자가 직접 객체 생성 로직을 작성해서 등록하는 방식이다. 즉 둘의 차이는 단순 문법 차이가 아니다.

“자동으로 발견할 것인가” 아니면 “직접 조립해서 등록할 것인가” 이 철학의 차이다.

@ComponentScan은 어떻게 객체를 자동 등록할까

스프링 프로젝트를 만들고 클래스를 하나 작성한 뒤 @Service를 붙였는데, 아무 설정도 하지 않았는데 자동으로 주입되는 경험을 많이 한다.

@Service
public class UserService {}

처음 보면 신기하다. “아니 분명 new도 안 했는데 어떻게 객체가 생긴 거지?” @ComponentScan이 해당 클래스를 주입하는 역할을 한다.

스프링은 애플리케이션이 시작될 때 특정 패키지를 기준으로 클래스들을 전부 훑는다. 그리고 그 안에서 특정 애노테이션이 붙은 클래스들을 찾아 자동으로 빈으로 등록한다.

대표적으로 이런 애노테이션들이 대상이다.

 @Component
 @Service
 @Repository
 @Controller
 @RestController

사실 @Service나 @Repository도 내부적으로 보면 전부 @Component를 포함하고 있다. 예를 들어 @Service 내부를 보면 이런 느낌이다.

@Component
public @interface Service {}

즉 스프링 입장에서는 결국 “@Component 친척인가?”하고 등록하는 것이다. 개발자는 클래스에 애노테이션만 붙인다. 그러면 스프링이 알아서 찾고, 알아서 생성하고, 알아서 DI까지 연결한다.

@Service
public class UserService {}

@Repository
public class UserRepository {}

이 방식의 장점은 엄청 단순하다는 점이다. 프로젝트 구조만 잘 나눠두면 개발자는 비즈니스 로직에 집중할 수 있다. 객체 등록 코드도 거의 작성하지 않아도 된다. 특히 서비스, 리포지토리, 컨트롤러처럼 “애플리케이션을 구성하는 기본 객체들”은 대부분 반복적인 패턴을 가진다.

예를 들어 이런 클래스들이다.

- 회원 서비스
- 게시글 서비스
- 댓글 리포지토리
- 인증 컨트롤러
- 파일 업로드 서비스

이런 클래스들은 대부분 “하나의 역할을 가진 애플리케이션 내부 객체”다. 그래서 스프링은 이런 객체들을 자동으로 등록하는 방향을 선택했다. 덕분에 개발자는 이런 설정 코드를 거의 안 써도 된다.

@Bean
public UserService userService() {
    return new UserService(userRepository());
}

예전 스프링 XML 시절이나 초창기 자바 설정 방식에서는 이런 등록 코드가 엄청 많았다. 프로젝트가 커질수록 설정 파일이 비대해졌다.

그런데 @ComponentScan이 등장하면서 상황이 완전히 달라졌다.

“이 클래스는 서비스입니다.” , “이 클래스는 리포지토리입니다.”

이 정도만 선언하면 스프링이 나머지를 처리한다. 그래서 현대 스프링 프로젝트는 대부분 @ComponentScan 기반으로 굴러간다.

우리가 스프링부트 프로젝트를 생성하면 있는 @SpringBootApplication 안에는 실제로 @ComponentScan이 포함되어 있다.

@SpringBootApplication
public class Application {}

즉 애플리케이션 시작과 동시에 현재 패키지 기준으로 컴포넌트 스캔이 자동 수행된다. 그래서 패키지 구조가 굉장히 중요해진다. 예를 들어 메인 클래스가 com.example폴더에 존재하면 하위 패키지는 자동 스캔된다.

com.example.user, com.example.board, com.example.auth

이외폴더는 스캔되지 않는다. com.external.service 그래서 보통 메인 클래스를 최상위 패키지에 둔다.

@ComponentScan의 핵심은 “애플리케이션 내부에서 반복적으로 사용하는 객체는 자동으로 찾아서 등록하자.”

이 철학 덕분에 스프링 개발 생산성이 엄청 올라갔다 하지만 여기서 한 가지 문제가 남는다. 자동 등록이 항상 좋은 건 아니다. 어떤 객체는 개발자가 생성 과정을 직접 제어해야 한다. 어떤 객체는 외부 라이브러리라서 애노테이션을 붙일 수도 없다. 이때 @Bean을 자주 쓰곤한다.

@Bean은 왜 굳이 수동 등록 방식을 남겨뒀을까

@ComponentScan을 보면 다른 방식이 굳이 필요할까 싶다 클래스에 애노테이션만 붙이면 자동 등록된다. 설정 코드도 줄어든다. DI도 자동 연결된다. 그런데 스프링은 왜 굳이 @Bean이라는 수동 등록 방식을 아직까지 유지하고 있을까? 이유는 간단하다. 모든 객체가 “자동 등록하기 좋은 형태”는 아니기 때문이다.

예를 들어 이런 코드를 보자.

@Service
public class UserService {}

이 클래스는 굉장히 단순하다. 애플리케이션 내부에서 직접 만든 클래스고, 생성 방식도 특별하지 않다. 이런 객체는 @ComponentScan이 정말 잘 맞는다. 그런데 세상 모든 객체가 이런 식은 아니다. 대표적으로 외부 라이브러리 객체들이 있다. 예를 들어 ObjectMapper를 사용한다고 해보자.

ObjectMapper mapper = new ObjectMapper();

이 객체는 우리가 만든 클래스가 아니다. Jackson 라이브러리 내부 클래스다. 즉 클래스 소스에 직접 들어가서 @Component를 붙일 수 없다. 이럴 때 사용하는 방식이 @Bean이다.

@Configuration
public class AppConfig {
    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();
    }
}

개발자가 직접 객체 생성 로직을 작성하고, 그 결과 객체를 스프링 빈으로 등록하는 방식이다. @Bean은 단순 등록 기능이 아니다. “객체 생성 과정을 개발자가 통제할 수 있게 해주는 방식”이다.

여기서 @ComponentScan과의 철학 차이가 더 선명하게 드러난다. @ComponentScan은 “이 클래스 그냥 자동 등록해줘” 에 가깝다. 반면 @Bean은 “이 객체는 내가 직접 생성 과정을 관리할게” 에 가깝다. 그래서 @Bean은 객체 생성이 복잡할수록 힘을 발휘한다.

예를 들어 생성 과정에 옵션이 많거나, 환경 설정값이 필요하거나, 조건 분기가 필요한 경우다.

@Bean
public DataSource dataSource() {
    HikariDataSource ds =  new HikariDataSource();
    ds.setJdbcUrl(url);
    ds.setUsername(username);
    ds.setPassword(password);
    return ds;
}

이런 객체는 단순히 @Component 하나 붙여서 끝낼 수는 없고 생성 과정 자체가 설정이다. 특히 스프링에서 인프라 객체들은 대부분 @Bean 방식으로 등록된다. 예를 들면 이런 것들이다.

- DataSource
- ObjectMapper
- SecurityFilterChain
- RedisConnectionFactory
- Executor
- CacheManager
- RestTemplate
- WebClient

이 객체들의 공통점이 있다. 애플리케이션 핵심 비즈니스 객체라기보다는 “프레임워크 설정 성격”이 강하다. 그리고 생성 시점에 세부 옵션 설정이 필요하다.

그래서 보통 이렇게 구분한다.

비즈니스 로직 객체 → @ComponentScan 기반

설정/인프라 객체 → @Bean 기반

물론 절대 규칙은 아니다. @Service를 @Bean으로 등록할 수도 있고, @Component로 설정 객체를 만들 수도 있다. 하지만 유지보수 관점에서 보면 역할을 나누는 게 훨씬 읽기 쉽다. 그리고 @Bean의 진짜 강력한 점은 “반환 객체를 자유롭게 바꿀 수 있다”는 점이다.

@Bean
public PaymentService paymentService() {
    if (localMode) {
        return new FakePaymentService();
    }
    return new RealPaymentService();
}

이런 식으로 환경에 따라 구현체를 다르게 넣을 수도 있다. 즉 @Bean은 단순 객체 등록을 넘어서, “객체 조립 공장” 역할까지 할 수 있다. 결국 @ComponentScan과 @Bean은 경쟁 관계가 아니다.

자동 등록에 적합한 객체는 자동으로 처리하고, 생성 제어가 필요한 객체는 수동으로 구성하는 것. 스프링은 둘을 같이 사용하는 방향으로 설계되어 있다.

내가 만든 클래스와 외부 라이브러리 클래스의 차이

뭐 실제로 일할때나 공부할때나 @ComponentScan과 @Bean를 다르게 적용하고 싶어도 그 기준이 애마할때가 있다 둘 다 결국 빈 등록을 하기 때문이다. 그래서 처음에는 보통 이렇게 생각한다.

“둘 중 아무거나 써도 되는 거 아닌가?”

실제로 기술적으로만 보면 가능한 경우도 많다. 하지만 쓰다보면 두 방식은 꽤 자연스럽게 역할이 나뉜다. 핵심 기준 중 하나가 바로 이것이다.

“내가 직접 만든 클래스인가?” 아니면 “외부 라이브러리 클래스인가?”

예를 들어 UserService는 보통 우리가 직접 만든다.

@Service
public class UserService {}

이 클래스는 프로젝트 내부 코드다. 패키지 구조 안에 존재한다. 애노테이션도 자유롭게 붙일 수 있다. 이런 객체는 @ComponentScan이 가장 자연스럽다.

반대로 이런 객체를 보자. ObjectMapper , HikariDataSource , RedisTemplate , RestTemplate

이 객체들은 대부분 외부 라이브러리다. 즉 우리가 클래스 소스를 수정할 수 없다. @Component를 붙이고 싶어도 못 붙인다. 그래서 이런 객체들은 @Bean 방식으로 등록하게 된다.

@Configuration
public class AppConfig {
    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();
    }
}

그렇다고 Bean등록 기준이 “외부 클래스라서”만은 아니다. 외부 라이브러리 객체들은 보통 생성 과정이 단순하지 않다. 예를 들어 DataSource를 생각해보자. DataSource는 단순 객체 하나 생성한다고 끝나는 게 아니다.

- DB 주소
- 사용자 계정
- 비밀번호
- 커넥션 풀 개수
- 타임아웃
- 드라이버 설정

이런 값들을 조립해야 한다. 즉 객체 생성 자체가 설정 행위가 된다. 그래서 자연스럽게 @Bean 기반 구성이 잘 어울린다 반면 서비스 객체들은 대부분 생성 규칙이 단순하다.

@Service
public class OrderService {
    private final OrderRepository repository;
    public OrderService(
        OrderRepository repository
    ) {
        this.repository = repository;
    }
}

이런 객체는 특별한 생성 로직이 거의 없다. “그냥 생성해서 DI 연결만 하면 되는 객체”다. 그래서 자동 등록 방식이 훨씬 효율적이다. 이 흐름 때문에 스프링 프로젝트 구조를 보다 보면 패턴이 드러나기도한다.

service , repository , controller 이런 영역은 대부분 @Component 계열을 사용한다.

반대로 설정 클래스에서는 @Bean이 등장한다.

@Configuration
public class SecurityConfig {
    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

@Configuration
public class WebConfig {
    @Bean
    public ObjectMapper objectMapper() {
        return new ObjectMapper();
    }
}

마지막으로 정리하는 선택 기준과 흔한 오해

@ComponentScan과 @Bean을 뭐 역할이 다르다 목적이 다르다 설명을했지만 도착지는 같다 결과적으로 둘 다 객체를 스프링 빈으로 등록한다. 하지만 출발점이 다르다.

@ComponentScan은 클래스를 기준으로 출발한다. 스프링이 패키지를 훑다가 @Component 계열 애노테이션이 붙은 클래스를 발견하면 자동으로 빈으로 등록한다.

@Bean은 메서드를 기준으로 출발한다. 개발자가 직접 객체를 생성해서 반환하면, 스프링이 그 반환 객체를 빈으로 등록한다.

이 차이를 기억하면 선택 기준도 정리된다. 내가 직접 만든 클래스이고, 애플리케이션 안에서 하나의 역할을 수행하는 객체라면 @ComponentScan 쪽이 자연스럽다.

@Service
public class BoardService {

    private final BoardRepository boardRepository;

    public BoardService(
        BoardRepository boardRepository
    ) {
        this.boardRepository = boardRepository;
    }
}

이런 클래스는 굳이 설정 클래스에서 직접 만들 필요가 없다. BoardService는 게시글 기능을 처리하는 내부 구성원이다. 생성 방식도 단순하다. 필요한 의존성을 생성자로 받으면 된다. 이런 객체까지 전부 @Bean으로 등록하면 설정 코드가 불필요하게 늘어난다.

반대로 생성 과정 자체에 의미가 있는 객체라면 @Bean이 잘 맞는다.

@Configuration
public class SecurityConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}

이 코드는 단순히 PasswordEncoder 객체를 하나 만든다는 뜻에서 끝나지 않는다.

“우리 애플리케이션은 비밀번호 암호화 방식으로 BCrypt를 사용한다” 이 의도를 코드로 드러낸다. 그래서 @Bean은 설정의 의미가 강한 객체에 어울린다.

외부 라이브러리 객체도 마찬가지다.

ObjectMapper, DataSource, RedisTemplate, SecurityFilterChain 같은 객체는 우리가 직접 만든 클래스가 아니다.

클래스에 @Component를 붙일 수 없고, 생성 과정에 옵션이 들어가는 경우도 많다. 이런 객체는 @Bean으로 등록하는 편이 자연스럽다.

여기서 흔한 오해가 하나 있다. “@Bean으로 등록한 객체가 더 특별한 빈인가?” 그렇지는 않다. @ComponentScan으로 등록하든, @Bean으로 등록하든, 스프링 컨테이너에 들어간 뒤에는 둘 다 빈이다.

DI 대상이 될 수 있고, 싱글톤으로 관리될 수 있고, 필요한 곳에 주입될 수 있다. 차이는 등록된 이후가 아니라 등록되는 과정에 있다. 또 하나 조심할 부분은 중복 등록이다.

예를 들어 어떤 클래스에 @Service를 붙여두고, 동시에 @Bean으로도 같은 타입을 등록하면 어떻게 될까?

@Service
public class UserService { }

@Configuration
public class AppConfig {

    @Bean
    public UserService userService() {
        return new UserService();
    }
}

이런 코드는 스프링 입장에서는 UserService 타입 빈이 두 개 생길 수 있다. 그러면 주입 지점에서 어떤 빈을 넣어야 하는지 애매해질 수 있다.

물론 @Primary나 @Qualifier로 해결할 수는 있다. 하지만 애초에 같은 객체를 자동 등록과 수동 등록으로 동시에 관리하지 않는 편이 더 읽기 쉽다.

마지막으로 기준을 짧게 정리하면 이렇다. 서비스, 컨트롤러, 리포지토리처럼 애플리케이션 내부 역할을 가진 클래스는 @ComponentScan 기반으로 둔다.

외부 라이브러리 객체, 설정값을 조립해야 하는 객체, 생성 과정에서 의도를 드러내야 하는 객체는 @Bean으로 둔다.

@ComponentScan은 반복적인 내부 객체 등록을 줄여준다. @Bean은 자동 등록으로 표현하기 어려운 객체 생성 과정을 코드로 남겨준다.

그래서 둘 중 하나를 고르는 문제라기보다, 각 객체의 성격에 맞게 등록 방식을 나누는 문제에 가깝다.

스프링이 두 방식을 모두 제공하는 이유도 여기에 있다.

모든 객체를 자동으로 찾는 방식만으로는 설정의 의도를 표현하기 어렵고, 모든 객체를 직접 등록하는 방식만으로는 반복 코드가 너무 많아진다. @ComponentScan과 @Bean은 서로를 대체하는 기능이 아니라,

스프링 컨테이너를 구성하는 중요한 두 가지 입구다.