GitHub Actions 비용 줄이기: 실행 시간·캐시·artifact 점검

AI Editter

GitHub Actions 비용이 늘었을 때 캐시를 전부 지우면 다음 빌드가 더 느려져 실행 비용이 늘 수 있습니다. 먼저 runner 실행 시간, artifact 보관, cache 보관을 분리해야 합니다. 같은 저장소라도 어떤 항목이 청구를 만드는지에 따라 줄이는 방법이 다릅니다.

2026년 10월 확인한 GitHub 문서는 artifact와 cache의 저장 허용량을 별도로 설명합니다. “캐시는 항상 무료”나 “공개 저장소면 모든 runner가 무료”라는 전제로 계산하지 마세요. 플랜과 runner 종류, 설정된 저장 한도에 따라 달라집니다. 현재 조건은 GitHub Actions 과금 문서에서 확인해야 합니다.

1. 저장소 설정보다 계정의 청구 내역을 먼저 본다

저장소 소유자 계정이나 조직의 Billing & licensing에서 Actions 사용량을 확인합니다. 실행한 사람의 개인 계정이 아니라 저장소를 소유한 계정에 비용이 귀속되는 상황을 구분하세요. 조회 기간을 고정하고 runner·storage 항목을 나눠 봅니다.

예를 들어 하루 20회 생성하는 300MB artifact를 30일 보관하면, 중간 삭제가 없을 때 보관량은 약 180GB까지 쌓일 수 있습니다. 이는 구조를 설명하는 단순 예시이며 실제 요금은 시간별 저장 사용량과 포함량을 반영합니다. 파일을 오늘 지웠다고 이전에 누적된 저장 사용량이 사라지는 것도 아닙니다.

2. 같은 변경을 여러 번 빌드하는지 찾는다

Actions 탭에서 같은 커밋이 push와 pull_request 양쪽으로 실행되는지, 문서만 바꿨는데 모든 플랫폼 테스트가 도는지 확인합니다. 실행이 중복이라고 보이더라도 서로 다른 보안 조건이나 필수 상태 검사를 담당할 수 있으므로 트리거를 지우기 전에 브랜치 보호와 연결을 봅니다.

이전 커밋의 CI 결과가 더는 필요 없는 PR 테스트라면 concurrency를 검토할 수 있습니다. 아래는 워크플로 수준의 설정 예시입니다.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

같은 그룹에서 새 실행이 들어오면 진행 중인 실행을 취소하도록 하는 구성입니다. concurrency 동작을 확인하고 CI에 적용하세요. 운영 배포·DB 마이그레이션처럼 중간 취소가 위험한 작업에는 같은 설정을 그대로 쓰지 않습니다.

3. timeout과 matrix를 실행 기록으로 정한다

정상적으로 6분 걸리는 테스트가 외부 서비스 장애 때 수십 분 대기한다면 job의 timeout-minutes를 설정할 근거가 있습니다. 최근 정상 실행의 상위 지연 구간과 캐시 미스 시 시간을 보고 여유를 정하세요. 아래의 15분은 예시이며 무조건 짧게 만드는 것이 목적은 아닙니다.

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      # 기존 checkout, 설치, 테스트 단계를 이 위치에 유지

matrix는 OS·런타임 버전을 곱하면 job 수가 빠르게 늘어납니다. PR에서는 대표 조합으로 빠르게 검증하고 전체 조합은 정기 검증에 두는 설계가 가능한지 검토합니다. 단, 지원을 약속한 조합을 검증하지 않은 채 비용만 줄여서는 안 됩니다. required check가 사라져 병합이 막히지 않는지도 작은 PR로 시험합니다.

4. 캐시는 hit율, artifact는 보관 목적을 본다

의존성 캐시 키에 매 실행의 고유 번호를 넣으면 대부분 다시 사용할 수 없는 캐시가 생깁니다. OS·런타임·lockfile 해시처럼 재사용 가능성을 판단하는 값이 적절한지 검토하세요. restore 단계가 성공했는지뿐 아니라 설치 시간이 실제로 줄었는지도 비교해야 합니다. 캐시 안에 토큰이나 비밀 설정 파일을 넣지 않습니다.

artifact는 실패한 테스트의 진단 자료, 릴리스 산출물, 임시 결과를 구분합니다. 임시 테스트 결과에 짧은 retention-days를 지정하고 릴리스는 별도 보존 정책을 두세요. 전체 작업 디렉터리를 올리면 의존성 폴더와 캐시까지 중복 보관될 수 있습니다. 업로드 범위를 결과 파일로 좁히는 것이 보관 기간만 줄이는 것보다 효과적일 수 있습니다. 사용 중인 action의 옵션은 upload-artifact 공식 저장소에서 확인합니다.

5. 비용을 줄인 뒤 배포 성공률까지 비교한다

변경 전후 1주 단위로 실행 횟수, 총 runner 시간, 실패 후 재실행 횟수, artifact·cache 용량을 비교합니다. 캐시를 줄여 저장량은 감소했지만 설치 시간이 크게 늘었다면 전체 비용을 다시 계산해야 합니다. 더 큰 runner도 분당 단가와 완료 시간, 대기 시간까지 함께 비교해야 합니다.

예산 알림과 사용 제한은 별도 기능입니다. 현재 청구 설정에서 초과 시 알림만 오는지 실행을 막는지 확인하세요. self-hosted runner를 검토한다면 머신 비용·패치·격리·운영 부담을 포함해야 합니다. 청구서의 Actions 항목이 줄었다는 사실만으로 총 운영비가 줄었다고 판단할 수는 없습니다.