Gradle은 Groovy를 활용한 빌드 자동화 시스템입니다.
최근 신규 프로젝트는 대부분 Gradle로 빌드를 관리하며, 이제 Maven은 레거시 프로젝트에서나 볼 수 있습니다.

Gradle Java Plugin

Gradle에서 자바 프로젝트를 구성할 때, 플러그인을 선택할 수 있습니다.
보통 Java Plugin을 기반으로 확장된 Java Library Plugin이나 Application Plugin을 사용합니다.

Java Plugin은 프로젝트에 자바 컴파일과 테스트 및 번들링 기능을 추가합니다.
JVM 프로젝트 작업을 위한 기본 빌드 설정을 담당하며, 보통 프로젝트에 직접 적용하지는 않습니다.

Java Library Plugin은 Java Plugin의 기능을 확장한 플러그인입니다.
아래 문서에서 자세한 내용을 확인할 수 있습니다.

Java Plugin
Java Library Plugin
Building Java Projects

Gradle 의존성 설정

Gradle에서 필요한 라이브러리의 의존성을 추가하는 다양한 방법이 있습니다.
참고로 예전에 사용하던 compile, runtime은 Gradle 7.0 이후로 사용이 중지됐습니다.

• implementation
  • 클래스 경로에 추가되며, 종속 항목을 사용하는 프로젝트에 전달하지 않습니다.
• api
  • 클래스 경로에 추가되며, 종속 항목을 사용하는 프로젝트에 전달합니다.
• runtimeOnly
  • 런타임에만 필요하며, 컴파일 클래스 경로에 포함되지 않습니다.
• compileOnly
  • 컴파일에만 필요하며, 런타임 클래스 경로에 포함되지 않습니다.
• compileOnlyApi
  • 컴파일에만 필요하며 런타임 클래스 경로에 포함되지 않고, 종속 항목을 사용하는 프로젝트에 전달합니다.
• testImplementation
  • 테스트에 필요한 종속성을 선언하며, 종속 항목을 사용하는 프로젝트 전달하지 않습니다.
• testCompileOnly
  • 테스트 컴파일에 필요하며, 런타임 시점에는 포함되지 않습니다.
• testRuntimeOnly
  • 테스트 런타임에 필요하며, 컴파일 시점에는 포함되지 않습니다.

dependencies {
    implementation 'org.example:example-library:1.0'
    runtimeOnly 'org.example:example-runtime-library:1.0'
}

Java Library Plugin 구성과 테스트 구성입니다.

아래 문서에서 자세한 내용을 확인할 수 있습니다.

Java Library Separation
Dependency Management for Java Projects

이쯤에서 알아보는 종속성 전이란?

implementation과 api의 차이는 종속성 전이 여부에 있습니다.
종속성 전이란 프로젝트에 설정한 종속성을 다른 프로젝트에 노출하며 사용할 수 있는 기능입니다.

implementation은 종속성 전이를 허용하고 api는 허용하지 않습니다.
예를 들어 3개의 프로젝트 혹은 모듈이 있다고 가정해 보겠습니다.

Module A → Module B → Module C

만약 implementation으로 종속성을 선언하면 Module A는 Module B의 종속성만 사용할 수 있습니다.
Module C의 종속성은 접근할 수 없습니다.

반면 api로 종속성을 선언하면 Module A는 Module B 뿐 아니라, Module C에도 접근이 가능합니다.

그럼에도 종속성 전이를 사용하지 않아야 하는 이유

이렇게 편한데 왜 종속성 전이를 사용하지 않아야 한다고 할까요?
사실 무조건 종속성 전이 기능을 사용하면 안돼! 라는 건 없습니다.

종속성 전이가 프로젝트에서 효율적이고 안정성이 보장된다면 써도 됩니다.
그럼에도 프로젝트에서 종속성 전이는 사용을 지양하는 편이 좋습니다.

종속성 전이를 사용하지 않을 때 몇 가지 이점입니다.

- 종속성 전이는 코드 실수를 유발합니다. 그래서 의도치 않은 기능 오류를 방지할 수 있습니다.
- 클래스 경로 크기가 줄어서 컴파일 속도가 빨라 집니다.
- 종속성 변경에 따른 재컴파일이 줄어듭니다. 전이된 종속성 개수가 줄기 때문입니다.
- 프로젝트의 종속성 구조가 명확해 집니다.

그럼 api 기능은 왜 만든거야?

위에서 이야기 했지만 프로젝트에서 효율적이고 안정성이 보장되는 상황이 있습니다.
주로 퍼블릭으로 사용할 때 유용합니다.

• 외부 모듈이나 프로젝트에서 사용해야 하는 경우
• 슈퍼클래스나 인터페이스에 사용
• 퍼블릭 메서드나 필드에 사용
• 퍼블릭 어노테이션 사용

반대로 implementation을 사용해야 하는 경우입니다.

• 모듈이나 프로젝트 내부에서만 사용하는 경우
• 내부 클래스에서만 사용
• 메서드 본문에서만 사용
• 개인 멤버에서만 사용

implementation과 api 사용에 대한 정리

정답은 없습니다.
프로젝트 구조와 라이브러리의 기능에 맞게 사용하는 게 베스트입니다.

일단 implementation을 기본 옵션으로 사용해야 합니다.
그리고 공통으로 사용되는 라이브러리에 한정해서 api를 사용합니다.

거기에 조금 더 세분화해서 runtimeOnly와 compileOnly를 적절하게 사용하면 됩니다.