전체 Cloudflare API를 위한 에이전틱 CLI, cf를 소개합니다

지난 1년 동안 에이전트의 Wrangler 사용량이 급증했습니다.

2026년 3월에는 Wrangler 사용량의 4분의 1을 에이전트가 차지했으며, 이는 전년의 한 자릿수 비율에서 크게 늘어난 것입니다. 지난주에는 에이전트 사용 비율이 48%에 도달했습니다.

에이전트는 훨씬 더 활발한 사용자입니다. 하루에 사용하는 서로 다른 명령 수가 거의 두 배이며, 6개 이상의 명령을 사용할 가능성은 거의 네 배에 달합니다.

에이전트는 CLI를 좋아합니다. 하지만 Wrangler가 제공하는 명령은 약 280개 작업에 불과하고, Cloudflare는 수천 개 작업을 제공합니다.

올해 초 우리는 이 문제를 어떻게 해결할 계획인지 예고했습니다. 그리고 오늘, 새로운 CLI인 cf를 소개하면서 에이전트가 모든 Cloudflare 제품을 사용할 수 있도록 합니다.

cf는 차세대 소프트웨어 개발을 위해 구축된 CLI입니다:

• 에이전트는 맞춤형 검색 및 스티어링을 통해 원하는 작업에 필요한 명령을 찾을 수 있습니다.
• JSON이 기본 인터페이스입니다. 사람이 볼 때는 보기 좋게 출력하고, 에이전트에는 컨텍스트 사용량을 최대한 줄일 수 있도록 압축해서 제공합니다.
• cloudflare.config.ts는 Workers부터 시작해 Cloudflare 전체를 위한 새로운 구성 형식이며, TypeScript의 안전성과 정확성을 여러분과 에이전트가 사용하는 언어 서버 프로토콜(LSP)에 제공합니다.
• Vite가 기본이 되어 뛰어난 로컬 개발 서버와 개발자 및 프레임워크 작성자를 위한 플러그인 제품군을 제공합니다.

오픈 베타를 지금 전역으로 설치하고 어디서든 실행하세요:

npm i -g cf

cf로 에이전트가 전체 Cloudflare API에 액세스할 수 있습니다

에이전트가 Cloudflare에서 할 수 있는 모든 일을 할 수 있다면 어떨까요? 이것이 올해 초 우리의 관심을 끈 질문이었습니다. 에이전트의 역량은 계속 강력해졌지만, Cloudflare의 CLI로 할 수 있는 일은 여전히 제한적이었습니다.

Wrangler는 각 제품 팀이 기여하면서 각자 방식으로 명령줄 개발자 경험을 만들어 온 수작업 기반 도구였습니다. 팀 전반에 일관된 패턴을 적용하는 것은 약 280개 명령 경로에서도 사실상 불가능했습니다. 각 팀이 서로 다른 시기에 자체 방식을 정하면서 d1 info, hyperdrive get, workflows describe 등에서 용어가 일관되지 않았습니다. 일부 팀은 수천 줄의 코드로 완전히 맞춤형 경험을 구축했지만 실제 사용은 극히 드물었고, 같은 문제를 해결하는 접근 방식도 팀마다 달랐습니다.

우리는 기존 기능을 표준화하는 동시에 한 번에 대규모로 확장하고 싶었습니다. Forge는 Cloudflare의 새로운 통합 API 생성 파이프라인으로, API 문서와 SDK 생성에 사용되는 API 스키마에서 CLI 명령을 직접 생성한다는 아이디어를 바탕으로 이를 가능하게 했습니다. 우리가 제공하는 모든 것에는 OpenAPI 스키마가 있으며, 여기에 약간의 정보만 더 주석으로 추가하면 Forge가 CLI를 만드는 소스로 사용할 수 있습니다.

이를 통해 우리는 cf를 Wrangler가 오랜 기간 구축한 약 280개 기능에서 확장해, 3,000개가 넘는 작업으로 구성된 Cloudflare API 전체 범위를 포괄할 수 있습니다.

