[Spring] 의존성 주입 시 @Autowired보다 생성자 주입을 권장하는 이유

🌏 의존성 주입 방법

1. 생성자 주입(Constructor Injection)
2. 필드 주입(Field Injection)
3. 수정자 주입(Setter Injection)

1️⃣ 생성자 주입(Constructor Injection)

생성자 주입 방법은 생성자를 통해 의존 관계를 주입한다.

생성자 주입은 생성자의 호출 시점에 1회 호출 되는 것이 보장되기 때문에 주입받은 객체가 변하지 않거나, 반드시 객체의 주입이 필요한 경우에 강제하기 위해 사용할 수 있다.

@Service
public class ProductService {
    // final을 붙일 수 있음
    private final ProductRepository productRepository;

    @Autowired	// 생략 가능
    public ProductRepository(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }
}

Spring 프레임워크에서는 생성자 주입을 적극 지원해 생성자가 1개만 있을 경우에 @Autowired를 생략해도 주입이 가능하도록 편의성을 제공하고 있다.

 

보너스 이득은 final 키워드를 사용할 수 있다. 생성자 주입 시, 의존성 주입이 클래스 인스턴스화 중에 시작되므로 final 선언을 할 수 있다. 반면에, final로 선언된 레퍼런스 타입 변수는 반드시 선언과 함께 초기화가 되어야 하므로 필드 주입 방식이나 수정자 주입 시 의존관계 주입을 받을 필드에 final을 선언할 수 없다.

 

2️⃣ 수정자 주입(Setter Injection)

수정자 주입 방법은 필드 값을 변경하는 Setter 메서드를 사용하여 의존성을 주입한다.

Setter 주입은 만들어진 객체를 통해 여러번 호출이 가능하므로 생성자 주입과 다르게 1회 호출을 보장하지 못한다.

주입받는 객체가 변경될 가능성이 있는 경우에 사용한다. (실제로 변경이 필요한 경우는 극히 드물다.)

@Service
public class ProductService {
    private ProductRepository productRepository;

    @Autowired
    public setProductRepository(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }
}

수정자 주입 방식은 @Autowired로 주입할 대상이 없는 경우 오류가 발생한다.

주입할 대상이 없어도 동작하도록 하려면 @Autowired(required = false)를 통해 설정할 수 있다.

 

3️⃣ 필드 주입(Field Injection)

필드 주입 방법은 필드에 직접 의존성을 부여하는 방법이다.

필드 주입 방법을 사용하면 코드가 간결해지지만 외부에서 접근이 불가능하다는 단점이 있다.

이는 테스트 코드의 중요성이 부각됨에 따라 필드의 객체를 수정할 수 없는 필드 주입은 거의 사용되지 않게 되었다.

(필드 주입은 의존성을 직접적으로 주입받기 때문에, 테스트 시 모의(mock) 객체를 쉽게 주입할 수 없어 테스트 작성이 어려워진다.)

 

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;
    
}

 

IntelliJ에서 필드 주입을 사용하면 Field injection is not recommended 이라는 경고 문구가 발생한다.

Spring Team recommends: “Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies”.

핵심은 생성자 주입 방식을 이용하라는 것인데, Spring Team에서 생성자 주입 방식을 권장하는 이유는 무엇일까?

 

🌏 왜 생성자 주입 방식이 권장되는데?

1. 순환 참조 방지
   
   • 애플리케이션 구동 시점에 순환 참조 에러 예방 가능
2. 테스트 용이
   • 단순 POJO를 이용한 테스트 코드 작성 가능
3. 스프링에 독립적인 코드 작성
4. 객체 불변성(Immutability) 확보
   • 실행 중에 객체가 변하는 것 방지
     → 오류 사전 방지
5. final 키워드 작성 및 Lombok과의 결합

 

🌱 순환 참조 방지

생성자 주입 사용 시 애플리케이션 구동 시점(객체의 생성 지점)에 순환 참조 에러를 예방할 수 있다.

 

예를들어 다음과 같이 필드 주입을 사용해 서로 호출하는 코드가 있다.

@Service
public class ProductService {

    @Autowired
    private ReviewService reviewService;

    @Override
    public List<Review> getReview(Long productId) {
        return reviewService.getReview(productId);
    }
}

 

