[스프링 핵심 원리] 의존관계 자동 주입 (2)

스프링 핵심 원리의 강의 내용을 정리한 포스팅입니다.

---

조회 빈이 2개 이상일 때

문제점

@Autowired는 타입으로 빈을 조회하기 때문에, 실제로는 더 많은 기능을 제공하지만

ac.getBean(DiscountPolicy.class)와 유사하게 동작한다.

 

이때 DiscountPolicy의 하위 타입이 두 개 이상 존재할 경우 @Autowired는 한 개가 아닌 스프링 빈으로 등록된 하위 타입 클래스의 개수만큼 중복된 빈을 찾게 되고, NoUniqueBeanDefinitionException이 발생하게 된다.

 

그렇다고 해서 하위 타입으로 빈을 조회하는 것은 아래와 같이 두 가지 문제점이 존재한다.

1. DIP를 위배함과 더불어 코드의 유연성이 떨어진다.

2. 빈 이름은 다르지만 타입이 동일한 경우 문제를 해결할 수 없다.

 

해결책

크게 세 가지 방법이 있다.

1. @Autowired 필드 명 매칭

@Autowired는 우선적으로 타입 매칭을 시도하는데, 이 때 조회된 빈이 여러 개일 경우 필드/파라미터 이름으로 빈 이름을 매칭 시도하는 기능을 가지고 있다.

@Autowired
private DiscountPolicy discountPolicy

@Autowired
private DiscountPolicy rateDiscountPolicy

기존 코드의 필드 명은 discountPolicy이므로 필드 이름을 가지고 매칭을 시도해도 중복이 발생하지만, 필드 명을 구체(구현) 클래스의 이름인 rateDiscountPolicy로 수정하게 되면 의존 관계가 정상적으로 주입된다.

 

2. @Qualifier

@Qualifier는 추가 구분자를 붙여주는 방법으로, 빈 이름을 변경하는 것은 아니다.

사용 방법은 빈 등록 시 @Qualifier를 원하는 이름과 함께 추가하고, 의존 관계 주입 시 @Qualifier와 함께 등록했던 이름을 적어주면 된다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

만약 @Qualifier로 의존 관계를 주입할 때 @Qualifier("mainDiscountPolicy")를 못찾으면 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾는 작업을 수행한다.

(이 작업에서도 매칭되는 빈이 없다면 NoSuchBeanDefinitionException이 발생된다.)

 

하지만 @Qualifier는 @Qualifier를 찾는 용도로만 사용하는 것이 협업이나 유지보수의 관점에서 명확하고 좋다. 또한 수동으로 빈을 등록할 때도 @Qualifier를 동일하게 사용할 수 있다.

 

3. @Primary

해당 방법은 우선순위를 정하는 것으로, @Autowired 시 여러 빈이 매칭되는 상황에서 @Primary가 붙은 빈에게 우선권이 가도록 하는 것이다.

다음과 같이 작성함으로써 rateDiscountPolicy가 우선권을 가지도록 할 수 있다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

이 상태에서 아래 코드를 실행하면 정상적으로 동작하게 된다.

@Autowired
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

 

4. @Qualifier vs @Primary

	@Qualifier	@Primary
장점	@Primary에 비해 명시적이다.	별도의 구분자 없이 해당 애노테이션을 붙이는 것만으로 의존 관계를 주입 받을 수 있다.
단점	의존 관계를 주입받을 때 모든 코드에 해당 애노테이션을 붙여주어야 한다. 추가 구분자를 붙여준다고 해도 컴파일 시점에서 타입 체크를 할 수 없다.	-
우선 순위	@Qualifier는 수동으로 관리하는만큼 @Primary에 비해 구체적이고 좁은 범위를 가진다. 따라서 두 애노테이션 중에는 @Qualifier가 더 높은 우선 순위를 가진다.
활용 시점	코드에서 비교적 사용 빈도가 떨어지는 스프링 빈 → 명시적으로 드러냄으로써 코드를 깔끔하게 유지할 수 있음 (e.g., 서브 DB 커넥션)	코드에서 자주 사용하는 스프링 빈 → 편리하게 조회 가능 (e.g., 메인 DB 커넥션)

 

