Skip to content
Published on

CI/CD 플랫폼 2026 — GitHub Actions / GitLab CI / CircleCI / Buildkite / BuildJet / Earthly / Dagger 심층 비교

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

프롤로그 — 2026년에도 왜 CI/CD를 다시 보는가

2022년쯤 한국·일본 개발팀에 "어떤 CI 쓰세요"라고 물으면 대답이 비교적 단순했다. 스타트업은 GitHub Actions, 중견 이상은 Jenkins, 모바일은 Bitrise, IaC는 Atlantis 또는 자체 스크립트. 2026년의 같은 질문에는 대답이 길어진다. "GitHub Actions를 쓰는데 러너는 BuildJet로 갈아탔고, Docker 빌드는 Depot로 분리했고, 모노레포 빌드 캐시는 BuildBuddy로 쏘고 있어요" 같은 식이다. 더 큰 조직은 "메인 파이프라인은 Buildkite, 데이터 파이프라인 일부는 Argo Workflows, Terraform은 Spacelift로 따로 빼놨습니다"라고 답한다.

이 변화는 우연이 아니다. 세 가지 흐름이 동시에 일어났다.

  1. 러너가 병목이 됐다. AI 코드 생성으로 PR 수가 2~3배 늘었고, 테스트는 점점 무거워졌고, GitHub의 기본 러너는 그 속도를 따라가지 못한다. BuildJet·Depot·Namespace 같은 "더 빠른 러너" 시장이 생겼다.
  2. 빌드 파이프라인 자체가 컨테이너·코드로 옮겨갔다. YAML 매트릭스 지옥에서 벗어나려는 시도가 Earthly·Dagger로 결실을 맺었다. 같은 파이프라인이 로컬·CI·다른 CI에서 동일하게 돈다.
  3. k8s가 데이터·ML 워크로드까지 빨아들였다. Argo Workflows·Tekton이 데이터 엔지니어링 영역까지 CI를 넓혔다. CI와 워크플로 오케스트레이션의 경계가 흐려졌다.

이 글은 2026년 5월 기준으로 20여 개 CI/CD 도구를 같은 축으로 정리한다. "어떤 게 좋은가"가 아니라 **"어떤 조건이면 어떤 게 맞는가"**를 본다. 가격·기능 수치는 빠르게 바뀌므로, 구조적 차이에 집중한다.

모델이 점점 같아지면 하니스가 차이를 만든다 — AI 코딩 도구에서 했던 말이 CI에서도 똑같이 성립한다. 러너가 점점 같아지면 빌드 캐시·동시성·관측 가능성이 차이를 만든다.

1장 · 2026년 CI/CD 지도 — 4분류

20개가 넘는 도구를 한 번에 비교할 수는 없다. 먼저 큰 4분류로 나눈 뒤, 각 칸 안에서 자세히 본다.

A. 매니지드 SaaS CI (호스티드 러너 포함) GitHub Actions, GitLab CI/CD, CircleCI, Travis CI(쇠퇴), Cirrus CI. SaaS 사업자가 러너·콘트롤플레인·과금까지 다 가져간다. 셋업이 빠르고, 대신 비용 곡선이 가파르다. 이 카테고리의 사실상 표준은 GitHub Actions.

B. 셀프호스팅 / 하이브리드 CI Buildkite, Jenkins, Drone, Cirrus(부분). 콘트롤플레인은 SaaS이거나 self-host지만 러너는 자기 인프라(EC2·GKE·온프렘). 보안·비용·하드웨어 통제가 필요한 팀의 선택지.

C. k8s-네이티브 / 파이프라인 컴퓨트 Argo Workflows, Tekton, Namespace, 일부 Drone. CI를 k8s 위에서 돌리는 데 1급 지원. 데이터·ML·인프라 워크플로와 경계가 흐릿하다.

D. 도메인 특화 모바일 — Bitrise, Codemagic. IaC — Spacelift, Garnix, Cycloid. 모노레포 빌드 캐시 — Bazel + Buildbarn / BuildBuddy / EngFlow. 디펜던시 업데이트 — Renovate, Dependabot, Mend.

그리고 위 카테고리를 가로지르는 **"가속 레이어"**가 따로 있다. BuildJet·Depot·Namespace는 GitHub Actions와 같이 쓰며 러너만 갈아치운다. 이게 2024~2026년 사이 시장에 등장한 가장 두드러진 변화다.

