GitHub Actions 요금 계산법: 러너 실행 시간·아티팩트 저장 비용 줄이기 (2026년)

GitHub Actions 요금 계산법의 핵심은 작업별 올림된 러너 시간과 무료 실행량, 초과 저장공간을 따로 계산하는 것이다. 월말 청구액만 보면 어떤 워크플로가 비용을 만들었는지 찾기 어렵지만, 운영체제별 단가와 아티팩트 보존 기간을 나누어 보면 절감 지점이 선명해진다.

이 글은 단계별 계산과 설정 방법을 찾는 탐색형 검색 의도에 맞춰 구성했다. 2026년 GitHub 공식 과금 문서의 수치를 기준으로 동일 작업의 Linux·Windows·macOS 비용, 실패 후 재실행 비용, 아티팩트 보관일 변경 효과와 예산 설정 순서를 차례로 살펴본다.

GitHub Actions 무료 실행 시간과 과금 범위 확인하기

먼저 저장소 공개 여부를 구분해야 한다. GitHub 공식 문서에 따르면 공개 저장소에서 사용하는 표준 GitHub 호스티드 러너와 셀프 호스티드 러너는 무료다. 다만 CPU·메모리 사양이 높은 대형 러너는 공개 저장소에서도 항상 비용이 발생하므로, 공개 프로젝트라는 이유만으로 모든 실행이 무료라고 판단하면 안 된다.

비공개 저장소에는 계정 요금제별 월간 무료 실행량이 적용된다. 무료분은 매월 주어지지만 사용하지 않은 시간을 다음 달로 넘겨 쓸 수 있는 예산처럼 보면 곤란하다. 조직 안에 저장소가 여러 개라면 개별 저장소가 아니라 청구 주체 전체의 사용량을 함께 점검해야 비용 급증을 놓치지 않는다.

기본 산식은 월 청구 대상 실행량 = 전체 청구 분 − 적용 가능한 무료분이다. 이후 청구 대상 분에 사용한 러너의 분당 단가를 곱한다. 여러 운영체제를 함께 썼다면 전체 시간을 하나로 합쳐 계산하지 말고 러너 종류별 사용량과 단가를 각각 적용해야 한다.

GitHub Actions 요금제별 무료 실행량과 최신 과금 기준 실시간 확인하기

운영체제별 GitHub Actions 러너 비용 계산 예제

2026년 기준 표준 러너 단가는 Linux 1코어가 분당 0.002달러, Linux 2코어 x64가 0.006달러, Linux Arm64가 0.005달러다. Windows는 0.010달러, macOS는 0.062달러다. 같은 테스트라도 운영체제 선택에 따라 비용 격차가 크게 벌어진다.

특히 GitHub Actions는 작업별 부분 분을 1분으로 올림한다. 하나의 작업이 8분 24초 실행됐다면 계산에는 8.4분이 아니라 9분이 반영된다. 병렬 매트릭스로 작업 네 개를 실행했다면 각 작업을 따로 올림하기 때문에 총 청구 시간은 최대 36분이 된다.

표의 계산은 8분 24초짜리 동일 작업이 작업별로 9분 청구되고 한 달에 100회 실행된 상황이다. 총 900분에 각 단가를 곱했으며, 무료분이나 세금은 차감하지 않은 순수 사용액이다. Linux 2코어에서는 5.40달러지만 macOS에서는 55.80달러로 약 10.3배가 된다.

플랫폼 호환성 검증이 필요한 프로젝트라면 macOS와 Windows 작업 자체를 없애기보다 실행 조건을 좁히는 편이 안전하다. Linux 테스트는 모든 푸시에서 돌리고, 운영체제 매트릭스는 병합 요청이나 릴리스 후보에서만 실행하는 방식이 대표적이다.

운영체제별 GitHub Actions 러너 비용 계산 예제 실시간 확인하기

실패한 워크플로 재실행 비용과 낭비 분 찾기

실패한 실행도 무료로 되돌아가지 않는다. Linux 2코어 작업이 11분 12초에 실패하면 12분이 청구되고, 수정 후 8분 24초 만에 성공하면 다시 9분이 계산된다. 결과적으로 한 번의 성공을 얻는 데 21분, 즉 0.126달러가 들며 처음부터 성공했을 때의 0.054달러보다 0.072달러가 더 발생한다.

