빌드 관리 도구란?

프로젝트 생성, 테스트 빌드, 배포 등의 작업을 위한 전용 프로그램
프로젝트에서 작성한 java 코드와 프로젝트 내에 필요한 각종 xml, properties, jar 파일들을 JVM이나 WAS가 인식할 수 있도록 패키징해주는 빌드 과정 = 빌드 자동화 도구
프로젝트에 필요한 외부 라이브러리들의 종류와 버전들, 종속성 정보를 명시하여 자동으로 다운로드하고 관리하는 도구

Maven

Maven은 Java용 프로젝트 관리도구로 Apache의 Ant 대안으로 만들어 졌다. 빌드 중인 프로젝트, 빌드 순서, 라이브러리 종속성 관계를 pom.xml 에 명시한다. 외부저장소에서 필요한 라이브러리와 플러그인들을 다운로드 한 다음, 로컬시스템의 캐시에 모두 저장한다.

예를들어 "Spring Boot Data JPA Starter" 모듈이 필요하면 Maven Repository에서 해당 모듈을 검색하여 xml 설정 파일에 추가하여 사용할 수 있다. (Maven용 코드 이외에도 gradle 등 다른 빌드 관리용 코드도 있다.)

[Spring] 빌드 관리 도구 Maven과 Gradle 비교하기.


<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
    <version>2.2.4.RELEASE</version>
</dependency>

Gradle

Apache Maven과 Apache Ant에서 볼 수 있는 개념들을 대안으로서 나온 프로젝트 빌드 관리 툴이다. (완전한 오픈소스) Groovy 언어를 사용한 Domain-specific-langauge를 사용한다. (xml보다 훨씬 간결하다) 꽤 큰 규모로 예상되는 multi-project 빌드를 도울 수 있도록 디자인되었다. 프로젝트의 어느 부분이 업데이트되었는지 알기 때문에, 빌드에 점진적으로 추가할 수 있다. (업데이트가 이미 반영된 빌드의 부분은 더 이상 재실행되지 않아, 빌드 시간이 훨씬 단축될 수 있다)

Maven VS Gradle

두 시스템이 빌드에 접근하는 방식에는 몇 가지 근본적인 차이점이 있다.

Gradle은 작업 의존성 그래프를 기반으로 하는 반면 Maven은 고정적이고 선형적인 단계의 모델을 기반으로 한다고 한다. 성능 측면에서는 둘 다 다중 모듈 빌드를 병렬로 실행할 수 있지만, Gradle은 어떤 task가 업데이트되었고 안되었는지 체크하기 때문에 Incremental build를 허용한다. 이미 업데이트된 task에 대해서는 작업이 실행되지 않으므로 빌드 시간이 훨씬 단축된다.

→ 빌드 설정 규모가 점점 키지면 커질수록, 빌드 시간의 차이도 Maven과 비교하여 꽤 격차가 벌어질 수 있을 것 같다.

Maven의 경우 멀티 프로젝트에서 특정 설정을 다른 모듈에서 사용하려면 상속을 받아야하지만, Gradle은 설정 주입 방식을 제공한다.
Gradle은 concurent에 안전한 캐시를 허용한다.

→ 2개 이상의 프로젝트에서 동일한 캐시를 사용할 경우, 서로 overwrite되지 않도록 checksum 기반의 캐시를 허용하고, 캐시를 repository와 동기화시킬 수 있다.

고도로 사용자 정의된 빌드를 작성하기 위해서는 커스터마이징이 간편한 Gradle을 사용하는게 훨씬 낫다.

속도나 캐시 사용 안정성에 대하여 당연히 Gradle로 사용하는게 이득이겠다는 생각이 든다. 그럼에도 Gradle을 상용하지 않는 이유는 초반에 Maven의 Scope를 지원하지 않았고 성능면에서도 앞설 것이 없었다. 이러한 점은 현재에 해결되었지만 여전히 익숙함의 문제와 새로운 것을 배우는 비용의 문제, 이로 인해 팀프로젝트에서 사용하기 위해서는 다른 팀원도 배워야한 다는 문제가 발생한다. 구글 트렌드가 그 차이를 여실히 보여주고 있는 듯 하다.