첫 번째 스프링 부트 애플리케이션 개발하기
구성 요소
@springBootApplication : 스프링 컴포넌트 검색과 스프링 부트 자동 구성을 활성화
@configuration : 스프링의 자바 기반 구성 클래스로 지정한다.
@componentScan : 컴포넌트 검색 기능을 활성화해서 웹 컨트롤러 클래스나 다른 컴포넌트 클래스들을 자동으로 검색하여 스프링 애플리케이션 컨텍스트에 빈으로 등록시킨다. ( 잠시 후 간단한 스프링 MVC 컨트롤러를 작성하면서 @Controller 애너테이션을 붙여 컴포넌트 검색이 이 컨트롤러를 찾을 수 있게 할 것이다. )
@EnableAutoConfiguration : @Abracadabra와 같은 의미로 스프링 부트의 자동 구성 설정
이외에 추가 구성이 필요하다면 @Configuration 에너테이션을 포함한 구성 클래스에서 작성하는 것이 가장 좋다. ( 이 구성 클래스 등은 컴포넌트 검색으로 자동으로 추가한다. )
pom.xml 프로젝트에 부모 스타터를 지정하면 메이븐의 의존성 관리 기능으로 자주 사용하는 라이브러리들의 의존성 버전을 상속받을 수 있어서 의존성을 선언할 때 버전을 명시하지 않아도 된다.
스타터 의존성 사용하기
Thymeleaf 뷰와 이 뷰의 데이터를 JPA로 저장하는 스프링 웹 애플리케이션을 개발하고 싶을 뿐이다.하지만 코드 첫 줄을 작성하기도 전에 빌드 명세에 어떤 것을 추가하여 기능을 만들어야 할지를 고민해야 한다.
Thymeleaf의 그룹 ID와 이티팩트 ID는 기억나는가?
스프링 데이터 JPA의 어떤 버전을 사용해야 할까? 이 모든 의존성은 서로 잘 호환이 될까?
만약 작성했다고 하더라도 그것이 잘 작성되었는지 어떻게 알 수 있을까?
선택한 의존성 버전까지 서로 잘 호환되는지 어떻게 장담할 수 있을까?
물론 잘될 수도 있지만, 애플리케이션을 빌드하고 실행하기 전까지는 확실히 알 수 없을 것이다. 스타터 의존성 버전은 사용하는 스프링 부트 버전에 따라 결정된다.또 스타터 의존성은 추가로 가져오는 다양한 전이적 의존성 버전도 자체적으로 결정한다.사용하는 여러 라이브러리의 버전을 몰라서 불안할 수도 있다. 하지만 스프링 부트는 사용할 모든 의존성 간에 호환성을 보장하도록 테스트를 마쳤다.
그럼에도 스타터 의존성이 가져오는 전이적 의존성 버전을 알고 싶다면 빌드 도구를 이용한다.
스타터 의존성은 빌드에 있는 다른 의존성처럼 의존성일 뿐이다. 이는 빌드 도구로 전이적 의존성 버전을 선택적으로 오버라이드 할 수 있고, 전이적 의존성들을 제외할 수 있으며,스프링 부트 스타터가 포함하지 않는 라이브러리에 의존성을 확실하게 지정할 수 있다는 의미다. 메이븐에서는 exclusions 요소를 사용하여 전이적 의존성을 제외할 수 있다. 가급적이면 새로운 버전에서 버그를 고칠 때 같은 특별한 상황에서만 전이적 의존성을 오버라이드하는 것이 좋다.
자동 구성 사용하기
스프링 부트 자동 구성은 스프링 구성을 적용해야 할지 말지를 결정하는 요인들을 판단하는 런타임 과정이라고 할 수 있다. 예를 들어
클래스패스에 jdbcTemplate이 있고 DataSource 빈이 있다면 JdbcTemplate 빈을 자동 구성한다.
클래스패스에 Thymeleaf가 있다면 Thymeleaf템플릿 리졸버, 뷰 리졸버, 템플릿 엔진을 구성한다.
클래스패스에 스프링 시큐리티가 있다면 아주 기본적인 웹 보안을 구성한다.
애플리케이션이 시작될 때 마다 스프링 부트는보안, 통합, 데이터 저장, 웹 개발 영역 등을 커버하려고 자동 구성에서 대략 200가지 정도 결정을 내린다.이 자동 구성 덕분에 필요한 상황이 아니면 명시적으로 구성을 작성하지 않아도 된다. (자동 구성을 이용하면 스프링 부트를 사용하지 않은 스프링 애플리케이션에서 흔히 했던 보일러플레이트 구성을 직접 하지 않아도 된다. )
Last updated