마지막으로 빌드 시스템 vs CI 시스템의 구분을 잊으면 안 된다. Bazel·Earthly·Dagger는 빌드 시스템에 가깝고, GitHub Actions·Jenkins·Buildkite는 오케스트레이터다. 두 레이어는 서로를 대체하지 않고 같이 쓰인다. Bazel 빌드를 GitHub Actions가 트리거하고 EngFlow가 캐시한다.

2장 · GitHub Actions — 사실상 표준

Surface · 강점 GitHub 저장소에 .github/workflows/ci.yml을 두면 끝. 2026년 5월 기준 OSS 저장소의 압도적 다수가 여기서 돈다. 마켓플레이스에 수만 개 액션이 있고, 사실상의 표준 빌드 액션(actions/checkout, actions/setup-node, actions/upload-artifact)이 잘 굳어 있다. 매트릭스 빌드, 재사용 가능 워크플로(reusable workflows), Composite Actions, OIDC를 통한 클라우드 자격증명 발급까지 거의 모든 핵심 기능이 무료 플랜에서도 돈다.

가격 퍼블릭 저장소는 무료. 프라이빗 저장소는 2,000분/월 무료, 그 다음부터는 분당 과금. Linux 러너 분당 0.008달러, macOS 분당 0.08달러, Windows 분당 0.016달러가 2026년 기준 표준가. 큰 러너(예: 16 vCPU)는 비례해서 비싸진다. 진짜로 무서운 건 macOS — 모바일 빌드를 호스티드 macOS 러너에서 돌리면 한 달 청구서가 쉽게 네 자릿수가 된다.

약점

  1. 기본 러너가 느리다. ubuntu-latest는 2 vCPU 7GB RAM. 모노레포에서는 답답하다. 그래서 BuildJet·Depot·Namespace 같은 가속 러너 시장이 생겼다.
  2. YAML 지옥. 큰 파이프라인은 reusable workflows로도 다 풀리지 않는다. ${{ matrix.os }} 같은 표현식이 줄지어 나오면 디버깅이 고통스럽다 — 식이 잘못돼도 빌드 시간 중간에야 알 수 있다.
  3. 시크릿 누수 사고. Composite Action을 잘못 쓰면 secrets.*가 로그에 그대로 노출되는 사고가 2024~2025년에 여러 번 보도됐다. OIDC로 갈아타라는 권고가 강하게 나온다.

Self-hosted runner GitHub-hosted 러너가 부족하면 ARC(Actions Runner Controller, k8s 위에서 도는 자동 스케일 러너)를 띄운다. 사내 데이터센터·VPC 내부 자원 접근이 필요한 팀의 표준 답.

한 줄 요약

무료 시작·압도적 생태계·OIDC까지 — 거의 모든 팀의 출발점이지만, 러너가 병목이 되는 순간 BuildJet/Depot/Namespace로 갈아탈 준비를 해야 한다.

3장 · GitLab CI/CD — 통합 DevOps

Surface · 강점 GitLab은 처음부터 "Single Application for DevOps"를 표방했다. SCM·이슈·CI·CR·아티팩트 레지스트리·SAST·DAST·환경 추적이 한 화면에 다 들어 있다. .gitlab-ci.yml에 stages, jobs, rules를 적으면 끝. DAG(Directed Acyclic Graph) 파이프라인, child pipelines, multi-project pipelines, dynamic child pipelines가 잘 정착돼 있다. 큰 모노레포에서 GitHub Actions보다 표현력이 좋은 경우가 많다.

가격 / 자체 호스팅 SaaS는 무료 400분/월부터 시작, Premium 29달러/사용자/월, Ultimate 99달러/사용자/월. 그러나 진짜 강점은 on-premise. GitLab Community Edition은 무료고, Enterprise Edition은 라이선스. 한국 대기업·일본 SIer가 사내 GitLab을 돌리는 패턴은 2026년에도 굳건하다.

약점

  1. SaaS 호스티드 러너의 단가가 GitHub보다 비싼 경향. 그래서 self-hosted Runner를 같이 쓰는 게 일반적.
  2. UI가 무겁다. Premium/Ultimate의 보안 기능(SAST 결과 화면 등)은 잘 만들었지만 평범한 PR 리뷰 흐름은 GitHub가 더 빠릿하다.
  3. CI 마켓플레이스가 GitHub Actions만큼 풍성하지 않다. CI/CD Catalog가 2024~2025년에 정비됐지만 생태계 크기는 비교가 안 된다.

언제 GitLab을 고르나 SCM·CI·보안 스캐닝·아티팩트 레지스트리를 한 벤더로 묶어 관리하고 싶을 때, 그리고 on-prem이 강제 조건일 때. 일본의 보수적 엔터프라이즈, 한국 금융권에서 GitLab CE/EE 비중이 여전히 높다.

