[Gradle] implementation과 api, compile의 차이에 대해

오늘은 Gradle에서 사용하는 implementation과 api, 그리고 compile에 대해 알아보겠다!

 

implementation과 api, compile

build.gradle에서 사용하는 implementation과 api는 모두 라이브러리를 적용시키는 키워드이다. 오래된 Gradle 버전에는 implementation이 없어서 compile을 사용했고, 새로운 버전에서 compile이 deprecated 되면서 compile 대신에 api 키워드가 사용되게 되었다. 이 때문에 오래된 프로젝트들의 build.gradle 파일들을 보면 api와 compile을 implementation 대신 쓰는 것을 볼 수 있다.

 

즉, api와 compile은 같은 역할을 한다. 하지만 Gradle은 api나 compile을 사용하는 것을 권장하지 않는다. api를 통해 라이브러리를 가져올 경우 라이브러리가 적용되는 범위 때문이다. (compile은 작성 시점의 Gradle version에서는 사용 가능하지만 deprecated 되었으므로 차후 버전에서 제거될 것이다.)

 

api, compile의 라이브러리 적용 범위

모듈에서 api나 compile을 사용해 라이브러리를 가져오게 되면, 해당 라이브러리는 해당 모듈을 의존하는 모듈에도 가져와진다,

예를 들어 ModuleA에서 api를 사용해 Library를 가져온 다음 ModuleB에서 api를 이용해 ModuleA를 가져올 경우 Library도 같이 가져와진다.

 

api의 동작

 

이것은 프로그램 유지보수성 측면에서 매우 좋지 않다. Module을 사용할 때는 Module의 인터페이스만이 외부에 노출되어야 하는데, Library의 인터페이스까지 같이 노출되기 때문이다.

 

특히 클린아키텍처적인 측면에서 Entity 모듈은 비즈니스 로직을 만드는 어플리케이션의 Usecase 모듈에서만 사용되고, Usecase 모듈은 Controller에서 Entity 모듈을 알게 된다면 모듈 계층을 건너뛴 참조가 일어날 수 있게 되어 레이어를 나눈 이유가 없어지게 된다.

 

따라서 이를 해결하기 위해 한 모듈에서 사용하는 라이브러리는 그 모듈에서만 사용될 수 있도록 implementation을 쓰는게 좋다.

 

implementation의 적용 범위

모듈에서 implementation을  사용해 가져오는 라이브러리는 해당 모듈을 의존하는 모듈에는 가져와지지 않는다. 예를 들어 ModuleA에서 implementaion을 이용해 Library를 가져온 다음 ModuleB에서 implementation을 사용해 ModuleA를 가져오면 Library는 가져와지지 않는다. Library는 ModuleA에 캡슐화되어 ModuleB에 노출되지 않는다.

 

implementation의 동작

 

이 방식을 이용하면 모듈 수준에서 공개되는 코드를 모듈의 인터페이스로 제한할 수 있어 모듈간의 의존성을 줄이게 된다. 프로그래밍 유지보수의 핵심은 모듈 간 의존성을 줄이는 것이 1순위이다. 수많은 라이브러리들이 범람하고, 하나의 프로그램에 코드가 수십만 줄이 넘어가는 시점에 모듈 간 의존성을 줄여야 프로그램을 유지보수하기 편해지기 때문이다.

 

따라서 api를 사용하기보단 implementation을 사용하는게 좋다!

 

출처

https://kotlinworld.com/317

[Gradle] implementation과 api, compile의 차이는 무엇인가?