CI/CD 플랫폼 2026 완벽 가이드 — GitHub Actions·GitLab CI·CircleCI·Buildkite·Dagger·Earthly·Drone·Argo CD·Flux 심층 분석

프롤로그 — CI/CD는 다시 정치다

2026년 어느 팀에서나 흔히 보이는 풍경이 있다. 플랫폼 팀이 "전사 표준은 GitHub Actions"라고 발표하면, 데이터 팀은 "우리 모노레포는 Buildkite로 돌리는 게 빠르다"라고 반박하고, SRE 팀은 "그런데 배포는 Argo CD로 한다"라고 끼어든다. 결국 CI 빌드는 GitHub Actions, 에이전트는 self-hosted runner, 캐시는 Turborepo Remote Cache, 배포는 Argo CD, 점진적 배포는 Flagger 같은 다층 구조가 굳어진다.

이게 2026년 CI/CD 현실이다. 한 도구가 모든 걸 한다는 환상은 깨졌고, 대신 우리는 "어떤 조합이 우리 팀에 맞나"를 매번 결정한다. 그리고 그 결정은 단순한 기술 선택이 아니라 비용·보안·속도·플랫폼 정치의 함수다.

이 글은 2026년 현재 CI/CD 플랫폼 전체 지도를 그린다. SaaS 빅4(GitHub Actions·GitLab CI·CircleCI·Buildkite), 컨테이너 네이티브 신세대(Dagger·Earthly·Drone·Harness), GitOps(Argo CD·Flux·Flagger), 그리고 K8s 네이티브(Tekton·OpenShift Pipelines), Terraform CI/CD(Spacelift·Atlantis·Pulumi Deployments)까지 — 각 도구의 위치와 비용과 손익분기점까지.

1장 · CI/CD 플랫폼 전체 지도 — 2026년 분류학

먼저 큰 그림. CI/CD라는 용어 하나가 너무 많은 것을 포함한다. 2026년 기준 흔한 분류는 이렇다.

레이어	역할	대표 도구
SaaS CI 빅4	Git push → 빌드/테스트	GitHub Actions, GitLab CI, CircleCI, Buildkite
컨테이너 네이티브 CI	컨테이너로 모든 단계 표현	Dagger, Earthly, Drone, Harness CI, Codefresh
K8s 네이티브 CI	K8s 안에서 파이프라인	Tekton, OpenShift Pipelines, Argo Workflows
CD / GitOps	Git을 진실의 원천으로 K8s 동기화	Argo CD, Flux, Flagger
Terraform CI/CD	인프라 변경의 안전한 적용	Spacelift, Atlantis, Terragrunt, env0
클라우드 매니지드	클라우드 종속 통합 패키지	AWS CodePipeline, Azure Pipelines, Google Cloud Build/Deploy
엔터프라이즈 전통강자	온프렘·복잡성·플러그인	Jenkins, TeamCity, Bamboo, GoCD
실행 인프라	runner와 캐시	BuildJet, Depot, Blacksmith, Turborepo Cache

핵심 통찰: 레이어가 다르면 경쟁이 아니라 조합이다. GitHub Actions와 Argo CD는 경쟁자가 아니다. Dagger와 Tekton은 같은 자리를 다툰다. 비교는 같은 레이어 안에서 해야 의미가 있다.

2장 · GitHub Actions — 사실상의 표준이 된 이유

2026년 신규 프로젝트의 70% 이상이 GitHub Actions로 시작한다(JetBrains DevEcosystem 2025 추정). 이유는 단순하다 — GitHub에 코드가 있고, 작은 워크플로는 yaml 하나로 충분히 표현되고, 마켓플레이스에 액션이 2만 개 넘게 쌓여 있다.

2026년 기준 새로 굳어진 패턴 몇 가지.

Larger runners — 4·8·16·32·64 vCPU runner를 GitHub이 직접 제공. ARM64 runner(Cobalt 100 기반)와 Apple Silicon runner(M2·M3)도 정식.
Reusable workflows + composite actions — 사내 표준 파이프라인은 reusable workflow로 추출, 작은 묶음 단계는 composite action으로.
OIDC for cloud — 장기 자격증명 대신 ID 토큰 교환으로 AWS/GCP/Azure 접근. 2024년 이후 사실상 기본.
Immutable releases / Artifact attestations — actions/attest-build-provenance로 SLSA Level 3까지 자동.
Self-hosted runners — 비용·보안·하드웨어 요구로 self-host가 다시 늘었다. 다음 장에서 따로.