4장 · CircleCI — 오래된 유료 리더

Surface · 강점 CircleCI는 GitHub Actions가 등장하기 전 SaaS CI의 표준이었다. 2026년에도 여전히 유료 SaaS CI의 강자다. orbs(재사용 가능 컴포넌트), 강력한 매트릭스, 큰 머신 사이즈, GPU 러너, 테스트 분할(test splitting) 같은 기능이 잘 익어 있다. ARM/x86, Docker/머신/macOS 러너 선택이 자유롭다.

가격 크레딧 기반. Free 6,000 크레딧/주, Performance 15달러/월 + 사용량, Scale는 협상. 같은 작업에 GitHub Actions보다 50~100% 더 비싸지만, 빌드 시간이 짧으면 총비용이 비슷하거나 더 싸다. 빠른 머신·테스트 분할 덕분.

약점

  1. GitHub과의 통합이 GitHub Actions만 못하다. "PR 코멘트에 결과 표시" 같은 사소한 흐름에서 마찰이 있다.
  2. OSS 친화도가 낮다. 무료 플랜이 있지만 GitHub Actions의 "퍼블릭 저장소 완전 무료"와 경쟁이 안 된다.
  3. 장애 이력. 2023년 1월 시크릿 유출 사고가 트라우마처럼 남았다. 모든 사용자가 토큰을 재발급해야 했다.

언제 CircleCI를 고르나 이미 쓰고 있고, 테스트 분할·orbs 자산이 두텁다면 그대로. 신규 도입은 GitHub Actions·GitLab을 먼저 검토한 뒤 이유가 있을 때만.

5장 · Buildkite — 셀프호스팅 러너 모델

Surface · 강점 Buildkite의 핵심 철학은 "콘트롤플레인은 SaaS, 러너는 너희 인프라". .buildkite/pipeline.yml에 step을 정의하면 SaaS 콘트롤플레인이 큐를 관리하고, 너희가 띄운 에이전트가 작업을 가져간다. AWS·GCP·온프렘 어디에 띄워도 같다.

왜 사람들이 쓰는가

  1. 데이터를 외부 SaaS에 안 보내고도 매니지드 UI를 쓴다. 빌드 로그는 너희 인프라에 남기고, 메타데이터만 Buildkite로 간다.
  2. 무거운 빌드에 최적. 큰 머신, GPU, ARM, 큰 디스크 — 자기 인프라에서 자유롭게 띄운다.
  3. 요금이 시트 기반. 사용량이 아니라 사용자 수에 비례. 무거운 빌드를 많이 돌리는 팀에서 GitHub Actions·CircleCI보다 훨씬 저렴해진다.

대표 사용자 Shopify, Pinterest, Airbnb, Lyft 같은 모노레포·중대형 엔지니어링 조직. 일본에서는 메르카리가 일부 백엔드 파이프라인에 Buildkite를 쓰는 것으로 알려져 있다.

약점

  1. 자기 인프라가 필요하다. AWS·GCP 비용·운영 부담이 추가된다.
  2. 마켓플레이스가 GitHub Actions만 못하다. 플러그인이 있지만 양이 적다.
  3. UI가 평이하다. 화려한 대시보드를 원한다면 다른 선택지가 있다.

한 줄 요약

자기 인프라를 잘 운영할 수 있는 중대형 팀의 최선의 답. "데이터는 우리 거, 운영은 너희가" 모델.

6장 · BuildJet / Depot / Namespace — 빠른 러너 / 빠른 빌드

이 세 도구는 같은 카테고리 안에서 살짝 다르다. 공통점은 "GitHub Actions를 그대로 두고 더 빠른 컴퓨트만 갈아끼우는" 가속 레이어.

BuildJet GitHub-hosted Linux/ARM 러너를 2배 빠른 CPU, 더 많은 메모리, 더 큰 디스크로 갈아치운다. runs-on: buildjet-4vcpu-ubuntu-2204 같은 라벨로 바로 적용. 가격은 GitHub Actions 같은 사양 대비 약 50% 수준이라고 마케팅. Linux 위주이고 macOS는 제한적. 단순한 갈아끼우기로 효과를 보고 싶을 때 적합.

Depot 컨테이너 빌드에 특화. docker build를 depot build로 바꾸면, BuildKit + 리모트 캐시 + ARM/x86 동시 빌드가 자동으로 돈다. 멀티 아키텍처 이미지를 빌드하는 팀에서 빌드 시간이 510배 줄었다는 사례가 흔하다. GitHub Actions 러너도 제공 — depot-ubuntu-22.04처럼 라벨만 바꿔 쓰면 된다. 20242025년 사이 "Docker 빌드 분리" 카테고리에서 사실상의 표준이 됐다.

