프로젝트 배포3- CI부분에 캐싱 적용

목차

1.도입 배경

2.문제 분석

3.캐시 적용

4.느낀점

 

1.도입 배경

CI/CD 파이프라인을 GitHub Actions로 구성한 이후, 커밋이나 PR마다 평균 2~3분의 빌드 시간이 소요되는 문제가 있었습니다.
현재 프로젝트는 멀티모듈 Gradle 기반으로 구성되어 있으며, 외부 의존성도 많아 빌드 성능의 손실이 반복되고 있었습니다.

단순한 변경 사항이나 테스트 커밋임에도 매번 전체 빌드를 새로 수행해야 했고, 이로 인해 개발 흐름이 끊기거나 PR 리뷰 속도가 느려지는 병목이 발생했습니다.

운영 환경 배포를 자동화하기 위해 CI를 구성했지만, 오히려 개발 속도를 방해하는 상황이 생긴 것입니다.

2.문제 분석

GitHub Actions는 매 빌드마다 새로운 VM 환경에서 실행되기 때문에, 기존에 다운로드된 의존성 파일(~/.gradle/caches)이나 빌드 결과물(~/.gradle/wrapper)이 전혀 남지 않습니다. 이로 인해 매번 다음과 같은 비효율이 발생했습니다:

• 매 PR마다 ./gradlew build를 처음부터 실행
• 매번 모든 의존성 JAR을 재다운로드 (~/.gradle/caches 없음)
• 모듈 변경이 없어도 전체 서브모듈을 재컴파일
• 결국 개발 속도보다 CI 속도가 병목이 되는 아이러니한 상황

빌드 시간이 길어지니 PR 단위 테스트/리뷰도 지연되고, 배포 주기도 자연스럽게 느려지는 악순환이 반복되었습니다.

 

3.캐시 적용

이 문제를 해결하기 위해 **GitHub Actions의 actions/cache@v3**를 활용하여 Gradle 캐시를 복원하도록 구성했습니다.
핵심은 ~/.gradle/caches, ~/.gradle/wrapper 경로를 캐싱하고, build.gradle, gradle-wrapper.properties의 변경 시점에만 캐시를 갱신하는 방식입니다.

- name: Cache Gradle dependencies
  uses: actions/cache@v3
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: gradle-${{ hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') }}
    restore-keys: |
      gradle-

 

이 캐시 설정을 GitHub Actions 워크플로우에서 checkout 이후, gradlew 실행 전에 추가하였습니다. 캐시를 적용을 하게 되면 GithubActions에서 아래와 같이 캐싱이 된것을 볼 수가 있습니다. 

 

적용 이후 빌드시 캐시가 적중할 경우(Cache restored from key:), 의존성 다운로드 및 빌드 시간이 현저히 줄어들며, 다음과 같은 결과를 확인할 수 있었습니다.

 

캐시를 적용하기 전의 빌드시간 : 2분 41초

캐시 적용후의 빌드시간 : 2분 2초, 1분 47초

 

약 빌드시간이 29%정도 단축이 된 것을 알 수 있습니다.

4.느낀점

CI/CD는 단순히 “자동화”를 넘어서 개발 사이클을 전체적으로 최적화하는 핵심 도구임을 다시 한 번 체감했습니다. 특히 반복되는 커밋, 작은 변경 사항에서 항상 전체 빌드가 수행되는 구조는 명백한 병목이 될 수 있습니다. Gradle 캐싱은 도입이 어렵지 않았지만, 그 효과는 분명했습니다. 빌드 속도 병목 없이 빠르게 테스트하고, 배포할 수 있는 기반이 마련되었습니다. 이후 계획 중인 Slack 알림 연동, MDC 기반 Kafka/스케줄러 로깅 등을 안정적으로 구축할 수 있는 기반이 함께 마련되었습니다.

작은 최적화 하나가, 전체 개발 리듬과 생산성을 끌어올릴 수 있다는 걸 경험하게 된 좋은 계기였습니다.