이제 에이전트에 cf 하나만 제공하면 Worker 설정, 배포, 모니터링 및 관찰, Cloudflare Access로 보호, 도메인 구매, 앞단에 Cloudflare WAF 적용까지 모두 하나의 도구로 요청할 수 있습니다.

cf를 한 번도 사용한 적 없는 에이전트를 위해 구축하기

cf는 에이전틱 개발이 소프트웨어 구축 및 배포 방식을 크게 바꾸고 있는 소프트웨어 엔지니어링의 흐름을 위해 만들어졌습니다. 올해 우리는 이러한 변화를 지원하는 도구 제공에 집중해 왔으며, 그 결과가 cf입니다. cf는 처음부터 에이전트를 염두에 두고 구축되었고, 에이전틱 명령 검색을 위한 새로운 도구를 포함합니다. 우리는 이런 기능이 가까운 미래에 더 많은 CLI의 표준이 될 것이라고 생각합니다.

Wrangler에는 수년간의 문서, 블로그, 제3자 가이드가 LLM 학습 과정에 흡수되어 있다는 이점이 있었습니다. 하지만 바로 그 점이 단점이기도 했습니다. 이제 Wrangler의 작동 방식을 바꾸면 이미 학습된 행동과 충돌하며, 우리가 원하는 개선 규모를 생각하면 큰 변화는 피할 수 없습니다.

에이전트가 한 번도 본 적 없는 새 CLI를 도입하는 것은 큰 파괴적 변화처럼 들리지만, 실제로는 우리가 할 수 있는 가장 깔끔한 방법입니다. 우리가 내린 설계 결정, 적용할 수 있는 컨텍스트 삽입, 추가할 수 있는 AGENTS.md 파일 덕분에 이런 방식으로 전환하는 편이 에이전트가 익숙한 도구의 두 버전 사이에 있는 큰 차이를 일일이 맥락화하도록 하는 것보다 오히려 덜 혼란스럽습니다. 출시 시점부터 이런 에이전트 중심 기능 몇 가지를 기본 제공하며, 앞으로 더 추가할 예정입니다.

에이전트는 표를 보는 대신 JSON을 필터링해야 합니다

에이전트가 Wrangler를 사용할 때는 실행하는 모든 명령에 --json을 붙인 다음, 출력에서 일부 필드만 추출하기 위해 jq로 필터링하는 경우가 많습니다. 하지만 Wrangler에서는 일부 명령만 --json을 지원했고, 많은 명령은 터미널에서 사람이 보기 좋게 만든 유니코드 표를 반환했습니다. 에이전트도 이를 처리할 수는 있지만 jq 필터보다 더 많은 시간과 토큰이 듭니다.

cf에서는 반대로 접근합니다. 에이전트에게 필요한 것은 JSON이며, 앞으로 이 도구의 주요 사용자가 에이전트라면 JSON이 기본이어야 합니다. 사람이 직접 액세스할 일이 거의 없는 대부분의 명령에서는 이 선택이 분명히 합리적입니다.

사람인 여러분은 실제로 이 CLI를 에이전트를 통해 한 단계 간접적으로 사용합니다. 에이전트가 결과를 쉽게 필터링한 뒤 여러분이 요청한 형식으로 그 목록을 돌려주는 편이, 여러분이 직접 읽을 가능성이 거의 없는 표를 제공하는 것보다 낫습니다.

하지만 구매할 도메인을 찾는 것처럼 실제로 개인의 입력이 필요할 수 있는 작업이라면 어떨까요?

에이전트가 길고 번거로운 순서로 명명된 매개변수를 연결해야 액세스할 수 있는 명령은 간단히 양식을 작성하면 됩니다. cf는 API 요구 사항을 검증된 일련의 입력으로 분해하므로, 요구 사항이 복잡한 도메인을 구매하는 경우에도 쉽게 따라갈 수 있습니다.

아니면, 정 원하신다면 에이전트에게 그냥 해 달라고 하세요.

에이전트가 올바른 명령을 스스로 찾을 수 있습니다

CLI에 가능한 경로가 3,000개나 있을 때, 컨텍스트를 불필요하게 늘리지 않고 에이전트가 필요한 작업을 빠르게 찾게 하려면 어떻게 해야 할까요? 이를 위해 우리는 cf cli search도 추가했습니다.

