필사 모드: 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가지
실패 패턴 모음.
1. **secret을 stdout에 흘리기** — 마스킹은 만능이 아니다. set -x와 함께 쓰지 말 것.
2. **`pull_request_target` + 외부 코드 체크아웃** — 시크릿 탈취의 단골 경로.
3. **단일 거대 워크플로** — yaml 1000줄. 분기·반복·매트릭스가 다 한 곳. 디버깅 지옥.
4. **캐시 키가 너무 광범위** — 한 사람의 변경이 다른 사람의 빌드를 깬다.
5. **캐시 키가 너무 좁다** — 캐시가 거의 안 맞아 의미 없어진다.
6. **CI에서 prod 자격증명을 직접 사용** — OIDC + 임시 자격증명으로 갈아탈 것.
7. **`apply`를 누구나 누를 수 있다** — Terraform/K8s 배포에 승인 흐름 없음.
8. **테스트가 flaky해서 재실행이 일상** — 근본 원인을 안 잡으면 신뢰가 0이 된다.
9. **배포 후 검증이 없다** — 헬스체크·smoke test 없이 traffic을 다 넘긴다.
10. **롤백이 수동** — 사고 시 평균 복구 시간이 10배가 된다.
24장 · 도구를 고르는 7가지 기준
요약하면 결국 이 7가지를 본다.
1. **Git 호스팅과의 통합** — GitHub면 Actions가 99% 정답.
2. **K8s 비중** — 높으면 Argo CD/Flux + Tekton 후보.
3. **모노레포 규모** — 큰 모노레포는 Buildkite·Earthly·Bazel·Nx Cloud 조합이 강하다.
4. **규제 요건** — self-managed/온프렘이 필수면 GitLab self-managed·Jenkins·Drone.
5. **클라우드 종속도** — 한 클라우드 90% 이상이면 클라우드 매니지드도 합리.
6. **팀 규모** — 작은 팀은 SaaS, 큰 팀은 self-host + 전담.
7. **비용 모델** — 분당 단가 + 캐시 + 운영 시간 모두 합산해서 본다.
선택의 본질: **"어떤 도구가 최고인가"가 아니라 "우리 제약 안에서 어떤 조합이 합리적인가"**다. 그리고 그 조합은 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개 항목 체크리스트
1. PR 시그널이 10분 이내에 돌아오나?
2. 캐시 hit율을 측정하고 있나?
3. self-host vs SaaS 비용을 계산해본 적이 있나?
4. OIDC로 cloud 자격증명을 받고 있나(장기 키 X)?
5. 빌드 아티팩트에 서명을 붙이나(Cosign 등)?
6. SBOM이 매 빌드마다 생성되나?
7. 배포가 GitOps(Argo/Flux)로 선언적인가?
8. canary/blue-green 같은 점진 배포가 있나?
9. 실패 시 자동 롤백이 동작하나?
10. flaky test를 격리하는 정책이 있나?
11. secret을 환경변수로 받고 stdout에 흘리지 않나?
12. 도구 선택을 1~2년마다 재평가하는 자리가 있나?
안티패턴 10가지
1. 한 도구가 다 한다는 환상 — 답은 항상 조합이다.
2. 분당 단가만 보고 결정 — 캐시·운영 비용을 빼먹는다.
3. yaml 1000줄 워크플로 — 분기·반복은 코드로 빼라.
4. PR 안에서 prod 배포 — 승인 흐름과 분리하라.
5. secret을 평문으로 출력 — set -x 금지.
6. flaky test 재실행으로 무마 — 근본 원인을 잡아라.
7. 캐시 invalidation 없는 빌드 — 깨진 캐시가 영원히 산다.
8. 배포 후 검증 없음 — smoke test는 필수.
9. 롤백 절차가 문서로만 — 자동화하라.
10. CI/CD 평가를 한 번도 안 다시 함 — 1~2년마다 재평가.
다음 글 예고
다음 글 후보: **GitOps 깊게 파기 — Argo CD vs Flux의 진짜 차이**, **모노레포 빌드 가속화 — Bazel·Buck2·Turborepo·Nx 비교**, **공급망 보안 — Cosign·SBOM·SLSA 실전 적용기**.
> "CI/CD는 도구가 아니라 신경계다. 신경계의 속도가 조직의 속도를 결정한다."
— CI/CD 플랫폼 2026, 끝.
참고 / References
- [GitHub Actions Documentation](https://docs.github.com/en/actions)
- [GitHub Larger Runners](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners)
- [GitLab CI/CD Documentation](https://docs.gitlab.com/ee/ci/)
- [GitLab Duo](https://about.gitlab.com/gitlab-duo/)
- [CircleCI Documentation](https://circleci.com/docs/)
- [CircleCI Sphere — TestGPT](https://circleci.com/blog/announcing-circleci-sphere/)
- [Buildkite Documentation](https://buildkite.com/docs)
- [Dagger — Programmable CI](https://dagger.io/)
- [Dagger GitHub — dagger/dagger](https://github.com/dagger/dagger)
- [Earthly Documentation](https://docs.earthly.dev/)
- [Drone CI](https://www.drone.io/)
- [Harness CI](https://www.harness.io/products/continuous-integration)
- [Argo CD](https://argo-cd.readthedocs.io/)
- [Flux CD](https://fluxcd.io/)
- [Flagger — progressive delivery](https://flagger.app/)
- [Tekton Pipelines](https://tekton.dev/)
- [OpenShift Pipelines](https://docs.openshift.com/pipelines/)
- [Jenkins](https://www.jenkins.io/)
- [Atlantis — Terraform PR automation](https://www.runatlantis.io/)
- [Spacelift](https://spacelift.io/)
- [Pulumi Deployments](https://www.pulumi.com/product/pulumi-deployments/)
- [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
- [Azure Pipelines](https://azure.microsoft.com/en-us/products/devops/pipelines)
- [Google Cloud Build](https://cloud.google.com/build)
- [Google Cloud Deploy](https://cloud.google.com/deploy)
- [BuildJet for GitHub Actions](https://buildjet.com/for-github-actions)
- [Namespace](https://namespace.so/)
- [Blacksmith](https://blacksmith.sh/)
- [RunsOn](https://runs-on.com/)
- [Depot](https://depot.dev/)
- [Ubicloud](https://www.ubicloud.com/)
- [Turborepo Remote Cache](https://turbo.build/repo/docs/core-concepts/remote-caching)
- [Nx Cloud](https://nx.app/)
- [Bazel Remote Cache](https://bazel.build/remote/caching)
- [sccache GitHub](https://github.com/mozilla/sccache)
- [Mise](https://mise.jdx.dev/)
- [Cosign / Sigstore](https://docs.sigstore.dev/cosign/overview/)
- [SLSA framework](https://slsa.dev/)
- [SPDX](https://spdx.dev/)
- [CycloneDX](https://cyclonedx.org/)
- [Harbor — CNCF](https://goharbor.io/)
- [Zot Registry](https://zotregistry.dev/)
현재 단락 (1/260)
2026년 어느 팀에서나 흔히 보이는 풍경이 있다. 플랫폼 팀이 "전사 표준은 GitHub Actions"라고 발표하면, 데이터 팀은 "우리 모노레포는 Buildkite로 돌리는 ...