[DevOps] GitLab CI/CD vs GitHub Actions 비교

0. 개요

1. GitLab CI/CD vs GitHub Actions 비교
2. 철학과 아키텍처 차이
   • 2-1. 올인원(단일 앱) vs 에코시스템(마켓플레이스)
   • 2-2. 파이프라인/잡/스테이지 vs 워크플로우/잡/스텝
3. 러너(에이전트)와 성능
   • 3-1. SaaS/자체 호스팅 러너, 오토스케일
   • 3-2. 캐시/아티팩트/매트릭스/컨테이너
4. 구성(YAML)과 재사용성
   • 4-1. 템플릿, 리유저블 워크플로우, 앵커
   • 4-2. 모노레포 전략(경로 필터, 다중 파이프라인)
5. 보안·거버넌스·컴플라이언스
   • 5-1. 권한 모델, 환경 보호, 승인 게이트
   • 5-2. 시크릿/OIDC/보안 스캔(구성 차이)
6. 배포와 릴리스 자동화
   • 6-1. 환경/릴리즈/서드파티 통합
   • 6-2. Blue-Green/Canary/승인 플로우
7. 비용·운영 관점 비교
   • 7-1. 분당 과금, 러너 스펙, 네트워크
   • 7-2. 유지보수/업그레이드/플러그인 리스크
8. 레퍼런스 예시(YAML)
   • 8-1. GitHub Actions 기본 워크플로우
   • 8-2. GitLab CI 파이프라인
9. 상황별 추천 시나리오
   • 스타트업/모노레포/엔터프라이즈
10. 체크리스트 & 의사결정 매트릭스
11. 결론 요약
12. FAQ

---

1. GitLab CI/CD vs GitHub Actions 비교

두 플랫폼 모두 “코드가 푸시되면 자동으로 빌드·테스트·배포”를 실현합니다. 하지만 도입 배경과 조직의 요구가 다르면 최적의 선택도 달라집니다. 아래 비교는 철학/구성/보안/성능/비용/운영 관점에서 핵심 차이를 빠르게 파악하고, 팀 상황에 맞는 실전 선택을 돕습니다.

2. 철학과 아키텍처 차이

2-1. 올인원(단일 앱) vs 에코시스템(마켓플레이스)

• GitLab: 이슈·리포지토리·CI/CD·패키지·보안 스캔·위키까지 단일 애플리케이션에 통합. 러너도 GitLab 관점에서 일관되게 관리합니다.
• GitHub Actions: 코드 허브 중심에 워크플로우 엔진을 얹고, 방대한 Marketplace Actions로 기능을 확장하는 에코시스템 지향.

2-2. 파이프라인/잡/스테이지 vs 워크플로우/잡/스텝

• GitLab: stages → jobs 모델. 스테이지 순서가 명확하고 needs:로 DAG 의존성 최적화가 용이합니다.
• Actions: workflow → jobs → steps. 잡간 의존(needs:)과 matrix 조합이 강력하며 Marketplace 액션으로 스텝 재사용이 쉽습니다.

3. 러너(에이전트)와 성능

3-1. SaaS/자체 호스팅 러너, 오토스케일

• GitLab Runner: Docker/Kubernetes/VM 등 다양한 실행자. 자체 Runner를 오토스케일링(예: K8s)하면 대량 CI에도 비용·성능 균형이 좋습니다.
• GitHub Runner: GitHub 호스팅 러너는 간편, self-hosted runner로 특수 빌드(대형 캐시, 사내 네트워크 접근)에 대응. Autoscaling은 컨트롤러(예: K8s, ASG)로 구현합니다.

3-2. 캐시/아티팩트/매트릭스/컨테이너

• 캐시: GitLab cache:, Actions actions/cache. 키 전략(OS/언어/락파일)을 표준화해야 히트율이 높습니다.
• 아티팩트: GitLab은 artifacts: paths, expire_in, Actions는 actions/upload-artifact로 수명 관리.
• 매트릭스: Actions가 문법적으로 간결. GitLab은 parallel:matrix로 유사 기능 제공.
• 컨테이너: 둘 다 컨테이너 빌드/서비스 컨테이너 지원. K8s와의 밀착은 GitLab Runner(K8s executor)가 다소 편리, Actions는 services:와 container:로 충분히 대응.