Namespace "Kubernetes-native CI"를 표방. 빌드 환경 자체를 코드로 정의하고 (rules.toml / Devbox 등), Namespace 콘트롤플레인이 클라우드 안에서 격리된 가상 머신 또는 컨테이너를 띄워 실행한다. GitHub Actions 러너로도 쓸 수 있고, 별도 CLI로도 돈다. 재현 가능한 빌드 환경 — 어제와 오늘의 러너가 똑같이 동작하는 것 — 이 셀링 포인트.

언제 가속 레이어를 도입하나

  • 빌드가 평균 10분 이상이고 PR당 비용이 신경 쓰이기 시작할 때
  • macOS 러너 청구서가 두려워질 때(Depot의 macOS·BuildJet의 macOS)
  • ARM 멀티 아키텍처 빌드가 표준이 됐을 때

도입 자체는 5분이다. runs-on: 한 줄만 바꾸면 된다. ROI 계산만 잘 하면 거의 무조건 이득인 시장이 됐다.

7장 · Earthly — Earthfile 컨테이너 기반

아이디어 "Dockerfile은 빌드만, Makefile은 워크플로만 한다. 둘을 합친 게 필요하다." Earthly는 Earthfile이라는 문법을 만들어 빌드 + CI 워크플로를 한 파일에 적는다. 모든 step이 컨테이너 안에서 돌고, 캐시는 자동, 출력은 호스트 또는 다른 컨테이너로 흘러간다.

핵심 가치 — 같은 파이프라인이 로컬·CI에서 동일하게 돈다 개발자의 노트북에서 earthly +test를 치면 CI가 도는 것과 똑같은 결과가 나온다. CI에서만 깨지는 빌드의 비율이 극적으로 줄어든다. 이게 모든 평가에서 가장 자주 언급되는 강점이다.

구조

# Earthfile
VERSION 0.8
FROM golang:1.22
WORKDIR /app

deps:
    COPY go.mod go.sum ./
    RUN go mod download

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

test:
    FROM +deps
    COPY . .
    RUN go test ./...

earthly +build가 위 타겟을 캐시 친화적 방식으로 실행한다. 캐시는 BuildKit 기반.

Earthly Cloud / Satellites Earthly Cloud는 호스티드 빌드 캐시·러너를 제공한다. Satellites라는 호스티드 빌드 머신 위에서 도는 캐시가 큰 모노레포에서 GitHub Actions보다 5~10배 빠르다는 보고. 2025년에 일부 가격 정책이 바뀌었으니 도입 전 직접 확인 권장.

약점

  1. 새 문법 학습 비용. Dockerfile을 이미 안다면 친숙하지만, 팀 전체에 강제하기는 약간 부담.
  2. 이미 GitHub Actions가 잘 도는 작은 프로젝트라면 도입할 이유가 약하다. 모노레포·복잡한 빌드일 때 ROI가 크다.

8장 · Dagger — 프로그래머블 파이프라인 (Solomon Hykes)

누가 만들었는가 Solomon Hykes — Docker의 공동창업자. Docker 떠난 뒤 Dagger를 창업했다. 야심은 명확하다. "CI 파이프라인은 YAML이 아니라 코드여야 한다."

아이디어 파이프라인을 Go·Python·TypeScript·Java로 작성한다. SDK를 호출하면 Dagger 엔진(BuildKit 기반)이 컨테이너 안에서 단계를 실행하고 결과를 돌려준다. 같은 코드가 로컬에서도, GitHub Actions에서도, GitLab CI에서도, Jenkins에서도 똑같이 돈다.

// 예시 — TypeScript SDK
import { connect } from "@dagger.io/dagger"

connect(async (client) => {
  const src = client.host().directory(".")
  const node = client.container().from("node:20").withDirectory("/app", src).withWorkdir("/app")
  await node.withExec(["npm", "ci"]).withExec(["npm", "test"]).sync()
})

왜 사람들이 이걸 좋아하는가

  1. 테스트 가능한 파이프라인. 유닛 테스트를 파이프라인 코드에 쓴다.
  2. CI 벤더 독립. 같은 함수를 GitHub Actions에서도, Jenkins에서도, 로컬에서도 부른다. 벤더 락인 탈출.
  3. 컴포저블 모듈. Dagger Cloud의 모듈 시스템으로 빌드 블록을 공유한다.