이 명령을 사용하면 에이전트가 자연어로 필요한 작업을 물을 수 있고, 작은 검색 인덱스가 API 설명과 매개변수를 바탕으로 적절한 명령 목록을 제공합니다. 에이전트가 처음 --help를 실행하면 이 명령에 대해 자동으로 알려 줍니다.

에이전트를 타입 체크하는 구성

새로운 구성 형식은 TypeScript를 기반으로 하며, 사람과 에이전트 모두 쉽게 파싱할 수 있고 구성을 프로그래밍 방식으로 작성할 수 있습니다.

타입이 지정된 구성은 에이전트에 매우 유용합니다. 프로그래밍 방식 구성 형식에 대한 사전 컨텍스트가 전혀 없어도 에이전트는 필요할 때 구성을 쉽게 찾아 수정할 수 있었습니다. Wrangler의 동명 기능과 크게 달라진 env 같은 요소도 마찬가지입니다. Claude Code와 Codex처럼 LSP 플러그인을 사용하는 모든 에이전트는 컨텍스트 안에서 구성 파일 형식을 더 잘 해석할 수 있어 훨씬 정확한 제안을 할 수 있습니다.

접근 가능한 스키마가 없었던 TOML이나, 연결된 스키마가 있어도 에이전트가 거의 사용하지 않았던 JSONC와 비교해 보세요.

Cloudflare 내부의 일부 Wrangler 구성 파일은 개발자별 커스텀 환경이 많아 5,000줄이 넘었지만, 각 개발자의 구성을 더 효율적으로 생성하는 팩토리 파일로 바꾸면서 40% 줄었습니다.

이는 Wrangler에서 일반적이었던 env 블록 복사 대신 동일한 범용 기반에서 각 환경을 프로그래밍 방식으로 정의해 구현합니다. 여러 환경이 있는 간단한 Worker는 Vite 네이티브 mode 인수만 전환해 한 구성 세트에서 다른 세트로 바꿀 수 있습니다.

이 작업을 하는 간단한 구성은 이제 다음과 같습니다:

import { bindings, defineConfig } from "cf/config";
import * as entrypoint from "./index.js" with { type: "cf-worker" };

export default defineConfig(({ mode }) => ({
  worker: {
    name: "example-worker", 
      entrypoint,
      compatibilityDate: "2026-09-27",
      env: {
        Environment: bindings.text(`This is ${mode} environment`),
      },
    },
}));

Cloudflare Worker는 cf migrate를 통해 이 새 형식으로 마이그레이션할 수 있습니다.

Worker를 더 쉽게 구축할 수 있도록 몇 가지 도우미 함수도 제공합니다.

bindings는 에이전트가 개발자 플랫폼에서 제공하는 모든 기능을 찾아볼 수 있는 간단한 출발점을 제공합니다. 환경 변수부터 스토리지, 데이터베이스, 큐까지 모든 항목을 에디터가 자동 완성하고 설명할 수 있습니다.

import { bindings, defineConfig } from "cf/config";

export default defineConfig(({ mode }) => ({
  worker: {
    // ...
    env: {
      API_URL: bindings.text(
        mode === "production"
          ? "https://example.com"
          : "https://staging.example.com",
      ),
      API_TOKEN: bindings.secret(),
      CACHE: bindings.kv({
        id: mode === "production"
          ? "production-namespace-id"
          : "staging-namespace-id",
      }),
      DATABASE: bindings.d1({ name: `example-${mode}-database` }),
      UPLOADS: bindings.r2({ name: `example-${mode}-uploads` }),
      JOBS: bindings.queue < { userId: string } > ({
        name: `example-${mode}-jobs`,
      }),
      AI: bindings.ai(),
      SEARCH_INDEX: bindings.vectorize({
        name: `example-${mode}-search`,
      }),
      API: bindings.worker({ worker: `example-${mode}-api` }),
    },
  },
}));

마찬가지로 triggers를 위한 도우미도 포함했습니다. 이는 Worker의 경로, 큐, 일정, 이메일 트리거를 정의하는 새로운 방식입니다. 구성 파일 곳곳에 흩어 놓는 대신, 이제 Worker 실행을 트리거할 수 있는 작업을 하나의 블록에서 쉽게 찾을 수 있습니다.

