Home Gradle 의존성 땡기는 방법 2가지 비교 (api, implementation)
Post
Cancel

Gradle 의존성 땡기는 방법 2가지 비교 (api, implementation)

Gradle이 대세인 요즘 라이브러리 의존성을 땡겨받는 방법 중 크게 두 가지가 있다.

  • api(의존성 어쩌구 저쩌구)
  • implementation(의존성 어쩌구 저쩌구)

두 방식의 차이점은 의존성 연쇄에 대한 것에 있다.

api 구문

api 구문은 의존성이 연쇄되어 의존성이 끊어지지 않고 이어진다는 것이다. 예를 들자면 아래와 같다.

  • A프로젝트 build.gradle에서 api(B프로젝트)구문을 사용했다.
  • B프로젝트 build.gradle에서 api(C프로젝트) 혹은 implementation(C프로젝트)구문을 사용했다.

이렇게 셋팅하면 A프로젝트에서 C프로젝트의 객체를 사용할 수 있다. A프로젝트가 직접 땡겨받고있는 B프로젝트가 C프로젝트를 땡겨받았고 이 의존성이 이어진 것이다.

implementation 구문

api 구문은 의존성이 연쇄되지 않는다. 위의 예시와 똑같은 상황에서 api구문만 implementation으로 바꾼 아래 상황을 예시로 한다.

  • A프로젝트 build.gradle에서 implementation(B프로젝트)구문을 사용했다.
  • B프로젝트 build.gradle에서 implementation(C프로젝트)구문을 사용했다.

A프로젝트에서 C프로젝트의 객체를 사용하고자하면 컴파일 에러가 발생한다. A프로젝트는 B프로젝트만을 땡겨받겠다고 implementation으로 선언했기때문이다.


api 구문을 사용하면 뭔가 나중에 쓸 기능에 대한 대비를 하여 확장성도 있어보이고 편리해보인다. 하지만 이 방식에는 단점이 있어 사용 시 권장되는 사항은 아니다.

api 구문을 사용하면 C프로젝트에서 변경이 일어날 때 A프로젝트도 새롭게 빌드해야한다.

당연하게도 의존성이 이어져있기 때문에 받고 있기 때문에 나는 C프로젝트만 변경했는데 총 3개의 프로젝트를 새롭게 빌드해야하는 상황이 온다.

빌드 시간이 증가할 뿐만 아니라 모듈 간 의존성이 강하게 엮여있기 때문에 관리에 복잡함이 추가될 수도 있다.

이러한 이유로 api구문을 최대한 지양하자는 내용이 많다.

This post is licensed under CC BY 4.0 by the author.