[Spring] 고급 어노테이션 정리: @Conditional, @Import 완벽 가이드

🚦 Spring 고급 어노테이션 정리: @Conditional, @Import 완벽 가이드 (예시 포함)

Spring은 프로젝트의 확장성과 유연성을 높이기 위한 다양한 고급 어노테이션을 제공합니다. 그 중 특히, 상황에 따라 빈(Bean)을 등록할지 결정하는 @Conditional, 외부 설정 클래스나 빈을 추가로 가져올 때 사용하는 **@Import**는 매우 유용한 기능입니다.

이 글에서는 실제 코드 예시를 통해 두 어노테이션을 확실히 정리하겠습니다.

---

✅ @Conditional 어노테이션 이해하기

@Conditional은 특정 조건이 충족될 때만 빈을 등록하는 데 사용하는 어노테이션입니다. 주로 환경별로 빈을 다르게 등록할 때 매우 유용합니다.

 

핵심 요소:

• Condition 인터페이스: 조건을 정의하는 로직을 담는 인터페이스입니다. matches() 메서드를 구현해야 합니다.
• matches(ConditionContext context, AnnotatedTypeMetadata metadata) 메서드:
  • 이 메서드가 true를 반환하면 해당 @Conditional이 붙은 대상(클래스 또는 @Bean 메서드)이 활성화됩니다.
  • ConditionContext: 현재 애플리케이션의 환경(Environment), 빈 팩토리(BeanFactory), 클래스 로더(ClassLoader) 등에 접근할 수 있는 컨텍스트 정보를 제공합니다.
  • AnnotatedTypeMetadata: @Conditional이 적용된 클래스나 메서드의 어노테이션 메타데이터에 접근할 수 있게 해줍니다.

📌 예제 코드로 알아보기

Case 1: 항상 참인 조건 (TrueCondition)

// 항상 true를 반환하는 Condition 구현체
class TrueCondition implements Condition {
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        System.out.println("Checking TrueCondition: Always true");
        return true;
    }
}

// Engine 컴포넌트는 TrueCondition을 사용하므로 항상 빈으로 등록됩니다.
@Component
@Conditional(TrueCondition.class)
class Engine {
    // ... (Engine 클래스 내용)
}

• 설명: TrueCondition은 matches() 메서드에서 항상 true를 반환합니다. 따라서 @Conditional(TrueCondition.class)가 붙은 Engine 클래스는 어떤 환경에서든 항상 스프링 빈으로 등록됩니다.

Case 2: 환경 속성 기반 조건 (OsCondition)

Java

 

// 시스템 환경 속성 'mode'가 'dev'일 때만 true를 반환하는 Condition 구현체
class OsCondition implements Condition {
    public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
        Environment env = context.getEnvironment();
        String mode = env.getProperty("mode");
        System.out.println("Checking OsCondition for mode: " + mode);
        // 'mode' 속성이 'dev'와 일치하는지 확인
        return "dev".equals(mode);
    }
}

// Door 컴포넌트는 OsCondition을 사용하므로 'mode=dev'일 때만 빈으로 등록됩니다.
@Component
@Conditional(OsCondition.class)
class Door {
    // ... (Door 클래스 내용)
}

• 설명: OsCondition은 ConditionContext를 통해 Environment 객체를 얻어와 mode라는 환경 속성 값을 확인합니다. 만약 mode 속성 값이 "dev"라면 true를 반환하고, 그렇지 않으면 false를 반환합니다.
• 결과: Door 클래스는 애플리케이션 실행 시 -Dmode=dev 와 같은 JVM 옵션이나, 환경 변수, application.properties 파일 등을 통해 mode 속성이 "dev"로 설정된 경우에만 스프링 빈으로 등록됩니다. 다른 값(prod 등)이거나 설정되지 않았다면 Door 빈은 생성되지 않습니다.
• 활용: 이처럼 @Conditional을 사용하면 개발 환경, 운영 환경 등 특정 환경에 맞는 빈을 선택적으로 등록하거나, 특정 라이브러리 존재 여부에 따라 빈 등록을 결정하는 등 매우 유연한 설정이 가능해집니다. (예: 특정 OS에서만 동작하는 빈, Feature Toggle 등)

 

* JVM 옵션 변경

 

---

 

✅ @Import 어노테이션 이해하기

