이번 포스팅에서 다룰 주제는
Spring Project에서 사용하는 필수적인 관리 도구인 Gradle과 Maven에 대해 알아보며
Gradle과 Maven이 어떤 부분에서 차이점이 있는지
Gradle의 장점으로 인한 CI / CD 환경에 대해 알아보겠습니다.
Maven과 Gradle 모두 빌드 관리 도구입니다.
빌드 관리 도구란???
프로젝트에서 작성한 소스 코드와 프로젝트 내에 필요한 Xml, Properties, jar 등의 파일을 JVM 혹은 WAS가 인식할 수 있도록 도와주는 도구입니다.
프로젝트의 생성, 테스트 빌드 혹은 배포 등의 작업을 위한 전용 도구입니다.
애플리케이션을 개발하며 필요한 라이브러리들을 다운로드하고 사용할 때 번거롭게 일일이 다운로드할 필요 없이 빌드 도구 설정에 필요한 라이브러리의 버전, 이름, 종속성을 명시하여 해당 관리 도구를 통해 자동으로 다운로드하고 간편하게 사용할 수 있습니다.
다음은 Gradle입니다.
Gradle이란??
Gradle은 빌드 배포 도구( Build Tool )입니다. ( 오픈소스 )
안드로이드 앱을 만들때에도 필요한 공식 빌드 시스템이며, Java, C or C++, Python 등을 지원합니다.
빌드 관리 도구인 Apache Maven과 Apache Ant의 기능과 역할에 대안으로 나온 프로젝트 관리 도구입니다.
Groovy Scrpit 언어를 사용한 Domain-Specifit-language를 사용합니다.
대규모의 프로젝트 빌드( Multi-Project )빌드 또한 도와줄 수 있도록 설계되었습니다.
Gradle의 특징은 빌드할 프로젝트의 업데이트된 부분을 알기 때문에 이미 반영된 부분은 더 이상 재실행되지 않습니다.
( 빌드 시간이 단축되는 장점을 갖고 있습니다. )
기본 메이븐의 경우에 XML로 라이브러리를 정의하고 활용하도록 되어 있지만, Gradle의 경우 별도의 빌드 스크립트를 통하여 사용할 애플리케이션 버전, 라이브러리 등의 항목을 설정할 수 있습니다.
Gradle의 장점 중 하나는 스크립트 언어로 구성되어 있어, XML과 다르게 변수의 선언, 조건문, 반복문등의 로직 구현이 가능하여 비교적 간결하게 구성 가능합니다.
그렇다면 Maven이란 무엇일까요???
Maven이란???
Maven 또한 Gradle처럼 빌드 관리 도구입니다.
Maven은 프로젝트의 전체적인 LifeCycle을 관리하는 도구이며, Apache에 Ant의 대안으로 설계되어 만들어졌습니다.
Maven의 특징으로 빌드 중인 프로젝트의 빌드 순서, 다양한 라이브러리의 종속성 관계를 Xml에 명시하여 사용합니다.
또한, Maven은 외부 저장소에서 필요한 라이브러리와 플러그인들을 다운로드하고, 로컬 시스템 캐시에 모두 저장합니다.
Maven에서는 미리 정의한 빌드 순서가 있으며 이러한 순서를 LifeCycle이라고 합니다.
LifeCycle의 빌드 단계를 Phase라고 하며, Phase들은 서로 의존 관계를 가지고 있습니다.
- Clean : 이전 빌드에서 생성된 파일들을 삭제하는 단계
- Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는 지 확인하는 단계
- Compile : 프로젝트의 소스 코드를 컴파일하는 단계
- Test : 단위( 유닛 )테스트를 수행하는 단계( 테스트를 실패할 경우 빌드 실패로 처리하며, 생략 가능한 단계입니다. )
- Package : 컴파일된 소스 코드와 리소스들을 jar 등의 배포를 위한 패키지로 만드는 단계
- Verify : 통합테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
- Install : 패키지를 로컬 저장소에 설치하는 단계
- Site : 프로젝트 문서를 생성하는 단계
- Deploy : 만들어진 Package를 원격 저장소에 Release 하는 단계
나열한 9가지의 LifeCycle 이외에도 수 많은 단계들이 존재합니다.
다양한 단계들을 큰 분류로 Clean, Build, Site로 나누며 각 단계를 모두 수행하는 것이 아닌 원하는 단계까지만 수행할 수 있습니다. ( 특히 Test 단계는 대규모 프로젝트의 경우 몇 시간이 소요될 수 있으며 해당 단계를 생략할 수 있습니다. )
또한, 앞서 설명한 Phase의 의존관계로 원하는 Phase가 수행되려면 이전 단계의 Phase가 모두 수행되어야 합니다.
Maven의 기능을 사용하기 위해서는 pom.xml 파일을 사용해야합니다.
POM 이란? ( Project Object Model )
POM은 말 그대로 해당 프로젝트 객체의 모델 정보를 담고 있는 파일입니다.
pom.xml에서 주로 사용하는 기능들입니다.
- 프로젝트 정보 : 프로젝트의 이름, 개발자 목록, 라이선스 등
- 빌드 설정 : 소스, 리소스, 라이프사이클 단계별 실행할 플러그인 등의 빌드와 관련된 설정
- 빌드 환경 : 사용자 환경 별로 달라질 수 있는 프로파일 정보
- POM연관 정보 : 의존 프로젝트( 모듈 ), 상위 프로젝트, 포함하고 있는 하위 프로젝트( 모듈 )
Gradle과 Maven의 대략적인 흐름을 알아보았고 다음은 차이점에 대해 알아보겠습니다.
그럼 Gradle과 Maven 둘 중에 무엇을 써야 하나요???
우선 Gradle을 사용하지 않는 이유는 Maven의 익숙함이 이유 중 한 가지입니다.
Gradle을 사용하기에 앞서 Maven과 Xml에 익숙해져 버린 프로젝트 구성원이 Gradle과 Groovy 구문을 배우고 사용하는 비용은 적지 않습니다. 그렇기에 협업이 중요한 개발환경에서는 구성원 모두 Gradle 구문을 익혀야 하는 사실 때문에 Gradle의 사용에 제한이 있을 수 있습니다.
하지만 Gradle이 처음 ( 태어났을 때? ) 출시되었을 때 Maven은 지원하지만 Gradle이 지원하지 않는 Scope와 같은 기능들이 있었고 성능적인 부분에서도 좋은 게 없었지만 Ant의 유연한 구조적 장점과 Maven의 편리한 의존성 관리 기능을 합쳐 놓은 것만으로도 인기를 끌며 Gradle이 버전업 되면서 성능 향상 등의 장점까지 더해지며 대세 빌드 도구가 되었습니다.
Gradle과 Maven을 비교하였을 때
Maven은 빌드라는 동적인 요소를 XML로 정의하기에는 어렵습니다.
Maven으로 관리할 경우 설정할 내용이 길어지고 가독성이 떨어집니다.
의존관계가 복잡한 대규모 프로젝트인 경우 설정하기에 부적절합니다. ( Gradle은 상속 구조를 이요한 Multi-Module 구현 가능 )
Maven은 특성 설정을 몇몇 개의 모듈에서만 공유하기 위해서는 부모 프로젝트를 생성하여 상속해야 합니다.( 상속의 단점 )
Gradle은 Groovy 문법을 사용하기 때문에 동적인 요소는 Groovy Script로 플러그인을 호출하거나 직접 코드를 작성하면 사용할 수 있습니다.
또한 위에서 언급한 공통 모듈을 의존성 주입 시 프로젝트마다 조건을 부여해서 프로젝트 마다 설정을 다르게 구현할 수 있습니다.
Gradle과 Maven의 근본적인 차이점으로는
Gradle은 작업 의존성 그래프를 기반으로 관리하는 도구이며 반면에 Maven은 고정적이고 선형적인 단계의 모델을 기반으로 관리합니다.
성능적 측면에서는 Gradle의 경우 해당 Task가 업데이트되었는지 여부를 확인하기 때문에 incremental build를 허용합니다.
이미 업데이트된 Task에 대해서는 빌드가 실행되지 않으므로 많은 시간을 아낄 수 있습니다.
Maven은 상속 기능을 사용해야 하지만 Gradle은 설정 주입 방식을 사용합니다.
Gradle은 concurrent에 안전한 캐시를 허용합니다.
( 2개 이상의 프로젝트에서 동일한 캐시를 사용하는 경우에 서로 overwrite하지 않도록 checksum 기반의 캐시를 사용하며 캐시를 repository와 동기화할 수 있습니다. )
마지막으로 Gradle은 고급 사용자 정의 빌드 커스터마이징이 간편합니다.
이러한 장점들을 종합했을 때 Gradle은 빠른 *CI/CD 배포와 신속한 테스트를 진행해야 하는 개발환경에서는 무조건적으로 Gradle을 사용한다고 합니다.
*CI/CD ( 지속적인 통합, 지속적인 배포 )
CI와 CD 중 CI ( Continuous Integration )을 의미합니다. CI를 성공적으로 구현할 경우 애플리케이션의 새로운 코드 변경사항이 정기적으로 빌드 및 테스트되어 공유된 Repository에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있습니다.
CD ( Continuous Delivery )는 즉 지속적인 서비스 제공 또는 지속적인 배포를 의미합니다.
지속적인 서비스, 지속적인 배포 이 두 용어는 상호 교환적입니다.
두 가지 의미 모두 애플리케이션의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 따로 사용되기도 합니다.
지속적인 서비스 제공( Continuous Delivery ) : 여러 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 Repository에 자동으로 업로드되는 것을 뜻합니다. 관리팀은 해당 Repositroy에서 애플리케이션을 해당 제품의 실시간 환경으로 배포 가능합니다. 이 용어는 최소한의 노력으로 새로운 코드를 배포하는 것이 목표로 합니다.
지속적인 배포( Continuous Deployment ) : 여러 개발자의 변경 사항을 해당 Repository에서 고객이 사용할 제품 환경까지 자동으로 Release 하는 것을 의미합니다. 이 용어는 애플리케이션이 제공하는 속도를 저해하는 수동 프로세스로 인한 관리팀의 프로세스 과부하 문제를 해결합니다.
이번 포스팅으로 Gradle과 Maven의 차이점을 알아보았습니다.
Gradle을 사용하며 CI와 CD의 개념에 대해 알아볼 수 있는 좋은 포스팅이었습니다.
더 자세한 CI / CD에 대한 설명은 Redhat 공식 홈페이지에서 확인할 수 있습니다.
'Backend > Spring' 카테고리의 다른 글
| 자주 사용되는 Spring 어노테이션에 대해 알아보자! (0) | 2022.01.21 |
|---|---|
| Spring AOP의 구동 원리와 Proxy와의 관계 (0) | 2022.01.13 |
| AOP, Filter, Interceptor의 정의와 차이점 (3) - AOP편 (0) | 2022.01.11 |
| AOP, Filter, Interceptor의 정의와 차이점 (2) - Interceptor 편 (0) | 2022.01.11 |
| AOP, Filter, Interceptor의 정의와 차이점 (1) - Filter 편 (0) | 2022.01.10 |