[스프링 핵심 원리와 활용] 섹션6. 자동 구성 Auto Configuration(3), 외부설정과 프로필

[YONGHYNG]

자동 구성 이해1 - 스프링 부트의 동작

스프링 부트는 다음 경로에 있는 파일을 읽어서 스프링 부트 자동 구성으로 사용한다.
resources/META-INF/spring/
org.springframework.boot.autoconfigure.AutoConfiguration.imports
우리가 직접 만든 memory-v2 라이브러리와 스프링 부트가 제공하는 spring-boot-autoconfigure 라이브러
리의 다음 파일을 확인해보면 스프링 부트 자동 구성을 확인할 수 있다.

memory-v2 - org.springframework.boot.autoconfigure.AutoConfiguration.imports
memory.MemoryAutoConfig

spring-boot-autoconfigure - org.springframework.boot.autoconfigure.AutoConfiguration.imports

org.springframework.boot.autoconfigure.aop.AopAutoConfiguration
org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration
org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfig
uration
org.springframework.boot.autoconfigure.context.MessageSourceAutoConfiguration
org.springframework.boot.autoconfigure.context.PropertyPlaceholderAutoConfigurat
ion
org.springframework.boot.autoconfigure.dao.PersistenceExceptionTranslationAutoCo
nfiguration
org.springframework.boot.autoconfigure.data.jdbc.JdbcRepositoriesAutoConfigurati
on
org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration
org.springframework.boot.autoconfigure.data.mongo.MongoDataAutoConfiguration
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration
org.springframework.boot.autoconfigure.http.HttpMessageConvertersAutoConfigurati
on
org.springframework.boot.autoconfigure.jackson.JacksonAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConf
iguration
org.springframework.boot.autoconfigure.kafka.KafkaAutoConfiguration
org.springframework.boot.autoconfigure.thymeleaf.ThymeleafAutoConfiguration
org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
org.springframework.boot.autoconfigure.validation.ValidationAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.error.ErrorMvcAutoConfigurati
on
org.springframework.boot.autoconfigure.web.servlet.HttpEncodingAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.MultipartAutoConfiguration
org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration
...

• 스프링 부트 자동 구성이 동작하는 원리는 다음 순서로 확인할 수 있다.
• @SpringBootApplication -> @EnableAutoConfiguration -> @import(AutoConfigurationImportSelector.class)

AutoConfigApplication

@SpringBootApplication
public class AutoConfigApplication {
           public static void main(String[] args) {
                 SpringApplication.run(AutoConfigApplication.class, args);
     }
}
- run()에 보면 AutoConfigApplication.class를 넘겨주는데, 이 클래스를 설정 정보로 사용한다는 뜻이다. AutoConfigApplication에는 @SpringBootApplication 애노테이션이 있는데, 여기에 중요한 설정 정보가 들어있다.

