Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 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 페더레이션 + 매트릭스 + 재사용 워크플로를 결합한 실전 워크플로 예시는 다음과 같다.

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:

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

arguments:

parameters: [{name: script, value: 'make build'}]

- name: test

dependencies: [build]

arguments:

parameters: [{name: script, value: 'make test'}]

- name: deploy

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 위에서 컨테이너를 그래프로 실행한다.

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 이하로 줄인다.

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

|---|---|---|---|---|---|

| Bazel + RBE | 모든 언어 | 자체/SaaS | O | 가파름 | 1만+ 파일 |

| Buck2 | 모든 언어 | Bazel 호환 | O | 가파름 | 1만+ 파일 |

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월 발표 기준)은 다음과 같다.

|---|---|---|---|---|

| High | 주 1회~월 수회 | 1일~1주 | 5~10% | 1일 이내 |

| Medium | 월 1회~분기 | 1주~1개월 | 10~15% | 1일~1주 |

| Low | 분기 이하 | 1~6개월 | 15%+ | 1주+ |

전체 응답자 중 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

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

|---|---|---|---|---|

| Bitrise | CI | 모바일 | SaaS | X |

도구 선택은 단일 평가축으로 안 끝난다. **팀 규모, 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](https://docs.github.com/en/actions)

- Buildkite Docs: [buildkite.com/docs](https://buildkite.com/docs)

- CircleCI Docs: [circleci.com/docs](https://circleci.com/docs)

- GitLab CI/CD Docs: [docs.gitlab.com/ee/ci](https://docs.gitlab.com/ee/ci/)

- Jenkins Docs: [jenkins.io/doc](https://www.jenkins.io/doc/)

- Tekton: [tekton.dev](https://tekton.dev/)

- Argo Project: [argoproj.github.io](https://argoproj.github.io/)

- Earthly: [earthly.dev](https://earthly.dev/)

- Dagger: [dagger.io](https://dagger.io/)

- Nx: [nx.dev](https://nx.dev/)

- Turborepo: [turbo.build](https://turbo.build/)

- Bazel: [bazel.build](https://bazel.build/)

- DORA: [dora.dev](https://dora.dev/)

- Actions Runner Controller: [github.com/actions/actions-runner-controller](https://github.com/actions/actions-runner-controller)

- SLSA Framework: [slsa.dev](https://slsa.dev/)