약점

  1. 러닝 커브. YAML 파이프라인보다 학습 비용이 크다. "그냥 빌드 한 줄" 짜는 데 SDK·언어 결정·모듈 구조까지 생각해야 한다.
  2. 에코시스템이 GitHub Actions 마켓플레이스만큼 크지 않다. Dagger 모듈이 늘고는 있지만 비교 대상이 어렵다.
  3. 벤더 운영 모델 변화. Dagger Cloud가 유료 SaaS로 자리 잡고 있어, OSS 엔진 외 부분의 비용 구조가 변하는 중.

누가 쓰면 좋은가 모노레포에서 파이프라인 코드가 1,000줄 넘어가 YAML로는 더 못 견디는 팀, 멀티 CI(GitHub Actions + Jenkins) 환경, "파이프라인도 코드"의 신념이 있는 팀.

9장 · Drone / Argo Workflows / Tekton — k8s 파이프라인

세 도구는 결이 다르다.

Drone 원래 OSS CI로 시작 → Harness가 2020년 인수 → 2024년 CNCF에 기증. 컨테이너 기반 파이프라인, .drone.yml로 정의, 러너는 도커·k8s·머신 모드. 단순함이 셀링 포인트다. GitHub Actions 등장 후 점유율은 줄었지만, 사내 GitOps + 가벼운 CI 조합에서 여전히 쓰인다.

Argo Workflows CNCF Graduated. k8s 위에서 도는 DAG/스텝 워크플로 엔진. 원래는 ML/데이터 워크플로 도구지만 CI 용도로도 자주 쓰인다. 각 step이 k8s Pod로 뜨고, Argo Events로 트리거된다. 모든 step이 k8s 리소스라는 게 양날의 검 — 가시성·확장성은 좋지만 단순한 CI에는 과하다.

Tekton 원래 Knative에서 갈라져 나온 CNCF 프로젝트. k8s CRD로 Pipeline, Task, PipelineRun, TaskRun을 정의한다. CI 빌딩 블록에 가깝다 — Tekton 위에 OpenShift Pipelines, Jenkins X 같은 더 친절한 UI가 올라간다. Red Hat이 OpenShift Pipelines로 강하게 밀고 있다.

언제 k8s-네이티브 CI를 고르나

  • 이미 k8s를 데이터/ML 워크로드로 쓰고 있고, CI도 같은 클러스터에서 돌리고 싶을 때
  • 빌드가 GPU·큰 메모리·특수 노드를 필요로 할 때
  • 멀티 테넌트 격리가 중요한 플랫폼 팀

약점 관측·디버깅 부담이 크다. kubectl logs로 파드를 찾아 들어가야 하는 경우가 잦다. 일반 개발자가 일상적으로 만지기엔 무겁다 — 그래서 보통 플랫폼 팀이 운영하고 개발팀은 GitHub Actions 같은 추상화 위에서 본다.

10장 · Jenkins — 여전히 살아있는 거인

현실 GitHub Actions가 표준이 됐다고 Jenkins가 죽지 않았다. 2026년에도 Jenkins는 엔터프라이즈·금융권·반도체·자동차에서 거대한 점유율을 유지하고 있다. CloudBees가 상용 지원으로 살아 있고, Jenkins X(k8s-네이티브 분파)도 일부에서 쓰인다.

왜 못 죽이는가

  1. 이미 천 개의 파이프라인이 돈다. Jenkinsfile, 자유형 잡, 플러그인 의존성이 거대하다.
  2. 플러그인 생태계가 어마어마하다. 1,800개 이상. "X 도구와 통합하려면" 플러그인이 거의 항상 존재.
  3. 온프렘에서 동작이 검증돼 있다. GitHub Actions의 ARC도 가능하지만, Jenkins만큼 익숙한 운영팀이 많지 않다.

고통

  1. 보안 — 플러그인의 CVE가 분기마다 나온다. 패치 적용이 늦다.
  2. UI — 2025년에도 클래식 UI 비중이 크다. Blue Ocean은 동결됐다.
  3. 신규 인력이 안 들어온다 — 신입 개발자가 Jenkinsfile을 배우려 하지 않는다.

전략 "새 프로젝트는 GitHub Actions로, 기존 Jenkins는 동결한 채 단계적으로 옮긴다"가 현실적인 패턴. Jenkins → GitHub Actions 마이그레이션 가이드가 GitHub 공식 문서에 들어 있을 정도로 흔한 길.

11장 · Spacelift / Garnix / Cycloid — Terraform / IaC CI