ProductService가 이미 ReviewService에 의존하고 있는데, ReviewService도 ProductService에 의존하고 있다.

@Service
public class ReviewService {

    @Autowired
    private ProductService productService;

    @Override
    public List<Review> getProductReview(Long productId) {
        return productService.getReview(productId);
    }
}

위의 두 메서드는 서로를 계속 호출할 것이고, 메모리에 함수의 CallStack이 계속 쌓여 StackOverflow 에러가 발생하게 된다.

Caused by: java.lang.StackOverflowError: null
	at com.example.ProductService.getReview(ProductService.java:20) ~[main/:na]
	at com.example.ReviewService.getProductReview(ReviewService.java:14) ~[main/:na]
	at com.example.ProductService.getReview(ProductService.java:20) ~[main/:na]
	at com.example.ReviewService.getProductReview(ReviewService.java:14) ~[main/:na]

문제는 애플리케이션이 아무 오류가 경고 없이 구동돼 실제 코드가 호출되기 전까지 문제를 발견할 수 없다는 것이다.

 

그렇다면 생성자 주입을 사용한 경우에는 어떻게 될까?

@Service
public class ProductService {

    private final ReviewService reviewService;

    public ReviewService(ReviewService reviewService) {
        this.reviewService = reviewService;
    }
}

@Service
public class ReviewService {

    private final ProductService productService;

    public ProductService(ProductService productService) {
        this.productService = productService;
    }
}

애플리케이션 실행 시 애플리케이션 구동 시점(객체의 생성 지점)에 BeanCurrentlyInCreationException이 발생하여 오류를 사전에 알 수 있다.

Description:
The dependencies of some of the beans in the application context form a cycle:
┌─────┐
|  reviewService defined in file [~~~\ReviewService.class]
↑     ↓
|  productService defined in file [~~~\ProductService.class]
└─────┘

 

🤔 왜 이런 차이가 날까?

이러한 실행 결과의 차이는 생성자 주입은 Bean을 주입하는 순서가 필드 주입과 수정자 주입과는 다르기 때문이다.

 

@Autowired를 이용한 필드 주입을 했을 때 애플리케이션 구동 시점에 에러가 발생하지 않는 이유는 빈의 생성과 조립(@Autowired) 시점이 분리되어 있기 때문이다. 생성자 주입은 객체의 생성과 조립(의존관계 주입)이 동시에 실행돼 위와 같은 에러를 사전에 잡을 수 있다. 하지만 @Autowired는 모든 Bean 생성이 완료된 후에 조립(의존관계 주입)이 처리돼 호출이 되고 나서야 순환 이슈를 확인할 수 있는 것이다.

 

참고로 Spring Boot 2.6 부터는 기본적으로 Bean 간의 순환 참조가 금지되도록 변경되었다.

 

🌱 테스트에 용이

생성자 주입 사용 시 테스트 코드를 더 편리하게 작성할 수 있다.

테스트가 특정 프레임워크에 의존하는 것은 테스트 격리가 어렵고 유연성이 감소해 좋지 않다. 따라서 독립적으로 인스턴스화가 가능한 POJO(Plain Old Java Object)로 작성하는 것이 좋은데, 생성자 주입이 아닌 다른 주입으로 작성된 코드는 순수 자바 코드로 단위 테스트를 작성하는 것이 어렵다.

 

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;

    public void createProduct(String name) {
        productRepository.create(name);
    }
}

예를들어 위와 같은 필드 주입 방식 코드에 대해 순수 자바 테스트 코드를 작성하면 다음과 같이 작성할 수 있다.

public class ProductServiceTest {

    @Test
    public void createProductTest() {
        ProductService productService = new ProductService();
        productService.createProduct("상품1");
    }
}

위의 테스트 코드는 Spring 위에서 동작하지 않으므로 의존관계 주입이 되지 않는다. 따라서 postRepository가 null이 되어 findById 호출 시 NPE가 발생할 것이다. 이를 해결하기 위해 Setter 사용 시 변경 가능성을 열어두게 되는 단점을 갖게 된다.