4. 구성(YAML)과 재사용성

4-1. 템플릿, 리유저블 워크플로우, 앵커

• GitLab: include:로 공통 템플릿을 가져오고, YAML 앵커(&/\*)로 반복을 제거. 그룹 수준 템플릿로 조직 표준을 강제하기 좋습니다.
• Actions: Reusable Workflows(workflow_call)과 Composite Actions로 재사용. Marketplace 배포·테스트 액션을 바로 가져다 쓰기 쉬움.

4-2. 모노레포 전략(경로 필터, 다중 파이프라인)

• GitLab: rules:changes로 경로 기반 트리거, child/parent 파이프라인으로 디렉터리별 세분화.
• Actions: on.push.paths, on.pull_request.paths로 조건 실행. 리유저블 워크플로우 + 경로 필터로 빠른 선택적 빌드가 가능.

5. 보안·거버넌스·컴플라이언스

5-1. 권한 모델, 환경 보호, 승인 게이트

• GitLab: Protected branches/tags, Environments + manual/승인, Code Owners로 리뷰 강제.
• Actions: Environments에 required reviewers, branch protection, CODEOWNERS, 그리고 required status checks로 게이트 구성.

5-2. 시크릿/OIDC/보안 스캔(구성 차이)

• 시크릿: GitLab CI/CD variables(masked/protected), Actions Secrets/Variables & 환경/조직 스코프.
• OIDC: 둘 다 클라우드 자격증명을 단기 토큰으로 발급(AWS/GCP/Azure)해 키 없는 배포를 구현.
• 보안 스캔: GitLab은 SAST/DAST/Dependency/Container Scanning를 템플릿로 쉽게 활성화. GitHub은 기본 시크릿 스캐닝/Dependabot + Advanced Security(옵션)로 SAST/CodeQL 제공.

6. 배포와 릴리스 자동화

6-1. 환경/릴리즈/서드파티 통합

• GitLab: environments + deployments 기록, Pages/Packages/Container Registry 일체형.
• Actions: Environments·Releases·Packages·Container registry 통합이 점진 강화. Marketplace로 클라우드 배포 액션이 풍부.

6-2. Blue-Green/Canary/승인 플로우

• 두 플랫폼 모두 스크립트/툴(Helm, Argo CD, Terraform)과 연계해 전략 배포를 구현. 승인·롤백은 환경 보호 규칙과 워크플로우 게이트로 구성합니다.

7. 비용·운영 관점 비교

7-1. 분당 과금, 러너 스펙, 네트워크

• SaaS 러너: 편하지만 분당 과금과 스펙 한계가 있어 캐시 최적화, 매트릭스 제한이 중요합니다.
• 자체 러너: 스팟/프리엠티브 인스턴스·K8s로 원가 절감. 내부망 접근·대용량 캐시·사설 패키지에 유리.

7-2. 유지보수/업그레이드/플러그인 리스크

• GitLab 자체 설치는 업그레이드/백업 전략이 필요. Actions는 관리형이어서 플랫폼 유지 부담이 적고, 대신 러너/비용 최적화가 숙제입니다.

8. 레퍼런스 예시(YAML)

8-1. GitHub Actions 기본 워크플로우

# .github/workflows/ci.yml name: CI on: push: branches: [ main ] paths: [ "app/**" ] pull_request: paths: [ "app/**" ]

jobs:
build-test:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [18, 20]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: ${{ matrix.node-version }} }
- run: npm ci
- run: npm test -- --ci
- uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ runner.os }}-${{ matrix.node-version }}-${{ hashFiles('**/package-lock.json') }}
- run: npm run build

8-2. GitLab CI 파이프라인

# .gitlab-ci.yml stages: [test, build, deploy]

variables:
NODE_ENV: production

cache:
key: "npm-${CI_COMMIT_REF_SLUG}"
paths: [node_modules/]

test:
stage: test
image: node:20-alpine
rules:
- changes:
- app/**/*
script:
- npm ci
- npm test -- --ci
artifacts:
when: always
reports:
junit: reports/junit.xml