왜 별도 카테고리인가 Terraform/OpenTofu/Pulumi/CDK 워크플로는 일반 CI와 다르다. drift detection, policy-as-code, plan/apply의 두 단계 흐름, 멀티 클라우드 자격증명 같은 요구사항이 일반 CI에는 없다. 그래서 IaC 전용 CI가 별도 시장으로 자리 잡았다.

Spacelift Terraform/OpenTofu/Pulumi/CloudFormation/Ansible/Kubernetes 통합. Stack과 Run의 개념, OPA 기반 정책, drift detection, Self-hosted worker pool, AWS/GCP/Azure 자격증명 매니저까지. 한국 핀테크·게임사 일부에서 도입했다는 보고가 있다.

Garnix Nix 기반 CI. 빌드 결과의 재현성이 셀링 포인트. Nix 빌더가 결과를 콘텐츠 주소로 캐시하고, 같은 입력에 같은 출력을 보장한다. NixOS·Nix 생태계 안에서 굳건. 일반 팀이 도입하기엔 Nix 학습 비용이 크지만, 한 번 들이면 빌드 신뢰성이 다른 차원으로 올라간다.

Cycloid "DevOps 자동화 플랫폼" 포지셔닝. Terraform 모듈 카탈로그, 환경 프로비저닝, 비용 가시화, 권한 관리까지를 한 UI에 넣는다. 인하우스 플랫폼 팀을 작은 SaaS로 대체하려는 중견 기업에 어필.

대안

  • Terraform Cloud / HCP Terraform — HashiCorp 공식. 2024년 라이선스 BUSL 전환 이후 정치적 부담이 생긴 팀은 OpenTofu + Spacelift/Atlantis로 옮기는 중.
  • Atlantis — OSS. self-host. 가장 가벼운 옵션.

12장 · Bitrise / Codemagic — 모바일 CI

왜 별도 시장인가 모바일 빌드는 macOS 러너가 필수다(iOS). 호스티드 macOS는 비싸고, 사인 키·프로비저닝 프로필·App Store Connect API·Firebase·내부 배포·코드 푸시까지 워크플로가 일반 CI와 결이 다르다. 그래서 모바일 전용 CI가 살아 있다.

Bitrise 2014년 헝가리 부다페스트 출발. iOS·Android 모두 지원. Step Library가 풍부하고, Workflow Editor로 시각적으로 파이프라인을 짠다. Fastlane 통합, App Store Connect 통합, 인-앱 코드 푸시까지 종합 패키지. 2024~2025년에는 Bitrise CI for AI 같은 ML 빌드도 밀고 있다.

Codemagic Flutter에 특화된 강점. Flutter 빌드의 사실상 표준이다. iOS·Android 양쪽을 한 워크플로에서 만들고, App Store/Play Store/Huawei/Amazon AppGallery까지 한 번에 배포. M2/M4 Mac Mini를 러너로 제공해 빌드 속도가 빠르다.

App Center의 죽음 Microsoft App Center는 2025년 3월 31일 공식 종료됐다. 한때 모바일 CI의 큰 한 축이었지만, Microsoft가 Visual Studio App Center로 흡수 → 결국 종료. App Center를 쓰던 팀은 2024~2025년 사이 Bitrise·Codemagic·GitHub Actions(macOS 러너)·Firebase App Distribution으로 갈렸다.

비용 현실

  • Bitrise: Hobby 무료, Velocity 50달러/월부터, 그 위는 사용량 기반.
  • Codemagic: 500분/월 무료, 그 다음 분당 과금. M2 macOS는 약 0.095달러/분.

호스티드 macOS는 어디서나 비싸다. 자체 Mac mini Farm을 운영하는 회사가 늘었다 — MacStadium·Scaleway·Hetzner 같은 호스팅 옵션과 합쳐서.

13장 · Bazel + Buildbarn / BuildBuddy / EngFlow — 리모트 빌드 캐시

왜 별도 영역인가 Bazel·Buck2·Pants 같은 빌드 시스템은 액션 단위로 캐시한다. 같은 입력에 같은 출력 — 입력 해시가 같으면 빌드 결과를 그대로 가져온다. 이 캐시를 여러 머신이 공유하면 빌드 시간이 극적으로 줄어든다. 그래서 Remote Build Execution(RBE) + Remote Cache 시장이 생겼다.

Buildbarn OSS. Google이 만들었던 buildfarm을 대체할 자유로운 구현. ContentAddressableStorage·ActionCache·ExecutionEngine을 모듈식으로 구성. 큰 모노레포의 OSS 옵션.

