자동 설정

클래스패스에 무엇이 있는지, 어떤 빈이 이미 있는지를 보고 필요한 빈을 대신 등록해 주는 기능. Boot의 핵심이다.

두 단계로 돈다

• ① 후보 목록을 읽는다
  • 각 스타터 jar 의 META-INF/spring/…AutoConfiguration.imports

② 조건을 평가한다 (@Conditional)
   @ConditionalOnClass         이 클래스가 클래스패스에 있나
   @ConditionalOnMissingBean   내가 직접 정의한 빈이 없나
   @ConditionalOnProperty      이 설정이 켜져 있나

중요한 건 순서다 — 자동 설정은 사용자 설정 다음에(deferred) 평가된다. 그래서 내가 정의한 빈이 항상 이긴다.

@AutoConfiguration
@ConditionalOnClass(DataSource.class)
class DataSourceAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean            // ← "내 정의에 양보한다" 를 구현하는 한 줄
    DataSource dataSource(...) { ... }
}

왜 이 빈이 생겼지 / 왜 안 생겼지

java -jar app.jar --debug              # 조건 평가 리포트
curl localhost:8080/actuator/conditions

• Positive matches: — 통과한 조건 — 왜 이 빈이 생겼는지
• Negative matches: — 탈락한 조건 — 왜 안 생겼는지
  • DataSourceAutoConfiguration:
    • Did not match: @ConditionalOnClass did not find required class 'javax.sql.DataSource'

"왜 안 되지"의 답이 여기 다 있다. 추측하기 전에 이걸 먼저 본다.

끄는 법

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)

spring.autoconfigure.exclude: org.springframework.boot...DataSourceAutoConfiguration

Spring Boot 4에서 실제로 부딪히는 지점

4.x 는 코드베이스가 잘게 모듈화됐다

• 예전에 다른 스타터에 '묻어 오던' 자동 설정이 더는 안 딸려온다
• 3.x 에서 올리면 "되던 게 안 되는" 경험을 한다
  • (Flyway 가 안 돌거나 H2 콘솔이 안 뜨거나)
• 버그가 아니라 의존성을 명시적으로 선언해야 하는 것이다

조건 리포트의 Negative matches에 @ConditionalOnClass 실패로 찍히면 답은 하나다 — 해당 스타터를 추가한다.

설정값 우선순위 (바깥일수록 이긴다)

명령행 인자  >  SPRING_APPLICATION_JSON  >  환경변수·시스템 프로퍼티
            >  application-{profile}.yml  >  application.yml  >  @PropertySource

relaxed binding 덕분에 my.service.pool-size 하나를 MY_SERVICE_POOLSIZE 환경변수로도 받을 수 있다.

면접 함정

• ❌ "자동 설정이 내 빈을 덮어쓴다" → 반대다. @ConditionalOnMissingBean으로 물러난다.
• ❌ "Boot가 마법을 부린다" → 조건 평가 리포트로 전부 설명된다.