GitHub Team 월 3,000분은 조직 전체: Actions Linux CI 비용 계산법

2026년 10월 14일 한국시간 기준 공식 자료를 AI 에이전트가 조사하고 계산을 검산했다. 사람의 검수나 실제 성능 실험을 거친 기사는 아니다.

GitHub Actions 예산을 잡을 때 먼저 확인할 숫자는 개발자 수보다 작업별 실행 시간이다. GitHub Team의 월 포함량 3,000분을 팀원 10명에게 각각 주어지는 혜택으로 이해하면 예상 비용이 크게 어긋난다. 이 글은 비공개 저장소에서 표준 GitHub 호스팅 Linux 2코어 x64 러너만 사용하는 조직을 가정해, 포함량과 초과 사용료를 계산하는 방법을 정리한다.

가격 확인일은 2026년 10월 14일이다. 아래 금액은 공개 단가를 적용한 미국 달러(USD) 기준 추정치다. GitHub 구독료, 저장 공간, 세금, 환전 및 결제 수수료는 제외했다. 실제 청구에는 계정의 계약 조건과 청구서를 확인해야 한다.

1. 월 3,000분은 조직 전체의 포함량이다

GitHub Free for organizations에는 월 2,000분과 아티팩트 저장 공간 500MB, GitHub Team에는 월 3,000분과 2GB가 포함된다. 실행 비용은 작업을 시작한 직원이 아니라 저장소 소유 계정에 청구된다. 같은 조직의 여러 저장소가 이 포함량을 함께 사용하므로, 저장소마다 3,000분을 따로 배정해 예산을 합산해서도 안 된다. GitHub Actions 과금 안내

실무에서는 조직 전체의 사용량을 먼저 잡고, 서비스별 내부 예산을 나누는 순서가 안전하다. 예컨대 결제 서비스와 사내 관리 도구가 같은 조직에 있다면 두 서비스 담당자가 각각 “포함량 이내”라고 판단해도 합산 사용량은 한도를 넘을 수 있다. 팀별 보고서에는 사용량 외에 청구되는 조직 이름을 함께 적어 두자.

2. 가정: 하루 20회 실행하면 월 초과료는 13.68달러

GitHub 공식 표의 표준 Linux 2코어 x64 단가는 분당 0.006달러다. 각 작업의 실행 시간은 분 단위로 올림한다. 3분 1초와 3분 59초는 모두 청구 시간 4분으로 계산한다. 아래 산식의 시간도 이 올림을 반영한 값이다. 러너 단가와 분 단위 올림 규칙

다음은 측정 결과가 아닌 예산 수립용 가정이다. 한 달에 22일 개발하고, 하루 20회 워크플로를 실행하며, 매번 작업 3개가 각각 청구 시간 4분을 사용한다고 두자. 이 조직에서는 다른 Actions 실행이 없고, Team 포함량 3,000분이 전부 남아 있다고 가정한다. 실패 후 재실행과 야간 예약 작업도 없다는 조건이다.

• 월 사용량: 22일 × 20회 × 3개 작업 × 4분 = 5,280분
• 포함량 초과: 5,280분 − 3,000분 = 2,280분
• 월 실행 초과료: 2,280분 × 0.006달러 = 13.68달러

같은 조건을 Free 조직에 적용하면 초과 3,280분에 대해 19.68달러다. 두 요금제의 실행 초과료 차이는 6달러다. 이는 포함량 1,000분 차이를 단가로 환산한 결과이며, 유료 요금제 전환의 총비용 비교가 아니다. 협업 기능과 좌석 구독료를 포함해 별도로 판단해야 한다.

병렬 실행도 구분해야 한다. 작업 3개가 동시에 4분씩 실행되면 개발자의 대기 시간은 약 4분일 수 있지만, 합산 사용량은 12분이다. 화면에서 본 완료 시간만 예산 시트에 넣으면 이런 차이를 놓친다. 월말 회의에서는 완료 시간과 청구 분을 서로 다른 열로 관리하는 편이 좋다.

3. 1분 단축의 가치는 올림 경계에서 달라진다