BuildBuddy SaaS + 셀프호스트 옵션. Bazel 친화적 UI, 액션 로그, 빌드 트리, RBE까지. Y Combinator 출신 팀, 2024~2025년에 빠르게 성장. Bazel 외에 Go·Rust용 빌드 가속도 만들고 있다.

EngFlow Bazel 공동 창업자들이 만든 회사. 엔터프라이즈 타깃, Bazel · Buck2 · Pants 모두 지원. 큰 게임사·금융권·자동차 OEM이 주된 고객. 가격이 비싸고 협상 베이스.

언제 RBE를 도입하나

  • 빌드가 모노레포에서 분당 수십 개 액션을 돈다
  • 같은 액션을 여러 PR이 동시에 빌드한다
  • 빌드 머신을 늘려도 시간이 안 줄어든다 (캐시 미스가 병목)

도입 후 효과는 극적이다 — 모노레포에서 10배 단축은 흔하다. 비용은 캐시 스토리지·네트워크·실행 머신 시간이지만, 개발자 대기 시간이 더 비싸다는 게 표준 ROI 논리.

14장 · Renovate vs Dependabot vs Mend — 디펜던시 업데이트

왜 별도 카테고리인가 2026년에는 디펜던시 업데이트 PR이 CI 트래픽의 큰 부분을 차지한다. 자동화가 없으면 사람이 못 따라간다. CI는 빌드만 하는 게 아니라 그 PR을 만드는 봇까지 책임진다.

Dependabot GitHub 1급 시민. .github/dependabot.yml 한 파일이면 끝. Security Updates(취약 의존성 자동 PR)와 Version Updates(주기적 업데이트 PR) 두 모드. GitHub Advanced Security와 연동. 단순한 설정·GitHub UI 통합이 강점.

Renovate 설정의 표현력이 압도적. 한 PR에 여러 의존성 묶기, 자동 머지 룰, monorepo·workspace 인식, 200개 이상의 매니저(npm·pip·gradle·terraform·docker·helm·ansible-galaxy ...), regex 매니저로 임의 파일까지 업데이트. Mend가 인수했지만 OSS·Self-host 옵션은 살아 있다.

Mend Renovate 인수 후, 더 엔터프라이즈 지향으로 확장. SCA(Software Composition Analysis)·라이선스 검증·정책 기반 업데이트·SBOM 관리까지. Renovate가 "기술적으로 강함"이라면 Mend는 "조직적·정책적 통제".

선택 가이드

  • 작은 팀·GitHub 위주 → Dependabot
  • 큰 팀·복잡한 모노레포·Terraform/Helm까지 → Renovate
  • 컴플라이언스·SBOM·라이선스 추적 필수 → Mend

세 도구 모두 CI를 트리거한다. CI 비용에서 디펜던시 봇 PR이 차지하는 비중을 측정해보면 의외로 크다.

15장 · 한국 / 일본 — 토스, 카카오, 메르카리, CyberAgent

한국 — 토스 토스의 SLASH 컨퍼런스 자료를 보면, 토스는 GitHub Enterprise + GitHub Actions + ARC(self-hosted runner on k8s) 조합을 중심으로 한다. 빌드 캐시는 사내 솔루션, 배포는 ArgoCD. CI 파이프라인을 개발 팀이 자기 손으로 만들고, 플랫폼 팀이 ARC와 시크릿 관리·OIDC를 책임진다.

한국 — 카카오 카카오는 거대한 사내 GitLab 자산이 있다. CI는 GitLab CI/CD가 메인, 모바일은 사내 Mac 팜 + Bitrise. ML 워크로드는 Argo Workflows를 일부 채택. 음악(멜론)·게임·커머스마다 자율성이 있고, CI 스택도 카카오톡·다음·뱅크 등 자회사마다 다르다.

일본 — 메르카리 메르카리는 마이크로서비스가 1,000개에 가깝다. CI 스택은 GitHub Actions + Buildkite + Spinnaker 조합. Spinnaker로 배포 워크플로를 관리하고, CI는 GitHub Actions가 주력. 모노레포 일부에서는 Bazel + 사내 RBE를 쓴다는 보고.

일본 — CyberAgent ABEMA·게임 사업 — k8s 기반. CI는 Argo Workflows + GitHub Actions 혼합, 빌드 캐시는 BuildBuddy 또는 사내. 모바일은 Bitrise. 발표 자료에서 "PR 평균 빌드 시간 5분 이하 유지"를 KPI로 두는 게 인상적.

