Cloudflare가 Artifacts에 저장된 코드를 빌드·검사·테스트·배포하는 CI/CD 구성을 공개했다. 새 CI SDK는 Cloudflare Workflows와 Sandbox SDK를 바탕으로 각 명령을 격리된 환경에서 실행하며, Artifacts의 push 이벤트로 Workflow를 직접 시작할 수 있게 한다. 파이프라인은 YAML 대신 TypeScript로 정의할 수 있고, 의존성 캐시와 병렬 실행, 조건부 배포, AI 에이전트를 활용한 오류 수정 흐름도 구성할 수 있다.

발표의 핵심

  • Artifacts: 수백만 개 저장소 규모를 지원하도록 설계된 버전 코드 저장소다.
  • CI SDK: @cloudflare/ci를 통해 Workflows 안에서 설치, 린트, 테스트, 타입 검사, 빌드, 배포 단계를 정의한다.
  • 격리 실행: Workflows와 Sandbox SDK를 이용해 CI 명령을 안전하게 격리된 환경에서 실행한다.
  • 직접 트리거: wrangler 설정의 triggers.events에 Artifacts push 이벤트와 대상 Workflow를 연결한다.
  • 실행 최적화: 설치 결과를 캐시해 이후 단계에서 재사용하고, 서로 독립적인 검사들을 병렬로 실행할 수 있다.

저장부터 배포까지 연결한 구조

Cloudflare가 제시한 방향은 코드를 자사 플랫폼에 저장하고 그 코드의 빌드, 테스트, 배포까지 같은 플랫폼에서 처리하는 것이다. 저장 계층에는 Artifacts가 있고, 실행과 상태 관리는 Workflows가 담당한다. CI SDK는 이 둘을 연결해 파이프라인의 각 명령을 Workflow 단계로 실행한다. Sandbox SDK는 빌드나 린트, 타입 검사 같은 작업이 수행되는 격리 환경을 제공한다.

CI/CD 파이프라인은 순서가 있는 여러 단계로 구성되며, 단계가 실패하면 실행을 멈추고 오류를 보고한다. Cloudflare는 이 구조를 하나의 Workflow로 표현한다. 각 명령은 별도의 Workflow 단계에서 실행되므로 Workflows가 제공하는 재시도와 시간 제한 기능도 이용할 수 있다. 실행 결과는 Workflow 인스턴스로 표시되며, Workflows 대시보드에서 단계별 실행과 관측 정보를 확인할 수 있다.

GitHub Actions와 기존 Cloudflare 연동은 구분해야 한다

Cloudflare는 CI/CD가 흔히 GitHub Actions로 오케스트레이션되며 YAML 정의가 복잡해질 수 있다고 설명한다. 새 SDK가 제시하는 대안은 파이프라인을 TypeScript로 작성하고 각 단계를 step.do()에 대응시키는 방식이다. 이는 조건이나 구성 로직을 TypeScript로 표현할 수 있다는 의미다.

한편 이벤트 구독, Cloudflare Queue, consumer, queue handler가 필요했다는 설명은 GitHub Actions의 일반적인 구성 방식이 아니라 기존 Cloudflare Artifacts push 연동 방식에 관한 것이다. 이전에도 Artifacts 이벤트를 Queue로 구독해 push 때마다 빌드 파이프라인을 시작할 수 있었지만 여러 구성 요소를 직접 연결해야 했다. 이번에는 Artifacts push 이벤트의 대상으로 Workflow를 지정해, 이벤트가 발생할 때마다 Workflow 인스턴스를 직접 만들 수 있다.

TypeScript로 정의하는 CI 단계

기본 흐름은 먼저 외부 패키지와 도구를 설치한 뒤 린트, 테스트, 타입 검사, 빌드를 수행하고, 모든 검사가 성공하면 배포하는 형태다. 설치 단계에서는 package.json과 bun.lock 같은 파일을 캐시 입력으로 지정할 수 있다. 의존성은 sandbox snapshot으로 캐시되며, 이 snapshot은 사용자의 R2 버킷에 저장된다. 이후 단계는 캐시된 의존성에 접근하므로 각 작업이 설치를 반복할 필요가 없다.

