#9 의존관계 자동주입에서 생기는 문제 (+Lombok 소개)

해당 글은 김영한님의 인프런 강의를 공부하고 정리한 내용입니다.

 

막상 개발을 해보면 알겠지만, 최근에 사용하는 방식은 Side-effect를 없애기 위해 가능한 객체들을 불변(final)으로 만들게 된다. 그런데 매번 생성자를 만들고, 주입 받은 값을 대입하는 코드를 만들고.. 이를 자동화해주는 도구는 없을까?

 

#Lombok 소개 (나중에 따로 다룰 예정)

그게 바로 Lombok 라이브러리이다. 어노테이션 기반으로 Getter, Setter등을 자동생성 해준다고 들어본 적 있을 것이다. 지금은 하나하나 코드를 작성하지만 실제 프로젝트에서는 Lombok을 대부분 사용하기에, 조금 앞당겨서 미리 소개를 하려고 한다.

// 기존 코드
@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    // @Autowired 생성자가 단 하나인 경우, 생략해도 똑같이 동작한다.
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

위의 코드를 Lombok 라이브러리를 사용해서 간단하게 만들어보자. 여기에서는 @RequiredArgsConstructor를 이용하여 final이 붙은 필드만 모아서 생성자를 자동으로 만들어 보겠다.

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

참고로 IntelliJ안에 Annotation Processing 기능을 활성화 시키면 Lombok이 적용된 코드를 자동완성으로 사용할 수 있다.

 

스프링부트에서 Lombok을 적용하려면 build.gradle에 다음과 같이 추가해주면 된다.

plugins {
    id 'org.springframework.boot' version '2.3.2.RELEASE'
    id 'io.spring.dependency-management' version '1.0.9.RELEASE'
    id 'java'
}
group = 'hello'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'
//** lombok 설정 추가 시작
configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}
//lombok 설정 추가 끝 **

repositories {
    mavenCentral()
}
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    
    //** lombok 라이브러리 추가 시작
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'
    //lombok 라이브러리 추가 끝 **
    
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
}
test {
    useJUnitPlatform()
}

 

---

# 다시 본론, 조회 빈이 2개 이상(상속 관계)일 때

@Autowired를 이용해서 의존관계를 자동등록 할 때, 해당하는 빈이 없거나 빈 컴포넌트의 이름이 중복되는 경우는 어떻게 처리되는지 알아보았다. 하지만 중복이 아니라 상속관계인 경우에는 어떻게 처리할까?

• Autowried는 빈의 타입(Type)을 조회하여 의존관계를 등록한다.
• 즉 ac.getBean(DiscountPolicy.class)를 이용해서 해당 빈을 구현체로 등록하는 것처럼 동작한다.
• 그렇다면 DiscountPolicy의 하위타입인 FixDiscount 와 RateDiscount는 어떻게 구분할까?

@Autowired
private DiscountPolicy discountPolicy

// 둘 중 무엇을 의존관계로 등록해야하는지 스프링 프레임워크가 알 수 있을까?
@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

정답은 '자동으로 등록하지 못한다'이다. NoUniqueBeanDefinitionException이 발생하게 되는데, 오류 내용을 읽어보면 같은 타입인 빈이 2개가 있어 매칭이 불가능하다고 친절하게 알려준다.

NoUniqueBeanDefinitionException: No qualifying bean of type 
'hello.core.discount.DiscountPolicy' available: expected single matching bean 
but found 2: fixDiscountPolicy,rateDiscountPolicy

물론 DiscountPolicy 인터페이스 대신에 하위타입의 구현체를 직접 스프링 빈으로 등록하는 방법도 있으나, 이는 DIP를 위배하고 앞에서 배웠던 다형성을 지키지 못하는 코드가 되버린다. 또는 스프링 빈을 수동(@Bean)으로 직접 지정하여 해결할 수 있겠지만, 의존 관계 자동 주입에서도 해결하는 여러 방법들이 있다.

 

---

 # 해결책

@Autowired [filed-name]

[ @Autowired ] 는 타입 매칭을 시도할 때 동일한 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 매칭한다. 즉 단순히 변수 이름을 등록하고자하는 빈이름으로 변경하기만 해도 해당 이름의 빈을 찾아서 등록해준다.

* 앞에서 컴포넌트 자동스캔으로 등록한 빈 이름이 클래스명과 동일한 이유. (MyClass -> myClass 로 생성) 

// 에러. 해당 타입의 빈이 여러개임
@Autowired
private DiscountPolicy discountPolicy

