올바른 실무 운영 기준

자동 기능을 기본으로 사용하자

시간이 지날 수록 자동을 선호하는 추세다. 스프링은 @Component, @Controller, @Service, @Repository처럼 계층에 맞춰 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 게다가 최근 스프링 부트는 컴포넌트 스캔을 그냥 기본으로 깔고 있다. 스프링 빈들이 조건만 맞으면 자동으로 등록되는 것이다.

설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누는 게 이상적이지만 개발자 입장에서는 @Component만 넣어주면 끝나는 일을 하나하나 설정해주는 게 번거롭다. 관리할 빈이 많아서 설정 정보가 커지면 설정 정보를 관리하는 것 자체도 부담이 된다.

게다가 자동 빈 등록을 사용해도 OCP, DIP를 충분히 지킬 수 있다.

수동 빈 등록을 사용하는 상황

기술 지원 로직을 사용할 때

애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나뉜다.

업무 로직 빈

웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리파지토리 등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.

기술 지원 빈

기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. DB 연결이나 공통 로그 처리처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술이다.

---

업무 로직은 숫자도 많고 한번 개발하면 컨트롤러, 서비스, 리파지토리처럼 유사한 패턴이 있다. 이런 경우 자동 기능을 적극 활용한다. 문제가 발생해도 어떤 곳에서 발생한 건지 명확하게 파악하기 쉽다.

기술 지원 로직은 업무 로직에 비해 수가 적고 애플리케이션 전반에 걸쳐 광범위한 영향을 미친다. 로직이 잘 적용되고 있는지 파악조차 어렵다. 그래서 이런 기술 지원 로직은 가급적 수동 빈 등록으로 명확하게 드러내는 것이 좋다. 컴포넌트 스캔을 하는 설정 정보는 보통 루트에 있으므로 이 파일 하나만 보고 파악하기가 좋다.

애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지 보수하기 좋다.

비즈니스 로직에서 다형성을 활용할 때

이전에 조회한 빈을 모두 가져와야할 경우의 예제를 생각해보자. 여기 어떤 빈이 주입될지, 각 빈의 이름은 무엇일지 코드만 보고 한번에 알기 어렵다. 만약 자동 등록을 하고 있다면 파악하기 위해 여러 코드를 찾아봐야 한다.

이런 경우 수동 빈으로 등록하는 것이 좋다. 혹은 자동으로 해야한다면 특정 패키지에 같이 묶어두자. 딱 보고 한 번에 이해가 되어야 한다.

@Configuration
public class DiscountPolicyConfig {

  @Bean
  public DiscountPolicy rateDiscountPolicy() {
    return new RateDiscountPolicy();
  }

  @Bean
  public DiscountPolicy fixDiscountPolicy() {
    return new FixDiscountPolicy();
  }
}

이렇게 설정 정보만 봐도 한 눈에 빈의 이름이 무엇이고 어떤 빈이 주입될지 파악할 수 있어야 한다. 빈 자동 등록을 굳이 사용하고 싶다면 파악하기 좋게 DiscountPolicy의 구현 빈들만 따로 모아 특정 패키지에 모아두자.

참고로, 스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈은 수동 등록 범위가 아니다. 이 요소들은 스프링 자체를 잘 이해하고 스프링의 의도대로 사용하는 게 중요하다. 스프링 부트는 DataSource 같은 DB 연결용 기술 지원 로직까지 내부에서 자동으로 등록한다. 이런 기능은 매뉴얼을 잘 참고해서 스프링 부트가 의도한 대로 편리하게 사용하면 된다.

반면, 스프링 부트가 아니라 내가 직접 기술 지원 객체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 드러내는 것이 좋다.