@Import 어노테이션은 하나의 설정 클래스에서 다른 설정 클래스나 빈을 불러올 때 사용합니다. 특히 조건에 따라 동적으로 추가 설정을 가져올 때 유용합니다.

주요 사용법:

1. 다른 @Configuration 클래스 직접 임포트: 가장 기본적인 방법입니다.
2. ImportSelector 구현체 임포트: 동적으로 임포트할 설정 클래스를 선택해야 할 때 사용합니다.
3. ImportBeanDefinitionRegistrar 구현체 임포트: 프로그래밍 방식으로 빈 정의를 직접 등록해야 할 때 사용합니다. (고급 기능)
4. (추가) 일반 클래스 임포트: @Component 등이 붙지 않은 일반 클래스를 지정하면, 해당 클래스가 빈으로 등록됩니다.

📌 예제 코드로 알아보기

사용법 1: 다른 @Configuration 클래스 직접 임포트

가장 간단한 방법은 @Import 어노테이션에 임포트하고 싶은 설정 클래스들을 직접 명시하는 것입니다.

// 예시: MainConfig에 직접 Config1과 Config2를 임포트하는 경우
@Configuration
@Import({Config1.class, Config2.class}) // Config1과 Config2를 모두 가져옴
class MainConfig {
    @Bean Car car() { return new Car(); }
}

class Config1 { @Bean Car sportsCar() { return new SportsCar(); }}
class Config2 { @Bean Car sportsCar() { return new SportsCar2(); }}

• 동작 방식: 위와 같이 MainConfig에 @Import({Config1.class, Config2.class})를 사용하면, Spring은 MainConfig를 로드할 때 Config1과 Config2에 정의된 빈들도 함께 로드합니다.
• 주의점: 이 방식은 지정된 모든 설정을 무조건 가져옵니다. 만약 위 예시처럼 Config1과 Config2 모두 "sportsCar"라는 이름의 빈을 정의하고 있다면 어떻게 될까요? Spring은 동일한 이름의 빈이 여러 개 정의된 것을 감지하고, 어떤 빈을 사용해야 할지 결정할 수 없어 애플리케이션 시작 시점에 NoUniqueBeanDefinitionException 같은 오류를 발생시킬 가능성이 높습니다. (물론 @Primary 어노테이션 등으로 우선순위를 지정할 수는 있지만, 의도하지 않은 충돌이 발생하기 쉽습니다.)
• 적합한 경우: 임포트하려는 설정들이 서로 다른 이름의 빈들을 정의하고 있거나, 명확한 의도를 가지고 빈 정의를 오버라이딩하려는 경우에 적합합니다. 하지만 조건에 따라 특정 설정만 선택적으로 로드하고 싶다면 이 방식은 적합하지 않습니다. 이때 ImportSelector가 필요합니다.

---

사용법 2: ImportSelector로 동적 선택하기

조건에 따라 임포트할 설정을 동적으로 결정해야 할 때 ImportSelector 인터페이스를 사용합니다. selectImports() 메서드에서 로드할 설정 클래스의 이름 배열을 반환하여 이 문제를 해결할 수 있습니다.

예제 코드 다시 살펴보기 (ImportSelector 활용)

// 설정 클래스 1: SportsCar 빈 정의
class Config1 { @Bean Car sportsCar() { return new SportsCar(); }}
// 설정 클래스 2: SportsCar2 빈 정의
class Config2 { @Bean Car sportsCar() { return new SportsCar2(); }}

// ImportSelector 구현체: @EnableMyAutoConfiguration의 value 속성 값에 따라 Config1 또는 Config2를 선택
class MyImportSelector implements ImportSelector {
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        AnnotationAttributes attr = AnnotationAttributes.fromMap(
                importingClassMetadata.getAnnotationAttributes(EnableMyAutoConfiguration.class.getName()));
        String mode = attr.getString("value");
        System.out.println("MyImportSelector mode: " + mode);
        if ("test".equals(mode)) {
            return new String[] {Config1.class.getName()};
        } else {
            return new String[] {Config2.class.getName()};
        }
    }
}

// 커스텀 어노테이션: MyImportSelector를 임포트하도록 설정
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Import(MyImportSelector.class)
@interface EnableMyAutoConfiguration {
    String value() default "";
}

// 메인 설정 클래스: @EnableMyAutoConfiguration 사용
@EnableMyAutoConfiguration("test2")
class MainConfig {
    @Bean Car car() { return new Car(); }
}

