GitLab CI/CD 비용 2026, compute minutes·러너·스토리지 운영 기준
GitLab CI/CD 비용을 줄이려는 팀은 보통 월 구독료부터 보지만 실제 청구와 운영 부담은 pipeline이 어떤 runner에서 몇 초 동안 돌았는지에서 갈립니다.
Free와 Premium의 plan 차이만 보고 판단하면 large runner, scheduled pipeline, artifact 보관, cache miss, self-managed runner 운영비가 빠집니다.
이 글은 GitLab 공식 pricing과 compute minutes 문서를 기준으로 DevOps 팀이 이번 달 CI 비용을 설명할 때 쓸 점검 순서를 정리합니다.
- GitLab.com pricing 기준 Free는 $0/user/month, Premium은 $29/user/month billed annually, Ultimate는 custom pricing으로 표시됩니다.
- GitLab.com plan별 compute minutes는 Free 400, Premium 10,000, Ultimate 50,000 minutes per month로 제시됩니다.
- Compute minute 사용량은 job duration / 60 × runner cost factor이며 Linux small은 1, medium은 2, large는 3, xlarge는 6, 2xlarge는 12입니다.
- Artifacts는 기본 30일 만료와 latest artifact 보존 정책이 있고, cache는 job당 최대 4개와 fallback key 최대 5개 기준을 운영표에 넣어야 합니다.
이 글이 필요한 사람
- GitLab CI/CD 비용이 늘었지만 namespace, project, pipeline, runner별 원인을 나누지 못한 플랫폼 담당자.
- GitLab-hosted runner와 self-managed runner 중 어느 쪽이 실제 총비용에 맞는지 비교해야 하는 DevOps 리드.
- Premium 또는 Ultimate 전환 전에 compute minutes, storage, GitLab Duo credits, 보안 기능 범위를 같이 봐야 하는 구매 담당자.
- scheduled pipeline, nightly E2E, large runner 사용이 많아 월별 quota 초과를 반복하는 개발 조직.
- cloud deploy job에서 장기 secret 대신 OIDC id_tokens를 검토해야 하는 보안팀.
공식 가격표 숫자로 먼저 비용 범위를 잡습니다
GitLab pricing 페이지는 GitLab.com Free를 $0 per user/month, Premium을 $29 per user/month billed annually로 표시합니다.
Ultimate는 custom pricing으로 안내되므로 공개 숫자만으로 enterprise 총액을 단정하면 안 됩니다.
같은 pricing 페이지는 Free에 5 licensed users, 400 compute minutes per month, 10 GiB storage를 표시합니다.
Premium은 unlimited licensed users, 10,000 compute minutes per month, 500 GiB storage를 제시합니다.
Ultimate는 50,000 compute minutes per month, 500 GiB storage, unlimited guest users를 포함한다고 설명합니다.
| 항목 | 공식 숫자 | 예산 해석 | 먼저 볼 질문 |
|---|---|---|---|
| Free | $0/user/month, 5 licensed users, 400 compute minutes/month, 10 GiB storage | 개인·작은 오픈소스·초기 검증에는 충분하지만 조직 CI 기준으로는 quota가 빨리 찰 수 있습니다. | Free namespace가 업무용 pipeline을 떠안고 있지 않은가 |
| Premium | $29/user/month billed annually, 10,000 compute minutes/month, 500 GiB storage | 협업 기능과 더 큰 compute quota가 필요할 때 기준 plan으로 봅니다. | 월 10,000 minutes 안에 merge request와 nightly를 나눌 수 있는가 |
| Ultimate | custom pricing, 50,000 compute minutes/month, 500 GiB storage | 보안·컴플라이언스와 더 큰 quota가 같이 필요한 enterprise 선택지입니다. | 보안 기능 가치와 CI quota를 따로 설명할 수 있는가 |
| GitLab Duo credits | Premium $12 credits/user/month, Ultimate $24 credits/user/month로 표시 | CI 비용과 AI credit은 서로 다른 항목이므로 같은 예산표에서 구분합니다. | Duo 사용량 owner와 platform owner가 분리되어 있는가 |
| Enterprise Agile Planning Seats | $15/user로 표시 | CI/CD 비용과 별도 구매 항목이므로 seat 수를 혼동하지 않습니다. | 개발 seat와 planning seat를 같은 숫자로 잡고 있지 않은가 |
이 조건이면 Premium 전환보다 pipeline 정리가 먼저입니다.
Free quota 400분을 넘는 원인이 중복 pipeline과 scheduled job이라면 plan을 올려도 낭비 구조가 그대로 남습니다.
반대로 보안 dashboard와 compliance 기능까지 필요한 조직은 compute minutes만으로 Ultimate 가치를 평가하면 결론이 왜곡됩니다.
compute minutes 계산식은 runner 선택을 비용으로 바꿉니다
GitLab compute minutes 문서는 job 사용량을 job duration / 60 × cost factor로 계산한다고 설명합니다.
job duration은 created 또는 pending 상태 시간을 제외하고 runner에서 실제 실행된 시간 기준입니다.
pipeline 하나의 compute usage는 실행된 모든 job의 합계이므로 job이 병렬로 돌면 wall-clock 시간보다 사용량이 클 수 있습니다.
| GitLab-hosted runner | cost factor | 10분 job 사용량 | 실무 판단 |
|---|---|---|---|
| Linux x86-64 small | 1 | 10 compute minutes | 대부분 lint와 unit test 기본값으로 둡니다. |
| Linux x86-64 medium | 2 | 20 compute minutes | 빌드 시간이 크게 줄어드는 job만 올립니다. |
| Linux x86-64 large | 3 | 30 compute minutes | 병렬 빌드와 e2e 기준을 측정한 뒤 사용합니다. |
| Linux x86-64 xlarge | 6 | 60 compute minutes | 대기 시간을 줄여도 월 quota 영향이 큰 선택입니다. |
| Linux x86-64 2xlarge | 12 | 120 compute minutes | 야간 batch나 release 후보에만 ticket 기준으로 허용합니다. |
| GPU medium | 7 | 70 compute minutes | ML 테스트는 schedule과 sample dataset 기준을 따로 둡니다. |
| macOS M1 medium beta | 6 | 60 compute minutes | 모바일 build job은 cache와 artifact 정책을 먼저 점검합니다. |
| macOS M2 Pro large beta | 12 | 120 compute minutes | 전체 PR 자동 실행보다 release branch 중심으로 제한합니다. |
실무 시나리오 1: mobile-e2e job이 2xlarge에서 45분 돌면 계산식상 540 compute minutes가 됩니다.
이 경우는 job 시간을 20% 줄이는 것보다 실행 조건을 release candidate와 nightly로 제한하는 편이 먼저일 수 있습니다.
실무 시나리오 2: Linux small에서 18분 걸리는 unit test가 medium에서 8분으로 줄면 사용량은 18분에서 16분으로 작게 줄어듭니다.
이 조건이면 medium runner가 개발자 대기 시간을 줄이면서 quota도 조금 줄이는 선택이 될 수 있습니다.
GitLab-hosted runner와 self-managed runner를 총비용으로 비교합니다
GitLab runner 문서는 GitLab-hosted runner가 GitLab이 관리하며 각 job에 fresh VM을 제공한다고 설명합니다.
Self-managed runner는 조직이 직접 설치하고 관리하며 Docker, Shell, Kubernetes 같은 executor를 선택할 수 있습니다.
따라서 GitLab-hosted runner의 비용은 compute quota와 cost factor 중심이고, self-managed runner의 비용은 서버·보안·패치·autoscaling 운영까지 포함됩니다.
| 선택지 | 유리한 조건 | 숨은 비용 | 보안 질문 |
|---|---|---|---|
| GitLab-hosted runner | 표준 Linux build와 빠른 시작이 중요함 | large runner cost factor와 monthly quota 초과 | job별 격리와 shared runner 제한이 업무에 맞는가 |
| Self-managed VM runner | 고정 workload와 private network 접근이 필요함 | VM idle, patch, disk, concurrent job capacity | runner host에 secret과 artifact가 남지 않는가 |
| Self-managed Kubernetes runner | burst workload와 autoscaling이 필요함 | cluster 운영, image pull, node autoscaler, cache backend | namespace 격리와 privileged container 정책이 있는가 |
| Project runner | 민감 project를 좁은 runner에 묶어야 함 | runner 수 증가와 운영 분산 | 다른 project job이 섞이지 않는가 |
| Group runner | 여러 project가 같은 표준 환경을 공유함 | tag 관리와 과밀 queue | 권한 높은 deploy runner가 일반 job을 받지 않는가 |
이 조건이면 self-managed runner를 검토합니다.
빌드가 private network와 내부 package registry에 강하게 묶여 있고 GitLab-hosted runner에서 image pull과 network latency가 반복되는 경우입니다.
이 경우는 보류합니다.
보안 patch, runner token 관리, cache lifecycle, idle VM 비용을 볼 사람이 없으면 GitLab-hosted runner가 더 싼 선택일 수 있습니다.
pipeline efficiency는 시간 절감이 아니라 원인 분류부터 시작합니다
GitLab pipeline efficiency 문서는 job runtime, stage runtime, total pipeline duration, repository size, job 수, dependency, critical path를 bottleneck으로 보라고 설명합니다.
또한 flaky test와 불필요한 실패가 개발 lifecycle을 늦추고 비용 효율에도 영향을 준다고 설명합니다.
그래서 GitLab CI/CD 비용 절감의 첫 작업은 긴 pipeline 삭제가 아니라 실패와 중복을 분류하는 일입니다.
| 비용 신호 | 원인 후보 | 첫 조치 | 중단 기준 |
|---|---|---|---|
| retries 증가 | flaky unit test, 외부 dependency 실패 | 실패 사유 태깅과 quarantine 정책 | 테스트 신뢰도가 떨어져 merge 품질이 낮아짐 |
| scheduled pipeline 증가 | owner 없는 nightly, mirror update pipeline | schedule owner와 주기 재검토 | 보안 scan 같은 필수 batch를 무조건 끊음 |
| critical path 장기화 | stage dependency와 늦은 실패 | needs로 빠른 feedback job 분리 | 병렬화가 runner quota를 더 많이 태움 |
| runner queue 증가 | capacity 부족 또는 tag mismatch | runner tag와 concurrency 점검 | large runner로만 queue를 해결하려 함 |
| storage 증가 | artifact와 cache 보관 정책 부재 | expire_in과 lifecycle rule 적용 | 실패 분석 자료까지 모두 삭제함 |
이 조건이면 rules와 workflow:rules를 먼저 봅니다.
같은 commit에서 push pipeline과 merge request pipeline이 동시에 생기고, 문서 변경에도 full test가 도는 구조입니다.
반대로 결제와 인증 service는 PR마다 heavy test가 필요할 수 있으므로 risk tier별로 다르게 줄여야 합니다.
artifact와 cache는 storage와 minutes를 동시에 흔듭니다
GitLab caching 문서는 cache를 dependency 다운로드 재사용에 쓰고, artifact를 stage 사이의 build output 전달에 쓴다고 구분합니다.
같은 문서는 cache가 job당 최대 4개까지 가능하고, per-cache fallback keys는 최대 5개까지 지원한다고 설명합니다.
Job artifacts 문서는 artifacts expire_in으로 보관 기간을 정할 수 있고, expire_in이 없으면 instance default artifact expiration이 적용된다고 설명합니다.
또한 latest successful pipeline의 artifacts는 ref별로 보관될 수 있으므로 release와 PR artifact 정책을 나눠야 합니다.
| 항목 | 공식 기준 | 비용 영향 | 운영 기준 |
|---|---|---|---|
| cache | job당 최대 4개 cache | dependency 재다운로드 minutes를 줄임 | lockfile 기반 key와 fallback key를 짧게 둡니다. |
| fallback keys | per-cache fallback 최대 5개 | cache miss 때 default cache 탐색이 반복될 수 있음 | default fallback이 매번 큰 archive를 받지 않는지 봅니다. |
| artifact expire_in | artifact별 보관 기간 지정 가능 | build output과 report storage가 누적됨 | PR 실패 자료는 1 week처럼 짧게 둡니다. |
| latest artifacts | 최근 successful pipeline artifact 보관 정책 존재 | release branch가 많으면 보관량이 늘 수 있음 | release와 feature branch 정책을 분리합니다. |
| dependencies와 needs:artifacts | 필요한 job artifact만 가져오도록 제어 가능 | 모든 이전 stage artifact 다운로드로 시간 증가 | test job이 실제 필요한 artifact만 받게 합니다. |
실무 시나리오 3: Node monorepo에서 every branch cache key가 commit SHA를 쓰면 cache hit가 낮아지고 install minutes가 계속 발생합니다.
이 경우는 cache를 없애는 게 아니라 lockfile 기반 key와 default branch fallback으로 바꾸는 것이 먼저입니다.
실무 시나리오 4: E2E screenshot과 trace를 모든 성공 pipeline에 30일 보관하면 storage와 다운로드 시간이 같이 늘어납니다.
이 조건이면 failure-only artifact와 expire_in 1 week 기준을 먼저 적용합니다.
manual job과 protected deploy는 비용·보안 기준으로 같이 봅니다
GitLab job control 문서는 manual job을 when: manual로 만들 수 있고, protected branch와 함께 배포를 더 엄격하게 보호할 수 있다고 설명합니다.
같은 문서는 manual job 실행자가 추가 CI/CD variables를 넣을 수 있고, retry 때도 기존 값을 볼 수 있으므로 민감 값 입력에 주의하라고 설명합니다.
비싼 deploy validation과 production smoke test는 모든 pipeline에서 자동 실행하지 말고 protected branch와 manual approval로 제한하는 편이 안전합니다.
| 통제 장치 | 비용 효과 | 보안 효과 | 주의점 |
|---|---|---|---|
| manual deploy job | release가 아닌 PR에서 비싼 배포를 막음 | 배포 승인자를 명확히 함 | manual variable에 secret을 넣지 않습니다. |
| protected branch | 민감 job 실행 범위를 줄임 | 권한 없는 배포를 막음 | branch policy와 runner tag를 같이 봅니다. |
| blocking manual job | 불필요한 후속 stage 실행을 막음 | 승인 전 production 접근 차단 | merge block 영향과 owner를 문서화합니다. |
| rules | 변경 없는 경로의 job을 만들지 않음 | 외부 MR의 민감 job 실행을 제한 | duplicate pipeline 방지와 함께 설계합니다. |
| workflow:rules | pipeline 자체 생성을 줄임 | 불필요한 trigger 표면 축소 | schedule과 MR 조건을 별도로 검증합니다. |
이 조건이면 manual job은 비용 절감 장치입니다.
release 후보가 아닌 모든 MR에서 staging 배포와 full scan이 자동 실행되는 경우입니다.
이 경우는 manual job만으로 부족합니다.
누가 눌렀는지와 어떤 변수를 넣었는지 감사가 필요하면 protected environment와 권한 정책을 같이 설계해야 합니다.
OIDC id_tokens는 CI 비용보다 사고 비용을 줄입니다
GitLab OIDC 문서는 CI/CD job이 id_tokens로 third-party service와 cloud service에 인증할 수 있다고 설명합니다.
문서는 aud claim으로 token이 인증할 대상 서비스를 제한할 수 있으며, token에는 iss, sub, aud, exp 같은 claim이 포함된다고 설명합니다.
이 기능은 runner minutes를 직접 줄이지 않지만 장기 cloud key를 CI variable에 보관하는 사고 비용을 줄입니다.
| 보안 항목 | 비용과 연결되는 이유 | 실무 기준 | 확인 증거 |
|---|---|---|---|
| id_tokens | 장기 secret rotation과 유출 대응 비용 감소 | cloud deploy job은 OIDC 우선 검토 | aud, sub, protected ref 조건 |
| protected variables | 외부 branch와 MR에서 민감 값 노출 방지 | production 변수는 protected ref에서만 사용 | settings export와 audit event |
| runner isolation | shared runner의 secret 잔존 위험 감소 | 민감 deploy는 dedicated runner 또는 tagged runner | runner tag와 project scope |
| manual variables | 민감 값이 재시도 화면에 보일 수 있음 | manual variable에는 secret 입력 금지 | job control 정책 문서 |
| artifact exclusion | 로그와 report에 key가 섞이는 사고 예방 | secret scanner와 artifact exclude 적용 | artifact sample review |
이 조건이면 비용 최적화 작업을 잠시 멈춥니다.
cloud access key가 masked variable로 오래 남아 있고, fork MR과 deploy job 조건이 분리되지 않은 상태입니다.
보안 사고가 나면 compute minutes 절감보다 secret 회전, 침해 조사, 배포 중단 비용이 훨씬 커집니다.
30일 운영 점검 순서
GitLab CI/CD 비용 최적화는 한 번의 runner 교체가 아니라 월간 운영 루프로 보는 편이 맞습니다.
- 1일차: namespace usage quota에서 compute minutes 사용량과 plan별 quota 대비 소진율을 확인합니다.
- 2일차: project별 pipeline duration, failed job count, retries, scheduled pipeline 목록을 뽑습니다.
- 3일차: runner size와 cost factor 기준으로 상위 compute minutes job 20개를 정렬합니다.
- 1주차: workflow:rules와 rules로 duplicate pipeline, mirror update, 문서 변경 full test를 줄입니다.
- 2주차: cache key, fallback key, artifact expire_in, latest artifacts 정책을 branch 유형별로 고정합니다.
- 3주차: large runner와 macOS runner 사용은 ticket 또는 release 후보 기준으로 제한합니다.
- 4주차: self-managed runner 후보는 VM idle, patch SLA, cache backend, OIDC, runner token 관리 비용까지 비교합니다.
- 월말: 줄인 compute minutes, 늘어난 queue time, 실패율, 개발자 대기 시간, 보안 예외를 함께 리뷰합니다.
이 순서가 필요한 이유는 명확합니다.
무작정 runner를 줄이면 queue가 길어지고, 무작정 large runner를 쓰면 compute factor가 커집니다.
운영팀은 비용, 속도, 실패율, 보안을 같은 표에 올려야 다음달 변경을 설명할 수 있습니다.
운영 정책 스켈레톤
아래 YAML은 GitLab CI/CD 비용을 plan 가격이 아니라 namespace quota, runner factor, storage, security control로 관리하기 위한 정책 초안입니다.
# gitlab-cicd-cost-policy.yaml
owner: platform-finops
review_cycle: monthly
scope:
namespace: engineering
billing_surface: gitlab-com
source_of_truth:
- usage_quotas_compute_minutes
- pipeline_analytics
- runner_fleet_metrics
- artifact_and_cache_inventory
cost_controls:
compute_quota:
free_namespace_minutes: 400
premium_namespace_minutes: 10000
ultimate_namespace_minutes: 50000
runner_cost_factor:
linux_small: 1
linux_medium: 2
linux_large: 3
linux_xlarge: 6
linux_2xlarge: 12
gpu_medium: 7
macos_m1_medium_beta: 6
macos_m2_pro_large_beta: 12
pipeline_defaults:
interruptible: true
default_timeout_minutes: 20
scheduled_pipeline_owner_required: true
duplicate_pipeline_review: true
storage_defaults:
artifact_expire_in: 1 week
keep_latest_artifacts_exception: release-only
cache_max_entries_per_job: 4
cache_fallback_keys_max: 5
security_controls:
protected_variables_for_deploy: true
id_tokens_for_cloud_access: preferred
long_lived_cloud_keys_in_ci: deny
manual_job_sensitive_variables: avoid
review_flags:
- compute_minutes_over_80_percent
- large_runner_without_ticket
- scheduled_pipeline_without_owner
- artifacts_without_expire_in
- cache_miss_rate_over_50_percent
- oidc_not_used_for_cloud_deploy
정책 파일의 숫자는 공식 문서 기준을 넣었지만 조직마다 plan, runner 유형, self-managed runner 비용이 다릅니다.
따라서 실제 저장소에는 billing owner, security owner, project owner가 승인한 값만 반영해야 합니다.
cost-aware .gitlab-ci.yml 예시
아래 예시는 pipeline을 무조건 줄이는 파일이 아니라 중복 생성, cache miss, artifact 장기 보관, 민감 배포 job을 함께 제어하는 검토용 스켈레톤입니다.
# .gitlab-ci.yml cost-aware skeleton
# 실제 적용 전 runner tag, protected branch, environment, secret 정책을 조직 기준으로 조정한다.
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $CI_PIPELINE_SOURCE == "schedule"
when: never
- when: never
default:
image: node:22
interruptible: true
timeout: 20m
cache:
key:
files:
- package-lock.json
paths:
- .npm/
fallback_keys:
- npm-$CI_DEFAULT_BRANCH
- npm-default
stages:
- lint
- test
- build
- deploy
lint:
stage: lint
script:
- npm ci --cache .npm --prefer-offline
- npm run lint
rules:
- changes:
- src/**/*
- package-lock.json
- .gitlab-ci.yml
test:
stage: test
needs: [lint]
parallel: 2
script:
- npm ci --cache .npm --prefer-offline
- npm test
artifacts:
when: on_failure
expire_in: 1 week
paths:
- reports/test-summary.txt
deploy-production:
stage: deploy
when: manual
allow_failure: false
id_tokens:
CLOUD_ID_TOKEN:
aud: https://cloud.example.internal
script:
- ./deploy.sh
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
중요한 부분은 workflow:rules, interruptible, timeout, cache key, artifacts expire_in, manual deploy, id_tokens입니다.
이 구조를 그대로 복사하지 말고 project path, branch 보호, runner tag, cloud audience, package manager에 맞춰 검증해야 합니다.
월간 리뷰용 분류 스크립트
아래 Python은 실제 GitLab API client가 아니라 billing export와 pipeline analytics 결과를 같은 기준으로 정렬하기 위한 검토용 스켈레톤입니다.
#!/usr/bin/env python3
# gitlab_cicd_cost_review.py
# 목적: 월간 GitLab CI/CD 비용 리뷰에서 먼저 볼 pipeline을 분류한다.
# 입력값은 GitLab usage quota, pipeline analytics, runner metrics에서 가져온 값으로 채운다.
from dataclasses import dataclass
@dataclass
class PipelineUsage:
project: str
pipeline: str
runner_size: str
duration_seconds: int
cost_factor: float
jobs: int
retries: int
artifact_gb: float
cache_entries: int
scheduled: bool
@property
def compute_minutes(self) -> float:
return self.duration_seconds / 60 * self.cost_factor
def flags(row: PipelineUsage) -> list[str]:
result = []
if row.compute_minutes >= 300:
result.append('high_compute_minutes')
if row.cost_factor >= 6:
result.append('large_runner_review')
if row.retries >= 5:
result.append('flaky_retry_cost')
if row.artifact_gb >= 5:
result.append('artifact_retention_review')
if row.cache_entries > 4:
result.append('cache_policy_review')
if row.scheduled:
result.append('scheduled_owner_required')
return result
rows = [
PipelineUsage('checkout-api', 'merge-request', 'linux-small', 720, 1, 14, 2, 0.4, 2, False),
PipelineUsage('mobile-e2e', 'nightly-e2e', 'linux-2xlarge', 5400, 12, 38, 7, 8.5, 6, True),
]
for row in sorted(rows, key=lambda item: item.compute_minutes, reverse=True):
print(row.project, round(row.compute_minutes, 1), ','.join(flags(row)) or 'ok')
compute_minutes 값이 큰 pipeline부터 보되, large runner, retries, artifact, cache, schedule flag를 같이 봐야 원인이 보입니다.
이 표가 만들어지면 개발팀에는 속도 영향, 재무팀에는 quota 영향, 보안팀에는 secret과 runner 격리 영향을 분리해서 설명할 수 있습니다.
도입 전 비교 체크리스트
- Plan 가격표를 보기 전에 현재 namespace의 monthly compute minutes 소진율과 storage 사용량을 확인합니다.
- Top 20 job을 duration, cost factor, retries, artifact size, cache hit 신호로 나눕니다.
- Linux 2xlarge, macOS, GPU runner는 release 후보 또는 승인된 schedule에만 붙입니다.
- Scheduled pipeline은 owner, 주기, 산출물, 중단 기준이 없으면 다음달 예산에서 제외합니다.
- Self-managed runner는 서버비만 비교하지 말고 idle, patch, autoscaling, cache storage, 보안 격리 비용을 더합니다.
- Cloud deploy job은 장기 access key 대신 id_tokens와 bounded audience를 우선 검토합니다.
- Artifact는 PR, main, release 기준으로 expire_in을 다르게 두고 latest artifact 보존 정책을 확인합니다.
- Cache는 lockfile 기반 key, fallback key, protected branch 공유 정책을 월 1회 점검합니다.
- Pipeline 변경 뒤에는 compute minutes 감소뿐 아니라 queue time, 실패율, developer feedback time을 같이 봅니다.
함께 보면 좋은 글
GitHub Actions CI/CD 비용 2026, Copilot CLI·러너·보관까지 줄이는 운영 기준
GitHub Copilot 모델 선택 2026, 사내 개발팀 비용·보안·품질 기준
AI 코딩 테스트 자동화 2026, CI에서 테스트 생성·검증·보안 승인 기준
컨테이너 SBOM 자동화 2026, Docker Buildx·Syft·CI 보안 게이트 기준
클라우드 비용 최적화 2026, AWS 비용 줄이기 전 확인할 운영 기준
로그 모니터링 비용 2026, 수집·보관·조회 비용 줄이는 운영 기준자주 묻는 질문
GitLab CI/CD 비용은 plan 가격만 보면 되나요?
아니요, plan 가격과 함께 compute minutes quota, runner cost factor, storage, artifact, cache, self-managed runner 운영비를 같이 봐야 합니다.
GitLab compute minutes는 어떻게 계산되나요?
GitLab 공식 문서 기준으로 job duration을 60으로 나눈 뒤 runner type과 project type에 따른 cost factor를 곱해 계산합니다.
Premium의 10,000 compute minutes면 충분한가요?
팀 규모보다 pipeline 구조가 더 중요하므로 duplicate pipeline, scheduled job, large runner, flaky retry가 많으면 10,000 minutes도 빠르게 소진될 수 있습니다.
Self-managed runner를 쓰면 GitLab CI/CD 비용이 줄어드나요?
일부 workload에서는 줄 수 있지만 VM idle, patch, autoscaling, cache backend, 보안 격리, runner token 관리 비용을 더해야 공정한 비교가 됩니다.
Artifact와 cache 중 무엇을 먼저 줄여야 하나요?
Minutes가 문제면 cache hit와 dependency install 시간을 먼저 보고, storage가 문제면 artifact expire_in과 latest artifact 보존 정책을 먼저 봅니다.
OIDC id_tokens는 비용 최적화와 어떤 관련이 있나요?
Runner minutes를 직접 줄이지는 않지만 장기 cloud secret 유출과 회전 비용을 줄이므로 deploy pipeline의 총 운영비와 사고 리스크를 낮춥니다.
출처와 확인일
- GitLab — Pricing (확인일: 2026-07-27)
- GitLab Docs — Compute minutes (확인일: 2026-07-27)
- GitLab Docs — Purchase additional compute minutes (확인일: 2026-07-27)
- GitLab Docs — Runners (확인일: 2026-07-27)
- GitLab Docs — GitLab Runner (확인일: 2026-07-27)
- GitLab Docs — Caching in GitLab CI/CD (확인일: 2026-07-27)
- GitLab Docs — Job artifacts (확인일: 2026-07-27)
- GitLab Docs — CI/CD YAML syntax reference (확인일: 2026-07-27)
- GitLab Docs — Pipeline efficiency (확인일: 2026-07-27)
- GitLab Docs — OpenID Connect Authentication Using ID Tokens (확인일: 2026-07-27)
- GitLab Docs — Control how jobs run (확인일: 2026-07-27)
위 출처는 2026-07-27 기준으로 확인했으며, GitLab plan 가격, compute minutes quota, runner cost factor, storage 포함량, GitLab Duo credits, OIDC claim, artifact와 cache 동작은 plan, namespace,
product update에 따라 바뀔 수 있습니다.
이 글은 일반적인 DevOps 비용 운영 검토 자료이며, 실제 구매, runner 설계, 보안 정책, 클라우드 접근 권한은 공식 문서와 조직 내부 책임자 검토를 기준으로 최종 확인해야 합니다.
댓글
댓글 쓰기