implementation vs. api

안드로이드에서는 ``build.gradle``의 ``dependencies`` 블럭 안에 의존성을 추가할 수 있다. 보통 ``implementation``을 사용하여 의존성을 구성한다.

implementation 'androidx.compose.material3:material3:1.4.3'

이번 글에서는 ``implementation``의 정확한 의미를 알아보고, 또다른 구성 방법인 ``api``에 대해서도 알아보겠다.

implementation

의존성을 compile classpath에 추가하고, build output에도 포함한다. 하지만 다른 모듈에서 ``implementation``으로 구성한 의존성을 컴파일 시간에 참조할 수는 없다. 컴파일 시간이라는 말이 어렵다면 코드를 작성할 때라고 이해해도 된다. 즉 코드를 작성하고 컴파일할 때 참조할 수는 없다는 것이다.

 

당연히 런타임 시간에는 다른 라이브러리도 해당 의존성이 존재함을 인지할 수 있다. 예를 들어 모듈 A가 의존성 b를 ``implementation``으로 구성했고, app 모듈에서 A를 ``implementation``했다고 하자. app 모듈은 컴파일 시간에는 b의 존재를 알 수 없다. 하지만 런타임 시간에는 A의 빌드 결과물에 b가 포함되므로 자연스럽게 b의 존재를 알게 된다. 물론 app에서 A에 포함된 b를 참조할 방법은 없다. app에서 b를 직접 구성하지 않는 한.

 

아래에서 살펴볼 ``api`` 대비 빌드 성능이 월등히 좋다(significant improvements). 그 이유는 다시 컴파일하는 모듈의 수가 크게 적기 때문이다. 예를 들어 특정 모듈의 external API가 바뀌었다면, Gradle은 해당 모듈과 그 모듈에에 직접 의존하는 모듈만 다시 컴파일한다. External API는 외부에서 참조할 수 있는 모든 클래스와 함수, 패키지를 의미한다. 위의 예시에서 의존성 b의 API가 바뀌었다면, b와 A만 다시 컴파일되고 app은 컴파일되지 않는다. 

 

특별한 이유가 없다면 ``implementation``을 사용해야 한다. 원문에서는 이렇게 표현하고 있다.

Most app and test modules should use this configuration.

api

의존성을 compile classpath와 build output에 포함하며, 이 모듈을 참조하는 상위 모듈에서도 해당 의존성을 컴파일 시간에 참조할 수 있다. 위의 예시에서 b를 ``api``로 구성한다면 app 모듈에서도 b를 직접 참조할 수 있다.

 

그럼 ``implementation``보다 좋은 거 아니냐고 할 수도 있는데, 빌드 시간이 늘어날 수 있기 때문에 주의해서 사용해야 한다(you should use it with caution). 해당 의존성을 상위 모듈에 노출해야 할 이유가 있을 때에만 사용해야 한다. 그 이유는 ``api``로 구성한 의존성의 external API가 바뀌면, 해당 모듈을 참조하는 모든 모듈이 다시 컴파일되기 때문이다. 

 

해당 의존성을 상위 모듈에 노출해야 하는 경우에만 ``api``를 사용하고, 그 외의 일반적인 경우에는 ``implementation``을 사용하자. 나는 보통 앱에서 정의한 모듈(core, feature 등)만 ``api``로 구성하고, 외부 라이브러리는 거의 ``implementation``으로만 구성한다.

더 읽어보기

Add build dependencies  |  Android Studio  |  Android Developers