반대로 테스트 코드에서 @Autowired를 사용하기 위해 스프링을 사용하면 단위 테스트가 아닐 뿐 아니라, 컴포넌트들을 등록하고 초기화하는 시간 때문에 테스트 비용이 증가하게 된다.

반면에 생성자 주입 사용 시 컴파일 시점에 객체를 주입받아 테스트 코드를 작성할 수 있으며, 주입하는 객체가 누락된 경우 컴파일 시점에 오류를 발견할 수 있다.

 

🌱 스프링에 독립적인 코드 작성

필드 주입 사용 시 @Autowired를 이용해야 하는데, 이것은 스프링이 제공하는 어노테이션이다.

그러므로 @Autowired를 사용하면 ProductService에 스프링 의존성이 생긴다.

import org.springframework.beans.factory.annotation.Autowired;
// 스프링 의존성이 ProductService에 import되어 코드로 박힘

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;

}

사용하는 프레임워크는 언제 바뀔지 모르고, 프레임워크는 비즈니스 로직을 작성하는 서비스 계층에서 알아야 할 대상이 아니다.

이는 필요한 자바 파일을 import해야하는 정적 언어인 자바의 한계이기도 하나, 가능한 스프링 없이 코드가 작성되면 더욱 유연한 코드 확보가 가능하다.

 

🌱 객체 불변성(Immutability) 확보

실제 개발을 하다보면 의존 관계의 변경이 필요한 상황은 거의없다. 하지만 수정자 주입이나 일반 메서드 주입을 이용하면 불필요하게 수정의 가능성을 열어두어 유지보수성을 떨어뜨린다. 그러므로 생성자 주입을 통해 변경이 가능성을 배제하고 불변성을 보장하는것이 좋다.

이는 오류를 사전에 방지할 수 있는 장점을 가지기도 한다.

 

@Service
public class ProductService {

    @Autowired
    private ProductRepository productRepository;
    
    public void someMethod() {
        productRepository = null;
        productRepository.call();
    }
}

필드 주입을 사용한 코드는 final 키워드를 사용할 수 없다. 따라서 런타임 시점에 변경될 수 있다.

위 코드에서는 null을 참조하도록 변경했기 때문에 NullPointerException이 발생할 것이다.

하지만 생성자 주입을 사용한다면 이와 같은 상황을 컴파일 시점에 방지할 수 있다.

@Service
public class ProductService {
    private final ProductRepository productRepository;

    public ProductRepository(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }
    
    public void someMethod() {
        // final 변수에 값을 재할당 할 수 없음
        productRepository = null;
    }
}

 

🌱 final 키워드 작성 및 Lombok과의 결합

생성자 주입을 사용하면 필드 객체에 final 키워드를 사용할 수 있으며 컴파일 시점에 누락된 의존성을 확인할 수 있다.

반면에 다른 주입 방법들은 객체의 생성(생성자 호출) 이후에 호출되므로 final 키워드를 사용할 수 없다.

 

final 키워드로 필드를 명시적으로 선언하면 코드의 가독성과 안정성을 높일 수 있으며, 다른 개발자들이 해당 필드가 불변이라는 것을 알 수 있어 코드의 이해를 도울 수 있는 장점이 있다.

또한 final 키워드를 붙이면 Lombok과 결합되어 코드를 간결하게 작성할 수 있다. Lombok에는 final 변수를 위한 생성자를 대신 생성해주는 @RequiredArgsConstructor가 있는데 생성자 주입 코드를 Lombok과 결합시키면 다음과 같이 간편하게 작성할 수 있다.

@Service
@RequiredArgsConstructor
public class ProductService {

    private final ProductRepository productRepository;
    private final UserRepository userRepository;

	public void createProduct(String name) {
        productRepository.create(name);
    }
}

 

 

 

 

 

[Spring] 다양한 의존성 주입 방법과 생성자 주입을 사용해야 하는 이유 - (2/2)

생성자 주입을 @Autowired를 사용하는 필드 주입보다 권장하는 하는 이유

의존 관계 주입(DI) - spring

Field injection is not recommended – Spring IOC - Marc Nuri

 

💉Dependency Injection in Spring: Constructor, Property, or Setter? Which one should I choose?

[Spring] 다양한 의존성 주입 방법과 생성자 주입을 사용해야 하는 이유 - (2/2)