그레이들의 장점

* 그레이들의 장점

 

(1) 빌드 스크립트 생산성이 높음.

- 그레이들은 메이븐과 마찬가지로 규칙 기반 빌드 접근법을 사용함.

- 즉, 규칙을 따라 프로젝트 구조(디렉터리 구조)를 만들면 빌드 스크립트 내용을 크게 줄일 수 있음.

- 또한, 규칙을 벗어난다 해도 필요에 따라 스크립트를 추가할 수 있어서 유연하게 대응할 수 있음.

- 이런 이유로 그레이들에 익숙해지기 전까지는 규칙에 기반한 디렉터리 구조를 사용하고, 어느 정도 익숙해진 후에 프로젝트 상황에 맞게 디렉터리 구조나 빌드 순서를 변경하는 것이 좋음.

- 또한, 그레이들은 JVM 언어인 그루비로 구축되어 있어 그루비의 장점을 그대로 활용할 수 있음.

- 그루비 문법은 자바와 거의 같아서 자바 엔지니어라면 특별한 노력을 들이지 않고도 쉽게 익힐 수 있음.

- 그뿐만 아니라 그루비에는 리스트 리터럴(list literal)/맵 리터럴(map literal)/클로저(closure) 등 자바에는 없는 편리한 기능이 있어서 빌드 스크립트를 간단하게 작성할 수 있게 해줌.

 

cf) 클로저는 자바 8에 추가된 기능인 람다(Lamda)와 비슷하지만, 람다와 비교해서 기능 제한이 적음. 또한 자바 7 이전 환경에서도 사용할 수 있음.

 

- 그레이들은 단순히 그루비 문법만 이용하는 것이 아니라 빌드 스크립트를 간략하게 해주는 자체 문법(DSL)도 제공함.

- DSL은 그루비가 제공하는 동적 타이핑(dynamic typing) 기능을 이용해서 구현되었으며, 빌드 스크립트 작성에 특화된 전용 언어(빌드 언어) 런타임을 제공함.

- 앤트나 메이븐은 이러한 빌드 언어 대신 XML을 사용함. 하지만, XML은 원래 범용 문서 형식이라 언어 처리 기능은 없음. 따라서 조건 분기나 반복 기능을 구현하려면 앤트와 메이븐에서 구조를 바꿔서 직접 해당 기능을 만들어야 함.

- 반면, 그레이들의 DSL은 그루비로 구촉되어 있어서 그루비가 제공하는 언어 기능을 그대로 이용할 수 있음.

- 게다가 그루비는 자바 클래슬르 직접 호출할 수 있으므로 빌드 스크립트에서 자바 유틸리티도 쉽게 사용할 수 있음.

 

cf) 애당초 XML은 정적 데이터 구조를 표현하는 것이 주요 목적이므로 빌드 스크립트 같이 처리 순서를 표현하기에는 적합하지 않음. 순서를 표현하려면 스크립트 언어가 적합함.

 

- 물론 그루비는 자바 가상 머신(JVM)만 있으면 동작하므로 특정 플랫폼에 의존하지 않는 빌드 스크립트를 작성할 수 있음.

-> 메이크에서는 구현이 어려웠던 크로스 플랫폼 대응이 가능해진 것.

-> 예) 개발 환경은 윈도와 맥이고, CI(Continuous Integration, 지속적 통합) 서버는 리눅스를 사용하는 환경을 구축할 수도 있음.

 

(2) 빌드 순서를 제어하기 쉬움.

- '대부분의 프로젝트에 적용할 수 있는 표준 빌드 순서(메이븐 용어로 설명하면 빌드 생명 주기 단위로 정의된 단계별 실행 순서)', '메타 데이터를 이용한 의존관계 해결'과 이를 실현하기 위한 아이디어로 POM(Project Object Model)을 도입한 점이 메이븐의 위대한 업적으로 평가됨.

- 하지만 메이븐의 빌드 순서는 추가나 변경이 불가능해서 메이븐의 빌드 순서에 맞지 않는 프로젝트에는 적용할 수가 없음. (빌드 스크립트 단순화 전략에 따라 불필요한 기능을 제거했기 때문.)

- 그레이들은 메이븐처럼 빌드 순서가 정해져 있지 않음.

- 그레이들의 빌드 순서는 테스크(빌드 순서의 각 단계) 의존관계에 따라 정해짐.

- 그레이들의 처음 상태에서는 태스크 의존관계가 정의되어 있지 않음.

- 사용자가 빌드 스크립트에 태스크 의존관계를 정의하면 이에 따라 빌드 순서가 정해짐.

- 하지만 이것만으로 앤트의 문제였던 '빌드 스크립트의 복잡성'을 해결할 수 없음.

- 대신 플러그인을 사용해서 태스크 의존관계의 기본 구성을 할 수 있음.

