Spring IoC (Inversion of Control)

leedong617·2024년 9월 13일

Spring IoC(Inversion of Control, 제어의 역전)는 Spring Framework의 핵심 개념으로, 애플리케이션에서 객체 간의 의존성을 직접 설정하는 대신, Spring 컨테이너가 대신 객체의 생명 주기를 관리하고 필요한 의존성을 주입해주는 설계 패턴임. 이를 통해 객체 간의 결합도를 낮추고, 애플리케이션의 유연성과 확장성을 크게 향상시킬 수 있음.

IoC는 일반적으로 의존성 주입(DI, Dependency Injection)을 통해 구현되며, 이를 통해 개발자는 객체를 직접 생성하거나 관리할 필요 없이 Spring이 이를 대신 처리하게 됨.

IoC(Inversion of Control)의 정의

IoC(Inversion of Control)는 객체의 제어권을 개발자가 아닌 프레임워크(즉, Spring 컨테이너)가 담당하는 것을 의미함. 이로 인해, 애플리케이션의 각 객체가 스스로 의존성을 관리하지 않고, Spring 컨테이너가 해당 객체의 생성, 초기화, 의존성 주입 등을 대신 처리함.

IoC의 일반적인 동작 흐름

개발자는 객체 간의 관계(의존성)를 설정함.
Spring 컨테이너는 이 설정을 바탕으로 객체를 생성하고, 객체가 필요로 하는 의존성을 주입함.
애플리케이션 실행 시, Spring 컨테이너가 필요한 객체를 미리 생성하고 의존성을 자동으로 관리함.

IoC 컨테이너

Spring IoC의 핵심은 Spring IoC 컨테이너임. IoC 컨테이너는 애플리케이션에서 사용할 빈(bean) 객체를 생성하고 관리하는 역할을 함. 빈이란 Spring 컨테이너에 의해 관리되는 객체를 의미함.

ApplicationContext

ApplicationContext는 Spring IoC 컨테이너의 핵심 인터페이스 중 하나로, 애플리케이션에서 사용할 빈의 생성, 관리, 의존성 주입 등을 담당함.
ApplicationContext는 애플리케이션 전반에서 빈을 관리하며, 다양한 설정 파일(XML, 자바 애너테이션, 자바 설정 클래스 등)을 지원함.

ApplicationContext context = new AnnotationConfigApplicationContext(AppConfig.class);
UserService userService = context.getBean(UserService.class);

BeanFactory

BeanFactory도 IoC 컨테이너의 기본 인터페이스이지만, 주로 ApplicationContext보다 기능이 적고, 단순한 용도로 사용됨. ApplicationContext는 BeanFactory를 확장한 인터페이스로, 더 많은 기능을 제공함.

빈(Bean) 정의 및 관리

Spring에서 빈(bean)은 IoC 컨테이너에 의해 관리되는 객체임. Spring은 빈 정의와 의존성 설정을 읽고, 컨테이너가 관리할 빈을 초기화하고 주입함. 빈을 정의하는 방법은 주로 세 가지 방식이 있음:

XML 기반 설정

전통적인 방법으로, XML 파일에서 빈과 의존성을 설정함.

<bean id="userService" class="com.example.UserService">
    <constructor-arg ref="userRepository"/>
</bean>

<bean id="userRepository" class="com.example.UserRepository"/>

어노테이션 기반 설정

자바 클래스와 어노테이션을 통해 빈을 정의하고 의존성을 주입함.
@Component, @Service, @Repository 등을 사용해 빈을 정의할 수 있음.

@Service
public class UserService {
    private final UserRepository userRepository;

    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

자바 설정 기반(자바 클래스)

@Configuration 클래스와 @Bean 어노테이션을 사용해 빈을 정의함.

@Configuration
public class AppConfig {

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

    @Bean
    public UserRepository userRepository() {
        return new UserRepository();
    }
}

의존성 주입(Dependency Injection, DI)

의존성 주입(DI)은 Spring IoC에서 객체의 의존성을 외부에서 주입하는 방식임. 즉, 객체가 스스로 의존성을 설정하지 않고, 외부에서 필요한 의존성을 설정해주는 패턴을 의미함. DI는 크게 세 가지 방식으로 구현됨.

생성자 주입(Constructor Injection)

생성자 주입은 가장 권장되는 방식으로, 객체가 생성될 때 필수적인 의존성을 주입하는 방식임.

모든 필수 의존성은 생성자를 통해 주입되며, 의존성을 final로 설정해 불변성을 보장할 수 있음.

@service
public class UserService {
    private final UserRepository userRepository;

    @Autowired
    public UserService (UserRepository userRepository) { // 의존성 주입
        this.userRepository = userRepository;
    }
}

클래스의 생성자가 하나이고, 그 생성자로 주입받을 객체가 빈으로 등록되어 있다면 @Autowired를 생략 할 수 있음.

수정자 주입(Setter Injection)

세터 주입은 객체 생성 후, 의존성을 세터 메소드를 통해 주입하는 방식임. 선택적인 의존성 주입에 적합하며, 필수 의존성을 강제할 수 없는 경우에 사용됨.

@service
public class UserService {
    private final UserRepository userRepository;