애노테이션 직접 만들기

앞서 @Qualifier의 단점으로 언급했듯이 @Qualifier("mainDiscountPolicy")의 "mainDiscountPolicy"은 문자이기 때문에 컴파일 시점에서 타입 체크를 할 수 없다.

따라서 다음과 같이 애노테이션을 직접 만들어 문제를 해결할 수 있다.

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
        ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {

}

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {} //스프링 빈으로 등록

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @MainDiscountPolicy DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
} //@MainDiscountPolicy 내부의 @Qualifier를 인식하여 의존 관계를 주입하는 방식

참고

애노테이션에는 상속이라는 개념이 없기 때문에 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다. @Qualifier 뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다.

@Autowired 또한 사용자가 재정의 할 수 있는데, 그렇다고 하여 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의 하는 것은 유지보수에 혼란을 줄 수 있으므로 가급적 필요한 상황에서만 사용하는 것이 좋다.

 

조회한 빈이 모두 필요할 때; List, Map

클라이언트가 할인 종류(fix, rate)를 선택하는 경우와 같이 해당 타입의 스프링 빈이 모두 필요한 경우가 있다.

이때는 ApplicationContext의 getBean을 이용해 스프링 빈을 List 또는 Map에 받아 이용할 수 있다.

 

자동, 수동의 올바른 실무 운영 기준

빈 등록과 의존 관계 주입에 있어 자동과 수동 방법은 각각 어느 상황에서 이용하는 것이 좋을까?

 

우선 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원함과 더불어 최근의 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 여러 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계했기 때문에 기본적으로는 자동 빈 등록을 이용하는 것이 권장된다.

자동 빈 등록을 이용해도 OCP, DIP를 지킬 수 있고, 스프링 빈을 등록할 때 @Component만 넣으면 끝나는 작업을 수동 빈 등록을 이용할 경우 @Configuration 설정 클래스에 @Bean을 추가하고, 객체를 생성하고, 주입할 대상을 일일이 적어주어야 하므로 그 과정이 번거롭고 규모가 커지면 설정정보를 관리하기가 힘들어진다.

 

업무 로직 빈(컨트롤러, 서비스, 리포지토리 등 비즈니스 요구사항의 영향을 받는 로직)의 경우 어느 정도의 유사한 패턴이 있기 때문에 자동 빈 등록을 이용해도 문제가 발생한 지점을 명확하게 파악하기가 쉽다. 또한 빈의 숫자가 많기 때문에 자동적으로 관리하는 방법이 적합하다.

 

기술 로직 빈(DB 연결이나 공통 로그 처리와 같이 기술적인 문제 등을 처리하거나 공통 관심사를 처리하는 로직)은 적용이 잘 되는지 여부조차도 확인하는 것이 어려운 경우가 많다. 또한 업무 로직 빈과 비교했을 때 그 수가 적고 일반적으로 애플리케이션 전반에 걸쳐 영향을 미치기 때문에 가급적 수동 빈 등록을 사용해서 명확하게 드러내는 것이 적합하다.

 

비즈니스 로직 중 다형성을 적극 활용하는 상황에서도 수동 빈 등록을 고민해 볼 수 있다.

DiscountService라는 빈이 의존 관계 자동 주입으로 Map<String, DiscountPolicy>에 주입받는다고 가정했을 때 해당 맵에 어떤 빈들이 주입될지, 각 빈들의 이름은 무엇일지 코드만 보고 한 번에 파악하기는 어렵다.

자동 등록을 사용하고 있기 때문에 파악을 위해서 여러 코드를 찾아봐야 하는데, 이러한 경우 수동 빈으로 등록하는 방법을 이용하거나 자동 빈을 등록할 경우 특정 패키지에 같이 묶어 단번에 파악하기 쉽도록 설계하는 것이 좋다.