빠지기 쉬운 함정도 있다.

${{ 템플릿 표현식 안에서 사용자 입력을 그대로 쓰면 명령어 인젝션. env:로 받아서 쓰는 패턴이 안전하다.
pull_request_target 트리거는 secret에 접근 가능하지만 PR 코드를 그대로 체크아웃하면 위험. 정책으로 막는다.
무료 분당 quota가 빠르게 소진된다. 비공개 저장소는 분당 단가가 빠르게 누적되니 self-host 손익분기점을 미리 계산하자.

3장 · GitLab CI/CD 17.x — 풀스택 DevSecOps의 한 묶음

GitLab 17.x(2024 후반 출시)는 CI/CD를 단순한 워크플로 실행기가 아니라 DevSecOps 풀스택의 한 묶음으로 포지셔닝한다.

.gitlab-ci.yml 한 파일에 빌드·테스트·SAST·DAST·컨테이너 스캐닝·라이선스 검사·배포를 다 표현.
GitLab Runner — Docker·Kubernetes·Shell·SSH 다양한 executor 지원.
Auto DevOps — 컨벤션 기반의 자동 파이프라인. 스타트업에서 가성비 좋음.
GitLab Duo — AI 기반 코드 리뷰·테스트 생성·취약점 설명. 2026년 들어 Duo Workflow가 베타에서 GA로.
Continuous Vulnerability Scanning(CVS) — main 브랜치를 주기적으로 다시 스캔해서 새로 공개된 CVE를 잡는다.
Compute minutes — SaaS 플랜에서 minute 단위 과금. self-managed에서는 무제한이지만 인프라 비용이 든다.

GitHub Actions가 "Git + 워크플로의 단순함"을 무기로 한다면, GitLab CI는 "한 벤더에서 끝나는 풀스택의 통합"이 무기다. 규제 산업(금융·공공·헬스케어)에서 GitLab self-managed 점유율이 여전히 높은 이유.

4장 · CircleCI 2.x — orbs와 병렬 실행의 강자

CircleCI는 GitHub Actions 등장 이후 점유율이 줄었지만, 여전히 monorepo·다언어 프로젝트에서 강하다.

Orbs — 재사용 가능한 yaml 묶음. 마켓플레이스에 3천 개 이상.
Parallelism + Test Splitting — 한 job을 N개의 컨테이너로 자동 분할, 테스트 시간 기반으로 균등 분배.
Matrix builds — 언어·OS·DB 조합을 격자 형태로 빠르게 표현.
CircleCI Sphere(TestGPT) — 실패한 테스트의 원인 분석·수정 제안 AI 기능.
Self-hosted runners — 보안 환경용. GPU runner도 정식.

CircleCI를 선택하는 팀의 흔한 이유는 "대규모 테스트 스위트의 병렬 실행이 가장 잘 된다"는 평. 단점은 GitHub Actions 대비 단순한 작은 워크플로에는 과해 보인다는 것.

5장 · Buildkite — agent는 내 인프라에서

Buildkite의 모델은 GitHub Actions와 다르다. 컨트롤 플레인(웹 UI·파이프라인 정의·로그 집계)은 Buildkite의 SaaS에서, agent(실제 빌드 실행기)는 우리 인프라에서 돈다. BYO(Bring Your Own) 컴퓨트 모델이다.

이게 왜 중요한가:

빌드가 우리 VPC 안에서 돈다 → 내부 리소스(DB·내부 레지스트리)에 안전하게 접근.
분당 단가가 없다 — agent를 우리가 운영하는 만큼만 비용.
거대 모노레포에서 빠르다 — 캐시·도커 레이어가 우리 인프라에 그대로 남는다.

Shopify·Airbnb·Pinterest 같은 대규모 모노레포 팀에서 인기. 단점은 agent 운영 자체가 일이 된다 — autoscaler·캐시 정책·하드웨어 관리.

6장 · Dagger — programmable CI라는 새로운 카테고리

Dagger는 Docker 공동 창업자 Solomon Hykes가 시작한 프로젝트로, 2024~2025년 사이에 빠르게 자리 잡았다. 핵심 아이디어는 단순하다 — CI 파이프라인을 yaml이 아니라 코드로 작성한다.

Go·TypeScript·Python·PHP·Java SDK 제공.
모든 단계는 컨테이너 안에서 실행 — 로컬 머신에서 돌린 결과가 CI에서도 같다. "It works on my machine"의 종말.
BuildKit 기반 — 캐시·병렬화가 빠르다.
Dagger Cloud — SaaS trace·timeline·캐시 hit율 시각화.
GitHub Actions·GitLab CI·Jenkins 위에서 그대로 돈다 — 기존 CI를 대체하는 게 아니라 안에서 호출한다.

Dagger의 진짜 매력은 "yaml 지옥에서 벗어남"이다. 복잡한 if/else와 매트릭스 조합을 yaml로 표현하다 보면 한계가 오는데, Go/TypeScript 함수로 짜면 IDE 자동완성·타입 체크·단위 테스트가 가능하다.

7장 · Earthly — 모노레포에 친화적인 BuildKit

Earthly는 다른 각도에서 같은 문제를 푼다. Earthfile이라는 단일 파일에 빌드 스텝을 선언적으로 적되, 안쪽은 BuildKit으로 컨테이너 단위 실행.

Dockerfile 문법과 비슷 — 진입 장벽이 낮다.
캐시·병렬화·모노레포 친화 — +target 형태로 의존성을 명시.
로컬과 CI에서 같은 명령어 실행 — 재현성 확보.
Earthly Satellites — 매니지드 BuildKit runner(SaaS).

Dagger와 Earthly는 비슷한 영역을 다투지만 철학이 다르다. Dagger는 "코드로 짠다", Earthly는 "Dockerfile스럽지만 더 강력하게 짠다". 팀의 정서에 맞춰 고른다.

8장 · Drone 2.x와 Harness CI — Harness 우산 아래

Drone은 컨테이너 네이티브 CI의 초창기 강자였고, 2020년 Harness에 인수됐다. 지금은 두 갈래로 살아 있다.

Drone 2.x(OSS) — yaml 기반, 컨테이너 단위 실행, 가볍다. self-host에 강하다.
Harness CI(매니지드) — Drone 위에 AI 기능(테스트 회귀 예측·실패 RCA·드리프트 감지)을 얹은 SaaS.

Harness의 무기는 AI Test Intelligence — 변경 코드와 과거 테스트 결과를 분석해서 PR마다 돌릴 테스트를 자동 선별. 큰 모노레포에서 테스트 시간을 30~70% 줄였다는 사례 보고가 흔하다.

9장 · Argo CD — GitOps for Kubernetes

CI가 빌드라면 CD는 배포다. 2026년 K8s 위의 CD에서 사실상의 표준은 Argo CD다.

GitOps 원칙 — Git이 진실의 원천. 클러스터 상태는 Git의 manifest를 따라간다.
ApplicationSet — 같은 차트를 여러 클러스터·환경에 자동 전파.
Argo CD Image Updater — 새 이미지 태그를 감지해 Git을 자동 업데이트.
Argo Rollouts — Canary·Blue-Green·점진 배포.
Argo Workflows — K8s 위 workflow 엔진(CI 보조로도 활용).

장점은 모든 변경이 Git 커밋으로 남는다 → 감사·롤백·재현이 쉽다. 단점은 K8s 종속 — VM·서버리스에는 직접 안 맞는다.

10장 · Flux CD와 Flagger — 또 다른 GitOps

Flux는 Argo CD와 비슷한 일을 하지만 철학이 다르다.

Flux는 controller 묶음 — Source·Kustomize·Helm·Notification·Image Automation이 각각의 컨트롤러.
Argo CD는 UI 중심·앱 중심, Flux는 CRD 중심·플랫폼 중심.
Flagger — Flux의 점진 배포 도구. Argo Rollouts와 같은 자리.

CNCF graduated 프로젝트인 점·SUSE/Microsoft 후원·composability가 강한 점이 Flux의 매력. Argo CD는 GUI 친화·앱 카탈로그 친화, Flux는 플랫폼 빌더 친화다.

11장 · Jenkins 2.x·Jenkins X·Tekton — 전통강자와 K8s 네이티브

Jenkins는 죽지 않는다 — 적어도 엔터프라이즈에서는.

Jenkins 2.x — 선언적 파이프라인, Blue Ocean UI, 2만 개 플러그인.
Jenkins X — K8s 네이티브 Jenkins. 사실상 별도 프로젝트화.
AWS Jenkins on EKS — 매니지드 Jenkins 옵션.

Jenkins의 강점은 플러그인 생태계의 깊이와 온프렘 전통. 약점은 단일 master의 SPOF, 플러그인의 보안 부담, 모던 UI 부재.

Tekton은 K8s 네이티브 CI의 표준 후보. CRD로 Task·Pipeline·PipelineRun을 정의하고, Red Hat OpenShift Pipelines는 Tekton 기반의 엔터프라이즈 패키지다. K8s를 이미 운영하는 팀에 자연스럽다.

12장 · Spacelift·Atlantis·Pulumi Deployments — Terraform CI/CD

인프라 코드(Terraform·OpenTofu·Pulumi)의 CI/CD는 별도 카테고리다. 일반 CI로도 돌릴 수는 있지만, state·plan·apply의 안전한 흐름을 만들기는 어렵다.

Atlantis(OSS) — PR 안에서 atlantis plan·atlantis apply 코멘트로 워크플로. self-host.
Spacelift — Atlantis의 SaaS 버전 + policy as code. OPA 통합.
env0 — 매니지드 Terraform 클라우드 + RBAC + 비용 추정.
Terragrunt — Terraform 코드 자체의 DRY 도구지만 CI 흐름에서 함께 쓰인다.
Pulumi Deployments — Pulumi 전용 매니지드 실행/스케줄러.

핵심: 일반 CI로 terraform apply 돌리지 말 것. state lock·동시성·승인 흐름·드리프트 감지를 한 도구가 책임지게 한다.

13장 · 매니지드 CI 그 외 — Codefresh·GoCD·Octopus·TeamCity·Bitbucket

상황별로 더 잘 맞는 도구들.

Codefresh — K8s/GitOps에 특화한 매니지드. Argo CD를 SaaS로 묶어준다.
Octopus Deploy — Windows/엔터프라이즈 배포에 강함. 변수 치환·환경 관리가 디테일.
GoCD(ThoughtWorks) — value stream map 시각화가 강점. 점유율은 작지만 충성도 높다.
TeamCity 2024.x(JetBrains) — 빌드 체인·메타 러너가 강력. JetBrains 생태계 친화.
Bitbucket Pipelines 2026(Atlassian) — Bitbucket Cloud 통합. Jira·Confluence와 단일 묶음.
Garden.io — 로컬 dev와 CI의 일관성에 집중한 도구. 마이크로서비스 다중 환경에 강함.

14장 · 클라우드 매니지드 CI — AWS·Azure·GCP

클라우드 종속이라도 통합 가치가 크면 합리적인 선택이 된다.

AWS CodePipeline + CodeBuild + CodeDeploy — IAM·VPC·S3 깊은 통합. Lambda·ECS·EKS 배포가 편하다. UI는 단순하지만 진화가 느리다.
Azure DevOps Pipelines / Azure Pipelines — Microsoft 생태계의 강점. yaml + classic 두 모드. 무료 분이 비교적 후하다.
Google Cloud Build / Cloud Deploy — GCR/GAR·GKE·Cloud Run 깊은 통합. Cloud Deploy는 Argo CD 스타일의 점진 배포.

선택 기준: 클라우드 한 곳에 90% 이상 묶여 있다면 매니지드 CI가 합리적. 멀티 클라우드/온프렘이 섞이면 GitHub Actions나 GitLab 같은 클라우드 중립 CI가 낫다.

15장 · self-hosted runner — BuildJet·Namespace·Blacksmith·RunsOn·Depot·Ubicloud

2026년의 새 흐름. GitHub-hosted runner의 분당 단가가 비싸지자, GitHub Actions와 호환되는 외부 runner SaaS가 한 카테고리를 이뤘다.

BuildJet — 가격 대비 빠른 머신. 8 vCPU runner가 GitHub의 절반 가격.
Namespace — instant runner와 KVM 기반 격리. 빠른 부팅이 장점.
Blacksmith — Hetzner 베어메탈 위. 가격 우위가 크다.
RunsOn — 우리 AWS 계정 안에서 runner 자동 기동. EC2 spot 활용.
Depot — BuildKit 베이스 컨테이너 빌드 가속에 강점. Docker build와 GitHub Actions 양쪽.
Ubicloud — OSS 클라우드 인프라 위에서 runner. Hetzner와 비슷한 가격대.

손익분기점 감각: GitHub-hosted Linux 분당 0.008 USD 기준, 월 5만 분 이상이면 외부 runner SaaS가 보통 더 싸다. 우리 회사 AWS 계정 안에서 spot으로 돌리는 RunsOn은 분당 0.001~0.003 USD까지 떨어진다.

16장 · 캐시 인프라 — Turborepo·Nx Cloud·Bazel·sccache·Mise

CI 속도의 절반은 캐시다. 2026년 흔히 쓰이는 캐시 도구.

Turborepo Remote Cache — JS/TS 모노레포의 표준. Vercel SaaS 또는 self-host(open spec).
Nx Cloud — Nx 모노레포용. 분산 task 실행·affected 계산.
Bazel Remote Cache — Google 출신, 대규모 모노레포의 정점. 학습 곡선이 가파르다.
sccache — Rust/C++ 컴파일러 캐시. S3 백엔드로 팀 단위 공유.
Mise(rtx 후신) — runtime 버전 관리 + tool cache. asdf 대체로 자리 잡았다.
GitHub Actions Cache(builtin) — 기본이지만 10 GB/repo 제한이 빨리 도달.

캐시가 잘 작동하면 PR 빌드 시간이 30분 → 4분으로 줄어든다. 캐시가 깨지면 그 반대다 — 그래서 캐시 키 디자인·invalidation 정책이 평소엔 안 보이지만 결정적이다.

17장 · 컨테이너 레지스트리 — Docker Hub·GHCR·ECR·GAR·Harbor·Zot

빌드의 결과는 보통 이미지다. 어디에 푸시할지도 중요하다.

Docker Hub — 2026년 들어 무료 pull 제한이 더 빡빡. public 이미지 host로는 여전히 표준.
GitHub Container Registry(GHCR) — GitHub Actions와 완전 통합. 비공개 이미지의 첫 선택.
Amazon ECR / Public ECR — AWS 계정 안의 표준. EKS·ECS·Lambda 깊은 통합.
Google Artifact Registry(GAR) — GCR의 후신. Docker·npm·Maven·Helm 한 레지스트리.
Harbor — CNCF graduated. 온프렘/사내 레지스트리의 사실상 표준.
Zot — OCI 네이티브 OSS 레지스트리. Cosign·SBOM이 1급 시민.

18장 · 서명·SBOM·SLSA — 공급망 보안의 3대 축

2024년 이후 빠르게 표준화된 영역.

Cosign(Sigstore) — OIDC 기반 keyless 서명. GitHub Actions OIDC와 잘 맞는다.
Notary v2 / Notation — OCI 네이티브 서명. AWS Signer 등이 채택.
SBOM — Software Bill of Materials. SPDX(리눅스 재단)·CycloneDX(OWASP)가 양대 포맷.
SLSA Level 1~4 — 공급망 무결성 등급. Level 3+가 2026년의 사실상 권장.
in-toto attestations — 빌드 출처 증명.

GitHub Actions의 actions/attest-build-provenance, GitLab의 SLSA pipeline, Google의 Binary Authorization이 이 묶음을 한 번에 처리해주는 통합 도구다.

19장 · AI in CI — 2026년에 새로 보이는 것들

CI에 AI가 들어오는 방식.

CircleCI Sphere / TestGPT — 실패 분석 + 수정 제안.
GitLab Duo Workflow — 코드 리뷰·테스트 생성·취약점 설명.
Harness AI Test Intelligence — PR 코드 변경 기반 테스트 선별.
Datadog Test Optimization — flaky test 감지·재실행 정책·테스트 시간 회귀.
Meta Predictive Test Selection — 자체 모델로 회사 내부에서만 운영(논문 공개).
GitHub Copilot Workspace + Actions — PR 자동 작성·자동 수정·자동 리뷰.

AI in CI는 한마디로 "무엇을 안 돌릴지를 결정하는 AI"다. 모든 PR에 전체 테스트를 돌리지 않고 영향받은 것만 돌리는 게 자원 절약의 핵심이고, 그걸 사람 손으로 분류하기는 어렵다.

20장 · 한국 빅테크 CI/CD 풍경 — 2026년

한국 빅테크의 흔한 패턴.

Coupang — GitHub Enterprise + GitHub Actions, self-hosted runner를 사내 K8s에. Argo CD로 EKS 배포. 모노레포는 Bazel.
NAVER Cloud DevOps — 자체 DevOps 플랫폼(NCP DevOps Pipeline). 사내 표준이지만 일부 팀은 GitHub Enterprise.
Kakao Pages CI — GitHub Actions + 자체 K8s + Argo CD. Spinnaker에서 Argo CD로 이전한 사례가 많다.
LINE SRE 팀 — Drone에서 GitHub Actions로 전환. 글로벌 cross-region 배포는 자체 도구.
배민(Baemin) / 우아한형제들 — GitHub Actions + AWS CodeDeploy + Spinnaker.
토스(Toss) — GitHub Enterprise + 자체 PaaS(Toss Platform). 배포는 Argo CD + 자체 control plane.

공통 패턴: GitHub Enterprise + Actions + self-hosted runner + Argo CD가 빠르게 표준화되는 중. Jenkins는 레거시 시스템에 남고, 신규는 거의 안 쓴다.

21장 · 일본 빅테크 CI/CD 풍경 — 2026년

일본 빅테크는 한국보다 도구 다양성이 큰 편이다.

Mercari — GHE + Actions가 메인. self-hosted runner를 GKE에. CD는 Argo CD + Spinnaker 혼용.
CyberAgent — 다양한 자회사가 각자 도구 선택. Buildkite·CircleCI·GitHub Actions가 공존.
Rakuten DevOps — Jenkins에서 GitLab CI로 이전이 진행 중. 규제 산업 자회사는 GitLab self-managed.
DeNA — GitHub Actions + AWS CodePipeline + 자체 internal platform.
Pixiv — GitHub Enterprise + Actions + self-hosted runner. 캐시는 자체 인프라.
SmartHR — Buildkite + Argo CD. 모노레포 빌드 가속에 Buildkite를 적극 활용.

흥미로운 점: 일본 기업은 on-prem 비중이 한국보다 약간 높고, GitLab self-managed 비중도 높은 편. 규제·보안 요건이 더 보수적인 경우가 많다.

22장 · 비용 — 분당 단가와 self-host 손익분기점

2026년 5월 기준 대략의 분당 단가(USD/min, Linux 기본 spec).

GitHub-hosted Linux 2-core: 0.008
GitHub-hosted Linux 8-core(Larger): 0.032
GitHub-hosted Apple Silicon: 0.16
GitLab.com saas-linux-medium: 0.01 정도
CircleCI medium: 0.005
Buildkite: agent 운영 비용만(분당 단가 없음)
BuildJet 8-core: 0.012
Blacksmith 8-core: 0.008
RunsOn(우리 AWS): 0.001~0.003 (spot 활용)

조직 규모별 권장:

월 1만 분 이하: GitHub Actions hosted가 가장 합리적. self-host는 운영 비용이 더 비싸다.
월 5만~30만 분: 외부 runner SaaS(BuildJet·Blacksmith) 또는 우리 AWS에서 RunsOn으로 50% 이상 절감.
월 100만 분 이상: 자체 K8s runner + 캐시 + 레지스트리. 단, 전담 인력 1~2명이 필요.

캐시까지 같이 본 후의 진짜 비용 = (분당 단가 × 분) + (캐시 인프라 비용) + (운영 시간 비용). 분당 단가만 보면 늘 잘못된 결정을 한다.

23장 · 흔한 함정 10가지

실패 패턴 모음.

secret을 stdout에 흘리기 — 마스킹은 만능이 아니다. set -x와 함께 쓰지 말 것.
pull_request_target + 외부 코드 체크아웃 — 시크릿 탈취의 단골 경로.
단일 거대 워크플로 — yaml 1000줄. 분기·반복·매트릭스가 다 한 곳. 디버깅 지옥.
캐시 키가 너무 광범위 — 한 사람의 변경이 다른 사람의 빌드를 깬다.
캐시 키가 너무 좁다 — 캐시가 거의 안 맞아 의미 없어진다.
CI에서 prod 자격증명을 직접 사용 — OIDC + 임시 자격증명으로 갈아탈 것.
apply를 누구나 누를 수 있다 — Terraform/K8s 배포에 승인 흐름 없음.
테스트가 flaky해서 재실행이 일상 — 근본 원인을 안 잡으면 신뢰가 0이 된다.
배포 후 검증이 없다 — 헬스체크·smoke test 없이 traffic을 다 넘긴다.
롤백이 수동 — 사고 시 평균 복구 시간이 10배가 된다.

24장 · 도구를 고르는 7가지 기준

요약하면 결국 이 7가지를 본다.

Git 호스팅과의 통합 — GitHub면 Actions가 99% 정답.
K8s 비중 — 높으면 Argo CD/Flux + Tekton 후보.
모노레포 규모 — 큰 모노레포는 Buildkite·Earthly·Bazel·Nx Cloud 조합이 강하다.
규제 요건 — self-managed/온프렘이 필수면 GitLab self-managed·Jenkins·Drone.
클라우드 종속도 — 한 클라우드 90% 이상이면 클라우드 매니지드도 합리.
팀 규모 — 작은 팀은 SaaS, 큰 팀은 self-host + 전담.
비용 모델 — 분당 단가 + 캐시 + 운영 시간 모두 합산해서 본다.

선택의 본질: "어떤 도구가 최고인가"가 아니라 "우리 제약 안에서 어떤 조합이 합리적인가"다. 그리고 그 조합은 1~2년마다 다시 평가해야 한다 — 가격도, 도구도 빠르게 변한다.

에필로그 — CI/CD는 플랫폼의 신경계다

이 글의 한 문장 요약: CI/CD는 도구 선택이 아니라 플랫폼 디자인이다.

2026년의 CI/CD는 어떤 도구를 쓰느냐의 문제가 아니라, 빌드 → 테스트 → 서명 → 배포 → 검증 → 롤백이라는 흐름을 어떻게 신뢰 가능하게 만들 것이냐의 문제다. GitHub Actions든 GitLab CI든, Argo CD든 Flux든, 한 도구가 답이 아니다. 답은 그 도구들이 만든 신경계가 우리 팀의 의사결정 속도를 결정한다는 사실 자체에 있다.

PR이 푸시되고 5분 안에 신뢰할 만한 시그널이 돌아오면 팀의 속도가 다르다. 30분이면 사람들이 컨텍스트를 잃는다. 1시간이면 사람들이 CI를 우회하기 시작한다. 그래서 CI/CD는 도구가 아니라 문화다.

다음 10년의 CI/CD는 AI가 점점 더 많은 결정을 가져갈 것이다 — 무엇을 안 돌릴지, 무엇이 깨졌는지, 무엇을 자동 수정할지. 그러나 그 결정의 안전선을 긋는 건 여전히 사람의 일이다. 그래서 CI/CD를 잘 만든다는 건 자동화의 양이 아니라 자동화의 경계를 잘 그리는 것이다.

12개 항목 체크리스트

PR 시그널이 10분 이내에 돌아오나?
캐시 hit율을 측정하고 있나?
self-host vs SaaS 비용을 계산해본 적이 있나?
OIDC로 cloud 자격증명을 받고 있나(장기 키 X)?
빌드 아티팩트에 서명을 붙이나(Cosign 등)?
SBOM이 매 빌드마다 생성되나?
배포가 GitOps(Argo/Flux)로 선언적인가?
canary/blue-green 같은 점진 배포가 있나?
실패 시 자동 롤백이 동작하나?
flaky test를 격리하는 정책이 있나?
secret을 환경변수로 받고 stdout에 흘리지 않나?
도구 선택을 1~2년마다 재평가하는 자리가 있나?

안티패턴 10가지

한 도구가 다 한다는 환상 — 답은 항상 조합이다.
분당 단가만 보고 결정 — 캐시·운영 비용을 빼먹는다.
yaml 1000줄 워크플로 — 분기·반복은 코드로 빼라.
PR 안에서 prod 배포 — 승인 흐름과 분리하라.
secret을 평문으로 출력 — set -x 금지.
flaky test 재실행으로 무마 — 근본 원인을 잡아라.
캐시 invalidation 없는 빌드 — 깨진 캐시가 영원히 산다.
배포 후 검증 없음 — smoke test는 필수.
롤백 절차가 문서로만 — 자동화하라.
CI/CD 평가를 한 번도 안 다시 함 — 1~2년마다 재평가.

다음 글 예고

다음 글 후보: GitOps 깊게 파기 — Argo CD vs Flux의 진짜 차이, 모노레포 빌드 가속화 — Bazel·Buck2·Turborepo·Nx 비교, 공급망 보안 — Cosign·SBOM·SLSA 실전 적용기.

"CI/CD는 도구가 아니라 신경계다. 신경계의 속도가 조직의 속도를 결정한다."

— CI/CD 플랫폼 2026, 끝.