한 번의 차이는 작아 보여도 하루 100개 브랜치에서 반복되면 추가 비용은 하루 7.20달러다. 같은 커밋에 연속 푸시가 들어오는 개발 환경에서는 이전 실행이 끝날 때까지 기다리는 동안 새 실행이 계속 쌓이는 문제도 흔하다.

낭비 분을 줄이는 순서는 다음과 같다.

1. 변경 파일 경로와 브랜치 조건을 설정해 관련 없는 워크플로 실행을 막는다.
2. 빠른 정적 검사와 단위 테스트를 앞에 두고, 느린 빌드·배포는 선행 검사가 성공했을 때만 실행한다.
3. 의존성 캐시를 사용해 패키지 다운로드와 설치 시간을 줄인다.
4. concurrency 그룹에 cancel-in-progress: true를 적용해 같은 그룹의 낡은 실행을 취소한다.
5. 행이 바뀐 매트릭스 작업은 꼭 필요한 운영체제와 런타임 버전만 남긴다.

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

실패한 워크플로 재실행 비용과 낭비 분 찾기 바로가기

아티팩트·캐시 GB-Hours 저장 비용 계산법

GitHub의 저장량은 월말 파일 크기만 보는 방식이 아니다. 저장된 용량을 매시간 GB-Hours로 누적한 뒤 해당 월의 전체 시간 수로 나누어 GB-Months를 계산한다. 30일인 달에는 720시간이므로, 10GB를 360시간 보관했다면 3,600GB-Hours ÷ 720시간 = 5GB-Months다.

무료 제공량을 넘은 아티팩트와 GitHub Packages 공유 저장공간은 월 GB당 0.25달러다. Actions 캐시와 사용자 지정 이미지는 각각 월 GB당 0.07달러다. 따라서 위의 5GB-Months가 모두 초과분이라면 아티팩트는 1.25달러, 캐시는 0.35달러가 된다.

삭제 시점도 중요하다. 저장량은 파일이 존재했던 매시간 이미 누적되므로 오늘 삭제하더라도 지난주에 기록된 GB-Hours가 소급 차감되지는 않는다. 비용 절감 효과는 삭제 이후 시간부터 나타난다.

보존 기간 90일과 30일의 월 예상액 비교

매일 1GB의 빌드 아티팩트를 만들고 지속적으로 운영해 보존량이 안정된 상황을 가정해 보자. 90일 보존 시 약 90GB, 30일 보존 시 약 30GB가 유지된다. 모든 용량이 무료 한도를 넘는다는 단순 조건에서는 월 예상액이 각각 22.50달러와 7.50달러로, 보존 기간을 줄이면 매월 약 15달러를 절약할 수 있다.

아티팩트와 로그의 기본 보존 기간은 90일이다. 공개 저장소는 1~90일, 비공개·내부 저장소는 1~400일 범위에서 조정할 수 있다. 단기 테스트 결과라면 워크플로의 업로드 단계에 retention-days를 지정하고, 규정상 장기 보관해야 하는 릴리스 산출물만 별도 정책을 적용하는 편이 효율적이다.

- uses: actions/upload-artifact@v4
  with:
    name: test-report
    path: reports/
    retention-days: 14

보존 기간을 90일에서 14일로 바꿔도 이미 저장된 아티팩트의 과거 사용량이 사라지는 것은 아니다. 새 정책이 적용된 이후 생성되거나 만료되는 데이터부터 월별 비용 곡선이 점진적으로 낮아진다는 점을 예상액에 반영해야 한다.

아티팩트·캐시 GB-Hours 저장 비용 계산법 신청하기

예제 워크플로 실행 후 Billing 사용량 확인 절차

비용 계산이 맞는지 확인하려면 작은 예제 실행을 만든 뒤 GitHub의 Billing 화면에서 반영된 사용량과 대조하는 과정이 필요하다. 개인 계정에서 결제한다면 개인 설정을, 조직이 결제한다면 해당 조직의 설정을 열어야 한다. 메뉴 명칭은 계정 유형과 GitHub 화면 개편에 따라 조금 다를 수 있지만 일반적으로 Settings → Billing and licensing에서 사용량과 예산 항목을 찾을 수 있다.