// ... (Main 클래스 실행 부분은 동일) ...

• 동작 설명: (이전 설명과 동일) MainConfig의 @EnableMyAutoConfiguration("test2") 때문에 MyImportSelector가 동작하고, value 값 "test2"를 읽어 Config2를 임포트합니다. 결과적으로 "sportsCar" 빈은 SportsCar2 타입이 됩니다.

왜 @EnableMyAutoConfiguration 같은 커스텀 어노테이션을 사용할까요?

여기서 한 가지 의문이 생길 수 있습니다. "굳이 @EnableMyAutoConfiguration 어노테이션을 만들 필요 없이, MainConfig에 직접 @Import(MyImportSelector.class)를 사용하면 안 되나요?"

 

답변: 기술적으로는 가능하지만, @EnableMyAutoConfiguration 같은 커스텀 어노테이션을 사용하는 데에는 몇 가지 중요한 이유가 있습니다.

1. 추상화 및 가독성 향상: @EnableMyAutoConfiguration("test2")는 "특정 모드('test2')에 맞는 자동 설정을 활성화한다"는 의도를 명확하게 드러냅니다. 반면 @Import(MyImportSelector.class)는 단순히 '어떤 Selector를 사용한다'는 구현 방식을 보여줄 뿐입니다. 사용자는 MyImportSelector의 내부 동작을 몰라도 @EnableMyAutoConfiguration만 보고 어떤 기능이 활성화되는지 쉽게 이해할 수 있습니다. 이는 Spring Boot의 수많은 @Enable... 어노테이션들이 따르는 방식이기도 합니다.
2. 파라미터 전달 용이성: MyImportSelector는 "mode" 값("test" 또는 "test2")에 따라 다른 설정을 임포트해야 합니다. @EnableMyAutoConfiguration 어노테이션에 value() 속성을 정의함으로써, 사용하는 쪽(MainConfig)에서 @EnableMyAutoConfiguration("test2")처럼 명확하고 간결하게 파라미터를 전달할 수 있습니다. 만약 @Import(MyImportSelector.class)를 직접 사용한다면, 이 "mode" 값을 MyImportSelector에 전달할 다른 방법을 찾아야 합니다 (예: 별도의 어노테이션을 추가로 붙이거나, 환경 변수를 통하는 등). 커스텀 어노테이션의 속성을 사용하는 것이 훨씬 직관적이고 깔끔합니다.
3. 재사용성 및 캡슐화: @EnableMyAutoConfiguration은 MyImportSelector라는 구체적인 구현을 사용자로부터 숨깁니다(캡슐화). 나중에 선택 로직이 바뀌어 MyImportSelector2를 사용해야 하더라도, @EnableMyAutoConfiguration의 내부 @Import 대상만 변경하면 사용자는 기존의 @EnableMyAutoConfiguration("test2") 코드를 수정할 필요가 없습니다. 또한, 이 @Enable... 어노테이션은 다른 여러 설정 클래스에서 재사용될 수 있습니다.
4. 관례 준수: Spring 커뮤니티에서는 특정 기능이나 설정을 활성화할 때 @Enable... 형태의 어노테이션을 사용하는 것이 일반적인 관례입니다. 이 관례를 따르면 다른 개발자들이 코드를 이해하기 쉬워집니다.

결론적으로, @EnableMyAutoConfiguration과 같은 커스텀 어노테이션은 ImportSelector를 사용하는 데 필수는 아니지만, 코드의 가독성, 추상화 수준, 재사용성, 파라미터 전달의 편의성을 크게 높여주기 때문에 적극 권장되는 방식입니다. 구현 세부사항을 숨기고 명확한 의도를 드러내는 좋은 설계 패턴입니다.

 

🎯 종합 정리: 왜 필요하고 언제 사용할까요?

기능목적예시

@Conditional	조건부 빈 등록	환경(개발, 운영, 테스트)에 따라 다른 빈 등록
@Import	외부 설정 클래스 가져오기	환경에 따라 설정 파일이나 빈 등록 변경

@Conditional과 @Import는 Spring에서 제공하는 가장 강력한 어노테이션 중 하나로, 복잡한 애플리케이션 환경에서 유연하고 관리가 쉬운 빈 등록 방식을 제공합니다.
이를 잘 이해하고 활용하면 코드 품질과 유지보수성을 크게 높일 수 있습니다.