이 시점에서 CLI가 다시 컴파일을 시도해도 import 문이 빠져 있으므로 여전히 컴파일에 실패할 것이다. 하지만 CLI는 흔히 사용하는 여러 타입의 패키지를 잘 알고 있다. 그루비 컴파일러의 기본 패키지 임포트를 사용자 정의할 수 있다는 이점을 살려 CLI는 필요한 패키지를 모두 그루비 컴파일러의 기본 임포트 리스트에 추가한다.

이제 CLI가 다시 컴파일을 시도한다. CLI의 기능 밖에서 문제(문법적 오류가 있거나 CLI가 인식하지 못하는 타입이 포함되는 등 문제)가 없다면 코드는 깔끔하게 컴파일될 것이고, CLI는 자바 기반의 예제에서 애플리케이션에 추가한 main() 메서드와 비슷한 내부 부트스트랩 메서드로 실행할 것이다.

이때쯤이면 스프링 부트 자동 구성을 활성화한다. CLI가 웹 스타터를 해석한 결과로 스프링 MVC가 클래스패스에 있으며, 이에 따라 스프링 MVC를 지원하는 데 적합한 빈과 애플리케이션을 구동할 내장 톰캣 빈을 자동으로 구성한다. 클래스패스에서 JdbcTemplate도 발견하므로 JdbcTemplate 빈을 자동으로 생성하고, 마찬가지로 자동으로 생성한 DataSource 빈과 연결한다.

DataSource 빈은 스프링 부트 자동 구성으로 생성된 많은 빈 중 하나다. 스프링 부트는 스프링 MVC에서 Thymeleaf 뷰를 지원하는 빈도 자동으로 구성한다. 이는 H2와 Thymeleaf를 클래스패스에 추가하려고 내장 H2 데이터베이스와 Thymeleaf를 자동 구성하는 @Grab 애너테이션을 사용했기 때문이다.

@Grab 애너테이션은 CLI가 자동으로 해석하지 못하는 의존성을 추가하는 아주 간단한 방법이다. 이 애너테이션에는 눈에 보이는 간편함만 있는 것은 아니다. 이제 @Grab 애너테이션에 어떤 특별한 기능이 숨어 있는지, 스프링 부트 CLI가 흔히 사용하는 다수의 의존성에서는 아티팩트 이름만 요구하여 얼마나 더 간단해질 수 있는지, 의존성 해결 과정을 어떻게 구성하는지 자세히 알아보자.