build:
stage: build
needs: [test]
image: node:20-alpine
script:
- npm run build
artifacts:
paths: [dist/]
expire_in: 7 days

deploy:
stage: deploy
needs: [build]
environment:
name: production
url: https://app.example.com

script:
- ./scripts/deploy.sh
when: manual # 승인 후 배포

9. 상황별 추천 시나리오

9-1. 스타트업(속도·도입 난이도 최소)

• GitHub Actions 권장: Marketplace 액션으로 빠르게 파이프라인 구성, 레포 단위로 독립 운영.

9-2. 모노레포·Kubernetes 중심

• GitLab 선호: rules:changes, parent/child 파이프라인, K8s Runner 오토스케일로 대규모 빌드에 유리.

9-3. 엔터프라이즈(거버넌스/보안/온프렘)

• GitLab Self-Managed: 사내망, 컴플라이언스, 통합 보안 스캔 요구가 강하면 일원화가 장점.
• GitHub Enterprise + Actions: 코드 협업이 GitHub에 이미 표준이면, Actions + Advanced Security 조합으로 보강.

10. 체크리스트 & 의사결정 매트릭스

• 레포/조직: 단일/다중 레포, 모노레포 여부, Marketplace/템플릿 선호?
• 러너: SaaS로 충분? 자체 러너 필요(사내망/전용 GPU/대형 캐시)?
• 보안: OIDC, 환경 승인, 시크릿 스코프, 스캔 범위.
• 비용: 분당 비용, 캐시/아티팩트 전송량, 러너 스펙/오토스케일.
• 운영: 업그레이드/백업/감사와 운영 인력의 숙련도.

| 항목 | GitHub Actions | GitLab CI/CD | |----------------|-------------------------------------------|----------------------------------------------| | 철학 | 에코시스템/마켓플레이스 중심 | 올인원 단일 앱 | | 러너 | 호스팅/자체 러너, 오토스케일 별도 구성 | GitLab Runner, K8s executor 오토스케일 용이 | | 재사용성 | Reusable WF/Composite/Marketplace 풍부 | include/템플릿/앵커로 조직 표준화 | | 모노레포 | paths 필터 + 리유저블 | rules:changes + parent/child 파이프라인 | | 보안 스캔 | 기본+Advanced Security(옵션) | SAST/DAST/컨테이너/의존성 스캔 템플릿 | | 배포/환경 보호 | Environments+승인/리뷰어 | environments+manual/승인/보호 브랜치 | | 비용 전략 | 분당 과금/호스팅 러너 단순 | 자체 Runner로 대량 빌드 비용 절감 가능 |

11. 결론 요약

빠른 도입·에코시스템 활용이 목표면 GitHub Actions, 올인원·자체 운영·대규모 빌드 최적화가 핵심이면 GitLab이 유리합니다. 실제로는 코드 호스팅 위치·조직 보안 요건·러너 운영 역량·비용 구조를 함께 고려해 혼용(예: GitHub 코드 + GitLab CI 또는 반대)도 현실적인 선택입니다. 표준 템플릿과 OIDC·경로 필터·캐시 전략을 먼저 정하면 어느 플랫폼이든 속도·안정성·비용을 모두 잡을 수 있습니다.

12. FAQ

Q1. 모노레포에서 부분 빌드만 트리거하려면?

A1. Actions는 on.push.paths·on.pull_request.paths, GitLab은 rules:changes를 사용하세요. 공통 템플릿/리유저블 워크플로우와 조합해 서비스별 파이프라인을 분리합니다.

Q2. 시크릿을 클라우드 자격증명 없이 쓰려면?

A2. 양쪽 모두 OIDC를 지원합니다. 클라우드에서 신뢰 정책을 구성해 단기 토큰을 발급받는 키리스(Keyless) 배포를 구현하세요.

Q3. 러너 비용을 절감하려면?

A3. 자체 러너를 스팟/K8s 오토스케일로 운영하고, 캐시 키를 OS+언어+락파일 기반으로 설계해 히트율을 높이세요. 매트릭스 축은 필요한 최소 조합으로 유지합니다.