- 이 의존관계는 어디까지나 기본 구성이므로 얼마든지 빌드 순서를 재정의해서 바꿀 수 있음.

- 이처럼 그레이들은 변경 가능한 기본 빌드 순서를 제공함으로써 메이븐과 앤트의 중간에 해당하는 접근법을 사용함.

 

(3)멀티 프로젝트에 대응함.

- 프로젝트 규모가 어느 정도 커져서 여러 개발 팀이 작업을 분담해야 할 상황이 되면 보통 한 프로젝트를 서브 프로젝트로 나눔.

- 하지만, 이때 문제가 되는 것은 서브 프로젝트 간 의존관계나 서브 프로젝트들의 공통 빌드 설정을 어떻게 효율적으로 관리하는냐임.

- 그레이들은 이런 상황에서 특히 힘을 발휘함. 구체적으로는 다음과 같은 기능을 통해서 서브 프로젝트로 구성된 전체 프로젝트의 빌드를 지원함.

 

1. 멀티 프로젝트에 있는 서브 프로젝트를 정의하는 기능

2. 서브 프로젝트에 공통 빌드 스크립트를 집약하는 기능

3. 서브 프로젝트 간 의존관계를 정의하는 기능

4. 의존관계를 고려해서 변경 내역만 빌드하는 기능

 

- 위에 나열한 기능들만 보면 다소 어려워 보일 수 도 있지만, 실제로 빌드 스크립트는 매우 간단함.

- 멀티 프로젝트 지원 기능에 매력을 느껴서 그레이들을 이용하는 사용자도 많으며, O/R 매버 하이버네이트의 빌드 툴을 그레이들로 변경하는 이유도 멀티 프로젝트 지원 기능이 우수하기 때문이었다고 함.

 

(4) 컴포넌트로 만들기 쉬움.

- 빌드 스크립트도 프로그램의 일종이므로 '공통 기능을 컴포넌트로 만들어서 재사용하고 싶다'는 요구가 있을 수 있음.

- 하지만 컴포넌트로 만드는 데 힘을 많이 쏟다 보면 거기에 들어가는 비용이 재사용으로 인한 효율성에 미치지 못할 때도 있음.

- 또한, 컴포넌트로 만들기 위한 구조가 심하게 복잡하다면 작업 의욕이 떨어질 수도 있음.

- 그레이들은 쉽게 사용할 수 있는 것부터 컴포넌트로 제대로 만들어서 공개 저장소에 등록할 수준의 것까지 유연하게 대응할 수 있는 컴포넌트 구조를 제공함. 구체적인 내용은 다음과 같음.

 

1. 빌드 스크립트에서 메서드나 클래스 추출

2. 빌드 스크립트의 분할과 재사용(apply from 이용)

3. 프로젝트에서만 사용할 수 있는 확장 모듈(buildSrc 프로젝트)

4. 여러 프로젝트에서 범용적으로 재사용할 수 있는 라이브러리

 

- 플러그인을 개발하려면 어느 정도 지식과 노력이 필요하지만, 빌드 스크립트의 공통 처리를 추출해서 메서드나 클래스로 만든느 정도라면 그렇게 어렵지 않음.

- 그레이들의 장점은 이렇게 컴포넌트화 수준을 단계적으로 향상할 수 있다는 것.

 

(5) 별도로 설치할 필요가 없음.

- 앤트나 메이븐을 사용하려면 빌드 스크립트 배포뿐만 아니라 사용자 환경에 앤트나 메이븐을 설치해야 하는 불편함이 있음.

- 이것은 사용자에게 부담을 줄 수도 있고, 관리 측면에서도 바람직하지 못함.

- 예를 들어 사용자가 다른 버전의 메이븐을 설치해버리면 'A의 PC에서는 빌드가 성공하지만, B의 PC에서는 실패하는' 문제가 생길 수도 있음.

- 이와 같은 문제에 대처하기 위해 그레이들은 그레이들 래퍼(wrapper)라는 구조를 제공함.

- 그레이들 래퍼는 프로젝트 안에 그레이들의 부트스트랩(bootstrap)을 심어서 지정한 버전의 그레이들을 자동으로 설치해주는 기능임.

- 사용법은 간단함. 그레이들의 래퍼 태스클르 실행해서 부트스트랩을 생성하기만 하면 됨.

- 그것을 그대로 서브버전(Subversion)이나 깃(Git)과 같은 버전 관리 시스템에 등록해두면, 사용자는 버전 관리 시스템에서 프로젝트를 체크아웃(checkout)하기만 하면 됨.

- 체크아웃한 후에 gradlew 명령을 실행하면 그레이들의 바이너리가 다운로드되면서 빌드가 실해됨.