**@SpringBootApplication**
```java
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes =
TypeExcludeFilter.class), @Filter(type = FilterType.CUSTOM, classes =
AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {...}

• 여기서 우리가 주목할 애노테이션은 @EnableAutoConfiguration이다. 이름 그대로 자동 구성을 활성화 하는 기능을 제공한다.

@EnableAutoConfiguration

@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {…}

• @import는 주로 스프링 설정 정보(@configuration)을 포함할 때 사용한다.
• 그런데 AutoConfigurationImportSelector를 열어보면 @configuration이 아니다.

자동 구성 이해2 - ImportSelector

• @import에 설정 정보를 추가하는 방법은 2가지가 있다.
  • 정적인 방법 : @import(클래스) 이것은 정적이다. 코드에 대상이 박혀 있다. 설정으로 사용할 대상을 동적으로 변경할 수 없다.
  • 동적인 방법 : @import(ImportSelector) 코드로 프로그래밍해서 설정으로 사용할 대상을 동적으로 선택할 수 있다.

정적인 방법

• 스프링에서 다른 설정 정보를 추가하고 싶으면 다음과 같이 @import 를 사용하면 된다.

@Configuration
@Import({AConfig.class, BConfig.class})
public class AppConfig{...}

• 그런데 예제처럼 AConfig , BConfig 가 코드에 딱 정해진 것이 아니라, 특정 조건에 따라서 설정 정보를 선택해야 하는 경우에는 어떻게 해야할까?

동적인 방법

• 스프링은 설정 정보 대상을 동적으로 선택할 수 있는 ImportSelector 인터페이스를 제공한다.
  ImportSelector

package org.springframework.context.annotation;
public interface ImportSelector {
          String[] selectImports(AnnotationMetadata importingClassMetadata);
 }

ImportSelector 예제

HelloBean

package hello.selector;
public class HelloBean {
}

• 빈으로 등록할 대상이다.

HelloConfig

package hello.selector;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class HelloConfig {

    @Bean
    public HelloBean helloBean() {

        return new HelloBean();
    }

}

• 설정 정보이다. HelloBean을 스프링 빈으로 등록한다.

---

package hello.selector;

import org.springframework.context.annotation.ImportSelector;
import org.springframework.core.type.AnnotationMetadata;

public class HelloImportSelector implements ImportSelector {

    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        return new String[] {"hello.selector.HelloConfig"};
    }
}

• 설정 정보를 동적으로 선택할 수 있게 해주는 ImportSelector 인터페이스를 구현했다.
• 여기서는 단순히 hello.selector.HelloConfig 설정 정보를 반환한다.
• 이렇게 반환된 설정 정보는 선택되어서 사용된다.
• 여기에 설정 정보로 사용할 클래스를 동적으로 프로그래밍 하면 된다.

ImportSelectorTest

package hello.selector;

import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Import;

import static org.assertj.core.api.AssertionsForClassTypes.assertThat;

public class ImportSelectorTest {

    @Test
    void staticConfig(){
        AnnotationConfigApplicationContext appContext = new AnnotationConfigApplicationContext(StaticConfig.class);
        HelloBean bean = appContext.getBean(HelloBean.class);
        assertThat(bean).isNotNull();
    }

    @Test
    void selectorConfig() {
        AnnotationConfigApplicationContext appContext =
                new AnnotationConfigApplicationContext(SelectorConfig.class);
        HelloBean bean = appContext.getBean(HelloBean.class);
        assertThat(bean).isNotNull();
    }

    @Configuration
    @Import(HelloConfig.class)
    public static class StaticConfig{}

    @Configuration
    @Import(HelloConfig.class)
    public static class SelectorConfig{}

}

staticConfig()

• staticConfig() 는 이해하는데 어려움이 없을 것이다. 스프링 컨테이너를 만들고, StaticConfig.class 를 초기 설정 정보로 사용했다. 그 결과 HelloBean 이 스프링 컨테이너에 잘 등록된 것을 확인할 수 있다

selectorConfig()

• selectorConfig() 는 SelectorConfig 를 초기 설정 정보로 사용한다.
• SelectorConfig 는 @import(HelloImportSelector.class) 에서 ImportSelector 의 구현체인 HelloImportSelector 를 사용했다.
• 스프링은 HelloImportSelector 를 실행하고, "hello.selector.HelloConfig" 라는 문자를 반환 받는다.
• 스프링은 이 문자에 맞는 대상을 설정 정보로 사용한다. 따라서 hello.selector.HelloConfig 이 설정 정보로 사용된다.
• 그 결과 HelloBean 이 스프링 컨테이너에 잘 등록된 것을 확인할 수 있다.

@EnableAutoConfiguration 동작 방식

@EnableAutoConfiguration

@AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class)
public @interface EnableAutoConfiguration {…}

• AutoConfigurationImportSelector 는 ImportSelector 의 구현체이다. 따라서 설정 정보를 동적으로 선택할 수 있다.
• 실제로 이 코드는 모든 라이브러리에 있는 다음 경로의 파일을 확인한다.
• META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

memory-v2 - org.springframework.boot.autoconfigure.AutoConfiguration.imports
memory.MemoryAutoConfig

spring-boot-autoconfigure - org.springframework.boot.autoconfigure.AutoConfiguration.imports

org.springframework.boot.autoconfigure.aop.AopAutoConfiguration
org.springframework.boot.autoconfigure.data.jdbc.JdbcRepositoriesAutoConfigurati
on
...

• 스프링 부트 자동 구성이 동작하는 방식은 다음 순서로 확인할 수 있다.
• @SpringBootApplication => @EnableAutoConfiguration => @import(AutoConfigurationImportSelector.class) =>
• resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 파일을 열어서 설정 정보 선택
• 해당 파일의 설정 정보가 스프링 컨테이너에 등록되고 사용

정리
스프링 부트의 자동 구성을 직접 만들어서 사용할 때는 다음을 참고하자.

• @autoConfiguration 에 자동 구성의 순서를 지정할 수 있다.
• @autoConfiguration 도 설정 파일이다. 내부에 @configuration 이 있는 것을 확인할 수 있다.
  • 하지만 일반 스프링 설정과 라이프사이클이 다르기 때문에 컴포넌트 스캔의 대상이 되면 안된다.
  • 파일에 지정해서 사용해야 한다.
  • resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
  • 그래서 스프링 부트가 제공하는 컴포넌트 스캔에서는 @autoConfiguration 을 제외하는 AutoConfigurationExcludeFilter 필터가 포함되어 있다.

@SpringBootApplication

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes =TypeExcludeFilter.class),
@Filter(type = FilterType.CUSTOM, classes =AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {...}

자동 구성을 언제 사용하는가

• AutoConfiguration 은 라이브러리를 만들어서 제공할 때 사용하고, 그 외에는 사용하는 일이 거의 없다. 왜냐하면 보통 필요한 빈들을 컴포넌트 스캔하거나 직접 등록하기 때문이다. 하지만 라이브러리를 만들어서 제공할 때는 자동 구성이 유용하다. 실제로 다양한 외부 라이브러리들이 자동 구성을 함께 제공한다.
• 보통 이미 만들어진 라이브러리를 가져다 사용하지, 반대로 라이브러리를 만들어서 제공하는 경우는 매우 드물다. 그럼 자동 구성은 왜 알아두어야 할까?
• 자동 구성을 알아야 하는 진짜 이유는 개발을 진행 하다보면 사용하는 특정 빈들이 어떻게 등록된 것인지 확인이 필요할 때가 있다. 이럴 때 스프링 부트의 자동 구성 코드를 읽을 수 있어야 한다. 그래야 문제가 발생했을 때 대처가 가능하다. 자동화는 매우 편리한 기능이지만 자동화만 믿고 있다가 실무에서 문제가 발생했을 때는 파고 들어가서 문제를 확인하는 정도는 이해해야 한다. 이번에 학습한 정도면 자동 구성 코드를 읽는데 큰 어려움은 없을 것이다.

남은 문제

• 그런데 이런 방식으로 빈이 자동 등록되면, 빈을 등록할 때 사용하는 설정 정보는 어떻게 변경해야 하는지 의문이 들 것 이다. 예를 들어서 DB 접속 URL, ID, PW 같은 것 말이다. 데이터소스 빈을 등록할 때 이런 정보를 입력해야 하는데, 빈이 자동으로 다 등록이 되어 버린다면 이런 정보를 어떻게 입력할 수 있을까? 다음 장을 통해 알아보자.

외부설정과 프로필

외부 설정이란?

• 하나의 애플리케이션을 여러 다른 환경에서 사용해야 할 때가 있다. 대표적으로 개발이 잘 진행되고 있는지 내부에서 확인하는 용도의 개발 환경, 그리고 실제 고객에게 서비스하는 운영 환경이 있다.
  • 개발 환경 : 개발 서버, 개발 DB 사용
  • 운영 환경 : 운영 서버, 운영 DB 사용

문제는 각각의 환경에 따라서 서로 다른 설정값이 존재한다는 점이다. 예를 들어서 애플리케이션이 개발DB에 접근하려면 dev.db.com 이라는 url 정보가 필요한데, 운영DB에 접근하려면 prod.db.com 이라는 서로 다른 url을 사용해야 한다.

- 개발 환경에는 dev.db.com 이 필요하므로 이 값을 애플리케이션 코드에 넣은 다음에 빌드해서 개발 app.jar 를 만든다. - 운영 환경에는 prod.db.com 이 필요하므로 이 값을 애플리케이션 코드에 넣은 다음에 빌드해서 운영 app.jar 를 만든다.

이렇게 하면 각각의 환경에 맞는 개발app.jar , 운영app.jar 가 만들어지므로 해당 파일들을 각 환경별로 배포하면된다.

하지만 이것은 다음과 이유로 좋은 방법이 아니다.

• 환경에 따라서 빌드를 여러번 해야 한다.
• 개발 버전과 운영 버전의 빌드 결과물이 다르다. 따라서 개발 환경에서 검증이 되더라도 운영 환경에서 다른 빌드 결과를 사용하기 때문에 예상치 못한 문제가 발생할 수 있다. 개발용 빌드가 끝나고 검증한 다음에 운영용 빌드를 해야 하는데 그 사이에 누군가 다른 코드를 변경할 수도 있다. 한마디로 진짜 같은 소스코드에서 나온 결과물인지 검증하기가 어렵다.
• 각 환경에 맞추어 최종 빌드가 되어 나온 빌드 결과물은 다른 환경에서 사용할 수 없어서 유연성이 떨어진다. 향후 다른 환경이 필요하면 그곳에 맞도록 또 빌드를 해야 한다.

• 배포 환경과 무관하게 하나의 빌드 결과물을 만든다. 여기서는 app.jar 를 빌드한다. 이 안에는 설정값을 두지 않는다.
• 설정 값은 실행 시점에 각 환경에 따라 외부에서 주입한다.
  • 개발 서버: app.jar 를 실행할 때 dev.db.com 값을 외부 설정으로 주입한다.
  • 운영 서버: app.jar 를 실행할 때 prod.db.com 값을 외부 설정으로 주입한다.

이렇게 하면 빌드도 한번만 하면 되고, 개발 버전과 운영 버전의 빌드 결과물이 같기 때문에 개발환경에서 검증되면 운영 환경에서도 믿고 사용할 수 있다. 그리고 이후에 새로운 환경이 추가되어도 별도의 빌드 과정 없이 기존 app.jar를 사용해서 손쉽게 새로운 환경을 추가할 수 있다.

유지보수하기 좋은 애플리케이션 개발의 가장 기본 원칙은 변하는 것과 변하지 않는 것을 분리하는 것이다. 유지보수하기 좋은 애플리케이션을 개발하는 단순하면서도 중요한 원칙은 변하는 것과 변하지 않는 것을 분리하는 것이다. 각 환경에 따라 변하는 외부 설정값은 분리하고, 변하지 않는 코드와 빌드 결과물은 유지했다. 덕분에 빌드 과정을 줄이고, 환경에 따른 유연성을 확보하게 되었다.

외부 설정
애플리케이션을 실행할 때 필요한 설정값을 외부에서 어떻게 불러와서 애플리케이션에 전달할 수 있을까?

외부 설정은 일반적으로 다음 4가지 방법이 있다.

• OS 환경 변수: OS에서 지원하는 외부 설정, 해당 OS를 사용하는 모든 프로세스에서 사용
• 자바 시스템 속성: 자바에서 지원하는 외부 설정, 해당 JVM안에서 사용
• 자바 커맨드 라인 인수: 커맨드 라인에서 전달하는 외부 설정, 실행시 main(args) 메서드에서 사용
• 외부 파일(설정 데이터): 프로그램에서 외부 파일을 직접 읽어서 사용
  • 애플리케이션에서 특정 위치의 파일을 읽도록 해둔다. 예) data/hello.txt
  • 그리고 각 서버마다 해당 파일안에 다른 설정 정보를 남겨둔다.
    • 개발 서버 hello.txt : url=dev.db.com
    • 운영 서버 hello.txt : url=prod.db.com

먼저 앞의 3가지를 알아보자. 외부 파일(설정 데이터)은 뒤에서 설명한다.