CI/CD 시스템 2026 완벽 가이드 - GitHub Actions · Buildkite · CircleCI · GitLab · Jenkins · Argo · Tekton · Earthly · Dagger 심층 분석

들어가며 — 2026년 5월, CI/CD 시장은 "GitHub Actions가 이긴" 풍경이다

2020년만 해도 CI/CD 시장은 다극화돼 있었다. Jenkins가 엔터프라이즈를 잡고, CircleCI가 스타트업을 잡고, Travis CI가 OSS 표준이었고, Buildkite는 일부 고난도 팀이 쓰는 옵션이었다. 2026년 5월 현재 풍경은 거의 한 방향으로 굳었다. GitHub Actions가 네트워크 효과로 사실상 시장을 가져갔다. GitHub에 코드가 있으면 Actions를 안 쓰기가 어렵다. Marketplace에 2만 개가 넘는 액션이 있고, OIDC 페더레이션으로 AWS/GCP/Azure 비밀 토큰 없이도 배포가 된다.

그렇다고 다 죽은 건 아니다. Buildkite는 대규모 모노레포 + 자체 호스팅 러너의 고급 시장에서 압도적이다(Shopify, Airbnb, Lyft가 표준). CircleCI는 Apple Silicon, ARM, GPU 러너에서 강점을 유지한다. GitLab CI/CD는 GitLab 사용자에게는 여전히 1순위다. K8s 네이티브 영역은 Tekton + Argo Workflows가 잡았고, Dagger는 "프로그래머블 CI"라는 새 카테고리를 키우는 중이다. 이 글은 2026년 5월 기준 누가 어디서 어떻게 쓰이는지를 정직하게 짚는다.

2026년 CI/CD 스택을 5개 레이어로 분해하기

CI/CD를 단일 도구로 보면 자꾸 비교가 어긋난다. 다음 5개 레이어로 나누는 게 정확하다.

1. 트리거(trigger)와 워크플로 정의(workflow): GitHub Actions, GitLab CI, CircleCI, Buildkite, Jenkins, Tekton
2. 실행 환경(runner / agent / executor): GitHub-hosted, ARC, RunsOn, BuildJet, Namespace, Buildkite agents, K8s Jobs
3. 빌드 시스템(build tool): Bazel, Buck2, Pants, Nx, Turborepo, Earthly, Mill, Make, Gradle
4. 캐시/원격 실행(remote cache / RBE): Bazel Remote Cache, Turborepo Remote Cache, Nx Cloud, sccache, ccache
5. 배포/오케스트레이션(delivery): Argo CD, Argo Rollouts, Spinnaker, Harness, Octopus, Flux, Vercel, Cloud Run, ECS Service

전통적으로 1번 도구가 2~5번을 다 흡수하려는 경향이 강했고(Jenkins가 그랬다), 그래서 모든 게 한 통에 들어가서 깨졌다. 2026년 베스트 프랙티스는 분리다. CI는 GitHub Actions, CD는 Argo CD, 빌드 가속은 Bazel + RBE 혹은 Turborepo Remote Cache처럼 레이어별로 다른 도구를 선택한다.

GitHub Actions — 시장 점유 60% 이상의 새 표준

GitHub Actions는 2019년 정식 출시 이후 2026년 현재 GitHub 사용자의 약 75%, 전체 CI/CD 시장의 60% 이상을 점유한다(JetBrains DevEcosystem 2025 Survey 기준). 가장 큰 이유는 GitHub 안에 있다는 것이다. 별도 SaaS에 가입할 필요가 없고, PR과 워크플로가 같은 화면에서 보이고, Marketplace의 2만 개 액션을 그대로 끌어다 쓴다.

2026년 5월 현재 핵심 기능은 다음과 같다.

• Reusable Workflows: workflow_call 트리거로 워크플로 자체를 모듈화. 조직 단위 표준 파이프라인을 1곳에 두고 100개 리포지토리가 호출.
• Composite Actions: 여러 스텝을 묶어 액션 하나로. JavaScript/Docker 액션보다 가볍다.
• OIDC Federation: 클라우드 비밀 키 없이 GitHub OIDC 토큰을 AWS IAM/GCP Workload Identity/Azure Federated Credential과 교환.
• Large Runners: 4·8·16·32·64 vCPU + GPU 옵션, 윈도우·macOS 포함. macOS는 M2 Pro 베이스.
• ARC (Actions Runner Controller): K8s 위에서 self-hosted runner를 동적으로 띄우는 공식 컨트롤러.
• Workflow Templates: 조직 레벨에서 새 리포지토리에 워크플로 자동 시드.

