---
title: CI 비교 — GitHub Actions vs GitLab CI/CD (그리고 Jenkins / CircleCI / Tekton)
source_type: official-doc
url: https://docs.github.com/en/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions
archive_url:
status: raw
confidence: high
tags: [ci, github-actions, gitlab-ci, jenkins, tekton, devops, ca-skeleton, official-doc, branch:feature-ci-quality-gates-contract]
related_projects: [ca-skeleton-operational-contract]
related_branches: [feature-ci-quality-gates-contract, feature-build-release-supply-chain-contract]
created: 2026-05-22
last_reviewed: 2026-05-27
---

# CI 비교 — GitHub Actions vs GitLab CI/CD (그리고 Jenkins / CircleCI / Tekton)

> Layer: `raw/official-docs/` — 공식 문서 발췌. CI provider 별 동일 개념(jobs/stages/needs)의 매핑 baseline.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-ci-quality-gates-contract]] | Gate ↔ Branch Contract Test 소유권 매트릭스의 backend 를 GitHub Actions 로 고정한 근거 (다른 provider 의 동일 개념 매핑) |
| [[raw/branch-notes/feature-build-release-supply-chain-contract]] | SBOM / Cosign / SLSA gate 가 어떤 provider step 으로 표현되는지의 이식성 baseline |

특정 branch 없이 foundational 조사로 수집한 경우:

- [[raw/project-notes/ca-skeleton-operational-contract]] — ca-tmpl 의 CI backend 의사결정의 외부 비교 기준

## 컨텍스트 / 왜 저장했는지

`feature-ci-quality-gates-contract` 가 release-blocking gate 매트릭스를 정의하는데, **gate 구현 backend 를 GitHub Actions 로 고정한 근거**가 필요합니다. matrix job, required check, workflow status 의존성 (`needs:`, `if: success()`) 은 provider 별로 모델이 다르므로, 다른 provider 에서의 동일 개념을 raw 로 확보해 두면 향후 이식 시 비용을 추정할 수 있습니다.

## 출처 / Source

- 원본 URL:
  - GitHub Actions migration guide — https://docs.github.com/en/actions/learn-github-actions/migrating-from-gitlab-cicd-to-github-actions
  - GitLab CI/CD pipelines — https://docs.gitlab.com/ee/ci/pipelines/
  - Jenkins Declarative Pipeline — https://www.jenkins.io/doc/book/pipeline/syntax/
  - CircleCI configuration reference — https://circleci.com/docs/configuration-reference/
  - Tekton Pipelines overview — https://tekton.dev/docs/pipelines/
- 아카이브 URL: (미수집)
- 저자 / 조직: GitHub Docs, GitLab Docs, Jenkins Project, CircleCI, CD Foundation (Tekton)
- 발행일: 공식 문서 (지속 갱신, fetched 2026-05-27)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [GitHub Docs §Introduction — Migrating from GitLab CI/CD] "GitLab CI/CD and GitHub Actions both allow you to create workflows that automatically build, test, publish, release, and deploy code."

> [GitHub Docs §Jobs — needs key] "GitLab CI/CD also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in GitHub Actions with the `needs` key."

> [GitHub Docs §Jobs — needs key] "Job dependencies in GitHub Actions can be specified explicitly with the `needs` key."

> [GitHub Docs §Scripts] "In GitLab CI/CD, script steps are specified using the `script` key. In GitHub Actions, all scripts are specified using the `run` key."

> [Jenkins Handbook §Pipeline syntax] "Declarative Pipeline … presents a more simplified and opinionated syntax on top of the Pipeline sub-systems. … The `agent` directive tells Jenkins where and how to execute the Pipeline, and is required in a declarative pipeline."