공통 패턴

  • 신규는 GitHub Actions, 기존은 자기 자산(Jenkins·GitLab·Bamboo)을 유지
  • 러너는 점점 self-hosted on k8s(ARC)로 이동
  • 빌드 캐시·RBE는 모노레포가 클수록 도입 ROI가 큼
  • 보안·시크릿 관리는 OIDC + Vault/AWS Secrets Manager 조합이 표준화

16장 · 누가 무엇을 골라야 하나 — 결정 트리

OSS 프로젝트

  • 첫 답: GitHub Actions. 퍼블릭 저장소 무료, 마켓플레이스 압도적.
  • 빌드가 무겁다면: BuildJet 라벨 변경으로 시작.
  • 컨테이너 빌드라면: Depot.
  • 파이프라인이 복잡해 YAML이 안 된다면: Earthly 또는 Dagger.

스타트업 (10~50명)

  • 메인 CI: GitHub Actions.
  • 모바일이 있다면: Codemagic(Flutter)/Bitrise(네이티브).
  • IaC가 많다면: Spacelift 또는 Atlantis(OSS).
  • 디펜던시 봇: Dependabot으로 시작, 복잡해지면 Renovate.

중견 (50~300명)

  • 메인 CI: GitHub Actions 또는 GitLab(on-prem이면 후자).
  • 가속 레이어: BuildJet/Depot/Namespace — 빌드 시간·비용 측정 후 도입.
  • 모노레포 빌드: Bazel + BuildBuddy 검토 시작.
  • 디펜던시: Renovate.

엔터프라이즈 (300+, 금융·통신·정부)

  • 메인 CI: GitLab(on-prem) 또는 GitHub Enterprise + ARC.
  • Jenkins 자산은 동결한 채 단계적 마이그레이션.
  • IaC: Spacelift / Terraform Cloud / OpenTofu + Atlantis.
  • RBE: EngFlow(상용·서포트 강함).
  • 디펜던시: Mend(컴플라이언스 포함).
  • 모바일: Bitrise + 자체 Mac 팜.

모바일 전용 팀

  • Flutter: Codemagic.
  • iOS/Android 네이티브: Bitrise.
  • 호스티드 macOS 비용이 부담스러우면 MacStadium·Hetzner·Scaleway에 자체 Mac 팜.

데이터/ML 팀

  • 워크플로 오케스트레이션: Argo Workflows.
  • 데이터 파이프라인: Airflow 또는 Dagster.
  • 모델 학습 CI: 일반 CI + 별도 GPU 러너(Lambda Labs·CoreWeave 같은 데서).

17장 · 변하지 않는 원칙

도구는 매년 바뀐다. 변하지 않는 원칙 몇 가지로 글을 닫는다.

  1. CI는 비용·시간의 핵심 병목이다. 빌드 5분이 10분이 되면, 팀 평균 PR 머지 시간이 두 배가 된다. 도구 선택은 비용 문제이자 인지 부담 문제다.
  2. 러너·빌드·캐시는 분리 가능하다. GitHub Actions를 그대로 두고 러너를 BuildJet으로, 빌드를 Earthly로, 캐시를 BuildBuddy로 갈아끼울 수 있다. 한 번에 다 바꾸지 말고 한 레이어씩.
  3. OIDC를 켜라. 시크릿을 환경변수로 박는 시대는 끝났다. OIDC 토큰 → STS → 단기 자격증명이 표준.
  4. CI 비용을 측정하라. GitHub Actions 빌링 페이지, GitLab Usage Reports, CircleCI 크레딧 — 한 달에 한 번이라도 본다. 가속 레이어 도입 ROI는 측정에서 시작된다.
  5. 벤더 락인을 의식하라. Dagger·Earthly 같은 도구는 같은 파이프라인을 여러 CI에서 돌릴 수 있게 만든다. 한 벤더에 종속될수록 마이그레이션 비용이 커진다.
  6. 디펜던시 봇 PR을 자동 머지하라. 안 그러면 사람이 못 따라간다. 패치 버전은 테스트 통과 시 자동 머지, 마이너/메이저는 수동 검토 — 이 두 규칙이 표준.

CI는 "한 번 정하면 끝"인 영역이 아니다. 2~3년에 한 번씩 시장을 재평가하고, 작은 가속 레이어부터 갈아끼우며 학습해야 한다. 큰 마이그레이션은 보통 실패한다.

다음 글에서는 이 글의 도구들 중 가속 레이어(BuildJet·Depot·Namespace)와 빌드 시스템(Earthly·Dagger·Bazel)을 같은 모노레포에 동시 적용해 본 결과를 본다. 같은 코드, 다른 파이프라인, 측정된 시간·비용·실패 모드.

참고 / References

Discuss on Twitter • View on GitHub