Maven과 Gradle 차이

이클립스 기반으로 개발할때는 Maven이 일반적이었는데, 인텔리제이를 접하게 되면서 Gradle이라는 녀석을 알게 되었다. 도대체 이 두 녀석의 차이가 뭔지 알아볼 필요성을 느꼈다..

 

Maven 이란?

프로젝트를 하다보면 본인의 코드만으로 개발을 하는것이 아닌 수많은 Library들을 활용하여 업무를 진행하게 된다. 만약 이러한 라이브러리들이 수십새가 넘어버린다면 관리를 하는것은 당연히 힘들다. Maven은 바로 이러한 경우에 도와주는 녀석이다. 사용할 라이브러리 뿐만 아니라 해당 라이브러리가 작동하는데 필요한 다른 라이브러리까지 관리하고 네트워크를 통해 자동으로 Set 할 수 있게 해주는 기능까지 있다.

프로젝트의 전체적인 LifeCycle을 관리해주며, 많은 편리함으로 많이 사용되고 있다. Maven 이전에는 Ant가 있었고, 최근에는 바로 Gradle이라는 녀석이 사용되고 있다.

 

Maven의 Lifecycle

Mavn에서는 미리 정희하고 있는 빌드 순서가 있으며, 이러한 순서를 라이프사이클(LifeCycle)이라고 칭한다. 라이프사이클의 빌드단계를 Phase라고 하는데 이들은 의존관계를 가지고 있다.

 

- Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계

- Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용 할 수 있는지 확인하는 단계

- Compile : 프로젝트의 소스코드를 컴파일하는 단계

- Test : 유닛(단위) 테스트를 수행하는 단계(테스트 실패시 빌드 실패로 처리, 스킵 가능)

- Package : 실제 컴파일된 소스 코드와 리소스들을 jar 등의 배포를 위한 패키지로 만드는 단계

- Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계

- Install : 패키지를 로컬 저장소에 설치하는 단계

- Site : 프로젝트 문서를 생성하는 단계

- Deploy : 만들어진 Package를 원격 저장소에 release하는 단계

 

위에서 언급한 라이프사이클 말고도 더 많은 종류의 라이프사이클이 있다. 이들은 크게 Clean, Build, Site 3가지 라이프사이클로 나뉜다. 

각 단계를 모두 수행하는 것이 아닌 원하는 단계까지만 수행이 가능하고, test 단계에서는 큰 프로젝트의 경우 많은 시간이 소요 될 수 있으니 수행하지 않도록 스킵 또한 가능하다.

 

Phase와 Goal

Phase는 Maven의 Build LifeCycle의 각각의 단계를 의미한다. 각각의 Phase는 의존관계를 가지고 있으며, 해당 Phase가 수행되려면 이전 단계의 Phase는 모두 수행 되어야한다.

Maven에서 제공되는 모든 기능은 플러그인 기반으로 동작하는데, Maven은 LifeCycle에 포함되어 있는 Phase 마저도 플러그인을 통해 실질적인 작업이 수행된다. 즉 각각의 Phase는 어떤 일을 할지 정의하지 않고 어떤 플러그인의 Goal을 실행할지 설정한다. Maven은 하나의 플러그인에서 여러 작업을 수행 할 수 있도록 지원하고, 플러그인에서 실행 할 수 있는 각각의 기능을 Goal이라고 한다. Goal을 실행하는 방법은 -mvn plugin:goal 식으로 진행 할 수 있다.

원래는 -mvn groupId:artifactId:version:goal 인데 앞 부분은 생략이 가능하다.

 

POM(Project Object Model) 이란?

메이븐 프로젝트를 할때 흔히 보는 pom.xml 의 pom은 Project Object Model의 약자이다. 말 그대로 Project Object Model의 정보를 담고 있는 파일이다. 이 파일에서 다루는 주요 기능들은

 

- 프로젝트 정보: 프로젝트의 이름, 개발자 목록, 라이센스 등

- 빌드 설정 : 소스, 리소스, 라이프 사이클별 실행한 플러그인(goal) 등 빌드와 관련된 설정

- 빌드 환경 : 사용자 환경 별로 달라질 수 있는 프로파일 정보

- pom 연관 정보 : 의존 프로젝트(모듈), 상위 프로젝트, 포함하고 있는 하위 모듈 등

 

이러한 pom은 Maven의 기능을 이용하기 위해선 사용되는 녀석이다.

 

Gradle 이란?

자 그럼 이제 Gradel에 대해 알아볼까?