// 해당 타입의 빈이 여러개지만, rateDiscountPolicy 라는 이름을 가진 빈이 있으므로 자동등록.
@Autowired
private DiscountPolicy rateDiscountPolicy

단, 타입 매칭이 실패했을 때만(=빈이 여러개일 때) 필드, 파라메타 이름을 추가적으로 사용한다는 것을 잊지말자.

 

---

@Qualifier 끼리 매칭하기

[ @Qualifier ] 는 추가적인 구분자를 붙여주는 방법이다. 마치 빈 이름을 등록해주는 것처럼 사용하지만, 자동 등록을 하기위해 구분자를 제공하는 것일 뿐 실제 빈 이름이 변경되는 것은 아니다.

만약 해당 이름의 Qualifier가 없는 경우, 같은 이름의 스프링 빈을 찾아서 연결해주긴 하지만 보통은 그렇게 사용하는 경우는 없다. Qualifier의 이름을 지정해주자.

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

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

// 컴포넌트 스캔이 아니라 수동으로 등록하는 경우
@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy() {
    return new ...
}

@Autowired // 파라메타 앞에 @Qualifier를 추가로 적어준다.
public OrderServiceImpl(MemberRepository memberRepository,
@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy){
        this.memberRepository=memberRepository;
        this.discountPolicy=discountPolicy;
}

 

---

@Primary 사용하기

이는 이름을 지정해주는 게 아니라, 우선순위를 정하는 방법이다. @Autowired에서 여러 빈이 매칭되면, @Primary 빈이 우선권을 가지게 된다. 위의 @Qualifier의 경우 모든 코드에 직접 구분자를 달아줘야해서 번거롭지만, @Primary를 사용하면 별다른 추가작업없이 원하는 의존관계를 설정할 수 있다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

 

---

@ Primary와 Qualifier의 활용팁

코드에서 자주 사용하는 메인 DB 커넥션을 획득하는 스프링빈과, 특별한 기능을 사용하려고 가끔식 사용하는 서브 DB의 커넥션을 획득하는 스프링 빈이 각각 있다고 생각해보자. 메인 DB빈은 @Primary를 적용해서 편리하게 사용하고 가끔 사용하는 서브DB는 @Qualifier를 지정하여 명시적으로 획득하는 방식이 코드를 깔끔하게 유지하면서, 개발자의 실수를 미연에 방지해준다. (물론 이는 사용하기 나름이다. 필요에 따라 전부 @Qualifier로 해도 전혀 문제가 없다.)

 

* 참고로 다른 우선순위와 마찬가지로, 동시에 사용했을 경우 기본값처럼 동작하는 @Primary보다 직접 지정해주는 @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;
}

다만 Qualifier 처럼 특별한 목적이 있는게 아니라면, 보통은 새로 어노테이션을 만들지 말고 스프링에서 제공하는 기본 어노테이션을 사용하는게 깔끔하고 유지보수에 좋다.

 

---

# 조회한 빈이 모두 필요할 때 (List, Map)

앞의 예제에서 할인정책을 클라이언트가 존재하는 할인정책중에 하나를 선택할 수 있다고 생각해보자. 스프링을 사용하면 이와 같은 전략 패턴을 자바의 Map과 List로 매우 간단하게 구현할 수 있다.

class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
		
        // Map 또는 List로 모든 DiscountPolicy 빈을 주입 받는다.
        // 보통 둘 중 하나만 사용하지만, 예제로 보여줄려고 Map, List로 각각 의존관계를 주입받았다.
        @Autowired
        public DiscountService(Map<String, DiscountPolicy> policyMap,
                               List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
        }
		
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            return discountPolicy.discount(member, price);
        }
}

@Autowired를 사용해서 의존관계를 Map이나 List로 받게되면 해당하는 모든 Bean들이 들어가게 된다. 이를 이용하면 아래와 같은 전략패턴(존재하는 할인정책중에 하나를 선택)을 구현할 수 있다. 이를 스프링 없이 구현해보면 알겠지만, 작성해야할 코드가 정말 많은데 스프링의 자동 의존관계 주입을 활용하면 정말 간단하게 구현할 수 있다.

public class AllBeanTest {
    @Test
    void findAllBean() {
        // 스프링 빈 생성. 아직 Map과 List는 비어있다. (의존성 주입 X)
        ApplicationContext ac = new
                AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        
        // 자동 의존관계 생성자 주입을 이용한다.
        // DiscountService에 있는 Map과 List에 DiscountPolicy들이 채워져 있다. (fix, rate)
        DiscountService discountService = ac.getBean(DiscountService.class);
        
        // discount() 메서드는 "fixDiscountPolicy" 가 넘어오면 map에서 해당 이름의 빈을 찾아 실행한다.
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000,"fixDiscountPolicy");
        
        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }
}

 