- 바이너리 다운로드 위치는 부트스트랩 안에서 지정할 수 있으므로 사내 공유 파일 서버에 그레이들 바이너리를 배치해두고 자동으로 지정한 버전의 그레이들을 사용할 수 있도록 설정할 수 있음.

- 또한, 그레이들 래퍼는 젠킨스(Jenkins) 같은 CI 서버에서 빌드할 때도 편리하게 사용할 수 있음.

- CI 서버에 자바가 있다면 버전 고나리 시스템에서 파일을 체크아웃해서 gradlew 명령을 실행하면 됨.

- 별도의 빌드 툴을 도입할 필요가 없음.

- 특히, 분산 빌드처럼 불특정 다수의 장비에서 빌드할 때 매우 유용함.

- 최근에 나오는 빌드 툴 역시 이러한 그레이들 래퍼의 우수성을 취하여 설치 없이 사용할 수 있도록 하는 추세임.

 

(6) 호환성을 최대한 배려함.

- 그레이들은 비교적 최신 툴로, 최근에도 신기능이 계속 추가되고 있으며 개발이 활발하게 진행되고 있음.

- 물론 신기능 추가나 버그 수정을 요구하는 사용자도 있지만, 반대로 안정적인 환경을 요구하는 사용자도 있음.

- 이와 같은 상반된 요구에 대응하기 위해 그레이들은 다음과 같은 방침을 세움.

 

1. 기존 기능을 갑자기 사용할 수 없게 되는 변경은 하지 않음.

2. 기능을 제거해야 한다면 장래에 폐지될 가능성이 있음을 명시하고 단계적으로 제거함.

3. 신기능은 피드백을 충분히 받아서 안정화한 후에 추가함.

 

- 그리고 위의 방침을 실현하기 위해 다음과 같이 단계적으로 기능을 추가함.

 

1. 비공개(Internal)

: 그레이들의 내부적으로 이용하는 기능. 사용자 가이드 DSL 매뉴얼이나 API 매뉴얼에 기재하지 않음. 예고 없이 변경될 가능성이 있으므로 사용자가 직접 이용하는 것은 권장하지 않음. 단, 특정 기능은 비공개(Internal)에서 공개(Public)로 전환될 수도 있음.

 

2. 실험(Incubating)

: 신기능을 빨리 사용해보고 싶은 사용자에게 기회를 주기 위해서 초기 단계에서 제공하는 기능. 신기능 추가는 이 상태에서부터 시작되며, 기존 기능과의 통합, 이전 버전과의 호환성에 관련된 의견을 받음. 이 단계의 기능들은 그레이들의 버전이 업그레이드될 때 변경될 수 있음. 변경 사항은 릴리스 노트에 기재됨. 이 단계에 머무르는 기간은 정해져 있지 않으며, 코드에는 @Incubating으로 표시하고 사용자 가이드에는 '이 기능은 실험 상태에 있다'고 기재함.

 

3. 공개(Public)

: 기능의 기본 상태. 비공개(Internal)도 아니고 실험(Incubating) 상태도 아닌 기능이 해당됨. 사용자 가이드, DSL 매뉴얼, API 매뉴얼과 같은 문서에 실험(Incubating) 또는 폐지(Deprecated)라고 표기되어 있지 않은 모든 상태. 실험 상태에서 공개 상태로 변경되면 릴리스 노트에 기재됨. 이 단계의 기능은 제거되거나 변경되지 않으며 제거될 때는 일단 '폐지'상태로 변경함. 또한, 변경 시에는 하위 호환성 정책을 따름.

 

4. 폐지(Deprecated)

: 그레이들의 버전이 업그레이드되면서 필요 없어진 기능이나 신기능으로 대체된 기능은 폐지 상태로 변경한 후 단계적으로 제거함. 폐지 상태로 변경된 기능은 사용을 자제해야 함. 코드에는 @Deprecated로 표시되며, 이 기능을 사용하면 그레이들 실행 시 경고가 발생함. 폐지된 기능은 릴리스 노트에 기재되며, 대부분 대체 기능도 함께 병기됨.

 

- 그레이들의 하위 호환성 정책

 

1. 그레이들은 주요 버전 업그레이드(예를 들어 1.X에서 2.X로)에서도 하위 호환성을 유지하도록 노력한다.

2. 공개(Public) 상태의 가능은 명시적으로 폐지(Deprecated) 상태로 변경하기 전에는 제거되지 않는다.

3. 폐지(Deprecated) 상태로 변경된 기능은 다음 주요 버전 업그레이드 때 제거된다. (제거되지 않고 남아있는 경우도 있지만, 남는다는 보장이 없으므로 빠른 시간 내에 대체 기능을 도입하는 것이 좋다.)

 

내용 출처 : Gradle 철저입문 (와타비키 타쿠마 외 지음, 길벗)