이동식 저장소

안드로이드에서는 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으로만 구성한다.

더 읽어보기