[Spring boot] compile과 implementation

build.gradle에서 compile과 implementation은 모두 의존성을 선언하는 데 사용되지만, 둘 사이에는 중요한 차이가 있습니다. Gradle 7.0부터는 compile이 deprecated(사용 중지)되었고, 대신 implementation과 api로 대체되었습니다.

 

1. compile vs implementation의 차이

compile

• 예전 방식: compile은 이전 Gradle 버전에서 의존성을 선언할 때 사용되던 기본 방식입니다. 이 방식으로 선언된 의존성은 컴파일 시간과 런타임 시간 모두에서 프로젝트에 포함됩니다.
• 특징:
  • 해당 의존성은 compile에 의해 컴파일 시점과 실행 시점 모두에서 사용할 수 있습니다.
  • compile 의존성은 해당 프로젝트를 사용하는 다른 프로젝트에 전이적(Transitive) 으로 포함됩니다. 즉, 다른 프로젝트에서도 이 의존성을 사용할 수 있게 됩니다.

implementation

• 새로운 방식: Gradle 7.0부터 implementation이 권장되는 방식입니다. implementation으로 선언된 의존성은 컴파일 시간에는 포함되지만, 전이적 의존성으로 다른 프로젝트에 포함되지 않습니다. 즉, 해당 의존성은 해당 프로젝트에서만 사용됩니다.
• 특징:
  • implementation으로 선언된 의존성은 다른 프로젝트에서 직접 사용할 수 없으며, 컴파일 시에만 사용되고 런타임 시에는 해당 프로젝트 내에서만 접근 가능합니다.
  • compile보다 성능 상 장점이 있습니다. 왜냐하면 implementation은 다른 프로젝트에 불필요한 의존성을 노출시키지 않기 때문에 의존성 트리가 더 깔끔하고, 빌드 성능이 개선됩니다.

 

2. Gradle 7.0부터 compile을 사용하지 않는 이유

성능 최적화:

Gradle 7.0부터 compile을 사용하지 않는 이유는 빌드 성능을 향상시키기 위해서입니다. compile을 사용하면 의존성이 전이되기 때문에 빌드 시 불필요한 의존성까지 포함되어 프로젝트의 의존성 트리가 복잡해지고, 빌드 시간이 길어집니다.

명확한 의존성 분리:

implementation을 사용하면 의존성을 프로젝트 내부에서만 사용할 수 있게 하여, 다른 프로젝트에서 의존성을 실수로 사용하지 않도록 방지할 수 있습니다. api와 implementation의 구분을 통해 의존성의 공개 여부를 명확히 할 수 있습니다.

코드의 캡슐화:

implementation을 사용하면 의존성을 내부적으로 캡슐화할 수 있습니다. 즉, 다른 프로젝트에서 해당 의존성의 내부 구현을 알 필요가 없게 되어, 더 강한 정보 은닉이 가능해집니다. 이로 인해 모듈화된 아키텍처를 유지하고, 나중에 라이브러리를 변경하더라도 의존성을 사용하는 프로젝트에 미치는 영향을 줄일 수 있습니다.

 

 

3. compile이 deprecated된 이유

• compile은 의존성의 전이성을 강제로 허용하며, 이를 통해 불필요한 의존성까지 포함될 수 있습니다. 예를 들어, compile을 사용하면 해당 라이브러리가 다른 프로젝트에서 사용될 때도 자동으로 의존성에 포함되지만, 이것이 성능과 유지보수의 어려움을 유발할 수 있습니다.
• Gradle 팀은 의존성 관리를 더 세밀하게 하고, 프로젝트의 의존성 트리를 깔끔하게 유지하기 위해 compile을 implementation과 api로 나누었으며, compile은 deprecated 처리하여 더 이상 사용하지 않도록 권장하고 있습니다.