출처 - gemini (조금 이상하네;)
우선 implementation하고 api란 무엇일까?
안드로이드를 개발하다보면 의존성을 넣어본 경험은 다들 있을 것이다.
주로 외부 라이브러리인 Retrofit, naviation, hilt등을 사용하기 위해 사용할 것이다.
또 멀티모듈인 경우에는 다른 모듈의 의존성을 추가하여 사용을 하기도 한다.
그때 사용하는게 implementation과 api이다.
하지만 이 둘은 다른 기능을 한다. 그래서 잘 알고 사용하는 게 중요하다.
하나씩 알아보자.
implementation
우선 가장 흔하고 자주 봤던 것일 것이다.
안드로이드 공식문서의 설명에 따르면
Gradle이 컴파일 클래스 경로에 종속 항목을 추가하고 빌드 출력에 종속 항목을 패키징합니다. 모듈이 implementation 종속성을 구성한다면 이는 Gradle에게 컴파일 타임에 다른 모듈로 종속성이 유출되면 안 된다고 알려주는 것입니다. 즉, 종속 항목은 현재 모듈에 종속된 다른 모듈에서 사용할 수 없습니다.
라고 기재되어 있다.
즉, implementation으로 라이브러리를 추가하면 현재 모듈에서만 사용할 수 있고 현재 모듈을 의존하고 있는 다른 모듈들은 해당 라이브러리를 사용할 수 없다는 뜻이다.
글로만 적으면 이해가 잘 안갈 것이다. 사진과 같이 보면 이해하기 쉬울 것이다.
사진을 보면,
Module A는 implementation으로 Module B를 의존하고 있고
Module B는 implementation으로 Retrofit을 의존하고 있다.
Module A에선 Retrofit을 사용할 수 없다.
왜냐하면 Module A는 Module B의 의존성만 가지고 있지 Module B에 추가되어있는 Retrofit의 의존성이 없기 때문이다. 그래서 Module A에서 Retrofit을 사용하기 위해서는 직접 implementation을 해줘야 될 것이다.
이건 어떻게 보면 당연한 결과이다. 그럼 멀티 모듈을 사용하는 프로젝트에선 공통된 dependency를 매번 추가하는 경우가 빈번할 것이다. 이걸 해결하기 위해선 어떻게 해야될까?
api
위에 말한 고충을 해결하기 위해선 api를 사용하면 쉬워진다.
알아보기전에 먼저 안드로이드 공식문서에 어떻게 기재되어있는지 확인해보자.
Gradle은 컴파일 클래스 경로와 빌드 출력에 종속 항목을 추가합니다. 모듈에 api 종속 항목이 포함되면 모듈이 다른 모듈로 종속 항목을 이전하여 다른 모듈에서 런타임과 컴파일 시간에 사용할 수 있도록 한다는 것을 Gradle에 알려주는 것입니다.
이 말은 즉, implementation 대신 api사용하여 라이브러리 또는 모듈의 의존성을 추가하면 해당 모듈을 의존하고 있는 다른 모듈도 해당 라이브러리 또는 모듈을 사용할 수 있다는 뜻이다.
이것 또한 사진하고 같이 보자!
Module A는 Module B를 implementation을 사용하고 있고
Module B는 Retrofit을 api를 사용하여 의존성을 추가하였다.
그럼 Module A는 Retrofit을 사용할 수 있을까? 없을까?
정답은 사용할 수 있다! 왜냐하면 Module B가 api를 사용하여 Retrofit의 의존성을 추가했기 때문에 Module B를 의존하고 있는 다른 Module도 Retrofit을 의존하게 된다.
그래서 멀티모듈에서 api를 잘만 쓴다면 의존 그래프를 엄청 간단하게 만들 수 있다. 하지만 그에따른 부작용도 있다.
implementation vs api 그래서 뭘쓰라고?
또 나온 안드로이드 공식문서를 보면 각 설명 뒤에 부연설명이 적어져 있다.
먼저 api의 부연설명을 보면
이 구성은 주의해서 사용해야 하며 다른 업스트림 소비자에게 전이하여 내보내야 하는 종속성에만 사용해야 합니다. api 종속성이 외부 API를 변경하면 Gradle은 컴파일 시간에 해당 종속성에 액세스할 수 있는 모든 모듈을 다시 컴파일합니다. api 종속 항목 수가 많으면 빌드 시간이 크게 증가할 수 있습니다. 종속 항목의 API를 별도의 모듈에 노출하지 않으려면 라이브러리 모듈에서 implementation 종속 항목을 대신 사용해야 합니다.
우선 첫줄이 주의사항이다.. 이 뜻은 권장하지 않는 다는 의미인 것 같다.
물론 의존성 그래프가 단순화되는 건 맞지만 그만큼 잘못 사용하게 되면 사용하지도 않는 라이브러리의 의존성을 가지게 될 수 있어 빌드시간이 크게 증가하는 경우가 발생할 수도 있기때문이다.
또한 의존성을 찾기 위해 거슬러 올라가야되는 문제가 발생할 수도 있어 유지보수하기 매우 안좋을 것 같다.
그 다음 implementation의 부연설명을 보면
api 대신 이 종속 항목 구성을 사용하면 빌드 시스템에서 다시 컴파일해야 하는 모듈 수가 줄어들기 때문에 빌드 시간이 크게 개선될 수 있습니다. 예를 들어 implementation 종속 항목이 API를 변경하면 Gradle은 이 종속 항목과 이에 직접적으로 종속된 모듈만 다시 컴파일합니다. 대부분의 앱과 테스트 모듈은 이 구성을 사용해야 합니다.
implementation을 사용하면 최소한의 의존성만 가지게 되기 때문에 빌드시간이 단축될 수 있다. 그리고 현재 모듈의 의존성을 보기 쉽게 확인할 수 있어 유지보수하기엔 implementation을 사용하는 게 유리해보인다.
결론
implementation을 주로 사용하는 게 좋아보이고
멀티 모듈인 경우에는 api를 조심스럽게 사용해도 되나, 유지보수를 위하여 주석을 통해 설명을 추가하는 것이 좋아보인다.