import { defineConfig, triggers } from "cf/config";

export default defineConfig({
  worker: {
    // ...
    triggers: [
      triggers.fetch({ pattern: "example.com/*" }),
      triggers.scheduled({ schedule: "0 * * * *" }),
      triggers.queue({ name: "jobs", maxBatchSize: 10 }),
      triggers.email({ addresses: ["support@example.com"] }),
    ],
  },
});

defineConfig.worker는 시작에 불과합니다. cloudflare.config.ts를 통해 Cloudflare 전체를 관리하는 것이 우리의 목표입니다. 필요한 모든 제품은 cf를 통해 에이전트가 해당 API를 사용할 수 있는 것과 함께 타입 안전 구성으로 표현할 수 있게 됩니다. 곧 이 구성 파일 하나로 전체 정책을 구성하고, 영역을 설정하고, DNS를 구성하는 등의 작업을 할 수 있습니다.

최고 수준의 개발 경험

Wrangler가 JavaScript Workers 구축을 처음 시작했을 때는 Vite가 존재하지 않았습니다. 대신 Wrangler에서 esbuild를 사용해 Workers를 번들링했습니다. Wrangler가 :8787에서 제공하던 개발 서버는 Wrangler 팀이 직접 만든 것이었고, 이를 수정하려면 Miniflare 같은 Cloudflare 전용 로컬 도구의 내부까지 손대야 했습니다.

Vite는 이를 크게 개선하며, 사용할 수 있는 방대한 플러그인 생태계를 제공합니다. 또한 HMR(핫 모듈 교체)을 지원하는 최고 수준의 개발 서버와, Rust 기반 라이브러리 Rolldown을 사용해 트리 셰이킹하는 빌드를 제공합니다. Vite에서 할 수 있는 일이라면 Cloudflare Vite Plugin에서도 할 수 있습니다.

Cloudflare Vite Plugin은 프런트엔드 중심 프로젝트든 백엔드 API든 무엇을 만들든 Workers를 구축하는 데 권장하는 방식입니다. Vitest 플러그인과 함께 사용하면 Workers 런타임과 일치하고 바인딩 및 플랫폼 API에 직접 액세스할 수 있는 일관된 개발 및 테스트 환경을 제공합니다.

cf는 Vite를 기본으로 사용하도록 구축되었습니다. 대부분의 Workers는 에이전트를 이용해 간단히 마이그레이션할 수 있습니다. 시간이 더 필요한 경우도 있기 때문에, esbuild를 계속 사용해야 하는 JavaScript Workers와 Rust 및 Python Workers의 개발 및 배포는 cf가 계속 Wrangler에 위임합니다.

Wrangler에서 마이그레이션

Worker를 Wrangler에서 마이그레이션하는 방법은 다음 명령을 실행하기만 하면 됩니다

cf migrate

이미 Vite로 빌드하는 Workers는 cloudflare.config.ts로 자동 변환됩니다. Worker가 빌드에 Wrangler의 esbuild를 사용한다면 cf가 계속 Wrangler에 빌드를 위임합니다.

오픈 베타가 종료되면 여러분과 에이전트가 cf를 사용하도록 안내하는 Wrangler의 마지막 메이저 버전을 출시하겠습니다. 마이그레이션할 시간을 드리기 위해 베타 종료 후 18개월 동안 Wrangler의 유지보수 지원을 계속 제공합니다.

새 프로젝트에서는 cf init/deploy를 실행해 Cloudflare에 맞게 자동 구성할 수도 있습니다. 이 명령은 Cloudflare Vite Plugin을 설치하고 구성 파일을 생성합니다.

정적 사이트는 시작할 때 여전히 구성 파일이 필요하지 않으며, 프로젝트에서 cf deploy를 실행하기만 하면 배포할 수 있습니다.

cf로 새 Hello World 프로젝트를 시작하려면 cf init을 사용하세요.

cf는 오픈 소스이며, 문제는 GitHub 리포지토리에 보고할 수 있습니다.