    @Autowired
    public setUserService (UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

Setter 메소드에 @Autowired 어노테이션을 붙이는 방법.

필드 주입(Field Injection)

필드 주입은 필드에 직접적으로 @Autowired 어노테이션을 붙여 의존성을 주입하는 방식임. Spring에서는 필드 주입이 권장되지 않음(테스트와 유지보수의 어려움 등).

@service
public class UserService {

	@Autowired 
    private final UserRepository userRepository;

}

Spring Framework에서 권장하는 방법은 생성자를 통한 주입임 아래는 그 이유임

1. 불변성 보장

불변성(Immutability)은 객체가 생성된 후 그 상태가 변경되지 않는 속성을 말함. 생성자 주입을 사용하면, 객체가 생성될 때 필요한 모든 의존성을 최초로 한 번만 설정할 수 있음. 한 번 생성된 객체는 의존성이 변경되지 않으므로 불변 객체가 됨.
이는 객체 상태의 일관성을 보장하며, 객체가 예측 가능한 방식으로 동작하게 함. 불변 객체는 스레드 안전성이 뛰어나며, 동시성 문제가 발생할 가능성이 줄어듦.

public class UserService {

    private final UserRepository userRepository;

    // 생성자 주입을 통해 의존성 주입
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // 의존성은 final로 선언되어 객체 생성 후 변경되지 않음
}

생성자 주입을 통해 의존성을 final로 선언하면, 불변 객체가 되어 외부에서 임의로 의존성을 변경할 수 없음

2. 필수 의존성 주입 보장

생성자 주입은 객체를 생성할 때 반드시 의존성을 주입하도록 강제함. 즉, 필수 의존성을 설정하지 않고 객체를 생성하는 것을 방지할 수 있음. 이는 런타임 오류를 줄이고, 잘못된 상태의 객체가 생성되는 것을 방지함.
반면, 세터 주입이나 필드 주입은 객체 생성 후에 의존성을 주입할 수 있어, 주입이 누락될 가능성이 있음. 이 경우 주입되지 않은 의존성을 사용하면 NullPointerException과 같은 오류가 발생할 수 있음.

// 생성자 주입을 통해 의존성을 강제
public class OrderService {

    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        if (paymentService == null) {
            throw new IllegalArgumentException("PaymentService cannot be null");
        }
        this.paymentService = paymentService;
    }

    // OrderService는 PaymentService가 반드시 필요함
}

위 예시에서는 필수 의존성인 PaymentService가 반드시 생성자에 주입되어야만 객체가 생성됨. 주입이 누락되면 컴파일 시점에서 경고를 받을 수 있음.

3. 테스트 용이성

세터 주입이나 필드 주입의 경우, 테스트 중에 별도의 주입 방식이 필요하거나, 리플렉션(reflection)을 사용해야 할 수도 있지만, 생성자 주입은 간단히 생성자 호출을 통해 의존성을 주입할 수 있음.
생성자 주입 덕분에 테스트 환경에서 의존성 주입이 매우 단순해짐. 이를 통해 테스트 코드를 더 직관적이고 읽기 쉽게 작성할 수 있음.

4. 순환 의존성 방지

순환 의존성(Circular Dependency)이란 두 개 이상의 클래스가 서로를 필요로 할 때 발생하는 문제임. 예를 들어, 클래스 A가 클래스 B를 의존하고, 클래스 B가 다시 클래스 A를 의존하는 경우 순환 의존성이 발생함.
생성자 주입을 사용하면 순환 의존성을 컴파일 시점에서 감지할 수 있음. 두 의존성이 서로 순환하고 있으면 객체 생성 시점에서 오류가 발생하여, 이를 빠르게 해결할 수 있음.
반면, 세터 주입과 필드 주입은 객체가 이미 생성된 상태에서 의존성을 주입하기 때문에 순환 의존성 문제를 감지하기 어려울 수 있음. 이로 인해 런타임 오류로 이어질 수 있음.

public class ClassA {
    private final ClassB classB;

    public ClassA(ClassB classB) {
        this.classB = classB;
    }
}

public class ClassB {
    private final ClassA classA;

