gradle에서 api와 implementation 차이

올해 초에 인턴 면접 보면서 받았던 질문 중 기억에 남는 질문이다.

“compile과 implementation의 차이를 설명해주세요”

 

생각해보지도 않은 질문이라 답변하지 못했고, 아쉬움이 많이 남았다.

kts가 요즘 디폴트로 주어지기도 하니 kts 기준으로 글을 작성하도록 하겠다. 이번 주제에서 groovy와 큰 차이는 없다.

api & implementation 구분하기

dependencies {
    api("org.apache.httpcomponents:httpclient:4.5.7")
    implementation("org.apache.commons:commons-lang3:3.5")
    compile("org.apache.httpcomponents:httpclient:4.5.7") // deprecated
}

 

외부 api 라이브러리를 사용할 때는 dependeny에 추가를 해줘야한다. compile로 하는 방법도 있었으나 이 방법은 7.0 이상부터는 deprecated되고 그때 대체된게 api 키워드이므로 이번 글에서는 api와 implementation만 다루도록 하겠다. api는 compile의 대체제로, compile로 선언된 모든 라이브러리를 api로 교체해서 사용할 수 있다.

 

아래 그림은 Java Library Plugin을 사용할 때의 구성도인데,

초록색 박스들은 사용자가 라이브러리 사용을 위해 선언해야하는 것들이고, 파란색 박스는 내부 컴포넌트에서 사용할 때 선언하는 것, 핑크색 박스는 구성요소들이 컴파일되거나 라이브러리가 실행중일 때 사용되는 구성설정이다. 화살표 방향을 보면 알 수 있듯이 api가 가장 최상위 레벨이고, implementation이 api를 받아서 사용하는 것을 알 수 있다.

 

클래스패스가 파란색으로 표현되어있는데, 자바파일을 컴파일하면 바이트 코드가 만들어지고, 이걸 실행할 때 각각 특정 경로에서 클래스 파일과 패키지를 탐색하게 되는데 이게 compileClasspath, runtimeClasspath다.

 

그림을 보면 api, implementation 모두 컴파일, 런타임 경로 모두 설정하는 것을 알 수 있다. 이제 api와 implementation을 살펴보자.

class A{
  fun main(){
    val b = B();
  }
}

class B {
  fun foo(): Int{
    return C().bar();
  }
}

class C {
  fun bar(): Int{
    return 10;
  }
}

 

A가 사용자의 클래스다. 외부 라이브러리인 B클래스를 사용자가 사용하려고 하는데, B에서는 C의 메서드를 사용한다. C까지 연결된 걸 전이 의존성(transitive dependency)이라고 한다.

graph LR
A-->B
B-->C

사용자가 쓸 것은 B이기 때문에, 컴파일 시 필요한 의존성이 A, B 이고 런타임 때는 B가 호출하는 C도 가져와야하니 A, B, C가 런타임 때 필요한 의존성이다. 사용자가 B 라이브러리를 implementation으로 선언했다면 compile 컴파일 시 C를 알 필요가 없고, C에 변화가 생겨도 사용자는 신경 쓸 필요가 없다.

정확히 얘기하면 implementaion이 전이 의존성을 허락하지않기 때문에 사용자가 C의 메서드를 직접 사용할 수 없다. 반면 api로 선언했다면 implementation보다 넓은 범위를 담당하기 때문에 컴파일 때 C도 들어가게 된다. 이러면 컴파일 시 사용자가 C의 존재를 알 수 있고 C가 수정이 된다면 사용자가 이 사실을 알기 때문에 사용자 쪽에서도 재컴파일이 필요하다.

 

주목해야될 부분은 재컴파일이다. 위 예시처럼 간단한 의존관계의 경우에는 크게 상관없을 수 있지만, 멀티모듈과 같이 여러 곳에서 각각의 라이브러리를 따로따로 사용하게 되는 경우를 가정해보자.

graph LR
A-->B
D-->B
E-->B
B-->C
G-->V

 

B를 사용하는 A, D, E가 있는데, A에서 사용하는 B메서드가 C에 존재한다. C에 있는 메서드(여기서는 bar메서드) 가 수정되었을 때 api로 라이브러리를 추가했다고 가정하면 A, D, E 모두 재컴파일이 필요한 상황이 된다. 또 C의 classpath를 컴파일 경로에 다 노출시키기 때문에 컴파일 속도가 느려지고, 앞서 말했듯 재컴파일이 필요한 경우도 있기 때문에 전체적인 컴파일시간이 늘어나게 되는 단점이 생긴다. 디자인패턴 측면으로 접근하면 단일책임원칙(Single Responsibility)에 어긋난다고 볼 수 있겠다.

 

이를 통해 알 수 있는건 되도록 implementation으로 라이브러리를 추가해야하고, api를 사용할 경우 최대한 약한 결합을 하게 유도해야한다는 것이다. api를 사용하려면 전역에 영향을 미치는 라이브러리나, 부모클래스나 인터페이스에 해당하는 라이브러리에 사용하는 것이 효율적이게 쓰는 방법이다.

 

멀티모듈, MVVM, MVC 와 같은 패턴의 존재이유와 비슷하다고 생각한다.

참조:

https://docs.gradle.org/current/userguide/java_library_plugin.html

https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:what-are-dependency-configurations

"댓글, 공감 버튼 한 번씩 누르고 가주시면 큰 힘이 됩니다"