---

# 자동과 수동, 올바른 선택의 기준

스프링 프레임워크는 업데이트를 계속하며 많은 부분을 자동으로 처리할 수 있게 만들어주고 있다. 그렇다고 전부 자동으로 사용하게되면 프로젝트의 구조를 파악하기 힘들고 문제가 생겼을 때 찾기 힘들 것 같은데, 어디까지 자동으로 사용해야 할까?

 

결론부터 이야기하면, 제공하는 편리한 자동 기능을 기본으로 사용하는 것을 권장한다. 스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 앱 로직을 자동스캔 할 수 있도록 지원한다. 거기에 더해 2014년 스프링 부트의 등장으로 컴포넌트 스캔이 설정이 아닌 기본 동작으로 바뀌게 되었고, 스프링 부트의 다양한 빈들도 조건이 맞으면 자동으로 등록하도록 설계되어져있다.

 

물론 설정 정보(AppConfig)를 기반으로 실행부분과 구성부분을 명확하게 나누는 것이 이상적이긴 하다. 하지만 개발자 입장에서 @Component 만 적어주면 끝나는 일을 하나하나 지정해주는건 상당히 번거롭기도 하고, 관리할 빈이 많아지면 설정 정보를 관리하는 것 자체가 부담이 된다. 결정적으로 자동 빈을 사용해도 OCP, DIP를 지킬 수 있다.

 

---

@ 그럼 수동 빈은 언제 쓰나요?

보통 어플리케이션은 업무 로직(비즈니스)와 기술 지원 로직으로 나눌 수 있다.

• 업무로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직을 가진 서비스, 데이터 계층의 리포지토리 등이 모두 업무 로직에 해당된다. 보통 비즈니스 요구사항을 개발할 때 변경된다.
• 기술지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결, 공통 로그처리 처럼 비즈니스 요구사항 그 자체라기 보다는, 업무 로직을 지원하기 위한 하부 기술들이다.

업무 로직 빈을 만들 때에는 자동기능을 적극 사용하자. 애초에 관리해야할 코드가 너무 많아 그런 것도 있지만 컨트롤러-서비스-리포지토리처럼 어느정도 유사한 패턴이 존재한다. 이런 경우 문제가 생기더라도 왜 문제가 발생했는지 명확하게 파악하기 쉽다. (어느 서비스에서 문제가 났는지 찾기 쉽다.)

 

반대로 기술지원 로직은 업무 로직과 비교해서 수가 적고, 어플리케이션 전반에 걸쳐 광범위하게 영향을 끼치게 된다. 그래서 문제가 발생하더라도 정확하게 어디가 문제인지 알기 어렵고, 적용이 잘되있는지 조차 파악하기 까다롭다. 이러한 로직들은 가급적 수동 빈 등록을 활용하여 사용하고 있음을 명확하게 들어내는 것이 좋다.

 

 

---

@ 비즈니스 로직에서 수동 빈을 통한 다형성의 활용

위에서 사용했던 전략패턴을 생각해보자. 아래 코드를 한눈에 보고 어떠한 동작을 하는지 알수 있을까?

class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
		
        // Map 또는 List로 모든 DiscountPolicy 빈을 주입 받는다.
        // 보통 둘 중 하나만 사용하지만, 예제로 보여줄려고 Map, List로 각각 의존관계를 주입받았다.
        @Autowired
        public DiscountService(Map<String, DiscountPolicy> policyMap,
                               List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
        }
		
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            return discountPolicy.discount(member, price);
        }
}

이런 경우 해당 부분을 아래와 같이 수동으로 등록하여 한눈에 의미를 알 수 있도록 해주는 것도 나쁘지 않다. 또한 자동으로 사용하더라도 최소한 '특정 패키지'에 하나로 묶어서 의미를 쉽게 찾을 수 있도록 만들어주자.

@Configuration
public class DiscountPolicyConfig {

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

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

 

---

@ 단, 스프링과 부트가 기본적으로 자동 등록하는 빈은 예외이다.

스프링부트의 경우 DataSource 같은 DB연결에 사용되는 기술지원 로직까지 자동으로 등록하는데, 이런 부분은 메뉴얼을 잘 참고해서 스프링부트가 의도한 대로 편리하게 사용하면 된다.

 

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