OIDC 페더레이션 + 매트릭스 + 재사용 워크플로를 결합한 실전 워크플로 예시는 다음과 같다.

name: deploy
on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest-16-cores
    strategy:
      matrix:
        node: [20, 22]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: 'pnpm'
      - run: pnpm install --frozen-lockfile
      - run: pnpm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: ap-northeast-2
      - run: aws s3 sync ./dist s3://my-bucket --delete
      - run: aws cloudfront create-invalidation --distribution-id $CF_ID --paths '/*'

여기서 핵심은 permissions.id-token: write다. 이 한 줄이 있어야 GitHub OIDC 토큰이 발급되고, configure-aws-credentials 액션이 그걸 AWS STS와 교환한다. AWS Access Key는 어디에도 없다. 이 패턴이 2024년부터 빠르게 표준이 됐고, 2026년에는 PAT/Deploy Key 기반 배포는 신규 시스템에서 거의 사라졌다.

GitHub Actions 보안 — SHA 핀 vs 태그 핀, 그리고 공급망 공격

2024년 9월 tj-actions/changed-files 사건은 GitHub Actions 보안의 기점이었다. 인기 액션이 침해당해 모든 호출자의 시크릿이 유출됐다. 이후 업계 표준은 다음으로 굳었다.

• 버전 태그(@v4) 대신 커밋 SHA로 핀: uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
• 공식 액션(actions/*)과 검증된 액션 외에는 Dependabot/Renovate로 정기 감사
• permissions: 블록을 워크플로/잡 레벨에서 명시적 최소화(기본은 read-all이 아니라 빈 권한)
• 시크릿은 환경(environment)으로 묶고 환경 보호 규칙으로 승인자 두기
• pull_request_target 트리거는 매우 신중히(fork PR이 main의 시크릿에 접근할 수 있다)

2026년 현재 GitHub은 "trusted publishers" 모델을 액션에도 적용했다. npm/PyPI의 OIDC 기반 검증된 게시자 표시처럼, 액션도 게시자 인증과 SBOM 첨부가 표시된다. SLSA 레벨 3 액션이 Marketplace에서 우선 노출된다.

자체 호스팅 러너 — ARC, RunsOn, BuildJet, Namespace

GitHub-hosted runner는 편하지만 비싸다. 대형 러너 8 vCPU 분당 약 0.064 USD, 64 vCPU GPU는 분당 0.50 USD 이상이다. 월 빌드 시간이 1만 분을 넘어가면 자체 호스팅이 절반 이하 비용이 된다. 2026년 5월 기준 옵션은 다음과 같다.

• ARC (Actions Runner Controller): GitHub 공식. K8s 클러스터 위에 러너 풀을 운영. AutoScaler가 job 큐를 보고 pod를 띄움. 대기업 표준.
• RunsOn.io: AWS 계정에 EC2 spot 인스턴스 풀을 자동 구성. 60초 안에 러너 부팅, GitHub 라벨로 라우팅. 비용이 GitHub-hosted의 1/8 수준이라 빠르게 점유율 상승.
• BuildJet: 외부 SaaS. GitHub-hosted와 동일한 인터페이스, 베어메탈 ARM/Intel, 캐시 가속까지. 가격은 GitHub 절반 수준.
• Namespace.so: 컨테이너 빌드/테스트에 특화된 클라우드. CDN처럼 분산 캐시를 깔아둬서 docker pull/push가 빠르다.

ARC를 K8s 위에 띄우는 최소 헬름 설정 발췌는 다음과 같다.

apiVersion: actions.github.com/v1alpha1
kind: AutoscalingRunnerSet
metadata:
  name: linux-large
  namespace: arc-runners
spec:
  githubConfigUrl: https://github.com/my-org
  githubConfigSecret: github-app-secret
  minRunners: 2
  maxRunners: 80
  template:
    spec:
      containers:
        - name: runner
          image: ghcr.io/actions/actions-runner:latest
          resources:
            requests:
              cpu: '4'
              memory: 8Gi
            limits:
              cpu: '8'
              memory: 16Gi

maxRunners: 80이면 큐가 차도 80개까지만 떠서 비용이 폭주하지 않는다. 토스, 우아한형제들, LINE은 ARC를 자체 K8s에 띄워 월 수십만 분의 CI를 GitHub-hosted 대비 60% 싸게 돌린다.

Buildkite — 대규모 모노레포의 고급 표준

Buildkite는 시장점유율로 GitHub Actions의 1/10도 안 되지만, 대규모 엔지니어링 조직에서는 압도적 우위다. Shopify(엔지니어 6,000+), Airbnb, Lyft, Pinterest가 표준으로 쓴다. 핵심 차별점은 다음이다.

• 에이전트가 사용자 인프라에서 돈다(SaaS는 메타데이터/UI만). 코드는 절대 Buildkite 서버에 안 올라간다.
• 파이프라인을 동적으로 생성 가능. YAML을 정적으로 두는 대신, buildkite-agent pipeline upload로 빌드 중에 새 스텝을 만들어 업로드.
• 모노레포 + 대규모 분할 실행에 최적화. 변경된 패키지만 빌드/테스트.
• 재시도/플레이크 정책이 stage-level로 세밀.

전형적 파이프라인 정의는 다음과 같다.

steps:
  - label: ':go: lint'
    command: make lint
    agents:
      queue: 'linux-amd64'

  - wait

  - label: ':go: test ({{matrix.shard}}/8)'
    command: make test SHARD={{matrix.shard}}
    parallelism: 8
    matrix:
      setup:
        shard: [0, 1, 2, 3, 4, 5, 6, 7]
    agents:
      queue: 'linux-amd64-large'

  - wait

  - block: 'Deploy to production?'
    branches: 'main'

  - label: ':rocket: deploy'
    command: ./deploy.sh
    concurrency: 1
    concurrency_group: 'deploy-prod'

여기서 parallelism: 8은 동일 명령을 샤드 8개로 분할 실행한다는 뜻이다. block은 사람이 버튼을 눌러야 다음으로 진행한다. Shopify는 PR당 평균 200 step, 매트릭스 분할 후 6,000 job을 띄우는 파이프라인을 Buildkite로 돌린다. GitHub Actions로는 동일 규모 실행이 비용과 큐잉 측면에서 부담된다.

CircleCI — Apple Silicon · ARM · GPU 러너의 강자

CircleCI는 2010년대 초중반 CI/CD의 사실상 표준이었고, 2026년에는 GitHub Actions에 일반 시장을 내줬지만 특수 러너에서는 여전히 1순위다.

• Apple Silicon (M2 Pro/M3) macOS 러너: iOS/macOS 빌드의 표준. GitHub-hosted macOS보다 안정적이고 빠르다는 평가.
• ARM Graviton 러너: AWS Graviton과 동일 ISA로 빌드 → 그대로 ECS Fargate ARM에 배포.
• GPU 러너: A100/H100 옵션. ML 학습/검증 파이프라인을 그대로 CircleCI에 묶는다.
• Docker Layer Cache: 자체 캐시 레이어로 docker pull/build 가속.

config.yml 구조는 매트릭스/orb(재사용 단위)/공유 executor로 GitHub Actions와 유사하지만, macOS·ARM·GPU 풀이 더 안정적이라는 게 2026년 시장 평가다.

GitLab CI/CD — GitLab을 쓰면 1순위

GitLab CI/CD는 별도 도구가 아니라 GitLab의 일부다. .gitlab-ci.yml 한 파일로 빌드/테스트/배포/보안 스캔이 다 들어간다. GitHub Actions와 가장 큰 차이는 다음이다.

• DAG가 명시적: needs: 키워드로 잡 간 의존성을 그래프로 그린다.
• Auto DevOps: 표준 파이프라인을 자동 적용(SAST, DAST, 컨테이너 스캔, 라이선스 스캔).
• GitLab Runner: 자체 에이전트가 Docker/K8s/Shell/SSH를 다 지원. 사내 데이터센터에 바로 둔다.
• Pipeline Editor: 웹 UI에서 시각적으로 잡 의존성을 본다.

GitLab Premium/Ultimate 라이선스를 갖고 있는 조직은 외부 CI 도입의 명분이 거의 없다. 그래서 GitLab CI/CD는 점유율 면에서 GitHub Actions에 밀려도 GitLab 사용자 안에서는 90% 이상 점유한다.

Jenkins + JCasC — 여전히 살아 있다, 다만 새 도입은 줄었다

Jenkins는 2004년 Hudson에서 시작해 2026년 현재도 전 세계 CI 인스턴스 수로는 1위다. 다만 신규 도입은 거의 없다. 대부분 기존 인스턴스가 "이미 너무 깊이 박혀 있어서" 운영 중이다.

2026년 모범 사례는 다음이다.

• Pipeline as Code (Jenkinsfile): 더 이상 UI 클릭으로 잡을 만들지 않는다. Git에 Jenkinsfile을 둔다.
• JCasC (Jenkins Configuration as Code): 인스턴스 자체 설정도 YAML로. UI 클릭 설정은 disaster recovery의 적.
• K8s Plugin + Pod templates: 에이전트를 정적 VM이 아니라 K8s pod로 동적 생성.
• Shared Libraries: Groovy 라이브러리를 별도 리포에 두고 여러 잡이 import.

전형적 선언형 Jenkinsfile은 다음과 같다.

pipeline {
  agent {
    kubernetes {
      yaml '''
        spec:
          containers:
            - name: node
              image: node:22
              command: ["sleep", "infinity"]
      '''
    }
  }
  stages {
    stage('Install') {
      steps { container('node') { sh 'npm ci' } }
    }
    stage('Test') {
      steps { container('node') { sh 'npm test' } }
    }
    stage('Deploy') {
      when { branch 'main' }
      steps { sh './deploy.sh' }
    }
  }
}

은행, 통신사, 대기업 IT 자회사는 2026년에도 Jenkins를 운영한다. 단, 새 팀은 GitHub Actions나 Argo Workflows로 시작한다.

Tekton — K8s 네이티브 CI/CD 표준

Tekton은 K8s 위에서 CI/CD를 1급 시민(first-class)으로 만든 프로젝트다. 모든 것이 K8s CRD(Custom Resource)다. Task, Pipeline, PipelineRun, TaskRun이 K8s 리소스로 정의되고, controller가 pod로 실행한다.

2026년 Tekton의 위치는 분명하다. 사용자가 직접 Tekton YAML을 쓰는 일은 드물고, 대신 Tekton을 백엔드로 쓰는 상위 도구들이 표준이 됐다. Jenkins X, Red Hat OpenShift Pipelines, Google Cloud Build, JetBrains Space가 내부적으로 Tekton을 쓴다. 즉 Tekton은 CI/CD의 K8s 런타임 표준이다.

Argo Workflows + Events + Rollouts — Argo 생태계

Argo는 K8s 네이티브 영역에서 가장 큰 생태계다. 2026년 5월 현재 4개 핵심 프로젝트가 있다.

• Argo CD: GitOps 배포(Git → K8s 클러스터 reconciliation)
• Argo Workflows: K8s 위의 워크플로 엔진(DAG, 스텝 시퀀스, ML 파이프라인)
• Argo Events: 이벤트 → 워크플로 트리거(S3, Kafka, GitHub webhook, calendar)
• Argo Rollouts: 카나리/블루그린/프로그레시브 배포 컨트롤러

Argo Workflows의 DAG 템플릿 예시.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: build-test-deploy-
spec:
  entrypoint: main
  templates:
    - name: main
      dag:
        tasks:
          - name: build
            template: run-script
            arguments:
              parameters: [{name: script, value: 'make build'}]
          - name: test
            template: run-script
            dependencies: [build]
            arguments:
              parameters: [{name: script, value: 'make test'}]
          - name: deploy
            template: run-script
            dependencies: [test]
            arguments:
              parameters: [{name: script, value: 'make deploy'}]
    - name: run-script
      inputs:
        parameters:
          - name: script
      container:
        image: alpine:3.20
        command: [sh, -c]
        args: ['{{inputs.parameters.script}}']

각 task는 별도 pod로 떠서 격리된다. GPU 노드 / 큰 메모리 노드를 task별로 다르게 스케줄링한다. ML 학습 파이프라인, 데이터 ETL, 야간 정산 잡 등이 Argo Workflows의 주 사용처다.

Argo Rollouts는 카나리 배포를 K8s Deployment 대체로 정의한다. 5% 트래픽 → 메트릭 검증 → 25% → 50% → 100%를 YAML 한 파일에 적는다. Prometheus 메트릭이 임계치를 넘으면 자동 롤백한다.

Earthly와 Dagger — 빌드 + CI를 통합한 새 카테고리

전통 CI는 YAML이 빌드 명령을 호출하고, 빌드 명령은 Makefile/Dockerfile이 처리하는 구조다. 이 분리가 만든 문제가 있다. 로컬과 CI의 빌드가 다르다. 로컬은 빠른데 CI에서만 실패하거나, 로컬에서만 캐시가 잘 먹는다.

Earthly는 "Dockerfile + Makefile + CI"를 하나로 합쳐 Earthfile이라는 단일 포맷을 제공한다.

VERSION 0.8
FROM golang:1.23-alpine
WORKDIR /app

deps:
    COPY go.mod go.sum .
    RUN go mod download
    SAVE ARTIFACT /go/pkg/mod /pkg-cache

build:
    FROM +deps
    COPY . .
    RUN go build -o app ./cmd/server
    SAVE ARTIFACT app AS LOCAL ./build/app

test:
    FROM +build
    RUN go test ./...

docker:
    FROM alpine:3.20
    COPY +build/app /usr/local/bin/app
    ENTRYPOINT ["/usr/local/bin/app"]
    SAVE IMAGE myorg/app:latest

이걸 earthly +docker로 로컬에서 돌리든, GitHub Actions의 한 줄로 CI에서 돌리든 결과가 같다. 캐시도 BuildKit 기반으로 일관된다. 로컬과 CI가 일치하니까 디버깅이 쉽다.

Dagger는 한 발 더 나간다. 빌드 파이프라인을 YAML이 아닌 TypeScript/Go/Python 코드로 작성한다. SDK가 BuildKit 위에서 컨테이너를 그래프로 실행한다.

import { dag, Container, Directory } from '@dagger.io/dagger'

export class Build {
  async test(source: Directory): Promise<string> {
    return dag
      .container()
      .from('node:22-alpine')
      .withMountedDirectory('/app', source)
      .withWorkdir('/app')
      .withExec(['npm', 'ci'])
      .withExec(['npm', 'test'])
      .stdout()
  }
}

CI YAML에 dagger call test --source=. 한 줄만 두면, 실제 파이프라인 로직은 코드로 관리된다. 테스트 가능한 CI가 가능해진다. 2026년 초 Dagger는 시리즈 B를 받고, Replit, Vercel, Anthropic 등이 평가 도입했다는 사례가 나왔다. 시장 점유율은 아직 작지만 추세는 분명하다.

Bazel · Buck2 · Pants · Mill — 대규모 모노레포 빌드 시스템

빌드 시스템 레이어는 CI와 분리된다. 같은 GitHub Actions를 쓰더라도 빌드를 make, npm, Bazel, Buck2 중 무엇으로 도는지에 따라 빌드 시간이 10배 차이가 난다.

• Bazel: Google이 만든 모노레포 빌드 시스템. BUILD 파일에 정확한 입력/출력을 선언하고, 변경된 타깃만 다시 빌드. Remote Build Execution (RBE)으로 빌드를 클러스터에 분산. 학습 곡선이 가파르다.
• Buck2: Meta가 만든 Bazel 대체. Rust로 재구현, Bazel보다 2~5배 빠른 evaluation. 2023년 오픈소스화, 2026년에는 사용자 베이스가 빠르게 늘었다.
• Pants: Twitter/Stripe 출신 팀이 만든 Python/JVM 친화적 모노레포 빌드. Python 모노레포에서는 사실상 표준.
• Mill: Scala 빌드 시스템. SBT 대체. 더 단순한 모델로 빠르게 점유율 확대.

Bazel BUILD 파일의 예시는 다음과 같다(개념만).

load("@rules_go//go:def.bzl", "go_library", "go_test")

go_library(
    name = "server",
    srcs = ["server.go"],
    importpath = "example.com/server",
    deps = ["//pkg/db"],
)

go_test(
    name = "server_test",
    srcs = ["server_test.go"],
    embed = [":server"],
)

이 정의가 있으면 Bazel은 정확히 어떤 파일 변경이 어떤 타깃을 다시 빌드해야 하는지 안다. 1만 파일 모노레포에서 5개 파일만 바뀌었으면 그 5개에 영향받는 타깃만 빌드한다. 풀 빌드 30분짜리가 incremental 빌드 30초가 된다.

Nx · Turborepo · sccache — 빌드 캐시 가속

Bazel/Buck2는 강력하지만 학습 곡선이 가파르다. 대부분의 JS/TS 모노레포는 Nx나 Turborepo를 쓴다.

• Nx: Angular CLI 팀이 만든 모노레포 도구. JS/TS는 물론 Python/Java/Go 플러그인까지. Nx Cloud가 원격 캐시 + 분산 실행을 제공.
• Turborepo: Vercel이 인수한 Rust 기반 모노레포 빌더. Nx보다 단순한 모델, turbo.json에 task graph 정의. Vercel Remote Cache가 무료로 제공.
• Bazel Remote Cache: Bazel의 원격 캐시. S3/GCS 위에 자체 호스팅하거나 BuildBuddy, EngFlow 같은 SaaS를 쓴다.
• sccache: Mozilla가 만든 C++/Rust 컴파일러 캐시. ccache의 분산 버전.
• Rust + sccache + S3: Rust 빌드에서 사실상 표준 조합. 빌드 시간을 1/3 이하로 줄인다.

세 도구의 비교는 다음과 같다.

2026년 5월 기준 트렌드는 명확하다. 신규 JS 모노레포는 Turborepo로 시작하고, 규모가 커지면 Nx Cloud로 이동, 그래도 안 되면 Bazel로 간다.

Spinnaker · Harness · Octopus · Codefresh — 엔터프라이즈 CD

Argo CD가 GitOps의 사실상 표준이 됐지만, 엔터프라이즈 CD 시장은 따로 살아 있다.

• Spinnaker: Netflix가 만든 멀티 클라우드 CD. 2014년 출시 후 한때 표준이었지만 운영 복잡도가 높아 2026년에는 신규 도입이 줄었다. 기존 사용자(Netflix, Salesforce, Google)는 유지.
• Harness: 상업용 CD 플랫폼. ML 기반 카나리 검증, 코스트 인사이트, FF(Feature Flags), STO(보안 테스트)를 통합. Drone CI를 인수해 CI까지 흡수.
• Octopus Deploy: 윈도우/.NET 진영의 CD 강자. IIS, SQL Server, Active Directory 환경에 친화적.
• Codefresh: Argo 위에 상업 UI/관리 기능을 올린 SaaS. CNCF 친화적.

신규 K8s 네이티브 워크로드는 Argo CD, 윈도우/하이브리드는 Octopus, 멀티 클라우드 + 정책 중심은 Harness가 일반적 선택이다.

Codeship · Travis CI · Drone — 사라졌거나 사라지는 중

CI 시장은 짧은 시간에도 많이 바뀌었다. 2026년 5월 현재 다음 도구들은 사실상 신규 추천 대상이 아니다.

• Travis CI: 2010년대 OSS 표준. 2020년 사용 정책 변경 후 점유율 폭락. 2026년에는 거의 안 보인다.
• Codeship: CloudBees가 인수 후 2021년 사실상 sunset. 신규 가입 불가.
• Drone CI: Harness 인수 후 Drone 2.x는 유지 모드. 후속작 Gitness(Harness 오픈소스 SCM + CI)가 등장했지만 시장 점유는 미미.

이 도구들에 락인된 기존 사용자는 마이그레이션 계획을 세우는 게 2026년 표준이다.

Bitrise · Codemagic — 모바일 특화 CI

iOS/Android 앱 빌드는 일반 CI와 다른 제약이 많다. macOS 러너 필수, 코드 사이닝, App Store/Play Store 업로드, 다양한 시뮬레이터/디바이스 매트릭스. 이 영역에서는 모바일 특화 CI가 압도적이다.

• Bitrise: 가장 큰 모바일 CI. M2 macOS 러너, 사이닝 관리, Firebase Test Lab 연동까지 완비.
• Codemagic: Flutter 친화적. Flutter 팀이 공식 권장. iOS/Android/Web/Desktop 멀티 플랫폼 빌드를 하나의 YAML로.

일반 백엔드는 GitHub Actions, 모바일 앱은 Bitrise/Codemagic을 병행하는 조직이 많다.

TeamCity · Bamboo · Semaphore — 틈새의 강자

JetBrains TeamCity는 .NET/Java 중심 엔터프라이즈에 강하고, IDE(IntelliJ) 통합이 가장 매끄럽다. Atlassian Bamboo는 Jira/Confluence와 묶인 패키지로 일부 조직에서 운영 중이지만 Atlassian이 2024년부터 Bitbucket Pipelines로 무게중심을 옮겼다. Semaphore CI는 Apple Silicon + 빠른 부팅을 셀링 포인트로 한 SaaS다. 모두 GitHub Actions에 일반 시장을 내줬지만 특정 컨텍스트에서 살아 있다.

DORA 지표 — 2026년 평균은 어디인가

DORA(DevOps Research and Assessment)의 4개 지표는 2026년에도 업계 표준이다.

• Deployment Frequency: 얼마나 자주 배포하는가
• Lead Time for Changes: 코드 머지 → 프로덕션까지 시간
• Change Failure Rate: 배포 중 사고를 일으킨 비율
• MTTR (Mean Time to Restore): 사고 발생 시 복구까지 시간

2025 State of DevOps Report 요약(2026년 5월 발표 기준)은 다음과 같다.

전체 응답자 중 Elite는 약 18%, High는 30%, Medium은 35%, Low는 17%다. 2024년 대비 Elite 비율이 4%p 증가했고, 가장 큰 차이는 자동화 테스트 커버리지와 PR 머지 자동화의 깊이였다. 평균 빌드 시간은 8~15분 구간이 가장 많고, Elite 그룹은 5분 미만이 다수다.

한국 — 토스, 쿠팡의 엔지니어링 생산성

한국 빅테크의 2026년 CI 풍경은 다음과 같다.

• 토스: GitHub Enterprise + GitHub Actions + ARC(자체 호스팅 러너). 모노레포는 일부 Bazel/Turborepo 혼용. Argo CD로 K8s 배포. 사내 "토스 CI" 추상화 레이어가 GitHub Actions 위에 얹혀 있다.
• 쿠팡: 엔지니어링 생산성 팀이 사내 Buildkite-like 시스템을 운영(원래 Jenkins → 자체 시스템). 빌드 캐시는 Bazel RBE 기반. 컨테이너 이미지 캐시 노드를 리전별로 둔다.
• 카카오: Krew CI(내부) + GitHub Actions 혼용. 신규는 Actions 우선.
• 네이버: GitHub Enterprise + Actions가 표준. 일부 팀은 Argo Workflows로 ML 파이프라인.
• 우아한형제들: GitHub Actions + ARC. K8s는 EKS + Argo CD.
• 당근: GitHub Actions + Argo CD가 표준 조합.

공통점은 CI는 GitHub Actions, CD는 Argo CD, 빌드 가속은 모노레포 도구라는 3축 구조다.

일본 — 메르카리, 사이버에이전트, 쿡패드

일본도 GitHub Actions로 빠르게 수렴 중이지만 디테일이 다르다.

• 메르카리(Mercari): GitHub Actions + ARC + Argo CD. 모노레포는 일부 Bazel. CI 인프라 팀이 별도 조직으로 강하다.
• 사이버에이전트(CyberAgent): 사내 "CI culture"라는 표현을 쓸 만큼 CI/CD를 문화로 강조. GitHub Actions + GKE + Argo CD. 게임 사업부는 별도로 Jenkins/UnrealEngine 빌드 잡을 유지.
• 쿡패드(Cookpad): 2010년대 Jenkins 표준 → 2020년대 CircleCI → 2024년부터 GitHub Actions + ARC로 이동.
• DeNA, GREE, 라쿠텐: Jenkins 유산이 두껍지만 신규는 Actions/GitLab CI.
• LINE: 사내 표준 GitHub Enterprise + Actions + ARC. 모노레포는 일부 Buck2 평가.

일본은 한국보다 Jenkins 잔재가 두꺼운 편이고, 마이그레이션이 더 길게 진행 중이다.

GitHub Codespaces Prebuilds, Vercel Preview, Devbox, Garden — 인접 영역

CI/CD와 인접한 도구들이 2026년에는 분리 불가능한 수준으로 통합됐다.

• GitHub Codespaces Prebuilds: PR 생성 시 미리 빌드된 dev 컨테이너가 띄워진다. 코드 리뷰가 "환경 구성 30분 기다림"에서 "30초 만에 IDE 진입"으로 바뀌었다.
• Vercel Preview Deployments: PR마다 별도 URL의 프로덕션-동급 환경이 자동 배포된다. 디자이너/PM이 머지 전 검토. Next.js 진영의 사실상 표준 패턴.
• Devbox(Jetpack.io): Nix 기반 dev 환경 재현 가능 도구. CI에서도 같은 환경을 보장한다.
• Garden.io: K8s 개발 환경을 PR 단위로 자동 생성. dev/preview/prod를 하나의 그래프로 본다.

이 도구들은 단독 CI가 아니지만 CI/CD 워크플로의 일부로 들어간다. PR 머지 전 사람이 보는 환경, 머지 후 자동 배포 환경, 이 둘을 같은 파이프라인으로 처리한다.

벤더 비교표 — 한눈에 보는 2026년 CI/CD

전체 도구를 사용 맥락별로 비교하면 다음과 같다.

도구 선택은 단일 평가축으로 안 끝난다. 팀 규모, SCM 위치, 모노레포 여부, K8s 정도, 인프라 셀프호스팅 정책의 5축이 동시에 결정한다.

마이그레이션 전략 — Jenkins/Travis에서 GitHub Actions로

기존 Jenkins/Travis CI 인스턴스를 GitHub Actions로 옮길 때 2026년 모범 사례는 다음이다.

1. 인벤토리부터: 현재 실행 중인 잡 목록, 트리거, 시크릿, 자체 스크립트 위치를 표로 만든다.
2. 재사용 워크플로로 추상화: 100개 리포지토리가 동일 패턴이면 조직 레벨 Reusable Workflow 1개로 압축.
3. OIDC로 시크릿 제거: 새 워크플로는 처음부터 OIDC 페더레이션. PAT/AccessKey를 만들지 않는다.
4. 자체 호스팅 러너 결정: 월 빌드 시간 1만 분 이상이면 ARC/RunsOn 검토.
5. 점진 이전: 한 번에 다 옮기지 말고, 새 잡부터 Actions, 기존 잡은 Jenkins에 둔 채 점차 이주.
6. 메트릭으로 검증: DORA 4개 지표를 마이그레이션 전후로 측정한다. "더 좋아졌다"는 감이 아니라 숫자.

대부분의 조직이 이 6단계를 1~2년에 걸쳐 진행한다. 한 번에 모든 잡을 옮기면 거의 실패한다.

마치며 — 2026년 CI/CD 선택의 3가지 원칙

마지막으로 큰 그림을 정리한다.

1. CI와 CD를 분리하라. 한 도구가 다 하려고 하면 둘 다 어중간해진다. CI는 GitHub Actions(혹은 Buildkite/CircleCI), CD는 Argo CD/Harness/Spinnaker처럼 다른 도구를 쓴다.
2. 빌드 시스템에 투자하라. CI를 아무리 빠른 도구로 바꿔도, 빌드 자체가 30분이면 30분이다. Bazel/Buck2/Nx/Turborepo + 원격 캐시가 진짜 가속이다.
3. 보안은 OIDC, 핀은 SHA, 권한은 최소화. 2024년 tj-actions 사건이 보여줬듯, CI는 공급망 공격의 1순위다. SHA 핀과 OIDC, 최소 권한이 2026년 신규 시스템의 기본값이다.

GitHub Actions가 사실상 시장을 가져갔다는 건 분명한 사실이지만, "다 GitHub Actions를 쓴다"가 정답은 아니다. Shopify는 Buildkite가, ML 팀은 Argo Workflows가, 모바일 팀은 Bitrise가, K8s 네이티브 팀은 Tekton이 더 맞을 수 있다. 핵심은 레이어를 분리하고, 각 레이어에서 최적 도구를 고르고, 메트릭으로 결정한다는 원칙이다.

References

• GitHub Actions Docs: docs.github.com/actions
• Buildkite Docs: buildkite.com/docs
• CircleCI Docs: circleci.com/docs
• GitLab CI/CD Docs: docs.gitlab.com/ee/ci
• Jenkins Docs: jenkins.io/doc
• Tekton: tekton.dev
• Argo Project: argoproj.github.io
• Earthly: earthly.dev
• Dagger: dagger.io
• Nx: nx.dev
• Turborepo: turbo.build
• Bazel: bazel.build
• DORA: dora.dev
• Actions Runner Controller: github.com/actions/actions-runner-controller
• SLSA Framework: slsa.dev