    public ClassB(ClassA classA) {
        this.classA = classA;
    }
}

위 코드처럼 순환 의존성이 있을 경우, Spring은 컴파일 시점에서 오류를 발생시켜 개발자가 즉시 문제를 인식할 수 있음.

5. 의존성 변경의 안전성

세터 주입이나 필드 주입의 경우, 객체가 생성된 후에 의존성을 변경할 수 있으므로, 의도하지 않은 상태에서 의존성이 수정될 위험이 있음. 이는 객체의 상태 불안정성을 야기할 수 있음.
생성자 주입은 객체 생성 후 의존성을 변경할 수 없으므로, 의존성 변경으로 인한 위험이 사라짐. 이는 애플리케이션의 안정성과 일관성을 보장하는 데 중요한 역할을 함.

6. 필드 주입의 문제점 (권장되지 않는 이유)

필드 주입은 의존성을 직접 필드에 주입하는 방식으로, 코드가 간단해 보일 수 있지만 여러 문제를 야기할 수 있음.

의존성 숨김

필드 주입은 의존성을 외부에서 알 수 없게 만듦. 즉, 클래스가 어떤 의존성을 사용하는지 명확히 알기 어렵고, 객체의 책임이 명확하지 않음.

테스트 어려움

필드 주입은 객체 생성 시 주입되지 않기 때문에, 테스트에서 의존성을 설정하기 어려움. Mock 객체를 주입하려면 리플렉션을 사용해야 할 수 있음.

순환 의존성 감지 불가

필드 주입은 객체 생성 후 의존성을 주입하기 때문에 순환 의존성 문제를 즉시 감지하지 못하고, 런타임 시점에만 문제가 발생할 수 있음.

필드 주입은 구조가 불명확하고, 코드의 명확성을 떨어뜨리기 때문에 생성자 주입이 더 권장됨.

7. 리팩토링과 유지보수의 용이성

생성자 주입을 사용하면 객체의 의존성 관계가 명확해지므로, 코드 리팩토링과 유지보수가 쉬워짐. 의존성이 명시적으로 표현되기 때문에, 어떤 클래스가 어떤 의존성을 필요로 하는지 바로 확인할 수 있음.
이로 인해 애플리케이션이 커지더라도 각 클래스의 의존성 관리가 쉬워지고, 새로운 의존성을 추가하거나 기존 의존성을 변경할 때도 코드의 일관성을 유지할 수 있음.

Spring IoC의 장점

결합도 낮추기

IoC는 객체 간의 결합도를 낮추는 데 큰 역할을 함. 각 객체는 서로에 대해 구체적인 정보를 알 필요 없이, Spring 컨테이너가 객체 간의 의존성을 관리하기 때문에 유연한 설계가 가능해짐.

테스트 용이성

IoC 컨테이너는 애플리케이션에서 의존성을 관리하므로, 테스트할 때 의존성 대체(Mock 객체 주입 등)가 매우 용이함. 의존성을 외부에서 주입받기 때문에, 테스트할 때 가짜 객체(fake object)나 Mock 객체를 손쉽게 주입할 수 있음.

코드 재사용성 증가

Spring IoC는 객체 생성과 관리를 외부에서 담당하기 때문에, 개발자는 비즈니스 로직에 집중할 수 있고, 의존성 주입을 통해 객체 재사용성을 높일 수 있음.

코드 가독성 및 유지보수성 향상

Spring IoC를 사용하면 객체 간의 의존성이 명확하게 정의되기 때문에, 코드의 가독성이 높아지고, 유지보수성이 크게 향상됨. 개발자는 객체 간의 관계를 쉽게 파악할 수 있고, 의존성 변경에도 유연하게 대응할 수 있음.

Spring IoC의 동작 과정

Spring IoC의 동작 과정은 크게 빈 정의, 빈 등록, 의존성 주입, 빈 사용의 네 단계로 요약할 수 있음

1. 빈 정의(Bean Definition)

빈은 XML 파일, 자바 클래스, 혹은 어노테이션을 통해 정의됨.

2. 빈 등록(Bean Registration)

IoC 컨테이너는 빈 정의를 바탕으로 빈을 생성하고 등록함. 등록된 빈은 ApplicationContext에서 관리됨.

3. 의존성 주입(Dependency Injection)

빈이 생성된 후, 빈이 필요로 하는 의존성은 생성자나 세터 메소드를 통해 주입됨.

4. 빈 사용(Bean Usage)

애플리케이션에서 필요할 때, ApplicationContext로부터 빈을 가져와 사용함.

Spring IoC의 단점

초기 설정의 복잡성

Spring IoC는 다양한 기능을 제공하는 만큼, 초기 설정이 복잡할 수 있음. 특히 대규모 애플리케이션에서는 많은 빈을 정의하고 관리해야 하므로, 설정 파일이 복잡해질 수 있음. 그러나 Spring Boot는 이러한 설정의 복잡성을 크게 줄여줌.

객체 생성의 모호성

Spring IoC를 사용하면 객체의 생성 과정이 외부로 노출되지 않기 때문에, 객체가 언제 어떻게 생성되는지 모호해질 수 있음. 이는 코드 분석을 어렵게 만들고, 디버깅이 복잡해질 수 있음.

결론

Spring IoC는 애플리케이션의 유연성과 확장성을 크게 높여주는 핵심 개념으로, 객체 생성과 의존성 관리를 프레임워크에 위임하여 개발자는 객체 간의 관계나 의존성을 코드에서 직접 다루지 않아도 됨. 이를 통해 결합도를 낮추고, 테스트 가능성과 코드 재사용성을 높이며, 유지보수성을 크게 향상시킬 수 있음. Spring IoC는 대규모 애플리케이션을 개발할 때 특히 강력한 도구로, 이를 활용하면 효율적인 설계와 관리가 가능함.

leedong617

웹개발자 취업 준비생

이전 포스트

Spring

다음 포스트