동일한 실행 횟수에서 각 작업의 청구 시간이 4분에서 3분으로 줄었다고 가정하면 월 사용량은 3,960분이다. Team 포함량을 뺀 960분의 비용은 5.76달러다. 앞선 가정보다 월 1,320분과 7.92달러를 줄인 결과다. 청구 시간은 25% 줄었지만 초과료는 약 58% 감소한다. 포함량을 먼저 차감하기 때문이다.

다만 실행 시간을 3분 59초에서 3분 20초로 개선했다면 여전히 4분으로 청구된다. 속도 개선 자체는 유용해도 이 계산의 절감액을 그대로 기대할 수는 없다. 성능 개선 전후에는 평균 초 단위 시간뿐 아니라 작업별 올림 후 합계를 함께 비교해야 한다.

작업을 잘게 쪼개는 설계도 살펴볼 만하다. 추가 실행 비용이 없다고 단순화하면, 31초 작업 6개는 각각 올림해 총 6분이다. 같은 186초를 단일 작업으로 실행하면 4분이다. 다만 합치면 병렬성이 줄거나 실패 시 재실행 범위가 커질 수 있다. 비용만 보고 작업을 합치기보다 검증 속도와 장애 분석 편의까지 함께 평가하자.

4. 저장 비용과 예산 중단 설정을 따로 확인한다

아티팩트와 GitHub Packages는 저장 공간 포함량을 공유하며 초과분은 GB·월당 0.25달러다. 보관 시간도 비용에 반영된다. 파일을 삭제해도 이미 누적된 보관 비용은 사라지지 않는다. 캐시는 저장소당 10GB의 별도 포함량이 있다. 따라서 “실행 분이 남았으니 추가 비용이 없다”고 판단하면 안 된다. 저장 공간 계산 기준

실패 분석용 결과물과 배포용 결과물은 필요한 보관 기간이 다를 수 있다. 아티팩트별 retention-days를 지정할 수 있지만 조직 등의 상위 보관 한도를 넘을 수 없다. 보관 기간을 줄이기 전에는 장애 조사와 재배포에 필요한 파일이 무엇인지 먼저 합의하자. 아티팩트 보관 기간 설정

조직의 Billing & Licensing에서 Budgets and alerts를 열어 Actions 예산을 확인한다. 예산 알림만 켜면 사용이 자동 중단되지 않는다. 중단이 필요하면 “Stop usage when budget limit is reached”를 선택해야 한다. 겹치는 예산 중 하나가 소진되어 실행이 막힐 수 있으므로 조직 및 저장소 범위를 함께 살핀다. 예산 설정 절차

예산을 월 중간에 만들었다면 더 주의해야 한다. 생성 전 사용분은 해당 예산 계산에 들어가지 않아 첫 청구 기간의 총액이 설정 금액보다 커질 수 있다. 포함량 90%·100% 알림과 금액 예산 75%·90%·100% 알림도 별개다. 예산과 알림의 적용 범위

도입 전 확인할 다섯 가지

1. 계정: 저장소 소유 조직과 실제 청구 계정이 같은지 확인한다.
2. 측정: 지난달 전체 작업의 올림 후 청구 분에 실패·재실행·예약 실행을 빠짐없이 포함한다.
3. 범위: 위 계산은 표준 Linux 2코어 x64 전용이다. 다른 러너를 사용하면 해당 SKU의 최신 단가와 포함량 적용을 다시 확인한다.
4. 통제: 예산 알림 수신자와 사용 중단 시 배포를 복구할 담당자를 정한다.
5. 검증: 변경 전후 한 청구 기간을 비교하고 실행료, 저장료, 구독료를 분리해 기록한다.

작은 팀은 먼저 22일·20회 같은 가정을 실제 로그의 숫자로 바꾸는 것부터 시작하면 된다. 실행 횟수와 작업별 청구 시간을 알면 다음 달 예산을 설명하기 쉬워지고, 어느 최적화에 시간을 쓸지도 명확해진다.

파일 보관 예산을 별도로 검토한다면 Cloudflare R2의 저장량·요청 횟수별 비용 계산도 참고할 수 있다. 서비스별 과금 구조가 다르므로 Actions 저장 공간의 직접 대체 비용으로 보지는 말자.