const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});

await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);

Workflow의 각 단계는 기본적으로 독립적으로 시작하므로 별도 지정이 없다면 동시에 실행된다. 예시에서는 Promise.all()로 린트, 테스트, 타입 검사, 빌드를 병렬 실행하면서 모든 검사가 끝날 때까지 기다린다. 그 뒤 bun wrangler deploy를 실행하는 배포 단계를 두면 빌드 파이프라인이 통과한 경우에만 Worker를 배포할 수 있다.

push 이벤트가 CI 작업이 되는 방식

CI Workflow를 자동 실행하려면 Worker의 wrangler 설정에서 Workflow 및 Artifact 바인딩과 함께 events 필드를 추가한다. 이벤트 유형으로 cf.artifacts.repo.pushed를 지정하고 대상에 CI Workflow를 연결하면, 해당 이벤트가 발생할 때마다 새 Workflow 인스턴스가 실행된다.

필터에는 Artifacts namespace와 특정 repoName을 지정할 수 있다. 플랫폼이 namespace 안의 모든 고객 저장소에 같은 CI를 실행하려는 경우에는 repoName을 생략하고 namespace만 지정할 수 있다. Cloudflare는 이를 Artifacts 중심의 통합이라고 설명하며, 향후에는 Cloudflare 계정 내 다른 제품의 이벤트를 프로그램 방식으로 소비할 수 있도록 타입 지원 범위를 넓힐 예정이라고 밝혔다.

플랫폼 운영자를 겨냥한 구성

이번 구조는 많은 저장소를 운영하는 플랫폼의 서로 다른 CI 요구를 함께 처리하는 데 초점을 둔다. 플랫폼이 고객 대신 하나의 CI/CD 파이프라인을 작성해 여러 애플리케이션에 공유할 수 있고, 자체 CI가 필요한 고객은 dynamic workflows를 이용해 자기 저장소만을 위한 Workflow와 사용자 정의 CI 작업을 만들 수 있다.

두 방식을 하나만 선택할 필요도 없다. 플랫폼이 관리하는 CI와 고객이 작성한 사용자 정의 CI를 같은 namespace에서 동시에 실행할 수 있다. 따라서 플랫폼 자체 코드와 고객 코드에 서로 다른 작업을 적용하거나, 공통 빌드 절차는 플랫폼이 제공하면서 일부 저장소에는 별도 Workflow를 허용하는 구성이 가능하다.

AI를 연결한 셀프힐링 예시

CI Workflow에서는 AI 검토 에이전트를 호출하는 단계도 구성할 수 있다. Cloudflare가 소개한 셀프힐링 예시에서는 빌드 단계에 오류가 생기면 에이전트가 문제를 수정하고, 승인을 받을 수 있도록 수정 커밋을 push한다. 이는 오류 수정과 커밋 생성을 자동화하는 예시이며, 원문 역시 생성된 커밋에 대한 승인 단계를 명시한다. 공개된 Project Think 예제에서 해당 Workflow 구성을 직접 확인할 수 있다.

검토할 때 확인할 범위

현재 발표의 직접 통합 대상은 Artifacts push 이벤트다. 따라서 실제 적용 가능성을 판단할 때는 코드가 Artifacts 저장소와 namespace에 어떻게 배치되는지, Workflow와 Artifact 바인딩 및 이벤트 필터를 어떻게 구성할지 확인해야 한다. 의존성 캐시를 사용할 경우에는 어떤 파일을 cache.inputs로 둘지와 snapshot을 저장할 R2 버킷도 구성 범위에 포함된다.

또한 이 발표가 보여주는 것은 GitHub Actions 전반을 즉시 대체한다는 선언이 아니라, Cloudflare 안에서 Artifacts·Workflows·Sandbox SDK를 연결해 CI/CD를 작성하는 구체적인 방법이다. 특히 여러 저장소에 공통 파이프라인을 제공하는 플랫폼, 저장소별 사용자 정의 CI도 함께 허용해야 하는 서비스, Worker의 빌드 성공 뒤 자동 배포를 연결하려는 구성에서 제품의 의도가 선명하다.

출처와 검증