(+) 스프링 의존성 관리

의존성 관리가 무엇이며 왜 필요한가

개발을 하다보면 여러가지 의존성을 주입하여 사용하게 된다. 그게 서드파티 라이브러리이든 프레임워크가 기본적으로 제공하는 라이브러리이든(이 경우 라이브러리 라는 단어의 경계가 모호해진다) 다양한 의존성을 설정하고 사용하게 되는데, 이 때 발생할 수 있는 가장 큰 문제는 ‘호환성’이다. 가령 A라는 의존성의 1.0버전은 스프링부트 2.2 에서 제공해주고 있는 자원을 활용하여 만들어졌는데 그 기능이 스프링부트 2.3에서 deprecated 되었다고 가정하자.

이러한 사실을 개발자가 직접 체크하고 미리 대비하지 않는 이상 스프링부트 버전을 2.2에서 2.3으로 올리는 순간 잘 작동하던 A라는 의존성의 1.0 버전은 에러를 발생시킨다. 우리는 개발을 하며 다양한 의존성들을 사용하고 이들 의존성은 프레임워크의 특정 버전에 종속적일 수 있다. 그렇기 때문에 어떤 버전이 프레임워크의 어떤 버전과 호환되고 있는지에 관한 이슈는 매우 중요하며, 많은 의존성들을 사용하는 만큼 관리 포인트가 많아진다(=개발자의 일이 많아지고, 하나라도 놓칠 여지가 많아진다)

이러한 맥락에서 결국 ‘의존성 관리’란 ‘의존성 (버전) 관리’라는 의미로 풀어서 말할 수 있다. 개발자가 의존성 설정시 버전간의 호환 이슈에서 자유롭도록 해주어 결국 ‘개발을 편하게’ 해주는 것이다.

의존성 관리는 어떻게 이뤄지는가

plugins {
    id 'org.springframework.boot' version '2.4.5'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

gradle을 기준으로 plugin 으로 io.spring.dependency-management를 선언해준다. 그러면 아래와 같이 io.spring.dependency-management의 대상이 되는 라이브러리의 경우 특별히 버전을 명시해주지 않아도 알아서 호환성을 고려하여 문제가 없는 버전을 잡아준다. 굳이 특정한 버전을 원할 경우 버전을 명시해주면 그 버전을 가져오게 된다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

maven의 경우 조금 다른데 원리는 같다. maven은 pom에서 소스를 타고 들어가서 어떤 라이브러리들을 어떤 버전으로 관리해주는지 더 보기가 편하다.

자동설정이 무엇인가

의존성을 '선언'해주는 것은 단지 그것을 External Libraries 로 받아오라는 뜻이지 이후에 아무 설정도 해주지 않으면 의미가 없다. 그런 의미에서 스프링부트가 제공해주는 ‘자동 설정’은 가져온 의존성들을 최적의 형태로 알아서 설정해주는 기능이다.

가령 db만 하더라도 mysql을 쓰고싶다 그러면 mysql 의존성을 설정해주고 .properties에 db 커넥션 정보를 넣어주기만 해도 어플리케이션이 db에 붙는 이 모든 것이 ‘자동 설정’덕분에 가능한 일이다. 스프링부트 프로젝트를 바로 실행만 해도 알아서 내장 톰캣이 뜨는 것 역시 결국 자동 설정 덕분이다.

그러면 여기서 의문인 것은 스프링부트가 내가 원하는 설정이 무엇인지 알고 알아서 ‘자동’으로 설정해주는지 이다. 이건 spring 진영에서 그냥 convention을 참고하여 ‘이것이 최적의 형태겠다’라고 생각되는 것을 기본 전략으로 정의해뒀고 자동 설정은 이 전략에 따라 처리된다.

스프링부트의 자동설정은 @SpringBootApplication이라는 어노테이션이 포함하고 있는 @EnableAutoConfiguration이라는 어노테이션에 의해서 처리되기 때문에 @EnableAutoConfiguration 에 대해서 학습하는 것이 곧 스프링부트의 자동설정을 이해하는 것이다.

하지만 일단 @EnableAutoConfiguration 에 대해서 정리하기 전에 @SpringBootApplication 를 정리하는게 좋을 것 같아서 @SpringBootApplication 에 대해서 알아보고 @EnableAutoConfiguration를 알아보자.

@SpringBootApplication 을 이해하기

@SpringBootApplication은 메타어노테이션이며 아래와 같은 어노테이션들로 구성되어 있다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {

@SpringBootConfiguration은 @Configuration과도 같아서 크게 의미가 없고 핵심은 @ComponentScan과 @EnableAutoConfiguration를 이해하는 것이다. 컴포넌트 스캔 은 공식문서를 참고하면 될 것 같다.

스프링의 bean은 결국 아래 두 단계로 읽히게 된다.

• @ComponentScan

• @EnableAutoConfiguration

그래서 ComponentScan에 의해서 bean이 먼저 등록이 되고 그 뒤에 자동설정이 적용되기 때문에 ‘커스텀 설정’이 가능하다. 이건 @EnableAutoConfiguration 를 정리하며 자세히 알아보자.

@EnableAutoConfiguration 을 이해하기

결국 스프링부트의 자동 설정은 @EnableAutoConfiguration에 의해서 이뤄진다.

@EnableAutoConfiguration 는 스프링부트가 제공하는 autoconfigure의 spring.factories에 정의된 Auto Configure의 값들을 key로 사용하여 스프링의 설정파일로 사용하게 만든다. 실제로 아무 키값이나 잡고 타고 들어가보면 결국 그 클래스에 @Configuration이 선언되어 있는 것을 확인할 수 있다.

여기서 주목해서 봐야할 것은 @ConditionalOn~ 이라는 어노테이션이다. 대표적인 예시로 @ConditionalOnMissingBean 이라는 어노테이션이 있다.

@Conditional that only matches when no beans meeting the specified requirements are already contained in the BeanFactory. None of the requirements must be met for the condition to match and the requirements do not have to be met by the same bean.

공식문서에도 나와있듯이 ‘없으면 이거 등록해라’ 라는 의미이다. 이 조건으로 인해서 스프링부트에서 최선이라고 생각하고 제공해주는 ‘자동 설정’ 에서 일부 변경하여 커스텀한 설정이 가능해진다.