1. Actions 탭에서 실행할 워크플로와 선택된 러너 운영체제를 확인한다.
2. 워크플로를 한 번 실행하고 각 작업의 시작·종료 시간 및 성공 여부를 기록한다.
3. 부분 분을 작업별로 올림해 Linux·Windows·macOS별 예상 청구 분을 계산한다.
4. 개인 또는 조직의 Billing and licensing 화면에서 Actions 사용량을 확인한다.
5. 사용량 반영에 시간이 걸릴 수 있으므로 실행 직후 값이 없으면 일정 시간이 지난 뒤 다시 조회한다.
6. 무료분 적용 전 계산값, 청구 대상 사용량, 실제 금액을 비교해 오차 원인을 찾는다.

예를 들어 Linux 2코어에서 8분 24초가 기록됐다면 예상 사용량은 9분이고 원가는 0.054달러다. 다만 해당 계정에 무료 실행량이 남아 있다면 청구액은 0달러로 보일 수 있다. 사용량과 실제 결제액이 같지 않은 이유가 바로 무료분, 공개 저장소 조건, 청구 주체 차이에 있기 때문이다.

저장 비용은 아티팩트 크기와 생성 시각, 삭제 시각을 함께 기록해 검증한다. 단순히 현재 저장된 GB만 비교하면 이미 누적된 GB-Hours를 설명할 수 없다. GitHub Packages를 함께 사용한다면 아티팩트와 공유되는 저장공간 범위도 같이 확인해야 한다.

GitHub Billing 화면에서 Actions 사용량과 저장공간 조회하기

GitHub Actions 예산 한도 설정과 2026년 비용 절감 체크리스트

예산은 지난 2~3개월의 정상 사용량을 기준선으로 잡고, 릴리스나 긴급 수정에 필요한 여유를 더해 설정하는 방식이 현실적이다. Billing and licensing의 예산 관리 영역에서 Actions 대상 예산을 만들고, 적용할 조직이나 저장소 범위를 선택한 뒤 월 한도와 알림 수신 대상을 지정한다. 한도 도달 시 사용 중지 옵션이 표시된다면 배포 중단 위험을 검토한 뒤 선택해야 하며, 알림만 설정했는지 실제 사용 제한까지 설정했는지도 구분해야 한다.

실무에서는 총액 하나보다 경고 구간을 나누는 편이 빠른 대응에 도움이 된다. 월 예산의 절반 수준에서는 증가 추세를 점검하고, 75~90% 구간에서는 비정상 재실행과 대형 러너 사용을 확인한다. 한도 직전에는 필수 배포가 중단되지 않도록 담당자와 대응 규칙을 미리 정해 두는 것이 좋다.

• 공개 저장소에서도 대형 러너가 사용되고 있지 않은지 확인한다.
• 작업마다 부분 분이 올림되므로 지나치게 잘게 쪼갠 짧은 작업을 점검한다.
• macOS·Windows 테스트를 모든 푸시가 아닌 필요한 이벤트에만 실행한다.
• 의존성 캐시의 저장비와 절감된 러너 시간을 함께 계산한다.
• 동일 브랜치의 오래된 실행은 cancel-in-progress로 취소한다.
• 테스트 아티팩트에는 짧은 retention-days를 적용한다.
• 러너 분과 GB-Hours를 매월 같은 날짜에 기록해 일시적 증가와 구조적 증가를 구분한다.

전문가 관점에서 가장 큰 절감 효과는 가장 싼 러너를 무조건 고르는 데서 나오지 않는다. 변경과 무관한 실행, 이미 낡아진 커밋의 실행, 실패가 예상되는 느린 단계를 먼저 제거해야 한다. 그다음 Linux 전환과 캐시 최적화, 보존 기간 단축을 적용해야 품질 저하 없이 비용을 낮출 수 있다.

또한 저장비와 실행비는 서로 영향을 준다. 캐시를 과도하게 줄이면 월 GB당 0.07달러를 아끼는 대신 매 실행마다 의존성을 다시 내려받아 분당 0.006달러 이상의 러너 시간이 늘 수 있다. 2026년의 합리적인 운영 기준은 저장공간 자체가 아니라 성공한 빌드 한 건당 총비용을 측정하는 것이다.

GitHub Actions 예산 한도 설정과 2026년 비용 절감 … 지원하기