Gradle은 기본적으로 빌드 배포 도구(Build Tool)이며, 안드로이드 앱을 만들때 필요한 공식 빌드시스템이자 Java, C와 C++ 그리고 파이썬 등을 지원하고 있다. 빌드툴인 Ant Builder와 그루비 스크립트를 기반으로 구축되어 기존 Ant의 역할과 배포 스크립트의 기능을 모두 사용이 가능하다.

Maven의 경우에는 xml로 라이브러리를 정의하고 활용을 하였으나 Gradle의 경우 별도의 빌드스크립트를 통해 사용하고 어플리케이션의 버전과 라이브러리 등의 항목이 설정 가능하다.

스크립트 언어로 구성되어 있기때문에 xml과 달리 변수 선언, if, else, for 등의 로직 구현이 가능하여 간결하게 구성이 가능하다는것이 장점이다.

 

- 라이브러리 관리 : Maven Repository를 동일하게 사용 할 수 있어 설정된 서버를 통해 라이브러리를 다운로드하여 모두 동일한 의존성을 가진 환경을 수정 할 수 있다. 자신이 추가한 라이브러리도 레포지토리 서버에 올리는것이 가능하다.

- 프로젝트 관리 : 모든 프로젝트가 일관된 디렉토리 구조를 가지고 빌드 프로세스를 유지하도록 도와준다.

- 단위 테스트 시 의존성 관리 : Junit 등을 사용하기 위해 명시한다.

 

그래서 Maven과 Gradle 둘중 뭘 사용해야하는가?

Gradle이 시기적으로 늦게 나온만큼 사용성, 성능 등 이 Maven 보다 비교적 뛰어난 스펙을 지니고 있는건 사실이다.

Gradle이 Maven 보다 좋은점

1) Build라는 동적인 요소를 xml로 정의하기에는 어려운 부분들이 많다.

- 설정 내용이 길어지고 가독성이 떨어진다.

- 의존관계가 복잡한 프로젝트 설정에는 부적절하다

- 상속구조를 이용한 멀티 모듈 구현

- 특정 설정을 소수의 모듈에서 공유하기 위해서는 부모 프로젝트를 생성하여 상속하게 해야함(상속의 단점 생김)

 

2) Gradle은 그루비를 사용하기 때문에, 동적인 빌드는 Groovy 스크립트로 플러그인을 호출하거나 직접 코드를 짜면 된다.

- Configuration Injection 방식을 사용해서 공통 모듈을 상속해서 사용하는 단점을 커버한다.

- 설정 주입시 프로젝트의 조건을 체크 할 수 있어서 프로젝트별로 주입되는 설정을 다르게 할 수 있다.

 

3) Gradle이 Maven 보다 처리되는 속도가 빠르다.

---

Gradle과 Maven 둘 중에 무엇을 사용하는지가 정답이 있을까? 우리가 아직 Gradle이 어색한 이유는 Maven처럼 익숙하지 않기때문이다. Gradle이 출시되었을때 Maven이 지원하는 Scope를 지원하지 않았고, 성능면에서도 앞서는것이 없었다고한다.

Ant의 유연한 구조적 장점과 Maven의 편리한 의존성 관리 기능을 합쳐놓은 것만으로도 많은 인기를 얻었던 Gradle은 버전이 올라가면서 성능도 함께 개선되는 장점을 통해 자리를 잡기 시작했다.

기업이고 가정을 했을때 그동안 사용했던 Maven과 익숙해져버린 xml을 대신하여 Gradle과 Groovy 문법을 새로 익힌다는건 비용적인 측면도 무시 할 수가 없다. 특히나 협업의 경우 프로젝트 구성과 빌드만을 위해서 모든 팀원이 Groovy 문법을 익혀야 한다는 사실은 Gradle을 사용하는데 있어 걸림돌이 될 수도 있다.

 

(나는 잘 몰랐지만) 실제로 여전히 Maven의 사용률은 Gradle보다 높다고 한다. 그래도 2가지는 모두 알아두는것이 좋겠지? 빌드타임의 비용적인 문제로 봤을때 아무래도 Gradle이 더 빠르기 때문에 익히긴 익혀야 할 것이다.

민첩하게 배포를 생각하고 있다면 Gradle이 필요할 것 같다.

 

mybatis와 JPA처럼 Maven 과 Gradle도 향후 몇 년이 어떻게 될지 궁금하다.

---

출처

https://gradle.org/
https://maven.apache.org/
http://egloos.zum.com/kwon37xi/v/4747016
https://bkim.tistory.com/13

https://hyojun123.github.io/2019/04/18/gradleAndMaven/