> [Tekton §Pipelines overview] "A `Pipeline` is a collection of `Tasks` that you define and arrange in a specific order of execution as part of your continuous integration flow. Each `Task` … runs as a Pod on your Kubernetes cluster."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| CIGG-C1 | GitHub Actions 와 GitLab CI/CD 는 모두 build/test/publish/release/deploy 를 자동화하는 workflow 작성을 지원한다 | [GitHub Docs §Introduction — Migrating from GitLab CI/CD] "GitLab CI/CD and GitHub Actions both allow you to create workflows that automatically build, test, publish, release, and deploy code." | `official-vendor-doc` | 두 provider 의 일반 워크플로우 능력 비교 | 두 provider 의 marketplace / extension 생태계가 동등하다는 뜻은 아님 — capability 만 동등 |
| CIGG-C2 | GitLab 의 `stages` (같은 stage 의 job 은 concurrent, 다음 stage 는 이전 stage 완료 후 시작) 는 GitHub Actions 의 `needs` key 로 재현 가능 | [GitHub Docs §Jobs — needs key] "GitLab CI/CD also has a concept of `stages`, where jobs in a stage run concurrently, but the next stage will start when all the jobs in the previous stage have completed. You can recreate this scenario in GitHub Actions with the `needs` key." | `official-vendor-doc` | GitHub Actions ↔ GitLab CI/CD stage 모델 이식 | `needs` 가 GitLab `stages` 의 모든 의미를 1:1 로 보존한다는 뜻은 아님 — `interruptible:` / `manual` 등 GitLab-specific keyword 는 별도 매핑 필요 |
| CIGG-C3 | GitHub Actions 의 job dependency 는 `needs` key 로 명시한다 | [GitHub Docs §Jobs — needs key] "Job dependencies in GitHub Actions can be specified explicitly with the `needs` key." | `official-vendor-doc` | GitHub Actions YAML 작성 | `needs` 의 fan-in/fan-out 시 status 전파 규칙 (e.g., `if: always()`) 의 정확한 의미는 본 인용에 명시 없음 |
| CIGG-C4 | GitLab CI/CD 의 `script` key 는 GitHub Actions 에서 `run` key 로 매핑된다 | [GitHub Docs §Scripts] "In GitLab CI/CD, script steps are specified using the `script` key. In GitHub Actions, all scripts are specified using the `run` key." | `official-vendor-doc` | shell script 의존 step 의 단순 이식 | `before_script` / `after_script` (GitLab) 의 GitHub 대응 (pre/post composite action, setup steps) 은 본 인용 범위 밖 |
| CIGG-C5 | Jenkins Declarative Pipeline 은 Pipeline sub-system 위의 단순화된 syntax 이며 `agent` directive 가 필수 (실행 위치/방법 지정) | [Jenkins Handbook §Pipeline syntax] "Declarative Pipeline … presents a more simplified and opinionated syntax on top of the Pipeline sub-systems. … The `agent` directive tells Jenkins where and how to execute the Pipeline, and is required in a declarative pipeline." | `official-vendor-doc` | Jenkins Declarative Pipeline 작성 | Scripted Pipeline (`node('label') { ... }`) 의 차이 / plugin 호환성은 본 인용 범위 밖 |
| CIGG-C6 | Tekton 의 `Pipeline` 은 `Task` 들의 collection 이며, 각 `Task` 는 Kubernetes cluster 의 Pod 로 실행된다 | [Tekton §Pipelines overview] "A `Pipeline` is a collection of `Tasks` that you define and arrange in a specific order of execution as part of your continuous integration flow. Each `Task` … runs as a Pod on your Kubernetes cluster." | `official-vendor-doc` | Tekton CI/CD 운영 모델 (k8s-native) | self-hosted Kubernetes 비용 모델이 GitHub Actions runner 와 동등하다는 뜻은 아님 — infra 비용은 별도 |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `CIGG-C1`: 두 major provider 가 동일 워크플로우 카테고리 (build/test/publish/release/deploy) 를 지원한다는 사실
  - `CIGG-C2`, `CIGG-C3`: `stages` ↔ `needs` 매핑이 GitHub 공식 문서에 명시되어 있다는 사실
  - `CIGG-C4`: `script` ↔ `run` 의 명시적 매핑
  - `CIGG-C5`: Jenkins Declarative Pipeline 의 `agent` 필수 요건
  - `CIGG-C6`: Tekton 의 k8s-Pod 기반 실행 모델
- **이 자료가 증명하지 않는 것**:
  - 각 provider 의 비용 / SLA / 가용성 비교
  - 어떤 provider 가 ca-tmpl 에 best fit 인가 — 이 결정은 별도 ADR 필요
  - matrix job 의 정확한 표현 차이 (`strategy.matrix` vs `parallel: matrix:` vs `axes`)
  - reproducible build 보장 수준 (Nix / Bazel / cosign 등 별도 도구)
  - 어떤 provider 가 SLSA Level 3+ certification 을 가진가 (별도 SLSA 문서 확인)
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 의 quality-gate workflow 가 `needs: [contract-test, openapi-check, sbom-attest]` 형태로 표현되는지의 실제 yaml 검증
  - 향후 GitLab 이식 시 `interruptible:` / `rules:if:` / `parallel:matrix:` 의 GitHub Actions equivalence 매핑 완성도
  - Tekton 이식의 infra 비용 (self-hosted k8s cluster 운영) 추정

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- GitHub Actions: `needs:` + `if: success()` 조합으로 contract test gate ↔ release-blocking 매트릭스를 단일 yaml 에서 강제 가능. branch note 의 "workflow yaml 의 `needs: [contract-test]` 의존성" 가설과 일치.
- GitLab CI: `rules:` + `needs:` + `interruptible:` 조합이 GitHub 의 `if:` + `needs:` + `concurrency:` 에 매핑. matrix 는 `parallel: matrix:` 키워드.
- Jenkins: declarative pipeline 의 `post { failure { ... } }` 는 GitHub 의 `if: failure()` step 에 해당. 단, plugin 의존도가 높아 reproducible build 와 충돌 위험.
- Tekton: k8s-native 라 self-hosted runner 비용 모델이 다름. ca-skeleton 단계에는 과한 인프라.
- CircleCI / Buildkite / Drone: 상용/소형 팀 옵션. ca-tmpl 의 default 를 GitHub Actions 로 잡되, **gate 정의는 provider-agnostic** 하게 작성해야 이식 가능.

## Related / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/ci-openapi-snapshot-diff-tooling]] — OpenAPI drift gate 도구 체인
- 적용 branch-note:
  - [[raw/branch-notes/feature-ci-quality-gates-contract]] — Gate ↔ Branch Contract Test 소유권 매트릭스의 backend 선택 근거
  - [[raw/branch-notes/feature-build-release-supply-chain-contract]] — SBOM / Cosign / SLSA gate 가 어떤 provider step 으로 표현되는지